abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 02:20 | Zajímavý článek

David Revoy, autor open source webového komiksu Pepper&Carrot nebo portrétu GNU/Linuxu, upozorňuje na svém blogu, že nový Inkscape 0.92 rozbíjí dokumenty vytvořené v předchozích verzích Inkscape. Problém by měl být vyřešen v Inkscape 0.92.2 [reddit].

Ladislav Hagara | Komentářů: 0
včera 02:02 | Komunita

Øyvind Kolås, hlavní vývojář grafických knihoven GEGL a babl, které využívá grafický program GIMP, žádá o podporu na Patreonu. Díky ní bude moci pracovat na vývoji na plný úvazek. Milník 1000 $, který by stačil na holé přežití, se již téměř podařilo vybrat, dalším cílem je dosažení 2500 $, které mu umožní běžně fungovat ve společnosti.

xkomczax | Komentářů: 12
21.1. 23:54 | Pozvánky

DevConf.cz 2017, již devátý ročník jedné z největších akcí zaměřených na Linux a open source ve střední Evropě, proběhne od pátku 27. ledna do neděle 29. ledna v prostorách Fakulty informačních technologií Vysokého učení technického v Brně. Na programu je celá řada zajímavých přednášek a workshopů. Letos je povinná registrace.

Ladislav Hagara | Komentářů: 0
21.1. 22:11 | Nová verze

Byla vydána verze 1.0.0 emulátoru terminálu Terminology postaveného nad EFL (Enlightenment Foundation Libraries). Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
20.1. 17:00 | Nová verze

Byl vydán Docker 1.13. Přehled novinek na YouTube a v poznámkách k vydání na GitHubu. Docker umožňuje běh aplikací v softwarových kontejnerech (Wikipedia).

Ladislav Hagara | Komentářů: 4
20.1. 15:51 | Komunita

Mozilla.cz informuje, že nástroje pro webové vývojáře se možná oddělí od Firefoxu a stanou doplňkem. Nástroje pro webové vývojáře prošly velkým přepisem a tým, který se stará o jejich vývoj, by uvítal možnost jejich častějších aktualizacích nezávisle na vydávání nových verzí Firefoxu.

Ladislav Hagara | Komentářů: 10
20.1. 07:00 | Humor

Čtenářům AbcLinuxu vše nejlepší k dnešnímu Dni zvýšení povědomí o tučňácích (Penguin Awareness Day).

Ladislav Hagara | Komentářů: 0
20.1. 06:00 | Komunita

Bylo spuštěno hlasování o přednáškách a workshopech pro letošní InstallFest, jenž proběhne o víkendu 4. a 5. března v Praze. Současně byla oznámena změna místa. InstallFest se letos vrací zpět na Karlovo náměstí do budovy E.

Ladislav Hagara | Komentářů: 0
20.1. 02:48 | Komunita

Greg Kroah-Hartman potvrdil, že Linux 4.9 je jádrem s prodlouženou upstream podporou (LTS, Long Term Support). Podpora je plánována do ledna 2019. Aktuální jádra s prodlouženou podporou jsou tedy 3.2, 3.4, 3.10, 3.12, 3.16, 3.18, 4.1, 4.4 a 4.9.

Ladislav Hagara | Komentářů: 0
20.1. 00:11 | Zajímavý článek

Výrobce síťových prvků, společnost Netgear, spustila nový program, který slibuje vývojářům, expertům, ale i běžným uživatelům vyplacení finanční odměny za nalezení bezpečnostních chyby v jejich produktech. Za nalezení zranitelnosti v hardware, API nebo mobilní aplikaci nabízí odměnu od 150 do 15 tisíc dolarů (dle závažnosti).

Michal Makovec | Komentářů: 0
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (10%)
 (2%)
 (74%)
 (3%)
 (10%)
Celkem 363 hlasů
 Komentářů: 25, poslední 21.1. 13:34
Rozcestník
Reklama

Dotaz: Diagnostika priciny dst cache overflow

19.2.2013 15:48 student
Diagnostika priciny dst cache overflow
Přečteno: 292×

Nazdar - neviete prosim, ako zistit presnu pricinu takychto hlasok? Tusim nejaky utok, ale viac neviem:

