GebruikersBlog: Een externe firewall deel 1
Inleiding
Ik wilde eens wat schrijven over het in gebruik nemen van een externe firewall. Dit gaat dus niet over problemen met Ziggo, of apparatuur van hun :). Misschien hebben de andere community leden er iets aan. Ik zal het in een aantal delen opsplitsen, en zal proberen wekelijks een deel hier te plaatsen. Het wordt geen installatie/configuratie handleiding, die zijn al wel op internet te vinden. Het is meer een verhaal over wat er bij komt kijken.
Eerst maar even het volgende: Wat is een firewall, en waarom zou je een externe firewall gebruiken terwijl er ook al een firewall in Windows en in het modem zit.
Een firewall is een systeem dat een netwerk afschermt van (meestal) het internet. Ongewenst verkeer wordt hierbij tegengehouden. Het doet dit gebruik te maken van een aantal regels. De regels kunnen vast zijn opgesteld, of door de gebruiker zijn gemaakt.
Modems hebben vaak ook een ingebouwde firewall, en soms heeft het security pakket op je computer er ook een. Je hebt dus al wel enige bescherming. Bovendien hebben de meeste modems/routers een NAT functie, waardoor men niet zomaar binnenkomt op het interne netwerk.
Om met het laatste te beginnen: NAT kan nuttig zijn als je maar één IPv4 adres van je provider krijgt, terwijl je meerdere computers wilt gebruiken. De DHCP in het modem of de router deelt de interne adressen uit.
Voorbeeld netwerk, het modem deelt de interne IP adressen uitVan buiten af is niet te zien welke apparatuur er in het interne netwerk hangt. Dat scheelt veel, maar qua bescherming kan het beter. NAT is nooit bedoeld geweest voor security.
En de firewall in de PC of in het modem dan? Die worden ook steeds beter. Vaak beschermen ze al tegen bepaalde aanvallen. Ze laten meestal wel alles vanaf het lokale netwerk (LAN) door naar buiten.
Een externe firewall
Goed, ik heb dus het idee opgevat om een externe firewall te gaan gebruiken. Niet omdat ik het nodig heb, maar om wat van te leren. Er zijn kant en klare firewalls te koop, maar dat was niet de weg die ik wilde gaan. Ik wilde zelf iets bouwen, goedkoper, en hopelijk leuker.
Na wat zoeken en lezen op internet, ben ik uitgekomen op pfSense als software voor de firewall, en een mini-PC zonder ventilator als hardware.
Ik heb gekozen voor een PC Engines APU2C4 bordje met een AMD processor en 4 GB RAM. Het printkaartje is ca 10 x 10 cm en heeft geen ventilator nodig. De fabrikant levert een passende behuizing en een geschikte voeding. Het geheel is overigens ook kant en klaar te koop, en is dan circa EUR 20 tot 30 duurder, maar het assembleren stelt niet veel voor.
APU printkaart in behuizing met een SSD in de daarvoor bedoelde connectorInstallatie opties
Het APU bordje kan zowel werken met een SD kaart als een SSD. Een SD kaartje is zo'n klein geheugen kaartje dat ook in uw fotocamera zit. Een SSD is eigenlijk een soort harddisk, maar dan volledig met geheugenmodules. Moderne PC's hebben vaak ook een SSD schijf.
Ik besluit om pfSense te installeren op een kleine SSD van 16 GB. 16 GB voor configuratie en logging is al vrij veel. Het APU bordje heeft een aansluiting voor een m-Sata SSD die nog in de behuizing past
Installatie pfSense
De pfSense software is te downloaden van de pfSense website. Er zijn twee installatie opties: met VGA aansluiting en met een seriële aansluiting. Dit leg ik even uit: Ik begin met een lege SSD, en ik moet installeren vanaf een CD of een USB-stick. Net als bij een gewone PC, moet ik daarbij een aantal vragen beantwoorden, en daarvoor heb ik een VGA monitor + keyboard nodig. Alternatief is dat ik een gewone PC via een seriële verbinding met de mini-PC verbind. (Kan iemand zich nog de tijd herinneren dat je de PC via een seriële lijn met het modem verbond en met 2400 baud bulletin boards bezocht?).
Ik heb gekozen voor de seriële lijn, eigenlijk omdat mijn mini PC geen echte VGA aansluiting heeft, en ik nog wel een PC met een seriële poort. Het pfSense bestand heb ik met Win32Image op een memory stick geplaatst. Win32Image is het CD-brander equivalent voor onder andere memory sticks.
Dus: Seriële lijn verbonden, Putty als serieel communicatie programma opgestart, memory stick met pfSense in de USB aansluiting van de mini PC, en aanzetten. Ik krijg als eerste een paar simpele vragen, bijvoorbeeld of ik van de memory stick wil opstarten, en of ik wil installeren op de SSD.
Na circa een minuut is alles geïnstalleerd, en moet hij opnieuw opstarten. De memory stick mag ik verwijderen. PfSense start al op, alleen kent het de omgeving waarin het moet werken nog niet. Daarvoor moet ik nog een paar dingen doen:
- Ik moet eerst de WAN (internet) netwerk kabel verbinden, en bevestigen dat WAN op deze poort zit.
- Daarna moet ik de LAN (interne netwerk) kabel verbinden en bevestigen.
- De derde netwerk aansluiting is optioneel, dus die laat ik even. Hier zal later het Wifi access point op komen (al te zien op de schermafdruk beneden)
Configuratiescherm via seriële interfaceVervolgens moet ik de IP adressen zetten:
- Aan de WAN kant kies ik voor IP via DHCP, dan krijg ik een IP adres van Ziggo.
- Aan de LAN kant heeft de pfSense firewall een eigen IP nodig, net als het modem ook een eigen IP adres heeft. Hier kun je bijvoorbeeld 192.168.1.1 invullen *). PfSense wordt ook de DHCP server voor het interne netwerk, en het is gebruikelijk dat die op x.x.x.1 zit.
*) Ik gebruik overigens 10.0.0.x voor mijn LAN, en 10.0.1.x voor de Wifi. Dat zal ik vanaf nu ook gebruiken. Als ik schrijf 10.0.x.x, en je gebruikt zelf 192.168.x.x, bedenk dan dat beide mogelijk zijn. Het maakt niets uit.
Vanaf nu mag ik afscheid nemen van mijn tekst mode terminal. De rest van de configuratie is te doen via de browser op http://10.0.0.1 (of http://192.168.1.1). Daar hadden we o.a. het IP adres voor nodig.
Het werk hierboven had ik me overigens kunnen besparen door pfSense geïnstalleerd op een reeds gemonteerde mini-PC te kopen. Ik hoop niet dat ik dus mensen die zelf bouwen niet zien zitten heb afgeschrikt. Je bent niet verplicht het zelf te bouwen.
In het volgende deel ga ik in op het gebruik van pfSense. Het heeft diverse schermen voor configuratie, status en diagnostiek. Hier zal ik iets van laten zien.
e-mail meldingen
Aan Uit
Een externe firewall deel 6.2
darkstat
De vorige keer heb ik wat verteld over ntopng, een zeer uitgebreide package voor pfSense waarmee netwerkverkeer in de gaten gehouden kan worden. Deze keer wil ik een wat eenvoudigere versie laten zien: Darkstat. Het is niet zo uitgebreid, maar geeft wel snel een overzicht.
Net als bij andere packages is het configureerbaar vanuit pfSense.
Darkstat configuratieAls eerste zijn de Capture interfaces in te stellen. Dit zijn dus de netwerk interfaces waarop darkstat luistert naar verkeer. Standaard staat het ingesteld op LAN. Ik vond dat een beetje vreemd, omdat je dan ook al het interne verkeer ziet, tenminste voor zover het aankomt bij pfSense. Voordeel is wel dat je niet alle port scans als data verkeer ziet. Het is me namelijk niet helemaal duidelijk of hij voor of na de firewall filters meet. Als je wilt kun meerdere interfaces selecteren waarop geluisterd wordt. Dat is ook wat gedaan wordt op andere darkstat configuraties (buiten pfSense) die ik vond.
Als tweede kun je selecteren op welke interfaces de web interface beschikbaar is. Normaal zijn web interfaces alleen vanaf de LAN zijde beschikbaar. Bij darkstat kun je dit selecteren. Ik heb gekozen voor alleen LAN. Toch kan ik hem benaderen vanaf mijn laptop via WLAN (Wifi). Dat komt omdat ik mijn laptop volledige toegang heb gegeven tot mijn LAN, en dus ook tot darkstat vanaf de LAN zijde. Dit soort dingen moet je wel om denken.
De rest van de opties kun je voorlopig zo laten. Het heeft er mee te maken met een “local network” optie in darkstat, waarmee wordt ingeperkt wat darkstat allemaal meet.
Darkstat zelf geeft allereerst een grafische weergave van de hoeveelheid verkeer in de afgelopen 60 seconden, 60 minuten, 24 uur en 31 dagen. Bij mij zijn ze jammer genoeg een beetje leeg, omdat ik heb gespeeld met de opties en de poorten waarop hij meet. Hierbij ben ik alle data van de afgelopen maand kwijt geraakt.
Darkstat grafische weergaveDe weergave kan statisch zijn (het moment waarop je darkstat binnenkomt), maar omdat hij real-time meet, is ook een live weergave mogelijk. Daarbij zie je de grafieken constant aangepast worden.
Als tweede heeft darkstat de mogelijkheid om de data per host te laten zien.
Darkstat overzicht per hostDit zijn dus niet alleen actieve verbindingen. De laatste kolom geeft aan wanneer er voor het laatst gecommuniceerd is. De data In/Out is in bytes. Op deze manier is snel te zien wanneer er veel data naar/van een bepaalde host gaat. Om meer informatie over een bepaalde host te krijgen kun je op het IP adres clicken.
Darkstat details Akamai host Nu worden details per poort en protocol getoond. Aan mijn kant is het poort 80, en er zijn 3 streams, ieder naar ieder een poort aan de andere host.
Dezelfde host is overigens ook terug te vinden in ntopng. De gegevens qua data komen niet helemaal overeen, maar dat komt omdat beide screenshots niet op hetzelfde moment zijn genomen.
Dezelfde Akamai host in ntopng Ik weet nu het IP adres en de poort aan mijn zijde (met Mac adres), idem aan de andere zijde, de hoeveelheid data in/out en de protocollen. Hiermee kan ik een inschatting maken of dit normaal verkeer is of niet. Daar gaat het mij om.
Als ik verdacht verkeer zie kan ik een rule aanmaken om het te blokkeren. Bepaalde landen heb ik al geblokkeerd.
Soms blokkeer je al met al ineens teveel. Dan werkt de update van een programma ineens niet meer, of het programma kan zijn licentie niet controleren. Ik zal het hier eens over hebben, zodra ik een paar goede problemen en oplossingen heb.
Ook wil ik port forwarding nog proberen, al heb ik er op dit moment zelf geen toepassing voor.
Een externe firewall deel 7.1
Als je zelf geblokkeerd wordt
Ik blokkeer in pfSense een aantal websites, gebaseerd op de URL’s en op IP adressen. Anderen hebben daarbij de lijsten samengesteld. Ook blokkeer ik hele landen, omdat van daaruit relatief veel hackpogingen worden gedaan. Soms blokkeer ik daarmee teveel. Software wil ineens niet meer updaten, of de online verificatie mislukt. In dat geval moet je overwegen of je een uitzondering wilt maken.
Het kan ook zijn dat een deel van de site niet meer werkt. Mensen die een ad-blocker in de browser hebben zullen bijvoorbeeld wel gemerkt hebben dat de filmpjes op nu.nl niet meer werken, en sommige kranten sites kom je helemaal niet meer op. Ook daar moet je voor jezelf bepalen of je een uitzondering wil maken. Wil je een advertentie site toestaan, of accepteer je dat je niet meer op de website komt.
In theorie zou je misschien de filtering kunnen verfijnen door de webpagina te analyseren en slechts bepaalde delen te blokkeren. Dit vereist wel wat rekenkracht, maar er is nog een ander probleem. Veel websites gebruiken tegenwoordig een https verbinding, waarbij de data versleuteld is vanaf de server tot aan de browser. De firewall kan niet eenvoudig meelezen. Het is in theorie mogelijk om “man in the middle” (MITM) toe te passen. Daartoe moet de firewall alle communicatie onderscheppen, en niet alleen meeluisteren. Als er encryptie sleutels worden uitgewisseld moet de MITM zijn eigen sleutels gebruiken. Voorlopig te gecompliceerd. Ik zal eerst eens een paar voorbeelden geven van problemen waar ik tegen aan ben gelopen, en die ik heb kunnen oplossen
Een Russische website
Kaspersky maakt antivirus producten. Alleen Kaspersky heeft zijn roots (en zijn servers) in Rusland. Ik heb in Geoblock heel Rusland geblokkeerd. Ook kaspersky.com is daarmee geblokkeerd.
Communicatie error met kasperasky.comDe foutmelding geeft al aan dat de server niet te bereiken is. Het is dus niet zo dat de DNS server weigert de domeinnaam om te zetten. Ik kan dit controleren in een cmd window met het ping commando. Ik krijg misschien geen antwoord van de server, maar de naam van de website wordt wel omgezet in een IP adres. Wie een cmd window te onwennig vindt, ook vanuit pfSense kun je een ping uitvoeren.
Ping vanuit pfSense: De naam wordt nog omgezet naar een IP adresHet ping commando geeft een ip adres, en dat is precies wat we nodig hebben. In dit geval wordt de website geblokkeerd, maar de ping vanaf pfSense zelf doorgelaten. Ik ga eens kijken of ik de geblokkeerde website terug kan vinden in de alerts van pfSense.
Het IP adres (93.159.228.22) is terug te vinden in de alert lijstIk kan nu een rule maken in pfSense die dit ip adres doorlaat. De eenvoudigste manier is gebruik te maken van een “easy rule”. Door op het + teken bij het IP adres te clicken, kan pfSense een zelf rule aanmaken om dit IP adres door te laten.
pfSense heeft zelf een pass rule aangemaaktHet enige probleem is dat de ‘pass’ rule onderaan staat, terwijl de ‘block’ rule bovenaan. Alle rules worden van boven naar onder afgewerkt, en zodra hij een ‘block’ rule tegenkomt die geldig is, worden de andere rules niet meer bekeken. Gelukkig heeft pfSense een eenvoudig mechanisme om een rule te verplaatsen: Selecteer de rule met de checkbox, en click op het anker icoon van de rule waar hij boven moet. Voorlopig kies ik ervoor om hem bovenaan te plaatsen.
Bij een kleine test bleek dat de website nog steeds geblokkeerd wordt. Er is dus nog meer aan de hand. Door nogmaals in de alert logging te kijken krijg ik een goede aanwijzing.
De https site wordt geblokkeerd door de pfB_Top_v4 rule, uit de Country listAls ik naar de http site ga, word ik vanzelf doorgestuurd naar de https site, die op een andere server, en een andere poort zit.
Ook is er een kans dat de antivirus updates van een andere server komen dan hun webshop. Ik ga dus een ‘alias’ aanmaken, waarin ik meerdere IP adressen kan plaatsen. Als ik even google vind ik dat kaspersky meerdere update servers heeft.
Alleen support.kaspersky.com zit weer in Rusland. We zullen het dus in stapjes moeten doen. Eerst maar eens een alias aanmaken voor meerdere IP adressen:
Alias met meerdere ip adressen van kasperskyDeze alias met IP adressen kan ik gebruiken om een rule te maken. Zoals vermeld, na kaspersky.com op 93.159.228.22 gaat de browser naar de https site ging op 185.85.15.36. Daarna werd verbinding gezocht met 185.85.15.38 (dat stapje heb ik hier maar even niet getoond) . In de screenshot is ook al een van de update sites te vinden
Omdat ik zowel http (poort 80) als https (poort 443) moet toestaan, ga ik ook een alias maken voor de poorten
Alias list voor de poorten voor websites. Met deze twee alias lijsten ga ik de easy rule aanpassen zodat die alles voor Kaspersky doorlaat
De aangepaste rule. Bij destination zijn de originele IP- en poort nummers vervangen door de alias naam Ik kan nu de google link bezoeken, en de lijst met update servers ophalen van hun website uit Rusland. De namen van deze update servers kan ik toevoegen aan mijn alias lijst met IP adressen.
Het is wat werk, maar nu is nog steeds heel Rusland geblokkeerd, met uitzondering van een paar servers.
Een video converter
Ik heb ooit een keer een videoconverter gekocht. Het programma kon sinds pfSense niet meer updaten, maar wat erger was: de licentie controle faalde, waardoor ik ineens weer de test versie had. Gelukkig controleert het programma alles tijdens het opstarten. Door de logging van pfSense gereed te houden en vervolgens het programma op te starten kan ik zien met welke ip adressen men probeert te communiceren. Tenminste, als men direct met een IP adres communiceert, en niet met een hostname.
Ik besluit eerst eens te kijken of er IP adressen gebruikt worden. Zodra het programma opstart en op updates controleert zie ik twee IP adressen voorbij komen die dicht bij elkaar liggen.
Twee verdachte IP adressen in de AlertsEen goede kans dat ze beide door het bedrijf gebruikt worden. Omdat ik twee IP adressen heb die ik moet toelaten, maak ik een alias aan met de beide IP adressen en geef het een duidelijke naam.
Alias list met de beide ip adressenNu kan ik een nieuwe rule aanmaken, die beide IP adressen toelaat. Alle rules worden van boven naar beneden geëvalueerd, dus mijn ‘allow’ moet nog voor de ‘block’ komen, anders heeft het geen zin. pfSense heeft een button om een nieuwe rule bovenaan te plaatsen.
Ik probeer eerst of een LAN rule voldoende is. Als source adres geef ik de PC waarop het programma draait, en als destination mijn alias lijst.
Rule, gebruikmakend van de alias
De twee pass rules staan nog boven de block rules
Nadat ik de nieuwe rule heb opgeslagen en bevestigd dat ik hem wil activeren, doe ik een nieuwe poging het programma opnieuw op te starten. Deze keer klaagt hij nergens over, en komt zelfs met een update. Ik besluit die gelijk te installeren. Dit gaat helemaal goed, alleen na afloop wordt de browser opgestart met een scherm dat geblokkeerd wordt. Waarschijnlijk een ‘gefeliciteerd met uw update’ mededeling. Ik weet de URL, en die wordt ook geblokkeerd als ik hem ingeef in de browser. De URL is ook terug te vinden in de DNSBL logging.
Omdat ik toch nieuwsgierig ben, voeg ik de url, en het hoofddomein toe aan de whitelist van DNSBL. Gewoon de url zoals boven vermeld in een soort tekst editor zetten. Het protocol (http of https) moet je weglaten. Omdat er geblokkeerd werd op de naam van de website, is het op de whitelist plaatsen voldoende. We hoeven geen rule aan te maken.
Twee domeinen toegevoegd aan de DNSBL Custom whitelistVolgende keer wil ik wat vertellen over als je PC zelf de blokkade veroorzaakt. Ik deel het even op, anders wordt het te veel in een keer.
Een externe firewall deel 7.2
Zelf veroorzaakte problemen
Als je aangevallen wordt, malware hebt, of de browser zaken gaat downloaden waar je geen belang bij hebt, verwacht je dat de firewall je beschermt en al het ongewenste verkeer tegenhoudt. Net zo goed wil je eigenlijk gewoon kunnen browsen op de sites die je altijd al bezocht. Dat lukt niet altijd. De website staat gewoon in Nederland, is betrouwbaar en toch wordt de verbinding soms geblokkeerd.
Ik heb het al eerder vermeld, soms zijn delen van de firewall te kritisch, vooral snort kan hier last van hebben. Soms wordt jouw verzoek om een webpagina geblokkeerd, en soms ook het antwoord van de webserver zelf. Dit komt altijd op ongelukkige momenten. Net als je bezig bent met een aankoop in een webshop, of als je inlogt op een van de gemeentelijke websites via DigID.
Er is iets in de communicatie waarop pfSense en zijn helpers reageren. Als je ook nog gebruik maakt van de optie “block offenders” kan het zijn dat je ineens geen enkele website meer kunt bereiken, en ook ping werkt niet.
De block offenders optie in snortVanaf een andere PC werkt het soms nog wel. Dan is het wel duidelijk dat pfSense jouw PC geblokkeerd heeft, omdat het iets verdachts heeft opgemerkt. En dat terwijl je alleen de naam van de website hebt ingevoerd.
Soms zijn de filters iets te kritisch. Ik heb gemerkt dat vooral snort daar last van heeft. Het kan zijn dat ik wel een simpele website heb ingegeven, maar dat er in het proces van beveiliging een URL wordt gegenereerd dat door snort als een “double decoding attack” wordt gezien, of iets anders verdachts. Op het pfSense forum heeft men het onder andere over het overgaan van een onbeveiligde http naar een beveiligde https verbinding.
Blokkade door pfSense valt eerst niet op, je gaat naar een normale website, maar er komt geen antwoord. Na een tijdje begint je te vermoeden dat pfSense wel eens de oorzaak kan zijn. Dan moet je zoeken of je eigen lokale IP adres, of je ziggo adres in de alert lijst voorkomt. Als je die hebt gevonden, kun je een uitzondering maken in de alerts.
Je kunt in theorie alles van/naar je eigen PC als uitzondering aanmerken, en alles toestaan. Alleen als je dan een keer malware op je PC hebt, wordt het ook niet opgemerkt. Immers: jouw PC staat op de lijst waarbij alles toegestaan is.
Ik wil dus alleen uitzondering maken voor de lichte overtredingen, zoal kleine foutjes in de communicatie.
Ik heb nu een paar maal gehad dat de communicatie opeens weg was, en heb de “block offenders” dus ook even uit staan. In alle gevallen is terug te vinden in de logging van pfSense waarom de communicatie geblokkeerd is. pfSense is gelukkig zo ingericht, dat ik altijd vanaf mijn LAN met de browser in pfSense zelf kan komen.
Het is handig als je twee dingen weet:
- Het lokale IP adres van de PC waarop je werkte
- Het IP adres aan de WAN zijde. Als je modem in bridge staat, is dat je IP adres van Ziggo, anders is dit het IP adres dat je van het modem krijgt.
Geen nood: beiden zijn in pfSense te vinden. Je hoeft geen nerd te zijn die zijn eigen IP adres uit zijn hoofd weet 🙂
IP adresssen in de ARP tabel in pfSense. Van boven af:- De ziggo gateway (ter herkennen aan het ip adres eindigend op .1
- Het IP adres dan ik van ziggo heb
- Twee apparaten met een intern IP adres
Met de IP adressen kun je in de diverse Alert lijst kijken of ze voorkomen als 'Source', of als 'Destination'.
Als het IP adres bij source staat, is die PC de veroorzaker. Als hij bij destination staat, is de server aan de andere kant de veroorzaker.
De alert logs kunnen in het begin een beetje verwarrend zijn, want er lijken drie of vier verschillende lijsten te zijn.
1. De pfBlocker Alert log
pfBlocker Alerts Deze kom je waarschijnlijk als eerste tegen, en wel omdat hij simpelweg onder: Firewall > pfBlocker > Alerts zit. Hier vind ik vooral overtredingen van de IP4 alert lijsten.
Als je op een groene i clicked gaat hij met het ip adres naar een ‘Threat lookup’, een lijst van web adressen die allerlei informatie over bedenkelijke IP adressen bijhouden.
Een lijst met bestrijders van spam, malware en andere zakenHet IP adres waar de i bij stond wordt meegegeven, zodat meteen wordt getoond wat bekend is over het IP adres. Je kunt zelf kiezen welke website je gebruikt. De een geeft aan of het adres al op een bekende block-lijst staat, de ander met welke malware hij in verband wordt gebracht.
Terug naar de alert lijst: Met een + kun je de lijst toevoegen aan de suppress lijst (of de whitelist voor DNSBL). Daarmee heb je van deze alert (eventueel alleen voor dat IP adres) geen last meer.
2. De System logs.
Je kunt hier op twee manieren komen, maar als je al bij de bovenstaande pfBlocker bent, click dan op 'firewall logs' op het menu eronder.
Afhankelijk van hoe je pfSense instelt, zullen veel alerts hier samen komen. Je hebt hier ook mogelijkheden om rules op de suppression list te zetten.
De system log met alertsDit zijn niet alleen malware waarschuwingen, er staat ook veel waarschuwingen in voor protocol fouten. Daarom staat hier onder andere ook het protocol vermeld.
We hebben hier vier punten waar we op kunnen clicken
- Een rode x: Hiermee wordt overtreding permanent geblokkeerd
- Een witte i: Deze zoekt een naam bij het IP adres
- Een groene - Deze voegt het IP adres toe aan de block list. Het IP adres is daarmee helemaal geblokkeerd
- Een groene + Deze zal dit verkeer op in het vervolg doorlaten
Deze informatie krijgt je ook als je er met de muiscursor op gaat staan.
3. De snort Alert log
Snort heeft zijn eigen Alert log, dat dankzij Barnyard uitgebreide filtermogelijkheden heeft.
Snort alert logOok hier mogelijkheden voor:
- Naam bij IP adres zoeken
- Toevoegen aan de suppress list, gebaseerd op source IP of destination IP
- De regel waarop snort alarm heeft geslagen permanent onderdrukken
Als een IP adres rare dingen doet, kun je filteren op IP adres, om te zien hoe lang hij al bezig is (dat heb ik behandeld in deel 5)
Bij mij staat hij vol met ET SCAN en ET COMPROMIZED die kijken of er bij mij poorten open staan. Het zijn vooral bekende poorten 22 (SSH) en 5060 (SIP). Als je het modem niet in bridge mode hebt staan, vangt de firewall in het modem dit voor je af.
4. De dnsbl log
Dit is de lijst met alle websites, die door de dnsbl functie niet naar een IP adres zijn omgezet, en die de PC dus niet door de PC bereikt konden worden.
De dnsbl listVaak staat deze vol met advertentie verstrekkers. Soms wordt er legale site geblokkeerd, of althans een die je wel wilt bezoeken. Dat is dan ook hier terug te vinden.
Ik heb een paar maal gehad dat een software programma niet kon updaten, of dat ik een Nederlandse website niet kon bereiken. Soms ging de hoofdwebsite nog wel, maar ging ergens iets met DigID fout. De website mijnoverheid.nl was ineens onbereikbaar, terwijl ik een bericht in mijn brievenbus had.
Dan ga je stuk voor stuk de bovenstaande alert logs bij langs, om te kijken of je eigen ip adressen in een alert log voorkomen. Als je een alert vindt, moet je voor jezelf uitmaken of er daadwerkelijk iets aan de hand is, of dat het alleen een probleem met de communicatie is.
Gelukkig hebben vrijwel alle logs een mogelijkheid om voor dat probleem een uitzondering te maken. Soms is het alleen voor dat ene lokale IP adres opgelost, maar omdat ook de uitzonderingen zijn aan te passen, is dat vaak ook op te lossen.
Dat wil nog niet zeggen dat alles goed gaat. Je komt nu wel bij de website, maar de webpagina van de server zelf wordt alsnog geblokkeerd. Nog een keer door de lijst om te zien waar het probleem zit.
Als je de uitzondingen goed maakt, zijn dat soort problemen gelijk bij alle websites opgelost.
De suppress lijstHierboven is een voorbeeld van een gegenereerde suppress lijst, die dus bepaalde regels onderdrukt. Het lijkt moeilijk te lezen, maar dat hoeft ook niet. Er is nog net te lezen welke rule onderdrukt wordt. Bij de onderste stond mijn lokale IP adres, die heb ik weggehaald om het voor alle IP adressen te laten gelden (het is gewoon een tekst bestandje)
Een vervelend probleem was een betaling via iDeal. Na afloop ga je weer terug naar de website, alleen die werd om een of andere reden geblokkeerd. Toen ik het probleem gevonden had (of althans ik dacht het) weigerde de website voor de tweede maal de inhoud van de pagina te versturen. Een soort beveiliging aan de kant van de server dus.
Tenslotte: Een Nice Catch
Omdat ik toch nog regelmatig in de alert logs kom, zag ik opeens dit in de alert log van Snort:
Hadsruda in de snort logLinks staat het source adres (mijn adres dus), rechts de bestemming. Ik wordt constant gescant door een tool Supviscious scan. Maar op de 5e regel van boven staat opeens MALWARE-CNC, een Trojan met de naam Hadsurda. En het is afkomstig van mijn IP adres.
Ik ben altijd erg voorzichtig met downloaden, maar er kan altijd iets doorslippen, of meekomen met andere software. Dat lijkt nu gebeurd. Het is gebeurd rond 20:22. Ik weet nog wat ik toen gedaan heb, maar ook in de DNSBL log hierboven is te zien wat ik toen deed.
Het kan toeval zijn, maar rond die tijd heb ik een update van Divx geïnstalleerd. Je moet een beetje voorzichtig zijn met dit soort afgeleide conclusies, maar het is wel toevallig.
Als ik even zoek op het internet naar Hadsruda vind ik:
In this case, Program:Win32/Hadsruda!bit may install other adware, toolbars, browser redirect, and hijack the home page of affected browser.
Het wordt niet als virus beschouwt, maar als een PUP, een Potential Unwanted Program. Het kan een programma zijn dat een toolbar installeert, of adware installeert, bijvoorbeeld in de browser.
pfSense met Snort heeft voor mij tegengehouden dat het kon communiceren met zijn thuisbasis, en andere dingen ophalen, en Adwcleaner wist het voor mij te verwijderen. Overigens staat het IP adres waarmee het probeerde te verbinden (54.76.37.1) ook al op de firehol blocklist. Ook als het niet was herkend, was het tegengehouden.
Dit is dus een van de alerts die ik mooi actief laat.
Een externe firewall deel 8
Port forwarding
Standaard blokkeert pfSense al het verkeer dat van buiten (vanaf het internet) komt. Als je zelf een webservice wilt draaien die vanaf het internet bereikbaar is zul je iets extra moeten doen. Je zult moeten configureren welke poort verkeer mag doorlaten naar een IP adres op je eigen netwerk. Of eventueel welke poorten, want je kunt in een keer een groepje poorten doorlaten. Dit noemt men NAT port forwarding. Het is alleen nodig bij IPv4, waarbij de router (in dit geval pfSense) je externe ziggo IP adres omzet naar een intern IP adres (of een groep van adressen). Bijvoorbeeld, het op internet bekende IP adres 84.85.86.87 wordt omgezet naar 192.168.1.x. x kan hierbij een getal tussen 1 en 254 zijn.
Voor IPv6 is NAT port forwarding niet nodig, omdat U voldoende externe IP adressen krijgt. Het kan natuurlijk wel zijn dat in het IPv6 modem in te stellen is welke poorten open of dicht staan.
Ik behandel hier even (IPv4) port forwarding voor de pfSense firewall. Dit is te vinden onder firewall> NAT
Destination staat standaard op WAN. Er is de mogelijkheid om een IP adres in te geven, en dat geeft soms wat verwarring. Dit is het originele IP adres aan de WAN zijde. Het is eigenlijk alleen van belang als er aan de WAN zijde (het internet) meerdere IP adressen zijn. Ik heb dat niet, dus ik laat het mooi leeg.
Destination port range Hier moet U het poort nummer ingeven waarop aan de internet kant geluisterd wordt. Ik kies een ongebruikelijk nummer 30180. Als je geen webserver draait, neem dan geen standaard poorten. Alle PC's die op het internet zijn aangesloten, worden constant gescanned op open poorten.
Redirect target IP Dit is het IP nummer aan de LAN zijde waar het binnenkomende verkeer naar toe wordt geleidt. Ik kies voor 10.0.0.101. Hierop zit een raspberry pi met Domiticz.
Redirect target port Dit is het poort die aan de LAN zijde gebruikt wordt. Domoticz gebruikt poort 8080 als webinterface.
Je kunt nog een omschrijving toevoegen, en opslaan. Bovenin komt een button waarmee de wijzigingen te activeren zijn. De nieuwe forward staat nu ook in het overzicht:
Om het te testen gebruik ik mijn telefoon. Ik zet Wifi uit, zodat al het verkeer via 4G data moet.
Ik moet nu ingeven mijn IP adres van ziggo, gevolgd door een dubbele punt en het poort nummer. Bijvoorbeeld: 80.81.82.83:30180.
Als het goed is, verschijnt dan het Domiticz login scherm op mijn telefoon.
Het werkt! Ik kan overal mijn Domoticz systeem instellen.
Als je dit soort dingen gaat doen, zorg dan wel dat het apparaat dat je openstelt helemaal bijgewerkt is met de laatste patches. Zowel het operating systeem, als de software die er op draait.
Telkens je IP nummer intypen is lastig. Er zijn wel mogelijkheden om net als bij websites een naam in te geven. Hier wordt onder andere uitgelegd hoe dit mogelijk is met ddns. Er zijn vast ook wel Nederlandse versies te vinden. Ik weet niet of noip.com in het Nederlands is, maar deze is in ieder geval gratis (als de informatie van het internet klopt).
Een externe firewall deel 9
Floating rules
In deel 7.1 liep ik tegen het volgende probleem aan: Ik blokkeer heel Rusland met behulp van Geoblock, maar wil toch een uitzondering maken voor een bepaalde site. We kunnen dan een rule aanmaken voor die ene site, maar omdat pfSense alle rules van boven naar beneden evalueert, en stopt zodra een rule geldig is, moet de uitzondering boven de geoblock staan. PfSense heeft een mogelijkheid om rules op een bepaalde plek te zetten.
Dit werkt heel goed, mits je daarna meteen de site benaderd. Als je het een paar dagen later weer probeert, kan het maar zo zijn dat je weer geblokkeerd bent. PfSense brengt namelijk ook zelf een volgorde aan, gebaseerd op een keuze die de gebruiker kan maken.
Standaard is: eerst alle rules die blokkeren, en dan de rules die iets toestaan. Dat is op zich logisch, want als je eerst alles doorlaat, heeft blokkeren geen zin meer. Alleen wordt door het automatisch sorteren die ene uitzondering ook weer verplaatst.
Ik heb verschillende opties geprobeerd om dit op te lossen. Andere manier van sorteren, secties, doch niets hielp. Ik was niet de enige die met dit probleem zat. Op forums vroegen mensen zich ook af wat het idee er achter was.
Uiteindelijk heb ik een oplossing gevonden: Floating rules. De floating rules worden als eerste uitgevoerd. Als ik mijn uitzonderingen in de floating rules plaats, worden ze al uitgevoerd voordat de standaard (blokkerende) rules worden geëvalueerd. Het maakt daarbij niet uit of de site geblokkeerd wordt door een Geoblock, of om een andere reden. Dus ook niet als de site op een lijst van besmette servers staat.. Je moet dus wel even oppassen voor je er gebruik van maakt.
De floating rules staan op een aparte tab, net als de rules voor WAN, LAN, etc.
Op de website van pfSense wordt de volgende informatie gegeven over floating rules:
Floating rules kunnen:
- Verkeer van de firewall zelf filteren
- Verkeer in uitgaande richting blokkeren (alle andere tabs filteren ingaand verkeer)
- Regels maken die gelden voor meerdere interfaces
- Filteren met 'laatste rule wint' bij meerdere geldige rules
- Veel meer
Met een floating rule kunnen we dus rules maken die als eerste geëvalueerd worden. Dat is perfect voor uitzonderingen op blokkering. Ik heb nu drie floating rules. Twee om verkeer door te laten, en een om verkeer te blokkeren.
De twee rules om wat door te laten zijn vrij simpel: Ze bevatten een enkele website, die elders geblokkeerd wordt. De rule om te blokkeren bevat een alias met een aantal websites die zich als tracker gedragen, en waarvan ik niet zeker weet of ze wel geblokkeerd worden. Omdat floating rules ook uitgaand verkeer kunnen blokkeren, leek me dit ideaal om deze sites te blokkeren. Het had het ook met een standaard rule kunnen doen, maar dan had ik die rule bij LAN en bij WLAN moeten plaatsen.
Floating rules hebben trouwens een Quick Optie. Hiermee heb je invloed op de evaluatie van de floating rules
- Als de optie aan staat, geldt de regel: de eerste rule die geldig is, wordt hij uitgevoerd.
- Als de optie niet aan staat, geldt de regel: de laatste rule die geldig is wordt uitgevoerd.
Alle floating rules worden geëvalueerd van boven naar beneden. Er wordt niet gestopt op de eerste die geldig is. Als er meer geldig zijn, kun je met de quick optie bepalen of de eerste wint, of de laatste.
Bij een rule die iets doorlaat, staat de optie standaard aan. Bij een die blokkeert staat hij standaard uit.
Als een geen de floating rules geldig is, wordt doorgegaan met de standaard rules bij WAN of LAN, afhankelijk van de richting van het communicatie pakketje
Interface, direction, etc.
Omdat je bij een floating rule aangeven voor welke interface hij geldt, en of het voor ingaand of uitgaand verkeer is zal ik dat nog wat toelichten. Stel we hebben de volgende situatie:
Je moet je goed realiseren dat alle rules gelden ten opzichte van de firewall. We zijn gewend om vanuit de PC, of vanuit het internet te redeneren.
Als ik vanaf de PC een datapakketje naar een website verstuur (b.v. een PING of een click op een link), dan gaat dat datapakketje van de PC naar de firewall, en die stuurt het naar de website.
- Voor de firewall (pfSense) komt er op de LAN interface data van de PC (10.0.0.5) binnen. Hierop worden de 'in' rules toegepast.
- Vervolgens vervangt de ingebouwde NAT het IP adres van de PC (10.0.0.5) door het IP adres aan de WAN zijde. Als mijn modem in bridge mode staat, is dit het adres dat je van Ziggo hebt gekregen (b.v. 81.82.83.84).
- Voordat de data naar Ziggo wordt verstuurd, worden aan de WAN zijde van de firewall, de 'out' rules toegepast. Wat door alle rules heen komt, wordt verstuurd via het internet.
- Het antwoord komt binnen aan de WAN zijde, en daar worden allereerst de 'in' rules voor de WAN interface toegepast.
- De NAT vervangt het publieke Ziggo IP adres weer met 10.0.0.5, en de 'out' rules van de LAN zijde worden toegepast.
Dit hele verhaal met in-rules en out-rules geldt dus alleen voor floating rules. De standaard rules worden alleen bij binnenkomend verkeer toegepast (LAN of WAN zijde).
Als je met standaard rules verkeer van PC naar facebook wilt blokkeren, moet je dus een rule aan de LAN zijde maken. Als je de verkeer vanaf facebook wilt blokkeren, moet je een rule aan de WAN zijde maken. Alleen met floating rules kan ik ook aan de WAN zijde uitgaande berichten blokkeren.
Hier is veel onduidelijkheid over, en eerlijk gezegd is het mij zelf ook lange tijd onduidelijk geweest. PfSense laat je namelijk ook rules aanmaken die niet zullen werken, zoals aan de WAN zijde een filter met source=10.0.0.5 en destination=facebook. (Dit werkt niet want de WAN zijde heeft geen inkomend verkeer van 10.0.0.5).
Niet gevonden wat je zocht?
Vind de oplossing met onze zoekmachine
Vul de belangrijkste trefwoorden in en vind het topic die past bij je vraag. Onze community zit boordevol kennis.
Stel je vraag aan andere community leden
Start je eigen topic en krijg hulp van anderen. Op de community helpen ervaren klanten je graag op weg.
