Setting Up a DHCP Server for your Organization

One of the most basic processes on a network is that of assigning IP addresses to network clients. Although there are many different types of DHCP servers that can do the job, you can configure Windows Server 2003 to act as a DHCP server. In this article, I will show you how.

Years ago, I used to be a network administrator for an organization that had some rather odd security policies in place. One of the existing policies when I got there was that all computers had to be assigned a static IP address. DHCP servers were forbidden for security reasons. The result was a maintenance nightmare. Obviously, some servers have a legitimate need for static IP addresses, but usually it is perfectly acceptable for workstations to use dynamic IP addresses. Generally speaking, using static IP addresses on workstations is only truly feasible on small networks. Unfortunately, the network that I spoke of a moment ago was anything but small. It had 25,000 workstations.

This network was a logistical nightmare for several reasons. For starters, any time that a PC’s hard disk crashed, someone had to figure out which IP address had been assigned to that PC before Windows could be reloaded. You can imagine what it was like to try to figure out which of the 25,000 IP addresses was supposed to be assigned to the machine that was being rebuilt. There was no central list of addresses. Each building had their own address block to manage, and consequently, there was no standard for managing addresses. Quite frequently, someone would assign a PC an address that had already been used, resulting in an IP address conflict that forced someone else’s PC off of the network.

Hopefully, this story shows you why it is a good idea to assign dynamic IP addresses to the workstations on your network. Fortunately, the process of configuring a Windows 2003 Server to act as a DHCP server is simple. Furthermore, in most cases, the DHCP services place such a small burden on the server that the DHCP services can often be run on one of your existing servers rather than you having to invest in a dedicated machine. In this article, I will show you how to install the DHCP services on a Windows 2003 Server. I will also take the opportunity to discuss some common DHCP configuration issues.

Avoiding DHCP Conflicts

As you will see later on, the Active Directory is designed to prevent rogue DHCP servers from being placed onto your network. The idea is that you don’t want to have an unauthorized DHCP server assigning an invalid block of IP addresses to the computers on your network. However, this protective mechanism is only effective if the rogue DHCP server is running a Windows operating system and is attempting to interact with the Active Directory.

Microsoft didn’t invent DHCP and DHCP servers are certainly not unique to Windows networks. In fact, it’s very possible that you might have a DHCP server on your network right now and not even know it.

When most people think of a DHCP server, they tend to think of a Windows, UNIX, Linux, or perhaps a NetWare or Macintosh server that is configured to assign IP addresses to clients. While these are certainly types of DHCP servers, you would probably notice it if someone brought one of these types of servers online on your network (at least I hope you would notice it). The most common type of rogue DHCP server is a router with a built in DHCP service. For example, wireless access points are available at any electronics store for a ridiculously low price. The vast majority of wireless access points have a built in DHCP server that is enabled by default. Typically, these devices are set up to assign an address in the 192.168.x.x range to any client (wireless or wired) that requests it. The DHCP services aren’t just limited to wireless access points though. You’ve probably seen low budget routers that are designed to connect a small network to a broadband Internet connection. These devices almost always have a built in firewall and a built in DHCP server.

A DHCP server can also be software based. For example, most of the Windows operating systems that have been released in the last decade offer a service called Internet Connection Sharing (ICS). The idea behind ICS is that one computer’s internet connection can be shared with other computers on the network. The ICS service implements its own mini DHCP service. Just for the record, ICS and the DHCP services that are a part of the Windows Server have trouble co-existing on a network.

The biggest trick to making the DHCP services work well on your network is to make sure that the IP address range that the server is handing out does not overlap with the addresses being handed out by another DHCP server on your network. If there are other DHCP servers present, you must make sure that they are configured to assign appropriate addresses to your workstations. It’s perfectly OK to use multiple DHCP servers on your network. In fact, doing so provides you with a degree of fault tolerance. You must however make sure that each DHCP server is assigned a block of IP addresses that does not overlap with an address block managed by another DHCP server. These blocks of addresses are known as scopes.

