Reroot exposes SSH, Telnet, Web UI to WAN
-
@nocling My rules:
-
Your last Rule allows your LAN to 443,80,22 on the pfSense WAN Adresse.
Do not try a Scan on the WAN Adresse from a LAN Client!
-
LAN : ok
WAN : why ? the default 'hidden' block rule will take care of these. "The good WAN is an empty WAN".
Floating : Looks fine to me.@nocling said in Reroot exposes SSH, Telnet, Web UI to WAN:
Do not try a Scan on the WAN Adresse from a LAN Client!
Because he's scanning the outside from the inside ?
Well, yeah, the test is wrong then.I was serious :
@gertjan said in Reroot exposes SSH, Telnet, Web UI to WAN:
you can use a device like a phone, and via the 3G/4G/4G you 'hammer' (nmap if possible ) your IP WAN
In short : from the outside.
-
Limiter Rules works best with match and no quick.
Have a look on the documentation:
https://docs.netgate.com/pfsense/en/latest/firewall/floating-rules.html?highlight=match -
@gertjan Learned something new today, thank you!
-
@nocling said in Reroot exposes SSH, Telnet, Web UI to WAN:
Your last Rule allows your LAN to 443,80,22 on the pfSense WAN Adresse.
Do not try a Scan on the WAN Adresse from a LAN Client!
Unless I am missing something, It's a default rule created by the setup wizard. Disabling this would lock me out even from LAN. I changed the limiter rule to "Match," but regardless even with the rule disabled my network becomes exposed to WAN after reroot.
@gertjan said in Reroot exposes SSH, Telnet, Web UI to WAN:
In short : from the outside.
The test was done from my phone with LTE. Why do you think I did it from LAN given the premise of the thread?
-
Ok, the cause of the issue is from using the TOE function of my NIC (Chelsio T5). With TOE disabled, nmap fails even after reroot. With TOE enabled, nmap can scan ports and port 80 appears open but my web UI is configured to use HTTPS, so fails to connect from WAN. After reroot, everything becomes exposed and accessible from WAN. I thought the ASIC was a self-contained firewall that further passed packets to the regular (system) firewall, but it appears to (partially) bypass it. I guess that's how it achieves line-rate filtering. For now I guess I will leave TOE disabled unless someone can suggest how to use it without bypassing PfSense's firewall.
-
Sorry, can't edit old posts, but I found the answer: https://calomel.org/freebsd_chelsio_toe_firewall.html:
The Chelsio Offload Policy (COP) manages when the TCP Offload Engine (TOE) takes affect allowing the card to only offload TCP connections which you want to offload and leave the other connection to the default FreeBSD TCP stack.
...
SECURITY NOTE: The Chelsio TCP Offload Engine (TOE) will completely bypass the FreeBSD TCP stack as well as any Chelsio filter rules. This means that traffic using TOE will NOT be filtered using our Chelsio Rules of Engagement filter rules or the Pf packet filter, nor will Pf log TOE connections. Netstat will show the connections using "netstat -np tcp" though. -
@user1337 That’s a feature? I wonder if that’s something Netgate can disable in the driver/config. You might open a Redmine.pfsense.org about it.
Side note:there’s a long thread here somewhere about (some?) Chelsio cards downloading at half speed in 23.01.
-
Hmm, so this was eliminated by disabling TOE or rather simply not enabling it?
What pfSense version did you see this in?
You only saw it after rerooting?
This was permanent after the reroot? Not just while the reroot was happening?
Steve
-
@steveits TOE is disabled by default and can't be enabled by accident so nothing Netgate needs to worry about. My WAN speed matches my expectations when using typical web-based speed tests, but I only have a ~350/10Mbps plan so it's not enough to expose a large bottleneck.
@stephenw10 Yes, I disabled TOE by commenting out these lines in a custom script in /usr/local/etc/rc.d:
#ifconfig cxl0 toe #ifconfig cxl1 toeI enabled TOE on LAN manually via SSH
ifconfig cxl1 toeand indeed it works, 1.15 vs .23 TIME+ shown in htop for each respective iperf2 server process. No difference with iperf3. Interestingly enough pfblockerng also works, which means the system firewall is taking effect. This all may be due to this detail from the same calomel link:TCP TIMING: We noticed that short lived connections of less then 0.6 seconds will NOT use the Chelsio TCP Offload Engine (TOE) even if TOE is allowed universally or through Chelsio Offload Policy (COP). Not sure of the reason.
Next I tried enabling TOE on WAN
ifconfig cxl0 toeand noticed SSH and web UI don't become exposed to WAN until after reroot. Version CE 2.6.0 (22.01). Yes it's permanently exposed after reroot. At this point it's not a real issue but may be of help to anyone else that goes down this path. -
Yes, that's a nice catch. It should definitely be documented.
Did you try both 2.6 and 22.01 or just noted they are closely equivalent?
-
@stephenw10 Just 2.6.0.
-
Given the description of how TOE works I would have expected it to always bypass pf and not just at reroot. I'll try to work a working against using that into the docs but I'm not sure where it might fit that users would see it. The most likely place would seem to be https://docs.netgate.com/pfsense/en/latest/hardware/tune.html#chelsio-cxgbe-4-cards
In the future, if you believe you have discovered a security vulnerability, please report it privately as described on https://www.netgate.com/security and not on a public forum post. That way we can investigate it and work on a fix before it is widely known to the public.
-
Also I wonder how this works then:
https://redmine.pfsense.org/issues/9091
Maybe it's different on the T4 vs T5 cards? Or maybe you need that module loaded so TOE works as expected.
-
@jimp Yes, I also load t4_tom as part of the script mentioned above. As for why those services become exposed after reroot, I'm not sure, perhaps something to do with the startup sequence and that 600ms exception. The real issue is there's no mention of TOE bypassing pf in Chelsio's FreeBSD manual. However obvious it is to most, it's quite the gotcha for someone like me and unfortunately resulted in creating this thread. A lot of things are poorly or not documented at all.
-
Yeah that is definitely unexpected, and also very inconsistent.
Were you seeing any actual measurable performance gains from TOE for traffic passing through the firewall?
Usually for connection-based offloading like that (e.g. TSO, LRO) it primarily benefits when acting as an endpoint and can degrade performance when acting as a router.
I'm still trying to figure out how best to warn about this in the docs because I'm wondering if there is any time we should even recommend enabling that, not just warning against it.
-
@jimp
fetch http://ping.online.net/1000Mo.dat~1.12s, but after enabling TOE on cxl0 the download speed is severely kneecapped for the firewall itself, from my PC the speed is as expected. Reroot made no difference in regards to speed. -
@User1337 said in Reroot exposes SSH, Telnet, Web UI to WAN:
.... on cxl0 the download speed is severely kneecapped for the firewall itself
Totally normal.
A firewall is optimized for packet handling.
Downloading a file from the firewall command line make packets enter into user land, to be stored on some drive afterwards, that takes extra time.You just discovered why 'speed tests should be done on LAN devices, not the firewall itself'.
@User1337 said in Reroot exposes SSH, Telnet, Web UI to WAN:
from my PC the speed is as expected.
Point proven.
-
@User1337 said in Reroot exposes SSH, Telnet, Web UI to WAN:
@jimp
fetch http://ping.online.net/1000Mo.dat~1.12s, but after enabling TOE on cxl0 the download speed is severely kneecapped for the firewall itself, from my PC the speed is as expected. Reroot made no difference in regards to speed.That's just one part of it. Is it better/worse with or without TOE in each of those cases?
Just one single stream downloading a large file isn't a great test, but not everyone has a setup capable of testing things in multiple ways (different numbers of traffic streams, packet sizes, etc.)
