Syn flood random ip címről

Hálózatok általános

Ü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.

( athila v | 2015. 03. 31., k – 18:49 )

Kérdezd meg az ISP-det, tud-e adni DDoS szűrést/tisztítást.

( gedez | 2015. 03. 31., k – 19:32 )

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?

( gergelykiss | 2015. 03. 31., k – 20:35 )

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. :)

( AndrewID v | 2015. 03. 31., k – 21:16 )

É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

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)

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!

( csabka v | 2015. 03. 31., k – 23:40 )

Alábbi lehetőséget tudom javasolni:

I. "előre menekülés"

  1. új IP-cím kérése a szolgálatótól
  2. DNS-(eke)t az új IP-re átíratod
  3. régi IP címet pihentettni egy route blackhole -ba (tűzfalt megelőzi így optimálisabb) pl: szolgáltató által
  4. amennyiben a szolgáltatód támogatja/hajlandó rá, BGP hirdetésben azt a címet behirdeti, hogy blacklisted (ami a DDOS áldozat) így megszűnhet az ISP-d terhelése is -saját érdekük-

II. Reverse proxyk (pl nginx) beüzemelése

  1. elindítasz 2 reverse proxy -lehetőleg két különböző gép legyen (egyiket pl az eredeti IP-n, bár nem érdemes, csak ha nagyon fontos) másikat egy új IP-n.
  2. web szervert egy 3. gépen futtasd, amit pl privát címen látnak a reverse proxyk
  3. DNS-ben mind a két reverse proxy IP-t megadod A rekorddal -esetleg érdemes a támadott címet kihagyni addig, amíg támadás alatt állsz-
  4. DDOS támadással, ha csak az egyik címedet hasaltatják el, a csak SYN miatt a HTTP szerveredig nem jut el a kérés...

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...