Fórumok
Üdv, olyan problémánk lenne, hogy random ip címekről érkezik syn flood 80-as portra. A gép valójában egy vps, dell t620-on vmware, azon pedig egy debian guest. Van ötletetek hogyan lehetne kivédeni? Cloudflare és társai első körben nem játszanak, ügyfelek vannak a gépen.
Hozzászólások
Kérdezd meg az ISP-det, tud-e adni DDoS szűrést/tisztítást.
Nem tud, próbáltuk.
Akkor ezzel sokat nem tudsz tenni, finomhangolsz:
Ez pl nem redhat specifikus dolog: http://rhelblog.redhat.com/2014/04/11/mitigate-tcp-syn-flood-attacks-wi…
// Happy debugging, suckers
#define true (rand() > 10)
Lehet, hogy normál http kérések, csak a mennyiségéből adódóan syn flood-nak nézi?
Ha normál http kérések akkor milyen domainre/url-re érkeznek a kérések?
Ez nem http kérés, syn flood, 100+ kpps.
Szerintem első körben próbáld meg bekapcsolni a syn cookie feature-t a kernelben:
http://en.wikipedia.org/wiki/SYN_cookies
http://www.cyberciti.biz/faq/enable-tcp-syn-cookie-protection/
Ezzel kivédhetők a megkezdett, de fel nem épített TCP kapcsolatokkal (aka. SYN flood) kiváltott túlterheléses támadások.
Ha HTTP request-ekkel bombázzák a szervert, akkor egy adott IP-cím vagy tartomány esetén tűzfalon kitilthatod a cím(ek)et. Ha tökéletesen random IP-kről jön az "áldás" (pl. tor exit node-ok vagy egymástól távol eső proxy szerverek, esetleg egy botnet), akkor...
...építesz egy több száz/több ezer node-ból álló cluster-t, ami képes kiszolgálni a legitim klienseket egy DDoS támadás alatt is. :)
Más is ajánlotta syncookies-t mielőtt ide jöttem, de nálam valamiért egyáltalán semmi hatása nincs.
Én is most kaptam egy 1,4Gbit/sec UDP forgalmat a 80-as portra, mindenféle egzotikus címekről.
Talán egyetlen hathatós védelem ha a szolgáltatótól kéred a nemzetközi sávszél korlátozását...?
logban ennyni nyoma maradt:
UDP: bad checksum. From 173.161.199.81:161
UDP: bad checksum. From 23.24.205.38:161
UDP: bad checksum. From 23.24.205.38:161
UDP: bad checksum. From 23.24.205.38:161
UDP: bad checksum. From 50.197.141.52:161
UDP: bad checksum. From 173.161.199.81:161
UDP: bad checksum. From 96.27.188.152:161
UDP: bad checksum. From 81.21.56.155:161
UDP: bad checksum. From 50.197.141.52:161
...
A közös bennük hogy mind a 161-es portról érkezett, így valószínű egy SNMP Reflection/Amplification támadás lehetett:
http://www.incapsula.com/ddos/attack-glossary/snmp-reflection.html
helyből eldobálnám az 1024 alatti ephemeral portokat, logolás nélkül:)
// Happy debugging, suckers
#define true (rand() > 10)
Eldobhatod, de semmit nem érsz vele ha már eljutott a gépedig.
Annyi jön belőle hogy kitömi a gigabites kapcsolatod.
Ha több gépre terhelés elosztasz, akkor a hálózatod legszűkebb kapcsolatát, akár a 10Gbit-et is kitömi.
Az UDP csomagok tárva-nyitva hagyott hálózati nyomtatók segítségével felerősítve jönnek.
Tudom, nem is így gondoltam, hanem core routeren dobálnám el. Aztán azóta rájöttem, hogy gyorsabb volt a szám mint az eszem (és ez nem egy brainstorming most), mivel nem lehet a kapcsolat irányát megállapítani udp esetén. Szóval sztornó!:)
// Happy debugging, suckers
#define true (rand() > 10)
Megtaláltam az árlistát. Nem kell vagyonokat költenie a haragosodnak:
Attack Script: $150
Scanner: $50
+150$-ért 8magos szervert lehet bérelni hozzá.
Azok a scriptek sajnos fent vannak neten ingyen is...
jah, ilyen nekem is volt regen. 100megas linket kitomtek, a szolgaltato ugyfelszolgalata meg azt tanacsolta hogy kapcsoljam be a tuzfalat. mikor megkerdeztem h ez hogyan fogja megszurni a "csoben" levo forgalmat, akkor csak hebegett, es a ceg tuzfal szolgaltatasat javasolta X Ft-ert...
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Alábbi lehetőséget tudom javasolni:
I. "előre menekülés"
II. Reverse proxyk (pl nginx) beüzemelése
Van olyan hazai szolgálató a nagyok közül, aki mostanában vezeti be a DDoS védelmet.
Hozzá beérkezik a teljes forgalom, de hozzád már csak a megszűrt forgalom. Működik, kaptunk egy flood-ot, pár perc alatt felismerte a szokottól eltérő "abnormális" forgalmat, és minden rendben ment tovább.
Cserébe nem olcsó.
Alternatívaként (ha szolgálató vagy) elméletileg több megoldás lehet szerintem:
- behatárolni a DDoS forrását, és AS szinten blackhole-ba hírdetni felé
- ha van több nemzetközi vonalad, a legkisebb felé hírdeted a támadott prefixet, a többit pedig leveszed onnan - de ez majdnem olyan mint a blackhole, mert úgysem fog működni benne semmi :-)
Amit fentebb írtál, a II. teljesen kihagyható, hiszen a vonalad ki van tömve, nem érkezik be a kérés egyik reverse proxyra sem.
A II. részemről egy másik opció, nem kiegészítése az elsőnek...
Persze akkor igaz, ha a szolgáltató nem hallt le, csak Te szervereden telt be a cső.... akkor egy másik csövön ugyan az a szolgáltató akár még mindig biztosíthat szabad forgalmat a másik reverse proxy számára, persze lehet két különböző szolgáltató is...
+1, jó összefoglaló:)
// Happy debugging, suckers
#define true (rand() > 10)
de pl. www.blacklotus.net