Practically Networked Home Earthweb HardwareCentral earthwebdeveloper CrossNodes Datamation
Welcome to PractiallyNetworked
Product Reviews

 • Routers
 • Hubs/Switches
 • Wireless Gateway
 • Wireless AP
 • Wireless NIC
 • Network Storage
 • Print Servers
 • Bluetooth Adapters
& Tutorials

 • Networking
 • Internet Sharing
 • Security
 • Backgrounders
 • Troubleshooting

 • PracNet How To's
User Opinions
Practicallynetworked Glossary

 Find a Network Term  

  Most Popular Tutorials

• Microsoft Vista Home Networking Setup and Options
The most daunting part of upgrading to Windows Vista may be trying to figure out where in the layers of menus the networking and file-sharing options are hidden.

• Do It Yourself: Roll Your Own Network Cables
It may not be something you do everyday, but having the supplies and know-how to whip up a network cable on the spot can be very handy.

• Tips for Securing Your Home Router
Seemingly minor and easily overlooked settings can still have profound security implications. Here are some steps you can take to make sure your wired or wireless home router and by extension, your network is as secure as possible.

  Most Popular Reviews

• Microsoft Windows Home Server
If you have a home network, you'll welcome the easy file sharing, remote access and the image-based backup features of Windows Home Server.

• Iomega StorCenter Network Hard Drive
Iomega's fourth generation StorCenter Network Hard Drive brings many of the features found in higher-end storage devices down to an attractive price.

• MikroTik's The Dude
This free tool delivers many of the same capabilities that you'd find in pricey network monitoring tools. As long as you don't mind tinkering, The Dude is a decent network utility that should be worth the download.

Building Network Appliances With Linux, Part 6: Running Servers

by Carla Schroder

In the previous installments of this series, we built a good, solid iptables firewall on Debian Linux. Last week we left off with testing and activating the firewall. At this point your firewall blocks all incoming connection attempts, and allows only connections initiated from inside your LAN, such as checking e-mail, IRC and Web surfing. If you are not running any public services you're all finished. If you want to run your own public Web or mail server you need to poke a hole or two in your firewall.

Running Servers Behind a Firewall

There are several different ways to configure your network for public services. A common architecture looks like Figure 1.

Figure 1.
(Click for a larger image)
This is common on small networks with a single static routable WAN IP and a range of private IPs. It presents a security weakness, though, because the public server is on the same subnet as the private LAN hosts. If the public server is compromised, it is easy for the attacker to penetrate your LAN. However, it is simple to set up, so it's good for testing. I do not recommend it for production systems! You have been warned.

Add these rules to the firewall_nat script from Part 5 to route incoming traffic destined for your Web server, using your own server IP address:

$ipt -t nat -A PREROUTING -p tcp -i $WAN_IFACE --dport 80 -j DNAT --to-destination
$ipt -A FORWARD -p tcp -i $WAN_IFACE -o $LAN_IFACE -d --dport 80  -j ACCEPT
Restart your firewall by running the ipt_flush script, then the firewall_nat script. Now your firewall is routing all incoming TCP port 80 traffic to your Web server.

Testing the Firewall

Run netstat on your server to make sure it is listening on the correct ports. This is what it looks like with for a server with only TCP 80 open:
# netstat -untap
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address            State     PID/Program name

tcp6   0   0 :::80                  :::*                       LISTEN     4464/apache2

Build a Linux Appliance

  • Part 1: Introduction and Hardware Requirements
  • Part 2: Install and Configure Linux
  • Part 3: The Firewall
  • Part 4: Locking Down the Firewall Box
  • Part 5: Internet Connection Sharing Firewall
  • Ideally you will run tests from both sides of the firewall to see what is happening. Having a friend who will give you a shell account on their remote system is a great way to see what your LAN looks like from the outside. Or just use your dialup account. Most DSL accounts come with free dialup. (Most cable Internet accounts don't.)

    When you're outside your LAN, the first command to run is nmap:

    $ nmap
    Starting nmap 3.81 ( ) at 2006-07-26 11:08 EST
    Interesting ports on (
    (The 1662 ports scanned but not shown below are in state: filtered)
    80/tcp open  http
    Nmap finished: 1 IP address (1 host up) scanned in 95.372 seconds
    This is just what you want to see. Then fire up a Web browser and admire your site.

    A More Secure Design

    Figure 2 shows a better LAN layout.

    Figure 2.
    (Click for a larger image)
    This requires three Ethernet cards (or one nice multiport Ethernet NIC) on the firewall: WAN, LAN, and DMZ, or "de-militarized zone." (See Part 4 for help on configuring network cards.) Public servers go in the DMZ and are given a different subnet than the LAN in order to protect your LAN hosts. To make this work you need some new iptables rules. First add the new NIC to firewall_nat:

    Then add these rules. Be sure to use your own IP address:
    # the NEW state allows TCP packets through that do not have the SYN flag set
    # so we must make sure that only SYN-flagged packets are allowed.
    -A INPUT p tcp ! --syn -m state --state NEW -j DROP
    # Permit the server to respond only to established WAN traffic, allow all incoming from LAN
    # route port 80 traffic to the Webserver
    $ipt -t nat -A PREROUTING -p tcp -i $WAN_IFACE --dport 80 -j DNAT --to-destination
    $ipt -A FORWARD -p tcp -i $WAN_IFACE -o $DMZ_IFACE -d --dport 80  -j ACCEPT

    Restart your firewall by running the ipt_flush script, then the firewall_nat script, then test to see if everything works.

    What if your server listens on multiple ports? Use the multiport option, like this:

    $ipt -A FORWARD -p tcp -i $WAN_IFACE -o $DMZ_IFACE -d -m multiport --dport 80,443,8080  -j ACCEPT

    See the complete example firewall_nat script: firewall_nat_part_6.txt

    Other Servers

    These rules can easily be adapted for other servers. All you need are the correct port numbers and server IPs, and mind if they use TCP or UDP, or both.

    Learning More

    This has been a crash course in firewalling, so there hasn't been much in the way of explanations. Please refer to Oskar Andreasson's Iptables Tutorial to learn what all the different options used here mean. Webmin's firewall module is useful for visualizing the relationships between the different rules.

    Additionally, please study man nmap and man netstat. Both are powerful tools for tracking down problems and keeping an eye on your network. Understanding the different utilities used in this series will give you mighty guru powers, and your network will be safe while your friends are cleaning up after intrusions and wondering what hit them.

    Next in this series: using Squid to speed up surfing and block bad Websites, then how to build a cross-platform file and print server.


    For more help, don't forget to try one of our PracticallyNetworked Forums. Earthweb HardwareCentral earthwebdeveloper CrossNodes Datamation

    Home | Networking | Backgrounders | Internet Sharing | Security | HowTo | Troubleshooting | Reviews | News | About | Jobs | Tools | Forums