Bekijk Volledige Versie : bruteforce problemen
servermonster
05/08/11, 01:28
Hallo, ik heb sinds de laatste dagen last van een enorme berg met bruteforce attacks, meestal nullroute ik die ip adressen dan per hand, enkel lijkt het erop dat ze alsnog toegang hebben :/
route add -host **.**.**.** reject
route add **.**.**.** gw 127.0.0.1 lo
als ik dan ip route get **.**.**.** opvraagt zegt hij
webserver29:~# ip route get **.**.**.**
RTNETLINK answers: Network is unreachable
webserver29:~#
en dan later in directadmin bij de bruteforce logs kijk staat die gladjanus er mooi weer tussen :s
iemand een idee om dit te oplossen?
Waarom gebruik je niet zoiets als ConfigServer Security & Firewall (http://configserver.com/cp/csf.html)? Dan worden Bruteforces automatisch gedetecteerd en geblokkeerd?
servermonster
05/08/11, 01:38
kga er eens mee knoeien :) heb eerst ff tijdelijk de ssh port op een andere gezet. Bedankt voor je snelle reactie
servermonster
05/08/11, 01:56
Bedankt joriz,
alles is nu opgelost :)
ga dit tooltje zo ff op alle (43) servers installeren.
dreamhost_nl
05/08/11, 08:14
Uit interesse: Wat had je hiervoor dan draaien als Firewall, want in elke Firewall die ik ken zit wel iets waarmee automatisch een BruteForce aanval wordt gestopt.
Als je dan toch 43 servers hebt, waarom gebruik je dan geen firewall voor allemaal die servers. Het moet daarom geen watchguard, juniper, cisco, sonicwall, ... zijn maar een pfsense, vyatta of andere opensource firewall zou ook al genoeg zijn. Dit belast je servers minder en je hebt het voordeel dat je dan niet in iedere server opnieuw een bruteforce moet ontdekken en je algemene regels kan toepassen.
ga dit tooltje zo ff op alle (43) servers installeren.
*proest*
En dat doe je 'ff' na het 'tooltje' nog geen 30 minuten getest te hebben.
Voor ssh (en andere services) kan je ook mooi fail2ban gebruiken, werkt erg goed
P.S. vergeet niet overal je zelf in ignore en/of allow te zetten, zodat je zelf nooit geblockeerd word ;)
Ik lig persoonlijk nooit zo wakker van brute-force aanvallen op de SSH.
Beste is imho om password authenticatie volledig UIT te zetten en enkel key-based SSH toe te staan.
websiteondemand
05/08/11, 11:51
denyhosts, ssh op andere poort, ssh alleen open voor bepaald ip, firewall rules en mods, ...
dreamhost_nl
05/08/11, 13:55
... en je hebt het voordeel dat je dan niet in iedere server opnieuw een bruteforce moet ontdekken en je algemene regels kan toepassen.
CSF/LFD kun je ook in een cluster draaien, waarmee je in één keer één Brute Force poging voor alle servers blokkeert.
dreamhost_nl
05/08/11, 13:56
Ik lig persoonlijk nooit zo wakker van brute-force aanvallen op de SSH.
SSH over een andere poort resulteerde hier in een teruggang van 100% aan Brute Force pogingen voor SSH.
SSH over een andere poort resulteerde hier in een teruggang van 100% aan Brute Force pogingen voor SSH.Wat schiet je daar nu echt mee op? Imho is het alleen maar vervelend om SSH op een andere poort te draaien.
Wij doen verder veel met de hosts.allow/deny icm key-based authentication, maar SSH op een andere poort?
A: Het is veel werk om het overal om te configureren
B: Bij het connecten moet je altijd een andere poort opgegeven
C: Het maakt je systeem niet veiliger
Maar die discussie is hier al vaker gevoerd :)
dreamhost_nl
05/08/11, 15:25
Inderdaad is die discussie al vaker gevoerd. Ik kan nl. ook weer legio verweren verzinnen waarom dit nu wel aan te raden is... ;)
websiteondemand
05/08/11, 15:27
Inderdaad is die discussie al vaker gevoerd. Ik kan nl. ook weer legio verweren verzinnen waarom dit nu wel aan te raden is... ;)
+1 ;)
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.
dreamhost_nl
05/08/11, 20:04
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.
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.
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.
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).
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.
dreamhost_nl
22/08/11, 13:16
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.
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).