pfSense

I would love to see this as I'm using pfSense as router and would like to disable the firewall to get greater performance. As described here:

This page documents limiting access when it cannot be done using firewall rules. In some scenarios, pfSense is deployed solely as a router, with filtering disabled, where very high throughput is required and filtering is undesirable (such as the core or edge of some small to mid sized ISPs). With filtering disabled, firewall rules cannot be used to restrict access.

https://doc.pfsense.org/index.php/Limiting_access_to_web_interface

Is there a way for me to at least look at this? Are there particular things I have to keep in mind when trying to create a patch for this?

Marlin Cremers wrote:

Is there a way for me to at least look at this? Are there particular things I have to keep in mind when trying to create a patch for this?

This is for nginx: https://github.com/pfsense/pfsense/blob/master/src/etc/inc/system.inc#L1182
This is for SSH: https://github.com/pfsense/pfsense/blob/master/src/etc/sshd

This has bothered me since I started using pfSense. Every instance of people asking about this was ignored or discouraged.
In my opinion it is fundamental to a secure firewall to only have services used to administer the firewall listening on your internal network.
It does not matter if your firewall is blocking attackers from accessing those services when listening externally.
If they are not listening there in the first place, they will not conflict with forwarding ports to other internal servers and they cannot be exposed accidentally. Yes we can work around this by using non-standard ports but that is ugly and painful.
It is much cleaner to not be listening on external ports in the first place.

This is especially important when you need to be able to use the external ports for other things.
This is a land mine that many new users step on. ex. Why can't I forward my external port 443 to my web server? etc.

Having a pfSense firewall listen on WAN 22 and 443 causes it to clobber other traffic and is particularly painful.

openssh does NOT have the concept of being able to bind to a particular interface. It can however only listen on a given IP address.
If you in the pfSense web interface if you go to System -> Advanced -> Admin Access and under "Secure Shell" you check "Secure Shell Server Enable Secure Shell".
You then leave the SSH port blank so it uses port 22.
Using the shell you add the following to /etc/sshd_extra (replace LAN_IP with your LAN ip address):
ListenAddress LAN_IP

So if your LAN interface IP was 192.168.3.1 you would have
ListenAddress 192.168.3.1
With this configuration you are able to ssh 192.168.3.1 and administer the firewall and still be able to use port 22 on your external IP for other purposes.

While this works after you are booted you seem to have to manually run /etc/sshd to restart the service after a firewall reboot. I'm guessing sshd is running before the LAN has its internal address. That in itself is weird as my LAN internal address is static. I tried another super ugly hack such as:
vi /etc/rc.local
#!/bin/sh
/etc/sshd
:wq

While running /etc/rc.local works on the command line, it still doesn't work during bootup. Manually running a command from the web UI after a reboot of simply /etc/sshd does make sshd startup only listening on my internal address again. Unclear to me why this is needed. The test pfSense had sshd enabled.

If we could add a field under System -> Advanced -> Admin Access with the ssh listen address for example $config['system']['ssh']['listen_ip'] it should be possible to teach sshd to add ListenAddress output of $config['system']['ssh']['listen_ip']
to the sshd_config file when it is generated. It seems openssh does understand multiple ListenAddress statements.

I was able to do a much uglier hack to get nginx to listen only on an internal address.

How to fix Web GUI so it doesn't listen on WAN based on: https://awesomediocrity.wordpress.com/2017/06/05/confine-webinterface-to-ssh-only-on-pfsense-2-4/
1. Leave Web Configurator tcp port as 9443 to prevent a conflict during upgrade
2. Copy cp /var/etc/nginx-webConfigurator.conf /root/my-nginx.conf
3. Edit /root/my-nginx.conf to (replace LAN_IP with your LAN_IP):
listen LAN_IP:443 ssl http2;
#listen [::]:443 ssl http2;
#Pick something else if you care about ipv6
4. Edit /etc/inc/system.inc
5. Change this line: /* start nginx /
$res = mwexec("/usr/local/sbin/nginx -c {$g['varetc_path']}/nginx-webConfigurator.conf");
To:
/ start nginx */
$res = mwexec("/usr/local/sbin/nginx -c /root/my-nginx.conf");

After all of these unholy hacks are done we actually see the desired results:
sockstat -4 -l | grep sshd
root sshd 64329 3 tcp4 192.168.3.1:22 *:*

sockstat -4 -l | grep nginx
root nginx 36795 5 tcp4 192.168.3.1:443 :*
root nginx 36590 5 tcp4 192.168.3.1:443 *:
root nginx 36270 5 tcp4 192.168.3.1:443 *:*

I also find this issue a bit strange, not very happy pfSense nginx and sshd listens on every interface. I modified /etc/inc/global.inc and added two variables mgmt_ipv4 and mgmt_ipv6 to $g, then used them in /etc/inc/system.inc in 6 places for nginx like:

$nginx_config .= "\t\tlisten {$g['mgmt_ipv4']}:{$nginx_port} ssl http2;\n";

and added two lines to /etc/sshd for sshd like:

$sshconf .= "ListenAddress {$g['mgmt_ipv4']}\n";

It looks like this works well with one problem. I have static IPv6 config on mgmt_ipv6 but sshd starts without listening on that one, but it listens on mgmt_ipv4. If I restart sshd then it works fine.