Názory k článku Vlastimil Pečínka (Seznam.cz): Anomálie v trafficu nás dovedly do Ruska

To jste ten článek četl dost špatně :-)
Dostupné nástroje jsou především ta infrastrukturní oddělenost. Na tento DDoS jsou libovolné krabičky krátké (nebo je jejich účinnost ekvivalentní nasazení SYN cookies na cílovém stroji).

Zrovna v tomto případě krabičky ničemu nepomůžou. Ale když se chcete nechat obrat o peníze... Už jsem četl pana Nápravníka v lidovkách, že stroj za 15MKč, který dodá, ty banky bezpečně ochrání před těmito útoky. Možná pan Pečínka míří zrovna na tyto prodavače bezpečnostních iluzí.

http://byznys.lidovky.cz/server-za-15-milionu-by-banku-pred-utoky-ubranil-rika-expert-po8-/firmy-trhy.aspx?c=A130309_205316_firmy-trhy_mtr

Tak co třeba ty krabičky do zásuvky co fitrovaly tu ošklivou energii z Dukovan a Temelína :o) Tak zkouší třeba tohle. Tak Horste co pro nás máš dnes nového.....

Ne vážně, reálně při dnešním stavu Internetu to prakticky nejde. Nemyslím je technologicky , ale i organizačně. V takovém "defenzivním" režimu by pravděpodobně byl daný server tak omezený , že je otázka jak moc by byl nad funkcionalitou při útoku bez aktivní ochrany. otázka jestli provozovatatel by právě vůbec měl prostředky se bránit. Tím není myšleno jen těch 15melounů za krabičku filtrující "zlé pakety z Uralu". A ale jestli má náhradní kapacitu, konektivitu . Konče lidmi kteří vědí co stím.

Server za 15M nebo na Linuxu:

echo 1 > /proc/sys/net­/ipv4/tcp_syn­cookies

:)

Branit se da. Napriklad tak, ze mate vetsi mnozstvi sitovych a vypocetnich zdroju, nez utocnik.

Problem je "jenom" to, ze obrana stoji neumerne mnozstvi prostredku.

Ale no tak. To je standardní nastavení u alespoň slušně použitelného providera. Žádná zvláštní analýza není potřeba.

Ale kdeže... Žádná analýza paketů není potřeba. Na telefonech taky operátoři docela jednoduše umí nastavit povolená čísla. Bohužel (i bohudík) je v Internetu mnohem více operátorů, takže donutit je k nějaké koordinované akci je trochu problém.

to je nedůslednost správců jednotlivých providerů. Na to se provideři nemusejí domlouvat mezi sebou. Prostě na místě správců sedí buď lidi, kteří tomu nerozumí/kašlou na to, nebo nemají technické prostředky, jak to realizovat.

Kéž by. Vyřešilo by to spoustu problémů se spoofovanými adresami. Nicméně se podívejte na datum BCP38, a na letošní rok... od doby vydání toho RFC se bohužel nic moc nestalo.

Nejde o domluvu. Kazdy ISP si to musi osefovat ve sve vlastni siti. Pricemz v pripade, ze jste tranzitni operator, nemusi byt urzba filtrovacich pravidel zadny med.

Vidite a presto se o to nekteri poskytovatele (celkem uspesne) snazi. Zejmena proto, ze slovni spojeni "1/2 zavirovanejch widli na netu" je pomerne v rozporu s realitou :-)

Jako poskytovatel infrastruktury muzete pouzivat ruzne "unfair" praktiky, jako syn cookies nebo anycasting (pro izolaci utocniku).

Docela pěkně je to vysvětleno zde:

http://lwn.net/Articles/277146/

The major downside to syncookies is that they only have space to encode the most basic of TCP handshake options. At the time of initial syncookie deployment this was not a large problem because the only option prominently in use at the time was the Maximum Segment Size (MSS) option. This option is provided to help the peer avoid unnecessary fragmentation by sending packets that the other end of the connection knows a priori are too large to cross its network. This is exactly the kind of information that is normally stored as state in the SYN queue. The syncookie designers knew that this option was important to performance and found 3 bits for it in the encoded syncookie. These bits are used to approximate the real value of the option to one of 8 common values.

In the intervening years new options have come into prominence and these are not syncookie compatible. The most important of these are the window scaling and Selective Acknowledgment (SACK) options. These features respectively allow the TCP congestion control window to grow beyond 64KB and be more efficient in the case of minor packet losses from those large windows. Without using these features it is impossible to get good transfer rates on networks with large bandwidth or large latency. Many household broadband links require at least the window scaling option to fully utilize the network connection. Due to this limitation, and the modest computation overhead of the cryptographic hash, the Linux stack only resorts to syncookie based connections when the number of half-open connection exceeds a high watermark controlled by the net.ipv4.tcp_max_syn­_backlog sysctl. These connections are less featureful than normal connections but they are only resorted to when the queue would otherwise require active pruning.

Proc si myslite, ze by to mel byt NIX.CZ nebo CSIRT schopen zariznout?

To, odkud minimalne cast utoku jde, bylo videt velmi brzy. Ze o tom dotycni nepsali do novin, je normalni. Stejne tak plati, ze pokud nekdo utoci na servery v siti X, tak v siti Y nikdo neprijima zadna zbrkla opatreni.

Mozna tim autor mel na mysli nejake pravidlo typu:

Cokoliv dostanes z daneho peeru, hazej do kose.

Nebylo by pak jednodušší zrušit ten peering?

Nebylo, protože pak to půjde nějakou jinou (zpravidla horší) trasou a zamíchá se to s ostatním provozem, tím pádem už to nedokážete odlišit.

Pokud zrušíte peering, tak minimálně odkloníte veškerý provoz, kterému byste dělal tranzit. A zahazovat se to dá i podle čísla AS. Je to ale trochu složitější.

V případě, že jste cílová síť, tak je blackholing efektivnější.

Je ovšem otázka, jak je to smluvně ošetřeno. Protože já bych se celkem vztekal, kdyby mi můj peer zahazoval všechna moje spojení, která přes něj jdou.

Velice pěkný článek, děkuji. :-) Jen více takových na Lupě! Dost bylo nudných Bártů a pitomých startupů... Back to the roots!

Návrat ke kořenům staré dobré Lupy. :-)