For some obscure reason I could access the WebGUI managment console via the internet, even though the ports were not opened to the WAN side, and only set for internal abuse.
Ports 81, and 1013 had no entries in the firewall settings either, which means they should be ignored or dropped. Out of the 15 odd boxes I have running, only 3 suffered from this issue, 2 of which were fresh installs with core141 ISO from two months ago, and one of these is a VM. Not all boxes are on the same cores, so I have not figured out what has caused it.
This is how to fix this issue with ipFire when the WebGUI is accessible from the outside world.
You can test to see if you are effected as well by trying to connect to your firewall from the outside as follows, open a browser and go to:
http:// Your live IP:81
If it redirects you to the WebGUI, may moan about insecure certificate, and prompt a login, then you have a problem.
On the other had if it times out, you are fine.
First thing to do is check on the firewall what ports your server is listening on.
*ssh -p 222 root@ Your FW IP *
lsof -i -P -n | grep LISTEN
You should see something along the lines of….
httpd 1218 nobody 3u IPv4 33056 TCP *:81 (LISTEN) httpd 1218 nobody 4u IPv4 33058 TCP *:444 (LISTEN) httpd 1218 nobody 5u IPv4 33060 TCP *:1013 (LISTEN) sshd 4912 root 3u IPv4 30412 TCP *:222 (LISTEN) httpd 5024 root 3u IPv4 33056 TCP *:81 (LISTEN) httpd 5024 root 4u IPv4 33058 TCP *:444 (LISTEN) httpd 5024 root 5u IPv4 33060 TCP *:1013 (LISTEN) squid 13593 squid 20u IPv4 74184535 TCP <Green0 IP>:800 (LISTEN) squid 13593 squid 21u IPv4 74184536 TCP <Green0 IP>:801 (LISTEN) unbound 16531 nobody 4u IPv4 72225765 TCP *:53 (LISTEN) unbound 16531 nobody 5u IPv4 72225766 TCP 127.0.0.1:8953 (LISTEN)
What we want to do is let the server listen to 81 and 444 from the internal network only, and not from *
Listen <Insert LAN IP>:81 Listen <Insert LAN IP>:444
For example, if the Green0 gateway IP of your firewall is 192.168.1.1 it would look like
Listen 192.168.1.1:81 Listen 192.168.1.1:444
If Apache fails to restart, run the same command with stop and then again with start.
To see if the port configuration has been changed correctly do a check
lsof -i -P -n | grep LISTEN
It should now look something like this if the gateway IP was 192.168.1.1
sshd 4912 root 3u IPv4 30412 TCP *:222 (LISTEN) squid 13593 squid 20u IPv4 74184535 TCP 192.168.1.1:800 (LISTEN) squid 13593 squid 21u IPv4 74184536 TCP 192.168.1.1:801 (LISTEN) unbound 16531 nobody 4u IPv4 72225765 TCP *:53 (LISTEN) unbound 16531 nobody 5u IPv4 72225766 TCP 127.0.0.1:8953 (LISTEN) httpd 20470 root 3u IPv4 74214732 TCP 192.168.1.1:81 (LISTEN) httpd 20470 root 4u IPv4 74214734 TCP 192.168.1.1:444 (LISTEN) httpd 20470 root 5u IPv4 74214736 TCP *:1013 (LISTEN) httpd 20472 nobody 3u IPv4 74214732 TCP 192.168.1.1:81 (LISTEN) httpd 20472 nobody 4u IPv4 74214734 TCP 192.168.1.1:444 (LISTEN) httpd 20472 nobody 5u IPv4 74214736 TCP *:1013 (LISTEN)
What I have noticed is that if your server redirected the 81 -> 444 traffic on externals, then it will also let you connect to 1013 externally. This is irrespective if you have configured or left the captive portal settings disabled. This should not be a problem, but if you are paranoid and wish to prevent connections to it, just kill the port
kill $(lsof -t -i:1013)
You may want to add that line into the /etc/sysconfig/rc.local so that it removes it at the next restart or you may sit with the same problem again.
I have not found where ipFire keeps the config for the captive portal or where it gets port tcp/1013 from, someone else may want to shed light on this. …hint, hint
Then you could make a change and have it listen local (Green0) only instead of the world.
I hope this is helpful for those wondering wtf is happening, and how to fix it. Cheers!