1 |
On Sunday 22 Jan 2012 19:29:47 Grant wrote: |
2 |
> >> > `watch` isn't going to help too much unless you're looking at it. |
3 |
> >> > Append the output to some log file instead. I chose netstat because |
4 |
> >> > its output looked easier to parse with a stupid regexp. |
5 |
> >> > |
6 |
> >> > while true; do |
7 |
> >> > netstat -antp | grep ':993 ' >> mystery.log; |
8 |
> >> > sleep 1; |
9 |
> >> > done; |
10 |
> >> > |
11 |
> >> > You'll want to change the port -- I tested to make sure that was |
12 |
> >> > really logging my Thunderbird connections. |
13 |
> >> |
14 |
> >> I'm still getting the blocked outbound requests to port 3680 on my |
15 |
> >> firewall and I'm running the above script (changed 993 to 3680) on the |
16 |
> >> local system indicated by SRC in the firewall log, but mystery.log |
17 |
> >> remains empty. I tested the script with other ports and it seems to |
18 |
> >> be working fine. |
19 |
> >> |
20 |
> >> Also the MAC indicated in the firewall log is 14 blocks long and the |
21 |
> >> local system in question has a MAC address 6 blocks long according to |
22 |
> >> ifconfig, but the 6 blocks from ifconfig do match 6 of the blocks |
23 |
> >> reported by the firewall. |
24 |
> >> |
25 |
> >> Does this make sense to anyone? |
26 |
> > |
27 |
> > Does not make sense to me, sorry. :-( |
28 |
> |
29 |
> Since my local firewall is rejecting the outbound requests, the time |
30 |
> elapsed between the request and the block should be very short. Is it |
31 |
> possible the 'sleep 1' portion of the script is causing the failure to |
32 |
> log the connection request? The outbound connection is only attempted |
33 |
> a few times per day. If so, how would you recommend fixing that? |
34 |
|
35 |
I'm the wrong guy to make recommendations on any sort of scripting, but if |
36 |
sleep 1 is not enough, could sleep 2 or 3 be adequate to complete writing what |
37 |
it is that is being watched? |
38 |
|
39 |
> I'm also wondering if there is a command I could run on the |
40 |
> router/firewall machine that would log something from the outbound |
41 |
> request. Even if the information logged isn't useful, it would be |
42 |
> nice to see a confirmation of the outbound requests logged from |
43 |
> somewhere besides the firewall. |
44 |
|
45 |
tcpdump will show you what the packets look like and their content if they are |
46 |
unencrypted. However, it may consume tonnes of disk space if you leave |
47 |
running all the time. |
48 |
|
49 |
Have you checked if such connection attempts take place when you start up the |
50 |
machine? If yes it may easier to capture it. |
51 |
-- |
52 |
Regards, |
53 |
Mick |