As applications continue to improve and add more
functionality that requires Internet connectivity, and as the business user’s
need continues to grow for on-demand enterprise anytime and anywhere, security
concerns also grow and dominate corporate concerns. This concern can clearly be
seen by the many new certifications that companies like Microsoft are
introducing to promote security and security awareness. Everything today is about
security, and companies are not touching software before examining the ins and
outs of how it will be deployed and how it can be secured.
This security frenzy was prompted by the many viruses that
have surfaced and have compromised corporate data and information. It is also prompted
by 14-year-old hackers from their garage attacking corporations and gaining
access to sensitive data.
One of the immediate measures that companies take in order
to improve security is to create a DMZ or “demilitarized zone.” A DMZ
is a perimeter network that isolates the internal network and controls what
kind of traffic, if any, is allowed to pass on to the internal network. By
creating a DMZ, you limit the amount of damage an intruder can do to just the
DMZ. Servers that typically go into the DMZ are servers that need to be exposed
to the Internet, such as Web servers and e-mail servers.
The problem
Suppose you have created a DMZ and populated it with servers
that are exposed to the Internet, and you have limited access from the DMZ to
the internal network to very specific and very closely monitored ports. One of
the immediate problems you are faced with is how to authenticate users to these
servers. Even better, how do you log in to these servers yourself? Sure, you
can log in locally, but most of the applications you have deployed require some
kind of directory for authentication purposes.
An example would be a project that your developers and a
consulting company are working on; these developers need user accounts in order
to log in to your system. Do you create local accounts for everyone? That would
be an administrative nightmare and a security concern.
The solution
Different scenarios exist for how to remedy the problem of
offering directory authentication for servers and users in the DMZ. For the
purposes of this article, we will be discussing Active Directory.
One scenario calls for placing a domain controller in the
DMZ to service the servers and users in the perimeter network. This is a viable
solution, and can be secured to some extent by denying any direct communication
with it from the Internet and by allowing it to communicate only with specific
domain controllers in the secured network using IPSec. This, however, still
poses a security risk because this domain controller has to be a Global Catalog
Server. This means the server must contain every single object in Active
Directory and, if the DMZ is compromised, an attacker can then compromise
this server and gain access to Active Directory. (This is assuming that you’re
adding a domain controller in the same forest as your secured network.)
So how do you take a more secure approach to this? Since in Active Directory the forest is now the security boundary,
the only way to have a fully secure implementation is to create a separate
forest for the DMZ and then create a trust between the internal network
forest and the DMZ forest. This trust would allow specific domain
controllers in the secured network to communicate with only specific domain
controllers in the DMZ. You would use IPSec to encrypt and secure the
communication between the domain controllers, or you could set firewall rules
for that as well.
Using this method you can allow your internal users to
access resources in the DMZ, and you can create user accounts for consultants
or administrators that can only use resources in the DMZ. This would negate the
need to replicate your company’s Active Directory to a domain controller in the
DMZ and, if the DMZ is compromised, you’re at risk only
with the
Let’s do it!
Before we start, let’s outline the steps that need to be
completed before we can successfully implement this exercise. There are five
steps that need to be completed:
- Open
certain ports on the firewall. - Create
the filter list. - Create
the filter action. - Create
the IPSec policy. - Assign
and activate the policy.
The first step is to open some ports on the firewall to
allow for the proper communication and also to allow IPSec to properly
function. Depending on your environment and what you are securing, you may need
to open application-specific ports or ports that are specific to your
architecture. At a minimum, the following ports should be open:
- Kerberos—TCP
88, UDP 88 - DNS—TCP
53, UDP 53 - LDAP—TCP 389, UDP 389
- LDAP over SSL—TCP 636
- SMB
over IP—TCP 445, UDP 445
For the purposes of this exercise, we’ll be using the
following machine names and IP addresses:
- DC-internal—172.16.1.2
- DC-external—172.16.10.1
These steps should be completed on both domain controllers. We
will display the steps that need to be configured on the domain controller that
is in the internal network. You would have to reverse some settings when configuring
the domain controller that is in the DMZ.
The filter list
Before you can create an IPSec policy, you’ll have to create
a filter list and a filter action. A filter list regulates and defines the
security between the participating servers. It is responsible for identifying
the source computer, the destination computer, and the type of IP traffic that
should be encrypted and secured. To create a filter list:
1. Click
Start | Programs | Administrative Tools | Domain Controller Security Policy.
2. In
the left control pane expand Windows Settings, select Security Settings, and
click IP Security Policies (see Figure A).
|
Figure A |
 |
