Vraag Ik ben onder DDoS. Wat kan ik doen?


Dit is een Canonical Question over DoS en DDoS-mitigatie.

Ik vond een enorme verkeerspiek op een website die ik vandaag host; Ik krijg duizenden verbindingen per seconde en ik zie dat ik alle 100 Mbps van mijn beschikbare bandbreedte gebruik. Niemand heeft toegang tot mijn site omdat alle time-outs van de aanvraag verlopen en ik kan me zelfs niet aanmelden bij de server omdat SSH ook een time-out krijgt! Dit is al een paar keer eerder gebeurd en elke keer heeft het een paar uur geduurd en is het alleen gegaan.

Af en toe heeft mijn website nog een ander, maar gerelateerd probleem: het server gemiddelde van mijn server (meestal rond .25), raketten tot 20 of meer en niemand heeft toegang tot mijn site, net als het andere geval. Het verdwijnt ook na een paar uur.

Het herstarten van mijn server helpt niet; wat kan ik doen om mijn site weer toegankelijk te maken en wat is er aan de hand?

Ik merkte eens dat ik voor een dag of twee elke keer dat ik mijn service startte een verbinding kreeg van een bepaald IP-adres en vervolgens crashte. Zodra ik het opnieuw opstartte, gebeurde dit opnieuw en het crashte opnieuw. Hoe is dat vergelijkbaar, en wat kan ik eraan doen?


171
2017-08-19 09:14


oorsprong


Ik volgde dit na het lezen (Het creëren van een canonieke "Help, ik krijg DDOS-ed!" Vraag?). Wil ik gewoon Nice Work zeggen !!! - AngryWombat
Zie ook security.stackexchange.com/a/792/2379 - Pacerier


antwoorden:


