Can tcp6 be removed from Listening Ports 444 and 81?

Security Firewall Rules
1

After reading an older post
How to disable ssh from RED - Dec2020
it occurred to me that ANY device connected to green could become a BACKDOOR for the outside world and access IpFire’s WebUI, or the SSH port. It’s every Security I.T’s nightmare; an employee that connects their badly compromised laptop to the company network.

In the case of the prior post I suspect it may have been the Pi-Hole installed on the green, as my playing around with Pi-Hole one or two years ago produced some odd behaviour activity which made me drop the project. Never had time to futher investigate.

Anyways back to my topic…
In order to tighten up security of any device access to ipFire’s WebUI and SSH ports from the green (this is already blocked on blue by default) I created rulesets that would allow full access to only one specific IP, own by one fully trusted device having a static IP, and blocking access to ports 444, 222, and 81 for all others.
In firewall groups I created the ports entries, and added those to a new Service Group call ipFire_Access_Ports, and used that to create the blocking rule. See my INPUTFW chain

Chain INPUTFW (1 references)
target prot opt in out source destination
LOG all – * * 192.168.68.181 192.168.68.1 limit: avg 10/sec burst 20 LOG flags 0 level 4 prefix "INPUTFW "
ACCEPT all – * * 192.168.68.181 192.168.68.1
LOG tcp – * * 192.168.68.0/24 192.168.68.1 multiport dports 444,222,81 limit: avg 10/sec burst 20 LOG flags 0 level 4 prefix "INPUTFW "
DROP tcp – * * 192.168.68.0/24 192.168.68.1 multiport dports 444,222,81
LOG udp – * * 192.168.68.0/24 192.168.68.1 multiport dports 444,222,81 limit: avg 10/sec burst 20 LOG flags 0 level 4 prefix "INPUTFW "
DROP udp – * * 192.168.68.0/24 192.168.68.1 multiport dports 444,222,81

The new rules works for SSH port 222 as I can access SSH from my trusted PC, and is blocked when accessing from another PC.

However, I was still able to get to the WebUI port 444 from the other PC !!!

I did a netstat -tulpen and got the following …
[root@ipfire ~]# netstat -tulpen
Active Internet connections (only servers)
Proto Local Address Foreign Address State User Inode PID/Program name
tcp 0.0.0.0:222 0.0.0.0:* LISTEN 0 330399 14760/sshd: /usr/sb
tcp 0.0.0.0:53 0.0.0.0:* LISTEN 0 23337 3020/unbound
tcp 127.0.0.1:8953 0.0.0.0:* LISTEN 0 23339 3020/unbound
tcp6 :::444 :::* LISTEN 0 30170 5008/httpd
tcp6 :::81 :::* LISTEN 0 30166 5008/httpd
tcp6 :::1013 :::* LISTEN 0 30174 5008/httpd
udp 0.0.0.0:53 0.0.0.0:* 0 23336 3020/unbound
udp 0.0.0.0:67 0.0.0.0:* 0 159290 11924/dhcpd
udp 192.168.0.101:68 0.0.0.0:* 0 29731 730/dhcpcd: [netwo
udp 192.168.68.1:123 0.0.0.0:* 0 29945 4893/ntpd
udp 192.168.0.101:123 0.0.0.0:* 0 29943 4893/ntpd
udp 127.0.0.1:123 0.0.0.0:* 0 29941 4893/ntpd
udp 0.0.0.0:123 0.0.0.0:* 0 29936 4893/ntpd
udp 0.0.0.0:514 0.0.0.0:* 0 23297 2983/syslogd
udp6 :::123 :::* 0 29933 4893/ntpd

The tcp6 :::444 caught my eye.
Is it possible that even though the rule was blocking tcpV4 traffic that it was letting through tcpV6 from my other PC (A win10 box)?
Oddly in that the netstat did not display a listening for 222 for tcp6, and the rule worked correctly for that one.

Is there a way to disable tcp6 listening on port 444 ?

2

@rejjysail

Look at this post

https://community.ipfire.org/t/how-can-i-disable-ipv6-bindings-for-services/5332

3

Thanks @loup001
I just made the changes to the /etc/httpd/conf/listen.conf as mentioned in

Ports 81 and 444 no longer display tcp6 listening, but I am still able to connect to the ipFire’s WebUI from the other PC.

So somehow the rule doesn’t work. Either something is wrong with my rule, or there is something else somewhere that allows this to accept before this rule is checked.

EDIT:
I’ve figured out why the rule works for port 222 and not 444
There’s a iptable entry GUIINPUT, which comes 3 chains before the INPUTFW (where the WebGUI rules are located), and this entry allows all GREEN to accept 444.
Looks like I’ll need to add this somehow to the CUSTOMINPUT chain, way up on the table, once I figure out how …

4

That is not correct for the WUI. See this link for how to block blue having access to the WUI.
https://wiki.ipfire.org/configuration/firewall/accesstoblue#deny-blue-clients-access-to-the-ipfire-web-interface

Use the firewall.local file
https://wiki.ipfire.org/configuration/firewall/firewall-local

However be careful when trying to block everything except yourself from accessing the WUI. One error and you can end up blocking your own access to the WUI and you will then need to go in to the console and edit the files to undo it.
People have done that before and you can find threads for how they had to fix it.

Anyone on Green still has to figure out the password for the WUI to be able to access it so your employees don’t have instant access to the WUI they have to attempt to guess the passwords.
You could try the guardian addon.
https://wiki.ipfire.org/addons/guardian
It basically gives you fail to ban type capabilities for ssh and for the wui. If your ssh is set up with certificates then you don’t need it for that but you can use it for the WUI access. You can also whitelist your own machine(s) ip so you don’t get banned if you make an error. You can adjust the number of errors before being banned and the ban time. The banned IP’s are logged and you can have them in the standard log file or direct them to a specific log file.

1 Like
5

Boy was I ever under the wrong impression !!!
I tested and you are correct.

Based on info on the WebUI …

image
image846×185 11.1 KB

BLUE should not have access to GREEN. Quite misleading for a rookie like me.

So what is the purpose of the GUIINPUT chain in that case ?

image
image785×211 14.7 KB

Yes I realize I could lock myself out.
That’s why I wanted to create a rule higher up that would first allow a specific IP Addr to access 444 or 222 ( so to use eLinks ) before adding any DROP rules further down.

I was also surprised to discover how far down the chain were any rules i created (INPUTFW) via the WebUI. DRO or REJECT rules probably would never have seen any action as they could have been ACCEPT in earlier chains.

Thanks again for all your helpful advice and information.
You are a busy guy responding to so many community blog questions.
We all appreciate the effort.

6

It is correct for access to the GREEN LAN. It is access to the GREEN WUI on the fiewall that is allowed from BLUE by default but I also see where you are coming from.

7

@bonnietwin
I’m obviously not interpreting that WebUI correctly.
In my simpleton view, the above tells me that …
GREEN interface can access the internet (via RED i assume), and can access the BLUE intefaces (eg: any device IP Addr on BLUE)
BLUE interface can also access the internet, but access to GREEN is ‘(Blocked)’ by default.

Unless I’m wrong, the ipFire’s access to the WebUI port 444 resides on the GREEN interface does it not ? This is where my confusion sets in.

If in fact BLUE really is blocked to GREEN, then maybe there’s already a default pinhole built-in the ipFire to allow the green WebUI access from blue.

No big deal. I simply made wrong assumption based on what the WebUI displayed. :slight_smile: