How to troubleshoot this?
jared
E.g.,
Tue Dec 05 15:54:56 2006 Blocked outgoing TCP packet from
192.168.0.14:50011
to 69.28.154.159:80 as FIN:ACK received but there is no active
connection
The address appears to belong to GoDaddy. I see different IP addresses
(all appearing to belong to GoDaddy) trying to communicate at various
times, all using different ports on the local side (i.e., not always
50011 - although always unprivileged and not well-known).
I am running Ubuntu 6.10 on this machine (a workstation, not a server),
patched up daily, chkrootkit run weekly. I do not leave any browsers
or mail clients open when I am off the machine (and in fact, was away
at the time of this entry). I don't think I can use netstat because
the ports always vary.
The only strange thing I see in netstat is a number of processes
running out of /tmp with strange appellations. E.g.:
/tmp/ssh-VNQcrB5688/agent.5688
/tmp/ssh-aqsysH5731/agent.5731
/tmp/ssh-HtJGjx5731/agent.5731
(I happen to pick ssh as I have only one connection, character-based,
right now. I could see one process for the server listening and
another for the session, but what might the third one be? But this is
not a question on ssh operation, just an example of the weird
appellations I see in netstat).
Is there a way to figure out which process is connecting to GoDaddy?
Thanks in advance -
Kind regards,
jh
ynotssor
jared <ja...@hwai.com> wrote:
> I am seeing a type of message appear repeatedly in my firewall logs.
> E.g.,
>
> Tue Dec 05 15:54:56 2006 Blocked outgoing TCP packet from
> 192.168.0.14:50011
> to 69.28.154.159:80 as FIN:ACK received but there is no active
> connection
...
> Is there a way to figure out which process is connecting to GoDaddy?
If you can monitor the log (perhaps via cron) for such an entry and execute
(perhaps in your cron script):
# netstat -pan
and/or
# lsof -i
then you could see in the output what process is using the port.
Jeroen Geilman
> I am seeing a type of message appear repeatedly in my firewall logs.
> E.g.,
>
> Tue Dec 05 15:54:56 2006 Blocked outgoing TCP packet from
> 192.168.0.14:50011
> to 69.28.154.159:80 as FIN:ACK received but there is no active
> connection
My first question would be: what kind of firewall ?
If it is a SOHO-type firewall appliance, or iptables on your own box, why
would it block outgoing TCP at all ?
Do you control this ? Do you manage it ?
> The address appears to belong to GoDaddy. I see different IP addresses
> (all appearing to belong to GoDaddy) trying to communicate at various
> times, all using different ports on the local side (i.e., not always
> 50011 - although always unprivileged and not well-known).
But all connecting to port 80 on the other side ?
> I am running Ubuntu 6.10 on this machine (a workstation, not a server),
> patched up daily, chkrootkit run weekly. I do not leave any browsers
> or mail clients open when I am off the machine (and in fact, was away
> at the time of this entry). I don't think I can use netstat because
> the ports always vary.
That depends; if the destination ports do not, simply keep tcpdump running
until you get a few of these "connections" and examine the output.
Yes, I say "connections" - have you actually read what it says ?
"Blocked outgoing packet as FIN:ACK received *but there is no active
connection*".
What this means is that the remote side of the connection sent YOU a notice
that it has closed the connection - but your side never opened it, or
already closed it earlier - perhaps reset it because of errors form the
remote side.
Use tcpdump, so you can see exactly what traffic is exchanged.
--
All your bits are belong to us.
jared
> jared wrote:
>
>
> My first question would be: what kind of firewall ?
> If it is a SOHO-type firewall appliance, or iptables on your own box, why
> would it block outgoing TCP at all ?
> Do you control this ? Do you manage it ?
>
It is a built-in firewall on my router. Yes.
> > times, all using different ports on the local side (i.e., not always
> > 50011 - although always unprivileged and not well-known).
>
> But all connecting to port 80 on the other side ?
yes
>
>
> That depends; if the destination ports do not, simply keep tcpdump running
> until you get a few of these "connections" and examine the output.
>
cool. something to do this evening. Thank you!
>
> "Blocked outgoing packet as FIN:ACK received *but there is no active
> connection*".
>
> What this means is that the remote side of the connection sent YOU a notice
> that it has closed the connection - but your side never opened it, or
> already closed it earlier - perhaps reset it because of errors form the
> remote side.
Sure - but, computers do things for a reason. If I don't have a
browser up, and don't use GoDaddy for any of their services (which I do
not), why would my PC try to contact it? Why did it receive a FIN:ACK
hours after an app closed? GoDaddy is a hosting provider if one
believes their site; hours-long response is not likely. I find it more
likely - especially given the port numbers used (always in five
figures) - that it might be some sort of probe, a slightly more
sophisticated version of the ping-spreads one sees from script kiddies
looking for a machine to infect. Not that I hold GoDaddy responsible;
if it is what I suspect, likely someone is using thier servers as
relays.
kind regards,
jh
jared....@gmail.com
jared wrote:
> Jeroen Geilman wrote:
>
> > What this means is that the remote side of the connection sent YOU a notice
> > that it has closed the connection - but your side never opened it, or
> > already closed it earlier - perhaps reset it because of errors form the
> > remote side.
>
Thanks to your suggestion, I fired up wireshark/ethereal and found it.
It was a weather applet; apparently NOAA uses a hosting service there
to help distribute their radar maps or somesuch.
Thanks again for teaching me how to do this.
Best regards,
jh
jared....@gmail.com
jared wrote:
> Jeroen Geilman wrote:
>
> > that it has closed the connection - but your side never opened it, or
> > already closed it earlier - perhaps reset it because of errors form the
> > remote side.
>
Thanks to your suggestion, I fired up wireshark/ethereal and found it.