Een externe firewall deel 5
DNS blocklists revisited
Allereerst: Ik heb in deel 3 een foutje gemaakt door te zeggen dat de DNSBL feeds werken door rules met IP adres blokkering aan te maken. Dat was helaas niet correct. Ik heb twee dingen door elkaar gehaald, die ik niet had mogen samenvoegen.
pfBlockerNG, met Ip menu en DNSBL submenuBlokkering op IP adressenPfBlockerNG heeft aparte ‘aliases’ met Ipv4 en Ipv6 adressen die je zou kunnen willen blokkeren.
Alises met Ipv4 blocklist, onderverdeeld naar risicoZe worden ‘aliases’ genoemd, omdat het lijsten zijn voor hetzelfde doel, namelijk gebruik in een rule. Het verschil is alleen dat voor deze aliases worden automatisch rules aangemaakt. Ik heb vier aliases aangemaakt, gebaseerd op het risico dat de IP adressen vormen. De lijst met IP adressen die het grootste risico vormen, kun je dan ook het vaakst updaten.
Ik zal level 1 er even uitpakken om te zien wat er in zit:
Top level ipv4: drie verschillende lijsten met IP adressenAlias “Level 1” heeft drie lijsten die automatisch worden gedownload. Elke lijst bevat een aantal IP adressen. Automatisch aangemaakte rules zorgen ervoor dat al het verkeer van en naar die IP adressen geblokkeerd wordt. Bij overtredingen wordt de Header in de logging getoont.
Hostname blokkeringDNSBL heeft als onderdeel van pfBlockerNG de DNSBL easylist, en de DNSBL feeds.
De easlylist heb ik al even behandeld; twee grote lijsten die continue worden bijgewerkt.
De DNSBL feeds zijn lijsten die door andere mensen worden bijgehouden, maar die lijsten bevatten hostnamen die geblokkeerd kunnen worden, en werken dus net als de easylist door geen IP adres bij de hostname te zoeken. Ik heb drie groepen, die op verschillende tijden worden geüpdate.
Groepen met DNSBL feeds
DNSBL feed met zero day domainsAls voorbeeld pak ik weer de Zero day threats. Domeinen die soms maar een dag bestaan, en vaak voor malware of spam worden gebruikt. Deze groep bevat slechts één lijst. De lijst bevat hostnamen waar je weg wilt blijven. Samen met de easylist worden ze door de DNS server gebruikt om host namen niet om te zetten naar IP adressen.
Ik hoop dat het nog een beetje duidelijk is. pfSense heeft meerdere mogelijkheden
Ik heb nog een eigenschap ontdekt in de DNS blocklists waar ik zo nog geen oplossing voor weet, maar die wel vervelend is. Als abcdef.com in een blocklist staat, wordt dat domein niet omgezet naar zijn IP adres. Echter, www.abcdef.com wordt nog steeds omgezet. Er is vaker melding van gemaakt in het pfSense forum, maar ik heb nog geen echte oplossing gezien. Men is bang om automatisch alle subdomeinen te blokkeren. Het heeft volgens mij wel de aandacht van de ontwikkelaars.
Dan ga ik nu verder met het onderwerp dat ik gepland had voor dit deel
Intrusion detection met snort
Snort is een intrusion detectie en preventie systeem. Het kan worden geconfigureerd van simpel loggen, tot automatisch blokkeren. Het kan dus werken als beveiliging. Bij intrusion moet je niet meteen denken aan iemand die je computer binnendringt, en dingen doet alsof hij achter je toetsenbord zit. Ook een poort-scan, buffer overflow of het versturen van verminkte pakketten kan al vervelende gevolgen hebben. Een browser kan er bijvoorbeeld niet op berekend zijn, met als gevolg dat hij vastloopt, of dan men kans ziet lokaal op je PC of smartphone code uit te voeren.
Snort kan helpen dit te voorkomen door op te treden als een packet sniffer, die dankzij definities probeert ongewenst netwerk verkeer te detecteren en voorkomen. Het is enigszins vergelijkbaar met de manier waarop antivirusprogramma's werken.
Je kunt deze definities zelf schrijven, maar er zijn al een hele hoop door anderen geschreven en ter beschikking gesteld.
De definities zijn er in diverse catagorieen, bijvoorbeeld
- Low-level protocollen (icmp, netbios, tcp, udp)
- High-level protocollen (http, ftp, dns, pop3, imap)
- Exploits (uitvoerbare code, backdoor, exploit)
- Beïnvloeding (dos, ddos)
- Scannen en andere onderzoeksmethodes (scan, bewust verminkte communicatie)
- Virussen en andere malware (virus)
Ze worden meestal gebundeld ter download aangeboden.
Om in snort gebruik te kunnen maken van die gedownloade definities heb je allereerst een oinkmaster Code hebben (ja ze verzinnen leuke namen). Je kunt een gratis code krijgen, alleen dan zijn alle definities tenminste 30 dagen oud. Alternatief is een betaald account.
Selectie van downloadbare rulesEr zijn nog twee groepen rules die je kan kiezen, de Community rules, en een Emerging Threads (ET) rules. Je hoeft het alleen aan te vinken. Bij die laatste heb je weer een gratis versie en een uitgebreidere betaalde versie. Je kunt aangeven hoe vaak ze moeten worden geüpdate.
Snort rules download overzichtNu hebben we lijsten waarmee snort intruders kan detecteren. We moeten ze alleen nog aan de WAN interface toevoegen. Eigenlijk stelt dit niet veel voor. De default settings zijn goed om mee te beginnen.
Enable snort op de WAN interface, en kies een log priorityWel belangrijk is de log policy. Snort zal namelijk allerlei zaken tegenkomen die niet helemaal netjes zijn, maar waar best mee te leven is. De prioriteit werkt als een soort niveau. Staat het te laag, dan lopen de logbestanden al snel vol. Standaard staat het op LOG_ALERT. Dan wordt je al gewaarschuwd als een HTML pagina geen lengte heeft meegekregen in het http protocol.
Minstens zo belangrijk is de regel Block Offenders. Als deze is aangevinkt, dan worden overtreders automatisch geblokkeerd, en is verdere communicatie voor hun niet mogelijk.
Vervolgens kun je uit de lijsten de categorieën selecteren waartegen je beschermd wil worden.
Selectie van categorieënHet lijkt aantrekkelijk om alles te selecteren, maar dat kan pfSense vertragen.
Nadat ik snort had geïnstalleerd, heb ik eens in het snort alert log gekeken. Ik was van mening dat die eigenlijk bijna leeg zou zijn. Tot mijn verbazing was hij al redelijk gevuld:

