Squid: howto seperate subnets from each other?
-
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