1

I have a BlueCoat ProxySG 810 appliance and want to use it as both an HTTP Proxy Server for clients on the Inside interface of a PIX 525 Firewall (OS Version = 8.0(4)) and a Reverse Proxy Server for my Web Servers on the DMZ.

  1. Should I place the ProxySG 810 on the DMZ?
  2. If I do so, does the ProxySG 810 need to be allowed access the Inside network (i.e. Initialize connections to Inside) to be able to serve as an HTTP Proxy Server to the Inside Clients?
  3. I think the answer to the 2nd question is no; if such, is it sufficient to just allow access from Inside to the DMZ (and ban the opposite direction)?

Notes:

  1. PIX 525 (8.0(4)) supports WCCP.
  2. The Outside interface of the PIX 525 is connected directly to the Internet.
1

The first question I'd have would be, what do the web servers need to get to that's internal and requires a reverse proxy? If I had to do this, I'd put the Proxy in the DMZ and set it up primarily as a reverse proxy. There's no way I would put a reverse proxy internally and allow DMZ/external sources to get straight to it.

Then, once you have that tuned and working properly, set up egress WCCP to push to your proxy, taking special care to only get client subnets and not servers (I would never suggest WCCP for a server. If you want it to be proxied, set it manually to a VIP that points to your proxies (if you have multiple)). Where you do this is key, because some versions only support it on the egress interface of devices (I ran into this with a l3 cisco switch). Also, as a FYI, I have had issues setting up WCCP on firewalls in the past because of the way traffic flows with WCCP, there are sometimes issues with state tables. Bluecoat suggested that I remove the state inspections for this box, and I immediately required the business to move WCCP to the closest switch, therefore I would similary suggest putting this on another device if at all possible.

It's hard to tell from the limited information we have what the best place to setup WCCP would be. Do you only have one firewall in your environment, or do you have a separate DMZ and internal firewall(s)?

0

No no no no no no no no. I can't say no to this one enough times. Blue Coat don't support this deployment type with a very good reason: it's incredibly easy to create a policy that allows ALL external clients to connect to ANY internal host.

Seriously, ask your Blue Coat sales engineer and they will say the same thing.

As requested:

1) Always, yes.

2) Not for standard HTTP proxy clients no.

3) Yes.

Now, assuming you have this set up, think about what happens if someone from the outside connects to your proxy as if it is a standard HTTP proxy. They will be able to connect to any machine in your DMZ (as the default policy for an HTTP proxy should be allow) without some very carefully crafted VPM policy. Now think about what happens if someone mistakenly opens up a rule on the DMZ/Internal firewall that allows the proxy to talk to the internal LAN, disaster awaits you.

  • Thanks @Chris for the answer, but I'm get somehow confused because I asked 2 questions which my opinion is the answers are: yes & no, respectively. Please answer each question separately, thanks in advance. – Joseph Dec 21 '13 at 7:52
  • Where have you seen it documented that bluecoat doesn't support this deployment type? I have worked with bluecoat in numerous similar scenarios and have put together what I feel is a relatively secure architecture. – JZeolla Dec 22 '13 at 22:20
  • An ex senior Blue Coat employee told me whilst I was working at a reseller. You might feel it is secure, but what happens when a less knowledgeable user comes along and opens everything up with a single mistaken line in the VPM? Not worth the risk if you ask me. – Chris Dec 30 '13 at 16:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.