On Sunday 22 Jan 2012 19:29:47 Grant wrote:
> >> > `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?
> > 
> > Does not make sense to me, sorry.  :-(
> 
> Since my local firewall is rejecting the outbound requests, the time
> elapsed between the request and the block should be very short.  Is it
> possible the 'sleep 1' portion of the script is causing the failure to
> log the connection request?  The outbound connection is only attempted
> a few times per day.  If so, how would you recommend fixing that?

I'm the wrong guy to make recommendations on any sort of scripting, but if 
sleep 1 is not enough, could sleep 2 or 3 be adequate to complete writing what 
it is that is being watched?

> I'm also wondering if there is a command I could run on the
> router/firewall machine that would log something from the outbound
> request.  Even if the information logged isn't useful, it would be
> nice to see a confirmation of the outbound requests logged from
> somewhere besides the firewall.

tcpdump will show you what the packets look like and their content if they are 
unencrypted.  However, it may consume tonnes of disk space if you leave 
running all the time.

Have you checked if such connection attempts take place when you start up the 
machine?  If yes it may easier to capture it.
-- 
Regards,
Mick

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to