If you aren’t aware of any DHCP servers on your network, then I recommend performing a quick test prior to deploying a Windows based DHCP server just to verify the absence of DHCP servers on your network. The easiest way to confirm that no DHCP servers are presently active is to configure a workstation’s TCP/IP settings so that the workstation acquires an IP address automatically. After doing so, simply reboot the computer and see if it is assigned an IP address. You can determine whether or not an IP address has been assigned by opening a Command Prompt window and entering the IPCONFIG /ALL command.

Installing a DHCP Server

Now that I have talked about how you can avoid DHCP conflicts, let’s talk about how to install and configure a Windows Server 2003 based DHCP server. Before I get started, I should mention that the server itself must be configured to use a static IP address.

Begin the process by selecting the Add / Remove Programs option in the Control Panel. When the Add / Remove Programs dialog box opens, click the Add / Remove Windows Components button. After a brief delay, Windows will open the Windows Components Wizard. Scroll through the list of available components until you find the Networking Services option. Select Networking Services and then click the Details button. You will now see a list of the various Windows network services. Select the check box next to Dynamic Host Configuration Protocol and click OK, followed by Next. Windows will now begin to copy the necessary files. During this operation, you may be prompted to insert your Windows Server installation CD. When the file copy operation completes, click Finish to close the wizard.

Configuring a DHCP Server


The process of configuring the DHCP services is almost as simple as the installation was. Before you begin the configuration process though, you will need to come up with at least one scope. Remember that a scope is a range of IP addresses that the DHCP server can lease to clients.

Begin by opening the DHCP console. You can access the DHCP console by selecting the DHCP command from the server’s Administrative Tools menu. When the console opens, the first thing that you will want to do is to create a new scope. To do so, right click on your server and select the New Scope command from the resulting shortcut menu. This will cause Windows to launch the New Scope wizard. Click Next to bypass the wizard’s Welcome screen and you will be prompted to enter a name and a description for the scope. After doing so, click Next and you will see a screen prompting you to enter the beginning and ending addresses of the scope range. After doing so, you must also enter the subnet mask to be used by the addresses (or the number of bits to use for a subnet) before clicking next.

The next screen gives you a chance to enter any necessary exclusions. Exclusions are addresses within the scope that are already in use. Entering an exclusion address prevents the DHCP server from leasing that address. Enter any exclusions that you might have and click Next. You will now be prompted to enter a lease duration. The lease duration is the length of time that a workstation can use an IP address before having to either give the address up or renew it. The default lease period is eight days, which works fine in most cases.

Click Next and you will see a screen asking if you want to configure extra DHCP options. Select the Yes option and click Next. You are now given the opportunity to enter the address for a default gateway. Click Next and you are presented with a screen that allows you to enter the IP address of one or more DNS servers. Click next one more time and you will be allowed to enter the addresses of any WINS servers that may exist on your network (newer networks do not usually use WINS servers). Click Next once more and you will be asked whether or not you wish to activate the scope. Select the yes option and click Next followed by Finish.

Although the newly created scope has been activated it won’t be used just yet because the DHCP server has not been authorized to issue addresses for your network. To solve this situation, right click on the server’s listing within the DHCP console and select the Authorize command from the shortcut menu. Assuming that you are logged in as a domain administrator, the server will be authorized to start servicing requests.
Conclusion

In this article, I explained that setting up a DHCP server provides you with an easy way of assigning IP addresses to workstations on your network. I then went on to show you how to install and configure a DHCP Server and how to avoid overlapping scopes.

Read More..

Configuring Windows Server 2003 to act as a NAT router

More years ago than I care to think about, IP addresses were handed out to companies on an indiscriminant basis. As the popularity of the Internet increased, IP addresses soon grew to be a scarce commodity. Internet service providers began to strictly limit the number of IP addresses that they would lease to companies. This presented an interesting challenge. A PC has to have an IP address in order to communicate with the Internet, but there weren’t enough IP addresses left for every PC to be given one. The solution to this problem was a technology called Network Address Translation (NAT). Today, NAT is alive and well, and more popular than ever. In this article, I will explain what NAT is and how you can configure Windows Server 2003 to act as a NAT router.

