Bekijk Volledige Versie : DDOS aanval maar krijg het niet gestopt.
Hallo,
Ik noem het ddos maar weet niet of jehet zo moet noemen?
Ik probeer het te stoppen en het komt vanaf 1 ip.
Er komt flink wat data op de server af, al flink wat GB's
Ik probeer het te stoppen via iptables.
Dit heb ik gedaan in de iptables:
iptables -A INPUT -s 109.230.245.** -j DROP
Maar de aanval gaat gewoon door? Klopt het wat hier bovenstaat?
En kan ik nog iets anders doen?
patrickekkel
18/12/11, 22:45
iptables -A INPUT -s IP-ADDRESS -j DROP
Mocht dat niet helpen dan kan je je hoster
Altijd vragen om dat ip te null routen
Hoeveel verkeer komt er binnen, wat voor verkeer komt er binnen?
Ik wil best wel helpen, maar te weinig info.
crossplatform
18/12/11, 23:00
Het verkeer zit al in het netwerk. Dat jij een firewall rule hiervoor heb geconfigureerd is prima, maar daarmee stop je het verkeer niet.
Je provider moet dus een blokkade zetten op het IP adres wat de aanval uitvoert.
Op die manier kom je er van af.
Wat het is kan ik niet zien.
Het zijn kleine packetje die binnen komen over verschillende poorten achter elkaar.
En het is toch nu wel al zo'n 600 gig.
Provider heb ik ook een ticket gestuurd
Yourwebhoster
18/12/11, 23:04
Het verkeer zit al in het netwerk. Dat jij een firewall rule hiervoor heb geconfigureerd is prima, maar daarmee stop je het verkeer niet.
Je provider moet dus een blokkade zetten op het IP adres wat de aanval uitvoert.
Op die manier kom je er van af.
Om het nog beter toe te lichten: Het verkeer zal ook na iptables naar je server gestuurd worden maar met iptables zorg je er voor dat verder niks met dat verkeer gedaan kan worden. Mocht je het verkeer naar je server willen stoppen vanaf dat IP dan zal je bij je netwerk/colo/server boer moeten zijn om te vragen of dat IP genullrouted kan worden.
Wat is overigens veel verkeer (vele GB's maar in welke tijdspanne) en om wat voor verkeer gaat het?
Wat het precies weet ik niet.
En het is begonnen vanacht om 2.39.
Normaal heb ik per maand maar 100 tot 150 gig vebruik.
Dus 600 in 1 dag is VEEL voor mij.
# ip route add blackhole $IP
is wat minder belastend voor de server dan via IP-tables. Als je meer IPs te blocken hebt, of een subnet wilt blocken kan dat ook via zo een nullroute (net als met IP tables btw).
Yourwebhoster
18/12/11, 23:14
Wat het precies weet ik niet.
En het is begonnen vanacht om 2.39.
Normaal heb ik per maand maar 100 tot 150 gig vebruik.
Dus 600 in 1 dag is VEEL voor mij.
Dan is dat inderdaad een verschil. Weet je om wat voor verkeer het gaat (inkomend neem ik aan, maar naar welke poort?).
O ja, een subnet block je niet met twee wildcards ** toch (of probeer je het IP anoniem te houden?)? beter 109.230.245.0/24 gebruiken. In ieder geval moet het verkeer meteen weg zijn. Zo niet, zit er een fout in de regel.
Ja idd denk plaats niet gelijk het IP hier.
Het gaat naar poort 7778. Dat is een query poort van een Unrealtournament 99.
Die heb ik inmiddels uit gezet en de user waar die onder draaide ook verwijderd.
Maar het gaat gewoon door op die poort.
Ook als ik de server op de switch aan en uit heb gedaan.
Yourwebhoster
18/12/11, 23:30
Ja idd denk plaats niet gelijk het IP hier.
Het gaat naar poort 7778. Dat is een query poort van een Unrealtournament 99.
Die heb ik inmiddels uit gezet en de user waar die onder draaide ook verwijderd.
Maar het gaat gewoon door op die poort.
Ook als ik de server op de switch aan en uit heb gedaan.
Switch poort aan en uit zetten zal niet helpen, als je op netwerk niveau iets wilt doen dan gaat het toch echt null routen worden.
Ja ik wacht nu op antwoord op me ticket.
Ik heb de server offline gehaald op dit moment.
HostingTotaal
19/12/11, 08:40
zou idd zsm contact leggen met de provider, als die het ip (zoals hierboven gezegd mara dan in andere bewoordingenen denk ik) het netwerk niet binnenkomt heb je er zelf pas geen last meer van. De provider zelf kan het ip dan desnoods ook bij de transit providers laten blokkeren zodat ook zij er zelf geen hinder meer van hebben!
marsipulami
19/12/11, 09:16
Voorgaande antwoorden helpen je eerst wel even verder, maar het antwoord op deze vraag:
Ik noem het ddos maar weet niet of jehet zo moet noemen?
is, nee.
De eerste "d" bij ddos staat voor "distributed" en geeft aan dat de aanval vanaf meerdere locaties komt.
In dit geval lijkt het dus te gaan om een "normale" denial of service aanval.
Als provider kan je de specifieke IP in een null-route gooien, dan komt het verkeer niet meer van / naar je server voor dat IP.
Het is wel zaak dat je even vraagt bij de provider waar het vandaan komt of hun die klant kunnen aanspreken. Hiervoor is het wel handig om fw logs etc mee te sturen.. of een netflow/sflow nfdump export. Een beetje ISP kan je die zo aanleveren op verzoek.
Hey allen,
Even een update.
De Coloprovider heeft het ip adres vanmorgen in een null-route gegooid.
Dus het is weer rustig op de server.
Hopelijk is het hierbij klaar, of die clown komt straks met een ander ip langs.
Maar dat zien we dan wel weer.
En oja die gast aanmelden bij z'n provider, het word mij niet duidelijk waar het ip van is.
Misschien iemand anders een idee?? IP> 109.230.245.206.
Met whowis kom ik alleen bij een wazige site uit.
https://apps.db.ripe.net/search/query.html?searchtext=109.230.245.206&search%3AdoSearch=Search#resultsAnchor
Het abuse adres is niet in gebruik.
Hey allen,
Even een update.
De Coloprovider heeft het ip adres vanmorgen in een null-route gegooid.
Dus het is weer rustig op de server.
Hopelijk is het hierbij klaar, of die clown komt straks met een ander ip langs.
Maar dat zien we dan wel weer.
En oja die gast aanmelden bij z'n provider, het word mij niet duidelijk waar het ip van is.
Misschien iemand anders een idee?? IP> 109.230.245.206.
Met whowis kom ik alleen bij een wazige site uit.
https://apps.db.ripe.net/search/query.html?searchtext=109.230.245.206&search%3AdoSearch=Search#resultsAnchor
Het abuse adres is niet in gebruik.
Dat lijkt inderdaad normaal, maar als je kijkt op www.exetel.de (genoemd wordt abuse@exetel.de voor deze IP reeks) zie je een template website met lorem ipsum .
Maar de betreffende route heeft AS197043 als origin (32 bits AS nummer nu in productie...) . De route is wel actief en heeft inderdaad dat AS als origin.
Het abuse contact voor AS197043 is
remarks: -- please report spam/abuse to abuse@optimate-server.de -
remarks: ----- reports to other addresses won't be processed -----
Deze site lijkt wel gebruikt te worden. Ik zou dus abuse@optimate-server.de contacteren.
Bedenk wel dat een DoS ook gespoofed kan zijn, waarbij dit netwerk dan niet werkelijk de bron is. Aan de andere kant, zo'n verlaten ogende website (exetel.de) kan natuurlijk gehacked zijn en gewoon de werkelijke bron.
Oke bedankt,
Ik zal de mail naar dat e-mail adres toesturen.
dennis0162
20/12/11, 08:25
Dat lijkt inderdaad normaal, maar als je kijkt op www.exetel.de (genoemd wordt abuse@exetel.de voor deze IP reeks) zie je een template website met lorem ipsum .
Maar de betreffende route heeft AS197043 als origin (32 bits AS nummer nu in productie...) . De route is wel actief en heeft inderdaad dat AS als origin.
Het abuse contact voor AS197043 is
remarks: -- please report spam/abuse to abuse@optimate-server.de -
remarks: ----- reports to other addresses won't be processed -----
Deze site lijkt wel gebruikt te worden. Ik zou dus abuse@optimate-server.de contacteren.
Bedenk wel dat een DoS ook gespoofed kan zijn, waarbij dit netwerk dan niet werkelijk de bron is. Aan de andere kant, zo'n verlaten ogende website (exetel.de) kan natuurlijk gehacked zijn en gewoon de werkelijke bron.
De bedrijfsnaam lijkt wel op het Nederlandse Ecatel (grote Spamhoster).
dreamhost_nl
20/12/11, 13:39
De bedrijfsnaam lijkt wel op het Nederlandse Ecatel (grote Spamhoster).
Hier zeker ook geen fan van Ecat#l/link#p, maar dat is wel erg kort door de bocht om dat direct aan te nemen.
Daar was ik weer even.
Ik heb toch even getest met de ip ban, en nu kom ik er achter dat het niet lijkt te werken.
Ik heb me zelf ook even in de iptables gezet, maar wat blijkt ik kom overal gewoon bij.
Deze config staat nu erbij in Iptables:
-A INPUT -s 109.230.245.206 -j DROP
-A INPUT -s 77.BEN.IK.147 -j DROP
Ik restart in webmin (NOOB) op het moment want ik word er niet wijs uit hoe nu de iptables in console te restarten.(Apply Configuration)
Ik heb 2 servers draaien, 1 met debian lenny en 1 met debian squeeze.
Op beide servers lukt het me niet
Het rare is al ik bijvoorbeeld poort 21 uit de iptables haal en restart (Apply Configuration) in webmin kom ik dus niet meer in mijn ftp server. Zoals het hoort.
Maar met een ip droppen werkt dat dus niet, kom gewoon overal bij ssh ftp web enz.
Daar was ik weer even.
Ik heb toch even getest met de ip ban, en nu kom ik er achter dat het niet lijkt te werken.
Ik heb me zelf ook even in de iptables gezet, maar wat blijkt ik kom overal gewoon bij.
Deze config staat nu erbij in Iptables:
-A INPUT -s 109.230.245.206 -j DROP
-A INPUT -s 77.BEN.IK.147 -j DROP
Ik restart in webmin (NOOB) op het moment want ik word er niet wijs uit hoe nu de iptables in console te restarten.(Apply Configuration)
Ik heb 2 servers draaien, 1 met debian lenny en 1 met debian squeeze.
Op beide servers lukt het me niet
Het rare is al ik bijvoorbeeld poort 21 uit de iptables haal en restart (Apply Configuration) in webmin kom ik dus niet meer in mijn ftp server. Zoals het hoort.
Maar met een ip droppen werkt dat dus niet, kom gewoon overal bij ssh ftp web enz.
Het moet wel zo werken, maar misschien dat vooraan in de iptables config een expliciete permit staat, om te voorkomen dat mensen zichzelf ophangen wanneer ze alle admin (of alle) toegang afsluiten.
Op de commandline, als root :
iptables -nvL
laat alle huidige iptables regels zien.
Kijk daar goed door alle regels om te zien of de drop regel die je hebt opgegeven er goed in staat, en of niet verkeer wat je wilt laten droppen door een eerdere regel ge-permit wordt.
Voor de plek waar iptables gestart/herstart kan worden,
cd /etc/rc3.d
ls (of grep iptables *) en kijk door welk startup script iptables gezet wordt.
(eventueel ook in /etc/rc5.d kijken, als runlevel 5 de default mocht zijn).
Het zou nog kunnen dat iptables via-via gestart wordt, maar kijken in de rcx.d directory is wel de handigste manier om te starten.
Zo zie ik mij ip staan in via command iptables -nvL
0 0 DROP all -- * * 77.251.4.147 0.0.0.0/0
In geen enkele rcx.d zie ik iets staan van iptables/firewall
Zo zie ik mij ip staan in via command iptables -nvL
0 0 DROP all -- * * 77.251.4.147 0.0.0.0/0
In geen enkele rcx.d zie ik iets staan van iptables/firewall
Er zijn ook geen hits op die regel ( de 0 0 zijn packets en bytes die gematched hebben)
Maar je laat alleen die regel zien, en mijn vraag/idee is dus dat voor (boven) die regel het verkeer al geaccepteerd is, of naar een andere chain gestuurd is.
dennis0162
21/12/11, 22:35
Hier zeker ook geen fan van Ecat#l/link#p, maar dat is wel erg kort door de bocht om dat direct aan te nemen.
Ik zeg toch ook nergens dat het Ecatel is.
Er zijn ook geen hits op die regel ( de 0 0 zijn packets en bytes die gematched hebben)
Maar je laat alleen die regel zien, en mijn vraag/idee is dus dat voor (boven) die regel het verkeer al geaccepteerd is, of naar een andere chain gestuurd is.
Ik zal zo even alles pasten!
# Generated by iptables-save v1.4.2 on Fri Feb 19 15:46:21 2010
*nat
:PREROUTING ACCEPT [14:1710]
:POSTROUTING ACCEPT [1:286]
:OUTPUT ACCEPT [1:286]
COMMIT
# Completed on Fri Feb 19 15:46:21 2010
# Generated by iptables-save v1.4.2 on Fri Feb 19 15:46:21 2010
*mangle
:PREROUTING ACCEPT [34:2495]
:INPUT ACCEPT [34:2495]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [33:4887]
:POSTROUTING ACCEPT [33:4887]
COMMIT
# Completed on Fri Feb 19 15:46:21 2010
# Generated by iptables-save v1.4.2 on Fri Feb 19 15:46:21 2010
*filter
:FORWARD ACCEPT [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
# Accept traffic from internal interfaces
-A INPUT ! -i eth0 -j ACCEPT
# Accept traffic with the ACK flag set
-A INPUT -p tcp -m tcp --tcp-flags ACK ACK -j ACCEPT
# Allow incoming data that is part of a connection we established
-A INPUT -m state --state ESTABLISHED -j ACCEPT
# Allow data that is related to existing connections
-A INPUT -m state --state RELATED -j ACCEPT
# Accept responses to DNS queries
-A INPUT -p udp -m udp --dport 1024:65535 --sport 53 -j ACCEPT
# Accept responses to our pings
-A INPUT -p icmp -m icmp --icmp-type echo-reply -j ACCEPT
# Accept notifications of unreachable hosts
-A INPUT -p icmp -m icmp --icmp-type destination-unreachable -j ACCEPT
# Accept notifications to reduce sending speed
-A INPUT -p icmp -m icmp --icmp-type source-quench -j ACCEPT
# Accept notifications of lost packets
-A INPUT -p icmp -m icmp --icmp-type time-exceeded -j ACCEPT
# Accept notifications of protocol problems
-A INPUT -p icmp -m icmp --icmp-type parameter-problem -j ACCEPT
# webmin
-A INPUT -p tcp -m tcp -m multiport -j ACCEPT --dports 15050,22
# Allow connections to our IDENT server
-A INPUT -p tcp -m tcp --dport auth -j ACCEPT
# Respond to pings
-A INPUT -p icmp -m icmp --icmp-type echo-request -j ACCEPT
# webmin en FTP en web
-A INPUT -p tcp -m tcp -m multiport -j ACCEPT --dports 10000,21,80
# FTP
-A INPUT -p tcp -m tcp --dport 49152:49162 -j ACCEPT
# TEAMSPEAK
-A INPUT -p tcp -m tcp -m multiport -j ACCEPT --dports 9987,9988,10011,30033
# ban test
-A INPUT -s 77.mijn.ip.147 -j DROP
COMMIT
# Completed on Fri Feb 19 15:46:21 2010
Bijdeze.
# webmin
-A INPUT -p tcp -m tcp -m multiport -j ACCEPT --dports 15050,22
..# webmin en FTP en web
-A INPUT -p tcp -m tcp -m multiport -j ACCEPT --dports 10000,21,80
# ban test
-A INPUT -s 77.mijn.ip.147 -j DROP
Bijdeze.
Daar zie je min of meer precies staan wat ik zei :
Eerst wordt alle SSH (en tcp/15050, webmin) verkeer geaccepteerd, en pas daarna wordt verkeer van jouw IP gedropt.
iptables werkt de regels in volgorde af, en de eerste match telt.
Dus met deze rulebase is het logisch dat je ssh verkeer niet gedropt wordt.
(noch ander verkeer wat geaccepteerd werd boven de drop regel).
Om je ban effectiever te maken moet je 'm als _eerste_ regel opnemen, zolang je zeker bent dat je er nog op een andere manier goed bij kunt.
met iptables -nvL moet je ook de counters voor de andere regels, die wel matchen, met oplopende waarden zien (paar keer iptables -nvL achter elkaar).
Jeetje dat wist ik niet..
Dat werkt dus.
Ik heb ff iemand anders gebant ( vriend) en die komt nergens meer bij.
Ik heb de ban nu onder de eerste regel staan, is dit ook goed?
# Accept traffic from internal interfaces
-A INPUT ! -i eth0 -j ACCEPT
# BAN
-A INPUT -s 109.230.245.206 -j DROP
# Accept traffic with the ACK flag set
-A INPUT -p tcp -m tcp --tcp-flags ACK ACK -j ACCEPT
# Allow incoming data that is part of a connection we established
-A INPUT -m state --state ESTABLISHED -j ACCEPT
# Allow data that is related to existing connections
-A INPUT -m state --state RELATED -j ACCEPT
# Accept responses to DNS queries
Jeetje dat wist ik niet..
Dat werkt dus.
Ik heb ff iemand anders gebant ( vriend) en die komt nergens meer bij.
Ik heb de ban nu onder de eerste regel staan, is dit ook goed?
Ja, dat is ook goed.
Uiteindelijk is het zo dat de eerste match (accept of drop) genomen wordt .
De eerste regel in je voorbeeld accepteert alle verkeer van alle interfaces _behalve_ eth0 .
Zolang je verkeer van "buiten" alleen over eth0 binnenkomt heb je geen last van die regel.
Je moet met die drop regel alleen oppassen dat je niet per ongeluk jezelf afsluit ("drop alles van alles") want dan kom je er alleen via een console/ilo/ipmi nog bij.
Wat je nog zou kunnen doen is als tweede regel die webmin en ssh toegang expliciet toestaan voor een paar van jouw (thuis, werk, umts reeks van je telco, evt nog een colo bak van een vriend) ip adressen , en drop regels pas daarna doen.
Als je iets fout doet kun je het dan zelf nog herstellen.
Verder zou ik uberhaupt "management vanaf de hele wereld toestaan" niet doen als je het niet echt nodig hebt.
Ja daar heb je gelijk in.
Ik zal dat inderdaad gaan doen.
Ik moet wel oppassen daarmee, want ik heb upc en mijn ip wil eens in de zoveel tijd nog wel is veranderen.
Ik heb wel een kennis die een vast ip heeft, die zal ik er dan ook in zetten.
En in het ergste geval moet ik na de server toe, 10 min ritje met de auto.
Maar in ieder geval bedankt voor de hulp op dit onderwerp.