Poortbeveiliging

[anon54082171]

Ik zit sinds twee dagen op op het Freedom netwerk en kom van Xs4all. Bij Xs4all kon je poortbeveiliging aanzetten op jouw verbinding.

Ik was vergeten dat het niet meer geval was nadat ik op Freedom was overgegaan en nog geen 24 uur geleden mijn teller gereset om te zien hoeveel scans er langskomen.

Dat zijn er nu bijna 15.000 (SYNC) packets en dat is toch best veel in nog geen 24 uur. De scanner komt op een lijst en dan ik kijken of die nog een keer langskomt binnen 15 minuten. Vier packet maar van terugkerende scanners die niet op TCP nog eens probeerden.

Is het een goed idee om net als bij Xs4all binnen het netwerk poort filtering implementeren. Dit kunnen enkele profielen die bepaalde services doorlaten of zelf heel specifiek zoals ik in mijn firewall gebruik poort 80,443,25. En voor de rest staat er niets open.

UDP is hier moeilijker en ook niet zo veel gebruikt om te scannen en die kunnen ook door de statefull firewall van Fritz buiten de deur gehouden worden.

Het gaat hier zuiver om SYNC packets en dit kan zonder connection tracking worden gedaan en heeft dan ook een minimale impact of zelf een positief effect op de hoeveelheid verkeer in het hele netwerk omdat de ranges niet meer worden opgenomen omdat er geen resultaten uitkomen voor de scanners.

Dit is wat Xs4all doet: https://www.xs4all.nl/service/installeren/beveiliging/veilig-internetten-poortbeveiliging/

Toevoeging: ik heb het hier alleen over van het internet komende scans naar de abonnee toe. Uitgaand zou precies zo kunnen werken dat in de lijst poorten staan die je liever niet in contact brengt met het internet. Die heten dan “out” poorten in de opzet zoals bij Xs4all.

Ik neem aan dat Freedom zelf in gaten houdt of een abonnee ook poort 53 openzet en dan die dan informeert dat dit niet gewenst is i.v.m. DDos attacks. Bij Xs4all zetten dan jouw verbinding meteen dicht en het kost je veel moeite om die weer open te krijgen.
Dat is nou ook niet wijze die ik als verstandig zie.

[readefries]

Lastig. Enerzijds krijg ik het gevoel dat iets standaard afsluiten niet helemaal past in het kader van Freedom. Anderzijds, denk ik dat er legio aan (potentiële) klanten zijn bij wie deze mogelijkheid een toegevoegde waarde zijn.

Ik zou het uitzetten: ik vind dat mijn provider verantwoordelijk is voor de lijn en niet voor mijn router of netwerkconfiguratie.

[Erik]

Ik vraag mij ook af, wat mijn fritzbox filtert.
Bij NETBIOS staat nergens wat het exact filtert.
En is dit voldoende, moet ik er nog wat aan toe voegen?
Een extra veiligheid bij de provider, gaf wel een veiliger gevoel.
Maar is dat ook zo?

[anon54082171]

Van de AVM site:

De FRITZ!Box biedt een compleet gesloten firewall voor bescherming tegen ongewenste gegevens vanaf internet. In de fabrieksinstellingen zijn alle computers, smartphones en andere apparaten die zijn verbonden met de FRITZ!Box, al volledig beveiligd tegen aanvallen vanaf internet.

LET OP! De firewall is niet actief als de FRITZ!Box de internetverbinding van een andere router gebruikt (“IP-clientmodus”). In dit geval raden wij aan om in de andere router een firewall te configureren.

De firewall van de FRITZ!Box biedt de volgende beveiligingsfuncties:

