Dotaz: DDOS utok

[Rishare]

Zdravim, uz nekolik dni je na mou linku vedeny DDOS utok, na apache chodi hromada takovychto requestu:
62.35.200.3 - - [14/Jan/2014:08:42:32 +0100] "POST / HTTP/1.1" 403 276 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
112.200.49.196 - - [14/Jan/2014:08:42:32 +0100] "POST / HTTP/1.1" 403 276 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
83.200.150.147 - - [14/Jan/2014:08:42:40 +0100] "POST / HTTP/1.1" 403 276 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"


To se diky spolupraci s poskytovatelem (UPC) podarilo vicemene odfiltrovat, ovsem na sendmail je vedeny utok, ktery me znepokojuje vice (predpokladam, ze jde o brute hadani hesla, nebo jen snaha o vycerpani pameti). Na mailserveru vidim hromadu takovychto procesu:
root 4817 0.0 0.3 7796 2948 ? S 09:06 0:00 sendmail: server 233.13.112.78.rev.sfr.net [78.112.13.233] cmd read
root 4819 0.0 0.3 7796 2912 ? S 09:06 0:00 sendmail: server 62-193-57-73.as16211.net [62.193.57.73] cmd read
root 4820 0.0 0.3 7796 2912 ? S 09:06 0:00 sendmail: server [194.250.70.41] cmd read
root 4821 0.0 0.3 7796 2916 ? S 09:06 0:00 sendmail: server 109.209-31-46.rdns.acropolistelecom.net [46.31.209.109] cmd read
root 4822 0.0 0.2 7352 2088 ? S 09:06 0:00 sendmail: startup with [147.30.142.123]
root 4823 0.0 0.2 7352 2120 ? S 09:06 0:00 sendmail: startup with ip-125-252-84-90.asianetcom.net
root 4824 0.0 0.3 7796 2900 ? S 09:06 0:00 sendmail: server [171.76.26.245] cmd read


Linka, ackoliv v neni vytizena mnozstvim prenasenych dat, je prakticky nepouzitelna, ikdyz je web i mailserver vypnuty. Nemate prosim nejake napady, co s tim?


Diky

---

---

Odpovědi

[Jeason]

to je otevreny server ? bez autorizace ?

fail2ban bych instaloval jako prvni.

[Filip Jirsák]

Pokud je linka nepoužitelná kvůli příchozím paketům, může s tím něco udělat jedině ISP. Pokud kvůli odchozím, musíte zjistit, co u vás generuje ten odchozí provoz, a to nějak zpacifikovat. Pokud je linka nepoužitelná, přes to že přes ní netečou žádná data, je buď fyzicky poškozená, nebo nestíhá zařízení na jedné nebo druhé straně spoje.

Fail2ban většinou moc neškodí (i když málokdy dělá něco užitečného). Ovšem malý DDoS útok je přesně ta výjimka, kdy fail2ban může situaci výrazně zhoršit. (Při velkém DDoS útoku vedeném na síťovou infrastrukturu už je jedno, co běží na cílovém počítači.)

[Jeason]

proc muze maly utok fail2ban zhorsit ?

[Filip Jirsák]

Protože zaměstná cílový počítač další zbytečnou činností - jednak sledováním těch selhání (pokud se to dělá procházením logů, je to hodně neefektivní), jednak vytvořením dlouhé sady pravidel pro firewall. A přesně o to - zaměstnat počítač něčím neužitečným - se útočník snaží. Pokud se navíc používají falešné zdrojové IP adresy (ICMP, UDP nebo útočník nepotřebuje navázat TCP spojení), blokují se tím IP adresy, které s útokem nemají vůbec nic společného - takže skutečným uživatelům zablokuje přístup fail2ban. Opět, znemožnit používat server skutečným uživatelům, to je přesně to, o co se útočník snaží.

[Jeason]

děkuji, takto jsem nad tim nepremyslel, ale je to logické.

[iKoulee]

+1

nejlepsi co se da v podobnem pripade delat je ulevit od vsech zbytecnosti

pokud se jedna o nejaky SYN utok, tak zapnout syncookies a kompletne vypnout veskere firewally (v cetne odebrani modulu, protoze i samotny zavedeny netfilter spotrebovava hromadu vykonu a brzdi packety ve fronte o contracku snad ani netreba mluvit)

pokud se jedna o utok na nejakou konkretni sluzbu, tak maximalne zjednodusit cestu pozadavku, pokusit se ho co nejdrive identifikovat a zastavit zpracovani

nekdy byva nejlepsi obrana utok pokud jde DOS z nejake cinske thaiwanske site (nebo podobneho mista kde nehrozi pritomnost regulernich klientu) tak zahltit mistni DNS muze pomoci (minimalne to donuti lokalni ISP zacit zjistovat co se deje)

[v]

No mě třeba pomohlo opačné řešení při útoku na web server apache. Se zapnutým syncookies a firewall nastavený na maximální počet navázání spojení z nějaké zdrojové adresy za jednotku času + maximální počet současných spojení z nějaké ip. To mi docela zabralo v první linii oproti DDOS útoku vedenému z několika zemí najednou (minimálně zdrojové IP takové byly), protože z každé z daných IP bylo vždy několik pokusů v podstatě najednou. Tím podstatným ale bylo řešit vyčerpání zdrojů na web serveru kvůli zpracovávání velkého množství requestů na dynamické weby v PHP a tím pádem 100% CPU využití pro běh php skriptů. Díky mod_qos a různým cachím v php byl server během útoku alespoň částečně dostupný i když reagoval strašně pomalu. V podstatě vše jsem vyřešil nasazením varnish cache před apache s vynucením cachování prakticky všeho.

Nicméně v případě opravdu pořádného DDOS se podle mně prakticky nelze bránit ničím (teda pokud člověk nemá tolik serverů jako třeba Google apod. a nemůže rozložit zátěž).

[iKoulee]

Pokud zahazujes SYN packety (limit poctu spojeni na IP) tak jsou syncookies vice mene zbytecne. Jinak iptables pomahaji jen v pripade hodne amaterskych pokusu.

Ano vycerpani zdroju je to cemu se snazime branit, snazil sem se to napsat nejak obecne. Pokud jde konkretne o web na apache, tak je dulezite, aby utocnikovy pozadavky prosli jen na staticky obsah. Pokud treba vsichni roboti utoci na stejne URL (coz byva pomerne bezne) tak misto neho servirovat nejaky staticky soubor s napr javascript redirectem, zkratka tak aby tomu robot nerozumel, ale regulerni prohlizec ano. Obcas se vyplati odchytit si par paketu a prolezt logy, a podivat se jestli podle neceho nelze poznat utocnika od regulerniho klienta, (napr. nejaka zvlastnost/chyba v hlavickach http).

jinak na zvladnuti bezneho DDOSu asi neni potreba farma ala google, vetsinou mezi serverem a botnetem byvaji jina uzka mista (treba pripojka do zahranicni konektivity) pak staci jen posilit vykon treba jen na 2 nasobek, ale hlavne dusledne posilit linku, protoze u vetsiny serveru (pokd aplikace neni napsana jak prase) dospejete k tomu ze 1Gbit je malo, protoze toho zvladnou upocitat vic

[Filip Jirsák]

Omezení počtu spojení z jedné IP adresy je úplně jiná kategorie, než fail2ban. V některých případech to může být dobré řešení. V popsaném případě (spoustu požadavků z jedné IP adresy najednou, a pak asi nějakou dobu nic), by fail2ban selhával přímo ukázkově – úvodní salvu by propustil, a až by bylo po všem, pak by IP adresu slavnostně zablokoval.