What is NAT?

So what is NAT? Network Address Translation, or NAT, is a technology that uses a router to share an Internet connection among the PCs on your private network, even though those PCs do not have a valid public IP address. There are both hardware and software NAT routers. In this particular situation, we will be configuring a Windows Server 2003 machine to act as a software based NAT router.

As you probably know, a router’s primary purpose is to regulate traffic flow between two networks, and a NAT router is no exception. The server that you will use as a NAT router must have two network interface cards (NICs) installed. One of these NICs will connect to the Internet and the other will connect to the private network. PCs on the private network will then send HTTP requests to the NAT server via the server’s private network connection. The server will then retransmit the request over the Internet on behalf of the client. When the requested Web site responds, the response is sent to the NAT server, which in turn forwards it to the client who made the original request. The client never communicates across the Internet directly.

IP Addressing Considerations

As I explained in the section above, a NAT router acts as a gateway between your private network and the Internet. The server that is acting as the NAT router must have two NICs. One of the NICs is connected to the Internet. This NIC must be assigned the IP address that was given to you by your Internet Service Provider.

The other NIC connects to your private network. As I mentioned, NAT does not expect you to have valid IP addresses on your private network. Instead, you are basically free to pick an address range at random. There is the off chance that the range that you pick might already be in use by a popular Web site, but I have only seen someone pick an address range that caused problems once. If you want to use an address range that is guaranteed not to interfere with anything on the Internet, you can use the 192.168.x.x address range.

After you pick an address range, I recommend setting up a DHCP server so that it will assign addresses from your chosen address range (the DHCP term for an address range is a scope) to the workstations on your network. You must however statically assign an address to the NIC on the NAT server that connects to your private network. For example, if you chose to use the address range 192.168.1.0 to 192.168.1.99, then you might consider assigning the address 192.168.1.0 to the NAT server. You could then use the 192.168.1.1 to 192.168.1.99 address block as your DHCP scope.

While you are configuring your DHCP server, there are a couple of other considerations that you need to make. As you may know, DHCP allows you to optionally assign a default gateway and a DNS server to workstations along with an IP address. When doing so, you must set the default gateway address to match the private network address that you assigned to your NAT server.

You have a few different options when choosing which DNS server address the DHCP server should assign to the workstations on your network. If you don’t have your own DNS server, then the best thing that you can do is to just use the IP address of your Internet service provider’s DNS server. If your network is running Active Directory though, then you already have a DNS server and you should use its address. It doesn’t matter if your DNS server is authoritative for your domain or not. Simply point the workstations to it. You can then set up a forwarder on the DNS Server so that any unresolved queries get forwarded to your ISP’s DNS server.

The advantage to pointing clients to your own DNS server rather than to your ISP’s DNS server is that doing so will provide your users with better performance. Your DNS server is local, so queries reach the server more quickly than they would reach a remote server. Furthermore, your DNS server has a built in cache so that popular Web sites do not have to be resolved each time a user visits them.

Setting Up NAT

Begin by selecting the Routing and Remote Access command from Windows’ Administrative Tools menu. When you do, Windows will display the Routing and Remote Access console. Locate your server (just below the Server Status). There should be a big red dot to the left of the server, indicating that the server is currently inactive. Now, right click on the server and select the Configure and Enable Routing and Remote Access command from the resulting shortcut menu. When you do, Windows will launch the Routing and Remote Access Server Setup Wizard.

Click Next to bypass the wizard’s Welcome screen. You will now see a screen , this screen allows you to select various configurations for Routing and Remote Access (RRAS). RRAS can be configured to do just about anything that you want, but Microsoft has included several templates to make the configuration process easier for common deployment types. Select the Network Address Translation (NAT) option and click Next. 