• De FRITZ!Box controleert alle inkomende en uitgaande gegevenspakketten en wijst ongevraagde gegevens van internet automatisch af ( Stateful Packet Inspection ). Hierdoor kunnen alleen gegevenspakketten naar het thuisnetwerk worden gerouteerd, die direct antwoorden op eerdere aanvragen.
• Geen enkel apparaat in het thuisnetwerk is zichtbaar op internet, zodat vanaf internet ook geen directe toegang tot de apparaten mogelijk is. Dit wordt op TCP/IP-niveau gewaarborgd door IP-masquerading of Network Address Translation (NAT) .
• Alle TCP-of UDP-poorten zijn standaard gesloten voor inkomende verbindingen vanaf internet naar het thuisnetwerk. Daarom kunnen zogenaamde “portscans” geen open TCP- of UDP-poorten vinden die zouden kunnen wijzen op zwakke punten voor mogelijke aanvallen van “hackers”.
• Met pakketfilters voorkomt de FRITZ!Box dat gegevenspakketten (bijvoorbeeld NetBIOS) die informatie over apparaten in het thuisnetwerk bevatten, het internet bereiken.

Voor web- en VPN-servers, onlinegames en andere toepassingen die toegankelijk moeten zijn vanaf internet, kun je portforwarding configureren voor specifieke poorten.

Als de FRITZ!Box ongevraagde aanvragen vanaf internet moet afwijzen in plaats van te antwoorden met ICMP-controleberichten, schakel je in de gebruikersinterface van de FRITZ!Box, onder “Internet > Filters > Lists > Global Filter Settings” de optie “Firewall in stealth mode” in.

De veiligheid zit wel snor met de fritz.box Het gaat mij meer om dat al scanverzoeken op een eerder moment in het netwerk al ge-tackled worden voordat het bij de duizenden fritz.boxen van de Freedom klanten aankomt.

De poort beveiliging van Xs4all gaat veel verder en in feite een tweede firewall in jouw verbinding. Het zijn basisprofielen die aangeboden worden en het is aan jou of die wilt gebruiken of niet. Een firewall moet ook de verbinding onderhouden en dat vraag dus processor kracht en dat is een extra investering.

Bron AVM: https://nl.avm.de/service/fritzbox/fritzbox-7590/knowledge-base/publication/show/57_Beveiligingsfuncties-firewall-van-de-FRITZ-Box/

[patrick]

Ik denk dat er veel technische argumenten zijn om een een poortfilter toe te voegen. Lokaal wegfilteren lokaal gefilterd verkeer geeft wat rust bij het bekijken van de logs. Geen idee of dat op de fritz kan.

Wel kan dit (poortfilter) een goede aanvulling zijn op de dienst, waaronder een extra zekerheid tegen het falen van bestaande lokale apparatuur. Dit kan zijn:

• Onduidelijke of onvolledige specificaties, zoals @Erik hierboven aangeeft.
• Configuratie fouten op lokale apparatuur.

Om dit laatste extra kracht bij te zetten. In het verleden had ik geen filter. Door een configuratie fout aan mijn kant heb ik ooit poort 445 open gezet voor een specifiek vlan naar de buitenwereld. Een halve dag later kwam ik hier pas achter. Dat was geen handige actie. Misbruik is gelukkig meegevallen. De schrik en de tijd die erin heeft gezeten was wel vervelen. Daarna dus een filter niveau 3 erop gezet. Een filter op die poorten heeft volgens mij meer baat dan het schaad voor het overgrote deel van klanten. Wel moet dit een keuze blijven.
Nu heb ik extra maatregelen genomen om een ‘ongelukje’ van een soortgelijke situatie te mitigeren.

[patrick]

@anon54082171

De poort beveiliging van Xs4all gaat veel verder en in feite een tweede firewall in jouw verbinding. Het zijn basisprofielen die aangeboden worden en het is aan jou of die wilt gebruiken of niet. Een firewall moet ook de verbinding onderhouden en dat vraag dus processor kracht en dat is een extra investering.

Dit gaat over de haalbaarheid en prioriteit. Waarvan ik mij kan voorstellen dat er eerst meer leden moeten komen om sneller uit de rode cijfers te komen.

[Noci]