Je ervaart een Denial of Service-aanval. Als u verkeer van meerdere netwerken ziet (verschillende IP's op verschillende subnetten), hebt u een gedistribueerde denial of service (DDoS); als het allemaal van dezelfde plaats komt, heb je een eenvoudige oude DoS. Het kan handig zijn om te controleren of u in staat bent; gebruik netstat om te controleren. Dit is misschien moeilijk om te doen.

Denial of service valt meestal in een paar categorieën: op verkeer gebaseerd en op belasting gebaseerd. Het laatste item (met de crashende service) is DoS op uitbanningbasis en is heel anders.

Als u probeert vast te stellen welk type aanval plaatsvindt, wilt u mogelijk wat verkeer vastleggen (met wireshark, tcpdump of libpcap). Je moet, indien mogelijk, maar ook bewust zijn dat je waarschijnlijk behoorlijk veel verkeer zult vastleggen.

Zo vaak als niet, zullen deze afkomstig zijn van botnets (netwerken van gecompromitteerde hosts onder de centrale controle van een of andere aanvaller, wiens biedingen ze zullen doen). Dit is een goede manier voor de aanvaller om (zeer goedkoop) de stroomopwaartse bandbreedte van veel verschillende hosts op verschillende netwerken te verwerven om je aan te vallen, terwijl ze hun sporen afdekken. De Low Orbit Ion Cannon is een voorbeeld van een botnet (ondanks dat het vrijwillig is in plaats van malware); Zeus is een meer typische.

Traffic-gebaseerde

Als je onder een verkeer gebaseerde DoS zit, vind je dat er is zoveel verkeer naar uw server komen dat de verbinding met internet volledig is verzadigd. Er is een hoog pakketverliespercentage bij het pingen van uw server van elders, en (afhankelijk van de gebruikte routeringsmethoden) ziet u soms ook een hoge latentie (de ping is hoog). Dit soort aanvallen is meestal een DDoS.

Hoewel dit echt een "luide" aanval is, en het is duidelijk wat er gaande is, is het voor een serverbeheerder moeilijk om te verhelpen (en in principe onmogelijk voor een gebruiker van shared hosting om te beperken). Je hebt hulp nodig van je ISP; laat hen weten dat je onder een DDoS staat en misschien kunnen ze helpen.

De meeste ISP's en doorvoerders zullen echter proactief beseffen wat er gaande is en een a publiceren Blackhole-route voor je server. Wat dit betekent is dat ze een route naar uw server publiceren met zo weinig mogelijk kosten, via 0.0.0.0: ze zorgen ervoor dat verkeer naar uw server niet meer routeerbaar is op internet. Deze routes zijn meestal / 32s en worden uiteindelijk verwijderd. Dit helpt je helemaal niet; het doel is om het netwerk van de ISP te beschermen tegen de zondvloed. Gedurende de duur verliest uw server effectief de internettoegang.

De enige manier waarop uw ISP (of u, als u uw eigen AS hebt) in staat zal zijn om te helpen, is als zij intelligente traffic shapers gebruiken die waarschijnlijk DDoS-verkeer kunnen detecteren en snelheidsbeperkend kunnen maken. Niet iedereen heeft deze technologie. Als het verkeer echter afkomstig is van een of twee netwerken of één host, kunnen ze mogelijk ook het verkeer voor u blokkeren.

Kortom, er is heel weinig wat je kunt doen over dit probleem. De beste oplossing voor de lange termijn is om uw services op veel verschillende locaties op internet te hosten die DDoSed afzonderlijk en tegelijkertijd zouden moeten zijn, waardoor de DDoS veel duurder wordt. Strategieën hiervoor zijn afhankelijk van de service die u moet beschermen; DNS kan worden beveiligd met meerdere gezaghebbende nameservers, SMTP met back-up MX-records en mail exchangers en HTTP met round-robin DNS of multihoming (maar sommige degradatie is sowieso al merkbaar voor de duur).

Load balancers zijn zelden een effectieve oplossing voor dit probleem, omdat de load balancer zelf aan hetzelfde probleem onderhevig is en slechts een bottleneck creëert. IPTables of andere firewall-regels zullen niet helpen omdat het probleem is dat je pijp verzadigd is. Zodra de verbindingen door uw firewall worden gezien, is het al te laat; de bandbreedte op uw site is verbruikt. Het maakt niet uit wat je doet met de verbindingen; de aanval wordt gematigd of beëindigd wanneer de hoeveelheid binnenkomend verkeer weer normaal wordt.

Als u dit kunt doen, overweeg dan om a te gebruiken inhoud distributienetwerk (CDN) zoals Akamai, Limelight en CDN77, of gebruik een DDoS scrubbing-service zoals CloudFlare of Prolexic. Deze services nemen actieve maatregelen om dit soort aanvallen te beperken, en hebben ook zoveel beschikbare bandbreedte op zoveel verschillende plaatsen dat overstromingen over het algemeen niet haalbaar zijn.

Als u besluit CloudFlare te gebruiken (of een andere CDN / proxy), vergeet dan niet het IP-adres van uw server te verbergen. Als een aanvaller het IP-adres te weten komt, kan hij opnieuw DDoS rechtstreeks op uw server plaatsen, zonder CloudFlare te omzeilen. Om het IP-adres te verbergen, moet uw server nooit rechtstreeks communiceren met andere servers / gebruikers, tenzij deze veilig zijn. Uw server moet bijvoorbeeld geen e-mails rechtstreeks naar gebruikers verzenden. Dit is niet van toepassing als u al uw inhoud op het CDN host en er geen eigen server voor heeft.

Ook zijn sommige VPS- en hostingproviders beter in het verzachten van deze aanvallen dan anderen. Over het algemeen zullen ze groter zijn naarmate ze groter zijn; een provider die erg goed wordt bekeken en veel bandbreedte heeft, is van nature veerkrachtiger en een provider met een actief en volledig bemand netwerkteam kan sneller reageren.

Load-gebaseerde

Wanneer u een load-based DDoS ervaart, merkt u dat de gemiddelde belasting is abnormaal hoog (of CPU-, RAM- of schijfgebruik, afhankelijk van uw platform en de specificaties). Hoewel de server niets nuttigs lijkt te doen, is het erg druk. Vaak zijn er grote hoeveelheden vermeldingen in de logboeken die wijzen op ongebruikelijke omstandigheden. Vaker wel dan niet komt dit van veel verschillende plaatsen en is het een DDoS, maar dat is niet noodzakelijk het geval. Er hoeven niet eens veel verschillende hosts te zijn.

Deze aanval is gebaseerd op het doen van veel dure dingen met je service. Dit kan zoiets zijn als het openen van een gigantisch aantal TCP-verbindingen en het dwingen je om de status voor hen te behouden, of het overdragen van buitensporig grote of talrijke bestanden aan je service, of misschien het doen van erg dure zoekopdrachten, of echt iets doen dat duur is om te verwerken. Het verkeer is binnen de grenzen van wat je hebt gepland en kunt aannemen, maar de typen verzoeken die worden gedaan, zijn te duur om zoveel te verwerken.

Ten eerste, dat dit soort aanvallen mogelijk is, is vaak een aanwijzing voor a configuratie probleem of bug in uw dienst. U hebt bijvoorbeeld overdreven uitgebreide logboekregistratie ingeschakeld en slaat mogelijk logboeken op iets dat erg traag is om naar te schrijven. Als iemand dit beseft en veel dingen doet waardoor je grote hoeveelheden logboeken op schijf kunt schrijven, zal je server traag worden. Uw software kan ook iets extreem inefficiënt doen voor bepaalde invoergevallen; de oorzaken zijn net zo talrijk als er programma's zijn, maar twee voorbeelden zijn een situatie die ervoor zorgt dat je service een sessie die anders is voltooid, niet sluit en een situatie veroorzaakt waardoor een kindproces wordt gestart en wordt verlaten. Als je tienduizenden open connecties krijgt met de staat om bij te houden, of tienduizenden kindprocessen, kom je in de problemen.

Het eerste dat je zou kunnen doen is gebruik een firewall om het verkeer te laten vallen. Dit is niet altijd mogelijk, maar als er een kenmerk is dat u kunt vinden in het inkomende verkeer (tcpdump kan hier handig voor zijn als het verkeer licht is), kunt u het bij de firewall neerzetten en het zal niet langer problemen veroorzaken. Het andere wat u moet doen, is de fout in uw service oplossen (neem contact op met de leverancier en wees voorbereid op een lange ondersteuningservaring).

Echter, als het een configuratieprobleem is, begin daar dan. Zet het loggen op productiesystemen op een redelijk niveau (afhankelijk van het programma is dit meestal de standaardinstelling, en het gaat er meestal om ervoor te zorgen dat de "debug" en "breedsprakig" niveaus van loggen uitgeschakeld zijn; als alles wat een gebruiker doet precies is ingelogd fijne details, je logboekregistratie is te uitgebreid). Bovendien, controleer het kindproces en vraag limieten aan, mogelijk smoorklep inkomende verzoeken, verbindingen per IP en het aantal toegestane onderliggende processen, indien van toepassing.

Het is vanzelfsprekend dat hoe beter uw server is geconfigureerd en hoe beter uw server is, des te moeilijker dit type aanval zal zijn. Vermijd gierig te zijn met RAM en CPU in het bijzonder. Zorg ervoor dat uw verbindingen met zaken als backend-databases en schijfopslag snel en betrouwbaar zijn.

Exploit-gebaseerde

Als je service op mysterieuze wijze crasht extreem snel nadat je bent opgevoed, vooral als je een patroon van verzoeken kunt instellen dat voorafgaat aan de crash en het verzoek atypisch is of niet overeenkomt met de verwachte gebruikspatronen, heb je mogelijk een op exploits gebaseerde DoS. Dit kan van zo weinig zijn als slechts één host (met vrijwel elk type internetverbinding), of veel hosts.

Dit is vergelijkbaar met een load-based DoS in veel opzichten, en heeft in principe dezelfde oorzaken en matigingen. Het verschil is alleen dat in dit geval de bug niet veroorzaakt dat uw server verspillend is, maar doodgaat. De aanvaller gebruikt meestal een beveiligingslek op afstand, zoals onleesbare invoer die een nulverwijzing of iets in uw dienst veroorzaakt.

Behandel dit op dezelfde manier als een ongeautoriseerde toegangsaanval op afstand. brandmuur tegen de oorspronkelijke hosts en het type verkeer als ze kunnen worden vastgezet. Gebruik validerende reverse proxies indien toepasselijk. Verzamel forensisch bewijsmateriaal (probeer een deel van het verkeer vast te leggen), dien een bugticket bij de leverancier in en overweeg om ook een klacht over misbruik (of een juridische klacht) tegen de herkomst in te dienen.

Deze aanvallen zijn redelijk goedkoop om op te zetten, als er een exploit kan worden gevonden, en ze kunnen heel krachtig zijn, maar ook relatief gemakkelijk op te sporen en te stoppen. Echter, technieken die nuttig zijn tegen DDoS op basis van verkeer zijn over het algemeen nutteloos tegen op uitbuiting gebaseerde DoS.


183
2017-08-19 09:14



Wat betreft je laatste alinea, En wat als je op uitbuiters gebaseerde informatie krijgt D DoS? Hoe kon je het opsporen en stoppen? - Pacerier


Als je een onderneming bent, heb je veel opties. Als je een klein mannetje bent zoals ik, een VPS of een dedicated server huurt om een ​​kleine website te bedienen, kunnen kosten snel onbetaalbaar worden.

Uit mijn ervaring denk ik dat de meeste toegewijde en VPS-providers geen speciale firewallregels alleen voor uw server instellen. Maar tegenwoordig heb je een paar opties.

CDN

Als je een webserver draait, overweeg dan om hem achter een CDN zoals CloudFlare of Amazon CloudFront te plaatsen.

CDN's zijn duur. Om kosten onder controle te houden, dient u grote bestanden (grote afbeeldingen, audio, video) direct vanaf uw server in plaats van via het CDN. Dit kan echter het IP-adres van uw server blootstellen aan aanvallers.

Private Cloud

Private clouds zijn meestal dure bedrijfsoplossingen, maar Amazon VPC kost bijna niets om in te zetten. De bandbreedte van Amazon is over het algemeen echter duur. Als je dat kunt betalen, kun je de beveiligingsgroep en de ACL van Amazon VPC instellen om verkeer te blokkeren voordat het bij je instantie aankomt. U moet alle poorten behalve uw TCP-serverpoort blokkeren.

Merk op dat een aanvaller je TCP-serverpoort nog steeds kan aanvallen. Als het een webserver is, overweeg dan iets als nginx te gebruiken dat niet-blokkerende IO gebruikt en een groot aantal verbindingen aankan. Buiten dat is er niet veel dat u kunt doen naast ervoor zorgen dat u de nieuwste versie van de serversoftware gebruikt.

Wanneer uw TCP-poort is aangevallen en anders niet werkt

Dit is een oplossing die ik heb ontwikkeld die van toepassing is op niet-webservers die zich niet achter een CDN kunnen verbergen, zoals WebSocket, mediacontent / streaming-servers. CloudFlare ondersteunt WebSocket, maar alleen voor ondernemingen op dit moment.

Het doel is om uw TCP-luisterpoort snel genoeg te veranderen dat een botnet het niet bij kan houden, zeg eens in de tien seconden. Dit wordt bereikt met behulp van een eenvoudig proxyprogramma dat poortroaming uitvoert. De reeks poorten is pseudo-willekeurig, maar moet gebaseerd zijn op de servertijd. En het algoritme voor het berekenen van de servertijd & -poort moet verborgen zijn in de javascript / flash-code van uw klant. Het programma zou ook de firewall moeten aanpassen als het de luisterpoort verandert, en de firewall moet stateful zijn. Als iemand geïnteresseerd is, upload ik mijn node.js-script dat met Amazon werkt naar GitHub.


6
2017-12-05 18:04





Wijzig uw domein om voor een korte periode naar een zwart gat zoals 0.0.0.0 te gaan.

Neem contact op met uw server en kijk of ze u een ander IP-adres kunnen geven als een tijdelijke manier om toegang tot de server te krijgen of kijk of de server externe consoletoegang heeft (zoals u ervoor zit). Hier kunt u zien of het een enkel IP-adres is en blokkeer het van de site of een gedistribueerde aanval.


3
2018-02-26 07:44



Zo'n DNS veranderen doet waarschijnlijk meer kwaad dan goed. In eerste instantie zou ik de TTL van het A-record verlagen, maar het IP-adres ongewijzigd laten - totdat ik een nieuw IP-adres heb om ernaar te verwijzen. - kasperd


Wanneer je onder DDoS bent aangevallen, kan je internetaanbieder je het meest helpen, maar als ze geen DDoS-bescherming hebben, is de kans groot dat je buiten dienst zal zijn tot de aanval stopt. Meestal zullen ze het aangevallen IP-adres zien en het netwerk op hun upstream-router op nul zetten. Als u niet veel verkeer hebt, zijn er veel online services voor DDoS-beveiliging waar uw verkeer wordt omgeleid, gefilterd en teruggestuurd naar uw server.


0
2017-11-18 11:42