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
On Sunday 22 Jan 2012 17:54:29 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 '
On 01/22/2012 12:54 PM, 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;
`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
`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
`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
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
On 01/22/2012 02:29 PM, Grant wrote:
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
On Sun, Jan 22, 2012 at 2:29 PM, Grant emailgr...@gmail.com 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
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.
On Sunday 22 Jan 2012 20:26:13 Grant wrote:
I just started running this on the router:
tcpdump -i eth1 -n | grep the.offending.ip.address
where eth1 is my LAN interface. I figure this will tell me if any
requests are being made to the offending IP, including any that aren't
being logged
On Jan 23, 2012 12:57 AM, Grant emailgr...@gmail.com wrote:
- 8 snip
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
On Jan 23, 2012 12:10 PM, Pandu Poluan pa...@poluan.info wrote:
On Jan 23, 2012 12:57 AM, Grant emailgr...@gmail.com wrote:
- 8 snip
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
My firewall is blocking periodic outbound connections to port 3680 on
a Rackspace IP. How can I find out more about what's going on? Maybe
which program is generating the connection requests?
- Grant
On 20 January 2012, at 18:34, Grant wrote:
My firewall is blocking periodic outbound connections to port 3680 on
a Rackspace IP. How can I find out more about what's going on? Maybe
which program is generating the connection requests?
Uh, a packet sniffer?
I have an old laptop here that I
My firewall is blocking periodic outbound connections to port 3680 on
a Rackspace IP. How can I find out more about what's going on? Maybe
which program is generating the connection requests?
Uh, a packet sniffer?
I have an old laptop here that I have a second (cardbus) network card in.
On Friday 20 Jan 2012 19:18:59 Grant wrote:
My firewall is blocking periodic outbound connections to port 3680 on
a Rackspace IP. How can I find out more about what's going on? Maybe
which program is generating the connection requests?
Uh, a packet sniffer?
I have an old laptop
My firewall is blocking periodic outbound connections to port 3680 on
a Rackspace IP. How can I find out more about what's going on? Maybe
which program is generating the connection requests?
Uh, a packet sniffer?
I have an old laptop here that I have a second (cardbus) network
On Fri, Jan 20, 2012 at 5:32 PM, Grant emailgr...@gmail.com wrote:
My firewall is blocking periodic outbound connections to port 3680 on
a Rackspace IP. How can I find out more about what's going on? Maybe
which program is generating the connection requests?
Uh, a packet sniffer?
I
My firewall is blocking periodic outbound connections to port 3680 on
a Rackspace IP. How can I find out more about what's going on? Maybe
which program is generating the connection requests?
Uh, a packet sniffer?
I have an old laptop here that I have a second (cardbus) network
On Fri, Jan 20, 2012 at 5:27 PM, Michael Mol mike...@gmail.com wrote:
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
On Friday 20 Jan 2012 23:34:12 Grant wrote:
My firewall is blocking periodic outbound connections to port 3680
on a Rackspace IP. How can I find out more about what's going on?
Maybe which program is generating the connection requests?
Uh, a packet sniffer?
I have an old
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 21.01.2012 01:12, Grant wrote:
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
On 01/20/2012 07:12 PM, Grant wrote:
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,
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
On Fri, Jan 20, 2012 at 6:34 PM, Grant emailgr...@gmail.com wrote:
My firewall is blocking periodic outbound connections to port 3680 on
a Rackspace IP. How can I find out more about what's going on? Maybe
which program is generating the connection requests?
Uh, a packet sniffer?
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 21.01.2012 02:39, Michael Mol wrote:
On Fri, Jan 20, 2012 at 6:34 PM, Grant emailgr...@gmail.com
wrote:
My firewall is blocking periodic outbound connections
to port 3680 on a Rackspace IP. How can I find out
more about what's going on?
28 matches
Mail list logo
