Port Forwarding and Firewall RulesPort Forwarding and Firewall Rules
Port Forwarding and Adding Firewall Rules
This section could also be titled, "How to open yourself up to attack in a civil sort of way." Normally, if your router receives a request from the Internet, your router will not have a matching request from a device on your home LAN. Therefore, it just throws the request (packet) away. This is exactly what you want it to do. Normally those requests are from a hacker trying to see if your computer has no firewall in front of it. If so, they could easily see your published/shared files using a Microsoft file sharing query, for example. In the router's default configuration, no device on the Internet can initiate a request destined for your router or a device on your LAN; devices on the Internet can only send back responses to requests made from the router or devices on your LAN (e.g., browsing a web site).
Sometimes, however, you may want machines on the Internet to be able to initiate a request on a certain port or set of ports that one of the devices on your LAN will serve. The common use of this is when you want to temporarily or permanently provide a server for a game using one of computers on your LAN as the server host. (You should make sure that you have the right to run a server before doing so. See Want to Host an Internet Game Server? Check First.) For example, you might want to run an Unreal Tournament 2004 server so you and some of your friends can have fun chatting to each other over the Internet and killing each other. When an Unreal Tournament 2004 client running on one of friend's computers wants to join your server, it will originate the request with a destination IP address being the public address of your router and also to particular port. (Remember, a port is just a number from 0 - 65,535.) When that request reaches your router, you don't want the router to just drop the packet (for a change). Instead you want to router to forward that packet to the computer running the server.
Most routers will allow you to add a "firewall rule" that will forward traffic, which originates from the Internet and that is destined for a particular port on your router's public IP address, to the same or another port on one of the devices on the LAN. Note that the client sends the request to your public IP address not the private IP address of the server on your LAN. The action of setting up these rules and the router fulfilling them is called "port-forwarding." Some games require multiple ports to be forwarded (e.g., 6800, 1900, 21005). Some require that a range of ports (e.g., ports 27000-27099) be made available.
So the first thing to do is to determine what ports need to be forwarded to your game server. The web site portforward.com contains the procedures for setting up port forwarding for many routers (in addition to the example we're going to have here) and also a list of common ports that need to be forwarded for a number of games and other applications. Unfortunately, I found it missing some detail as the procedures are written in a generic fashion. Some games are also not in the list. When that happens do a search at http://www.google.com and use “<insert game's title here>” firewall ports as the search phrase. (Putting the game's title in double quotes makes Google search for that exact title as a single search term. For example, using "Unreal Tournament 2004" will find only those pages that have those words together and in order - rather than the words unreal, tournament, and 2004 as individual terms. That cuts down a lot of extraneous links from being returned.)
After a little digging in the search results, we find that UT 2004 servers receive requests on UDP ports 7777 and 7778 (Query Port) and 7787 (GameSpy Query Port) from UT 2004 players wishing to join the server. Additionally, the server will send TCP requests using the local port 28902 to the UT 2004 Master Server List (so that your server is put into the list of servers that the UT 2004 players see). However, since that TCP request is an outbound connection initiated by your UT 2004 server, you usually don't need an explicit rule for it.
We'll show setting up the necessary port forwarding by using the same Netgear WGT624 used in our previous examples. Other routers won't have port forwarding in exactly the same place, so you may have to search your menus for it. (This is where the pages at https://portforward.com/ can really help.) As we always do, start your session by logging into the router as shown in section Connecting to Your ISP Using Dynamic IP Addressing. Then, from the Basic Settings screen, choose the Port Forwarding/Port Triggering menu item under the Advanced menu as shown here.
That will bring us to the Port Forwarding/Port Triggering page as shown below.
Make sure that the Port Forwarding radio button is enabled (if your router has such a button or check box). Click on the Add Custom Service button, which will take us to the Ports - Custom Services page.
The Ports - Custom Services page is where we add the new port-forwarding rule for our game server. First, we enter a Service Name for our new rule into the text box, which in this example is "UT_2004_UDP-1." Then, we indicate that we wish this rule to apply to request sent using the UDP protocol by choosing UDP from the Service Type pull-down box. Next, since ports 7777 and 7778 are next to each other, we enter them as a range of ports (even though it is a short range) into the Starting Port and Ending Port text boxes, respectively. Finally, we type in the Server IP Address. Note that the IP address used is outside of the range of IP addresses that the router's DHCP server serves. This means that we assigned a static (fixed) IP address to the game server. Since the rules we're setting up are specific to one IP address, we like the game server's IP address to be set to that and never change. DHCP cannot guarantee this, so we use static IP addresses which do. (See Fixed/Static IP (Manual IP) Assignment for information about assigning a fixed IP address to your game server machine.) When we hit the Apply button, we are back at the Port Forwarding/Port Triggering page, but the rule we just added is now shown on the page.
We need to add a second rule for UDP port 7787. We do this by again clicking on the Add Custom Service button and entering the information for the second rule as shown below.
We name the second port-forwarding firewall rule "UT_2004_UDP_2." Note that the starting and ending port numbers are the same when defining a rule for a single port. Again, we press the Apply button and are returned to the Port Forwarding/Port Triggering page, but this time, both of the new rules are shown.
Now, we've added the port-forwarding rules, but there is one extra thing that needs to be done for this particular game server after it is installed. That is to edit the UT2004.ini file (using Notepad or some other plain text editor), search for the lines:
and change the ServerBehindNAT from "False" to "True" as shown. This solves a specific problem that makes the server behave itself when behind a NAT firewall such as the Netgear WGT624.
Maintaining Security with Port ForwardingMaintaining Security with Port Forwarding
Maintaining Security with Port Forwarding
Now that you know how to open yourself up to attack in a civil manner, a few words of caution are in order. In ancient Internet times (i.e., 10 years ago or more), there were two approaches to how to set up a firewall. The first approach was to open all ports to all internal machines by default. In this approach rules were created to restrict traffic on those ports known to be "bad" or sources of trouble. This tends to make the life of system administrators easier because most traffic will be routed through the firewall by default. Unfortunately, as time went on and viruses and Trojan horses appeared using more and more ports, this approach became too unsafe.
The second approach is to close most or all ports by default and open only those known to be reasonably safe. This makes the system administrator's job tougher because every new service that their organization wants to offer to users on the Internet or services on the Internet to which the organization's internal users want access will often require rules to be added. However, it is much safer from a security standpoint. Because new viruses that exploit different weaknesses of operating system services found at certain ports and Trojan horses that use different ports than previously known ones, opening ports without a good reason is just a bad idea. All home office/small office routers I have used thus far have adopted the second approach by default, but can be made to operate under the first approach simply by opening large ranges of ports in the rules table.
You might be surprised to learn that your personal computer is most likely a server. No, I didn't say if you have a Windows Server 2003 machine or the like. I'm talking about any right-out-of-the-box, plain-Jane, straight-up PC you can get at Best Buy. Remember that whole topic about connecting up your home PCs so that you can share files, printers, and the like? Guess what? Doing that also makes them servers in every sense of the word. The File Sharing and Printer Sharing services are just that - services. If you share a folder or printer from your machine to other machines on your network a service is started and begins listening on a port on your machine for requests from other machines just like an Internet web server waits for requests for web pages from your browser. If you want to see this for yourself, open a command prompt window and type netstat -rn as the command. You will see something like the following screen.
Any of the port numbers given above (i.e., the number after the ":" such as 135 and 445) are services waiting for commands. TCP and UDP ports 135 - 139 and 445 (and according to Microsoft, port 593) are used by the Windows file and print sharing service. TCP Port 1027 is used by Microsoft's Internet Connection Sharing service and the Internet Firewall. UDP Port 1029 is used by Microsoft's Local Security Authority (LSA), which is used to verify and compare user names and passwords (as a part of sharing files and printers). The Sasser worm variants attacked this port and often caused the service to shut down. This in turn would cause the system to reboot itself as a security precaution. Hence, this is a good example of a port you don't want to make available to the Internet. The above list might seem like more services that you would like to have running, but, in reality, that list is about the shortest it ever gets. This particular computer was just rebooted and connected to a router with no access to the Internet when this screenshot was captured. It only gets worse from this point. If you are curious and want to further investigate any of the ports you see in your netstat results, check out the section Test 10: Using the netstat command and TCPView to Check Port Usage.
Your file and printer sharing server will periodically broadcast that it has services available and inquire about other services from other machines. I'm going to assume that you probably didn't intend to share your files or printer with the entire Internet. At one time, I logged unsolicited requests from the Internet that reached my router. I saw Windows machines doing just that many, many, ... many, many times. It was so bad, that I stopped logging all the generous attempts of Windows machines on the Internet to give me access to their files and printers. The amount of this traffic varied from hundreds to thousands per day. I no longer see this traffic at my router, so I believe that ISPs have wizened up and now filter it. That and most people do have router/firewall products in place.
There are certain ports you should never open. Hopefully, it's obvious that the ports mentioned above - TCP & UDP ports 135 - 139, 445, and 593 - should never be open either going to or coming from the Internet. The table below lists ports that should generally not be open to inbound traffic. This means that you should be wary of adding rules to your firewall that allow Internet traffic through to any of the devices on your LAN over the ports listed.
|0 - 1023||TCP/UDP||The ports in this range are known as "privileged ports." They are reserved for usage by specific services like a web server, FTP server, or email server. Unless you have a machine that is running one of these special services, there is no good reason to ever have a rule allowing traffic to any of the LAN machines using any of these ports.|
|1025-1030||TCP||Microsoft Remote Procedure Call (RPC) service: This port is used to allow other machines on the network to run services on a local machine. Inside of a LAN this is a useful feature, but Internet machines should not be allowed to run services on LAN machines. These ports also seem to have other uses in Microsoft systems.|
|1026 - 1027, and to a lesser extent 1028 - 1029||UDP||In Windows NT, 2000, and XP systems, these ports are used by the messenger service (a.k.a. "net send"). This should not be confused with the Windows Messenger application used for instant messaging (a la AOL Instant Messenger). The intent of the net send service was to allow system administrators to broadcast messages like "Dept. 43 file server going down for 1 hour of maintenance." Unfortunately, spammers started using the service to display messages like "You may have a virus. Visit www.imalowlifespammer.com for details." It's mostly just a nuisance.|
|1434||UDP||Probably not a concern to most home network users, but small businesses using Microsoft SQL server will want to keep this port closed to inbound traffic. It's intended to be used to allow remote monitoring of Microsoft SQL Server databases, but it was also the used to exploit SQL Server as one of the fastest spreading worms ever. (If you are a SQL Server user, keep port 1433 closed as well.)|
|2745||TCP||Opening this port does not actively open a machine up to attack. It is used by the Bagle and Beagle viruses as a port that allows the virus writer to upload and execute software on an infected machine. If the machine is not infected, there's no harm in opening this port. My personal feeling is, “Why take any unnecessary chances?”|
I derived the above list from looking at the incoming Internet traffic that was logged as denied by my firewall. Then I went to Google and use the port and protocol as a search term (e.g., "UDP port 1434") in order to find out what the ports were (mis)used for. I find http://www.linklogger.com/commonscans.htm a useful source for such information as well.
From time to time, it is a good idea to check the security of your firewall. This is best done from an outside source trying to poke its way in. There are several sites that will scan your IP (i.e., your firewall) for open ports. Most of these do so to try to sell you products for security. One that exists just to try to further security (awareness) on the Internet is (Steve) Gibson Research Corporation's Shields Up!, which is a tool that scans your IP and tells you what you may have open that could be exploited. Click the Proceed button to get to a menu of scan types. I generally like all the first three: File Sharing, Common Ports and All Service Ports. It's good to get in the habit of running this tool regularly. Another good tool is nmap, but that tool is much more complex and probably beyond what most home network users can work with.
The DMZ Machine and Why It Is Evil
A De-Militarized Zone or "DMZ" machine - for the purposes of a home network - is one computer that resides at a static IP address on your LAN that has been designated to be fully exposed to the Internet. Normally, if the firewall receives a packet that does not map to a request made by one of the devices on the LAN, it just drops the packet. However, if a DMZ host has been designated, the firewall will instead route the packet to the DMZ server. That means the DMZ machine is potentially bombarded with requests from the Internet that it may or may not be prepared to handle. Many of those requests will be attempts to hack or infect the DMZ machine.
The security risk to the DMZ machine is high, so why would somebody wish to designate a DMZ machine? A good reason for having a DMZ machine is when you want a machine to be outside of the firewall in order to be a dedicated server (web server, mail server, Unreal Tournament 2004, etc.) and you are willing to isolate that machine from the rest of the machines on the LAN as much as possible. Unfortunately DMZ servers are usually used for a "bad" reason. Sometimes, it is very complicated to set up all the port forwarding firewall rules necessary for a particular game or other server. Some require three, four or more rules to be added. Some routers may not support the number and types of firewall rules that need to be added. Just designating the machine as a DMZ server seems like a good alternative because the work of adding those rules is avoided.
When you designate a computer as a DMZ machine, you've effectively placed it outside of the firewall protection provided by the router. Therefore, if you're going to have a DMZ machine, treat it as a leper. Assume it has been compromised the moment you attach it to the Internet. Don't store any sensitive data on it - up to and including reformatting the machine and reinstalling a fresh copy operating system before starting to use it as such. Only designate a machine as the DMZ machine if you are not going to use it for any other purpose. Install a software firewall with only the only open ports being those needed expressly by to the server and a few other services like outbound ports 80 and 443 (for http and https, respectively).
More importantly, the other machines on your LAN should be protected from the DMZ machine. Install personal firewalls on every other machine and device on the LAN and configure those firewalls to deny any traffic from the DMZ machine with the exception of the ports it's been specifically set up to use for whatever service it is offering. That way, if the DMZ machine does get compromised, the other machines on the LAN may remain safe.