Hoe Splunk ons heeft geholpen bij het oplossen van netwerkuitdagingen

Mei is de maand van zichtbaarheid: het perfecte moment om Splunk en Observability te leren kennen. Ontdek meer in onze laatste aflevering van “Wat is er nieuw met Cisco U.? (Scroll naar beneden naar het einde van de blog om nu te kijken!)

---

Binnen het infrastructuurbeheerteam van Cisco bieden we interactieve labs die gebruikers uitvoeren op Cisco U. en gebruiken in door instructeurs geleide cursussen via Cisco en Cisco Learning Partners. Op dit moment beheren we twee datacenters die de leveringssystemen bevatten voor al die labs en leveren we duizenden labs per dag.

We streven ernaar om een betrouwbare en efficiënte labomgeving te bieden aan elke student. Er gebeurt veel achter de schermen om dit te laten gebeuren, waaronder monitoring. Een belangrijke manier om de gezondheid van onze infrastructuur te monitoren is door logs te analyseren.

Als we infrastructuur en tools verzamelen, is onze filosofie “eet ons eigen hondenvoer” (of “drink onze champagne”, als je dat liever hebt). Dit betekent dat we waar mogelijk Cisco-producten gebruiken. Cisco-routers, switches, servers, Cisco Prime Network Registrar, Cisco Umbrella voor DNS-beheer, Cisco Identity Services Engine voor authenticatie en autorisatie. Je krijgt het idee.

We gebruikten software van derden voor enkele van onze loganalyse om de lablevering bij te houden. Onze lableveringssystemen (LDS) zijn intern ontwikkeld en gebruiken volledig unieke logberichten voor henzelf. We begonnen enkele jaren geleden met het gebruik van Elasticsearch, met bijna geen eerdere ervaring, en het kostte ons vele maanden om ons systeem aan de praat te krijgen.

Toen kocht Cisco Splunk en Splunk werd plotseling onze champagne! Dat was het moment waarop we de beslissing namen om over te stappen naar Splunk.

Ook geld speelde een rol. Onze interne IT bij Cisco begon Splunk Enterprise aan te bieden als service (EAAS) tegen een veel lagere prijs dan onze extern gehoste Elasticsearch-instanties. Met Elasticsearch moesten we alle VM’s architecten en beheren die een volledige elastische stack vormden, maar het gebruik van Splunk Eaas bespaarde ons veel tijd. (Overigens kan iedereen gratis zes maanden ontwikkelen op Splunk Enterprise door zich aan te melden bij Splunk> Dev.) We begonnen echter met beperkte voorafgaande training.

We hadden enkele maanden van overgang, dus het leren van Splunk was ons eerste doel. We richtten ons niet alleen op een specifiek gebruiksscenario. In plaats daarvan stuurden we al onze logs, niet alleen onze LDS-logs, naar Splunk. We configureerden routers, switches, ISES, ASAs, Linux-servers, load balancers (NGINX), web servers (Ruby on Rails) en meer. (Zie de bijlage voor meer details over hoe we de gegevens naar Splunk Enterprise hebben gekregen.)

We waren in feite een gootsteen vol logboeken aan het verzamelen en gebruikten ze om meer te weten te komen over Splunk. We hadden basisontwikkelingsvaardigheden nodig zoals het gebruik van de Splunk Search Processing Language (SPL) om alarmen te bouwen en dashboards te maken. (Zie de bronnen voor een lijst van leermiddelen die we hebben gebruikt.)

Netwerkapparatuur monitoring

We gebruiken SNMP om onze netwerkapparatuur te monitoren, maar we hebben nog steeds veel systemen uit het tijdperk Configure-Every-Device bij de hand. De configuraties zijn overal. En de oude NMS-systeem-UI is onhandig. Met Splunk hebben we een alternatief en moderner systeem gecreëerd met eenvoudige logconfiguraties op de apparaten. We hebben Splunk Connect voor Syslog (SC4S) gebruikt als pre-processor voor de in syslog-stijl gelogde logs. (Zie de bijlage voor meer details over SC4S.)

Zodra onze router- en switch-logs bij Splunk Enterprise aankwamen, begonnen we het Splunk Search Processing Language te leren en te experimenteren. We waren snel operationeel nadat we enkele basisregels en syntaxisfuncties hadden onder de knie gekregen. De bijlage bevat elke SPL-functie die we nodig hadden om de projecten in deze blog te voltooien.

We leerden snel hoe we waarschuwingen konden bouwen; dit was intuïtief en vereiste weinig training. We kregen meteen een waarschuwing over een voeding. Iemand in het lab had per ongeluk de voedingskabel losgekoppeld. De tijd tussen het ontvangen van de eerste logs in Splunk en het hebben van een werkende waarschuwing was zeer kort.

Aanvallen op onze openbare systemen

Afgelopen zomer hadden we een verdachte ineenstorting van de webinterface voor ons planningsysteem. Na een saaie tijd door logs te doorzoeken, vonden we een grote scriptaanval op de load balancer (het publieke gedeelte van ons programma). We hebben het directe probleem opgelost door enkele verbindingen toe te voegen naar de interne systemen vanaf de load balancer.

