-: In deze les gaan
we ons richten op monitoring en auditing.
Laten we eerst beginnen met monitoren.
Als we het over monitoren hebben, is
een van de belangrijkste taken van een beveiligingsanalist
het monitoren van het netwerk.
We zijn net detectives.
We proberen alles eruit
te halen wat er niet goed uitziet
en dit kan handmatig of geautomatiseerd gebeuren.
Welnu, syslog is een protocol waarmee verschillende apparaten
en softwaretoepassingen hun logs of eventrecords naar
een gecentraliseerde server kunnen sturen.
Nu volgt syslog een standaard client-server model.
En dit is de defacto standaard voor het loggen van gebeurtenissen
van gedistribueerde systemen over een netwerk.
Je zult syslog in gebruik zien in veel van de systemen
waar je dagelijks mee werkt.
Nu draait syslog op de meeste besturingssystemen en
op de meeste netwerkapparatuur.
Dus of je nu een Cisco router gebruikt of
een Windows machine of een Linux server, ze kunnen
allemaal syslog gebruiken.
Als we deze berichten terugsturen,
hoe ziet een syslog bericht er dan uit?
Een syslog bericht bevat een aantal dingen.
Het bevat een PRI-code, wat een prioriteitscode is.
Het bevat een koptekst en een berichtgedeelte.
Laten we het over elk van deze hebben.
Ten eerste hebben we deze PRI-code, deze prioriteit,
en deze wordt berekend op basis van de faciliteit
en het ernstniveau van de gegevens.
Vervolgens hebben we een header
en de header bevat de tijdstempel van de
gebeurtenis en de hostnaam.
We weten dus waar het vandaan kwam en hoe laat het was.
En tot slot hebben we het berichtgedeelte, dat het
bronproces van de gebeurtenis en de gerelateerde
inhoud bevat, in feite welke gegevens er zijn gebeurd en waarover je ons
iets wilt vertellen?
En dat is het idee hier met het berichtgedeelte.
Dit is het vlees en de aardappelen van deze boodschap.
Nu, toen we syslog behandelden,
zaten er een paar nadelen aan in de originele versie.
Het oorspronkelijke protocol vertrouwde op UDP.
Nu kan dit afleverproblemen veroorzaken met overbelaste
netwerken omdat UDP een fire and forget protocol is.
Het verzendt het en wacht niet op
antwoord en bevestiging.
En dus gaat het er gewoon van uit dat het er is gekomen.
Als je een overbelast netwerk
hebt, kan het zijn dat gegevens wegvallen,
waardoor je informatie niet op de logserver terechtkomt
en niet wordt gelogd.
Vroeger was dit misschien oké, omdat mensen ervan
uitgingen dat iedereen in je
netwerk te vertrouwen was, maar tegenwoordig
willen we dat niet meer.
We willen er zeker van zijn dat onze gegevens daar terechtkomen.
We moeten hier dus een oplossing voor bedenken.
Het tweede punt is dat er niet veel basisbeveiligingscontroles
zijn.
Er was niets zoals encryptie of authenticatie
standaard inbegrepen bij syslog.
En dit was weer een nadeel.
Dus in moderne implementaties van syslog hebben
we deze dingen gecorrigeerd.
Vanwege deze beveiligingsproblemen
hebben onze nieuwere syslog implementaties veel verschillende
functies en mogelijkheden toegevoegd.
En we gaan er hier een paar bespreken.
Eerst gebruiken nieuwere implementaties TCP voor
consistente aflevering.
Op deze manier, als het netwerk overbelast raakt
en dat bericht niet aankomt,
zal het het steeds opnieuw afleveren
omdat het TCP gebruikt.
De tweede verbetering, nieuwere implementaties,
kunnen TLS, of transport layer security, gebruiken om je berichten
die naar servers worden gestuurd te versleutelen.
Op die manier kunnen gegevens die onderweg zijn niet
worden gelezen door iemand anders op het netwerk.
Het kan alleen worden gelezen door het eindpunt dat het
heeft verzonden en de server die het ontvangt.
Het derde punt
is dat nieuwere implementaties ook MD5 en SHA1 gebruiken
voor authenticatie en integriteit.
Op deze manier kunnen de berichten berichtauthenticatie en -integriteit
hebben terwijl ze door je netwerk gaan om er zeker van
te zijn dat er niemand anders mee kan knoeien.
Nogmaals, veel andere functies.
Ik concentreer me echter niet te veel op deze set, want
de drie belangrijkste waar we ons zorgen over maken is dat
we zijn overgestapt op TCP voor een consistente levering.
We zijn overgestapt op TLS voor encryptie
en we gebruiken MD5 en SHA1 voor authenticatie
en integriteit.
Nu wordt deze nieuwere versie van
de server meestal syslog-ng genoemd, voor syslog next generation,
of rsyslog.
Het laatste wat ik wil zeggen over syslog
is dat syslog vaak gebruikt wordt om drie dingen te betekenen.
Het kan verwijzen naar het protocol waar we de gegevens over verzenden.
Het kan verwijzen naar de server, zoals in een syslogserver, of
het kan verwijzen naar de logboekvermeldingen
zelf, zoals in sysloggegevens.
Mensen zeggen vaak gewoon syslog en
bedoelen dan alle drie, of een van deze drie, afhankelijk
van de context.
Dus wees voorzichtig als
je mensen hoort praten in de industrie
om er zeker van te zijn dat
je begrijpt over welke van de drie ze het hebben,
SNMP is onze volgende.
SNMP is het Simple Network Management Protocol.
Het is een TCP-protocol dat helpt bij het monitoren
van netwerkapparaten en computers.
SNMP is opgenomen in netwerkbeheer- en bewakingssystemen
en wordt veel gebruikt in het concept van beheer
en bewaking.
SNMP is onderverdeeld in drie componenten.
Er zijn de beheerde apparaten, de agent
en de netwerkbeheersystemen zelf.
We praten over beheerde apparaten.
Dit zijn computers en andere netwerkapparaten die
gemonitord worden met behulp van agents
door een netwerkbeheersysteem.
Agents zijn software die op een beheerd apparaat wordt geladen.
Hierdoor kunnen we informatie doorsturen
naar het netwerkbeheersysteem dat
de monitoring uitvoert.
En een netwerkbeheersysteem, of NMS,
is de software die op een of meer servers draait
en die de bewaking
van alle netwerkapparaten en -computers in het
netwerk regelt.
SNMP is de lijm die ervoor zorgt dat alle
drie met elkaar praten via dat SNMP-protocol.
Hoe ziet dit er allemaal uit binnen het netwerk?
Hier op het scherm zie je een kort diagram.
Links hebben we ons netwerkbeheerstation, of onze
NMS, dat deel uitmaakt van ons netwerkbeheersysteem.
Dit gaat fungeren als onze manager
en het gaat berichten sturen en ontvangen
naar alle beheerde apparaten in het netwerk, je
routers, je switches en je servers, toch?
Nu, wanneer het informatie
wil, stuurt het een get verzoek,
en dan sturen die apparaten informatie terug door middel
van een set verzoek.
Nu is er ook nog zoiets als een trap verzoek, dat ongevraagd
informatie gaat ontvangen van die beheerapparaten,
waarbij ze gewoon informatie sturen
als dat nodig is met periodieke tussenpozen.
Dus wanneer je al dit netwerkbeheer uitvoert met SNMP, heb je twee opties
waar de gegevens naartoe gestuurd kunnen worden.
Je kunt het versturen via het netwerk dat je gebruikt,
wat bekend staat als in-band communicatie,
of je kunt het out-of-band versturen.
Wanneer je nu in-band doet,
betekent dit dat je deze managementgegevens
over hetzelfde netwerk stuurt dat je bedrijfsinformatie
en normale gegevens vervoert.
Dit is goedkoper en gemakkelijker, maar het is minder veilig.
Om veiliger te zijn, zou
je nu een out-of-band netwerk moeten creëren.
Dit is een secundair netwerk waar al het
beheer plaatsvindt, maar je hebt nog
steeds dat primaire in-band netwerk waar alle
gegevens die de gebruikers gaan krijgen plaatsvinden.
Beheer moet altijd worden uitgevoerd
op een out-of-band netwerk omdat het de veiligheid verhoogt
en de beheerfunctie weghaalt van de plaats waar gebruikers
het kunnen aanraken of zien.