Can't create firewall rules with port = 0

[rcarr]

Understandably, the Firewall->Rules GUI will not let you create a rule in which the source or destination port is zero, since zero is an illegal port.  (Instead, the GUI changes the port to be "any").

However, crafted packets with source port zero do occur:

http://www.securityfocus.com/archive/75/402099/30/0/threaded

In a future version of pfsense, I would like to be able to specify port 0 in Firewall->Rules to create:

block in quick inet proto { tcp, udp } from any port = 0 to any
block in quick inet proto { tcp, udp } from any to any port = 0

[sullrich]

Considering that this is a false use of ports wouldn't it be better to simply block these packets regardless at the beginning of our ruleset?

[rcarr]

If you're suggesting integrating rules which block source port 0 into pfsense's default ruleset, I agree – that would be better.

[sullrich]

Yes, that is what I speak of.  I'll go ahead and commit it in a bit.

Thanks for the suggestion!

[rcarr]

I see there's built-in anti-spoofing for the non-WAN interfaces, but didn't see anything for the WAN interface. Another suggestion that might make sense to integrate into the default ruleset:

block in quick on $wan inet from ($wan) to any

[sullrich]

There should be spoofing protection on all WANS.

Can you show an example?

[rcarr]

I'm running 1.0.1-SNAPSHOT-03-27-2007.  Here's what my rules.debug has with regard to spoofing and anti-spoofing:

LAN/OPT spoof check (needs to be after DHCP because of broadcast addresses)

antispoof for fxp1
antispoof for fxp2

block anything from private networks on WAN interface

anchor "spoofing"
block in log quick on $wan from 10.0.0.0/8 to any label "block private networks from wan block 10/8"
block in log quick on $wan from 127.0.0.0/8 to any label "block private networks from wan block 127/8"
block in log quick on $wan from 172.16.0.0/12 to any label "block private networks from wan block 172.16/12"
block in log quick on $wan from 192.168.0.0/16 to any label "block private networks from wan block 192.168/16"

Firewall->Rules-> doesn't show any anti-spoofing rules in the GUI for any of the interfaces.  Interfaces->WAN does present "Block private networks" and "Block bogon networks" options, but no anti-spoofing of the interface's IP addr.

I ended up adding a rule in the GUI, which looks like this in rules.debug:

User-defined rules follow

block in quick on $wan from x.x.x.x to any  label "USER_RULE: Block packets spoofing WAN IP addr (LAND attacks)"

[databeestje]

Not sure, but i would think this breaks nat reflection. Need testing.

[sullrich]

Commited a antispoof for $wan.  Did not know that we where lacking this.  Thank you.

Also, if you could please test with reflection to make sure we did not break this functionality.

[rcarr]

NAT reflection.  I hadn't thought of that.

Ok, I'll try testing that.

[rcarr]

I applied the 1.2 beta snapshot from 4/22.

rules.debug now shows antispoofing for $wan:

LAN/OPT spoof check (needs to be after DHCP because of broadcast addresses)

antispoof for em1
antispoof for em2

block anything from private networks on WAN interface

anchor "spoofing"
antispoof for $wan

I disabled my custom rule for anti-spoofing on $wan.

Haven't had a chance to test NAT reflection yet.

Thank you also for adding:

We use the mighty pf, we cannot be fooled.

block quick proto { tcp, udp } from any port = 0 to any
block quick proto { tcp, udp } from any to any port = 0

[gbelanger]

I've seen situations where the WAN is not the Internet (i.e. a DMZ or another private network). In that case, wouldn't these 'anti-spoof' rules prevent legitimate traffic to go through? (assuming the traffic doesn't get NAT'ed).

An example of this could be two offices connected through a point-to-point link on the WAN interfaces.

Shouldn't this be an option rather than a permanent rule? Maybe I'm just not getting this right …

[rcarr]

The antispoof rule should prevent an interface from receiving a packet which claims to have the same source IP as the interface.

I can't think of a scenario in which that is legitimate.

It means either that someone is crafting packets to spoof the source addr of one of your interfaces (for instance, during a LAND attack), or that you have two devices sharing the same IP addr – which is also bad.

[gbelanger]

Oh, yes, that makes sense. I was reacting to this:

anchor "spoofing"
block in log quick on $wan from 10.0.0.0/8 to any label "block private networks from wan block 10/8"
block in log quick on $wan from 127.0.0.0/8 to any label "block private networks from wan block 127/8"
block in log quick on $wan from 172.16.0.0/12 to any label "block private networks from wan block 172.16/12"
block in log quick on $wan from 192.168.0.0/16 to any label "block private networks from wan block 192.168/16"

I was referring to the fact that theoretically, the WAN could be a private network. So blocking private networks on the WAN Interface by default might be problematic.

[cmb]

It can be disabled by unchecking "block private networks" on the WAN. 99.9+% of installs will want this, so it's on by default.

[techatdd]

@cmb:

It can be disabled by unchecking "block private networks" on the WAN. 99.9+% of installs will want this, so it's on by default.

Not sure if this is right, actually everybody using multiwan with pppoe needs it.
Btw, when mpd4 is implemented, will multiple PPPoE WAN-OPTx connections became possible?  :)

Greetings,
techatdd

[cmb]

@techatdd:

@cmb:

It can be disabled by unchecking "block private networks" on the WAN. 99.9+% of installs will want this, so it's on by default.

Not sure if this is right, actually everybody using multiwan with pppoe needs it.

That's not true unless you have private IP space on your WAN, which normally won't be the case with PPPoE of any kind.

@techatdd:

Btw, when mpd4 is implemented, will multiple PPPoE WAN-OPTx connections became possible?  :)

It's in the works.