The next screen that you will see is a rather important one to pay attention to. The screen gives you the choice of selecting a network interface that is connected to the external network (usually the Internet) or to select a demand dial interface. In case you are wondering, demand dial is a feature that allows Windows to establish a dial-up connection when ever external connectivity is needed. For the purpose of this article, I am assuming that you have a broadband connection to the Internet. Additionally, I am assuming that the NIC that the broadband connection comes in through has a static IP address assigned to it. You will have to select that network interface.

Before you click Next, you should notice that there is a check box that allows you to enable a firewall for the connection. I recommend always selecting this option. The firewall will keep unwanted traffic out of your network. If you need to grant external users access to some service on your network, you have the option of configuring port forwarding to pass packets through the firewall to the desired network resource.

After you enable the RRAS firewall, click Next and you will see a screen asking you to select the network that will have shared Internet access. Although the dialog box uses some weird wording, it is basically just asking you to select the NIC that is attached to your private network. Make your selection, and click Next, followed by Finish to complete the process.

Conclusion

In this article, I have explained how you can use a NAT server as a way of sharing an Internet connection among the users on your network. I then went on to explain how IP addressing should be configured and how to configure RRAS to act as a NAT router.

Read More..

Protecting Your Network Against Spoofed IP Packets


These days, the vast majority of administrators go to great lengths to protect the files on their network. Typically, elaborate firewalls are used to keep outsiders away from file servers. The files residing on those servers often lie behind an intricate permissions scheme and are often encrypted. Complex auditing mechanisms might even monitor access to files. The point is that in this day and age, most administrators take security very seriously. What you might not realize though is that all of this security can be easily undone through the simple action of a user accessing a file through legitimate means. In this article, I will show you how this is possible and what you can do to fight back.

Encrypted Files on the Network

Let’s pretend for a moment that you use the Encryptable File System (EFS) to encrypt all of the files residing on a particular server. Now let’s pretend that a user with legitimate access needs to open one of those files from their workstation. When the user opens the file, security is briefly compromised. The reason for this is that the file must travel over the network. This is a problem because when a user accesses an encrypted file, the file is decrypted at the server level, not at the workstation level. This means that the file has been decrypted before it ever arrives at the user’s PC. Anyone on the network with a little bit of know-how can use a protocol analyzer to intercept the file in transit and gain access to the information contained in the file.

The reason that this type of exploit works has to do with the way that networking works at the most basic level. On many types of networks, all of the computers on a network segment share a common connection medium. When a computer transmits a packet to another computer, all of the computers on the segment receive the packet. Each computer checks the packet’s destination address to see if it is the intended recipient of the packet. If the destination address doesn’t match the computer’s address, then the computer assumes that the packet is intended for someone else and ignores the packet.

Protocol Analyzers

When a computer runs a protocol analyzer though, the protocol analyzer places the computer’s network card into promiscuous mode. This means that the computer does not ignore packets, regardless of the intended destination. The protocol analyzer then displays the contents of each packet on the screen. Every protocol analyzer is different, but most of the time protocol analyzers will allow users to filter out unwanted packets and reconstruct packet streams. The result is that a user who is running a protocol analyzer can get their own copy of a file that is being transmitted, they can read E-mail messages, and do just about anything else that they want.

Obviously, the idea that a user on your network can use a protocol analyzer to snoop the contents of packets that are flowing across the network isn’t exactly a comforting thought. In reality though, the damage that a user can do with a protocol analyzer is a whole lot worse than what I have already told you about. Yes, a user who’s equipped with a protocol analyzer can steal files in transit, read E-mails, see the contents of the Web page that you are looking at and things like that, but they can also steal your online identity.

Identity Theft

Think about it for a moment. Files, E-mail messages, and Web pages aren’t the only things that flow across the network. Authentication credentials are also transmitted across a network. Imagine for a moment that you are logging on to a FTP site. As you type your password, the password is not displayed on the screen. You see a dot or an asterisk in place of each character. As soon as you press enter though, your password is transmitted to the FTP server. If someone is watching the login process with a protocol analyzer, they won’t see your password represented as dots or as asterisks. They will see your password spelled out in plain text.

OK, in all fairness, it isn’t always that easy to steal a password. A generic FTP session transmits the password in clear text, but most modern authentication mechanisms encrypt the password prior to transmission. When the server receives the password, it is decrypted and checked for accuracy. If you were to watch an encrypted password be transmitted, the protocol analyzer wouldn’t show you anything but a long string of hieroglyphics.

The good news is that having the password encrypted makes it difficult, if not impossible, for someone with a protocol analyzer to steal the password. The bad news is that the user doesn’t have to steal the password. The user can steal your identity through the use of a replay attack.

Replay attack

Here’s how it works. The person with the protocol analyzer recognizes an authentication packet, but can’t read the password contained within it because the password is encrypted. Just because the password is encrypted though, it doesn’t mean that the password isn’t there. The packet still contains a password and that password exists in a form that is perfectly acceptable to the server that authenticates the password. That being the case, the user makes a copy of the authentication packet and changes the packet’s source address to match the address of the computer that they are using. They then use the protocol analyzer to transmit the modified authentication packet to the server that handles authentication for the network. The server receives the packet and sees that it contains a valid set of authentication credentials. The server therefore assumes that the user whose identity was just stolen is logged in at the hacker’s machine. To put it simply, the hacker is logged in as the user whose identity they stole, and they never even had to figure out the victim’s password to do it.

Since the hacker is impersonating a legitimate user, there is always the chance that the user whose identity was stolen could log in while the hacker is logged in as them. Sometimes, the hacker will launch a denial of service attack against the user that they are impersonating. This keeps the victim from logging on until the hacker is finished with what ever it is that they are doing.

How do I Protect the Network?

So I guess the million dollar question is how can you protect your network against this type of attack? There are a couple of different things that you can do. The first thing that you need to do is to have a system in place to catch anyone who is using a protocol analyzer on your network. At first it might seem impossible to catch someone using a protocol analyzer since a protocol analyzer passively listens to network traffic.

The Bait

The key to catching someone using a protocol analyzer is to watch DNS name resolutions. You can setup a bait machine on your network. The machine doesn’t actually have to do anything other than run Windows. The catch is that you must not tell anyone of this machine’s existence. Since nobody knows that the machine exists, and the machine isn’t doing anything, then nobody should have any reason to communicate with the machine. However, because the machine is running Windows, it will send out the occasional packet. Normally, the machines on your network will be completely oblivious to this packet. However, a protocol analyzer will notice that traffic is coming from an unknown host on the network. The protocol analyzer will then perform a DNS query to try to determine the machine’s identity. Normally, nobody should have any reason to be making DNS queries regarding your bait machine, so these types of queries are almost always indicative of someone running a protocol analyzer or other hacking tool.

IPSec

Another way that you can defend your network against these types of attacks is to use IPSec to encrypt network traffic. I’ve already shown you how encryption can be circumvented, so you might be wondering what makes IPSec any different.

The difference is that IPSec’s whole job is to secure data flowing over the network. Before a session can even be encrypted, IPSec insists on mutual authentication. What this means is that if Computer A wanted to securely transmit a packet to Computer B, IPSec would require both machines to prove their identities before it would permit the session.

IPSec also takes measures to insure that packets are not tampered with in transit. Earlier I explained how the source address of a packet could be modified by a hacker. A hacker can change much more than a packet’s address though. For example, imagine that a hacker knew that Computer A was going to be sending an important E-mail message to Computer B. The hacker could run a denial of service attack against Computer B to prevent them from receiving the message. Meanwhile, the hacker intercepts the message and changes it to make it look like the guy at Computer A said something completely different than what the original message said. The hacker then ends the denial of service attack against Computer B and sends the modified packets. The result is that the person at Computer B receives a fraudulent E-Mail message that looks authentic.

IPSec can protect against packet modification. IPSec calculates a check sum value based on the packet’s original contents. If the packet is modified, then the checksum value becomes invalid and IPSec knows that the packet has been tampered with.