Alleen is het nog niet zo gevaarlijk
- Regels 1 & 2: Ik heb een .exe gedownload. Als ik had gewild, had ik het kunnen blokkeren.
- Regels 3 & 4: Communicatie problemen. Op een HELLO, wordt ook met een HELLO geantwoord, in plaats van een ACK. Niet erg, maar dit soort technieken liggen wel aan de basis van sommige hack pogingen.
- Regel 5; Unicode encoding; hiermee kun je buitenlandse characters gebruiken die sprekend lijken op de westerse characters. Als je naar de url in de browser kijkt zie je het niet, en ook het slotje op de https verbinding is groen. Zie bijvoorbeeld een melding op tweakers dat Chrome onderscheid gaat maken.
- Regels 6 & 7: Double decoding attack. Klinkt al erger. Het kan een poging zijn om browsers of servers om te tuin te leiden. Je krijgt dit bijvoorbeeld bij: http://www.somesite.com/index.php/Sp%25C3%25A9cial/page.
%25 is karakter hexadecimaal 25. Iedereen heeft wel eens %20 gezien, als er een spatie in een URL voorkomt. %25 is weer een % teken, dus %25C3 levert na 'decodering' weer %C3 op. Dubbel gecodeerd dus. Het kan gebruikt worden om de werkelijke opgevraagde tekst te verhullen.
Snort schijnt nogal gevoelig te zijn en levert regelmatig ‘false positives’. Vooral documenten met speciale characters, spaties en andere tekens die eigenlijk niet in een URL thuishoren kunnen ervoor zorgen dat snort het als verdacht aanmerkt.
In de snort log lijst komen trouwens veel IP adressen van 192.168.178.x voor. Dit komt omdat al het verkeer nog eens via de NAT van het modem moet. Mijn modem staat nog niet in bridge mode. Maar ik had een reden om dit nog even zo te laten.
Ik heb de port scan alert aangezet. Als iemand een port scan doet om te kijken of er poorten open staan, moet ik een alert krijgen. Als mijn modem in bridge mode had gestaan, had ik een webdienst als ShieldsUp van grc.com kunnen gebruiken. Hij staat nog niet in bridge mode, want ik wil zelf een scan kunnen uitvoeren. In de standaard mode werken alle vier poorten op mijn modem. Ik kan dus op een van de andere poorten een laptop aansluiten, en een scan uitvoeren met nmap, een portscan programma dat standaard in linux zit.
nmap scan op de WAN zijde van pfSenseStandaard probeert nmap eerst een ping, om te zien of de andere kant online is. Op een ping reageert pfSense helemaal niet. Ik kan die test negeren met de optie –Pn, waarna hij 1000 van de meest gebruikte poorten gaat scannen. Ze zijn allemaal ‘filtered’, wat betekent dat nmap helemaal niet kan vertellen of er naar de poort gekeken wordt, stealth dus.
De poging blijft echter niet onopgemerkt:

