Squid: howto seperate subnets from each other?
-
Hello everyone
My network setup looks like the following, each hive representing a subnet.
¦–-WLAN--+
¦
¦---LAN---Router---WAN---¦
¦
¦---VLAN---+Now I would like to setup squid on my pfSense box and lock down each segment so the web (80/443/tcp) can only be reached via squid... so far so good.
At the same time I would like to deny access to the pfsense webinterface from VLAN which is more or less a DMZ. This is quite easy from a firewall rule perspective, however when a browser in VLAN uses squid the webinterface is easily accessible.
So long story short:
How can I deny access to the webinterface via squid on the VLAN segment?
And more general:
How can I seperate each subnet when each is using the same squid instance?
Thanks in advance
-
Put your outgoing rules (to block) first for each interface.
In my example below- the public interface is blocked from seeing the LAN interface (plus a couple of other public subnets) before the allow all rule.
public net and 192.168.15.0/24 are the same.
-
Thanks for your reply. Blocking each subnet makes total sense to me.
However, please have a look at my ruleset:
Action: Reject Source: VBOX net (192.168.3.0/24) Port: * Destination: 192.168.3.1 Port: 443/tcp
I would have expected that this rules blocks access to pfSense webinterface, but it doesn't. The user connects via proxy so the rule will never match!
The same applies to this rule.
Action: Reject Source: VBOX net (192.168.3.0/24) Port: * Destination: LAN net (192.168.1.0/24) Port: *
The rule above clearly blocks access to the LAN subnet - but only if not connecting via squid.
My test setup shows, that I can access the LAN subnet from VBOX subnet via proxy (destination ports 80/tcp & 443/tcp)
So how can I configure squid to block this access?
-
One thing you could do is change the pfSense webgui port and then block all connections to that port.
Something to watchout for is that the webgui listens on every interface and so you have to be careful to block access to each of those from your VBOX interface. For example you will be able to access it on your WAN IP from the VBOX subnet.
A slightly odd thing here is that unless you are running some experimental version of Squid it doesn't normally proxy https traffic. :-\
Steve
-
Hello Steve
Thanks for replying. I also would love to configure the interface on which the webConfigurator is listening on.
But anyway I solved my issue in the meantime by simply blacklisting the relevant subnets:
192.168.1.0/24 192.168.2.0/24 192.168.3.0/24
Mission completed!
-
It's probably still accessible on the WAN address. ;)
Steve
-
Ehrm, it shouldn't as squid is only listening on my internal vlan interface. Also 443/tcp from WAN is blocked…
-
Maybe I should open another thread for this question, but is there a way I can prevent DNS tunneling from my DMZ to the outside? E.g. by disabling TXT records within DNS?
-
To access the WAN interface from an internal subnet you are only filtered by the firewall rules on the internal interface. Since the WAN IP is public it will not be caught by any of your rules or your squid blacklist. I'm not sure how squid comes into effect here though if it was proxying connections to internal interfaces ok I see no reason why it shouldn't do so for WAN.
You mean like vpn-over-dns?
Steve
-
Ouch! Never thought about that! :-\
No, I am not talking about DNS in VPN, I am talking about TCP/UDP in DNS txt records:
http://www.sans.org/reading_room/whitepapers/dns/detecting-dns-tunneling_34152
-
Neither did I until I stumbled across it by accident one day and was forced to think about it.
I don't think I've ever tested it on a box running Squid though so your situation may be different.That's what I meant by VPN-over-DNS, hiding an encrypted tunnel inside dns queries. I have never looked into blocking/detecting it, mostly because last time I looked into setting it up it was not trivial. However I see that Softether supports it so maybe it will be more common: http://www.softether.org/1-features/1._Ultimate_Powerful_VPN_Connectivity#1.6.VPN_over_ICMP.2C_and_VPN_over_DNS%28Awesome!%29
I assume to do this you still need to actually own a domain though. :-\I'd be interested in any thoughts.
Steve