3. On
the Action menu, choose Manage IP Filter Lists And
Filter Actions.
4. Click
Add and type a name for the filter list. For the purposes of this exercise, we’ll
select DMZ and click Add again, which will launch the IP Filter Wizard.
5. Click
Next to bypass the welcome screen.
6. Under
Source address, select A Specific IP Address from the drop-down menu. Type the source
IP address—in our case it is 172.16.1.2—and click Next
(see Figure B).
|
Figure B |
 |
7. Now,
under Destination address, select A Specific IP Address from the drop-down
menu. Type the destination IP address of 172.16.10.1 and click Next.
8. Select
Any under Select A Protocol Type. Click Next, click
Finish, and then click Close.
When creating the IPSec policy on the DMZ domain controller,
the source address here becomes the DMZ domain controller’s IP address and the
destination IP address becomes the internal network domain controller’s IP address.
The filter action
A filter action regulates and defines the security
requirements of how information is treated from different sources. A filter action
can permit, block, or negotiate security.
Permit means that TCP/IP traffic is passed on without
interference and is usually used with computers that are not IPSec capable. Block
means that IPSec will block any communication with computers that were not
explicitly defined in the filter list. The Negotiate Security setting allows
you to customize what IPSec will do in different circumstances—for example,
when communication is attempted from a non-IPSec-capable computer.
To set up a filter action:
1. From
the Action menu choose Manage IP Filter Lists And Filter
Actions, and then click the Manage Filter Actions tab.
2. Click
Add, and then click Next.
3. On
the Filter Action Name page type a name for the filter action—in our case it
will be DMZ. Click Next.
4. When
the Filter Action General Options window comes up, select Negotiate Security
and click Next (see Figure C).
|
Figure C |
 |
5. In
the next window, select Do Not Communicate With Computers
That Do Not Support IPSec and click Next.
6. On
the IP Traffic Security page, select High and click Next (see Figure D).
|
Figure D |
 |
7. Ensure
the Edit Properties checkbox is selected and click Finish.
8. On
the New Filter Action Properties windows, deselect Accept Unsecured Communication,
But Always Respond Using IPSec, and click OK.
9. Click
Close.
Create the IPSec policy
Now that we have fulfilled all the requirements, we are
ready to create the IPSec policy as follows:
1. From
the Action menu choose Create IP Security Policy.
2. Click
Next to bypass the welcome screen.
3. In
the IP Security Policy Name window, type DMZ.
Click Next to continue.
4. Uncheck
Activate The Default Response Rule and click Next.
5. Make
sure the checkbox for Edit Properties is selected, then
click Finish.
6. Click
Add, and then click Next.
7. On
the Tunnel Endpoint window, select This Rule Does Not Specify A Tunnel and click Next.
8. Under
Select The Network Type, choose Local Area Network
(LAN) and click Next.
9. In
the Set The Initial Authentication Method For This
Security Rule window, select Windows 2000 Default (Kerberos V5 Protocol) and click
Next (see Figure E).
|
Figure E |
 |
10. Select the
filter list created earlier, in our case DMZ, and click Next.
11. Select the
filter action created earlier, in our case DMZ, and click Next.
12. Uncheck
Edit Properties, and click Finish.
13. Click OK,
and then click Close.
Activating the policy
The final step is to assign your IPSec policy and to
activate it so that it can start encrypting and securing communications between
the designated computers. To assign and activate it:
1. In
the right control pane, right-click the IP Security Policy you have created (in
our case, DMZ) and then select Assign.
2. Right-click
IP Security Policies in the left control pane, and select Refresh.
Safe and secure
By implementing this exercise and by creating a totally
separate forest for your DMZ network, you can rest assured that, in the
unlikely situation that your network should be hacked, you have sufficient
layers of security to shield your internal network where your most valuable
information resides. This also makes it very time-consuming for a hacker to sit
there and keep pounding at your network in order to crack it. Remember that they
are on the clock, too, and the longer it takes them to get in, the more likely
they are to be caught.
In my opinion, aside from shutting down your servers, it is
extremely hard to stop a seasoned and gifted hacker from getting access to your
network, but you can make their attempted hack as difficult and as complicated
as possible—to the point where it becomes not worth it for them anymore.
Finally, by making it more complex and harder to get in, you separate the
seasoned hackers from the wanna-be hackers, which also
lowers your chances of getting hacked.
