Onderwerp: bruteforce problemen

Oorspronkelijk geplaatst door dreamhost_nl

CSF/LFD kun je ook in een cluster draaien, waarmee je in één keer één Brute Force poging voor alle servers blokkeert.

I know, heb er zelf een paar in cluster mode runnen, alleen resulteert dit in een iptable van +50.000 rules. En dat is iets dat je niet wil hebben op je gewone server, zeker niet als het letterlijk 5 minuten duurt om je iptables op te starten en volledig in te lezen. Daarom heb ik nu beslist om een watchguard voor de servers te zetten zodat de csf ontlast wordt en bvb enkel nog lokale dingen moet blokken zoals bruteforce van bvb cronscripts etc. En hardware matige firewall zijn er nu eenmaal voor gebouwd om die dingen te doen en een gewone server zijn resource kun je beter gebruiken waarvoor die bedoeld zijn.

Verder ben ik het met wido eens dat je de standaard poorten beter de standaard poorten kunt laten tenzij je een honypot op de ssh poort wil draaien om wat voor reden dan ook. Maar als ze je server echt willen hebben komen ze met een portscan toch direct achter de open poorten en met een version scan weet je ook direct wat op die poorten draaid. Ja je poort veranderen helpt tegen allerhande scripts, maar je maakt het er voor je klanten en jezelf niet makkelijker op.

Oorspronkelijk geplaatst door The-BosS

Ja je poort veranderen helpt tegen allerhande scripts, maar je maakt het er voor je klanten en jezelf niet makkelijker op.

Onze "shared hosting" cliënten hebben standaard geen toegang tot SSH. SSH wordt dus alleen door ons benaderd (of zou dit moeten worden ).

tenzij je een honypot op de ssh poort wil draaien om wat voor reden dan ook.

Dus 22 lekker bereikbaar laten blijven maar je SSH daadwerkelijk op een andere poort laten draaien, doen wij ook met hetzelfde resultaat als Dreamhost, 100% rust, ondanks dat we ook keys gebruiken voor ssh.
Maar het is gewoon leuk om scriptkiddies en wanabe's lekker te maken maar toch dwars te zitten.
Doe je een poortscan hang je al in de blacklist voordat je alle poorten hebt gehad.

Je kunt het ook standaard laten en hetzelfde doen, feit is wel dat ze altijd lopen te klooien op die poort en op een niet-standaard poort niet zo vlug.
Met veel servers is het onhandig, met weinig servers zorgt het voor rust in je logfiles danwel bruteforce meldingen.
Tenzij jullie die niet nakijken uiteraard. Voor beide methodes is iets te zeggen maar een "beter" bestaat m.i. niet v.w.b. dit geval. Als je ze je echt willen hebben krijgen ze je toch wel, desnoods via sql injecties of andere zaken.

Back on topic lijkt me dat ik voor 43 servers ook toch wat verder ging kijken voor oplossingen i.p.v. al zo vlug op alle servers iets te plaatsen, ondanks dat CSF/LFD wel erg goed is.

Oorspronkelijk geplaatst door dreamhost_nl

Onze "shared hosting" cliënten hebben standaard geen toegang tot SSH. SSH wordt dus alleen door ons benaderd (of zou dit moeten worden ).

Dan snap ik niet waarom je ssh in je firewall niet gewoon volledig toe zet en enkel je fixed office (of andere externe ip's) toe laat of via een vpn verbinding maakt met je ssh op de server.

Oorspronkelijk geplaatst door Blacky

Dus 22 lekker bereikbaar laten blijven maar je SSH daadwerkelijk op een andere poort laten draaien, doen wij ook met hetzelfde resultaat als Dreamhost, 100% rust, ondanks dat we ook keys gebruiken voor ssh.
Maar het is gewoon leuk om scriptkiddies en wanabe's lekker te maken maar toch dwars te zitten.
Doe je een poortscan hang je al in de blacklist voordat je alle poorten hebt gehad.

Je kunt het ook standaard laten en hetzelfde doen, feit is wel dat ze altijd lopen te klooien op die poort en op een niet-standaard poort niet zo vlug.
Met veel servers is het onhandig, met weinig servers zorgt het voor rust in je logfiles danwel bruteforce meldingen.
Tenzij jullie die niet nakijken uiteraard. Voor beide methodes is iets te zeggen maar een "beter" bestaat m.i. niet v.w.b. dit geval. Als je ze je echt willen hebben krijgen ze je toch wel, desnoods via sql injecties of andere zaken.

Uiteraard worden de brute-force meldingen in het oog gehouden, alleen zitten die ook vlugger in de firewall dan dat er een melding komt. Maar zoals in vorig antwoord al gegeven waarom zou je de poorten aanpassen als je ze gewoon volledig kunt blokken in je firewall als je toch alleen die poorten gebruikt. Zo heb ik een server die voor iemand van buitenaf volledig onbereikbaar is (alsof hij niet bestaat) maar voor sommige fixed ip's wel toegankelijk is. En dan is het nog afhankelijk welk fixed ip's in de firewall toegang krijgen tot de verschillende poorten. Dit lijkt me een betere keuze dan standaard poorten veranderen en moet je sommige management tools ook niet beginnen aanpassen.

En inderdaad als ze je willen hacken/cracken/... dan zullen ze wel een manier vinden om hun doel te bereiken.

maar voor sommige fixed ip's wel toegankelijk is.

Ook die bescherming zit er momenteel op. Nadeel is dat mijn bedrijfje maar klein is en geen echte fixed ip's heeft. Als het dus wisselt moet je telkens alles gaan omzetten omdat CSF bij mijn weten dat niet via een hostnaam kan regelen.
Daarnaast wisselt de hostnaam ook weer met het wisselen van het ip. Als je van thuis uit werkt dus zonder een zakelijk adsl/kabel abo met vaste ip's.

Natuurlijk is de methode van beveiligen die je aangeeft beter dan alleen het verplaatsen van een poort.

Ik wilde ook alleen aangeven dat het verplaatsen van de poort of standaard laten staan niet beter of slechter is maar wel wat rust brengt. Want poort 22 zichtbaar of niet, ze bruteforcen er toch op.
De echte bescherming (het betere) hangt immers toch af van de beveiligingsmethode(s) die je gebruikt zoals je zelf ook al aangeeft.

Zoals gezegd zal het voor grotere bedrijven c.q. meer servers anders zijn, dan kun je het vermoedelijk weer beter gewoon allemaal laten staan mede i.v.m. management tools etc.

Oorspronkelijk geplaatst door The-BosS

I know, heb er zelf een paar in cluster mode runnen, alleen resulteert dit in een iptable van +50.000 rules. En dat is iets dat je niet wil hebben op je gewone server, zeker niet als het letterlijk 5 minuten duurt om je iptables op te starten en volledig in te lezen.

Wat blokkeer je dan allemaal met meer dan 50.000 regels in de firewalls? Net heb ik even gekeken en wij hebben beduidend minder firewall regels op de firewalls die bij ons overal bij voor staan. Wel hebben wij een eigen systeem ontwikkeld om automatisch bepaalde logs te scannen en mislukte inlogpogingen (SSH/IMAP/POP3/SMTP/FTP/etc.) automatisch te blokkeren zodra er te veel mislukte inlogpogingen binnen een bepaalde periode plaatsvinden vanaf een bepaald IP.

Connection tracking is overigens iets dat je niet wilt gebruiken in veel gevallen (door de extra belasting/vertraging voor bijvoorbeeld DNS verkeer).

Oorspronkelijk geplaatst door Mark17

Wat blokkeer je dan allemaal met meer dan 50.000 regels in de firewalls?

Heel simpel helft van rusland, en bijna volledig korea, china, japan, pakistan, afganistan en ga zo maar door. Plus natuurlijk de bruteforce attacks en andere dingen die de firewall moet opvangen. Nu het is ook zo dat de firewall momenteel ingesteld staat om enkel te blokkeren op de poorten die misbruikt worden, het kan dus zijn dat een ip 3 keer voorkomt met 3 verschillende poorten die geblokkeerd worden. Maar zoals ik dus al eerder vermelde komt hier binnenkort verandering in door het plaatsen van een watchguard.

Enige nadeel dat ik tegenwoordig ondervindt is dat gebruikers de duppe worden van andere gebruikers sinds dat bepaalde providers zoals proximus nat zijn beginnen invoeren op hun mobiele verbindingen. Iemand toevallig een oplossing daarvoor, want er moet maar één enkele persoon iets doen waardoor die in de firewall terecht komt en plots blokkeer je een paar tientallen/honderd/duizend mensen.

Oorspronkelijk geplaatst door The-BosS

Iemand toevallig een oplossing daarvoor, want er moet maar één enkele persoon iets doen waardoor die in de firewall
terecht komt en plots blokkeer je een paar tientallen/honderd/duizend mensen.

Simpelweg IP-adressen van mobiele providers niet blokkeren of slechts gedurende een bepaalde periode.

Oorspronkelijk geplaatst door dreamhost_nl

Simpelweg IP-adressen van mobiele providers niet blokkeren of slechts gedurende een bepaalde periode.

Dat is al het geval dat het maar tijdelijk is, maar van zodra het weer vrijgegeven wordt zit het bijna direct terug in de firewall. Heb trouwens van een klant al vernomen dat firewall's niet de enige zijn die hier problemen mee hebben. Maar ftp servers die een maxclient per ip hebben bvb 3, dan wil dat ook zeggen dat er maar 3 mobiele klanten van die range de ftp kunnen gebruiken (of andere diensten die connecties per ip bekijken).