Jinak pokud to jde a aplikace je na to připravená, připadá mi lepší dostat provoz až do aplikace a odmítnutí řešit až tam. Samozřejmě to předpokládá, že ta aplikace vůbec ustojí velký počet spojení a že dokáže ten škodlivý provoz obsloužit rychle. Ale v aplikaci je víc možností, jak škodlivý provoz identifikovat (jak píšete, anomálie v protokolu apod.), jednak je větší šance útočníka nějak omezit – pokud otevře spojení, počká na jeho uzavření a otevře další, můžete mu držet spojení otevřené atd. Nejlépe jde tohle řešit na aplikačním firewallu (v HTTP proxy server nebo load balancer), ten by měl právě umět požadavek zpracovat s minimální režií, ale zároveň vidí všechny podstatné informace.

[iKoulee]

V podstate se vsim souhlasim.

Jen mam dost spatne zkusenosti s ohledem na pripravenost aplikaci. Napr u runtime kompilovanych a interpretovanych jazyku je skoda obetovat na utocnika strojovy cas potrebny ke kompilaci a slinkovani skriptu. Oboje lze sice resit, ale aplikaci ktere by na to byli pripraveny je naproste minimum.

Bohuze deployment do produkce vetsinou vypada jen tak, ze nekdo chytne git a udela check out do produkcniho prostredi, proto jako administrator radeji nenecham zavadne dotazy do aplikace ani dorazit.

[Filip Jirsák]

Souhlasím. Aplikaci jsem myslel v širším smyslu, včetně třeba proxy serveru nebo předřazené cache. Pokud tam je jen Apache v defaultní konfiguraci s nějakým skriptovaným bumbrlíčkem, větší nápor neustojí. Ale s takovou aplikací bude problém, i když se podaří část útoku odfiltrovat na firewallu. Pak by ale taková aplikace neměla být nasazována na místo, kde se určitá odolnost proti DDoS vyžaduje. Ale nemám problém s tím, když se na začátku řekne, že DDoS se považuje za nepravděpodobný, případná několikahodinová nedostupnost je přípustná a náklady na ochranu by převýšily přínosy - není to žádná ostuda.

[Rishare]

No obavam se, ze mi moc veci (predevsim aplikaci typu fail2ban) na me strane moc nepomuze, protoze ikdyz primo na vstup zapojim notebook, ktery ma vsechny porty zavrene, presto je linka temer nepouzitelna. Pokud ovsem zustanu na tom stejnem kabelu, jen zmenim na jinou IP (mam nastesti k dispozici vice verejnych IP), tak hned vse jede v poradku.

Nechci prepisovat DNS zaznamy na jinou verejnou IP, protoze se obavam, ze by velice rychle doslo i k jejimu zahlceni. Zatim jsem zvolil provizorni reseni, ze veskery traffic z vnitrni site vedu pres jinou verejnou IP a servery vystavene pro venek zustavaji na IP pod utokem. Paradoxni je, ze obe verejne IP bezi pres ten stejny ethernetovy kabel.

[Filip Jirsák]

Nerozumím tomu vašemu popisu. Nejdřív píšete, že když na tu linku připojíte počítač s tou IP adresou, na kterou je veden útok, je linka nepoužitelná. Pak zase píšete, že i když tam máte připojený server s danou IP adresou, linka je pro jiné IP adresy pořád použitelná.

Pokud je to tak, že kapacita linky vyčerpaná není, ale je pomalá komunikace na jedné IP adrese, musí to omezovat ISP – má nastavený limit na šířku pásma pro tu IP adresu.

Nejdřív ale musíte zjistit, v čem je skutečný problém. Pokud si myslíte, že jde o DDoS útok, zjistěte něco o těch příchozích paketech – jestli směřují na jeden port, co je to vůbec za protokol, jestli jsou opravdu z různých zdrojových adres, kolik jich je. Z toho, co jste popsal, totiž také vůbec nemusí jít o DDoS útok, ale mohl vám ISP jenom přiškrtit pásmo pro danou IP adresu.

[Rishare]

S ISP (UPC) docela svizne komunikujeme a zadny limit tam pry nastaveny neni. Pri mereni rychlosti linky pres ruzne webove sluzby to dokonce ukazuje temer dvojnasobne rychlosti, nez jake mame ve smlouve.

