How does antispoof in pfSense work?
-
@johnpoz said in How does antispoof in pfSense work?:
So the way I read the rules...
Lets say you have 2 interfaces
em0 192.168.1/24
em1 192.168.2/24So this block prevents 192.168.1/24 being used on anything other than em0?
Yes this is correct, and the same for 192.168.2/24 with anything other than em1.
And prevents source of firewall IP on any interface from being used as source..
Correct.
Now imagine you were to create an interface group consisting of
em0&em1. Note that interface groups are just some logical grouping, no new antispoof rules get added for this (which makes sense). Lets name the interface group TEST for fun and create a rule on it allowing everyone to access some server:pass return in quick on $TEST inet proto { tcp } from any to $SOME_HOSTNow everyone on
em0&em1can accessSOME_HOST. So far so good, but the result of that rule is also than anyone onem0can use a spoofed IP fromem1to access that host (actually any address), which is what I am trying to prevent.Yes, the knowledge of jimp would most certainly be appreciated.
-
Lets page @stephenw10 he might also be able to smack down some info ;)
I show him online - as well, let me see if he will join in on the discussion
-
The defaults can't stop you from hurting yourself. No matter how they are set, there will be some way to misuse them or break things. The burden is on the user to choose appropriate options.
/24is a worse default for interfaces than/32. With/32, everyone has to change the mask and it's safely broken (not going to hurt any other networks), whereas/24could harm any number of misconfigured WANs.anyas a default source is the most eye-catching default. Anyone who sees that should want to fix it. If we defaulted to something else, it could break in other ways. Not every interface has an address, thus doesn't have an interface network, so using that would not work on such interfaces.Sure there is a lot of subjectivity here but ultimately the burden is on the end user to know what they are doing.
@apollo13 said in How does antispoof in pfSense work?:
Now everyone on em0 & em1 can access SOME_HOST. So far so good, but the result of that rule is also than anyone on em0 can use a spoofed IP from em1 to access that host (actually any address), which is what I am trying to prevent.
That example isn't valid, though. If the user spoofed the address in that scenario, it would either never leave the network or never get a reply. They couldn't access anything. At most they'd get a single packet to the destination, so it's more of a concern for attacks that may only have a single packet payload or need no response.
By not using
quickwe give the user the option to override theantispoofbehavior. If we changed them toquickthen odds are we'd break thousands of networks out there that rely on being able to manually manage that behavior.Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
@jimp said in How does antispoof in pfSense work?:
Sure there is a lot of subjectivity here but ultimately the burden is on the end user to know what they are doing.
Completely and wholeheartedly agree with this! ;)
@jimp so could you give an example of when the antispoof actually comes into play for sake of completeness.
-
Ok, thank you for clearing up the rationale behind those defaults. I do agree with most of them. I guess what threw me off was that https://docs.netgate.com/pfsense/en/latest/firewall/firewall-rule-processing-order.html#longer-version has "Internal automatic rules (pass and block for various items like lockout, snort, DHCP, etc.)" before "User-defined rules" and I assume
antispoofwas such an internal automatic rule.@jimp said in How does antispoof in pfSense work?:
@apollo13 said in How does antispoof in pfSense work?:
Now everyone on em0 & em1 can access SOME_HOST. So far so good, but the result of that rule is also than anyone on em0 can use a spoofed IP from em1 to access that host (actually any address), which is what I am trying to prevent.
That example isn't valid, though. If the user spoofed the address in that scenario, it would either never leave the network or never get a reply. They couldn't access anything. At most they'd get a single packet to the destination, so it's more of a concern for attacks that may only have a single packet payload or need no response.
Okay, this is where my network knowledge appears to be lacking. In which cases wouldn't it leave the network? Is it because the return-path would make no sense for pfSense or something else?
And couldn't it be used for instance to send a DNS response to the spoofed address? Or with any other UDP protocol to generate amplification.
I understand that the last questions are most likely not realistic attack scenarios after all, but the answer to those would help me widen my understanding of how all of this works. So while the question might be naive, I'd appreciate if you find the time to give me a few more pointers.
-
If a client connected to em0 manually sets an IP from em1 and you have rules to pass that that bypass the antispoof rules as discussed they should not have any connectivity.
What do they set as their gateway IP? If they set the em0 IP that's outside their subnet (probably). If they set the em1 IP they would ARP for it and it would not reply as it's in a different subnet.
But even if it did and they managed to send traffic any replies would be sent back out of em1. If in fact it left at all since the client would not respond to ARPs from em1 as it's not connected there.Interesting question though. I normally try to avoid that sort of thing!
I don't think I've ever tested how it fails exactly.Steve
-
@stephenw10 said in How does antispoof in pfSense work?:
If a client connected to em0 manually sets an IP from em1 and you have rules to pass that that bypass the antispoof rules as discussed they should not have any connectivity.
Sure, there would be no (full) connectivity. But I am more thinking about malicious users here, not legitimate users.
But even if it did and they managed to send traffic any replies would be sent back out of em1. If in fact it left at all since the client would not respond to ARPs from em1 as it's not connected there.
Right, but an answer sent back to em1 could be considered kind of an attack (DNS amplification attacks etc come to mind?)
Interesting question though. I normally try to avoid that sort of thing!
Hehe, me to. I was tightening firewall rules and looked at the generated
rules.debugand started wondering…Thank you all for your insights, it was fun to dig through the rules and I guess I learned something on the way.
-
I would still like to see a when would this really "make sense" and do what it suppose to do, etc. as an example.
-
Well, I cannot see any legitimate or useful use case myself aside from launching attacks against the network :)
-
P phil80 referenced this topic on
-
This thread was really helpful and the flexibility that pfsense gives here is amazing
However, it should have been better documented in the docs, in anti spoofing section
Is it worth a commit to propose a change in the docs?
Here's a somehow atypical use of this specificity in the anti spoofing rule:
https://forum.netgate.com/topic/163088/l3-switch-and-pfsense-design-advise/16?_=1641114477363 -
@apollo13 said in How does antispoof in pfSense work?:
Therefor antispoff will match after any user defined rules by default if I understand it correctly.
Doesn't it depend on where the antispoof rules are in the ruleset? I'm looking at the expanded rules and it looks like the expanded antispoof rules are above my userrules anchor. Since they don't have a quick on the antispoof, but are physically above userrules, shouldn't it get evaluated first but not acted on unless there is no other rule matching the packet? The "last match wins" behavior?
Everything else said in this thread is the behavior I've seen; it's just that specific statement I think is not quite correct.
If I'm wrong, please correct me. -
Yes, exactly that. I think that statement was intended to imply the same; the antispoof rules match traffic before the user rules but without 'quick' set their action is not applied until after the user rules. Therefore it's possible to by-pass the antispoof rules with an excessively wide user rule.
Pass rules should use actual subnet(s) they apply to as source where possible.
The Interface group example above is an interesting one though.Steve
