DMZ's.... what are they? How do they work? Why the hell are they called De-Militarised Zones when it's just geeky computer stuff? All these questions and more will be answered in this paper, which is concerned with the Kung-Foo of DMZ's. Normally here I tell everybody that if they do what I tell them to, then it's not my fault. Today's a little different. Use this information to build the most secure DMZ you can.... go ahead... I dare ya ;-)
What is a DMZ?
DMZ, or De-Militarised Zone is a kind of "Sacrificial Lamb" for hackers, to prevent internal systems compromisation in the event of a successful hack attack. This is why it's called a De-Militarised zone, as people have pretty much unrestrictive access to this area, in which no rules are applied. Of course, this isn't particularly true, as we still do apply some rules to what happens within this area, it's just that calling something a "De-Militarised Zone" makes it sound mucho cool, and then girls will want to have sex with computer geeks, which is a good thing. Honest, it doesn't matter what that Nun who taught you when you were 8 years old said. Or your mother for that matter...
So why do we use them?
Essentially, a DMZ works on the principal of moving all network services that need to go to the "outside world" onto another separate network. That way all the "open ports" to the outside world are on this new network. Therefore, if a hacker attacks and cracks a server from within the DMZ, he will only (at worst) have access to the hosts within the DMZ, not to the internal network.
For example, if I am running an FTP server for public (internet) access, and I have the server installed within the general users networks, then if a malicious hacker cracks the FTP server, thanks to NIS/NFS services and trusted systems on Unix hosts, or generic Windows NT/2000 security, the hacker can have access to pretty much the whole network. If he doesn't have access to the whole network he soon can with a little bit of packet capturing or any number of methods which I'm sure you've all read about.
However, if we have the FTP server on a completely different, unrelated network then once the malicious hacker hacks the network the absolute best he or she can do is have access to the hosts in the DMZ. Hopefully though, there are no inherent trusts setup between the DMZ machines, which means that the worst a hacker could do to you is trash your FTP server.....
Also, by cutting down on the pathways that can be taken out of the internal network, it makes it impossible (practically) to access the network with trojans etc.
Therefore, a DMZ should be been as more of a concept, rather then a "product" per se, as we can achieve this using various techniques and hardware etc. Essentially, what we are trying to do is give users (both internal and external) all of the network services that they require, whilst securing the network as much as practical by cutting down on the amount of services that are externally accessible and present on the internal network.
And really, that's it. That's all that there is to DMZ's. Of course, the problem is applying this theory to real live situations. So, I've put together an example to illustrate the points that I've made. If you're familiar with NAT & PAT and access lists, then feel free to skip the next section and go onto the example case study.
General Concepts: NAT,PAT and access lists
NAT stands for Network Address Translation, whilst PAT stands for Port Address Translation. These are pretty convoluted names for (relatively) simple terms. NAT allows you to redirect incoming packets from a real (i.e. Addressable from the internet) address to an internal address. For example, if we have a real address of 203.8.90.100, we can configure NAT to automatically direct incoming data to 192.168.100.1 (an internal network address).
Now, this is (obviously) not a particularly good situation, as all information is automatically pushed to the internal IP address, which means that we really have no control over the incoming data. To help combat these problems, PAT was created.
PAT, as the name suggests, allows us to direct data that comes on a particular port, or range of ports and protocols (TCP/UDP and others [such as GRE or ICMP]) and IP address to a particular port, or range of ports to an internal IP address. As you can imagine, this gives us a lot more control over exactly what's going on.
Access lists, on the other hand, allow us to control exactly what is going in or out of the network in question. They can deny or allow access based upon source IP address, destination IP address and protocol type. For example, we can deny all incoming ICMP to every IP address except for a particular one, whilst still allowing all internal addresses to send ICMP requests out.
Example Case Study
On this particular site, I was called out to "bring it into the 2000's", as it had not had a serious infrastructure appraisal since the company had formed, and it was made up of a conglomeration of systems that just grew as the company did. The network itself was a Microsoft Windows NT4.0 based network. They were running Proxy Server 2.0 for Internet access and Microsoft Exchange 5.5 for Internet and local mail. After attending onsite, I found the following security problems (I'm only listing the ones here that could be fixed directly by a DMZ).
i) All the IP addresses were "real" addresses, so they were accessible directly from the Internet ii) External DNS Servers were running on the internal network iii) The web server was running internally iv) There was an FTP server running internally v) The exchange server was directly accessible from the internet vi) There was no restrictions (firewalling) on incoming and outgoing requests
Stage 1 - New IP scope & removal of web services
The current network access was supplied by a RedHat Linux 4.0 box (ugh! wayyyy old) that had an ISDN card installed internally. Now, this box had ALL routing disabled and ran as an applications gateway. Fortunately, this is a rather secure scenario. However, an application gateway works by allowing software to monitor certain ports, then activating another program to allow the information to go to the internal network. What this means is that most common protocols (HTTP & FTP) are supported, but some of the less common (or newer, considering that the system has been running since about 1994) do not have applications associated with them, meaning that the company could not have things such as VPN access to their network, which they needed to link with their companies in Europe and America, thus pretty much negating the security aspect (hey, if you can't use it, it doesn't matter how secure it is). Also, since the IP addresses being used internally were valid internet addresses (Man, these guys had a whole class C network, can you believe the luck?), if anybody compromised that particular box and enabled routing it was all over since every machine could be addressed by the internet. Also, there were internal servers running Internet-accessible applications (SMTP on the Exchange box, and FTP on the same box, for example, as well as a web server), which, if compromised, could cause all sorts of problems as these servers were Domain Controllers in the network.
So, our first priority was to get rid of these internet addressable IP addresses so that in the event of a hack on the RedHat Linux box, the only way internal machines could be compromised is from a session on the Linux box itself.
So, I setup DNS on a Windows NT4.0 machine (2000 wasn't out just yet). Why Windows DNS?? I hear you cry. Well, quite simply because Windows NT4.0 DNS Services is relatively easy to configure, pretty secure for an internal DNS solution (although kinda easyish to spoof, it doesn't really matter as the machine would be on the internal network only), and it supported dynamic Registrations so I didn't have to get RSI typing in a whole lot of name records. I know that new versions of BIND support dynamic registration, but once the site upgraded to Windows 2000 they would need Windows 2000 DNS services for the active directory extensions, so Microsoft DNS was incorporated.
I then modified all of the IP addresses on the Servers & Print Servers, changed the application gateway settings on the Linux gateway, and set a new DHCP scope up complete with DNS server settings as part of the scope options. Viola, it's all done. Having said that, there were numerous problems with this after it was done though, because a number of users were accessing resources based on IP address as opposed to name, although these problems were pretty easy to resolve.
Now, whilst this was all happening, we removed the web pages from the internal network and moved it across to the ISP because web page updates were not particularly common, and by moving it to the ISP it means that the security of that component is no longer our problem, and the less we have to worry about it, the better.
Stage 2 - Acquisition of new Hardware
So, now we get to the start of the really fun stuff - buying equipment! I just love spending other peoples money.... Basically, we were going to be upgrading the site to an ADSL connection, Implementing a Firewall product and then Implementing the DMZ. Obviously, we couldn't use the internal machines as DMZ machines, as they already had jobs so I shopped around to see what was on the market. Whilst (within reason) it doesn't really matter what you pick to install into a DMZ my two basic (personal) rules are; 1) Don't install a Microsoft product, and, 2) Don't eat yellow snow, well actually my second rule is never to install Linux in a DMZ....
I don't really like to install Windows Equipment in a DMZ for a couple of reasons; 1) Although Windows NT/2000 is very difficult to hack per se, it is relatively easy to DOS or crash services, thus creating outages, which is a bad, bad thing..... We hate outages..... 2) Every black-hat hacker out there wants to hack Microsoft kit, so there are a lot of bugs floating around at any given time, and if your site administrator is not going to be really vigilant 100% of the time, then it's too much of a risk
Now, I really don't like to install Linux in a DMZ because to put it quite simply, it is an operating System written by hackers, for hackers. Every man and his dog has the source code available to them, and because of that there are so many hacks for Linux that are around in peoples personal hack compiles that it too is just not worth the risk.
Based upon these guidelines, I settled on some Sun Hardware. The SunBlade100, to be precise. This decision was based upon the fact that the SunBlade was available for US$995.00, and came with Solaris 8 pre-installed as well as 128MB memory, 15GB HDD and a Network Interface. What more would you want for a thousand bucks? I picked up 4 of these machines, one for DNS and proxy, one for ftp, one for sendmail, and one spare in the event of a systems level failure or hack that could be built quickly and integrated into the network. The only backup that I was performing was a basic config file copy made any time I changed a configuration option (which shouldn't be too often). Using the config files and some reasonable documentation I could rebuild any one of these machines within two hours quite comfortably.
For the ADSL connection and firewall I settled on Cisco Kit, basically an 827 series router and a Cisco PIX 515. I also arranged memory upgrades for the both the Router and PIX, and a third Ethernet interface for the PIX firewall (and make sure you get the IP feature set IOS).
For the Data-Link Layer, I arranged for a Cisco 2912XL Switch. Whilst there are many Switching devices available on the market, I decided on a Cisco because I like Cisco kit, and it means that all of my WAN equipment is Cisco based, which makes it considerably easier to gain support, as you don't have cross-vendor problems.
After that it was just a case of waiting around for the kit to come in....
Stage 3 - Implementation of the ADSL Line and PIX firewall
Once the equipment had arrived onsite and the Comms dudes had installed the ADSL connection (which felt like it took about 9 months), I arranged for an account with an ISP and configured my router up for access (using all the security that I could, encrypted passwords etc.). Once I cold access the internet directly from the router (using telnet etc.), I then connected the Firewall and set it up on it's own subnet with the Ethernet Interface of the ADSL router. At this stage, my IP addresses look like this;
ADSL - 209.15.20.34 Ethernet0 on ADSL - 192.1.10.5/30 (255.255.255.252) Ethernet0 on PIX firewall - 192.1.10.6/30 (255.255.255.252)
Now, I create a NAT translation to forward all incoming data to 209.15.20.34 through to 192.168.10.6. Please note that I DO NOT apply any access lists at this point, simply because the job of the access lists is done by the PIX firewall. Leave the router to route data, and let the Firewall do it's thing. If you try to load up a router with too much then you risk having it run out of Memory or CPU cycles, and everything will come a-crashing down. The most I'd suggest you should try, is applying some blanket access-lists (eg for all ICMP data), but I generally like to leave all that stuff up to the Firewall if I can.
Once we've got that section ready to go, we can start to setup the machines in the DMZ.
Stage 4 - Installation and configuration of the DMZ hosts
Now that we've got the external section of our network sorted out, we can now look after our semi-trusted section (or DMZ). Please note that whilst this is going on, the original ISDN connection is completely separate and working away quite happily, so the users are unaffected. Also, I normally leave the ADSL (or whatever) connection offline at this stage unless when I am specifically testing something. That way I can be (relatively) sure that the systems have not been compromised whilst I've been setting them up.
The first thing to do is decide on the Subnet that we will be using on the DMZ. 192.100.100.0/24 was the IP range that I decided to. Also, I tried to make sure that the IP address ranges are similar, but not so similar that I can't remember what range I'm using for what job. It means I have to think less, I don't really have spare cycles at the best of times, so it all helps ;-)
So Ethernet1 on the PIX is configured with the IP address 192.100.100.6/24, to keep it in line with the IP address of the Ethernet Interface. I also ensure that I configure my Cisco switch with an IP address that is NOT PRESENT on the network. May main reason for this is to stop a hacker coming in, and hacking the switch to gain access and initiate packet sniffs. The only way to get to it is to reconfigure one of the hosts with a new IP address on a scope that they don't know, which will result on that host effectively going offline from the internet, and therefore the hackers access (yes RARP can sometimes get around this, or a secondary IP address on the hosts Ethernet Card - check with your vendor), or a Console cable needs to be connected to the switch, which cannot happen without local access (which hopefully the hacker doesn't have).
The stateful inspection and antispoofing rules on the PIX firewall are configured at this stage. Stateful inspection isn't really covered in this document, as not all firewall will support it, and each firewall implements it differently, do some searches on google, or start here. http://www.spirit.com/CSI/Papers/apgw+spf.html
Then all of the machines are brought online and configured with IP addresses (choose any that you want), install and configure their respective network services (ftp etc.) to the point that you can deploy your services. These machines should then be setup according to the various security specifications that vendors/security consultants have developed. To name a couple of simple ones, make sure that all of your services are running on their own account, not the root users (or whatever) account. Rename your root account if you can (depends on OS), Dont allow any service that you do not need (i.e. No telnet access, SSH only and only then if you really need it). There are a few web pages at the bottom of this paper to get you started on some of the more popular operating environments, and I have deliberately left this area a little bit shady because it will change depending on your precise operating environment. Every site has different operating constraints, and it is up to the local administrator to ensure his site is as secure as possible. No two sites are ever setup the same way.
At this point, I also configured the PIX firewall to accept incoming VPN requests (using IPSEC tunnels) to allow remote users to authenticate to the system, and restricted the access to this VPN server using access-lists which would deny any incoming connection requests for VPN access unless it originated from either one of the remote offices or from my companies office (easy to do as they were all fixed-IP addresses). By doing this I cold control SSH access to the DMZ machines to come only from my VPN IP address. This allowed me to remotely connect to the machines via SSH, but a port scan from the internet would never show SSH as open.
Now, whilst all of this is going on, we need to redirect our domain name services from the ADSL connection. Port Address Translations are configured on the PIX firewall to forward incoming UDP/TCP port 53 requests (we can just allow incoming port 53 requests if we want to be even more secure, for details on this, please refer to my paper on DNS Spoofing - which is somewhere on this site). Then, we apply a packet filter to the PIX firewall to allow incoming TCP port 53 connections from our secondary nameservers only (which should belong to our ISP), incoming UDP port 53 requests from anywhere, and outgoing UDP port 53 requests ONLY from our DNS server. Essentially, this task needs to be completed for all of the services on all of the servers and obviously the requirements are different for different services and even different versions of services, so you will need to research each of your services specifically. Also, we need to change our nameserver delegation so that the primary nameserver is now configured to our ADSL external address, not to our ISDN external address (otherwise international name requests will come to a sticky end).
By the time you have finished all of this you should be able to switch on your ADSL connection with relative security as you have applied all of the necessary access-lists and PAT's. The basic rule is this - if you do not need access to a particular service then do not allow it, it is this simple. A hacker can only attack the services that a host is running, therefore your primary objectives are to Minimise the number of services that are available to the internet, and to make those services as secure as possible. Essentially, all services should now be accessible from the internet (although only by IP address, as we have not yet modified our external DNS configuration, so everything is still going via the ISDN line). Take this time to test each service, complete some port scans and ensure that you have limited access as much as possible to the specific devices.
As our final stage, we need to configure the final ethernet interface on the PIX firewall onto our internal network. Ensure at this stage that all traffic is blocked via Access-lists from the internal network, so that nobody and nothing can get outside access. These access-list rules will be modified during the next stage
Stage 5 - Configure chaining/pass through (a proxy, by any other name)
Now, in this design DMZ, we will be running true proxying for as many of our services as possible. Essentially, this means that (for example) the exchange server will not send or receive mail directly. Instead, it will proxy its mail via the sendmail server. This means that no person on the internet can directly access any internal services. It also allows us to run multiple instances of different software to increase our protection. For example, we could run a sendmail virus scanner on the DMZ mail server and Norton Anti-Virus for Exchange on the Exchange server, by doing this we significantly increase our chances of virus detection (by scanning with different engines, definitions and heuristics algorithms). Essentially various services need to be configured to forward all of their incoming data to one of the internal machines. In our case above this will apply only for the SMTP service. The sendmail server must be configured to receive mail for all the domains that the site services, and to forward all of this mail to the internal mail server (i.e.. Exchange). Then we configure the PIX firewall to allow the Exchange Server only to send TCP port 25 data only to the sendmail server. We then configure the PIX firewall to allow the sendmail box to send SMTP port 25 to any internet address and ONLY to the Exchange Server.
Depending on the services that you run, you will need to create access-lists of varying complexity. For example, outgoing web requests need to be accepted by the Proxy box in the DMZ from the Internal Proxy only, and the DMZ Proxy can initiate any outbound connection. The DMZ proxy does not need to accept requests from any other source (internal or external), so hackers should not be able to locate it anyway. Nor does it need an entry in your external DNS configuration, so hackers shouldn't be able to locate the proxy server via Zone Transfers etc.
The great trick with this stage, once again, is to ensure that you do not have any access allowed that is not needed. For example, outgoing web requests should be allowed from the Internal Proxy Box only, and then only to the DMZ proxy. Ditto SMTP connections. DNS requests should only come from the DNS servers on the internal network, and should only be allowed to the DMZ named server. Anything that you do not need you should automatically block. Think of it this way.... when we build a firewall, block everything, then only allow the things that you really need through, and try to restrict that as much as possible. "But Squire," I hear you ask in a whiney voice, "It's soooo much easier just restricting incoming and leaving outgoing to fend for itself, why do we have to restrict outgoing." Well, there are actually a couple of reasons for this. Firstly, it makes logging things at lot easier.... I know that it will make your gathering of p0rn a lot more difficult, but it really is a good idea to keep good logs. The main reason though, are the infamous trojans that all the 3j337 h4x0rs are using at the moment. Some trojans are actually configured to initiate a call from the infected machine to a particular host. That way if the administrator has been a little slack and is allowing outgoing connections a malicious hacker can still get in, no matter how secure you are for incoming connection attempts. I know that most firewalls now use stateful inspection, and quite often they will not allow this form of connection, but they are not infallible, and you can reduce our risk further. To help this, allow no client to initiate a connection by themselves. If they want to IRC to the real world , use an IRC server. Do not allow ICQ or MSN internally (I know some people will have a problem with this, but it is a HUGE risk). Essentially, you have to try and ensure that outbound connections from your internal network will only be made from servers, so you can be as sure as you can that all of these connections are legitimate. Note for the newbies: Don't ever open mail, run freeware programs etc. etc. on these "border" servers.... the last thing you want is your internal Proxy Server with a Trojan on it. I know that the risk of problems from this is very small, but if you're spending the time and money to make yourself secure you can at least ensure that you are secure.
Also, as much as possible ensure that you test the filters and translations. Attempt to access the outside world internally with no proxy. Reconfigure your proxy to point via your new proxy for a couple of hours and ensure that it's gong to work. Remember: Block everything, and then let stuff through in the most secure way whilst still providing the service required to the users.
Stage 6 - Alarmbells and tripwires - or how to piss of 3j337 h4
Really, there aren't too many methods for tripping up hackers.... It's still largely unknown territory and theres just not too much out there. In this particular system I relied on three main methods;
1. SysLog logging 2. Tripwire intrusion detection process 3. Cron jobs
Essentially, on the PIX firewall I logged all Authorisation and Connection failures to a SysLog server on the internal network. This is pretty important to do, as in the event of a hack you can start to see the methodology that the hacker used to get to your system. This is really all that you can do on most firewalls to protect yourself, which means that you have to really concentrate on the next couple of paragraphs....
Tripwire is an excellent daemon that runs on a system (there are versions available for NT as well) and simply monitors a list of files that you give it for changes/modifications, and that's it really. If a hacker gets into your system, pretty much everything that they do will result in the modification of a file. This means that you can monitor these files for changes, and based upon that make a decision as to whether the system has been compromised, and log these changes to a syslog server, or even run scripts based upon these changes. For example, when a particular user logs in (eg. Root), or a particular file changed (eg password files etc.) I would setup tripwire to log this information to a syslog file and run a script that sends a mail message to the systems administrator, and follows this with a SMS message to the administrators mobile phone. Essentially, this gives the site administrator instant knowledge of major system changes..... cool, eh?
Now, tripwire sounds like a brilliant product to use..... unfortunately, it has one major problem. The tripwire process runs on a system at set intervals and most decent hackers (i.e. not script kiddies) know about this particular problem with tripwire, and if they gain root access they will immediately shut the process down. This, naturally, can be a little bit of a problem. Therefore, I implement my own little script to make sure that things are going OK, being my own script a hacker won't really know about it, no will they know how to check it. Essentially, all that I do is create a cron job that starts up minutley and searches the running process list to see if the tripwire process is running. If it is not running, then it simply emails and SMS's the administrator and shuts the machine down. Problem solved..... This can appear to be a drastic measure, but if you've got secondary ISP side mail exchanger's, and secondary DNS servers, then you can generally afford to be on the safe side and shut a machine down for a short period of time.
The future of intrusion detection
There are constantly new pieces of software becoming available, but I think that the future belongs to syslog analyzers. Essentially, what I mean is a syslog utility that can take syslog information, process it, and if a certain set of rules are met, activate a script. For example, most hackers start off by running a port scan. You can configure most firewalls to log all communication errors to a syslog server, if you had an analyser you could generate a ruleset that would run a script if four connection rejections occurred on different ports/protocols in a ten second period. This script would then automatically add a deny statement into the firewalls access list which would automatically reject all connections (even legitimate ones) from the IP address that the port scan originated from. This deny list could be in place for only 30 minutes, but it would seriously affect the value of the "Information Gathering" section of a hack. With the ability to perform this function, you would be able to control your systems security extremely finely indeed.
Stage 7 - Switch it on and watch the fun
Well.... you've got all of your rulesets defined, you're logging all accesses, it's pretty much time to start using the new system. All this system needs is a change in the name records, reconfigure some internal services (mail etc.) and we're ready to go. Simply update your zone files and turn off your ISDN connection....
Final Words
Well, hopefully you now understand the concepts behind a DMZ, and using my example as a baseline have the ability to start planning your own. I have deliberately left out some of the specifics (i.e. Firewall scripts etc.) for four reasons: 1. Everybody has different preferred firewalling products, and whilst all of them (well, the god ones) should be able to do everything that I have described in this article, although each on does it in a different way, with a different command set. 2. Even if I supplied all of the commands on a particular firewall, these commands change from software update to software update, so it really wouldnt be valid. 3. Hopefully it will encourage people to actually read up on the features and use of their firewall, so they actually start to understand how to set it up. 4. if you don't have enough networking knowledge to follow this, then you need to really read up on Networking as a general concept, and by the time you understand each step in this document you'll easily be able to replicate this work.
If anybody has heard of a product that I mention in 5.7.1, please, let me know. I'd love to try it out.
Sorry for taking so long to get out this article..... but I've been kinda busy lately.
If anybody wants to post this work on their site, then please feel free, as long as you leave the document completely intact.
Also as usual, flames can be sent to /dev/null.
Oh yeah. after one email that I got last time I wrote an article although my spelling can be pretty bad at the best of times, I actually write in English, not Amerienglish, so its not quite as bad as you think (thats right, its colour, not color ;-)
Greetz
rainshesaid - What can I say? I'm so impressed at meeting my first Irish/French person that I had to give you a shout Saruman - Where the hell's your article, eh??? Drew - Who's your Daddy? X - Just how many sites are you running??? Ahhhhh!!! Will it never end??? ;-) Marek - There.... it's done.... OK??? You happy now??? ;-p IceBerg_Slim - bwahahahahaha, HC quivers before our combined might Scooby_Foo - WTF happened to cowscalper e-zine??? I need it, my life is empty without it Webmaster - Our Man in Egypt! Thexy - 'Who are you?' said the Caterpillar. Everybody @ Fromadia (better put that in since I'm a mod there ;-) Anybody that reads the whole article down to here (actually, you probably deserve more than a greet for that ;-)
Be first to comment this article