Een port scan vanaf 192.168.178.164 valt op. Ik heb geen poorten geforward dus ik log alleen een alert. Als ik wel poorten zou forwarden voor bijvoorbeeld een IP camera, of een NAS, dan kan ik pfSense de opdracht geven om het IP adres helemaal te blokkeren gedurende een bepaalde tijd (de 'Block offenders' een stukje verder naar boven). Al mijn poorten, inclusief de IP cam, zijn dan geblokkeerd voor dat IP adres. Door de camera op een wat hogere poort te zetten (b.v. 4321) kan ik er meteen bij, maar iemand die gaat scannen vindt hem niet omdat hij geblokkeerd wordt.
BarnyardAls je met snort bezig gaat krijg je ook te maken met barnyard. Snort is nooit bedoeld geweest om de tcp/ip pakketten helemaal te decoderen. Het schrijft de data weg als een simpele regel, en niet in een soort database waarin eenvoudiger is te zoeken. Daar was op een gegeven moment wel belangstelling voor, maar men durfde het niet aan om zowel het luisteren naar de communicatie als het verder analyseren en opslaan in een database door hetzelfde programma te laten doen. Als het tweede deel tijdelijk meer tijd in beslag zou nemen, zou het afvangen van de data onder druk komen te staan. Daarom heeft men besloten om dat in een apart programma te doen: Barnyard. Snort levert nog steeds 'platte tekst', en barnyard zorgt ervoor dat het keurig in een database komt. Als Barnyard wat meer tijd nodig heeft, is dit niet van invloed op de capaciteiten van snort. Die kan gewoon doorgaan met het capturen van data.
Omdat het in een database komt, kunnen we ook mooi filteren op de snort events
De logging is te filteren op diverse gegevensBarnyard wordt automatisch mee geïnstalleerd. We hoeven alleen aan te geven dat we het willen gebruiken en hoeveel harde schijf ruimte we het willen geven.
Wat te doen bij detectieAls snort iets detecteert wat echt verdacht is kun je eerst eens kijken wat de bron is. Probeert men mij van buiten aan te vallen, of heb ik malware of een virus binnengehaald die naar buiten toe communiceert. Port scans kun je verwachten, zeker als het modem in bridge mode draait. Ook zal je meerdere simpele DOS attacks zien, of een poging een bepaald type modem te kraken.
Het kan ook een vals alarm zijn. Snort moet proberen onderscheid te maken tussen echte kwaadaardige communicatie, en dingen die er veel op lijken, maar gewoon de titel van een document is. Zonder snort zou het waarschijnlijk helemaal niet zijn opgemerkt. Het kan handig zijn om alle apparatuur op het eigen netwerk een vast IP adres te geven. Op die manier is in een keer te zien welk apparaat het verdachte gedrag vertoont. Als je aanvinkt dat de host naam in de ARP lijst moet komen, kan snort de naam ook bij het ip adres zoeken.
Bovenste: voeg alle DHCP leases toe, onderste: voeg de static adressen toeKijk in de logging ook eens naar het bestemmings IP adres. Door op de + te clicken, zal pfSense proberen het IP adres om te zetten in een naam. Je kunt overigens ook prima googelen op een IP adres, dan zie je soms het bedrijf er achter zoals Google of Microsoft. In veel gevallen zijn het doodnormale software updates. Ik heb wel eens gehad dat ik zag dat mijn PC veel verkeer genereerde, terwijl ik niets deed. Toen ik de netwerkstekker er uit trok kwam er een pop-up dat de update gefaald was
🙂De meeste software updates zullen geen sporen achterlaten in pfSense. Een enkele keer communiceert er opeens iets met China, terwijl je geen Chinese hardware hebt. Er zijn wel drivers die af en toe een berichtje naar de fabrikant sturen. Niet kwaadaardig, maar uit privacy oogpunt blokkeer ik het toch liever.
Als je pech hebt, heb je echt een stukje malware binnengehaald, dan wel een nuttig programma dat op de achtergrond andere dingen doet. Dan moet je zien te achterhalen welk programma dat is. Je weet in ieder geval welk apparaat het is (je PC of je smartphone). Soms helpt het dan om de virusscanner eens uitgebreid te laten scannen.
Ik wil nog eens kijken of ik bepaalde meldingen van pfBlocker of snort kan onderdrukken, zonder de rule helemaal uit te schakelen.
Ik ben ook nog van plan te kijken naar squid, waarmee nog meer netwerk filtering kan worden gedaan. Squid werkt als een proxy, zodat al het internet verkeer via squid moet. Op die manier kan er al worden gefilterd voordat de data wordt doorgelaten. Als ik lees op diverse fora kan het echter zijn dat squid daarvoor veel harde schijf ruimte gaat innemen. De data wordt namelijk even bewaard voor het geval er een tweede verzoek komt om dezelfde data. Ik wil voorkomen dat squid mijn SSD 100% gaat gebruiken. Dat is niet goed voor de levensduur van een SSD.
Ik heb de komende tijd wat minder vrije tijd, en wil ook nog het www probleem in DNSBL blocklists onderzoeken, dus waarschijnlijk wordt squid even op de lange baan geschoven. Als er iemand is die er al wel ervaring mee heeft en bereid is een stukje te schrijven: be my guest.