This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Discussion about "Configure HTTP Proxy for a Network of Guests"

Many people here have requested me to email them a document I maintain that I make available to members of the UTM Community, "Configure HTTP Proxy for a Network of Guests."  If you would like me to send you this document, PM me your email address. I also maintain a version auf Deutsch initially translated by fellow member hallowach when he and I did a major revision in 2013.  Ich behaupte auch eine deutsche Version, die ursprünglich von dem Mitglieder hallowach übersetzt wurde, als wir zusammen im Jahre 2013 eine große Revision machten.

Recently, fellow member kerobra asked me for the document and then posed the following questions via our PM conversation:

Hi Bob,

thanks a lot. But I have a few questions if allowed:

VII. DNAT Rule:

o ‘[Guest network] → HTTP Proxy (8080)→ [Guest network] (Address) : DNAT to HTTP (80)’

With that rule should only be prevented, that a guest user could use the proxy in "standard" mode even if it runs in transparent mode?

That means that a potential exploit would remain; a user on the Guest network could use a service like DynDNS to trick the Proxy into providing access to an internal IP.

How can he do that? The dyndns entry will point to the external IP (as SNATing to an additional IP isn't possible when proxying), but the IP itself is no secret to the user if he uses a webservice that shows the current IP. If there is access via NAT he could always use an external server to get into the internal network. But he can't connect to external IP:port from the guest network or can he? That should be forbiddable with the transparent skip list I think.

I don't understand the need for having the internal network targets being skipped generally (skip list) and having an additional filter profile blocking the internal ip-range. If I use different blocking categories okay, but the explicit blocking of destination URLs in the internal network won't "hit" anytime because of the global skiplist?

Cheers

Kevin

We discussed this and decided that I should start a thread here with my response so that we all can continue to discuss the issues here.  My response to Kevin is:

Hi Kevin,

"With that rule should only be prevented, that a guest user could use the proxy in "standard" mode even if it runs in transparent mode?" - Correct.

"... use a service like DynDNS to trick the Proxy into providing access to an internal IP."  I have an instance in the AWS cloud that's connected to our lab UTM via an IPsec tunnel.  Part of what I do requires that the lab UTM know the private 10. IP at Amazon.  This is done using the FreeDNS service.  There's no rule that says you can't give out a private IP from a public DNS server.

It's been a long time since I went through the document, but the approach does have overlapping safeguards where one technique covers a hole left by another but also covers many of the same things.

Cheers - Bob



This thread was automatically locked due to age.