Spoof Protection With Firewall-1

I need help understanding a problem with Spoof Detection on Firewall-1 4.0 that appears to be rendering it worthless.

On an internal network we have a Firewall-1 4.0 box that has 12 dmz interfaces attached to it, each of them Class C networks that do not overlap. I tried to put spoof detection into effect on the firewall as follows:

1) Edited the Firewall-1 network object

2) Selected each Interfaces tab and hit Edit button

3) For every interface except external, I specified valid addresses as "This Net"

4) For the external interface, I specified "Others"

As soon as I install that policy, I see packets that should be allowed through the firewall get an accept on the incoming interface, and then get a reject on rule 0 as soon as they are passed to the interface with the server they are trying to reach. I researched this online and got this explanation:

A "reject" on Rule 0 typically means that an outgoing packet (one that has been accepted by your security policy and routed by the OS) is violating your anti-spoof rules because the packet is being routed out the wrong interface. If your Network Address Translation is misconfigured, you will often have problems with Anti-Spoofing.

This already concerns me a lot, because it implies that Firewall-1 has no way to distinguish a packet that has already passed through its security rules and NAT, from a packet that is incoming on an interface.

Can someone please give me an example of a valid NAT configuration that would allow spoof detection to work correctly, without causing the packets to be rejected on rule 0 when they get to the destination interface?

Further confusing me here, packets that are not having destination IPs modified by NAT are not triggering spoof detection. I don't see how the spoof detection can trigger when the packet gets to the dmz interface after being changed by NAT, but not triggered when there is no NAT. In both cases if the packet's source is a different network, then the Source IP won't be the same as the Valid Addresses that correspond to the Firewall-1 "This Net" spoof detection setting.

Reply to
Will
Loading thread data ...

Will wrote: : I need help understanding a problem with Spoof Detection on Firewall-1 4.0 : that appears to be rendering it worthless.

Will, Wow.. 4.0 is indeed a very very old version. I guess version 4.1 was released 6 years ago. Or was it 7? Anyhow..

The anti spoofing depends on your config. If you're having manual NAT rules you need to specify the external ip addresses on the other side of the network as well. This because the packets are routed before they are NAT'ed.

Lars

Reply to
larstr

Can you give an example of this that would work with the spoof detection?

In our NAT rule, we only change the destination address to agree with addresses in the DMZ networks. We don't modify the source address which is coming on the external interface. I could certainly modify the external source address to match one on the local DMZ, but that would be a hysterical security flaw if I had to do that, in effect hiding external source IPs from my own internal applications! I just don't see how to do the NAT to make Firewall-1's spoof detection happy.

I would be glad to see one example that works for any configuration where NAT rules are use to convert the destination IP that the external host uses into an IP that is used on a local DMZ (e.g., 10.x.x.x, 192.168.x.x,

172.x.x.x).
Reply to
Will

: Can you give an example of this that would work with the spoof detection?

Will, The easiest thing is to use automatic NATing. By that I'm meaning that when defining a host you give it a name+private ip and in the same object settings under NAT you can give it a public ip address.

This will make the spoof detection happy. If you OTOH don't specify the NAT address on the object, but rather choose to define the NATing by manually insert a NAT rule, then the spoof detection will kill this trafic.

This because (as I said in the previous post) the rule base is enforced after the packet has been routed internally in the kernel. The workaround if you must have a manual NAT rule is to define the external ip address of this object and assign it to a group where also the private network is assigned and use this group in the topology for this nic.

Lars

Reply to
larstr

Now it is very clear. Thanks!

Reply to
Will

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.