Voor mij stond de poort beveiliging bij Xs4all altijd uit. Al kan ik me voorstellen dat het voor sommige leden wat gemoedsrust kan bieden.
Ik gebruik zelf een firewall op basis van (Linux) iptables waarbij veel checks in de raw keten, prerouting zitten. (ipadresses blokkeren etc, zonder veel overhead).
Fail2ban wordt gebruikt om scans vanuit de diverse logfiles te scannen en die dan op de eigen zwarte lijst op te nemen.
Daarnaast wordt er regelmatig een blacklist van het internet gehaald, en heb ik ook een zwarte lijst van opvallende reeksen van Sans stormcenter. ( https://isc.sans.edu/ )

Er zijn een paar netwerken waarbij je poorten gescanned worden vanuit een /22 netwerk waarbij een host maar een paar keer per dag langs komt. met een paar poorten. Er wordt best moeite gedaan om onder de radar te blijven.

[anon54082171]

Ik gebruik een router en die werkt ook zo en dit zijn mijn RAW regels voor TCP en UDP (voorbeeld):

action=add-src-to-address-list chain=prerouting protocol=tcp dst-port=!25,80,443 address-list=detectedTCP src-address-list=!detectedTCP tcp-flags=!fin,!rst,!psh,!ack,!urg,!ece,!cwr
action=drop chain=prerouting dst-port=!25,80,443 protocol=tcp tcp-flags=!fin,!rst,!psh,!ack,!urg,!ece,!cwr
action=drop chain=prerouting protocol=udp src-address-list=!voip src-port=!53,123

De eerste regel voegt en bronadres toe aan de lijst "detectedCTP"welke die mijn router bezoekt en niet gaat voor de drie poorten die ik heb open staan. Als scanner nog een keer langskomt dan gaat die niet nog een keer in de lijst. Dit is gedaan om de teller niet te laten verhogen zodat ik het verschil kan zien met de daadwerkelijke geblokkeerde scans.

De tweede regel is in basis hetzelfde maar die blokkeert ook de daadwerkelijke scan. De poorten die ik open heb staan 25,80,433 (ontvangen e-mail en webserver) worden doorgelaten en worden vergeleken met van het internet opgehaalde adreslijsten van niet betrouwbare adressen.

UDP is lastiger omdat er in RAW geen SYNC aanwezig is en je niet weet of de scanner een begin van een sessie wil opzetten of al in de sessie zit.
Ik draai het daarom om. Ik verwacht alleen inkomend UDP verkeer via poorten die ik zelf ook als doel gebruik. Hier dus port 53,123 (DNS en NTP) en alle andere bron poorten worden geblokkeerd.
O ja, VOIP die komt ook binnen als er geen sessie staat via NAT. Ik weet wie er binnen mag komen op poort 5060 en aankloppen en die laat ik door op hun bron adres. Die kunnen dus binnenkomen via al hun bronpoorten maar het is hier dan een kwestie van vertrouwen.
De scanners die deze bronpoorten gebruiken worden weer vergeleken met adreslijsten van niet betrouwbare adressen

Nu heb ik firewall redelijk dicht en hoeven er niet veel adressen vergeleken te worden met de adreslijsten van niet betrouwbare adressen.

Ik wil alleen de SYNC packet bekijken en ik moet daarom alle ander uitsluiten en dat resulteert in: tcp-flags=!fin,!rst,!psh,!ack,!urg,!ece,!cwr en het uitroep teken staat voor “niet”.

ps. voor adres blokken heb ik ooit een script gemaakt die dan in blokken van /24 die pakt.

De werking is, alle scanners gaan op lijst-1 en blijven daar een tijd staan. Het script kijkt of er meer enkele IP adressen in lijst01 aanwezig zijn in hetzelfde /24 bereik. Zo ja dan gaat dat IP adressenbereik op lijst-2 die dan daadwerkelijk in de het hele /24 bereik blokkeert.

Onderhoud gaat als volgt. Als een adresbereik niet verschillende keren voorkomt dan gaat die uit de lijst. Als een adresbereik wel voldoet dan gaat de /24 naar lijst-2 en worden in lijst-1 alles wat in dat /24 bereik gewist.

Ik had het al even niet gebruikt en nu getest en hij pakte meteen acht /24 reeksen uit de lijst van 1 uur en komt dan weer voor wat ik hierboven had beschreven.

Update: weer bezig geweest met het script om het sneller te maken want door zo’n 40.000 adressen te gaan en dat honderd keer achter elkaar is traag. Nu zet ik eerst verdachte adressen in een array waarna ik alleen de array hoef na te lopen.

Daar naast ben ik aan het kijken of ik een /16 range kan gebruiken om zo ook scans uit een grote range detecteer en opbreken in /24 ranges.

Eentje is 192.241.128.0/17 Digitalocean die met een hele reeks in de scanlijst staat.

Sinds gisteren zo’n 14.000 packets ontvangen die niets te zoeken had op mijn verbinding.

[anon54082171]

Ik heb het nu een tijdje lopen en ook met het blokkeren op /24 ranges. Een nadeel van blokkeren en dan vooral op grotere aantallen opvolgende IP adressen is dat je mogelijk een website wil bezoeken die bij toeval in die range zit.

Omdat alleen inkomende verbindingen worden vergeleken met de blokkeerlijst kan de router zien wanneer een browser naar zo’n IP adres wil gaan. In Mangle markeer ik de uitgaande connectie en in NAT verwijs ik dan mijn lokale webserver die dan aangeeft dat IP adres dus op de blokkeerlijst staat.

Nu het ‘probleem’ dat verbindingen versleuteld zijn en dan kan mijn lokale webserver wel een antwoord geven maar dat matcht niet met adres welke ik heb ingeven in de browser.
Er komt dan een SSL/TSL foutmelding en dan kan ik toch controleren of de blokkeerlijst de oorzaak is. Dit door HTTPS te veranderen in HTTP en opnieuw te verzenden.

Ik gebruik een ‘niet blokkeerlijst’, die toestaat om toch sites te bezoeken die op de blokkeerlijst staan.

Ook heb ik nu UDP helemaal dicht staan voor inkomend verkeer en ik doe UDP geheel door de VPN dus niets meer te zien op mijn WAN IP voor inkomende UDP.
Mocht ooit de VPN niet werken dan is er altijd nog een geitenpaadje voor DNS beschikbaar.

Het blokkeren is nog heftig aan mijn zijde omdat na detectie en eventuele plaatsing op de permanent range 24 blokkeerlijst (perm24block) geen enkele verbinding meer wordt aangenomen, ook geen 25,80,433 en zo ziet de scanner helemaal geen ‘open’ poorten meer. Ik schijf open, maar eerst gaat die binnenkomende verbinding eerst door een aantal lijsten en daarna moet die eerst ook nog eens match met wat de statefull firewall verwacht.

[anon54082171]

De laatste stap is klaar en ik kan nu met een bredere range zoeken en dan alleen blokkeren in de range van /24 waar ook het IP adres zat die de scan heeft gedaan.

Hier heb een range van /18 opgegeven en dan pakt hij alle scanners in die range. De lijst waaruit de adressen komen zit een timeout van twee dagen. Als ze in die tijd niet naar de perm24Block lijst zijn gezet dan gaat de blokkade op alleen dat specifiek IP adres er weer vanzelf af.

Hieronder één met een kleinere range van /22

Bij vier gevonden scanner lijst adressen in de opgegeven range gaat alle gevonden adressen in die range naar de perm24Block lijst.

[anon54082171]

In de “Honeypot” zaten in het twee dagen venster veel reeksen gevangen en toen ik die bekeek kwamen de meeste grote reeksen van Digital Ocean af. De ASN nummers opgezocht en de hele mikmak geblokkeerd met uitzondering van enkele nog niet gedetecteerde ranges/reeksen van hun.

Deze zijn du nu niet actief geblokkeerd maar met één klik zijn ze dat wel als ik veel IP adressen uit die range in de “Honeypot” vind.

Ik kan dit redelijk ongestraft doen in mijn eigen route omdat ik ook de deblokkeerlijst zelf bij hou en zo toch IP adressen kan toestaan als ik die wil bezoeken.

Eens kijken of het twee dagen venster nu ook daadwerkelijk minder gedetecteerde scans gaat bevatten dan de huidige 2500 gemiddeld.

Over twee dagen nog maar eens oogsten en kijken wat er dan in de lijst zit.

Dit is dus een stap verder dan hetgeen ik hier voorstelde en dat is simpler en behoeft maar minimale onderhoud.