Vervolgens hebben we meer geleerd door de Nginx-logs van de load balancer naar Splunk te uploaden. Dit was buitengewoon eenvoudig met de Universal Forwarder (zie bijlage). Met behulp van die logs hebben we een eenvoudig dashboard gebouwd, dat onthulde dat kleinschalige aanvallen, script-kiddie, voortdurend plaatsvonden, dus besloten we om Splunk proactief te gebruiken om deze slechte actoren te blokkeren. We hebben het gebruik van de waardevolle statistiekopdracht in SPL onder de knie gekregen en enkele nieuwe waarschuwingen ingesteld. Vandaag hebben we een waarschuwingssysteem dat alle aanvallen detecteert en een snelle reactie om de bronnen te blokkeren.

Automatiseringsblunders

We hebben onze ISE-logs onderzocht en zijn met onze nieuwe SPL-vaardigheden en Dashboard aan de slag gegaan om snel grafieken te maken van succes- en mislukte toegangspogingen. We merkten meteen een verdacht patroon van mislukte toegangspogingen vanuit een specifiek gebruikersaccount dat werd gebruikt door de back-upautomatisering voor onze netwerkapparatuur. Een beetje graven onthulde dat de automatisering verkeerd was geconfigureerd. Met een eenvoudige aanpassing aan de configuraties was het probleem opgelost.

Menselijke fouten

Als onderdeel van ons datacenterbeheer gebruiken we NetBox, een database speciaal ontworpen voor netwerkdokumentatie. NetBox heeft tientallen objecttypen voor zaken als hardwareapparaten, virtuele machines en netwerkcomponenten zoals VLAN’s en houdt een wijzigingslogboek bij voor elk object in de database. In de NetBox-gebruikersinterface kunt u deze wijzigingslogs bekijken en enkele eenvoudige zoekopdrachten uitvoeren, maar we wilden meer inzicht in hoe de database werd gewijzigd. Splunk heeft gelukkig gegevens geïnterpreteerd in JSON-indeling van NetBox, met wat extra identificerende metagegevens toegevoegd.

We hebben een dashboard gebouwd dat de lopende wijzigingen en wie de wijzigingen aanbracht, laat zien. We hebben ook een waarschuwing ingesteld om af te gaan als er snel veel wijzigingen plaatsvonden. Binnen enkele weken was de alarmbel afgegaan. We zagen veel verwijderingen, dus gingen we op zoek naar een verklaring. We ontdekten dat een tijdelijke medewerker enkele apparaten had verwijderd en ze onvolledig had vervangen (sommige interfaces en IP-adressen waren weggelaten). Na een gesprek met de medewerker werden de apparaten correct bijgewerkt. En de monitoring gaat door.

Vervanging van Elasticsearch

Met wat basisvaardigheden van Splunk, waren we klaar om te werken aan de vervanging van ElasticSearch voor de monitoring en statistieken van de lablevering.

Om te beginnen moesten we de gegevens invoeren, dus hebben we de Universal Forwarder van Splunk geconfigureerd om specifieke applicatielogs op alle delen van ons leveringssysteem te monitoren. We kozen aangepaste SourceType-waarden voor de logs en moesten vervolgens veldenextracties ontwikkelen om de gegevens te krijgen die we zochten. De leercurve voor dit proces was zeer kort! Basisveldenextracties in Splunk zijn gewoon reguliere expressies die worden toegepast op gebeurtenissen op basis van de gegevens van sourcetype, bron of host. De veldexpressies worden geëvalueerd op het moment van de zoekopdracht. De Splunk Enterprise GUI biedt een handig hulpmiddel om die reguliere expressies te ontwikkelen. We hebben ook regex101.com gebruikt om de reguliere expressies te ontwikkelen en te testen. We hebben extracties gebouwd die ons hielpen gebeurtenissen bij te houden en te classificeren op basis van lab-ID’s en studenten.

Soms hebben we te maken met problemen met de beschikbaarheid van apparatuur. Stel dat een gebruiker van Cisco U. een lab start dat een specifieke reeks apparatuur vereist (bijvoorbeeld een reeks Nexus-switches voor DC-gerelateerde training) en er zijn geen beschikbare apparatuur. In dat geval ontvangen ze een bericht dat zegt: “Sorry, probeer later opnieuw” en ontvangen we een logboekbericht. In Splunk hebben we een waarschuwing ingesteld om bij te houden wanneer dit gebeurt, zodat we proactief kunnen onderzoeken. We kunnen ook deze gegevens gebruiken voor capaciteitsplanning.

