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
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
tohle?
https://ddos-guard.net/en/terms/ddos-attack-types/syn-ack-flood
Nějak
tomuto nerozumím:
CitaceIn 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í:
(https://accedian.com/wp-content/uploads/2018/09/standard_tcp_handshake.png)
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 ?
no a neni to treba uz znama a opravena chyba pro vas mejlserver? zkuste aktualizovat a je nadeje ze uz to fixli.
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.
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.
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