Onderwerp: CSF Firewall County block maakt lange iptable, hoe is dit op te lossen?

Mede wht-ers,

Op een klant zijn server (op kantoor) heb ik csf geinstalleerd omdat deze nogal wat last had van bruteforce attacks, bij nader onderzoek na een periode van een week bleek dat veel attacks afkomstig waren uit rusland, china, japan, korea, .... Kortom landen die niet geconnecteerd moeten worden op die server, hierop heb ik met overleg dus besloten om deze landen te blokeren vanuit csf. Maar tot mijn verbazing is de iptable nu gigantisch groot geworden en duurt het 8 minuten om deze volledig in te laden. Nadat ik even de iptable bekeken had werd mij al direct iets duidelijk, csf blijkt namelijk heel kleine netblocks te blokeren (/29 /28 /27 ...), voorbeeld:

Code:

123.456.1.0/24
123.456.2.0/24
123.456.3.0/25
123.456.3.128/25
....

Mijn vraag is of iemand weet hoe je dit vlug (en makkelijk) kan analyseren en dit tot grotere netblocks kan indelen, zodat de iptable lijst aanzienlijk kan ingekort worden, dus bvb van:

Code:

123.456.10.0/24
123.456.11.0/24
123.456.12.0/24
123.456.13.0/24
123.456.14.0/24
123.456.15.0/24
123.456.16.0/24
123.456.17.0/24

naar bvb:

Code:

123.456.10.0/21

Alvast bedankt voor het mee denken en zoeken.

Gebruik een eigen lijst ipv die van CSF?
http://www.countryipblocks.net/count...elect-formats/

Maar alles buiten Nederland komt nog op een 113k lijntjes hoor.

Oorspronkelijk geplaatst door Wynand

Gebruik een eigen lijst ipv die van CSF?
http://www.countryipblocks.net/count...elect-formats/

Maar alles buiten Nederland komt nog op een 113k lijntjes hoor.

Heb dit net even bekeken en juist even china geselecteerd en rarara wat stond er al in lijn 5:

Code:

1.1.0.0/24
1.1.2.0/23
1.1.4.0/22
1.1.8.0/21
1.1.16.0/20
1.1.32.0/19

1.2.0.0/23
1.2.2.0/24
1.2.4.0/22
1.2.8.0/21
1.2.16.0/20
1.2.32.0/19
1.2.64.0/18

Kortom dit kan ook veel simpeler en compacter lijkt me 1.1.0.0/18, 1.2.0.0/17 en ja ik weet dat die 1.1.1.0/24 en 1.2.3.0/24 niet mee telt maar die zou je dan bvb nog expliciet kunnen accepten. Maar dit scheelt op 13 lijnen al direct 11 lijnen (en met uitzondering 9 lijnen verschil), het is dus zo iets dat ik zoek al maakt het mij niet uit of het een vaste korte country lijst is of een programma dat iptables automatisch verkleint.

Je hoeft maar net een cliënt te hebben die voor z'n werk in één van deze landen vertoeft en je even een e-mail stuurt vanuit z'n hotel en die e-mail zal je al niet kunnen bereiken. Het blokkeren van gehele landen zou ik daarom dan ook afraden.
Als je goede wachtwoorden ingesteld hebt, wordt dit wachtwoord in de xx keer dat je dit toestaat überhaupt toch nooit geraden.

Oorspronkelijk geplaatst door dreamhost_nl

Je hoeft maar net een cliënt te hebben die voor z'n werk in één van deze landen vertoeft en je even een e-mail stuurt vanuit z'n hotel en die e-mail zal je al niet kunnen bereiken. Het blokkeren van gehele landen zou ik daarom dan ook afraden.
Als je goede wachtwoorden ingesteld hebt, wordt dit wachtwoord in de xx keer dat je dit toestaat überhaupt toch nooit geraden.

Lees even de start post goed, het gaat om een kantoor server waar geen smtp server op draaid dus dat is het punt niet. Verder staat de vpn poort voor overal ter wereld open, dus moesten er werknemers in een land zitten dat geblacklist is dan kunnen ze nog altijd via vpn aan wat ze moeten hebben. Maar zelf daarvoor zie ik niet direct een noodzaak, als ze daar op vakantie zouden zijn moeten ze toch niet werken . Het gaat vooral om het portal systeem (intranet) en ftp waar bruteforce op toegepast wordt. Reden waarom die server inhouse staat heeft te maken met de database koppeling tussen magazijn, verkoop, aankoop en boekhouding (maar dat maakt op zich ook niet uit, zelf al stond hij in colo dan nog moet het secure zijn).

Oorspronkelijk geplaatst door The-BosS

Lees even de start post goed, het gaat om een kantoor server waar geen smtp server op draaid dus dat is het punt niet. Verder staat de vpn poort voor overal ter wereld open, dus moesten er werknemers in een land zitten dat geblacklist is dan kunnen ze nog altijd via vpn aan wat ze moeten hebben. Maar zelf daarvoor zie ik niet direct een noodzaak, als ze daar op vakantie zouden zijn moeten ze toch niet werken . Het gaat vooral om het portal systeem (intranet) en ftp waar bruteforce op toegepast wordt. Reden waarom die server inhouse staat heeft te maken met de database koppeling tussen magazijn, verkoop, aankoop en boekhouding (maar dat maakt op zich ook niet uit, zelf al stond hij in colo dan nog moet het secure zijn).

