mnoho spojení SYN_RECV - DDOS botnet?
Ahoj, už několik dnů na mé VPS pozoruju mnoho spojení se stavem SYN_RECV viz: netstat -anp |grep 'SYN_RECV' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n 23 xxx.xxx.xxx.xxx 23 xxx.xxx.xxx.xxx ... okolo 20 IP adres. Mám se tím znepokojovat nebo je vše ok a vše by se mělo řešit na infrastruktuře? Díky moc za postřehy a rady Petr
Ahoj, co myslis tim resit na infrastrukture? My Ti do trafficu sahat nebudeme, pokud to nebude prusvih velikosti, jako byl ten prusvih s memcached udp amplification utokama - nic takovyho nepozorujeme; kazdopadne je mozny, ze se zase neco rozmaha (ale podle toho, ze se zatim nezvedla vlna abuse notices, to nevypada). Kazdopadne se ujisti, ze mas vsechno aktualni - z poslednich dni hlavne napr. PHP-FPM, ktere ma remote code execution diru v urcitych setupech uz od PHP5... a na PHP7 je venku proof of concept exploit. /snajpa On 2019-10-29 15:28, Petr Parolek wrote:
Ahoj,
už několik dnů na mé VPS pozoruju mnoho spojení se stavem SYN_RECV
viz: netstat -anp |grep 'SYN_RECV' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n 23 xxx.xxx.xxx.xxx 23 xxx.xxx.xxx.xxx ...
okolo 20 IP adres.
Mám se tím znepokojovat nebo je vše ok a vše by se mělo řešit na infrastruktuře?
Díky moc za postřehy a rady
Petr _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahojte, popravdě jsem si toho také všiml, je to > vše na 443 nebo 80 portu. Většina adress je Amazon south asia (seoul) + nějaký provider Leaseweb NL, je to na všech serverech. Trochu by to asi stálo za prozkoumání. Není toho moc cca 50 -200. V minulosti to bylo víc, pak to ustálo a asi se to oživuje? Zdenek út 29. 10 2019 v 19:48 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
Ahoj,
co myslis tim resit na infrastrukture? My Ti do trafficu sahat nebudeme, pokud to nebude prusvih velikosti, jako byl ten prusvih s memcached udp amplification utokama - nic takovyho nepozorujeme; kazdopadne je mozny, ze se zase neco rozmaha (ale podle toho, ze se zatim nezvedla vlna abuse notices, to nevypada).
Kazdopadne se ujisti, ze mas vsechno aktualni - z poslednich dni hlavne napr. PHP-FPM, ktere ma remote code execution diru v urcitych setupech uz od PHP5... a na PHP7 je venku proof of concept exploit.
/snajpa
On 2019-10-29 15:28, Petr Parolek wrote:
Ahoj,
už několik dnů na mé VPS pozoruju mnoho spojení se stavem SYN_RECV
viz: netstat -anp |grep 'SYN_RECV' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n 23 xxx.xxx.xxx.xxx 23 xxx.xxx.xxx.xxx ...
okolo 20 IP adres.
Mám se tím znepokojovat nebo je vše ok a vše by se mělo řešit na infrastruktuře?
Díky moc za postřehy a rady
Petr _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
... tak to prozkoumej, kdyz to rikas ;) /snajpa
On 30 Oct 2019, at 07:04, zd nex <zdnexnet@gmail.com> wrote:
Ahojte,
popravdě jsem si toho také všiml, je to > vše na 443 nebo 80 portu. Většina adress je Amazon south asia (seoul) + nějaký provider Leaseweb NL, je to na všech serverech. Trochu by to asi stálo za prozkoumání. Není toho moc cca 50 -200. V minulosti to bylo víc, pak to ustálo a asi se to oživuje?
Zdenek út 29. 10 2019 v 19:48 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
Ahoj,
co myslis tim resit na infrastrukture? My Ti do trafficu sahat nebudeme, pokud to nebude prusvih velikosti, jako byl ten prusvih s memcached udp amplification utokama - nic takovyho nepozorujeme; kazdopadne je mozny, ze se zase neco rozmaha (ale podle toho, ze se zatim nezvedla vlna abuse notices, to nevypada).
Kazdopadne se ujisti, ze mas vsechno aktualni - z poslednich dni hlavne napr. PHP-FPM, ktere ma remote code execution diru v urcitych setupech uz od PHP5... a na PHP7 je venku proof of concept exploit.
/snajpa
On 2019-10-29 15:28, Petr Parolek wrote:
Ahoj,
už několik dnů na mé VPS pozoruju mnoho spojení se stavem SYN_RECV
viz: netstat -anp |grep 'SYN_RECV' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n 23 xxx.xxx.xxx.xxx 23 xxx.xxx.xxx.xxx ...
okolo 20 IP adres.
Mám se tím znepokojovat nebo je vše ok a vše by se mělo řešit na infrastruktuře?
Díky moc za postřehy a rady
Petr _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Tak jsem to trochu prozkoumal více, vypadá to že je to nějaký scanner. Nyní je neaktivní (na žádném serveru to není) a vypadá to, že přistupuje z více obdobných adres např. - každá z nich je z jiné části Amazonu (routing, compute) apod.. Vše je ale AWS Soul. 54.180.139.105 54.180.138.177 54.180.163.44 54.180.139.105 13.124.8.54 13.125.235.121 13.125.197.34 - tato dokonce je živá a jede tam nějaký mail server https://www.abuseipdb.com/check/54.180.139.105 https://www.abuseipdb.com/check/13.125.197.34 <https://www.google.com/url?q=https://www.abuseipdb.com/check/13.125.197.34&sa=D&source=hangouts&ust=1572511680416000&usg=AFQjCNEOOO_7Kqh0hzDL5cQBvLnegK-rWA> podle komentářů to opravdu vypadá na nějaký scanner / SYN flood? st 30. 10. 2019 v 9:26 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
... tak to prozkoumej, kdyz to rikas ;)
/snajpa
On 30 Oct 2019, at 07:04, zd nex <zdnexnet@gmail.com> wrote:
Ahojte,
popravdě jsem si toho také všiml, je to > vše na 443 nebo 80 portu. Většina adress je Amazon south asia (seoul) + nějaký provider Leaseweb NL, je to na všech serverech. Trochu by to asi stálo za prozkoumání. Není toho moc cca 50 -200. V minulosti to bylo víc, pak to ustálo a asi se to oživuje?
Zdenek út 29. 10 2019 v 19:48 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
Ahoj,
co myslis tim resit na infrastrukture? My Ti do trafficu sahat nebudeme, pokud to nebude prusvih velikosti, jako byl ten prusvih s memcached udp amplification utokama - nic takovyho nepozorujeme; kazdopadne je mozny, ze se zase neco rozmaha (ale podle toho, ze se zatim nezvedla vlna abuse notices, to nevypada).
Kazdopadne se ujisti, ze mas vsechno aktualni - z poslednich dni hlavne napr. PHP-FPM, ktere ma remote code execution diru v urcitych setupech uz od PHP5... a na PHP7 je venku proof of concept exploit.
/snajpa
On 2019-10-29 15:28, Petr Parolek wrote:
Ahoj,
už několik dnů na mé VPS pozoruju mnoho spojení se stavem SYN_RECV
viz: netstat -anp |grep 'SYN_RECV' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n 23 xxx.xxx.xxx.xxx 23 xxx.xxx.xxx.xxx ...
okolo 20 IP adres.
Mám se tím znepokojovat nebo je vše ok a vše by se mělo řešit na infrastruktuře?
Díky moc za postřehy a rady
Petr _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Je něco proti něčemu dropovat obecně celý provoz z AS patřícího k oné IP adrese? Plus nějaké porty povoluju. To podle toho, jak se to u mne vyskytuje v logu a podle četnosti. Vencour On 30. 10. 19 9:52, zd nex wrote:
Tak jsem to trochu prozkoumal více, vypadá to že je to nějaký scanner. Nyní je neaktivní (na žádném serveru to není) a vypadá to, že přistupuje z více obdobných adres např. - každá z nich je z jiné části Amazonu (routing, compute) apod.. Vše je ale AWS Soul. 54.180.139.105 54.180.138.177 54.180.163.44 54.180.139.105
13.124.8.54 13.125.235.121 13.125.197.34 - tato dokonce je živá a jede tam nějaký mail server
https://www.abuseipdb.com/check/54.180.139.105 https://www.abuseipdb.com/check/13.125.197.34 <https://www.google.com/url?q=https://www.abuseipdb.com/check/13.125.197.34&sa=D&source=hangouts&ust=1572511680416000&usg=AFQjCNEOOO_7Kqh0hzDL5cQBvLnegK-rWA>
podle komentářů to opravdu vypadá na nějaký scanner / SYN flood?
st 30. 10. 2019 v 9:26 odesílatel Pavel Snajdr <snajpa@snajpa.net <mailto:snajpa@snajpa.net>> napsal:
... tak to prozkoumej, kdyz to rikas ;)
/snajpa
On 30 Oct 2019, at 07:04, zd nex <zdnexnet@gmail.com <mailto:zdnexnet@gmail.com>> wrote:
Ahojte,
popravdě jsem si toho také všiml, je to > vše na 443 nebo 80 portu. Většina adress je Amazon south asia (seoul) + nějaký provider Leaseweb NL, je to na všech serverech. Trochu by to asi stálo za prozkoumání. Není toho moc cca 50 -200. V minulosti to bylo víc, pak to ustálo a asi se to oživuje?
Zdenek út 29. 10 2019 v 19:48 odesílatel Pavel Snajdr <snajpa@snajpa.net <mailto:snajpa@snajpa.net>> napsal:
Ahoj,
co myslis tim resit na infrastrukture? My Ti do trafficu sahat nebudeme, pokud to nebude prusvih velikosti, jako byl ten prusvih s memcached udp amplification utokama - nic takovyho nepozorujeme; kazdopadne je mozny, ze se zase neco rozmaha (ale podle toho, ze se zatim nezvedla vlna abuse notices, to nevypada).
Kazdopadne se ujisti, ze mas vsechno aktualni - z poslednich dni hlavne napr. PHP-FPM, ktere ma remote code execution diru v urcitych setupech uz od PHP5... a na PHP7 je venku proof of concept exploit.
/snajpa
On 2019-10-29 15:28, Petr Parolek wrote: > Ahoj, > > už několik dnů na mé VPS pozoruju mnoho spojení se stavem SYN_RECV > > viz: netstat -anp |grep 'SYN_RECV' | awk '{print $5}' | cut -d: -f1 | > sort | uniq -c | sort -n > 23 xxx.xxx.xxx.xxx > 23 xxx.xxx.xxx.xxx > ... > > okolo 20 IP adres. > > Mám se tím znepokojovat nebo je vše ok a vše by se mělo řešit na > infrastruktuře? > > Díky moc za postřehy a rady > > > Petr > _______________________________________________ > Community-list mailing list > Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> > http://lists.vpsfree.cz/listinfo/community-list _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Nejlip bude to na Internet nevystavovat v takovym pripade vubec ;) Nebo jaky je toho duvod? Ja to nechapu. Je smyslem zamezit jakemukoliv dalsimu vyhledavaci, co neni Google, aby vubec vzniknul? Nebo proc proboha? Vzdyt byt videt je podstatou toho byt na Internetu... /snajpa
On 30 Oct 2019, at 09:59, V.K. <vencour@gmail.com> wrote:
Je něco proti něčemu dropovat obecně celý provoz z AS patřícího k oné IP adrese? Plus nějaké porty povoluju.
To podle toho, jak se to u mne vyskytuje v logu a podle četnosti.
Vencour
On 30. 10. 19 9:52, zd nex wrote: Tak jsem to trochu prozkoumal více, vypadá to že je to nějaký scanner. Nyní je neaktivní (na žádném serveru to není) a vypadá to, že přistupuje z více obdobných adres např. - každá z nich je z jiné části Amazonu (routing, compute) apod.. Vše je ale AWS Soul. 54.180.139.105 54.180.138.177 54.180.163.44 54.180.139.105
13.124.8.54 13.125.235.121 13.125.197.34 - tato dokonce je živá a jede tam nějaký mail server
https://www.abuseipdb.com/check/54.180.139.105 https://www.abuseipdb.com/check/13.125.197.34
podle komentářů to opravdu vypadá na nějaký scanner / SYN flood?
st 30. 10. 2019 v 9:26 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
... tak to prozkoumej, kdyz to rikas ;)
/snajpa
On 30 Oct 2019, at 07:04, zd nex <zdnexnet@gmail.com> wrote:
Ahojte,
popravdě jsem si toho také všiml, je to > vše na 443 nebo 80 portu. Většina adress je Amazon south asia (seoul) + nějaký provider Leaseweb NL, je to na všech serverech. Trochu by to asi stálo za prozkoumání. Není toho moc cca 50 -200. V minulosti to bylo víc, pak to ustálo a asi se to oživuje?
Zdenek út 29. 10 2019 v 19:48 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
Ahoj,
co myslis tim resit na infrastrukture? My Ti do trafficu sahat nebudeme, pokud to nebude prusvih velikosti, jako byl ten prusvih s memcached udp amplification utokama - nic takovyho nepozorujeme; kazdopadne je mozny, ze se zase neco rozmaha (ale podle toho, ze se zatim nezvedla vlna abuse notices, to nevypada).
Kazdopadne se ujisti, ze mas vsechno aktualni - z poslednich dni hlavne napr. PHP-FPM, ktere ma remote code execution diru v urcitych setupech uz od PHP5... a na PHP7 je venku proof of concept exploit.
/snajpa
On 2019-10-29 15:28, Petr Parolek wrote:
Ahoj,
už několik dnů na mé VPS pozoruju mnoho spojení se stavem SYN_RECV
viz: netstat -anp |grep 'SYN_RECV' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n 23 xxx.xxx.xxx.xxx 23 xxx.xxx.xxx.xxx ...
okolo 20 IP adres.
Mám se tím znepokojovat nebo je vše ok a vše by se mělo řešit na infrastruktuře?
Díky moc za postřehy a rady
Petr _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
A ma to nejaky realny smysl? Port scanning a hledani napadnutelnych sluzeb je proste bezna vec, ktere se deje a dit bude a to neustale. To by asi clovek nemusel delat nic jineho, nez porad pridavat nove rozsahy techto zaskodniku a pak co opusti nejaky prideleny rozsah to schyta nekdo legitmni po jeho znovu-uziti... Zejmena u AWS. S pozdravem Jan Pleva st 30. 10. 2019 v 10:02 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
Nejlip bude to na Internet nevystavovat v takovym pripade vubec ;)
Nebo jaky je toho duvod? Ja to nechapu. Je smyslem zamezit jakemukoliv dalsimu vyhledavaci, co neni Google, aby vubec vzniknul?
Nebo proc proboha?
Vzdyt byt videt je podstatou toho byt na Internetu...
/snajpa
On 30 Oct 2019, at 09:59, V.K. <vencour@gmail.com> wrote:
Je něco proti něčemu dropovat obecně celý provoz z AS patřícího k oné IP adrese? Plus nějaké porty povoluju.
To podle toho, jak se to u mne vyskytuje v logu a podle četnosti.
Vencour
On 30. 10. 19 9:52, zd nex wrote:
Tak jsem to trochu prozkoumal více, vypadá to že je to nějaký scanner. Nyní je neaktivní (na žádném serveru to není) a vypadá to, že přistupuje z více obdobných adres např. - každá z nich je z jiné části Amazonu (routing, compute) apod.. Vše je ale AWS Soul. 54.180.139.105 54.180.138.177 54.180.163.44 54.180.139.105
13.124.8.54 13.125.235.121 13.125.197.34 - tato dokonce je živá a jede tam nějaký mail server
https://www.abuseipdb.com/check/54.180.139.105 https://www.abuseipdb.com/check/13.125.197.34 <https://www.google.com/url?q=https://www.abuseipdb.com/check/13.125.197.34&sa=D&source=hangouts&ust=1572511680416000&usg=AFQjCNEOOO_7Kqh0hzDL5cQBvLnegK-rWA>
podle komentářů to opravdu vypadá na nějaký scanner / SYN flood?
st 30. 10. 2019 v 9:26 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
... tak to prozkoumej, kdyz to rikas ;)
/snajpa
On 30 Oct 2019, at 07:04, zd nex <zdnexnet@gmail.com> wrote:
Ahojte,
popravdě jsem si toho také všiml, je to > vše na 443 nebo 80 portu. Většina adress je Amazon south asia (seoul) + nějaký provider Leaseweb NL, je to na všech serverech. Trochu by to asi stálo za prozkoumání. Není toho moc cca 50 -200. V minulosti to bylo víc, pak to ustálo a asi se to oživuje?
Zdenek út 29. 10 2019 v 19:48 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
Ahoj,
co myslis tim resit na infrastrukture? My Ti do trafficu sahat nebudeme, pokud to nebude prusvih velikosti, jako byl ten prusvih s memcached udp amplification utokama - nic takovyho nepozorujeme; kazdopadne je mozny, ze se zase neco rozmaha (ale podle toho, ze se zatim nezvedla vlna abuse notices, to nevypada).
Kazdopadne se ujisti, ze mas vsechno aktualni - z poslednich dni hlavne napr. PHP-FPM, ktere ma remote code execution diru v urcitych setupech uz od PHP5... a na PHP7 je venku proof of concept exploit.
/snajpa
On 2019-10-29 15:28, Petr Parolek wrote:
Ahoj,
už několik dnů na mé VPS pozoruju mnoho spojení se stavem SYN_RECV
viz: netstat -anp |grep 'SYN_RECV' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n 23 xxx.xxx.xxx.xxx 23 xxx.xxx.xxx.xxx ...
okolo 20 IP adres.
Mám se tím znepokojovat nebo je vše ok a vše by se mělo řešit na infrastruktuře?
Díky moc za postřehy a rady
Petr _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing listCommunity-list@lists.vpsfree.czhttp://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj, včera jsem trochu hledal na internetu a pomohlo mi přidat tyto pravidla ze článku https://javapipe.com/blog/iptables-ddos-protection/ a zdá se, že fungují: ### 1: Drop invalid packets ### /sbin/iptables -t mangle -A PREROUTING -m conntrack --ctstate INVALID -j DROP ### 2: Drop TCP packets that are new and are not SYN ### /sbin/iptables -t mangle -A PREROUTING -p tcp ! --syn -m conntrack --ctstate NEW -j DROP ### 3: Drop SYN packets with suspicious MSS value ### /sbin/iptables -t mangle -A PREROUTING -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP ### 4: Block packets with bogus TCP flags ### /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN FIN,SYN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,RST FIN,RST -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,ACK FIN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,URG URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,FIN FIN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,PSH PSH -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL ALL -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL NONE -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL SYN,FIN,PSH,URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP ### 5: Block spoofed packets ### /sbin/iptables -t mangle -A PREROUTING -s 224.0.0.0/3 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 169.254.0.0/16 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 172.16.0.0/12 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 192.0.2.0/24 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 192.168.0.0/16 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 10.0.0.0/8 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 0.0.0.0/8 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 240.0.0.0/5 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 127.0.0.0/8 ! -i lo -j DROP ### 6: Drop ICMP (you usually don't need this protocol) ### /sbin/iptables -t mangle -A PREROUTING -p icmp -j DROP ### 7: Drop fragments in all chains ### /sbin/iptables -t mangle -A PREROUTING -f -j DROP ### 8: Limit connections per source IP ### /sbin/iptables -A INPUT -p tcp -m connlimit --connlimit-above 111 -j REJECT --reject-with tcp-reset ### 9: Limit RST packets ### /sbin/iptables -A INPUT -p tcp --tcp-flags RST RST -m limit --limit 2/s --limit-burst 2 -j ACCEPT /sbin/iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP ### 10: Limit new TCP connections per second per source IP ### /sbin/iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m limit --limit 60/s --limit-burst 20 -j ACCEPT /sbin/iptables -A INPUT -p tcp -m conntrack --ctstate NEW -j DROP ### 1: Drop invalid packets ### /sbin/iptables -t mangle -A PREROUTING -m conntrack --ctstate INVALID -j DROP ### 2: Drop TCP packets that are new and are not SYN ### /sbin/iptables -t mangle -A PREROUTING -p tcp ! --syn -m conntrack --ctstate NEW -j DROP ### 3: Drop SYN packets with suspicious MSS value ### /sbin/iptables -t mangle -A PREROUTING -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP ### 4: Block packets with bogus TCP flags ### /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN FIN,SYN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,RST FIN,RST -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,ACK FIN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,URG URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,FIN FIN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,PSH PSH -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL ALL -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL NONE -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL SYN,FIN,PSH,URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP ### 5: Block spoofed packets ### /sbin/iptables -t mangle -A PREROUTING -s 224.0.0.0/3 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 169.254.0.0/16 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 172.16.0.0/12 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 192.0.2.0/24 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 192.168.0.0/16 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 10.0.0.0/8 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 0.0.0.0/8 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 240.0.0.0/5 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 127.0.0.0/8 ! -i lo -j DROP ### 6: Drop ICMP (you usually don't need this protocol) ### /sbin/iptables -t mangle -A PREROUTING -p icmp -j DROP ### 7: Drop fragments in all chains ### /sbin/iptables -t mangle -A PREROUTING -f -j DROP ### 8: Limit connections per source IP ### /sbin/iptables -A INPUT -p tcp -m connlimit --connlimit-above 111 -j REJECT --reject-with tcp-reset ### 9: Limit RST packets ### /sbin/iptables -A INPUT -p tcp --tcp-flags RST RST -m limit --limit 2/s --limit-burst 2 -j ACCEPT /sbin/iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP ### 10: Limit new TCP connections per second per source IP ### /sbin/iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m limit --limit 60/s --limit-burst 20 -j ACCEPT /sbin/iptables -A INPUT -p tcp -m conntrack --ctstate NEW -j DROP Petr st 30. 10. 2019 v 10:02 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
Nejlip bude to na Internet nevystavovat v takovym pripade vubec ;)
Nebo jaky je toho duvod? Ja to nechapu. Je smyslem zamezit jakemukoliv dalsimu vyhledavaci, co neni Google, aby vubec vzniknul?
Nebo proc proboha?
Vzdyt byt videt je podstatou toho byt na Internetu...
/snajpa
On 30 Oct 2019, at 09:59, V.K. <vencour@gmail.com> wrote:
Je něco proti něčemu dropovat obecně celý provoz z AS patřícího k oné IP adrese? Plus nějaké porty povoluju.
To podle toho, jak se to u mne vyskytuje v logu a podle četnosti.
Vencour
On 30. 10. 19 9:52, zd nex wrote:
Tak jsem to trochu prozkoumal více, vypadá to že je to nějaký scanner. Nyní je neaktivní (na žádném serveru to není) a vypadá to, že přistupuje z více obdobných adres např. - každá z nich je z jiné části Amazonu (routing, compute) apod.. Vše je ale AWS Soul. 54.180.139.105 54.180.138.177 54.180.163.44 54.180.139.105
13.124.8.54 13.125.235.121 13.125.197.34 - tato dokonce je živá a jede tam nějaký mail server
https://www.abuseipdb.com/check/54.180.139.105 https://www.abuseipdb.com/check/13.125.197.34
podle komentářů to opravdu vypadá na nějaký scanner / SYN flood?
st 30. 10. 2019 v 9:26 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
... tak to prozkoumej, kdyz to rikas ;)
/snajpa
On 30 Oct 2019, at 07:04, zd nex <zdnexnet@gmail.com> wrote:
Ahojte,
popravdě jsem si toho také všiml, je to > vše na 443 nebo 80 portu. Většina adress je Amazon south asia (seoul) + nějaký provider Leaseweb NL, je to na všech serverech. Trochu by to asi stálo za prozkoumání. Není toho moc cca 50 -200. V minulosti to bylo víc, pak to ustálo a asi se to oživuje?
Zdenek út 29. 10 2019 v 19:48 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
Ahoj,
co myslis tim resit na infrastrukture? My Ti do trafficu sahat nebudeme, pokud to nebude prusvih velikosti, jako byl ten prusvih s memcached udp amplification utokama - nic takovyho nepozorujeme; kazdopadne je mozny, ze se zase neco rozmaha (ale podle toho, ze se zatim nezvedla vlna abuse notices, to nevypada).
Kazdopadne se ujisti, ze mas vsechno aktualni - z poslednich dni hlavne napr. PHP-FPM, ktere ma remote code execution diru v urcitych setupech uz od PHP5... a na PHP7 je venku proof of concept exploit.
/snajpa
On 2019-10-29 15:28, Petr Parolek wrote:
Ahoj,
už několik dnů na mé VPS pozoruju mnoho spojení se stavem SYN_RECV
viz: netstat -anp |grep 'SYN_RECV' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n 23 xxx.xxx.xxx.xxx 23 xxx.xxx.xxx.xxx ...
okolo 20 IP adres.
Mám se tím znepokojovat nebo je vše ok a vše by se mělo řešit na infrastruktuře?
Díky moc za postřehy a rady
Petr _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj, můžeš prosím přidat i výpis: iptables -vL aby bylo vidět které pravidlo to "vyřešilo"? Díky MH Dne 30. 10. 19 v 10:08 Petr Parolek napsal(a):
Ahoj,
včera jsem trochu hledal na internetu a pomohlo mi přidat tyto pravidla ze článku https://javapipe.com/blog/iptables-ddos-protection/ a zdá se, že fungují:
### 1: Drop invalid packets ### /sbin/iptables -t mangle -A PREROUTING -m conntrack --ctstate INVALID -j DROP
### 2: Drop TCP packets that are new and are not SYN ### /sbin/iptables -t mangle -A PREROUTING -p tcp ! --syn -m conntrack --ctstate NEW -j DROP
### 3: Drop SYN packets with suspicious MSS value ### /sbin/iptables -t mangle -A PREROUTING -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP
### 4: Block packets with bogus TCP flags ### /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN FIN,SYN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,RST FIN,RST -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,ACK FIN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,URG URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,FIN FIN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,PSH PSH -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL ALL -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL NONE -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL SYN,FIN,PSH,URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
### 5: Block spoofed packets ### /sbin/iptables -t mangle -A PREROUTING -s 224.0.0.0/3 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 169.254.0.0/16 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 172.16.0.0/12 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 192.0.2.0/24 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 192.168.0.0/16 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 10.0.0.0/8 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 0.0.0.0/8 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 240.0.0.0/5 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 127.0.0.0/8 ! -i lo -j DROP
### 6: Drop ICMP (you usually don't need this protocol) ### /sbin/iptables -t mangle -A PREROUTING -p icmp -j DROP
### 7: Drop fragments in all chains ### /sbin/iptables -t mangle -A PREROUTING -f -j DROP
### 8: Limit connections per source IP ### /sbin/iptables -A INPUT -p tcp -m connlimit --connlimit-above 111 -j REJECT --reject-with tcp-reset
### 9: Limit RST packets ### /sbin/iptables -A INPUT -p tcp --tcp-flags RST RST -m limit --limit 2/s --limit-burst 2 -j ACCEPT /sbin/iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP
### 10: Limit new TCP connections per second per source IP ### /sbin/iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m limit --limit 60/s --limit-burst 20 -j ACCEPT /sbin/iptables -A INPUT -p tcp -m conntrack --ctstate NEW -j DROP
### 1: Drop invalid packets ### /sbin/iptables -t mangle -A PREROUTING -m conntrack --ctstate INVALID -j DROP
### 2: Drop TCP packets that are new and are not SYN ### /sbin/iptables -t mangle -A PREROUTING -p tcp ! --syn -m conntrack --ctstate NEW -j DROP
### 3: Drop SYN packets with suspicious MSS value ### /sbin/iptables -t mangle -A PREROUTING -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP
### 4: Block packets with bogus TCP flags ### /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN FIN,SYN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,RST FIN,RST -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,ACK FIN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,URG URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,FIN FIN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,PSH PSH -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL ALL -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL NONE -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL SYN,FIN,PSH,URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
### 5: Block spoofed packets ### /sbin/iptables -t mangle -A PREROUTING -s 224.0.0.0/3 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 169.254.0.0/16 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 172.16.0.0/12 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 192.0.2.0/24 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 192.168.0.0/16 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 10.0.0.0/8 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 0.0.0.0/8 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 240.0.0.0/5 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 127.0.0.0/8 ! -i lo -j DROP
### 6: Drop ICMP (you usually don't need this protocol) ### /sbin/iptables -t mangle -A PREROUTING -p icmp -j DROP
### 7: Drop fragments in all chains ### /sbin/iptables -t mangle -A PREROUTING -f -j DROP
### 8: Limit connections per source IP ### /sbin/iptables -A INPUT -p tcp -m connlimit --connlimit-above 111 -j REJECT --reject-with tcp-reset
### 9: Limit RST packets ### /sbin/iptables -A INPUT -p tcp --tcp-flags RST RST -m limit --limit 2/s --limit-burst 2 -j ACCEPT /sbin/iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP
### 10: Limit new TCP connections per second per source IP ### /sbin/iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m limit --limit 60/s --limit-burst 20 -j ACCEPT /sbin/iptables -A INPUT -p tcp -m conntrack --ctstate NEW -j DROP
Petr
st 30. 10. 2019 v 10:02 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
Nejlip bude to na Internet nevystavovat v takovym pripade vubec ;)
Nebo jaky je toho duvod? Ja to nechapu. Je smyslem zamezit jakemukoliv dalsimu vyhledavaci, co neni Google, aby vubec vzniknul?
Nebo proc proboha?
Vzdyt byt videt je podstatou toho byt na Internetu...
/snajpa
On 30 Oct 2019, at 09:59, V.K. <vencour@gmail.com> wrote:
Je něco proti něčemu dropovat obecně celý provoz z AS patřícího k oné IP adrese? Plus nějaké porty povoluju.
To podle toho, jak se to u mne vyskytuje v logu a podle četnosti.
Vencour
On 30. 10. 19 9:52, zd nex wrote:
Tak jsem to trochu prozkoumal více, vypadá to že je to nějaký scanner. Nyní je neaktivní (na žádném serveru to není) a vypadá to, že přistupuje z více obdobných adres např. - každá z nich je z jiné části Amazonu (routing, compute) apod.. Vše je ale AWS Soul. 54.180.139.105 54.180.138.177 54.180.163.44 54.180.139.105
13.124.8.54 13.125.235.121 13.125.197.34 - tato dokonce je živá a jede tam nějaký mail server
https://www.abuseipdb.com/check/54.180.139.105 https://www.abuseipdb.com/check/13.125.197.34
podle komentářů to opravdu vypadá na nějaký scanner / SYN flood?
st 30. 10. 2019 v 9:26 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
... tak to prozkoumej, kdyz to rikas ;)
/snajpa
On 30 Oct 2019, at 07:04, zd nex <zdnexnet@gmail.com> wrote:
Ahojte,
popravdě jsem si toho také všiml, je to > vše na 443 nebo 80 portu. Většina adress je Amazon south asia (seoul) + nějaký provider Leaseweb NL, je to na všech serverech. Trochu by to asi stálo za prozkoumání. Není toho moc cca 50 -200. V minulosti to bylo víc, pak to ustálo a asi se to oživuje?
Zdenek út 29. 10 2019 v 19:48 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
Ahoj,
co myslis tim resit na infrastrukture? My Ti do trafficu sahat nebudeme, pokud to nebude prusvih velikosti, jako byl ten prusvih s memcached udp amplification utokama - nic takovyho nepozorujeme; kazdopadne je mozny, ze se zase neco rozmaha (ale podle toho, ze se zatim nezvedla vlna abuse notices, to nevypada).
Kazdopadne se ujisti, ze mas vsechno aktualni - z poslednich dni hlavne napr. PHP-FPM, ktere ma remote code execution diru v urcitych setupech uz od PHP5... a na PHP7 je venku proof of concept exploit.
/snajpa
On 2019-10-29 15:28, Petr Parolek wrote:
Ahoj,
už několik dnů na mé VPS pozoruju mnoho spojení se stavem SYN_RECV
viz: netstat -anp |grep 'SYN_RECV' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n 23 xxx.xxx.xxx.xxx 23 xxx.xxx.xxx.xxx ...
okolo 20 IP adres.
Mám se tím znepokojovat nebo je vše ok a vše by se mělo řešit na infrastruktuře?
Díky moc za postřehy a rady
Petr _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Pripada mi to ze uz se reseni tohodle "probemu" dost prehani... Ze na server dorazilo 20 SYN packetu u kterejch nikdo uz neodpovedel na SYN+ACK, no to se proste stava! Az takovejhle spojeni budes mit 20 tisic za vterinu, tak ma smysl se tim zabejvat. Protoze jestli je potreba takhle strasne resit tehle par packetu tak si pust tcpdump nebo wireshark a koukni co na bezny verejny IPv4 adresy chodi v udp a uz neusnes vubec! :D A k tomu firewallu dole v mejlu, branit se na firewallu DDoS utoku firewallem kterej ma nahozenej conntrack, to se muzes rovnou sam strelit do nohy! Z pohledu utocnika kterej chce udelat DoS utok, bych ze zapnutyho conntracku na koncovym serveru mel veeeelikou radost. -- Stanislav Petr
31. 10. 2019 v 10:33, Michal Halenka <michal.halenka@gmail.com>:
Ahoj,
můžeš prosím přidat i výpis: iptables -vL
aby bylo vidět které pravidlo to "vyřešilo"?
Díky MH
Dne 30. 10. 19 v 10:08 Petr Parolek napsal(a):
Ahoj,
včera jsem trochu hledal na internetu a pomohlo mi přidat tyto pravidla ze článku https://javapipe.com/blog/iptables-ddos-protection/ a zdá se, že fungují:
### 1: Drop invalid packets ### /sbin/iptables -t mangle -A PREROUTING -m conntrack --ctstate INVALID -j DROP
### 2: Drop TCP packets that are new and are not SYN ### /sbin/iptables -t mangle -A PREROUTING -p tcp ! --syn -m conntrack --ctstate NEW -j DROP
### 3: Drop SYN packets with suspicious MSS value ### /sbin/iptables -t mangle -A PREROUTING -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP
### 4: Block packets with bogus TCP flags ### /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN FIN,SYN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,RST FIN,RST -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,ACK FIN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,URG URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,FIN FIN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,PSH PSH -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL ALL -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL NONE -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL SYN,FIN,PSH,URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
### 5: Block spoofed packets ### /sbin/iptables -t mangle -A PREROUTING -s 224.0.0.0/3 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 169.254.0.0/16 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 172.16.0.0/12 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 192.0.2.0/24 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 192.168.0.0/16 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 10.0.0.0/8 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 0.0.0.0/8 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 240.0.0.0/5 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 127.0.0.0/8 ! -i lo -j DROP
### 6: Drop ICMP (you usually don't need this protocol) ### /sbin/iptables -t mangle -A PREROUTING -p icmp -j DROP
### 7: Drop fragments in all chains ### /sbin/iptables -t mangle -A PREROUTING -f -j DROP
### 8: Limit connections per source IP ### /sbin/iptables -A INPUT -p tcp -m connlimit --connlimit-above 111 -j REJECT --reject-with tcp-reset
### 9: Limit RST packets ### /sbin/iptables -A INPUT -p tcp --tcp-flags RST RST -m limit --limit 2/s --limit-burst 2 -j ACCEPT /sbin/iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP
### 10: Limit new TCP connections per second per source IP ### /sbin/iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m limit --limit 60/s --limit-burst 20 -j ACCEPT /sbin/iptables -A INPUT -p tcp -m conntrack --ctstate NEW -j DROP
### 1: Drop invalid packets ### /sbin/iptables -t mangle -A PREROUTING -m conntrack --ctstate INVALID -j DROP
### 2: Drop TCP packets that are new and are not SYN ### /sbin/iptables -t mangle -A PREROUTING -p tcp ! --syn -m conntrack --ctstate NEW -j DROP
### 3: Drop SYN packets with suspicious MSS value ### /sbin/iptables -t mangle -A PREROUTING -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP
### 4: Block packets with bogus TCP flags ### /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN FIN,SYN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,RST FIN,RST -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,ACK FIN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,URG URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,FIN FIN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,PSH PSH -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL ALL -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL NONE -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL SYN,FIN,PSH,URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
### 5: Block spoofed packets ### /sbin/iptables -t mangle -A PREROUTING -s 224.0.0.0/3 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 169.254.0.0/16 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 172.16.0.0/12 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 192.0.2.0/24 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 192.168.0.0/16 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 10.0.0.0/8 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 0.0.0.0/8 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 240.0.0.0/5 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 127.0.0.0/8 ! -i lo -j DROP
### 6: Drop ICMP (you usually don't need this protocol) ### /sbin/iptables -t mangle -A PREROUTING -p icmp -j DROP
### 7: Drop fragments in all chains ### /sbin/iptables -t mangle -A PREROUTING -f -j DROP
### 8: Limit connections per source IP ### /sbin/iptables -A INPUT -p tcp -m connlimit --connlimit-above 111 -j REJECT --reject-with tcp-reset
### 9: Limit RST packets ### /sbin/iptables -A INPUT -p tcp --tcp-flags RST RST -m limit --limit 2/s --limit-burst 2 -j ACCEPT /sbin/iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP
### 10: Limit new TCP connections per second per source IP ### /sbin/iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m limit --limit 60/s --limit-burst 20 -j ACCEPT /sbin/iptables -A INPUT -p tcp -m conntrack --ctstate NEW -j DROP
Petr
st 30. 10. 2019 v 10:02 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
Nejlip bude to na Internet nevystavovat v takovym pripade vubec ;)
Nebo jaky je toho duvod? Ja to nechapu. Je smyslem zamezit jakemukoliv dalsimu vyhledavaci, co neni Google, aby vubec vzniknul?
Nebo proc proboha?
Vzdyt byt videt je podstatou toho byt na Internetu...
/snajpa
On 30 Oct 2019, at 09:59, V.K. <vencour@gmail.com> wrote:
Je něco proti něčemu dropovat obecně celý provoz z AS patřícího k oné IP adrese? Plus nějaké porty povoluju.
To podle toho, jak se to u mne vyskytuje v logu a podle četnosti.
Vencour
On 30. 10. 19 9:52, zd nex wrote:
Tak jsem to trochu prozkoumal více, vypadá to že je to nějaký scanner. Nyní je neaktivní (na žádném serveru to není) a vypadá to, že přistupuje z více obdobných adres např. - každá z nich je z jiné části Amazonu (routing, compute) apod.. Vše je ale AWS Soul. 54.180.139.105 54.180.138.177 54.180.163.44 54.180.139.105
13.124.8.54 13.125.235.121 13.125.197.34 - tato dokonce je živá a jede tam nějaký mail server
https://www.abuseipdb.com/check/54.180.139.105 https://www.abuseipdb.com/check/13.125.197.34
podle komentářů to opravdu vypadá na nějaký scanner / SYN flood?
st 30. 10. 2019 v 9:26 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
... tak to prozkoumej, kdyz to rikas ;)
/snajpa
On 30 Oct 2019, at 07:04, zd nex <zdnexnet@gmail.com> wrote:
Ahojte,
popravdě jsem si toho také všiml, je to > vše na 443 nebo 80 portu. Většina adress je Amazon south asia (seoul) + nějaký provider Leaseweb NL, je to na všech serverech. Trochu by to asi stálo za prozkoumání. Není toho moc cca 50 -200. V minulosti to bylo víc, pak to ustálo a asi se to oživuje?
Zdenek út 29. 10 2019 v 19:48 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
Ahoj,
co myslis tim resit na infrastrukture? My Ti do trafficu sahat nebudeme, pokud to nebude prusvih velikosti, jako byl ten prusvih s memcached udp amplification utokama - nic takovyho nepozorujeme; kazdopadne je mozny, ze se zase neco rozmaha (ale podle toho, ze se zatim nezvedla vlna abuse notices, to nevypada).
Kazdopadne se ujisti, ze mas vsechno aktualni - z poslednich dni hlavne napr. PHP-FPM, ktere ma remote code execution diru v urcitych setupech uz od PHP5... a na PHP7 je venku proof of concept exploit.
/snajpa
On 2019-10-29 15:28, Petr Parolek wrote:
Ahoj,
už několik dnů na mé VPS pozoruju mnoho spojení se stavem SYN_RECV
viz: netstat -anp |grep 'SYN_RECV' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n 23 xxx.xxx.xxx.xxx 23 xxx.xxx.xxx.xxx ...
okolo 20 IP adres.
Mám se tím znepokojovat nebo je vše ok a vše by se mělo řešit na infrastruktuře?
Díky moc za postřehy a rady
Petr _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Pro začátek - když se bavíme o spojení ve stavu SYN_RECV - ten paket vůbec nemusel přijít z toho AS. On 30. 10. 19 9:59, V.K. wrote:
Je něco proti něčemu dropovat obecně celý provoz z AS patřícího k oné IP adrese? Plus nějaké porty povoluju.
To podle toho, jak se to u mne vyskytuje v logu a podle četnosti.
Vencour
On 30. 10. 19 9:52, zd nex wrote:
Tak jsem to trochu prozkoumal více, vypadá to že je to nějaký scanner. Nyní je neaktivní (na žádném serveru to není) a vypadá to, že přistupuje z více obdobných adres např. - každá z nich je z jiné části Amazonu (routing, compute) apod.. Vše je ale AWS Soul. 54.180.139.105 54.180.138.177 54.180.163.44 54.180.139.105
13.124.8.54 13.125.235.121 13.125.197.34 - tato dokonce je živá a jede tam nějaký mail server
https://www.abuseipdb.com/check/54.180.139.105 https://www.abuseipdb.com/check/13.125.197.34 <https://www.google.com/url?q=https://www.abuseipdb.com/check/13.125.197.34&sa=D&source=hangouts&ust=1572511680416000&usg=AFQjCNEOOO_7Kqh0hzDL5cQBvLnegK-rWA>
podle komentářů to opravdu vypadá na nějaký scanner / SYN flood?
st 30. 10. 2019 v 9:26 odesílatel Pavel Snajdr <snajpa@snajpa.net <mailto:snajpa@snajpa.net>> napsal:
... tak to prozkoumej, kdyz to rikas ;)
/snajpa
On 30 Oct 2019, at 07:04, zd nex <zdnexnet@gmail.com <mailto:zdnexnet@gmail.com>> wrote:
Ahojte,
popravdě jsem si toho také všiml, je to > vše na 443 nebo 80 portu. Většina adress je Amazon south asia (seoul) + nějaký provider Leaseweb NL, je to na všech serverech. Trochu by to asi stálo za prozkoumání. Není toho moc cca 50 -200. V minulosti to bylo víc, pak to ustálo a asi se to oživuje?
Zdenek út 29. 10 2019 v 19:48 odesílatel Pavel Snajdr <snajpa@snajpa.net <mailto:snajpa@snajpa.net>> napsal:
Ahoj,
co myslis tim resit na infrastrukture? My Ti do trafficu sahat nebudeme, pokud to nebude prusvih velikosti, jako byl ten prusvih s memcached udp amplification utokama - nic takovyho nepozorujeme; kazdopadne je mozny, ze se zase neco rozmaha (ale podle toho, ze se zatim nezvedla vlna abuse notices, to nevypada).
Kazdopadne se ujisti, ze mas vsechno aktualni - z poslednich dni hlavne napr. PHP-FPM, ktere ma remote code execution diru v urcitych setupech uz od PHP5... a na PHP7 je venku proof of concept exploit.
/snajpa
On 2019-10-29 15:28, Petr Parolek wrote: > Ahoj, > > už několik dnů na mé VPS pozoruju mnoho spojení se stavem SYN_RECV > > viz: netstat -anp |grep 'SYN_RECV' | awk '{print $5}' | cut -d: -f1 | > sort | uniq -c | sort -n > 23 xxx.xxx.xxx.xxx > 23 xxx.xxx.xxx.xxx > ... > > okolo 20 IP adres. > > Mám se tím znepokojovat nebo je vše ok a vše by se mělo řešit na > infrastruktuře? > > Díky moc za postřehy a rady > > > Petr > _______________________________________________ > Community-list mailing list > Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> > http://lists.vpsfree.cz/listinfo/community-list _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj, máme podobný návštěvy na jednom projektu. Nejedná se o VPSfree servery, je to projekt se servery v Rakousku. Občas se v nginx access logu objevuje "Cloud mapping experiment. Contact research@pdrlabs.net" -- Lukáš Váňa (fabian) On 30 October 2019 at 09:52:43, zd nex (zdnexnet@gmail.com) wrote: Tak jsem to trochu prozkoumal více, vypadá to že je to nějaký scanner. Nyní je neaktivní (na žádném serveru to není) a vypadá to, že přistupuje z více obdobných adres např. - každá z nich je z jiné části Amazonu (routing, compute) apod.. Vše je ale AWS Soul. 54.180.139.105 54.180.138.177 54.180.163.44 54.180.139.105 13.124.8.54 13.125.235.121 13.125.197.34 - tato dokonce je živá a jede tam nějaký mail server https://www.abuseipdb.com/check/54.180.139.105 https://www.abuseipdb.com/check/13.125.197.34 <https://www.google.com/url?q=https://www.abuseipdb.com/check/13.125.197.34&sa=D&source=hangouts&ust=1572511680416000&usg=AFQjCNEOOO_7Kqh0hzDL5cQBvLnegK-rWA> podle komentářů to opravdu vypadá na nějaký scanner / SYN flood? st 30. 10. 2019 v 9:26 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
... tak to prozkoumej, kdyz to rikas ;)
/snajpa
On 30 Oct 2019, at 07:04, zd nex <zdnexnet@gmail.com> wrote:
Ahojte,
popravdě jsem si toho také všiml, je to > vše na 443 nebo 80 portu. Většina adress je Amazon south asia (seoul) + nějaký provider Leaseweb NL, je to na všech serverech. Trochu by to asi stálo za prozkoumání. Není toho moc cca 50 -200. V minulosti to bylo víc, pak to ustálo a asi se to oživuje?
Zdenek út 29. 10 2019 v 19:48 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
Ahoj,
co myslis tim resit na infrastrukture? My Ti do trafficu sahat nebudeme, pokud to nebude prusvih velikosti, jako byl ten prusvih s memcached udp amplification utokama - nic takovyho nepozorujeme; kazdopadne je mozny, ze se zase neco rozmaha (ale podle toho, ze se zatim nezvedla vlna abuse notices, to nevypada).
Kazdopadne se ujisti, ze mas vsechno aktualni - z poslednich dni hlavne napr. PHP-FPM, ktere ma remote code execution diru v urcitych setupech uz od PHP5... a na PHP7 je venku proof of concept exploit.
/snajpa
On 2019-10-29 15:28, Petr Parolek wrote:
Ahoj,
už několik dnů na mé VPS pozoruju mnoho spojení se stavem SYN_RECV
viz: netstat -anp |grep 'SYN_RECV' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n 23 xxx.xxx.xxx.xxx 23 xxx.xxx.xxx.xxx ...
okolo 20 IP adres.
Mám se tím znepokojovat nebo je vše ok a vše by se mělo řešit na infrastruktuře?
Díky moc za postřehy a rady
Petr _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj, ono by pomohlo i zkontrolovat výpis (32 cpu? 4x víc než přiděleno?) od conntrack-tools ... např. # conntrack -S cpu=0 entries=253 searched=6477 found=1922571 new=216594 invalid=125749 ignore=56794 delete=294449 delete_list=176172 insert=98317 insert_failed=0 drop=0 early_drop=0 icmp_error=125377 expect_new=0 expect_create=0 expect_delete=0 cpu=1 entries=253 searched=1393 found=530132 new=18124 invalid=31 ignore=17394 delete=111863 delete_list=111852 insert=18113 insert_failed=0 drop=0 early_drop=0 icmp_error=4 expect_new=0 expect_create=0 expect_delete=0 cpu=2 entries=253 searched=10696 found=1767389 new=330110 invalid=126079 ignore=30864 delete=339137 delete_list=144911 insert=135884 insert_failed=0 drop=0 early_drop=0 icmp_error=125536 expect_new=0 expect_create=0 expect_delete=0 cpu=3 entries=253 searched=15116 found=3554646 new=338689 invalid=126828 ignore=148946 delete=380967 delete_list=184474 insert=142196 insert_failed=0 drop=0 early_drop=0 icmp_error=125521 expect_new=0 expect_create=0 expect_delete=0 cpu=4 entries=253 searched=10035 found=1548869 new=342939 invalid=126380 ignore=27917 delete=297105 delete_list=101731 insert=147565 insert_failed=0 drop=0 early_drop=0 icmp_error=125763 expect_new=0 expect_create=0 expect_delete=0 cpu=5 entries=253 searched=5346 found=257153 new=135449 invalid=188 ignore=11431 delete=112532 delete_list=34915 insert=57832 insert_failed=0 drop=0 early_drop=0 icmp_error=13 expect_new=0 expect_create=0 expect_delete=0 cpu=6 entries=253 searched=408 found=108223 new=3179 invalid=27 ignore=4626 delete=23704 delete_list=23691 insert=3166 insert_failed=0 drop=0 early_drop=0 icmp_error=1 expect_new=0 expect_create=0 expect_delete=0 cpu=7 entries=253 searched=4468 found=983602 new=188071 invalid=125103 ignore=17795 delete=168153 delete_list=51847 insert=71765 insert_failed=0 drop=0 early_drop=0 icmp_error=124705 expect_new=0 expect_create=0 expect_delete=0 cpu=8 entries=253 searched=1049 found=277266 new=7887 invalid=3 ignore=14849 delete=9600 delete_list=9600 insert=7887 insert_failed=0 drop=0 early_drop=0 icmp_error=0 expect_new=0 expect_create=0 expect_delete=0 cpu=9 entries=253 searched=929 found=197947 new=7437 invalid=3 ignore=10731 delete=8287 delete_list=8287 insert=7437 insert_failed=0 drop=0 early_drop=0 icmp_error=0 expect_new=0 expect_create=0 expect_delete=0 cpu=10 entries=253 searched=231 found=75693 new=3558 invalid=3 ignore=7000 delete=5247 delete_list=5247 insert=3558 insert_failed=0 drop=0 early_drop=0 icmp_error=1 expect_new=0 expect_create=0 expect_delete=0 cpu=11 entries=253 searched=496 found=97357 new=4107 invalid=9 ignore=5501 delete=4421 delete_list=4421 insert=4107 insert_failed=0 drop=0 early_drop=0 icmp_error=0 expect_new=0 expect_create=0 expect_delete=0 cpu=12 entries=253 searched=310 found=35788 new=2183 invalid=5 ignore=4102 delete=2843 delete_list=2843 insert=2183 insert_failed=0 drop=0 early_drop=0 icmp_error=0 expect_new=0 expect_create=0 expect_delete=0 cpu=13 entries=253 searched=82 found=21521 new=1490 invalid=2 ignore=2653 delete=1992 delete_list=1992 insert=1490 insert_failed=0 drop=0 early_drop=0 icmp_error=0 expect_new=0 expect_create=0 expect_delete=0 cpu=14 entries=253 searched=137 found=23261 new=1490 invalid=2 ignore=1784 delete=1625 delete_list=1625 insert=1490 insert_failed=0 drop=0 early_drop=0 icmp_error=0 expect_new=0 expect_create=0 expect_delete=0 cpu=15 entries=253 searched=55 found=9952 new=857 invalid=0 ignore=1680 delete=1185 delete_list=1185 insert=857 insert_failed=0 drop=0 early_drop=0 icmp_error=0 expect_new=0 expect_create=0 expect_delete=0 cpu=16 entries=253 searched=5826 found=351693 new=138139 invalid=147 ignore=17533 delete=100788 delete_list=23756 insert=61107 insert_failed=1 drop=0 early_drop=0 icmp_error=9 expect_new=0 expect_create=0 expect_delete=0 cpu=17 entries=253 searched=10345 found=1172446 new=327121 invalid=125891 ignore=29652 delete=228624 delete_list=34736 insert=133233 insert_failed=0 drop=0 early_drop=0 icmp_error=125288 expect_new=0 expect_create=0 expect_delete=0 cpu=18 entries=253 searched=5489 found=1309259 new=196508 invalid=125754 ignore=22188 delete=165059 delete_list=47384 insert=78833 insert_failed=0 drop=0 early_drop=0 icmp_error=125368 expect_new=0 expect_create=0 expect_delete=0 cpu=19 entries=253 searched=4695 found=1117231 new=195003 invalid=126420 ignore=21675 delete=286973 delete_list=168990 insert=77020 insert_failed=0 drop=0 early_drop=0 icmp_error=126071 expect_new=0 expect_create=0 expect_delete=0 cpu=20 entries=253 searched=430 found=91305 new=3728 invalid=3 ignore=4396 delete=11207 delete_list=11205 insert=3726 insert_failed=0 drop=0 early_drop=0 icmp_error=1 expect_new=0 expect_create=0 expect_delete=0 cpu=21 entries=253 searched=98 found=30599 new=2038 invalid=5 ignore=3166 delete=5839 delete_list=5839 insert=2038 insert_failed=0 drop=0 early_drop=0 icmp_error=0 expect_new=0 expect_create=0 expect_delete=0 cpu=22 entries=253 searched=5146 found=398966 new=133045 invalid=147 ignore=8667 delete=84267 delete_list=6735 insert=55513 insert_failed=1 drop=0 early_drop=0 icmp_error=7 expect_new=0 expect_create=0 expect_delete=0 cpu=23 entries=253 searched=5892 found=312510 new=132864 invalid=136 ignore=8578 delete=83717 delete_list=6423 insert=55570 insert_failed=1 drop=0 early_drop=0 icmp_error=9 expect_new=0 expect_create=0 expect_delete=0 cpu=24 entries=253 searched=701 found=109546 new=2616 invalid=2 ignore=5716 delete=2698 delete_list=2698 insert=2616 insert_failed=0 drop=0 early_drop=0 icmp_error=0 expect_new=0 expect_create=0 expect_delete=0 cpu=25 entries=253 searched=311 found=65923 new=2144 invalid=5 ignore=7936 delete=2544 delete_list=2544 insert=2144 insert_failed=0 drop=0 early_drop=0 icmp_error=0 expect_new=0 expect_create=0 expect_delete=0 cpu=26 entries=253 searched=213 found=39709 new=1665 invalid=20 ignore=4651 delete=1712 delete_list=1712 insert=1665 insert_failed=0 drop=0 early_drop=0 icmp_error=0 expect_new=0 expect_create=0 expect_delete=0 cpu=27 entries=253 searched=62 found=32462 new=2139 invalid=5 ignore=4790 delete=2349 delete_list=2349 insert=2139 insert_failed=0 drop=0 early_drop=0 icmp_error=0 expect_new=0 expect_create=0 expect_delete=0 cpu=28 entries=253 searched=77 found=19951 new=1579 invalid=12 ignore=3399 delete=1619 delete_list=1619 insert=1579 insert_failed=0 drop=0 early_drop=0 icmp_error=0 expect_new=0 expect_create=0 expect_delete=0 cpu=29 entries=253 searched=60 found=15739 new=1353 invalid=2 ignore=2175 delete=1323 delete_list=1323 insert=1353 insert_failed=0 drop=0 early_drop=0 icmp_error=0 expect_new=0 expect_create=0 expect_delete=0 cpu=30 entries=253 searched=40 found=9898 new=999 invalid=4 ignore=1401 delete=1066 delete_list=1066 insert=999 insert_failed=0 drop=0 early_drop=0 icmp_error=0 expect_new=0 expect_create=0 expect_delete=0 cpu=31 entries=253 searched=33 found=9472 new=942 invalid=9 ignore=1322 delete=899 delete_list=899 insert=942 insert_failed=0 drop=0 early_drop=0 icmp_error=0 expect_new=0 expect_create=0 expect_delete=0 conntrack v1.4.5 (conntrack-tools): Operation failed: Invalid argument Přičemž man conntrack -S, --stats Show the in-kernel connection tracking system statistics. A aktuální kernel je: # uname -a Linux hostname 3.16.6-042stab139.44 #1 SMP Sat Aug 17 02:58:37 CEST 2019 x86_64 Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz GenuineIntel GNU/Linux S pozdravem Vencour On 29. 10. 19 15:28, Petr Parolek wrote:
Ahoj,
už několik dnů na mé VPS pozoruju mnoho spojení se stavem SYN_RECV
viz: netstat -anp |grep 'SYN_RECV' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n 23 xxx.xxx.xxx.xxx 23 xxx.xxx.xxx.xxx ...
okolo 20 IP adres.
Mám se tím znepokojovat nebo je vše ok a vše by se mělo řešit na infrastruktuře?
Díky moc za postřehy a rady
Petr _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
participants (10)
-
Jan Pleva -
Jirka Bourek -
Lukas Vana -
Michal Halenka -
Pavel Snajdr -
Petr Parolek -
Stanislav Petr -
V.K. -
Vašek Kratochvíl
-
zd nex