>>>> If the machine is running linux, then 'watch "lsof -n|grep TCP|grep >>>> 3680"' as root is a sloppy but effective way to find it. There's >>>> probably some way to set up a firewall rule on the host in question >>>> that logs out the user and (possibly) PID of the connection, but I >>>> don't know. >>> >>> >>> "lsof -i" is easier, it only shows network connections :) >>> >>> catching it when it happens (if it is very briefly connected) could be >>> hard with lsof... Maybe setup a tarpit firewall rule on that box so >>> the connection stays open for a long time. >> >> >> The connections are only attempted a few times throughout the day. Is >> a tarpit firewall rule the only way to do this? Can anyone tell me >> what package 'watch' belongs to if that would work? >> > > `watch` isn't going to help too much unless you're looking at it. Append the > output to some log file instead. I chose netstat because its output looked > easier to parse with a stupid regexp. > > while true; do > netstat -antp | grep ':993 ' >> mystery.log; > sleep 1; > done; > > You'll want to change the port -- I tested to make sure that was really > logging my Thunderbird connections.
I'm still getting the blocked outbound requests to port 3680 on my firewall and I'm running the above script (changed 993 to 3680) on the local system indicated by SRC in the firewall log, but mystery.log remains empty. I tested the script with other ports and it seems to be working fine. Also the MAC indicated in the firewall log is 14 blocks long and the local system in question has a MAC address 6 blocks long according to ifconfig, but the 6 blocks from ifconfig do match 6 of the blocks reported by the firewall. Does this make sense to anyone? I installed and ran rkhunter and this was the only warning I couldn't disregard: Warning: The command '/usr/sbin/rkhunter' has been replaced and is not a script: /usr/sbin/rkhunter: POSIX shell script, ASCII text executable, with very long lines - Grant