[5805319.745570] net_ratelimit: 1252 callbacks suppressed

[5805319.745572] dst cache overflow

 

Raz za cas mi vyskocia, traffic k serveru sa zdvihne tak na 2-5 minut na cca 10 nasobok (z ~20Mbps na ~200Mbps; opacny smer sa nemeni), load mi stupne z 2-3 na okolo 25 a zacne to pisat toto pomerne dost rychlo (a velakrat). Vsetko, bohuzial, logovat nemozem, lebo aj pri beznom trafficu je to vela dat a problem sa vyskytuje len naozaj sporadicky (ale aj tak mna stve). Pocas tohoto sa naviac obycajne ani nemozem pripojit k serveru, aby som presne zistil, o co ide.

Mate nejaky tip, ako to diagnostikovat a pripadne riesit? Idealne by bolo, aby to same naplno nevytazilo stroj (tj nieco ako regexp na kazdy paket nie je dobre riesenie)

Iptables mam, loguju a dropuju velke mnozstvo connection z 1 IP (-m connlimit) na moje sluzby / otvorene porty, neobycajne pakety a pod, ale tu nic take nezachytili.

Odpovědi

19.2.2013 18:03 NN
Rozbalit Rozbalit vše Re: Diagnostika priciny dst cache overflow
Muzes poslat konifguraci firewallu vecetne uprav /proc/ a routovaci tabulku..
19.2.2013 18:56 student
Rozbalit Rozbalit vše Re: Diagnostika priciny dst cache overflow

 

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         94.229.35.129   0.0.0.0         UG    100    0        0 eth0
94.229.35.128   0.0.0.0         255.255.255.224 U     0      0        0 eth0

 

IPtables:

iptables -F
iptables -X
iptables -I INPUT -i lo -j ACCEPT

#drop spoofed packets from private subnets
iptables -A INPUT -i eth0 --src 192.168.0.0/16 -j DROP
iptables -A INPUT -i eth0 --src 172.16.0.0/12 -j DROP
iptables -A INPUT -i eth0 --src 10.0.0.0/8 -j DROP
iptables -A INPUT -i eth0 --src 127.0.0.0/8 -j DROP

iptables -N logdrop
iptables -A logdrop -m limit --limit 1/hour --limit-burst 5  -j LOG --log-prefix "Logdrop: "
iptables -A logdrop -j DROP

iptables -N pscanblock
iptables -A pscanblock -m limit --limit 1/min -j LOG --log-prefix "Blocking portscan: "
iptables -A pscanblock -m recent --set --name portscan

#drop invalid
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

#let it be... (when it works, then it is OK)

iptables -I INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT

#ssh
iptables -A INPUT -p tcp -m tcp --dport 22 -s 1.2.3.4 -j ACCEPT #ja, upravene
iptables -A INPUT -p tcp -m tcp --dport 22 -j REJECT
ip6tables -A INPUT -p tcp -m tcp --dport 22 -j REJECT


#block smtp
iptables -A INPUT -p tcp -m tcp --dport 25 -j TARPIT
ip6tables -A INPUT -p tcp -m tcp --dport 25 -j DROP


#ntp with some exceptions
iptables -A INPUT -p udp -m udp --dport 123 -s 195.113.144.201 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 123 -s 147.231.19.43 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 123 -s 193.171.23.163 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 123 -s 80.50.231.226 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 123 -s 83.19.137.3 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 123 -j REJECT
ip6tables -A INPUT -p udp -m udp --dport 123 -j REJECT


################ CONNLIMITS ####################################3

iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 30 -m limit --limit 1/hour --limit-burst 5  -j LOG  --log-prefix " Too much connections "
iptables -A INPUT -p tcp --dport 443 -m connlimit --connlimit-above 30 -m limit --limit 1/hour --limit-burst 5  -j LOG  --log-prefix " Too much connections "
iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 30 -j TARPIT
iptables -A INPUT -p tcp --dport 443 -m connlimit --connlimit-above 30 -j TARPIT

#block too many connections
iptables -A INPUT -p tcp --dport 23000:30001 -m connlimit --connlimit-above 20 -j LOG --log-prefix " Too much connections "
iptables -A INPUT -p tcp --dport 23000:30001  -m connlimit --connlimit-above 3 -j LOG --log-prefix "CONNLIMIT: " --log-level debug

