Access to the FW via BLUE

Security
1

BLUE is not a trusted environment. So it should not possible to reach the FW config site (192.168.53.2:444)

I add:

iptables -A CUSTOMINPUT -s 192.168.53.0/24 -p tcp -d 192.168.53.2 --dport 444 -j DROP

into firewall.local.

This is fine! Now I not able to reach the IPfire WebUI at the BLUE Interface. But If I call the IPfire WebUI at the GREEN interface (192.168.50.2:444) (from a device in the BLUE LAN!) it is possible to login and manage.

Of course there is the proxy. But I enabled:
‘Disable internal proxy access to Green from other subnets’ and
‘Disable internal proxy access from Blue to other subnets’

As far as I understand this should be stopped all traffic from BLUE to GREEN (and reverse) via the proxy. But this does not help.

Where is my misunderstanding?

2

As explained in the wiki, these two settings do not deny the access to the IPFire machine.
For manual setting see wiki.ipfire.org - Manually editing the Squid configuration ( at the end of page ).

2 Likes
3

OMG … what a PITA …

The Wiki-page is at least … insufficient …

The file

/var/ipfire/proxy/advanced/acls/include.acl

exists in a fresh IPfire. But it is complete empty. I add

#Start of custom includes

acl BLUE src 192.168.53.0/24
acl IPFIRE-WEBUI dst 192.168.50.2/32 

# deny blue network access to IPFire
http_access deny BLUE IPFIRE-WEBUI

#End of custom includes

(and restart from IPfire WEBUI)
to stop the access to IPfire from the BLUE LAN

Maybe someone want to check this (and my changes in the wiki).

4

What was in the wiki before worked. Why did you completely change it.

I have confirmed that it worked.

http_access deny IPFire_blue_network IPFire_ips

denies access to any computer on the blue network to the IPFire green network ip

It worked fine for me as it was.

Your alteration just creates new names for existing ip ranges so doesn’t add anything to what was already there.

2 Likes
5

OK, … I redraw my changes …

From my POV I not could see that IPFire_blue_network and IPFire_ips where existing acl.

1 Like
6

If you look into /etc/squid/squid.conf above the custom section you will find those variables listed with their values.

3 Likes
7

@bonnietwin @jon Should we create a wiki page dedicated to all things to do to secure the BLUE zone? In the wiki all information is available but dispersed. I find that it should be added here as a short paragraph with all the links.

3 Likes
8

To bad this is not as easy as a check box in the WUI.

9

A checkbox is just a little element of a HTML page.
There must be some code in associated .cgi file to realize the function. Maybe someone wants do the coding.
IMO, this functionality isn’t very urgent. Allowing access to the IPFire WUI isn’t really a security problem.
Without credentials ( which are not shared by the admin, hopefully ) one can do nothing.
On the other side, a strict denial closes out the admin too.

EDIT: changed my answer according to TO’s problem. My first answer related to the problem of immediate blocking in firewall. :roll_eyes:

1 Like
10

I understand it is not that simple to implement.
Hopefully ipfire 3 this will be easier to implement.?

11

Sounds good!

I am not sure about the final location. Once it is added then we can take a look about the best location.