Configuration in a pseudo reverse mode

Discuss and get help configuring CacheGuard to protect Web servers
rmansell
Posts: 6
Joined: 14 Sep 2015 16:54

Configuration in a pseudo reverse mode

Post by rmansell » 14 Sep 2015 17:01

Prior to authentication on a Wi-Fi network, users are presented with content that can come from multiple ip addresses on the web. The firewall in the Wi-Fi controller that is used prior to authentication will not accept domain names – only ip addresses. The nature of the content supplier(s) networks is such that an exhaustive list of ip addresses is not available. We want to assign a fixed ip address to CacheGuard and place this in the Wi-Fi controller firewall whitelist and in turn, have the CacheGuard access the content provider(s). Note that a single ip address could point to more than one domain depending on the parameters in the URL. Once the Wi-Fi user has clicked on the "Accept and Connect" button, CacheGuard will no longer be part of the process. Can all of this be accomplished with CacheGuard?

User avatar
david
Posts: 157
Joined: 08 Aug 2015 20:38

Re: Configuration in a pseudo reverse mode

Post by david » 14 Sep 2015 18:14

Dear RMansell

In a classical configuration the internal interface of a CG (CacheGuard) is connected to the internal networks (WLAN) and its external interface is connected to the external network (Internet Router). In such a configuration the external zone is considered as an untrusted zone while the internal zone is secured by CG. In reverse mode Web servers are placed in the internal zone (behind CG) and CG acts as a reverse proxy for Web servers. For Web servers cloaked by CG users come from the Internet. So you get this:

Users ----- (Internet) ----- [Router] ----- (external)[CG](internal) ----- [WLAN] ----- Cloaked Web Servers

In forwarding mode CG acts as a forwarding (transparent or not) proxy for internal Web users who are protected by CG. So you get this:

Web Servers ----- (Internet) ----- [Router] ----- (external)[CG](internal) ----- [WLAN] ----- Users

From my understanding of your implementation you intend to revert the classical implementation in order to place cloaked Web servers in the external zone (Internet) and users of those Web servers in the internal zone (your WLAN). So you want this:

Cloaked Web Servers ----- (Internet) ----- [Router] ----- (internal)[CG](external) ----- [WLAN] ----- Users

Is my understanding correct?

Best Regards,
David Jan
CacheGuard Technical Team
https://www.cacheguard.com

rmansell
Posts: 6
Joined: 14 Sep 2015 16:54

Re: Configuration in a pseudo reverse mode

Post by rmansell » 14 Sep 2015 18:33

Yes, your understanding is correct.

User avatar
david
Posts: 157
Joined: 08 Aug 2015 20:38

Re: Configuration in a pseudo reverse mode

Post by david » 14 Sep 2015 19:43

Good

So I think that you can implement CG that way under the following conditions:

- Cloaked Web servers can be configured by giving their IP addresses and not names, so you should know the IP addresses of external clocked Web servers. If the same public name is associated to more than one cloaked Web server CG acts as a load balancer for those Web servers.

- Communications between CG and cloaked Web servers is done in an unencrypted HTTP mode so your Web servers should support HTTP and not HTTPS (but your internal users may access your external cloaked Web servers using HTTPS if your configure CG to act as an SSL terminator).

- In any type of implementation including yours, all traffic is routed via CG and will be part of the process (except if you use a L4/L7 switch like an Alteon to only route Web traffic via CG and route other traffic by bypassing CG).

- If you revert the CG implementation as you described I recommend that you disable the forwarding mode (mode web off) and configure the firewall accordingly to avoid exposing your infrastructure to threats. Please find below an extract of the documentation:
By default, all new connections incoming from the external zone and destined to internal and auxiliary zones are denied. On the contrary all new connections incoming from the web zone and destined to other zones are allowed. New connections incoming from the rweb, admin, mon, file, peer and auxiliary zones are denied by default. Default filtering are applied when a rule set is empty. When a rule set contains at least one rule, only allowed traffic in that rule set are allowed. So there is not need to add a deny rule at the end of a rule set to deny any other traffic.
So as you need a reverted implementation you should revert the default behaviour:

- Deny all traffic incoming from the internal interface (from the Internet in your case) and destined to your WLAN zone but only those really needed.
- Allow all (or only required) traffic incoming from the external interface (your users in your case) and destined to the Internet.

Please note that you firewall rules to configure regarding the Web cloaking (as when you configure the Web cloaking, firewall rules are implicitly added to the system).

Please read the following for further information:

- http://www.cacheguard.net/doc/guide/installation.html
- http://www.cacheguard.net/doc/command/firewall.html
- http://www.cacheguard.net/doc/command/access.html
- http://www.cacheguard.net/doc/command/rweb.html

Best Regards,
David Jan
CacheGuard Technical Team
https://www.cacheguard.com

rmansell
Posts: 6
Joined: 14 Sep 2015 16:54

Re: Configuration in a pseudo reverse mode

Post by rmansell » 14 Sep 2015 23:58

Thanks for your response. I have not reviewed the documentation links yet but based on your description of a possible solution, I do not think it will work as planned. The public servers are already cloaked and their ip addresses are not known nor can they be known - this is creating the problem. When a welcome splash screen is presented to a Wi-Fi user prior to authentication, content from the public servers is to be included. Since the user is not yet authenticated, specific firewall rules are used and are strictly ip/port/protocol based - no domain names are possible. Unfortunately, we have the domain names but not the ip addresses and are being told that many ip addresses are possible and are not predictable due to the architecture of the content delivery network. We would like to change the domain names for the content on the welcome screen to an ip address pointing to CacheGuard (in this case, a private address in the 10.2.0.x range) and this ip address will also be whitelisted in the firewall. The other side of CacheGuard would use the proper domain name to retrieve the content and provide it back to the WLAN client via the defined ip address. The content is required to be served using https.

