Serious network architecture that works for everyone.

I started writing this blog post as a way to setup a reverse proxy for mail inspection, but it turned out that a network architecture blog focused on security of the perimeter was more important. I’ve gone over in my head with all the companies that have told me, “Ohhh we don’t need this” or, “this is too much administrative overhead” or, “We don’t need this much complexity, we’re just manufacturing “widgets” , or something like that. And to those people, I say this: “I am so sick and tired of hearing excuses of why you think it’s okay to be lazy. Do it right, do it now, and save yourself the headaches of a breach.” We’ll talk about the costs associated with being penetrated some other time, but it’s EXPENSIVE!

If you’re planning to do this right, then you’ll want/need to have a multi-tier DMZ for your public facing services. We’re not talking about internal servers or your internal network at this point (though after thinking about it, the exact same concept can be carried out on the Internal network too). In this blog, I’m merely trying to tell you about your externally facing services. This blog will go over proper placement for Internet facing services. The VAST majority of companies out there don’t go to this level of sophistication, but its totally possible for any company to do this and if you really want to secure your network infrastructure, then you’ll at least attempt this.

Before we start, I’ll say this. I’m going to try my best to describe this as granular as possible. There are a TON of intricacies here that need to be thought out. I’ll provide a rudimentary Visio diagram to help on this, but you’ll need to map out your own network and break it down in a way you can understand.

The main point of network segmentation and building a secure network architecture is based on one of the most talked about security areas: The Principle of Least Privilege. Do your end users need access to databases? How about other network services? How about filesharing with eachother? How about shared resources for just once specific department (should engineering folks be able to communicate with financial systems)? Please think about the level of access people should have to services while going through this blog.

You’re first level DMZ should house only your front end web servers (or load balancers in front of those servers), DNS servers and your proxy servers, nothing more. These systems are extremely visible to the public and will be processing thousands of requests per day, so if anything happens to them, trust me people will notice. Remember, these are front end systems, so you don’t need much of anything out there. I’ll be going over how to set those services up on a future blog, but for now just remember, least privilege. Internet users dont need direct access to the webserver, they do need access to a reverse proxy server that inspects the traffic going to the web server(s).

From here, you can create your second tier that will house your web servers (if you have load balancers or proxy servers in front of them out in tier one), mail servers, SFTP servers, if you’re using LDAP or AD you could add a read-only domain controller (RO-DC) for authentication (but NO Internet access), and things like that. These systems should be using local firewalls as well as network layer firewalls to control access to them. Web servers dont need to talk to anything except the back-end SQL BD and the end user. Both of those firewalls should specify that the only systems they’re allowed to talk to is the server in tier 1 that proxies data to it, and if there is a server behind it in tier three.

Then there is an optional third tier where you would house your back-end database servers and any other servers deemed unnecessary for tier two. when I say optional, I dont mean just throw it away and put SQL over in tier 2. I mean, if you dont have a SQL back-end you can eliminate tier 3. Another RO-DC could be posted here for authentication services(again, NO Internet access!). If you’re running MS-SQL or Oracle SQL servers here, you can have services level authentication (or any other services for that matter) authenticating to that RO-DC. Same goes for tier two.

Lastly, I’ll mention a Management network that will have access to all three tiers. You’ll obviously have admins (even if it’s just yourself) that will need to run updates on those boxes or perform other administrative functions on those systems. Don’t forget to allow yourself access to that. But that doesn’t mean “IP ANY ANY” from the management network into those tiers either! Dont be LAZY, be smart and do it right.

In my Visio diagram, I used some old hardware, and multiple physical switches, but don’t forget, you can trunk VLANs and do some pretty cool configurations with Cisco gear, especially the new ASA’s. See it here: DIAGRAM LINK

So from tier 1, your DNS server should only be servicing requests from your 3 DMZs, and the Internet. I would say, you shouldn’t open this up to your internal clients, because you should already have internal DNS servers for Active Directory (or what ever LDAP service you’re using). At most, you should only be allowing 53/udp inbound to that DNS server from the Internet, and allow SSH inbound to that server from your management network. That’s IT! For your proxy server or load balancer, you should allow 80/tcp and 443/tcp inbound from the Internet and allow in whatever port your load balancer needs from the management network. So in this scenario, you should have 80 and 443/tcp and 53/udp open from the Internet to tier 1. Simple, see?

Tier two only has ports open FROM tier 1 into tier 2 (and management network into tier 2). The people out on the Internet will NEVER communicate directly with tier 2, there’s just no need.

And lastly, tier 3 will only accept communications from tier 2 and the management tier. No end user needs to communicate with the SQL DB’s directly, so why let them?

The only thing I’ve left out here is the RO-DCs. What do they communicate with? Well, the way I would set them up is have the 2 real Domain Controllers in the management network. This should be a totally different domain than your internal network. Name the domain whatever you want (fubar.dmz or whatever). Your RO-DCs are only acting as a proxy to the domain. Nothing is stored on them, so you’ve got really nothing to lose.

So that’s really about it. If you’ve got any questions, contact me via my LinkedIn profile. There’s a link to that right on my home page near the bottom of the left column.

 

Enjoy!! 🙂

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)