[MEGOLDVA] ismeretlen eredetu kimeno halozati forgalom

Linux-kezdő

Hello,

iptables logban ilyeneket latok, mint eldobalt csomagok, nagyjabol fel orankent 5x ismetlodik (a cel mindig ugyanaz):

IN= OUT=eth0 SRC=[torolve] DST=92.122.212.10 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=58084 DF PROTO=TCP SPT=53643 DPT=80 WINDOW=335 RES=0x00 ACK PSH FIN URGP=0

nem fut bongeszo, semmi auto update es megis... hogyan tudom megfejteni, hogy mifele process probalkozik kifele? Crontab ures. Semelyik log file sem tartalmaz erre utalo nyomot, amit meg probaltam atop log raw fajlba, nethogs, rkhunter, de semmi eredmeny. Valami egyeb otlet esetleg?

  • 1904 megtekintés

( sjrextor | 2010. 12. 23., cs – 18:01 )

Az "lsof -i" kimeneteben nezz korul elso korben!

Esetleg nincs gyanus tartalom a /tmp konyvtarban?

meg is van, ereztem en, hogy a linux kezdo reszbe valo... ennyi ev linux hasznalat utan eleg kellemetlen :(

clock-app 2022 gykovacs 23u IPv4 33022 0t0 TCP collector:54694->a92-122-212-10.deploy.akamaitechnologies.com:http (CLOSE_WAIT)

az immar ismerte valt eredet: /usr/libexec/clock-applet

rakom is at megoldva statuszba.

koszonom :)

( ToNyo | 2010. 12. 23., cs – 18:03 )

ez akamai-s ip szoval valami autoupdate vagy hasonlo lesz megis

( aleb | 2010. 12. 23., cs – 21:13 )

Win 7?
Nekem erre az (92.122.213.50) ip-re inkább letiltottam, mert idgesittően az egész sávszélességemet lefoglalta.

( zeller | 2010. 12. 23., cs – 21:20 )

tcpdump -s 1500 -c 10 -w /tmp/idebele host 92.122.212.10 ; strings /tmp/idebele lehet, hogy mutat valami értelmeset...

( godot v | 2010. 12. 23., cs – 21:42 )

Ez egy FIN ACK csomag, szóval nem kapcsolatfelépítés így magában. Van SYN-es logsor is? A logból nem derül ki, hogy ezt most eldobod, vagy átengeded, illetve jó lenne látni hogyan logolsz. (Direkt a FIN csomagokat is, vagy ez a default DROP szabályra illeszkedő log). Ilyen logsor akkor is keletkezhet, ha a conntrack táblából már eltűnt a kapcsolathoz tartozó bejegyzés, de egy késői FIN ACK még beesett utána. (Alkalmazás bug pl, v nagyon terhelt gép) Ilyenkor nincs conntrack bejegyzés (RELATED, ESTABLISHED), tehát a csomag nem illeszkedik, és mivel a FIN az nem kapcsolatfelépítési csomag ezért eldobódik. A tcpdump-al történő figyelés egy ideig valóban jó ötlet. Illetve a netstat -antp -ben is meg lehet nézni a FIN_WAIT os bejegyzéseket.

Megválaszolom magamnak.

a gweather applet csinálja nekem is.

Ez a csúnya CLOSE_WAIT állapot a progi nem engedi el a socket-et.

CLOSE_WAIT
Indicates that the server has received the first FIN signal from the client and the connection is in the process of being closed

So this essentially means that his is a state where socket is waiting for the application to execute close()

A socket can be in CLOSE_WAIT state indefinitely until the application closes it.
Faulty scenarios would be like filedescriptor leak, server not being execute close() on socket leading to pile up of close_wait sockets

tcp 1 0 192.168.1.104:33252 92.122.206.18:80 CLOSE_WAIT 2247/gweather-applet

( gyko v | 2010. 12. 23., cs – 22:34 )

koszonom mindenkinek (megfejtes fentebb), ma is tanultam valamit :)