Rad bych o prichozich paketech zjistil vic, nemam vsak v tehle oblasti moc zkusenosti. Nemohl byste mi pro to prosim nejake nastroje doporucit?

[alkoholik]

tcpdump

[Rishare]

Tak jsem neco zkousel, ale moc chytry z toho nejsem. Jde o mailserver za firewallem:

[root@mail ~]# tcpdump -X -l -w - port 25 | strings -a

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
2DO~
220 mujserver.cz ESMTP Sendmail 8.13.1/8.13.1;
2DO~
220 mujserver.cz ESMTP Sendmail 8.13.1/8.13.1;
220 mujserver.cz ESMTP Sendmail 8.13.1/8.13.1;
500 5.5.1 Command unrecognized: ",Z'C~D/
2D](\
220 mujserver.cz ESMTP Sendmail 8.13.1/8.13.1;
f<fG
f<fG
220 mujserver.cz ESMTP Sendmail 8.13.1/8.13.1;
2D<K
500 5.5.1 Command unrecognized: "
(T7@
_e\gO
2DK(
2D\gO
K(}	uL
_b\gO
2DK(
z}	uMP
[`\gO
2DK(
z}	uMP
{#RHi[Y
fpm_qw
2D\gO
K(}	uM
2D<K
(j}@
2D]=
?rGa
]?*P
]=}{:
500 5.5.1 Command unrecognized: "bc[
]=}{;
2D]=
500 5.5.1 Command unrecognized: "
500 5.5.1 Command unrecognized: "
2D<K
500 5.5.1 Command unrecognized: "
\bF2
2D\bF2
2D\gO
K(}	uM
220 mujserver.cz ESMTP Sendmail 8.13.1/8.13.1;
\bF2
\bF2
2D\bF2
2DK(
z}	x8P
X%}P
X%}P
@)e{
h}Wv
O0tn
0R%@
(R+@
(R,@

[root@mail ~]# tcpdump -ni eth0 'dst 192.168.50.68' |head -n 30
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
17:45:38.218437 IP 192.168.50.55.45795 > 192.168.50.68.ssh: . ack 200739613 win 1323 <nop,nop,timestamp 144251835 171133595>
17:45:38.218507 IP 192.168.50.55.45795 > 192.168.50.68.ssh: . ack 113 win 1323 <nop,nop,timestamp 144251835 171133595>
17:45:38.453184 IP 190.239.157.188.59769 > 192.168.50.68.smtp: F 578564534:578564534(0) ack 2511328731 win 16616
17:45:38.692882 IP 190.239.157.188.59769 > 192.168.50.68.smtp: R 1:1(0) ack 160 win 0
17:45:39.331688 IP 178.248.39.10.60333 > 192.168.50.68.smtp: R 706985253:706985253(0) ack 2520855258 win 16384
17:45:39.455043 IP 122.164.190.40.29535 > 192.168.50.68.smtp: R 2077333757:2077333757(0) ack 2514071860 win 16384
17:45:39.539647 IP 81.93.6.152.14054 > 192.168.50.68.smtp: F 120277023:120277023(0) ack 2510789905 win 65202
17:45:39.616262 IP 81.93.6.152.14054 > 192.168.50.68.smtp: R 1:1(0) ack 38 win 0
17:45:40.079257 arp who-has 192.168.50.68 tell 192.168.50.1
17:45:40.395685 IP 86.64.144.172.53573 > 192.168.50.68.smtp: F 1520487877:1520487877(0) ack 2515604318 win 2920 <nop,nop,timestamp 925174499 171133420>
17:45:40.398128 IP 192.168.50.55.45795 > 192.168.50.68.ssh: . ack 1185 win 1323 <nop,nop,timestamp 144254014 171134140>
17:45:41.491866 IP 82.71.5.240.34948 > 192.168.50.68.smtp: F 289190999:289190999(0) ack 2519538730 win 254
17:45:41.626310 IP 82.71.5.240.34948 > 192.168.50.68.smtp: R 1:1(0) ack 79 win 0
17:45:41.650807 IP 181.66.39.65.54786 > 192.168.50.68.smtp: F 3796169060:3796169060(0) ack 2514954746 win 16938
17:45:41.878169 IP 181.66.39.65.54786 > 192.168.50.68.smtp: R 1:1(0) ack 240 win 0
17:45:41.880095 IP 181.66.39.65.54786 > 192.168.50.68.smtp: R 3796169061:3796169061(0) win 0
17:45:42.528168 IP 86.64.144.172.53573 > 192.168.50.68.smtp: R 1520487878:1520487878(0) win 0
17:45:42.528632 IP 86.64.144.172.53573 > 192.168.50.68.smtp: R 1520487878:1520487878(0) win 0
17:45:42.808445 IP 72.8.1.186.33348 > 192.168.50.68.smtp: F 15125237:15125237(0) ack 2507305667 win 16296
17:45:42.979094 IP 72.8.1.186.33348 > 192.168.50.68.smtp: R 1:1(0) ack 187 win 0
17:45:43.268603 IP 181.165.69.204.2047 > 192.168.50.68.smtp: S 1437914439:1437914439(0) win 65535 <mss 1460,nop,wscale 1,nop,nop,sackOK>
17:45:43.271060 IP 192.168.50.55.45795 > 192.168.50.68.ssh: . ack 2257 win 1323 <nop,nop,timestamp 144256887 171134858>
17:45:43.396337 IP 176.249.19.176.64706 > 192.168.50.68.smtp: S 1686973645:1686973645(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
17:45:43.457368 IP 176.249.19.176.64706 > 192.168.50.68.smtp: . ack 2529639876 win 16425
17:45:43.471707 IP 176.249.19.176.64706 > 192.168.50.68.smtp: P 0:1024(1024) ack 1 win 16425
17:45:43.500534 IP 90.207.238.101.domain > 192.168.50.68.32768:  4458 NXDomain*- 0/1/1 (103)
17:45:43.552884 IP 181.165.69.204.2047 > 192.168.50.68.smtp: . ack 2516948740 win 64000
17:45:43.561819 IP 181.165.69.204.2047 > 192.168.50.68.smtp: P 0:1024(1024) ack 1 win 64000
17:45:45.438570 IP 81.20.147.34.1839 > 192.168.50.68.smtp: S 2628082629:2628082629(0) win 65535 <mss 1460,nop,nop,sackOK>
17:45:45.498282 IP 81.20.147.34.1839 > 192.168.50.68.smtp: . ack 2530633455 win 65535
49 packets captured
49 packets received by filter
0 packets dropped by kernel

[Filip Jirsák]

To vypadá, jako by na ten mailserver byl přesměrovaný nějaký šifrovaný protokol. Každopádně tímhle způsobem to těžko vyřešíme, na to máme zoufale málo informací – nevíme nic o topologii sítě, o konfiguraci firewallu, o běžících službách… Pravděpodobně pokud si k tomu počítači sedne někdo, kdo tomu trochu rozumí, najde a vyřeší chybu za 10 minut. Doporučuji tedy sehnat někoho, kdo se vám o ten server bude starat – provozovat veřejný server bez znalostí sítí opravdu není možné.

Pokud na straně UPC není žádné omezení, pak nevím, co znamená věta z dotazu „To se diky spolupraci s poskytovatelem (UPC) podarilo vicemene odfiltrovat“. Nebo to znamenalo, že UPC vám poradilo, co si máte na serveru nastavit? Každopádně z toho, co zatím víme, takřka jistě nejde o externí DoS útok a už vůbec ne o DDoS. Spíš to tipuju na chybnou konfiguraci – serverů, firewallu nebo něčeho takového.

[marek]

Dobry den.

DDOS s 5 packety za sekundu je opravdu "masivni".

Podobne chovani jsem zazil u adslmodemu, ktery natoval-routoval.

Ono se dost setri - takze dokazal udrzet jen asi 256 spojeni.

Vzhledem k tomu, ze utocnik spojeni nezavira, tak vam to i pri jednom utoku za sekundu do peti minut vycerpa.

Marek