Hi,
new to IPFire so only had first few days on a cloud server. I’m not sure if I’ve missed soemthing, but my web gui is accessible on the red iface, its public IP. Reading wiki, by default this should be prohibited and IPFire amanagement only accessible on green interface
I did try to block this by creating firewall rule Souurce: any, Destination : Firewall-Red, Protocol any (or TCP:444), Action: drop… but that has no effect at all. Still able to get to the management on the public IP address.
Luckily the provider does allow their own firewall filtering over this so I could provisionally create rule in hosting stopping this, but I would rather have RED on onfiltered network from hosting and manage rest in IPFire.
I’m on IPFire 2.27, CU172
Any advice where to look for to disable this? Or best enable fromTCP to 444 from specific IP adresses and disable from all others… FW rules seem not to be doing anything for me.
The default firewall behaviour is really blocking access from the WAN.
Therefore the situation you describe can, to my knowledge, only occur, if there is a physical or logical connection of WAN and LAN.
From the LAN ( green network ) you can reach IPFire’s public address. Because the request is coming in on the LAN NIC it is allowed.
EDIT: This is true only if the proxy isn’t active and used.
Hi Bernhard, thank you fro your hint. I don’t think this is the case, although it is really weird… the IPFire actually runs in a datecenter in Germany and I can indeed access it from the rpivate network there using the IP address of green adapter. But at the same time, it is accessible on it public IP adress, tested from several different locations (have several offices offices over europe from where I’ve tried). Setting up rule on firewall to block this seem not to do anything.
The only traffic I can restrict is the datacentre firewall - ie. firewall before the red NIC. Have only these two rules
with Remote Admin group being 3 IPs where IT support can realisticly access it from…all therest should be blocked. But no… still can access it from pretty much anywhere I tried, it’s like FW not active at all?
in FW Option s, Block Policy is set to DROP for all three INPUT/FORWARD/OUTPUT chains.
But in my case it works as if the access to red is not blocked at all and fw rules are not doing anything
Proxy not active and not used, correct.
But since you mentioned “physical or logical connection of LAN-WAN” - there might be something dodgy there, it runs as cloud server and VM with two adapters. Each has distinct MAC address and private LAN(green) is assigned VLAN tag.
This is my zone config
But I do not see how this would allow for the gui management on redNIC still? external traffic arrives to red and is at that moment input chain for the firewall, isn’t it?
I can get to 444 from any other IP adress - it is just opened to everyone in internet at the moment. An you can see that none of those rules has a single packet counted…like FW not really active??
The rules of each type are processed from top to bottom (internally in the iptables chains). The first rule that matches (where source, destination and all other settings equal with these in the packet that is currently processed) is executed and all rules after that are not evaluated any more.
You can use the arrows to re-order rules of the same type or define a position when you create new rules.
Mystery solved!
the problem indeed was not in the fw rules, but the fact that web gui has its own chain in IPFire, “GUIINPUT” - and there was access opened up from any ip address to red0.
And it has only got there 'cos I followed installation guide that suggested to add this to /etc/init.d/firewall cfg to have initial access to the IPFire. And this has stayed there as there was no mention to remove it later…and few day later one does not remember such detail
The guide here at IPFire wiki wiki.ipfire.org - Hetzner Cloud seem to go about it in a smarter way, just modifying iptables on CUSTOMINPUT chain from command line, so it is cleared on next reboot.
This isn’t quite right.
The wiki page suggests a rule in CUSTOMINPUT set from the console.
This rule is active in iptables - until a restart. At startup the firewall rules are build from the settings files of IPFire. These are only modified by the WebGUI ( usually ).
The chain GUIINPUT does allow access from green only!
Hi Bernhard,
correct, I think the guide here at wiki goes uses better approach adding the ruel form command line,ie. only temporarily (this way I would not have forget days later the /etc/initd.d/firewall has been modified iopening this up to veryone). I’ve removed the open access to web gui from firewall conf file and used firewall.local wiki.ipfire.org - firewall.local conf file to open up access to management on red0 from authorised IP addresses, this adds the rules into CUSTOMINPUT at start up and seem to work fine.
@jon , for the records. The wiki about Hetzner Cloud installation mentions adding the iptables rule from the command line only. This is correct, so no change is necessary.
I think that @pinky used a non IPFire based installation guide that told him to change the /etc/init.d/firewall
file which became a permanent change as the guide never mentioned to remove the edit after doing the initial setup.
Yes, indeed got confused by guide from elsewhere - as i was to set this up within IONOS host, I first found this, littel outdated, guide that sugegsted modifying /etc/init.d/firewal confing file Install IPFire Linux Firewall | IONOS DevOps Central
Troubleshooting the issue I found the local wiki guide goes about the initial access oepening in a smarter way… noting to be corrected here guys!
).
