» » Beveiliging: Fail2Ban

Beveiliging: Fail2Ban

Geplaatst in: Nieuws, Techniek | 0

Beveiliging: Fail2Ban

Als systeembeheerder bent u bekend met beveiliging. U heeft servers die publieke services aan het internet leveren. U controleert dagelijks de logfiles wanneer de drukte van uw werkzaamheden dit toelaten. Veelal richt deze controle zich in eerste instantie op het correct functioneren van uw services. Vandaag de dag echter wordt het controleren van beveiligingsincidenten echter steeds belangrijker.

Bij één van mijn clienten hoorde ik dat ‘IMAP en SMTP TLS dichtgezet zijn’. De systeembeheerders bij deze clienten hadden geconstateerd dat er zeer veelvuldig password checks worden uitgevoerd op deze diensten. ‘Het is dan slechts een kwestie van tijd voordat ze een wachtwoord hacken!’. Ik denk dat er betere alternatieven bestaan dan het volledige dichtzetten van veilige (eg. TLS encrypted) diensten waar hackers toch gebruik van proberen te maken. Een zeer elegant middel hiertoe is de tool fail2ban.

Firewall

3DN bedient zich exclusief van Linux servers. Op Linux servers zijn firewalls veelvuldig uitgevoerd met behulp van iptables. Iptables is een method om de Linux kernel te vertellen wat voor netwerk pakketjes vanuit de OS laag doorgegeven mogen worden aan de applicatie laag. Wanneer u de kernel met behulp van iptables bijvoorbeeld het volgende zegt:

iptables -A INPUT -i lo -j ACCEPT

vertelt u de kernel dat:

  • Alle netwerk pakketjes die op interface (-i) lo, het loopback interface, binnenkomen geaccepteerd worden en worden doorgegeven aan de applicatie laag of door de kernel zelf mogen worden afgehandeld.

Mogelijk ziet u hier al direct de complicatie ontstaan. Iptables commandos zijn vaak moeilijk leesbaar. De gemiddelde leek kan er niets mee en zelfs wat minder doorgewinterde systeembeheerders kunnen wat gecompliceerdere iptables commandos vaak moeilijk inschatten.

Er bestaan allerlei fraaie en minder fraaie applicaties die het aanmaken van gedegen firewall rules eenvoudiger maken. Zo is er bijvoorbeeld de applicatie ufw, Ubuntu Fire Wall. Met UFW word het al veel eenvoudiger en leesbaarder om firewall tables toe te voegen:

ufw allow 53/udp

Bovenstaand voorbeeld toont hoe eenvoudig UDP verkeer voor poort 53 (DNS) kan worden toegestaan. UFW, net zoals veel van de andere tools, bedient zich onderwater gewoon van iptables maar heeft slechts de commando structuur zwaar vereenvoudigd.

Statisch of Dynamisch

TPol
Space is a very large place, captain.

Nu komen we bij de kern van dit artikel. Het aanmaken van statische firewal tabellen kan eenvoudig geleerd worden en er bestaan duidelijke groeipaden voor de meer senior systeembeheerder om hun firewalls op detail te verfijnen. Echter, het internet is een erg grote en bonte verzameling van gebruikers van uw diensten.

Minder ervaren firewall beheerders zullen bij constatering van veelvuldige hackpogingen een IP-adres blokkeren. Zo ook een netwerkbeheerder bij een client uit het verleden die veel activiteit naar het internet zag op TCP poort 3127. In het verleden was op het internet vaak een policy ‘alles staat open totdat we misbruik constateren, dan zetten we het dicht’ nog erg gebruikelijk. Betreffende systeembeheerder zette daarom onmiddelijk TCP poort 3127 dicht. Dit had als gevolg dat de inmiddels geinfecteerde lokale PC’s onmiddelijk naar het internet probeerden te gaan via TCP poort 3128. Toevallig was dit tevens een well-known TCP poort voor een bekende service, namelijk de Squid cache. De Squid cache werd indertijd vaak gebruikt als lokale caching teneinde langzame internet connecties te ontzien…

Uit bovenstaande kunnen we zien dat het dichtzetten van bepaalde poorten niet altijd in het gewenste resultaat resulteert. De schrijvers van het virus uit bovenstaand voorbeeld wisten de mindset van gemiddelde firewall administrators en hadden hier dankbaar gebruik van gemaakt. Als resultaat werd de squid cache nagenoeg onbruikbaar waardoor de internet connectie van betreffend instituut zwaar overladen werd. In essentie werd er dus op een handige manier een zgn. DOS (Denial of Service) aanval uitgevoerd waarbij de geinfecteerde PC’s van het instituut zelf de DOS uitvoerden op de Squid server.

Een firewall beheerder vandaag de dag dient meer dynamisch van karakter te zijn en dient zich te realiseren dat er honderdduizenden hackers op het internet leven. Deze hackers varieren in nivo van zgn. scriptkiddies, mensen die een scriptje downloaden van het internet en daarmee ‘gaan hacken’, tot experts die zich zeer goed kunnen inleven in de mindset van beveiligers en zeer flexibel kunnen reageren op deze mindset.

Fail2Ban

Ook systeembeheerders kunnen zich echter soms goed inleven in de mindset van hackers. Het patroon zoals eerder beschreven:

U controleert dagelijks de logfiles wanneer de drukte van uw werkzaamheden dit toelaten. Veelal richt deze controle zich in eerste instantie op het correct functioneren van uw services. Vandaag de dag echter wordt het controleren van beveiligingsincidenten echter steeds belangrijker.

