Bekijk Volledige Versie : Wat te doen tegen DDoS
Hallo allemaal, ik ben net nieuw hier op dit forum en heb al veel interassante kennis opgedaan.
Ik exploiteer diverse websites die liepen altijd bij yourhosting echter omdat ik meer controle wilde heb ik ze overgeheveld naar deze forum sponsor dus bij FXW op een VPS.
Tot nu toe erg tevreden en na wat tweaks draait mijn Magento shop veel sneller. en is de pageload ergens tussen 1 a 2 seconden.
Een andere site die ik heb en nog bij yourhosting draait ondergaat al vanaf voor 4 oktober een DDoS aanval.
Hierbij wordt steeds een niet bestaand bestand opgevraagd namelijk
http://mijndomein.nl/images/abc.php?crc=123
of
http://mijndomein.nl/images/abc.php?crc=558161692
door vele IP´s uit de hele wereld.
Yourhosting heeft op 12 oktober mijn site offline gezet echter in de logs zag ik al dat ze van voor 4 oktober al bezig zijn (lekker late reactie dus van YH ) verder kan ik niet terugkijken.
Op dit moment is het nog steeds aan de gang.
Er draait daar een webshop met erotische artikelen maar er is door tijdgebrek nog nauwelijks promotie geweest en er zijn nog maar een handvol bestellingen op binnengekomen. De site is dus nog nagenoeg niet bekend. Ook heb ik geen reputatie als DSB bank of stichting Brein.
Ik lees wel meer over DDoS aanvallen maar die duren dan 1 dag of zo.
Dit is toch niet meer normaal.
Ik was van plan deze site ook over te hevelen maar laat hem daar nog maar even de DDoS uitzingen ( wordt toch nog niet echt omzet op gedraaid).
Ik ben dus erg benieuwd naar jullie ervaringen hiermee en wil tevens graag weten of bijvoorbeeld mod_evasive daar enig effect op heeft en misschien zijn er nog wel andere mogelijkheden dit te bestrijden binnen een CentOs VPS omgeving met DirectAdmin.
Ook ben ik benieuwd of er een manier is om de source te achterhalen.
marsipulami
15/10/09, 22:00
Een van de mogelijkheden om het afte weren is wanneer de doelgroep dit toelaat ip's uit "verkeerde" landen te blokkeren. Dat scheelt al direct.
Een andere site die ik heb en nog bij yourhosting draait ondergaat al vanaf voor 4 oktober een DDoS aanval.
Hierbij wordt steeds een niet bestaand bestand opgevraagd namelijk<KNIP>
Ook ben ik benieuwd of er een manier is om de source te achterhalen.
-heb je de domeinnaam al lang?
-Zou het mogelijk zijn dat het legitiem verkeer is naar een oude site?
-Over hoeveel hits heb je het?
-hoeveel traffic/resources gebruikt je 404 page? dat zou erg beperkt moeten zijn.
weet je zeker dat het een ddos aanval betreft? verder duurt zo'n ddos aanval natuurlijk precies zo lang als dat de aanvaller dat wil. Je kunt er niets tegen doen..
-heb je de domeinnaam al lang?
-Zou het mogelijk zijn dat het legitiem verkeer is naar een oude site?
-Over hoeveel hits heb je het?
-hoeveel traffic/resources gebruikt je 404 page? dat zou erg beperkt moeten zijn.
De domeinnaam heb ik al sind begin 2008 en eerst heeft daar een oscommercefork (xtcommerce) gedraaid.
Het is echter een dropship webshop dus ben onlangs overgestapt op Magento omdat deze flexibeler is om the synchen met de XML feed van de leverancier.
De overstap naar Magento was net gemaakt en sindsdien ook nog geen orders op binnengekomen omdat de laatste hand er aan wordt gelegd om de puntjes op de i te krijgen en trok nog nauwelijks bezoekers.
Legitiem verkeer is dus uitgesloten.
Als ik het log bestudeer zijn het ongeveer zo'n 70.000 hits per etmaal zeg maar effe grof gezegd elke seconde 1.
De 404 pagina wordt door Magento dynamisch gegenereerd en is ca 141,4k volgens Yslow in firefox.
@marsipulami
Inderdaad komen de meeste zombies uit azie, brazilië etc ik had dus ook al gedacht alleen toegang te verschaffen voor Nederland en een paar buurlanden zoals de ons omringende landen.
Ik had ook al gedacht dit via htaccess te doen maar weet niet of dat de juiste wijze is. Als ik het log in excel importeer en sorteer op ip adres dan komt de aanvraag van elk IP een keer of 4 a 5. en er is een hele waslijst aan ip adressen.
Is het ook mogelijk om via htaccess een 403 te geven op het opgevraagde bestand? dus ./images/abc.php?
Als ie op je eigen VPS draait, installeer CSF en blokkeer landen gewoon daarin met de landcode, iets makkelijker. Denk niet dat je veel serieuze klanten in amerika gaat vinden in nederlandse erotica webshops.
Wat ik zo lees krijg je veel aanvallen uit Zuid Amerika
Het beste is om CSF te installeren en ook mod_evasive
In CSF kun je complete landen blokkeren maar dat heeft niet altijd nut omdat deze van een lijst gebruikt maakt waar niet alle IP adressen opstaan.
Wat wel helpt is in CSF het CIDR adres blokkeren, hiermee blokkeer je hoofdzakelijk de providers waar de ddos vandaan komt.
Helaas kan CSF nog niet automatisch CIDR blokkeren, je zult de IP adressen uit je logfiles moeten halen en dan het CIDR adres handmatig in de drop moeten gooien.
Ik heb deze oplossing gebruikt bij een server van iemand anders die al meer dan 2 maanden regelmatig onder vuur lag.
Hiervoor had ik van alles geprobeerd en niets was afdoende, het bovenstaande was de oplossing.
De domeinnaam heb ik al sind begin 2008 <KNIP
Legitiem verkeer is dus uitgesloten.
Ok, ik vroeg het voor de zekerheid, bij domeinen overnemen (of herregisteren) kan dit namelijk gewoon dode links zijn.
Als ik het log bestudeer zijn het ongeveer zo'n 70.000 hits per etmaal zeg maar effe grof gezegd elke seconde 1.
De 404 pagina wordt door Magento dynamisch gegenereerd en is ca 141,4k volgens Yslow in firefox.
Dat is best pittig.
Is het ook mogelijk om via htaccess een 403 te geven op het opgevraagde bestand? dus ./images/abc.php?
Dat is zeker mogelijk, via een Files directive:
<Files "abc.php">
Order allow,deny
Deny from all
</Files>
Zie ook:
http://httpd.apache.org/docs/1.3/mod/core.html#files
Dat is zeker mogelijk, via een Files directive:
<Files "abc.php">
Order allow,deny
Deny from all
</Files>
Wat heeft dat verder voor effect op de server? Dit is waarschijnlijk minder belastend voor de server dan een 404 genereren kan ik me zo voorstellen.
Er is trouwens een PDF met handige tips van de overheid op GOVCERT.NL over DDoS voor de geinteresseerden die kunnen het hier downloaden:
http://www.govcert.nl/download.html?f=59
Hierin staat o.a.
Het is onmogelijk om alle IP-spoofing tegen te gaan. Daarom is het noodzakelijk
om de kans op IP-spoofing zoveel mogelijk te verkleinen. Via een aantal antispoofing
mechanismen is het mogelijk om RFC1918 IP-adressen en IP-blokken die
door IANA nog niet zijn uitgedeeld aan een LIR te blokkeren
Ik zie dit soort dingen veel de laatste tijd. Met name dingen als wordpress sites hebben bepaalde bestanden waar soms vanaf heel de wereld naartoe wordt ge-POST. Dat kun je limiten, maar dan gaat de site stuk.
Als je niet wil limiteren of moeilijk wil doen kan je ook gewoon die pagina maken en leeg laten, dan gebruikt het amper resources en wacht je gewoon tot ze het opgeven.
Als je niet wil limiteren of moeilijk wil doen kan je ook gewoon die pagina maken en leeg laten, dan gebruikt het amper resources en wacht je gewoon tot ze het opgeven.
je bedoeld in de map images gewoon een bestand genaamd abc.php en verder leeg laten?
Als je niet wil limiteren of moeilijk wil doen kan je ook gewoon die pagina maken en leeg laten, dan gebruikt het amper resources en wacht je gewoon tot ze het opgeven.
Als ze maar genoeg requests tegelijk doen heeft zelfs dat geen zin meer.. Maar het is wel het proberen waard idd..
je bedoeld in de map images gewoon een bestand genaamd abc.php en verder leeg laten?
Yup
eventueel kan je er een scriptje in zetten wat gelijk het ip (of de range) blokeert op je server met iptables oid
Yup
eventueel kan je er een scriptje in zetten wat gelijk het ip (of de range) blokeert op je server met iptables oid
Vergeet niet als je zo iets doet je eigen ips of nederlandse ips altijd te negeren.
In het verleden heb ik mijzelf (en iedereen) weleens perongelijk geblokeert bij het testen van het script %)
en allow google en andere zoekmachines
en allow google en andere zoekmachines
Is ook wel wenselijk ja ;)
Ik heb nu een map images met daarin een leeg bestand abc.php geplaatst en nu krijg ik een blanco pagina als ik deze vraag.
Is er nog een code snipped die ik er in kan zetten om de ip's waar de aanval vandaan komt bijvoorbeeld een tijd in de wacht te zetten voor een maximum aantal seconden. Of zal ik ze maar redirecten naar de FBI in USA?
Ik heb nu een map images met daarin een leeg bestand abc.php geplaatst en nu krijg ik een blanco pagina als ik deze vraag.
Is er nog een code snipped die ik er in kan zetten om de ip's waar de aanval vandaan komt bijvoorbeeld een tijd in de wacht te zetten voor een maximum aantal seconden. Of zal ik ze maar redirecten naar de FBI in USA?
Je kunt ze laten wachten, maar of je daar blij van moet worden...
<?php
sleep($aantal_seconden);
?>
Redirecten naar de FBI lijkt me niet slim, straks verdenken ze jou van een DDoS op hun site.
Ik heb nu een map images met daarin een leeg bestand abc.php geplaatst en nu krijg ik een blanco pagina als ik deze vraag.
Is er nog een code snipped die ik er in kan zetten om de ip's waar de aanval vandaan komt bijvoorbeeld een tijd in de wacht te zetten voor een maximum aantal seconden. Of zal ik ze maar redirecten naar de FBI in USA?
In de wacht zetten met sleep zou ik niet doen, dat houd ook de connectie van jouw open. Je moet er zo snel mogelijk vanaf.
Ik zou eventueel wel de header connection: close sturen, dan blijft de connectie ook niet open voor nog reen request (keep-alive)
Ik kan je niet zo snel een stukje code geven waarmee je alles kan blokken. Maar in principe zou ik het volgende doen:
- Checken of het IP een IP is wat je wilt blokken (dus alles behalve je eigen IP, NL IP's, Google z'n IP's, etc).
- Als je PHP gebruikt met de functie exec() het commando uitvoeren om het betreffende IP in je firewall te zetten (alle connecties droppen).
Je zult dan in ieder geval niet meer de load op je webserver krijgen (maar op je firewall).
Beter is natuurlijk om met je netwerkprovider te praten en hen laten proberen de DDOS af te slaan.
als je in ieder geval de aanvallende ip's wil loggen dan zou ik dat als volgt doen:
<?php
$fm = "Source: ".$REMOTE_ADDR;
$fp = fopen("log.txt", "a+");
fwrite($fp, $fm.'< br />', 1024);
fclose($fp);
header("Connection: close");
?>
Beter is natuurlijk om met je netwerkprovider te praten en hen laten proberen de DDOS af te slaan.
Een netwerk provider heeft ook niet zoveel opties als een attack van veel verschillende (gespoofde) ips komen
Ik heb nu een map images met daarin een leeg bestand abc.php geplaatst en nu krijg ik een blanco pagina als ik deze vraag.
Is er nog een code snipped die ik er in kan zetten om de ip's waar de aanval vandaan komt bijvoorbeeld een tijd in de wacht te zetten voor een maximum aantal seconden. Of zal ik ze maar redirecten naar de FBI in USA?
<?php
if ($ip = $_SERVER['REMOTE_ADDR']) {
shell_exec('iptables -I INPUT -s '.'-j DROP'
?>
<?php
#undrop: iptables -D INPUT -s <IP> -j DROP
$allow = array(
'127.0.0.1',
'209.85.229.105',
);
if ($ip = @$_SERVER['REMOTE_ADDR'] AND !in_array($ip, $allow)) {
shell_exec('iptables -I INPUT -s '.$ip.' -j DROP');
}
?>
Een netwerk provider heeft ook niet zoveel opties als een attack van veel verschillende (gespoofde) ips komen
Hangt er vanaf welke provider het is natuurlijk, maar meeste providers hebben wel firewalls met IDS/IPS die er al een heel deel kunnen uit filteren. Want op zich maakt het niet veel uit als je het zelf in je firewall zet, want de traffic komt nogaltijd toe op je server. Dus is je probleem niet opgelost maar gewoon van webserver load afgehaald en verplaatst naar je firewall.
IP adressen loggen en kijken of er reeksen bij zitten die bvb van dezelfde ISP afkomstig zijn en dan even een abuse melding bij die provider doen. Want een neen heb je altijd en een ja kan je krijgen.
Inmiddels ben ik er achter dat dit van een virus afkomstig is wat rondwaart en een lijst met websites aanvalt met veel GET requests.
Zie hier de info:
The virus is identified as a worm by several virus scanners.
This virus is identified as:
a-squared 4.5.0.50 2010.02.06 Trojan-Downloader.Win32.Bagle!IK
AntiVir 7.9.1.158 2010.02.05 WORM/Bagle.Gen
Authentium 5.2.0.5 2010.02.06 W32/Themida_Packed!Eldorado
AVG 9.0.0.730 2010.02.06 Win32/Cryptor
BitDefender 7.2 2010.02.06 MemScan:Trojan.Downloader.Bagle.MD
CAT-QuickHeal 10.00 2010.02.06 (Suspicious) - DNAScan
DrWeb 5.0.1.12222 2010.02.06 Trojan.DownLoad.61893
eTrust-Vet 35.2.7286 2010.02.05 Win32/Bagle!generic
F-Prot 4.5.1.85 2010.02.06 W32/Themida_Packed!Eldorado
F-Secure 9.0.15370.0 2010.02.06 MemScan:Trojan.Downloader.Bagle.MD
GData 19 2010.02.06 MemScan:Trojan.Downloader.Bagle.MD
Ikarus T3.1.1.80.0 2010.02.06 Trojan-Downloader.Win32.Bagle
McAfee+Artemis 5884 2010.02.06 Artemis!DCB98E06CE47
McAfee-GW-Edition 6.8.5 2010.02.06 Heuristic.LooksLike.Win32.Suspicious.K
Panda 10.0.2.2 2010.02.06 Trj/CI.A
Prevx 3.0 2010.02.06 Medium Risk Malware
Sophos 4.50.0 2010.02.06 Mal/Generic-A
For your reference see ths info on comodo.com : http://camas.comodo.com/cgi-bin/submit?file=b537e9f01fecb18f4af43f65371427c295c980 bbd5881748a18fd51cbcece6b3&iframe=
Ik heb inmiddels Fail2Ban geïnstalleerd en deze haalt uit de logs perfect het IP en zet deze dan in iptables
Het enige nadeel wat er nog aan kleeft in dat het de apache access logs vervuilt maar ik zal eens kijken of ik deze kan filteren met dontlog in apache
marsipulami
03/07/10, 19:28
wauw en dat binnen het jaar. gefeliciteerd.
ik neem aan dat met een beetje inzet je dat virus wel eerder had kunnen vinden.?
wauw en dat binnen het jaar. gefeliciteerd.
ik neem aan dat met een beetje inzet je dat virus wel eerder had kunnen vinden.?
Nou niet echt nee. Door het beperkt aantal sites die de target zijn is er verder niet veel over geschreven. Regelmatig heb ik zoekopdrachten op internet uitgevoerd voor info maar pas recent kwam ik het bericht op comodo.com tegen en zag ik de lijst twee van onze sites staan.
Doordat we de opgevraagde bestanden ooit hebben aangemaakt met een leeg php bestand is de serverload te verwaarlozen en is het hoogstens irritant dat logbestanden worden vervuild en zijn we recent eens aan het experimenteren gegaan met Fail2Ban die overigens perfect werkt. Jammer dat Fail2Ban nog geen auto abuse email naar de netbeheerder kan sturen.
Ik verrmoed overigens dat het geval is ontstaan na dat tot 2 keer toen de shared server die we eerst bij Yourhosting hadden was gehackt. Dit was de reden over te stappen naar een Dedicated Server ook omdat regelmatig de Server bij Yourhosting plat lag door allerlei aanvallen.