Re: What's going on here?

[<wykkyd () ziplip com>]

In-Reply-To: <000f01c24eb9$2837b150$841e0a0a@dynamite>

> Don't know if this was mentioned, haven't been following the whole thread,
> but my suggestion would be that it's someone who physically resides in 
your
> upstream path portscanning, using source port 80 to fool misconfigured
> non-stateful ACLs into thinking that these are replies to normal web
> traffic, but using Syn only to catch valid open TCP ports.
>
> -Mark C.

Here's my guess (as that is truly all I can do with the information given).

Three scenarios, both based on the facts that (1) ZoneAlarm is host-based, 
ans (2) 10.x is not an internet-routable protocol (as in, no router will 
forward it outside of your own network):

Scenarion #1:  Someone port scanning your system:

IF it was a port scan, how would the SYN-ACKs be routed back to the 
scanner (source)?  Someone external to your network would receive no 
results by spoofing these IPs (if that is what it is) because the 
responses wouldn't be routed properly (see Scenario #2, below).

Coming from a 10.x IP, it would have to someone INSIDE your own network 
doing the scanning, assuming you use NAT behind your firewall (so that 
folks would HAVE a 10.x IP to begin with), for any measurable results to 
come from the scanning.  

Bottom line:  IF it is port scanning, it is from the inside (or the person 
on the outside is silly).

Scenario #2:  Someone attempting to DoS your system:

IF it is a DoS, by continually scanning your system with non-routable IPs, 
if will cause you to consume system resources by waiting for time-outs or 
other nastiness to occur.  The fallacy of this plan, though, is that they 
are hitting seemingly random ports, which will make the DoS effect (IF 
that is what this was) less, and easier for your system to process.  If 
they were to hit a single port known to be open on your system, the 
ensuing SYN-ACKs would take longer to get error messages, thus taking more 
system resources, and tying up more "wait-states".

Bottom Line:  IF it is DoS, it is a poor one, at best, and probably 
ineffective.

Scenario #3:  This is the combo scenario (allow me to explain)...

IF you have a misconfigured network device, say, your firewall, and it is 
performing NAT INBOUND (as opposed to only outbound) it could be masking 
the scanner's true IP.  In this case, this could be a combination of a 
misconfigured NATing device and one of the two scenarios above.

Bottom Line:  Make sure your network firewall is not performing INBOUND 
Network Address Translation!!!

Others can probably come up with other solutions (I kind of like the ad 
server one, but how would a 10.x IP be routed across the internet again, 
unless it was spoofed, and ad servers don't generally do that) but this is 
what I came up with (as in, if I was doing for you what I get paid to do 
for other people (network forensics)) these are what I would pursue 
initially.

Good luck.

wykkyd

----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com