('binary' encoding is not supported, stored as-is) 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
This archive was generated by hypermail 2b30 : Thu Aug 29 2002 - 11:29:43 PDT