IPSec even protects against replay attacks. Each IPSec packet is assigned a sequence number. If a hacker attempts to replay an IPSec encrypted packet, then the sequence number will not fit into the current packet sequence and IPSec will know that the packets are invalid.

As you can see, deploying IPSec on your network can greatly enhance your network’s security. Before you deicide to deploy IPSec though, there are a few things that you need to know. First, IPSec requires your network to have a certificate server in place. Windows Server 2003 can be configured to act as a certificate authority, but you will need a dedicated server. Technically, a dedicated server isn’t an absolute requirement for a certificate authority, but running any other services on a certificate server is an extremely bad idea from a security standpoint.

Another thing that you will need to know is that IPSec does place an additional burden on your network. Extra CPU cycles are necessary to perform the encryption and decryption process, and IPSec encryption usually increases the volume of traffic that’s flowing across your network. One way of easing this additional burden though is to use IPSec enabled NIC cards. These NICs offload the encryption and decryption process from the machine’s CPU.

One last thing that you need to know about IPSec is that not every operating system supports it. IPSec was first introduced in Windows 2000. Older Windows operating systems do not support IPSec.

Conclusion

In this article, I have explained some different ways that hackers can exploit the traffic that’s flowing across your network. I then went on to explain how you can use bait machines and IPSec encryption to counter these techniques.
About Brien M. Posey

Read More..

Flip and Swivel Combo Cell Phone - Multimedia Bluetooth Dualband


Dual Band GSM/GPRS flip and swivel combo multimedia cell phone with Bluetooth, Dual SIM, TV and FM radio as it signature features. This is a truly video friendly multimedia mobile phone with its rotating vertical and horizontal wide screen. Not only does the screen rotate, but the images/videos on the screen change from portrait to landscape mode. This is a one of a kind feature that is sure to dazzle your friends as well as your own eyes as you see the pictures automatically change with the orientation of the screen.


Contained within the user friendly software interface are a bevy of multimedia features such as analog TV, FM Radio, MP3/MP4 player, digital camera, digital video recorder, image viewer, sound recorder, and Ebook reader. The phone is pre-loaded with a 1GB TF (microSD) memory card, so the phone comes out of the box ready to start taking pictures and loading up audio files. Unlike competing multimedia phones, this one is not locked into any particular network carrier, so feel free to use your unlocked cell phone with whatever carrier you prefer.

This is not your grandmothers cell phone. The CVSCD-7300 not only has robust multimedia features, but also includes native dual-band GSM to keep you connected in more than 100 countries and contains a large 2000mAh capacity li-ion battery for plenty of work and play time between charges. The handy dual SIM slots allow you to keep in touch with business and personal contacts from the same phone.

At a Glance...
Flip and swivel screen multimedia cell phone.
Dual SIM interactive mobile phone with a large selection of easy to use pre-loaded software tools.

Prices

1 or more for $146.25 each
3 or more for $140.40 each
7 or more for $134.55 each
15 or more for $132.21 each
25 or more for $131.63 each
50 or more for $128.70 each

BUY NOW

Read More..

Mobile Phone Watch with Back Lit Keypad Strap


Just when you thought our selection of cell phone watches couldn't get any cooler, we've out done ourselves by securing this awesome model with a back lit keypad built into the strap.

You can simply make quick calls by dialing the number on the keypad strap, and when you need to do some more serious activity like using the organiser you can take out the handy mini stylus. All the media features you've come to expect are here too, with A2DP Bluetooth, video camera MP3 player and high resolution still camera.
NOTE: This product is compatible with GSM at 900MHz, 1800MHz, 1900MHz only, please check with your local provider if you are unsure.

Buy More... Get Lower Prices
 
1     or more for $166.88  each
3     or more for $160.20 each
7     or more for $153.52  each
15   or more for $150.85  each
25   or more for $150.19  each
50   or more for $146.85  each

BUY NOW

Read More..