Reverse squid proxy to protect IIS?

Hi all,

I need your opinions on this situation I'm facing:

I have to set up a public IIS server for a new "webapp" we're buying :rolleyes: .
Currently, I'm running an apache server on an openbsd machine in a dmz.
The apache/openbsd box is staying, IIS another box..

Now given IIS security history (heh, just in this past week!), I'm a bit wary. Setting up an IIS webserver in the DMZ in itself doesn't concern me that much, but the catch is it will need access through SMB (either NBT (tcp 137-139) or SMB over TCP (445)) to database files stored on the main server, which is in the private network... URGH!!!, yeah, it sucks.

Still, I have to deal with it.
So I was thinking, I have 2 alternatives:
1- IIS server in DMZ, allow TCP 445 from that host back into private net (only to DB server), possibly setup SSH tunnel or IPSec between the 2 hosts.

2- Have a Squid proxy in the DMZ filter and forward http requests back into the private net to the IIS server, so the IIS server would be inside the private net, but in a restricted subnet that would have only access to SMB to the DB server.

So, which one do you figure exposes less, or would be harder to compromise and less likely to be able to use the IIS server as a stepping stone to further compromise the internal network?

TIA

Ammo

I recommend leaving the IIS server on an seperate internal network that only has the aforementioned netbooboo access to a restricted number of hosts and then everything else denied, that way even if someone does manage to get in, they can't sniff anything else and their options for leaving the box are severely limited.

I also recommend using the apache server to setup a virtual host and use it as a proxy server to grant access to only this web server. You need to take special care to ensure that the proxy can only connect to the IIS server in question (to prevent you from being attacked by it) through not only the configuration, but your firewall as well.

I just recently setup an apache server to do an SSL and HTTP reverse proxy in just this fashion. If you are interested I could slap together a tutorial (reading material that I found on the internet was very very very sparse and often incomplete, at least for SSL so alot of it was learned the hard way :) ).

/nebulus

Yeah, doing a little more research I noticed squid doesn't seem to do reverse SSL, and anyways, apache would probably be the more logical choice...

Thanx for the insight..

Ammo

Hum, follow-up on my question:

how much (if any) http validation does apache do when proxying? Does it do unicode decoding or anything like that?

Ammo

Don't know if it does unicode decoding.

Using mod_rewrite you can configure it to do just about anything. I imagine you can set up a mod_rewrite rule to match undesirable URLs and block them.

I would definitely recommend that you set up Apache's reverse proxy to only forward requests that match given patterns. That would mean your're protecting your IIS server against new, as-yet-undiscovered attacks involving patterns of URLs that might not even be supported yet.

For example, if your application only uses .asp files, only forward requests .asp, not any other extensions. This means that the many well-known IIS attacks on .idc, .htr etc, will fall on your Apache (which will probably send 404 not found) rather than your (hopefully not vulnerable anyway) IIS.

You *can* forward HTTPS request via HTTP. This is somewhat of an advantage because it reduces the load on your IIS as it doesn't need to do encryption / decryption, although it increases the load on Apache (and Apache has been shown to be less efficient at SSL under some circumstances).

There are disadvantages in reverse proxying - it causes latency (not very much), it prevents the server from getting the address of the client to use in its logs, authentication and auditing. This usually means that if you want meaningful logs of the origin of the clients you'll have to log on the front-end web server (this is possible and works well)

Also still remember to keep your IIS (and indeed your Apache) up to date.

I haven't used such a configuration in a production environment but I've tested it and it appears to work.

Finally got a brief description of what I did put together. Seems to be pretty fast, I do dicuss a few security ramifications in there, let me know what you think:

http://www.antionline.com/showthread...hreadid=237755

/nebulus