| View previous topic :: View next topic |
| Author |
Message |
alex.blackbit
Advocate
Joined: 26 Jul 2005
Posts: 2397
|
 Posted: Wed Apr 13, 2011 7:50 am Post subject: how to identify the origin of a paket |
 |
|
hi,
i use shorewall on my internet gateway.
there i get log messages like these: | Code: | Apr 13 09:08:13 net4801 kernel: [1720895.203628] Shorewall:FORWARD:REJECT:IN=eth1 OUT=ppp0 SRC=192.168.0.2 DST=192.168.178.21 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=392 DF PROTO=TCP SPT=55963 DPT=1024 WINDOW=14600 RES=0x00 SYN URGP=0
Apr 13 09:08:13 net4801 kernel: [1720895.204976] Shorewall:FORWARD:REJECT:IN=eth1 OUT=ppp0 SRC=192.168.0.2 DST=192.168.178.21 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=14767 DF PROTO=TCP SPT=55964 DPT=1024 WINDOW=14600 RES=0x00 SYN URGP=0
Apr 13 09:08:19 net4801 kernel: [1720901.198082] Shorewall:FORWARD:REJECT:IN=eth1 OUT=ppp0 SRC=192.168.0.2 DST=192.168.178.21 LEN=56 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=55878 DPT=1024 LEN=36
Apr 13 09:37:49 net4801 kernel: [1722672.005149] Shorewall:FORWARD:REJECT:IN=eth1 OUT=ppp0 SRC=192.168.0.2 DST=192.168.178.21 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=7598 DF PROTO=TCP SPT=36471 DPT=1024 WINDOW=14600 RES=0x00 SYN URGP=0
Apr 13 09:37:49 net4801 kernel: [1722672.008780] Shorewall:FORWARD:REJECT:IN=eth1 OUT=ppp0 SRC=192.168.0.2 DST=192.168.178.21 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=2041 DF PROTO=TCP SPT=36472 DPT=1024 WINDOW=14600 RES=0x00 SYN URGP=0
Apr 13 09:37:55 net4801 kernel: [1722677.311320] Shorewall:FORWARD:REJECT:IN=eth1 OUT=ppp0 SRC=192.168.0.2 DST=192.168.178.21 LEN=56 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=55878 DPT=1024 LEN=36 |
192.168.0.2 is my workstation.
the subnet 192.168.178.0 is not in use on my LAN.
i am searching for a way to identify which process emits those packets.
i tried with tcpspy which seems to miss those packets.
lsof does not help either.
who knows a way to log the process ID/name of packets that match certain criteria? in this case that would be the destination ip. |
|
| Back to top |
|
 |
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Wed Apr 13, 2011 10:37 am Post subject: |
|
|
as it just query another local network ip, it might just be an application that was bind to that ip and you forget about it
as it query an answer from that ip port 1024 just check who is listening at 1024 (i suspect the query comes from the application that is also listening)
netstat --listen and look who's at 1024 (if anyone is there of 'course) |
|
| Back to top |
|
|
alex.blackbit
Advocate
Joined: 26 Jul 2005
Posts: 2397
|
| Posted: Wed Apr 13, 2011 1:46 pm Post subject: |
|
|
there is no ip 192.168.178.21 in my network, nothing in 192.168.178.0/24.
i don't understand what you mean regarding the destination port 1024.
on my workstation nothing is listening on 1024.
answer ? you think these are answer packets ?
why would the initial packets not have been logged?
please clarify.
EDIT: typo
Last edited by alex.blackbit on Wed Apr 13, 2011 5:58 pm; edited 1 time in total |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Wed Apr 13, 2011 2:59 pm Post subject: |
|
|
yep i think they are answers from a spoof query forged so your computer answer to that ip, and to port number 1024.
a simple icmp is enough for that, and the query might appears legit at first. |
|
| Back to top |
|
|
alex.blackbit
Advocate
Joined: 26 Jul 2005
Posts: 2397
|
| Posted: Wed Apr 13, 2011 6:00 pm Post subject: |
|
|
do have any ideas how i could find out where the problem comes from?
i.e. what host initially emitted the suspicious packet to which my workstation (192.168.0.2) answers. |
|
| Back to top |
|
|
Veldrin
Veteran
Joined: 27 Jul 2004
Posts: 1945
Location: Zurich, Switzerland
|
| Posted: Wed Apr 13, 2011 6:43 pm Post subject: |
|
|
Depends on how the setup is.
I'd definitely get a tcpdump from your own workstation, and if it is just to confirm that you are not the source...
Then either get another tcpdump from the firewall itself.
Finally, analyse both dumps in wireshark.
This should get you started; just replace IF, with the interface you are listening on (should be eth1 on the firewall), and omit -w /tmp/tcpdump to see the dump direly on the CLI.
| Code: | | # tcpdump -nnvvi IF -w /tmp/tcpdump host 192.168.178.21 and host 192.168.0.2 and port 1024 |
V.
_________________
read the portage output!
If my answer is too concise, ask for an explanation. |
|
| Back to top |
|
|
alex.blackbit
Advocate
Joined: 26 Jul 2005
Posts: 2397
|
| Posted: Thu Apr 14, 2011 11:28 pm Post subject: |
|
|
in the mean time i found out that it's transmission that causes these packets.
the packets have the same source port for some time, so i checked that with lsof.
i will move to a different torrent client to see if it's a problem of the protocol or transmission itself.
thank you all. |
|
| Back to top |
|
|
|
Networking & Security