bevat al enkele van de gotchas van de hedendaagse systeembeheerder. Het controleren van logfiles met immer groeiende aantallen servers is altijd geestdodend werk en veelal zelfs ondoenlijk gezien management het niet toestaat. Bedrijven zijn zich ondertussen wel vaak bewust van het belang van beveiliging maar ze zijn in toenemende mate niet bereid om de gevolgen van deze erkenning ook te accepteren.

Systeembeheerders kunnen daarom tegenwoordig vaak gebruik maken van tooling die de logfiles voor hun leest. Een fraai voorbeeld hiervan is de tool logscan. Logscan aggregeert vaak repeterende berichten in allerhande logfiles tot een leesbaar geheel. Logwatch stuurt vervolgens een inzichtelijke email naar de systeembeheerder die berichten bevat als:


 sshd:
    Authentication Failures:
       root (121.18.238.125): 9 Time(s)
       root (121.18.238.28): 7 Time(s)
       root (109.254.2.69): 6 Time(s)
       root (113.122.34.208): 6 Time(s)
       root (121.18.238.106): 6 Time(s)
       root (121.18.238.119): 6 Time(s)
       root (121.18.238.123): 6 Time(s)

Bovenstaande laat zien dat vanaf een aantal IP adresssen geprobeerd is om een password van een gebruiker te raden. Wanneer een organisatie een sterk wachtwoord beleid forceert is hier eigenlijk al geen probleem. Random pogingen om het wachtwoord te raden zullen nooit het juiste wachtwoord raden.

Wanneer uw organisatie echter geen sterk wachtwoord beleid heeft zal zo’n probe doorgaan en maar doorgaan totdat uiteindelijk het wachtwoord word geraden. De vraag is echter of u bij een zwak wachtwoord beleid dient te besluiten om SSH maar dicht te zetten of dat u als organisatie eens grondig dient na te gaan of u niet eigenlijk verplicht bent om een sterk wachtwoord beleid te forceren bij uw gebruikers.

Zelfs bij een sterk wachtwoord beleid echter kan het irritant worden wanneer uw SSH dienst meer en meer bekend word, soms in gedistribueerde databases van hackers die samenwerken in teams, waardoor meer en meer IP adressen uw dienst zullen proberen te scannen. Een eenvoudige login poging resulteert in het geval van SSH tot een encryptie slag die redelijk duur is in termen van CPU cycles. Wanneer tienduizenden IP adressen dit doen per dag zult u dan ook merken dat de performance van uw server hieronder begint te lijden.

Hier is het dan uiteindelijk tijd om fail2ban in te gaan zetten.

Fail2ban kan net zoals logwatch allerlei logfiles bekijken en doet dit niet periodiek maar continu. Het aantal logfiles dat fail2ban kan monitoren is bij mijn weten nagenoeg onbegrensd, het aantal methodes waarmee deze logfiles worden bekeken is extensief te noemen.

fail2ban kan vervolgens een filter meekrijgen en een actie. Globaal is het mest voorkomend algoritme van fail2ban:

  • Open een logfile en blijf hierin kijken zolang het systeem up-and-running is.
  • Controleer of toevoegingen aan de logfile voldoen aan een zgn. reguliere expressie.
  • Indien bovenstaande reguliere expressie waar is, voer dan een actie uit. Veelvuldig is zo’n actie dan het tijdelijk toevoegen van een iptables rules.

In de volgende hoofdstukken zullen we een aantal praktijkvoorbeelden van populaire diensten toelichten nadat we eerst een korte toelichting geven op de installatie en configuratie van Fail2Ban.

Installatie

We installeren hier Fail2Ban op een Debian 9 systeem. Fail2Ban is deel van de standaard Debian repository en kan zonder enig probleem geïnstalleerd worden met behulp van het apt-get commando:

root@gamma:~# apt-get install fail2ban

Ten tijde van schrijven van dit artikel installeert dit versie 0.9.6 van Fail2Ban.

Configuratie

We configureren Fail2Ban eenvoudig door:

root@gamma:~# cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Bovenstaande dient eigenlijk altijd het eerste onderdeel van de configuratie te zijn; We copieren er de standaar configuratie mee naar onze lokale configuratie. Voor Use Case 1 editten we jail.local en passen de SSH sectie als volgt aan:

[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

Bovenstaande aanpassing ‘enabled = true’ zorgt er voor dat bij het herstarten van Fail2Ban de SSH jail aangezet word. Overig jails die in Use Case 2 en Use Case 3 benodigd zijn worden in de relevante hoofdstukken nader toegelicht.

Use Case 1: Fail2Ban om SSH te Beveiligen

SSH, of secure shell, heeft een voordeel en een nadeel. Het is een schoolvoorbeeld van een beveiligde dienst. Er is bij de beveiliging aan veel zaken gedacht. Zo is het mogelijk, en wenselijk, om root login onmogelijk te maken. Het is tevens mogelijk om inloggen met een wachtwoord volledig onmogelijk te maken en slechts inloggen mogelijk te maken wanneer men een beveiligde sleutel heeft. De goede beveiliging van SSH heeft er echter tevens voor gezorgd dat SSH vaak open word gezet naar het internet ‘omdat het toch veilig is’.

Bovenstaande heeft er echter tevens voor gezorgd dat SSH een zeer populair mikpunt is van brute-force aanvallen. Bij een brute-force aanval probeert een aanvaller om met behulp van duizenden wachtwoorden eenvoudigweg het juiste wachtwoord te raden. Vaak zit er meer intelligentie achter dan het op het eerste gezicht lijkt.

Vanwege de zeer grote aantallen brute force aanvallen is SSH verreweg het grootste mikpunt van aanvallers. 95% van alle aanvallen lijken op SSH gericht te zijn. Mede hierdoor is het beveiligen van SSH met behulp van fail2ban daarom ook erg eenvoudig, het is een van de (vele) meegeleverde filters bij fail2ban.

 

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *