Internal IP-Spoofing

I take it 10.0.0.0 is your internal network. Put the following rules in the top of your packet filter list (ASL v4):

Internal_Network__  { netbios } Internal_Interface__   Drop
Internal_Network__  { netbios } Internal_Broadcast__  Drop

Windows PCs, particularly the newer Win2K and WinXP machines will beacon netbios packets to their default gateway like crazy. If you don't have the above rules in your filter list, you are also filling up your daily filter log and kernel log with megabytes of junk, since ASL log drops this stuff by default.

That did not fix it.  Below is a sample of the packet filter log file.

Anyone got any thoughts?

2004-Apr  9 00:01:24 (none) kernel: IP-SPOOFING Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:07:e9[:D]5:8c:74:08:00 SRC=10.0.0.237 DST=10.0.0.255 LEN=229 TOS=0x00 PREC=0x00 TTL=128 ID=42801 PROTO=UDP SPT=138 DPT=138 LEN=209 
2004-Apr  9 00:01:32 (none) kernel: IP-SPOOFING Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:50:8b:b1:c9:f0:08:00 SRC=10.0.0.18 DST=10.0.0.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=45218 PROTO=UDP SPT=137 DPT=137 LEN=58 
2004-Apr  9 00:01:32 (none) kernel: IP-SPOOFING Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:50:8b:b1:c9:f0:08:00 SRC=10.0.0.18 DST=10.0.0.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=47777 PROTO=UDP SPT=137 DPT=137 LEN=58 
2004-Apr  9 00:01:33 (none) kernel: IP-SPOOFING Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:50:8b:b1:c9:f0:08:00 SRC=10.0.0.18 DST=10.0.0.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=49847 PROTO=UDP SPT=137 DPT=137 LEN=58 
2004-Apr  9 00:01:37 (none) kernel: IP-SPOOFING Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:06:25:0a[:D]c:72:08:00 SRC=10.0.0.11 DST=10.0.0.255 LEN=229 TOS=0x00 PREC=0x00 TTL=30 ID=11247 PROTO=UDP SPT=138 DPT=138 LEN=209 
2004-Apr  9 00:01:40 (none) kernel: IP-SPOOFING Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:f1:af:37[:D]7:08:00 SRC=10.0.0.137 DST=10.0.0.255 LEN=229 TOS=0x00 PREC=0x00 TTL=128 ID=17580 PROTO=UDP SPT=138 DPT=138 LEN=209 
2004-Apr  9 00:01:43 (none) kernel: IP-SPOOFING Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:10:5a[:D]5:c7:93:08:00 SRC=10.0.0.72 DST=10.0.0.255 LEN=229 TOS=0x00 PREC=0x00 TTL=128 ID=48036 PROTO=UDP SPT=138 DPT=138 LEN=209 
2004-Apr  9 00:01:53 (none) kernel: IP-SPOOFING Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:03:47:a7:ad:3a:08:00 SRC=10.0.0.236 DST=10.0.0.255 LEN=229 TOS=0x00 PREC=0x00 TTL=128 ID=58386 PROTO=UDP SPT=138 DPT=138 LEN=209 
2004-Apr  9 00:01:57 (none) kernel: IP-SPOOFING Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:b0[:D]0:20:09:67:08:00 SRC=10.0.0.36 DST=10.0.0.255 LEN=229 TOS=0x00 PREC=0x00 TTL=128 ID=47960 PROTO=UDP SPT=138 DPT=138 LEN=209 
2004-Apr  9 00:02:00 (none) kernel: IP-SPOOFING Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:c0:4f:a0:a3:79:08:00 SRC=10.0.0.49 DST=10.0.0.255 LEN=229 TOS=0x00 PREC=0x00 TTL=128 ID=53577 PROTO=UDP SPT=138 DPT=138 LEN=209

make sure your netmask is right on ASL's internal network
should be 255.255.255.0

Barry

[ QUOTE ]
make sure your netmask is right on ASL's internal network
should be 255.255.255.0

[/ QUOTE ]Good one!

I don't know why so many folks insist on using the 10.0.0.0 addressing for their internal networks, which defaults to a 255.0.0.0 netmask, when they would be far better off by sticking with a simple class "C" network in the 192.168.xx.0 address range, with a 255.255.255.0 default netmask. Very few people require more than the 253 available IP addresses a class "C" network gives them.

There just aren't that many folks out there with the 16 million PCs on their private network that they would need to fill the 10.xx.yy.0 class "A" network range.   

Hi there, 

IP-Spoofing protection comes into play, if a packet with an iP from a  connected network enters the firewall from the wrong interface.
This mostly happens if you connected multiple interfaces to the same switch/hub.

If that is your case, than thats your problem.

Regards
Gert

What does your packet filter table look like?
Is 10.0.0.0 not your internal network number?
What logical  interface is eth1 used for on your system?

The rule I gave you:

Internal_Network__ { netbios } Internal_Broadcast__ Drop

should take care of both port 137 and port 138 netbios broadcasts on the internal network.
It works on my system.

If your eth1 circuit is not your internal network, but is used for the external network, then you must modify the rules I gave you to match that situation. Use rules such as those below instead:

Any { netbios } External_Interface__ Drop
Any { netbios } External_Broadcast__ Drop

VelvetFog,

Great tips! 

It would be really nice if this kind of stuff was in the manual or intial setup guides. ( * hint * )
I have a Win2003/Win2000 environment that spams like crazy (thanks uncle Bill . . .)
I am sure this will make my logs far more readable from this point in.  [:)]
Thanks.

Thanks.     

Here's another tip for creating filter rules:

Open your live packet filter log now and again, and spend a couple of minutes watching the log dropped traffic that it shows you. If you see any systemic repeat traffic that you'd prefer not to clutter up your log files with, write yourself a custom filter drop rule, which will then eliminate that particular repeat traffic from your daily filter log and kernel log.

This will ease the burden on the ASL box at midnight, when it processes and rolls over the previous day's log files.

Since everyone's network is unique, without looking at the life filter log from time to time, you are not going to catch everything going on in your environment. Dropping Microsoft's netbios traffic is a pretty standard, obvious thing to do, but in your network, there could be other processes that are also beaconing out packets that you don't want to show up in your log files.

Yes.  I just blocked all broadcast packets, since my log has been full of trash for a long time.  Uck!

globalB  255.255.255.255/32  

Filter:
Any -> globalB - Any - Drop
internal_Net ->  internal_Boradcast - Any - Drop

Wonder if I'll see any problems caused by this (i.e., services that require broadcast packets.) ??

Shouldn't cause you're only dropping them on ASL, not for the whole lan. Only prob would be if you're doing some sort of bridging between 2 LANs.