Zvláštní reflected SYN ACK útok

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

zjistil jsem podivný traffic, že můj počítač odesílá SYN ACK pakety , třeba 6x za minutu. a sleduji to 5 minut a třeba příchozí paket přišel teprv před minutou... Je to nějaké divné.... na cílové soketu běžel jen smtp server. Ta IP  217.26.33.62  je nějaká švýcarská a leží na nějakém blacklistu hostů


(reflected je trochu nemístné - nejde o útok někam reflected na jiný cíl)
V logu serveru nic nevidím, protože samozřejmě ani nedojde k otevření spojení...

Prosím o vysvětlení toho chování, proč můj  pc odesílá tolik Syn ACk k neúměrně málo (jen jeden jsem viděl) příchozí SYN.

conntrack hlásí
tcp      6 38 SYN_RECV src=217.26.33.62 dst=10.5.0.1 sport=59020 dport=25 src=10.5.0.1 dst=217.26.33.62 sport=25 dport=59020 mark=0 use=1
tcpdump: Zvláštní jsou flagy navíc: mptcp

Kód: [Vybrat]


IP 10.5.0.1.25 > 217.26.33.62.56030: Flags [S.], seq 994965436, ack 3670934280, win 64296, options [mss 1380,sackOK,TS val 3206162276 ecr 3672003851,nop,wscale 7], length 0
IP 217.26.33.62.34337 > 10.5.0.1.25: Flags [S], seq 2251389447, win 64240, options [mss 1460,
..... (pokrač.)wscale 8,sackOK,TS val 2250320907 ecr 2250320907,mptcp capable csum {0xfca89f02fca89f02},tfo  invalid], length 0
IP 10.5.0.1.25 > 217.26.33.62.34337: Flags [S.], seq 4153591080, ack 2251389448, win 64296, options [mss 1380,sackOK,TS val 3206171226 ecr 2250320907,nop,wscale 7], length 0
IP 10.5.0.1.25 > 217.26.33.62.34337: Flags [S.], seq 4153591080, ack 2251389448, win 64296, options [mss 1380,sackOK,TS val 3206172276 ecr 2250320907,nop,wscale 7], length 0
IP 10.5.0.1.25 > 217.26.33.62.34337: Flags [S.], seq 4153591080, ack 2251389448, win 64296, options [mss 1380,sackOK,TS val 3206174356 ecr 2250320907,nop,wscale 7], length 0
a ještě jeden s -verbose
IP (tos 0x0, ttl 121, id 34470, offset 0, flags [none], proto TCP (6), length 80)
    217.26.33.62.33446 > 10.5.0.1.25: Flags [S], cksum 0xcbc7 (correct),
...seq 2193025287, win 64240, options [mss 1460,wscale 8,sackOK,TS val 2191965963
...ecr 2191965963,mptcp capable v0 csum {0xf82f0c02f82f0c02},tfo  (invalid)], length 0



ss hlásí
sudo ss -4pexa |grep 217
tcp    SYN-RECV  0       0         10.5.0.1:25      217.26.33.62:42234     timer:(on,19sec,6) ino:0 sk:1017 

[Reklama]

[alex6bbc]

tohle?

https://ddos-guard.net/en/terms/ddos-attack-types/syn-ack-flood

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Nějak tomuto nerozumím:

In a SYN-ACK flood attack, the target server is inundated with a large number of forged SYN-ACK packets.

Příchozí SYN packet přichází méně často chodí od 217 na server. Ale proč server odpovídá toliky SYN+ACK . To by si pak server za DDoS mohl sám, když on je ten, kdo odpovídá. Odpovídá klientovi. A jak tedy mohou být forged, když odpovídá server. A hlavně proč server odpovídá tolikrát. Nebylo to jen třikrátm ale tipl bych každou sekundu po dobu 1s. A iniciátoroský SYN přišel třeba jednou za minutu.
Bohužel jsem to zaznamenal s tcpdump -t/(bez času)

(chápu, že při sestavování  TCP spojení se pakety odesílají třeba třikrát v určitém odstupu, je to vidět v wiresharku., Nevím zda jde o uplně stejnou věc jako TCP retransmision uprostřed spojení obsahující data)

Jen pro osvěžení:


Po zavedení pravidla DROP je samozřejmě klid. iptables -nvL FORWARD -jDROP -s 217...... hlásí celkem 22 paketů (příchozích, jelikož *). a conntrack neobsahuje tuto adresu.
Mám pocit, že v tom hraje roli i conntrack, ale je to jen pocit (Celé je to forwardované na jiný PC)

* existuje iptables pravidlo něco jako -d/-s 217.62.1.3, tedy že by jedno pravidlo matchlo ip adresu nezávisle na směru dst/src ?

[alex6bbc]

no a neni to treba uz znama a opravena chyba pro vas mejlserver? zkuste aktualizovat a je nadeje ze uz to fixli.

[Foreigner]

Doporucuji udelat pcap otevrit ve wiresharku a analyzovat. Jedna se o komunikaci na port 25 pak bude dokonce videt i obsah spojeni a nebo aspon uvod pripojeni pred startls. Takova TCP spojeni, ktera nezacinaji 3-way handshake se odfiltruji ve firewallu pomoci stavu invalid. Debatovat nad tim co server delal a proc je zbytecna ztrata casu.

[Reklama]

[NaRootuJeNeskutecneDebilniRegistracniFormular]

Autor si z vas
a) dela zadek
b) nevi, jak funguje TCP

Kdyz dostanu SYN, poslu SYN/ACK.
Kdyz nedostanu ACK, pockam predem definovany interval (1s) a poslu znovu.
Kdyz porad nedostanu ACK, zdvojnasobim interval, pockam a poslu SYN/ACK znovu.
Opakuji, dokud nedosahnu hodnotu z /proc/sys/net/ipv4/tcp_synack_retries.

Problem vidim v tom, ze se autoruv SYN/ACK nedostane ke zdroji SYN a ten nevi, ze ma poslat ACK.

[kanoe22]

Autor hlavne trpi poruchou kedy si mysli ze ho niekto neustale sleduje. Ved ten jeho PC musi byt orezanejsi ako telefon co dostavaju americky prezidenti ked su v urade (kto nevie, vygooglite si o tom nieco)

Uz som sa tu viac menej naucil ignorovat vlakna od zopar ludi

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

kanoe22 trpi nadmernou fantazii. Nic o \bsled[uo]\W+ jsem nepsal . Kromě toho DDoS a sledování spolu jinak nesouvisí.

Neplatí ani jedna z možností a( a b(.  Ty pakety odcházely častěji, řekl bych neustále.
hodnota /proc/sys/net/ipv4/tcp_synack_retries je 5