Potwierdzam

09:49:21.031942 149.156.119.1.6667 > 80.53.62.82.58461: . [tcp sum ok] ack 2093393713
win 65535 (ttl 47, id 39426, len 40)
09:49:21.032020 80.53.62.82.58461 > 149.156.119.1.6667: R [tcp sum ok]
2093393713:2093393713(0) win 0 (DF) (ttl 64, id 0, len 40)
09:49:26.750974 149.156.119.1.6667 > 80.53.62.82.13492: . [tcp sum ok] ack 3277615905
win 65535 (ttl 46, id 39426, len 40)
09:49:26.751050 80.53.62.82.13492 > 149.156.119.1.6667: R [tcp sum ok]
3277615905:3277615905(0) win 0 (DF) (ttl 64, id 0, len 40)
09:49:32.424468 149.156.119.1.6667 > 80.53.62.82.31808: . [tcp sum ok] ack 2263990552
win 65535 (ttl 47, id 39426, len 40)
09:49:32.424539 80.53.62.82.31808 > 149.156.119.1.6667: R [tcp sum ok]
2263990552:2263990552(0) win 0 (DF) (ttl 64, id 0, len 40)

osobiście narazie zrobiłem dropa na adresy źródłowe 6667


On Thu, 26 Feb 2004 17:16:53 +0000, Piotr KUCHARSKI wrote:

> Witam,
>
> Oprócz zwykłych ataków (D)DoS przez flood UDP i ICMP na serwery IRC.pl,
> od kilku dni obserwujemy ataki na serwery IRC.pl i całe sieci klientów
> (bardzo prawdopodobne, że brane wprost z I:linii) wg następującego
> schematu:
> - do serwerów IRC.pl przychodzą pakiety ACK ze spoofowanym adresami
> klientów
> - serwer nie ma takich połączeń, więc (oczywiście) odsyła RST
> - jednocześnie adresy klientów otrzymują pakiety ACK ze spoofowanym
> adresem źródłowym (wstawiane są adresy serwerów IRC.pl)
> - klienci nie mają takich połączeń, więc (oczywiście) odsyłają RST
>
> Co prawda to tylko dwukrotne wzmocnienie ataku, ale jest on dość
> niewygodny do eliminowania.
>
> Uprzejmie proszę o przyjrzenie się swoim sieciom i zgłaszanie
> takich przypadków swoim providerom, dobrze by było z kopią do
> CERT Polska.
> Spoofowane pakiety skądś przychodzą, trzeba znaleźć i uciąć;
> niestety sprawę utrudnia fakt, że w większości są spoza Polski.
>
> Ataki (D)DoS mają w porywach do 400Mbps, stąd mogą występować
> utrudnienia w dostępie do serwerów IRC.pl.
>
> p.