How to check/enable antispoofing
-
Coming back to my first question, can anyone say how can i enable or disable antispoofing (reverse path check) on pfsense?
-
@panicos said in How to check/enable antispoofing:
disable antispoofing (reverse path check) on pfsense?
There is no such thing. Do you mean allowing for asymmetrical traffic where pfsense sees syn,ack when there was not syn to create the state..
How about you do this..Remove all your lagg setup, and do just physical paths and with actual isolation... Do you see the problem then?
A server would never send traffic out a different interface with different source IP.. What OS do you think works that way?? How would you think it would even know to do that?
Sure you can do it with generating packets and such, but no normal OS routing or stack would do such a thing..
What are those mac address.. your sending to a HP mac c8:cb:b8, from vm mac... But your return is to intel 00:1b:21
-
I believe the OP is talking about behaviors that a few firewalls have, Checkpoints in particular. Here is a link to a short description of the feature -- http://www.jay-miah.co.uk/configuring-anti-spoofing-on-a-checkpoint-firewall/.
So far as I know, @johnpoz is correct that no such feature exists in pfSense. At least I know of no such directly configurable similar feature.
I managed Checkpoint firewalls for several years and anti-spoofing was one of those really cool but really irritating features. It usually raised its head and blocked stuff somewhat invisibly when you were creating complex configurations such as VRRP.
-
man, please, understand what i am saying and stop saying the otherwise.
What OS do you think works that way?? --> for instance, FreeBSD works that way.
The reverse patch check is a kernel setting. In some Linux distributions (like Ubuntu for instance) it is enabled by default. I don't know how is it in FreeBSD, but judging by its behaviour, it is not enabled.
If you want to help me, please post relevant messages to what i am asking and stop seeing problems where there actually aren't. -
Give us the Mac address - see my edits... You have what looks like asymmetrical flow.. You send to mac A, but get answer back from mac B.. one is HP, the other is intel..
So that traffic is not flowing back through pfsense..
Reverse path filtering is router thing - what OS that is NOT being used as a router would do such a thing? None of them.
Good luck - you have a complete and utter mess with such a setup.. So no shit your going to see all kinds of problems...
-
@bmeeks said in How to check/enable antispoofing:
or several years and anti-spoofing w
Hi, yes, Checkpoint is an example.
I am here refering to Reverse Path Filter. It is called like that on Linux, but i don t know how is it on FreeBSD.
In my case, the Pfsense (which is a freebsd as far as i know) receives a packet on an interface that it should not be receiving it and it allows it; i want to know if i can enable the feature that blocks it.
Further explination: the firewall has interface A and interface B. The firewall receives a packet with source IP from interface B , but it receives it on interface A instead of receiving it on interface B and it allows it. I want to know how i can block this. -
As i said. Please stop. You are not reading my posts and my captures and all i added. Stop adding confusion.
-
@panicos said in How to check/enable antispoofing:
@bmeeks said in How to check/enable antispoofing:
or several years and anti-spoofing w
Hi, yes, Checkpoint is an example.
I am here refering to Reverse Path Filter. It is called like that on Linux, but i don t know how is it on FreeBSD.
In my case, the Pfsense (which is a freebsd as far as i know) receives a packet on an interface that it should not be receiving it and it allows it; i want to know if i can enable the feature that blocks it.
Further explination: the firewall has interface A and interface B. The firewall receives a packet with source IP from interface B , but it receives it on interface A instead of receiving it on interface B and it allows it. I want to know how i can block this.I don't believe FreeBSD has that capability, or at least it is not compiled into the kernel's firewall engine by default. pfSense is really just a few patches on top of FreeBSD, so if FreeBSD does not have something then generally pfSense will not have it either.
Here is a very old thread from the Netgate forums discussing the feature: https://forum.netgate.com/topic/2228/rp_filter/3. I also found a handful of Google links suggesting you can sort of mimic anti-spoofing using some features of the
ipfw
firewall on FreeBSD. However, in pfSense, theipfw
firewall engine has been modified a little and is used solely for Captive Portal operation. The firewall engine used in pfSense for controlling network traffic ispf
. -
@bmeeks said in How to check/enable antispoofing:
I don't believe FreeBSD has that capability, or at least it is not compiled into the kernel's firewall engine by default. pfSense is really just a few patches on top of FreeBSD, so if FreeBSD does not have something then generally pfSense will not have it either.
Here is a very old thread from the Netgate forums discussing the feature: https://forum.netgate.com/topic/2228/rp_filter/3. I also found a handful of Google links suggesting you can sort of mimic anti-spoofing using some features of the ipfw firewall on FreeBSD. However, in pfSense, the ipfw firewall engine has been modified a little and is used solely for Captive Portal operation. The firewall engine used in pfSense for controlling network traffic is pf.Yes bmeeks, i also saw that thread before, but it is indeed very old; i had the impression that maybe something changed in the last 14 years, since then.
So i guess, that means the antispoof i want to enable is just not possible, right? -
@panicos said in How to check/enable antispoofing:
@bmeeks said in How to check/enable antispoofing:
Yes bmeeks, i also saw that thread before, but it is indeed very old; i had the impression that maybe something changed in the last 14 years, since then.
So i guess, that means the antispoof i want to enable is just not possible, right?Correct. I don't think the feature has made it into the
pf
engine used for controlling traffic on pfSense.You might consider opening a Feature Request on the pfSense Redmine site here: https://redmine.pfsense.org/. In my search I did see a number of discussions about a recent (as in 2019) VPN vulnerabililty that is exploited using spoofing techniques that "anti-spoofing" is designed to prevent.
-
ok, thanks. i will need then to find different alternatives to this situation.
Thx a lot. -
Well if properly filtered at L3 wouldn't be an issue what your NAS does for return traffic.. Because your box would never be able to hit the 100 vlan address in the first place.
-
@bmeeks said in How to check/enable antispoofing:
believe the OP is talking about behaviors that a few firewalls have, Checkpoints in particular.
Fortigate too.
-
But that only comes into play with routers.. Why would you "server" being do it.
Routers that have multiple path it makes sense so... But not when OS is being used as on a local network..
-
This post is deleted! -
Referring all the way back to the OP's very first post and simplified diagram, this is what I understand is going on.
You initiated a ping from host 10.40.40.3 to host 10.100.100.7. The pfSense firewall has both networks (the 10.40.40.0 and the 10.100.100.0) locally attached along with 172.35.35.0. Just assuming for this example all the networks are a /24 subnet.
So your ping towards 10.100.100.7 was routed by the firewall directly to the host on 10.100.100.7 via the local attachment. That target host (10.100.100.7) is actually a dual-homed server with two different interfaces. It's internal routing is set up such that 172.35.35.x is the default route (or the gateway). So when that dual-homed server is ready to return the reply to 10.40.40.3 it sees that is not on its network so it hands it off to the gateway at 172.35.35.x to route. The gateway sees that 10.40.40.3 is locally attached so it just routes the packet straight over to VLAN 40 and back to the originating host.
Now the above assumes the firewall has no rules (or they are all "any any pass"). In a typical firewall scenario with rules, the reply coming in to VLAN 35 (from the server host's default route) would be dropped due to being out of state. You did not share your firewall rules.
I don't really see where anti-spoofing comes into play in this scenario.
Or am I just dazed and dense and not seeing something obvious ???
-
@bmeeks said in [How to check/enable antispoofing]
Hi bmeeks,
Yes, you understood correctly the scenario.
"In a typical firewall scenario with rules, the reply coming in to VLAN 35 (from the server host's default route) would be dropped due to being out of state. You did not share your firewall rules."
My firewall rules for the moment are allow any any (for testing purpose). How do you make the "out of state rule" that you are referring to? This feature should be present by default on firewalls as far as i know, but the pfsense acts like just a router in my case.
"I don't really see where anti-spoofing comes into play in this scenario." -> the antispoofing comes in by blocking the traffic that comes on the wrong interfaces. More exactly, in my case, the firewall receives the response from 10.100.100.7 towards the host 10.40.40.3, coming through its vlan 35 interface instead of coming through vlan 100 interface.
The firewall has interfaces in vlan 100 and vlan 35 and all the vlans that exist in my setup; he receives a packet from the vlan 100 subnet range, coming inbound in its vlan 35 interface (instead of vlan 100 interface), so it should say: "hey stop, you should be coming through interface 100, not interface 35. I don't have a route towards you through my interface 35, but i have through interface 100"It is the same thing as a firewall is receiving trafic from a public IP not on its WAN interface, but on one of its other interfaces (LAN, DMZ, whatever). It sees traffic from let's say 85.34.56.78 coming inbound in its LAN interface and says " hey you should be coming from my WAN interface, because i have a route(default one) to you through WAN interface, not through any of my other interfaces". and drops it.
This is reverse path check (called different from vendor to vendor, OS to OS, etc), in which the firewall does a check of the certain IP against its routing table and if he sees a match there, he forwards the packet, otherwise it drops it.
I hope i explained ok.
-
https://docs.netgate.com/pfsense/en/latest/book/firewall/rule-methodology.html
Anti-spoofing Rules
pfSense uses the antispoof feature in pf to block spoofed traffic. This provides Unicast Reverse Path Forwarding (uRPF) functionality as defined in RFC 3704. The firewall checks each packet against its routing table, and if a connection attempt comes from a source IP address on an interface where the firewall knows that network does not reside, it is dropped. For example, a packet coming in WAN with a source IP address of an internal network is dropped. Anything initiated on the internal network with a source IP address that does not reside on the internal network is dropped.
If you look you will see them...
[2.4.5-RELEASE][admin@sg4860.local.lan]/root: cat /tmp/rules.debug | grep antispoof antispoof for $WAN tracker 1000001570 antispoof for $LAN tracker 1000002620 antispoof for $WLAN tracker 1000003670 antispoof for $TEST tracker 1000004720 antispoof for $NS1VPN tracker 1000005770 antispoof for $W_PSK tracker 1000006820 antispoof for $W_GUEST tracker 1000007870 antispoof for $W_ROKU tracker 1000008920 antispoof for $DMZ tracker 1000009970 [2.4.5-RELEASE][admin@sg4860.local.lan]/root: pfctl -vvsr | grep 1000002620 @65(1000002620) block drop in on ! igb0 inet6 from 2001:snipped:9::/64 to any @66(1000002620) block drop in on igb0 inet6 from fe80::208:a2ff:fe0c:e624 to any @67(1000002620) block drop in inet6 from 2001:snipped:9::253 to any @68(1000002620) block drop in on ! igb0 inet from 192.168.9.0/24 to any @69(1000002620) block drop in inet from 192.168.9.253 to any [2.4.5-RELEASE][admin@sg4860.local.lan]/root:
So again ask how is it this traffic would be allowed.. State table would be for the other interface.. So this traffic would not be allowed in..
If you disabled antispoof, you would be wanting such traffic to happen..??