User avatar
david
Posts: 157
Joined: 08 Aug 2015 20:38

Re: Configuration in a pseudo reverse mode

Post by david » 15 Sep 2015 10:16

Hi

Thank you for your clarifications but I'm a little confused. Could you please tell me which one of the following is your original need:

- The cloaking/hiding of the name of a CDN (Content Delivery Network)?
OR
- Filtering/Guarding Web traffic according to the name of a CDN?

Best Regards,
David Jan
CacheGuard Technical Team
https://www.cacheguard.com

rmansell
Posts: 6
Joined: 14 Sep 2015 16:54

Re: Configuration in a pseudo reverse mode

Post by rmansell » 15 Sep 2015 12:27

The need is to be able to reach the content delivery servers using a fixed ip address in the URL rather than a domain name. This will allow the firewall to be set up properly. The proxy should take the URL of the form "https://10.2.0.x/page&parameter list" from the WLAN controller and convert it to a URL of the form "https://sub.domain.com/page&parameter list" to retrieve the content from the internet. The firewall would whitelist 10.2.0.x. Since there is more than one domain possible (there are 2 defined at this time), parameters could be added to identify them and stripped as part of the mapping process.

User avatar
david
Posts: 157
Joined: 08 Aug 2015 20:38

Re: Configuration in a pseudo reverse mode

Post by david » 15 Sep 2015 14:26

Dear RMansell

I think that I understand better now. Actually my comprehension is that your original need is to filter Web traffic according to destination domain names (and not IP addresses) and allow only domain names listed in a white list. If so CacheGuard can manage it easily as follows:

- Implement CacheGuard in forwarding mode in your network.

- Force your WIFI end-users to use CacheGuard as a HTTP/HTTPS proxy.

- Activate the URL Guarding mode using the command "mode guard on" or the Web GUI at: [GENERAL] / [Main Settings] / [Main Features]

- Configure the URL Guarding mode using the command "guard" or the Web GUI at: [SECURITY] / .

Please note that CacheGuard manages Web traffic at the L3 but also at the L4/L7 while a classical firewall like the one that is built into your WIFI controller is limited to the L3 (IP Level) only. Hence the complex configuration you intended to implement.

You will find more information at:

http://www.cacheguard.net/doc/guide/guarding.html
[url]http://www.cacheguard.net/doc/command/guard.html


I hope it could help.

Best Regards,
David Jan
CacheGuard Technical Team
https://www.cacheguard.com

rmansell
Posts: 6
Joined: 14 Sep 2015 16:54

Re: Configuration in a pseudo reverse mode

Post by rmansell » 16 Sep 2015 16:16

Hi David,
We are getting closer but no cigar yet. I can get the unauthenticated users to use the proxy by explicitly using an ip address in the URL rather than a domain name - in fact, because of the L3 firewall at this stage, it is mandatory. I would then need the proxy to map to a specific URL or URLS. Guarding would not be an issue. All traffic would be secure. I noticed that in one of the configuration commands used for a reverse proxy, an item ID from the SSL certificate is required - since we are not owners of the site or the certificates, we do not have that information. The command looked very much like a mapping command (rweb site [raz | add <site-name> [(http | https <tls-object-id>) [<ip> [<qos>]]] | del <site-name> [(http | https) [<ip>]]]). What we would need is to map https://<ip address:port1>/parameters to https://domain1.com/parameters, https://<ip address:port2>/parameters to https://domain2.com/parameters etc. I am using the port number to identify different domains.

User avatar
david
Posts: 157
Joined: 08 Aug 2015 20:38

Re: Configuration in a pseudo reverse mode

Post by david » 17 Sep 2015 08:49

Hello RMansell

For my understanding I need some addition information.

How did you cable CacheGuard in your network (internal interface connected to your WLAN or to your Internet router)?

You say:
I can get the unauthenticated users to use the proxy by explicitly using an ip address in the URL rather than a domain name - in fact, because of the L3 firewall at this stage, it is mandatory.
What do you mean by using the proxy? Using it's IP (external or internal) address in your URL or using its internal IP address as an HTTP/HTTPS proxy with your Web browser?

Why do you use an IP address in the URL rather than the a domain name? Why don't you allow DNS traffic on your L3 firewall? FYI CacheGuard can also acts as a DNS (caching only) server.

You say:
I noticed that in one of the configuration commands used for a reverse proxy, an item ID from the SSL certificate is required - since we are not owners of the site or the certificates, we do not have that information.
The ID here is related to a self-signed certificate or CA signed certificate that you can build yourself using the "tls command" or Web GUI: [SECURITY] / [TLS Certificates] / [Manage TLS Objects].

You say:
What we would need is to map https://<ip address:port1>/parameters to https://domain1.com/parameters, https://<ip address:port2>/parameters to https://domain2.com/parameters etc.
The "rweb" command allows you to configure the reverse proxy. With the current version (NG-V1.1.2) the SSL offloading for an HTTPS cloaked website is done on CacheGuard so exchanges between CacheGuard and backend Web servers are in clear HTTP. Backend servers are configured using their IP address and not their network name (for HA reasons). In a future version we can improve those feature if we really identify a need.

Finally I still don't really understand your functional need. All we are talking about are related to possible technical solutions for your original need. Maybe we are in a wrong way... So could please explain me what is your functional need?

Best Regards,
David Jan
CacheGuard Technical Team
https://www.cacheguard.com

Post Reply