Can't block webconfigurator on the wan.
-
WTH,
anti-lockout is off,
here's my wan rules:
clearly blocking 443, yet external nmap show 80,443, and 22 wide open. FYI WebCfgPorts=443,80,22(all three of which are wide open on the nmap scan).States Protocol Source Port Destination Port Gateway Queue Schedule Description Actions 0/0 B * RFC 1918 networks * * * * * Block private networks 0/15 KiB * ReservedNot assigned by IANA * * * * * Block bogon networks
0/0 B
IPv4 TCP * 443 (HTTPS) * * * none
0/44 B
IPv4 TCP * * * WebCfgPorts * none
0/169 KiB
IPv4 UDP * * WAN address 1194 (OpenVPN) * none Allow OpenVPN
0/0 B
IPv4 UDP * * WAN address 1195 * none Allow OpenVPN -
-
tried changing the config.xml with a listen statement, that is ignored.
Implications
You cannot restrict the webConfigurator to LAN only via config.xml in 2.7.2.
Any “attempt” to bind it using <listen> is ignored, which explains why sockstat still shows * :443.
This means WAN exposure must be controlled purely via firewall rules, because the GUI process will always listen on all interfaces., but the firewall rules are ignored.
This can't be correct.
-
the more and more i delve into this the more concerning its getting. It's looking like in 2.7.2 and 2.8.0, you can not unbind 80,443, and 22. It's bound to all interfaces and nginix kernel. And that can't be changed.
Since I can't block those ports with rules on the WAN interface. The only suggestion is to change the port from 443 to something else. However that still leave port 22 wide open.
Do I really have to put a firewall in front of pfsense just to block these three ports?
Please tell me what I'm missing.
-
I can't believe this:
I changed the webconfigurator to 8443, and it immediately exposed port 8443 to the web, and ignores blocking rules on 8443. WTF?
-
@EricAiken you say external nmap - running nmap on your internal network hitting your external IP is not an external scan.
Those rules blocking 443 and your webcfgports are pointless since unless you allow traffic it is blocked by the default deny anyway.
Go to something you can send traffic to wan IP from, can you see me . org - or even use the grc scanner.
-
@johnpoz nope, running from an external ip.
-
This post is deleted! -
@EricAiken all traffic is denied unless allowed by a rule - if you are seeing open traffic from external to your wan IP. Then you have a rule open - what is in your floating tab.
You have never been able to unbind the gui from specific interfaces, it always listens on all IPs. Same goes for ssh. This hasn't changed in forever.
BTW your attempt at blocking 443, you have 443 as the source port.. That isn't going to be something you would normally every see.
edit:
You sure its not something in front of pfsense answering.. Do your packet capture on your wan, do your scan from external - you see that traffic specific hit your pfsense, and an answer.. So your state table with this traffic and pfsense answering. For pfsense to see traffic and answer you would for sure see both of those things.example: Here is outside hitting my ports.. both 22 and 8443 which is what my gui listens on. But as you can see no answers, since I have no rules that would allow that traffic on my wan or in my floating tab.
Here you see that those are the ports in use, and you can see my PC currently connected to them via the lan IP.
-
@EricAiken Check https://docs.netgate.com/pfsense/en/latest/troubleshooting/firewall.html#new-rules-are-not-applied ... you should not need to add a block rule since the default rule is to block.
Your fourth rule to block to WebCfgPorts has matched something (0/44B).
-
If it was something upstream the port wouldn't change when you change the pfSense gui port.
It pretty much has to be a floating rule or interface group passing that traffic.
If you look at the states at the CLI using:
pfctl -vssyou can see the rule that opened the state.Then check the rules with
pfctl -vsrto see what that rule is.
