How to check/enable antispoofing
-
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
ipfwfirewall on FreeBSD. However, in pfSense, theipfwfirewall 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
pfengine 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..??
