Complicated server/router/firewall question

Question

I think this is a fairly advanced question, I hope someone with experience can help me. Deep breath, here we go:

We're a small, but growing, website that is looking to add another server in so we'll have two: One Web Application server and one Database Server.

We're also looking to get a hardware Firewall.

All standard stuff.

Our servers are hosted by a hosting company (natch) in one of their facilities. We don't own our own box, but instead are simply renting a rack shelf from a company that does. When we get our Firewall and additional server, we'll rent a couple of more shelves.

Pretty straight forward, I guess.

Now it gets a bit more complicated: We need direct access to both servers (ie. for Remote Desktop access, SQL server access, FTP access, etc).

We have our single IP address for the website and, although our connection comes through a router before it reaches our server, we don't have access to it. If I try and navigate to our default gateway I get nothing.

What would be the best way to add a Firewall to our current configuration? We were hoping to be able to get something like a Firebox X1000 cheaply off eBay and take a request for: www.ourdomain.com and forward it to Server A (eg. 192.168.0.10) and a request for server.ourdomain.com and forward it to Server B (eg. 192.168.0.11).

Does this make any sense? Are we going about it the wrong way? Does such an enterprise level Firewall even exist? (As an asidE: 2,000 concurrent sessions is about the maximum we've seen on the site so far, but obviously it would be good to have to grow.)

Thanks for any help, I'm utterly perplexed and the people at Watchguard and Juniper, while being incredibly helpful, can't seem to put my mind at ease.

---

Update: Thanks to Zoredache and Jesper Mortensen for answering my question in the most straight forward and useful way. I understand a lot more about this whole process now (obviously there's no easy way for a h/w firewall to do what I wanted - and my original request doesn't really make sense now I understand more about layers - doh).

Ultimately, we have decided to use a third server as a Firewall, rather than a dedicated h/w firewall. The reason for this is mainly because it will work out a lot cheaper for us and do exactly the same job. We were already planning on having a third server to collect our own analytics, which we expect this to be a pretty light job (they're triggered on the client and then logged in SQL), so it makes sense for us to move it to the "front" of our configuration and use it as a firewall too.

We'll also probably configure a VPN on it so we can administer the Web App server and DB server that way, rather than directly connecting to them.

This will mean we don't need to buy a h/w firewall or rent an additional rack unit.

The only difference between the recommendations and our solution is that we'll be using Windows Server 2008 instead, because of a) my knowledge of it and b) we get it for free through our BizSpark pack.

Thanks again!

PS - Anyone got any tips for the specs of this new firewall/VPN/(lightweight)SQL server? (A fast processor and a good amount of RAM seems to make sense to me... but what do I know? :)

Answer 1

Sure it makes sense, and would be pretty easy to do with a Linux-based firewall. Simply setup the Linux box with one interfaces that has the public address, and a second interfaces with a private address.

Then setup a reverse proxy like squid. Squid or whatever reverse proxy you choose can forward http requests to the internal systems based on the host header.

You can use a VPN to the Linux firewall, to get access to most of the other services. I don't think it would be a good idea to have your SQL server directly connected to the internet. If you must access some services you could also use NAT to forward some port you choose to the port on the internal system.

Answer 2

Welcome to this site, Django R. :-)

You're doing the fact-finding smartly, but clearly IP networking is not your primary skill set -- maybe hiring a nearby consultant would be a good idea? This isn't hard stuff, but depending on your datacenters (DC) requirements the solution can take different directions...

We don't own our own box, [...] When we get our Firewall and additional server, we'll rent a couple of more shelves.

Ehmn, which model is it -- colocation of your own hardware, or a managed service (DC provides hardware and some or all system administration)? If it's managed service, then let the DC handle this in their usual way, so that your solution is 'familiar' to the DC techs.

What would be the best way to add a Firewall to our current configuration?

One common approach would be:

• to make a /30 subnet of public IPs for your firewalls outside interface and the DC router (other methods exists, this is much a matter of DC preference).
• a small (as big as you can justify) network of public IPs for your web servers (maybe a /29 subnet with around 5 usable IPs).
• a professional firewall (Cisco, Juniper, Checkpoint, there are many mature products) to route and firewall between the nets, and to provide a VPN for remote management access to the firewalled net.
• database servers and other support servers on a private IP network & VLAN behind the webservers.
• a KVM-over-IP or a remote managament gateway behind the firewall for remote management (less important if you don't have any servers on a private IP range & VLAN).
• a switchable PDU (powerstrip) behind the firewall to hard reset servers that have crashed.

This way your Internet-facing servers have public IP addresses, which simplifies troubleshooting, allows for easy remote monitoring, and is in general just nice. And your database servers don't have public IP addresses, which adds a layer of indirection, i.e. is helpful with regards to security-in-depth.

Firebox X1000 cheaply off eBay and take a request for: www.ourdomain.com and forward it to Server A (eg. 192.168.0.10) and a request for server.ourdomain.com and forward it to Server B (eg. 192.168.0.11).

Not easily. Your firewall works on layer 3; it does not have access to HTTP (layer 7), so "www." and "server." hostnames are not known to it. You can do static NAT on IP addresses and port numbers only. You could assign multiple IP addresses to the external interface of the firewall, or use different port numbers, but this is IMHO a cumbersome solution.

Additionally, if your web servers are on internal IPs, then you will always see the firewall as the origin IP of the request, i.e. webserver logs have less meaning.

You could use a load balancer (layer 7 device) up front, and have it direct traffic based on HTTP server names. In this scenario, the origin IP address is added to the HTTP request as a X-FORWARDED-FOR HTTP header, and your webservers and web applications need to look for this header if they need the original IP. A linux server, with the built-in software firewall, and a HTTP server such as nginx would be a excellent and inexpensive solution. But ask yourself, do you have the prior experience to quickly set up such a server, and keep it well maintained...

Answer 3

The tricky thing about this is determining the topology constraints of your hosting company as well as your other performance requirements, i.e what kind of bandwidth does your site have? Could you conceivably need gigabit throughput?

What you are essentially talking about doing is changing the ips of your dedicated serves to a private range you can't route to (192.168.0.10 and 11 respectively) and then fronting them with another colocated server with several public ip addresses that do port forwarding. So servers A and B would communicate on their local switch via the 192.x subnet, and all inbound internet traffic would traverse router/firewall C. You would do NAT from router C to A and B respectively , and your website would resolve as normal to one of the ip addresses on C. This is a basic setup, and the firebox probably does it ok although I think you would be better off with a Linux based server to do the routing or a packaged solution like Vyatta.

The key is checking with your hosting service because they may not allow this, and if they don't then your options may be limited to host based fire walling or some other relatively insecure solution. Your hosting provider may also have a different setup for people who want to handle their own routing and fire walling, it is worth checking with them.

Answer 4

Without writing as much as the others, I did pretty much exactly what you need here for my last company.

We had a Fortigate firewall and configured it to accept connections externally to a variety of addresses, which then forwarded internally to different hosts. Ie. siteA.domain.com goes to server A, siteB.domain.com goes to Server B.

It wasn't too tough to set-up and we had services automatically fail-over between sites.

Answer 5

You didn't mention what kind of firewall behavior you want. You also didn't mention what kind of traffic you are getting on the servers. So, first things first...

1. You mention web sites. This implies traffic on port 80. Are you using SSL? Then you have traffic on port 443 as well. What about mail? What about users on the servers (I really, really hope not)?

So, in addition to the web sites, what other "stuff" is going on with the servers with respect to the network? Who needs access to the servers, and for what? (i.e. do you need FTP access, Telnet access, SSH access... ?)

2. Once you have itemized the things that need to get through the firewall, then you need to decide what kind of firewall behavior you want.

Do you want/need only port restrictions? For example, if you only use ports 80/443 and SSH (port 22) (no telnet, no FTP), then you can block access on all ports except those. Add email and you need more ports open.

Do you want stateful packet inspection? If you are just firewalling the above 3 ports and have no mail server, then you probably don't. But - if you have users on the servers (yikes!) or a mail server, then you have much bigger firewall 'issues', including white lists, black lists, stateful packet inspection, virus checkers, etc.

If all you want is port blocking on all but the key 3 ports (80/443/22) then a single server running OpenBSD (much, MUCH, MUCH MORE SECURE THAN ANY LINUX BOX, IMO) running PF will probably suffice. Put the web servers on their own 'non-routable' static IPs and have the OpenBSD box's PF route the traffic as required. Easy, cheap and simple.

If you need a "full bodied" firewall with statefull packet inspection, email and spam filtering, etc. then I recommend you invest in something larger from SonicWall.

Cheers,

-R