We moesten onze logs verrijken met meer details over de labs (zoals labtitel en beschrijving) en extra informatie over de studenten die die labs startten (reserveringsnummer, bijvoorbeeld). We hebben snel geleerd hoe we de Lookup-tables moesten gebruiken. We hoefden alleen maar wat CSV-bestanden te verstrekken met labgegevens en reserveringsinformatie. In feite wordt de reservering-lookup-tabel dynamisch bijgewerkt in Splunk met behulp van een gepland rapport dat logs doorzoekt op nieuwe reserveringen en deze toevoegt aan de CSV-lookup-tabel. Met lopende zoekopdrachten hebben we alle dashboards gebouwd die we nodig hadden om Elasticsearch te vervangen en meer. Het bouwen van dashboards die met elkaar verbonden zijn en het koppelen aan rapporten was bijzonder eenvoudig. Onze dashboards zijn nu veel meer geïntegreerd en stellen ons in staat om naadloos labstatistieken te bekijken.

Als gevolg van onze aanpak hebben we enkele nieuwe handige dashboards voor het monitoren van onze systemen en hebben we Elasticsearch vervangen, waardoor onze kosten zijn verlaagd. We hebben verschillende problemen vastgelegd en opgelost tijdens het leren van Splunk.

Maar we hebben slechts het topje van de ijsberg aangeraakt. Bijvoorbeeld, onze analyse van het ISE-logboek kan veel dieper worden met behulp van de Splunk-app en add-on voor Cisco Identity Services, die wordt behandeld in de tutorial Cisco U., “Monitoring Network Access Control Using Cisco Identity Services Engine and Splunk.” We overwegen ook om onze eigen Splunk Enterprise-instantie te implementeren om meer controle te krijgen over waar en hoe de logs worden opgeslagen.

We kijken ernaar uit om onze leerreis voort te zetten.

---

Leermiddelen voor Splunk

We hebben vertrouwd op drie belangrijke bronnen om Splunk te leren:

• De gratis online trainingen van Splunk, met name deze zeven korte cursussen:

  • Inleiding tot Splunk
  • Gebruik van velden
  • Rapporten en waarschuwingen plannen
  • Zoeken onder de motorkap
  • Inleiding tot kennisobjecten
  • Inleiding tot dashboards
  • Gegevens in Splunk krijgen

• Documentatie van Splunk, met name deze drie gebieden:
• Cisco U.
• Zoeken

  • Zoeken op internet leidt vaak naar antwoorden op Splunk-communityforums, of je kunt er rechtstreeks naartoe gaan. We hebben ook nuttige informatie gevonden in blogs of andere helpsites.

NetBox: en

Elasticsearch: en

Bijlage

Gegevens verkrijgen: metagegevens zijn belangrijk

Alles begint bij de bron. Splunk slaat logs op als gebeurtenissen en stelt metadata-velden in voor elke gebeurtenis: tijd, bron, sourcetype en host. De architectuur van Splunk maakt snel zoeken mogelijk met zoekopdrachten die gebruikmaken van metadata-velden. Metadata moet van de bron komen. Zorg ervoor dat de juiste metadata uit al uw bronnen komt.

Gegevens verkrijgen: Splunk Universal Forwarder

De Splunk Universal Forwarder kan worden geïnstalleerd op Linux, Windows en andere standaardplatforms. We hebben enkele systemen handmatig geconfigureerd en voor de rest gebruikt. We monitorden gewoon de bestaande logbestanden voor veel systemen, dus de standaardconfiguraties waren voldoende. We gebruikten aangepaste SourceTypes voor onze LD’s, dus deze correct instellen was de sleutel voor ons om veldextracties te maken voor de LDS-logs.

Gegevens verkrijgen: Splunk Connect voor syslog

SC4S is gratis software speciaal gebouwd door Splunk die syslog-gegevens verzamelt en deze met extra metadata naar Splunk doorstuurt. De onderliggende software is syslog-ng, maar SC4s heeft zijn eigen configuratieparadigma. We hebben een SC4S ingesteld voor ons datacenter (en een koude standby toegevoegd met behulp van Keepalived). Voor ons was het instellen van SC4s op de juiste manier een niet-triviaal onderdeel van het project. Als u SC4 moet gebruiken, geef uzelf dan wat tijd om de juiste instellingen te maken en te tweaken.

Zoeken met de Splunk Zoekverwerkingstaal

Hier is een volledige lijst van de SPL-functies die we hebben gebruikt:

• Eval
• velden
• Top
• statistieken
• hernoemen
• TimeChart
• tabel
• toevoegen
• Dedup
• zoeken
• InputLookup
• iplocatie
• geostat

Rechten, rechten, rechten

Elk object dat in Splunk is gemaakt, heeft een reeks rechten die eraan zijn toegewezen: elk rapport, elke waarschuwing, elk veldextractie en elke tabel, enz. Wees voorzichtig bij het instellen ervan; ze kunnen u tegenwerken. Bijvoorbeeld, u kunt een dashboard maken met rechten die andere gebruikers toestaan het te bekijken, maar dashboards zijn meestal afhankelijk van vele andere objecten zoals indexen, veldextracties en rapporten. Als de rechten voor die objecten niet correct zijn ingesteld, zien uw gebruikers veel lege panelen. Het is een gedoe

BRON