1 |
>> > `watch` isn't going to help too much unless you're looking at it. Append |
2 |
>> > the output to some log file instead. I chose netstat because its output |
3 |
>> > looked easier to parse with a stupid regexp. |
4 |
>> > |
5 |
>> > while true; do |
6 |
>> > netstat -antp | grep ':993 ' >> mystery.log; |
7 |
>> > sleep 1; |
8 |
>> > done; |
9 |
>> > |
10 |
>> > You'll want to change the port -- I tested to make sure that was really |
11 |
>> > logging my Thunderbird connections. |
12 |
>> |
13 |
>> I'm still getting the blocked outbound requests to port 3680 on my |
14 |
>> firewall and I'm running the above script (changed 993 to 3680) on the |
15 |
>> local system indicated by SRC in the firewall log, but mystery.log |
16 |
>> remains empty. I tested the script with other ports and it seems to |
17 |
>> be working fine. |
18 |
>> |
19 |
>> Also the MAC indicated in the firewall log is 14 blocks long and the |
20 |
>> local system in question has a MAC address 6 blocks long according to |
21 |
>> ifconfig, but the 6 blocks from ifconfig do match 6 of the blocks |
22 |
>> reported by the firewall. |
23 |
>> |
24 |
>> Does this make sense to anyone? |
25 |
> |
26 |
> Does not make sense to me, sorry. :-( |
27 |
|
28 |
Since my local firewall is rejecting the outbound requests, the time |
29 |
elapsed between the request and the block should be very short. Is it |
30 |
possible the 'sleep 1' portion of the script is causing the failure to |
31 |
log the connection request? The outbound connection is only attempted |
32 |
a few times per day. If so, how would you recommend fixing that? |
33 |
|
34 |
I'm also wondering if there is a command I could run on the |
35 |
router/firewall machine that would log something from the outbound |
36 |
request. Even if the information logged isn't useful, it would be |
37 |
nice to see a confirmation of the outbound requests logged from |
38 |
somewhere besides the firewall. |
39 |
|
40 |
- Grant |