How to troubleshoot this?

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

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

In news:(E-Mail Removed) oups.com,
jared <(E-Mail Removed)> 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.

jared 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

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.

Jeroen Geilman wrote:
> 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 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 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