Server-update en security: monitoringtools
Beschikbaarheid en beveiliging van servers: monitoringtools optimaal gebruiken
Hackers maken vaak van ping en traceroute gebruik om servers op het internet op te sporen. Veel systeembeheerders komen hierdoor in de verleiding om het ping- en tracerouteverkeer te blokkeren met de firewall in hun netwerk. Daarmee bemoeilijken ze echter hun werk. Bovendien heeft het weinig zin: er zijn nog talloze andere manieren om servers op te sporen.
De commandlinetools ping en traceroute, die deel uitmaken van elk modern pcbesturingssysteem, zijn populaire hulpmiddelen bij zowel hackers als systeembeheerders. Ze kunnen via scripts gemakkelijk worden geautomatiseerd en geven daarmee snel en eenvoudig antwoord op de vraag of op een bepaald IPadres al dan niet een server draait. Zo ja, dan zijn systeembeheerders tevreden. Maar voor hackers begint de pret dan pas: ze zullen de server gaan testen en proberen hem over te nemen. Dit laatste willen systeembeheerders uiteraard voor komen, en sommige denken dat te kunnen doen door een totale blokkade in te stellen. Ze maken daarbij gebruik van firewallregels om al het ping en tracerouteverkeer van en naar de server te blokkeren. Dit zijn echter lapmiddelen. Ze stellen de systeembeheerder gerust zonder de veiligheid te verhogen, terwijl de monitoring van de server wordt belemmerd. Publieke servers zijn immers ook zonder ping eenvoudig te identificeren.
Voor dat doel bestaat een handvol universele en speciale tools, waarvan we de concepten en de functies uitvoerig
zullen behandelen. We beginnen met ping en traceroute omdat de basisconcepten daarvan het eenvoudigst zijn uit te leggen. Vervolgens passeren monitoringtools op applicatieniveau de revue, waarvoor met enige knowhow ook traceroute kan worden gebruikt. Alle extra tools zijn te vinden via de link op het eind van dit artikel.
Basisprincipes ping en traceroute
Het pingcommando is een eenvoudig hulpmiddel om de netwerkverbinding met een apparaat te testen. Het verzoek van de afzender (echo request) en het antwoord van de ontvanger (echo reply) zijn gedefinieerd in protocolspecificatie RFC 792 (Internet Control Message Protocol, ICMP). Als de afzender van het pingcommando een antwoordpakket van het doelsysteem ontvangt, betekent dit dat de netwerkverbinding met het benaderde IPadres functioneert. Ping meldt tevens de voor de heen en terugreis benodigde responstijd, ook wel latency genoemd, een eenvoudige maatstaf voor de reactiesnelheid van de server. Hoe lager de latency, des te tevredener de systeembeheerder en de gebruikers.
Op Windows en Unixsystemen is het commando gewoon ping. Daarop volgt het doeladres, bijvoorbeeld ping ct.nl. Het commando levert één regel per antwoordpakket af. Hierin worden de doorvoersnelheid in milliseconden en het aantal tussenstations op de route naar de bestemming vermeld (hops bij IPv6, TTL bij IPv4, zie kader 'Verschillen tussen IPv6 en IPv4').
Als op Windows en Linux beide internetprotocollen zijn geconfigureerd (IPv4 en IPv6, d.w.z. dual stack), verzendt het besturingssysteem de verzoeken via IPv6. Met de opties -6 en -4 kan het gebruik van één van beide protocollen worden geforceerd. Oudere Linuxversies werken standaard met IPv4; voor pings met IPv6 moet ping6 worden ingegeven.
Het Windowscommando stuurt in de standaardinstelling vier echo requests en stopt dan. Het Linuxcommando stuurt onafgebroken requests tot deze met behulp van Ctrl+C worden gestaakt. Als alternatief kan het aantal met de optie -c worden begrensd (bijv. ping -c3 voor drie pings).
Als er op een ping geen reactie komt, is niet direct duidelijk wat daarvan de reden is. Misschien antwoordt de host niet, maar het is ook mogelijk dat een firewall op het pad naar de bestemming het ICMPverzoek niet doorlaat. Dit kan nader worden onderzocht met de tool traceroute. Traceroute maakt gebruik van de IPparameter hop limit (voor IPv4 is dat Time To Live of TTL) om antwoorden van specifieke routers op te vragen die zich op het pad naar de host bevinden.
Voor Windows luidt het commando tracert, voor Linux en macOS traceroute. Hierna volgt het doeladres. Het Windowscommando gebruikt voor routeanalyse normaal gesproken ICMPpakketten van het type echo request, met andere woorden pingpakketten. Linux verstuurt UDPpakketten naar doelpoorten vanaf 33434. Als je de optie –I kiest, wordt in Linux omgeschakeld naar het verzenden van ICMPecho requests. Dit vereist rootprivileges.
De hop limit is tegelijkertijd als beveiliging en waarschuwingsmechanisme bedoeld. Als een systeembeheerder per ongeluk een routingloop heeft geconfigureerd, zullen pakketten die in een dergelijke lus belanden eindeloos worden rondgestuurd. Daarom worden IPpakketten meestal met een hop limit van bijvoorbeeld 64 of 128 verzonden, en elke router die een pakket ontvangt moet deze limiet met 1 verlagen alvorens het door te sturen. Als de hop limit de waarde 0 heeft bereikt, mag het pakket niet verder worden gestuurd en moet de router het verwijderen. Tegelijkertijd zal aan de afzender van het pakket een ICMPmelding worden verzonden met de tekst: 'Time Exceeded/Hop Limit exceeded'. Een systeembeheerder kan aan de hand van deze foutmelding de oorzaak achterhalen.
Traceroute maakt van de hop limit gebruik om een respons af te dwingen van routers op de route naar de bestemming, die een IPpakket gewoonlijk stilzwijgend doorgeven. Daartoe stuurt het commando meerdere IPpakketten naar het doelsysteem. Er wordt gestart met een hop limit van 1, waarna de waarde stapsgewijs met 1 wordt verhoogd. De eerste router,
die het pakket met hop limit 1 ontvangt, zal de hop limit verlagen naar 0, moet vervolgens het pakket verwijderen en stuurt de afzender de foutmelding 'Time Exceeded'. Hierin is ook het IPadres van de eerste router verwerkt. Dit adres – of de DNSnaam, die traceroute met behulp van reverse lookup zal proberen te vinden – wordt inclusief de latency weergegeven in een regel in de terminal.
Met het tweede pakket (hop limit 2) wordt de tweede router genoodzaakt een foutmelding te verzenden. Dit gaat zo verder tot de bestemming is bereikt. Per hop limit verstuurt traceroute doorgaans drie pakketten.
In het voorbeeld 'Traceroute in Wireshark' wordt in de netwerkmonitor het resultaat weergegeven van een routeanalyse (IPv6) naar ct.nl. Er worden UDPpakketten verzonden naar poort 33434 (grijze achtergrond). Eronder staan de ontvangen pakketten (zwarte achtergrond). Bron en bestemming (source, destination) van de traceroutepakketten zijn gelijk, alleen de hop limit wordt om de drie pakketten met de waarde 1 verhoogd. De antwoorden komen via ICMPv6 en zijn van het type 'hop limit exceeded in transit'. Het voorbeeld toont drie van elk van deze berichten van de eerste drie routers langs het pad.
Voor de goede orde: ook de door de router verzonden ICMPv6pakketten hebben een hop limit. Voor de eerste en de derde router is de waarde 64 ingesteld, voor de tweede 255. De output laat voor de tweede en derde router lagere waarden (254 en 62) zien omdat de hop limit van de pakketten onderweg is verlaagd.
Als traceroute binnen 5 seconden geen antwoord van een router langs het pad ontvangt, wordt deze router gemarkeerd met een asterisk (*). Deze tijdsduur kan worden aangepast met behulp van de optie –w. Als een router geen foutmelding terugstuurt kan dat drie redenen hebben: de systeembeheerder heeft deze functie uitgeschakeld, het routermanagement is overbelast of de betreffende pakketten worden geblokkeerd door een firewall.
Applicatieping
In plaats van alleen de IPverbinding met een server te testen (laag 3 in het OSImodel), kan ook het functioneren van de server met eenvoudige commando's worden getest. Dit laatste komt overeen met pingen op applicatieniveau (laag 7 in het OSImodel). In dit geval verstuurt een commando verzoeken om daadwerkelijke functies uit te voeren, bijvoorbeeld HTTP of SMTP. Omdat de commando's via scripts kunnen worden geautomatiseerd, kan continu worden gecontroleerd of een webserver draait, zonder in een browser steeds weer de F5toets in te drukken of te klikken op de knop Pagina vernieuwen.
De meeste laag7functies maken gebruik van TCP of UDP. Ook de tools werken met TCP of UDP. Omdat UDP verbindingsloos werkt, kan voor de test één UDPpakket al volstaan. Voor TCP is de gebruikelijke drievoudige handshake 'SYN, SYNACK, ACK' vereist.
Voor het testen van webservers is de tool httping gebruikelijk. Deze stuurt onafgebroken HTTPrequests naar de doelserver. Als geen opties zijn aangegeven, wordt alleen de header van de rootdirectory '/' (HEAD) benaderd.
Het commando is opgenomen in verschillende Linuxdistributies, waaronder Ubuntu. Vaak zijn de daarin opgenomen versies echter verouderd. Wij raden je daarom aan om de actuele versie van de software handmatig te installeren (momenteel is dat versie 2.6):
sudo apt-get install : .libncursesw5-dev libssl-dev : .libfftw3-dev gettext
git clone https://github.com/flok99/ .httping.git cd httping/ make sudo install
Macgebruikers kunnen httping vinden via de optionele pakketmanagers MacPorts en Homebrew. Windowsversies kunnen worden gedownload van de site van de ontwikkelaar.
In het voorbeeld 'Webservertest' is te zien hoe httping de webserver ct.nl inspecteert. De output toont onder andere de latency en de actuele statuscode van de server (in dit geval de gunstigste waarde: '200 OK'). De tool bouwt per regel een volledige TCPverbinding op, waarna een HTTPHEADrequest volgt. De antwoorden geven aan dat de internetverbinding en de webserver functioneren.
Om toegang te krijgen tot websites met een TLSbeveiliging begin je het doeladres met https://, bijvoorbeeld htt-
ping https://ct.nl. Met de opties s -Y is het mogelijk om de HTTPstatuscode een kleur te geven.
De tool is op alle gangbare HTTPopties berekend, is tevens geschikt voor HTTP en HTTPSverkeer via een proxy en kan bovendien de HTTPauthenticatie controleren.
Bij een TLSverbinding naar een webserver (zie HTTPStest) worden 25 pakketten via het internet verstuurd. Er wordt gestart met een volledige TCPhandshake (fase 1, grijs gemarkeerd in Wireshark), waarna de TLSonderhandeling plaatsvindt (fase 2). Dan volgt het HTTPrequest (fase 3). Tenslotte rondt de tool de TCPsessie op de correcte wijze af (fase 4). Desondanks neemt het complete proces in Nederland niet langer dan 100 ms in beslag.
DNS-servercontroles
Met de in Python geschreven tool dnsping kunnen de bereikbaarheid en de belangrijkste functies van DNSservers met behulp van een DNSquery worden gecontroleerd. Standaard vraagt dnsping bij de eerste geconfigureerde resolver een Arecord op voor de gespecificeerde host. In de output geeft de tool de latencies weer. Voor de queries wordt DNSconform gebruikgemaakt van UDP, zodat voor zowel de heen als de terugweg één pakket voldoende is.
Dnsping maakt deel uit van 'DNS Diagnostics and Performance Measurement Tools', oftewel DNSDiag. Voor Windows en macOS zijn op GitHub binaries beschikbaar. De installatie op Linux gaat als volgt:
sudo apt-get install python3-pip git clone https://github.com/ .farrokhi/dnsdiag.git cd dnsdiag/ pip3 install -r requirements.txt
Voor een eenvoudige DNSping van je DNSresolver is het voldoende om een host te specificeren, bijvoorbeeld zo: ./ dnsping.py ct.nl. Je kunt bovendien het DNSantwoord opvragen (-v), het te benaderen DNSresourcerecord specificeren (-t <type>, standaard is A), de DNSserver aangeven (-s <server>) of de IPversie bepalen (-6/-4).
Het DNSprotocol kan ook gebruikmaken van TCP. Dit is nodig bij antwoorden die te groot zijn voor UDP. Om een TCPquery te versturen gebruik je de optie -T. Als het verwachte DNSantwoord binnenkomt, betekent dit dat de firewall en de DNSresolver TCPpakketten doorlaten en dus correct geconfigureerd zijn.
Als je in je netwerk een DNSresolver gebruikt, kun je met deze tool de beschikbaarheid ervan controleren en de latency bepalen. Routers voor thuisgebruik beschikken standaard over zo'n resolver. Zo controleer je of hij werkt:
./dnsping.py -s 192.168.xxx.xxx ct.nl.
Hierbij geeft de parameter -s 192.168. xxx.xxx het IPadres aan van de router. Bij Ziggo's Connectbox is dit bijvoorbeeld 192.168.178.1 of bij KPN's Experia Box 192.168.2.254.
Op dezelfde wijze test je openbare DNSresolvers, bijvoorbeeld Googles PublicDNS (2001:4860:4860::8888, respectievelijk 8.8.8.8) of OpenDNS (2620:0:ccc::2, respectievelijk 208.67.222.222). Aan de hand van de antwoorden kunnen de snelheden van de DNSservers worden vergeleken. Snelle DNSservers verdienen de voorkeur omdat meer DNSverzoeken moeten worden verzonden naarmate websites groter zijn, en hoe eerder een DNSantwoord binnenkomt, des te sneller een browser het betreffende IPadres kan oproepen.
Ook via het internet toegankelijke DNSservers kunnen met dnsping worden getest. Geef als bestemming het publieke IPadres van de server op en benader een van de door die server beheerde domeinen. Voorbeeld: voor ebay.nl is de DNSserver 'a1.verisigndns.com' in gebruik.
Het is om veiligheidsredenen af te raden om je eigen DNSserver zo in te stellen dat op verzoeken voor andere domeinen wordt gereageerd, zoals bijvoorbeeld ct.nl. Je server kan dan namelijk als
publieke DNSresolver worden misbruikt. Voor het testen van de DNSSECvalidatie van resolvers vind je in dezelfde toolkit het commando dnseval. Meer informatie over tools in de DNSDiagsuite vind je op de website van de ontwikkelaar (zie link op het eind).
Mailserver testen
Om het functioneren van een SMTPserver continu te controleren kun je het commando smtpping gebruiken. De tool is te verkrijgen via GitHub en is beschikbaar voor Windows, macOS en Linux. Smtpping verstuurt net als een emailclient complete emails, maar levert aanvullende statusinformatie.
Als je deze tool in een script gebruikt, kies dan niet voor korte testintervallen, want SMTPservers kunnen dat als spamgolf zien. Daarna blokkeren SMTPservers ontvangen mail van dergelijke in het oog lopende IPadressen (grijze of zwarte lijst). Hieronder een voorbeeld van een SMTPtest:
./smtpping -c 4 -S foobar@test.nl johannes@webertest.net @esa.webertest.net
De parameter -c <count> bepaalt het aantal tests. Bovenstaand voorbeeld bevat er vier. Hierop volgen het adres van de afzender (-S <adres> en dat van de ontvanger. Als er geen SMTPserver wordt opgegeven met @<server>, stuurt de tool de email naar het adres dat in het MXrecord van het ontvangende domein geregistreerd staat.
Voor een succesvolle SMTPtest moet de computer die de test uitvoert over een statisch publiek IPadres beschikken. Mails die via een dynamisch publiek IPadres worden verzonden, zullen normaal gesproken niet door een SMTPserver worden geaccepteerd. Dit is een normale voorzorgsmaatregel tegen spam van door malware geïnfecteerde privécomputers.
Als de computer waarmee de test wordt uitgevoerd via een dynamisch publiek IPadres met het internet is verbonden, kun je SMTPrelays gebruiken als intermediair. Daarvoor voer je aan het einde van de commandoregel een @teken in, gevolgd door het IPadres van de relay (bijv. @198.51.100.10).
Smtpping vermeldt in de output ook responstijden van de SMTPserver voor elk van de zes SMTPcommunicatiefasen (connect, helo, mailfrom...). Een ongewoon lange verwerkingstijd voor een fase kan wijzen op een fout.
Traceroutespecialiteiten
Menig systeembeheerder blokkeert het pingverkeer naar publieke servers die in de DMZ staan. In de praktijk levert deze blokkade bij eenvoudige firewalls geen beveiligingsvoordelen op aangezien de server van buitenaf nog steeds eenvoudig te identificeren is.
Dit gebeurt met een Layer Four Traceroute (laag4traceroute, LFT). Het is daarvoor voldoende om een pakket naar een specifieke TCP of UDPpoort van een server te sturen. Aangezien het hierbij om gewone TCPSYNpakketten gaat, zullen eenvoudige firewalls ze laten passeren. Zo wordt dus het opbouwen van een TCPverbinding met een webserver gesimuleerd door een pakket naar poort 80 te sturen – ogenschijnlijk het begin van een browsersessie.
Dit heeft consequenties voor de veiligheid van de infrastructuur achter de internetrouter: als binnen het bedrijfsnetwerk namelijk routers op het pad naar de webserver staan, kunnen die worden geidentificeerd met behulp van pakketten waarvan de hop limit bij ontvangst 1 bedraagt. Na verlaging van de hop limit zal de afzender van het pakket normaal gesproken de foutmelding 'ICMP Time Exceeded' toegestuurd krijgen. Eenvoudige, poortgebaseerde firewalls zien geen gevaar in het terugsturen van een ICMPpakket naar de bron en laten het passeren. Zo druppelt informatie over het routingpad binnen de DMZ van het bedrijfsnetwerk naar buiten.
Om dit soort speciale traceroutes te starten zijn in Linux rootprivileges vereist. Met de optie -T schakel je TCP in, en voor UDP gebruik je -U. Een webserver wordt met TCP benaderd via poort 80 of 443 (-p
<poort>), een DNSserver met UDP op poort 53. Zo test je de HTTPSservice van ct.nl via IPv6:
sudo traceroute -6 -T -p 443 www.ct.nl
Stel dat je het routingpad naar een SMTPserver wilt detecteren. Je stuurt dan een LFT naar TCPpoort 25 van de server en laat je verrassen door de verschillen met een gewone traceroute.
DNS en man-in-the-middle
Een bijzonderheid in verband met traceroute betreft de DNSservice. Als DNSverzoeken en antwoorden zoals gebruikelijk via UDP worden verzonden, vindt geen laag4handshake plaats. Daarom is voor een DNSverzoek maar één UDPpakket nodig.
Dienovereenkomstig kan een router, een firewall of een inbraakpreventiesysteem niet alleen het UDPprotocol met bestemmingspoort 53, maar ook het DNSverzoek lezen, alsmede ongewenste verzoeken blokkeren. DNSantwoorden kunnen bovendien gericht worden vervalst om de afzender bijvoorbeeld naar een overheidswebsite met een waarschuwing door te sturen.
Dergelijke manipulaties kunnen met behulp van speciale traceroutes aan het licht worden gebracht door het versturen van DNSverzoeken en het per hoplimitverhoging bekijken hoe die worden afgehandeld. Behalve het routingpad naar de DNSresolver kunnen daarmee ook maninthemiddleaanvallen c.q. DNSspoofing worden onthuld.
Manipulaties zijn herkenbaar aan het feit dat het DNSantwoord niet van de eigenlijke DNSresolver afkomstig is, maar van een normaal gesproken transparant infrastructuurelement dat zich op het pad vóór de resolver bevindt.
Dit soort DNSspoofing kan echter ook wenselijk zijn. Zo bieden moderne firewalls en DNSapparatuur een functie genaamd 'DNS Sinkholing' waarbij DNSverzoeken aan malwaredomeinen met een dummyIPadres worden beantwoord om de gebruiker te beschermen.
Voor dergelijke speciale analyses bevat DNSDiag de tool dnstraceroute. Op Linux en Windows zijn voor de uitvoering hiervan rootprivileges vereist. Test eerst met je gebruikelijke DNSresolver hoe bekende domeinen dit afhandelen:
sudo ./dnstraceroute.py ct.nl Net als bij dnsping kun je de te benaderen DNSserver ingeven met de optie -s <server>. Met de optie -t <type> kies je welk resourcerecord de DNSserver moet leveren (A = IPv4adres, AAAA = IPv6adres, MX = domein van de mailserver).
Basisaanbevelingen firewall
Een totale pingblokkade voor het interne netwerk is vanuit veiligheidsoogpunt onnodig en soms zelfs schadelijk. Het pingcommando is erg belangrijk voor systeembeheerders die de beschikbaarheid van hun diensten willen waarborgen. Toegang tot een DMZ via het internet is normaal gesproken gewenst, zij het dat hiervoor uitsluitend de daadwerkelijk benodigde poorten dienen te worden gebruikt. Een laag7ping staat sowieso niets in de weg, en ook laag4traceroutes zullen worden beantwoord, mits geen andere acties worden ondernomen.
De veiligheid van een bedrijfsnetwerk zal dan ook geen significante problemen ondervinden van ICMPpings die van buitenaf in de DMZ worden toegelaten. Als je webserver op algemene HTTPen HTTPSverzoeken vanaf het internet reageert, is hij hoe dan ook bekend, en een ICMPping levert aanvallers geen nieuwe informatie op. Het tegenovergestelde is echter het geval als je server niet via standaardpoorten toegankelijk is, maar via speciale, die alleen bepaalde gebruikers kennen. Alleen in dat geval zou je ICMPpings moeten blokkeren, omdat een verborgen server dan door middel van automatische zoekopdrachten sneller kan worden geïdentificeerd.
Toegang tot het LAN via internet is hoe dan ook taboe, of het nu om ICMPpings of ander verkeer gaat. Maar dat heeft je systeembeheerder hopelijk standaard zo geconfigureerd.
Naast de klassieke poortgebaseerde firewalls zijn er de 'next generation firewalls'. Hiermee kunnen zeer gedetailleerde instellingen worden gemaakt voor de afhandeling van laag4traceroutes, die ongeacht het gebruikte protocol worden herkend. Je kunt ze zodoende eenvoudig blokkeren terwijl je HTTPS blijft toestaan. Een webbrowser zal je webserver op die manier gewoon via TCPSYN op poort 443 bereiken, maar een laag4traceroute die een TYPSYN op poort 443 simuleert wordt geblokkeerd. Zo blijven interne routingpaden van buitenaf onzichtbaar. (mdt)
www.ct.nl/softlink/1803136