Re: incoming interface confusion question [LONG]

["Shaun T. Erickson" <ste@smxy.org>]

Ok, here's some more detail on what happened.

I have a SonicWall firewall as my external firewall. Its external 
address and the address of the systems in the DMZ hanging off of it, are 
in a pool of 16 real IPs we got from the ISP.

The LAN port of the SonicWall is connected to a hub. The only other 
thing connected to the hub is eth0 of my internal iptables 
router/firewall. I have an internal lan hanging off eth1 of the iptable 
system, and a second internal lan hanging off eth2 of the iptables 
system. The SonicWall has two static routes pointing traffic for my 
internal lans to eth0 on the iptables system. Both of my lans use 
non-routable private ip address space.

What happened is that the iptables system dropped what appear to be 
quite methodical scans of system on one of my lans by sites out on the 
internet. It saw the packets coming in eth0 and destined to head out 
eth1 and, based on my rulesets, logged and dropped them.

The problem is, the iptables system should have never seen them in the 
first place. The source addresses are from multiple internet sites, 
coming from either port 80 or port 443, and were destined for the 
private address space of one of my internal lans. The initial 
destination port seemed randomly chosen, but then incremented by 1. Most 
often, 92 bytes was sent to each port, but not always. The ruleset of 
the SonicWall should not allow such traffic through it. They looked over 
my ruleset and could find nothing that would allow such traffic to pass 
their device. Moreover, traffic destined for private non-routable 
address space can't be routed over the internet, as routers along the 
way would drop it, so it would seem the traffic couldn't have come in 
the wan port of the SonicWall. Now, maybe they broke into a system on my 
DMZ. Well, I did an nmap scan of my internal lan from the DMZ and the 
sonicwall screamed in it's logs that a port scan was happening and it 
dropped the packets. The iptables system never saw the scan. So that 
suggests that it didn't come from my DMZ, either.

How else could the traffic have arrived? Well, outside the sonicwall, 
there is a switch between it and my external router. Plugged into that 
switch is a wireless access point. If someone was on that, the packets 
would still have to come through the sonicwall to be seen by the 
iptables system. Sonicwall says the packets could not have come through 
their device.

Ok. Next theory: some system on the inside is compromised and spoofing 
the source address of the packets it sends out. So maybe something on 
lan2 tried to scan something on lan1. The problem with that is that on 
the iptables system, I have a rule that says if a packet comes in eth2 
with a source address other than one from the network attached to that 
interface, the system is to drop the packet. I have a similar rule for 
packets coming in eth1 from the other lan. So, that suggests that the 
packets couldn't have come from the inside, either.

We have a separate, smaller sonicwall that acts as our vpn concentrator. 
Only vpn traffic passes through that device. If someone broke in via our 
vpn, they'd either get a dhcp address on that lan or they could pretend 
to be something else. If they spoofed packet source from there, again 
the rule saying drop packets with a source other than that net would 
kick in.

So, The ruleset on the sonicwall says it couldn't have come from the 
outside, and the rulset on the iptables system says it couldn't have 
come from the inside.

Now what?

	-ste