Kun je niet beter iets met portknocking doen ?
Als je "alles behalve Asië" toelaat moet je nog steeds behoorlijk bovenop password keuzes zitten, evenals zero days.

Met portknocking kun je de logruis en risico van automatische exploits bij een zero day enorm beperken.

(portknocking : de firewall zet de tcp poorten open nadat een 'magisch herkenbaar' pakket gezien is. Bijvoorbeeld een ping van een bepaalde lengte, of connectie poging op andere tcp poort).

Je moet alleen de gebruikers instrueren, en iets kiezen wat simpel te gebruiken is en goed doorgelaten wordt door allerhande providers.

Oorspronkelijk geplaatst door visser

Kun je niet beter iets met portknocking doen ?
Als je "alles behalve Asië" toelaat moet je nog steeds behoorlijk bovenop password keuzes zitten, evenals zero days.

Met portknocking kun je de logruis en risico van automatische exploits bij een zero day enorm beperken.

(portknocking : de firewall zet de tcp poorten open nadat een 'magisch herkenbaar' pakket gezien is. Bijvoorbeeld een ping van een bepaalde lengte, of connectie poging op andere tcp poort).

Je moet alleen de gebruikers instrueren, en iets kiezen wat simpel te gebruiken is en goed doorgelaten wordt door allerhande providers.

Daar had ik ook al aan zitten denken maar dit is een beetje omslachtig voor klanten die moeten inloggen op het intranet systeem om bestellingen te plaatsen etc. Het zijn tenslotte geen ict-ers die moeten inloggen. Tenzij er een eigen webclient ontwikkeld zou worden die eerst de portknocking doet en dan de webpage opent. Maar dan zit je met het punt wat support je wel van os/devices en wat niet.

Oorspronkelijk geplaatst door The-BosS

Daar had ik ook al aan zitten denken maar dit is een beetje omslachtig voor klanten die moeten inloggen op het intranet systeem om bestellingen te plaatsen etc. Het zijn tenslotte geen ict-ers die moeten inloggen. Tenzij er een eigen webclient ontwikkeld zou worden die eerst de portknocking doet en dan de webpage opent. Maar dan zit je met het punt wat support je wel van os/devices en wat niet.

Je kunt van alles verzinnen, het hoeft niet (technisch) moeilijk te zijn.
Je kunt http://rarenaam.bedrijf.invalid/abacadabraxyz1234 op laten vragen voordat de intranet open gaat bijvoorbeeld.

Dat kan op alle devices die ook op het intranet kunnen (want een webbrowser) in een bookmark;
Iets op een non-standaard poort kan ook, maar dan kun je alweer tegen filter regels op lopen van bijvoorbeeld bedrijfsnetwerken of gasten wifi.

Ik denk dat je met zo'n drempeltje om de 'ruis' van brute forcende willekeurige botjes te filteren beter af bent dan met monsterlijk grote reeksen ip subnetjes om (slechts) 1/3 van het internet te blokkeren.

Je zult alleen wat moeten scripten om een koppeling te maken tussen het queryen van de 'geheime' url en pas daarna het accepteren van een login poging vanaf het IP adres wat de URL opvroeg.

Qua security is het natuurlijk erg beperkt, maar het doel van dit soort truken is gewoon om de 'logruis' en risico van een automatisch zero-day exploit iets te beperken;
De rest van de security moet nog steeds volgen uit behoorlijke passwords (en SSL) op het intranet.

Oorspronkelijk geplaatst door visser

Qua security is het natuurlijk erg beperkt, maar het doel van dit soort truken is gewoon om de 'logruis' en risico van een automatisch zero-day exploit iets te beperken; De rest van de security moet nog steeds volgen uit behoorlijke passwords (en SSL) op het intranet.

Daar ben ik het uiteraard mee eens, het intranet is ook beveiligd met een ssl cert, maar dat neemt de brute force logins niet weg. Kwa wachtwoorden ben ik ook niet direct zo bang eigenlijk (toch niet op administrator level), en wat betreft klanten logins is het de fout van de klanten lijkt me als die gehackt worden. Tenzij hackers natuurlijk die login dan gebruiken om packet injection te doen op sql query's etc, maar dat is dan weer het probleem van de software fabrikant.

Ik denk dat ik die country dingen dan maar achterwege zal laten en de firewall (csf) gewoon strakker zal instellen en het risico er dan maar bijnemen dat een geldige login bvb tijdelijk geblokeerd kan worden. Andere optie is natuurlijk om de volledige netblocks die iana aan apnic, afrinic en lacnic toekent te blokkeren en eventueel bepaalde landen/ranges toe te laten. En dan voor europese (RIPE) ip blocken enkel de country code toe te passen voor bvb rusland.