Dotaz: Prosim o vysvetlenie zaznamu zo suboru messages

[truhlik]

v subore messages mam tento riadok:

Feb 2 08:15:48 webserver kernel: Shorewall:newnotsyn:DROP:IN=eth0 OUT= MAC=00:60:97:96:db:8d:00:30:84:a6:4d:8e:08:00 SRC=212.80.76.58 DST=$OUR_IP LEN=40 TOS=0x00 PREC=0x00 TTL=57 ID=4159 DF PROTO=TCP SPT=80 DPT=33407 WINDOW=65535 RES=0x00 ACK FIN URGP=0

ktory sa mi opakuje kazde dve minuty cely den, DPT je vzdy iny...
traceroute mi ukazal jednu ip za serverom seznam.cz, na sezname mi povedali, ze je to ich server, z ktoreho sa neda ani pingnut....
viete mi to niekto prelozit do ludskej reci? :o)
vdaka za vsetky odpovede
vb.

Odpovědi

[Zdeněk Štěpánek]

Zdravim

Shorewall je jakasi automatizujici nadstavba nad iptables. Doporucuju vypnout/zahodit/smazat a napsat si firewall rucne, je to lepsi.

Zdenek

[truhlik]

mne nejde ani tak o shorewall, pretoze ten webserver je este za hardverovym routrom v DMZ.
chcem vediet o co sa snazi ten pocitac s uvedenou ip adresou.

[Hynek (Pichi) Vychodil]

No já se v tomhle moc nevyznám, ale vypadá to jako nějaká nekorektní odpověď webserveru.

newnotsyn - notsyn paket, není to pokračování žádného povoleného spojení

PROTO=TCP SPT=80 DPT=33407 - proces který to odesílá je/byl root (aspoň při startu), a pravděpodobně webserver. Kdyby byl ten paket akceptován tak bych ho považoval za odpověď na nějaký požadavek o webovou stránku na tom serveru. Zvláštní je, že je tak vytrvalý, nomálně by to měl už dávno vzdát a považovat to za chcíplého clienta. Možná bych skusil tohle pravidlo co to loguje změnit na REJECT místo DROP a pokud s tím nepřestane, tak je to pokažené

P.S.: Já se v tom ale fakt nevyznám, tohle je jen z mých velmi chabých znalostí, tak doufám, že se tu moc neztrapňuju.

[Beda]

lidsky? ehm to asi nepujde nikdy.

prisel ti tcp(PROTO=) paket. chtel byt doruceny na cil(DST=) a tcp port(DPT=). nekdu mu bud prikraslil nebo jsou to skutecny(50:50 - to nelze u ipv4 rict s jistotou) hodnoty odchozi ip(SRC=) stroje a odchoziho tcp portu(SPT=). v tcp hlavicce mel jeste nastaveny bity v tcp flags(ACK rika, ze je platna hodnota v poli sekvencniho cisla pro potvrzeni prijeti paketu s takovym tcp sekvencnim cislem a FIN rika, ze zavira z jeho strany spojeni) v datech paketu nezacinaji prednostni data, ktera by mohly v socketu predbehnout jina drive prijata na temze socketu(URGP=) LEN= rika, ze je to minimalni ip hlavicka + tcp halvicka a prazdna data. TOS= a PREC=, ze se nechce specialni zachazeni po ceste skrz tvuj router. TTL= - spocitej si, kolik mas hop-u ke zdroji a jestli se lisi o >3 od (google:ttl os defaults) tak to bude jen nepatrne divnej paket. no DF bit v ip hlavicce rika, ze se paket nema fragmentovat a da se podle nej odhadovat, ze posilajici pouziva pMTU discovery. id a res naprosto nic nerikajici pole. WINDOW= je velikost tcp okna - kolik bytu se muze poslat bez prijeti potvrzeni. MAC, IN, OUT - zkontroluj prichozi sitovou adresu (1. 1/2 mac cisla bez ukoncovaci dvojnuly (00:60:97:96:db:8d)), abys vedel, ktera ethernetova sitofka to poslala. prijalo to zarizeni v IN a neodchazelo to zadnym zarizenim OUT=. firewall s tim provedl zahozeni bez odpovedi DROP. ID a RES? asi naprosto k nicemu cisla.

[Beda]

blbost - DROP... to je trosku jinak. newnotsyn:DROP: je logprefix, ktery si kazdy muze napsat jak chce... jestli autor shorewallu to napsal aspon trosku tak, jak pojmenoval prefixy, tak se z toho da uvazovat, ze se v nasledujicim pravidle po zalogovani paket zahodi, protoze nebyl asociovan s zadnym existujicim spojenim.

[truhlik]

dakujem za vsetky odpovede.
presne to som potreboval.