#block invalid packets
iptables -A INPUT -p udp --dport 23000:30001 -m length --length 0:28  -m limit --limit 1/hour --limit-burst 5 -j LOG --log-prefix " Small_packets "
iptables -A INPUT -p udp --dport 23000:30001 -m length --length 0:28 -j DROP

#deny or log everything 60 (can be 3600 or so) seconds after portscan
iptables -A INPUT -m recent --name portscan --rcheck --seconds 60 -j DROP # LOG --log-prefix "Pscantest: "
iptables -A INPUT -p tcp -m recent --name portscan --remove

iptables -A INPUT -p tcp ! --dport 80 -m state --state new -m recent --set --name NEWCONN
iptables -A INPUT -p tcp -m recent --update --seconds 10 --hitcount 10 --rttl --name NEWCONN -j pscanblock

 

Upravy proc (sysctl; ine upravy asi nemam):

net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv4.tcp_timestamps = 0

19.2.2013 19:00 student
Rozbalit Rozbalit vše Re: Diagnostika priciny dst cache overflow

Este som nenapisal (aj ked to je asi jasne), ze tcp_syncookies, tj. casto pisane odporucanie mam default, teda 1.

19.2.2013 21:58 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Diagnostika priciny dst cache overflow
Zajímavější bude obsah směrovací cache. Stačí počet záznamů (ip route list cache). Především porovnat v klidu a popisované zátěži.
20.2.2013 02:59 student
Rozbalit Rozbalit vše Re: Diagnostika priciny dst cache overflow
Vdaka, po tej zatazi porovnam.
19.2.2013 23:04 NN
Rozbalit Rozbalit vše Re: Diagnostika priciny dst cache overflow
Metrika 100 u default route ma nejaky zvlastni duvod ? To by mohla byt pricina te druhe hlasky.

Ta prvni hlaska bude diky rozesranemu modulu na limit spojeni diky tomu gulasi tech pravidel.

Asi to bude chtit nak zjednodusit a sledovat, mozna si najdu zitra cas zkontrolovat vsechny ty omezovaci pravidla jestli nekde neni nejake, ktere se da "vydosovat".
20.2.2013 02:48 student
Rozbalit Rozbalit vše Re: Diagnostika priciny dst cache overflow

Metrika 100 nema ziadny dovod; je to tak "by default" (nemenil som to umyselne). Ale neviem, comu moze vadit - ved to by malo rozhodovat len pri rovnako cenenych routach, nie?

Potom pripadne aspon na prvy pohlad - co je na tych pravidlach "gulasoidne"?

19.2.2013 23:07 NN
Rozbalit Rozbalit vše Re: Diagnostika priciny dst cache overflow
Btw. mam tcp_syncookies v default na 0 a abych priznal z hlavy nevim co to dela..
20.2.2013 02:51 student
Rozbalit Rozbalit vše Re: Diagnostika priciny dst cache overflow
Co som cital, tak by to malo zlepsovat chovanie pri SYN floode tak, ze prakticky zacne ignorovat SYN a domysli si ich obsah. V logu ale zavedenie SYN cookies nemam, takze pravdepodobne neslo o SYN flood.
20.2.2013 01:22 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Diagnostika priciny dst cache overflow

Pravděpodobně bude potřeba zvýšit hodnoty

  /proc/sys/net/ipv4/route/gc_thresh
  /proc/sys/net/ipv4/route/max_size

tak, aby se celkový počet dst_entry položek udržoval kolem gc_thresh (nebo níž) a v žádném případě nedosahoval k max_size. Aktuální počet najdete v /proc/net/stats/rt_cache jako "entries" (šestnáctkově, měla by to být první hodnota na řádku, na každém stejná).

20.2.2013 02:58 student
Rozbalit Rozbalit vše Re: Diagnostika priciny dst cache overflow
Vdaka; momentalne som mimo utoku, takze to musim skusit asi az ked to znova nastane. Pri beznej prevadzke ako je to teraz ten pocet uplne staci (asi tak 500x viac dst_entry by muselo byt, aby som dosiahol na gc_thresh, ktory je cca 15x mensi ako max_size).

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.