Joshua Chamas wrote:
> 
> One of my machines just got probed by a set of IPs
> during the same _TCP_ probe, one of which is an illegal
> 192.168.1.*

This was probably not a probe but an actual attack. For a probe, a legal
address would be used so that information could be extracted back out of
your network. Attackers will typically only use private addresses when
they are launching an actual attack. An exception to this would be if
they have compromised one of your ISP's systems so they are sitting
along the default route.

It's also possible that you are dealing with some with a mis-configured
firewall or NAT device. I noticed they are trying to hit your Web site.
It may be this was part of their testing to see if NAT is working. It
could also be that the NAT device on the other end is failing and
leaking out private addresses. I would be more concerned if they where
hitting ICMP or some off beat TCP port like 53.

> My understanding was that 192.168.1.* addresses wouldn't
> be routable,

They should not be. Keep in mind however that routing of this address
will not come into play until your system responds. You do not need a
legal IP address to send an IP packet, just to receive a reply. What
*should* happen is that your system would respond to this address, pass
the response to your external router, which will then pass the packet
along the default route settings till it eventually dies.

To prevent this type of thing in the future, create an inbound access
list on your router which filters out all inbound traffic from private
address space.

> and that having the probe alternate IPs
> also concerns me.

Tools like nmap will do this, but I'm not convinced that you are
actually looking at a tool which is varying the IP address. The fact
that both sessions (one from 192.168.1.65 and the second from
38.149.215.71) are both using the same source port number at exactly the
same time is more than suspicious. However there does not seem to be any
information sharing between the two connection attempts like one would
expect from a tool like nmap. For example the fact that session one
attempts three times to ACK-FIN when it does not receive a reply sounds
more like a normal TCP session rather than a scanning tool. Also, look
at the times. scanning tools are built for speed and would not wait so
long between transmissions.

Hope this helps,
Chris
-- 
**************************************
[EMAIL PROTECTED]

* Multiprotocol Network Design & Troubleshooting
http://www.amazon.com/exec/obidos/ASIN/0782120822/geekspeaknet
* Mastering Network Security
http://www.amazon.com/exec/obidos/ASIN/0782123430/geekspeaknet
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]

Reply via email to