A gateway machine is one that has a connection to the Internet, and which allows other machines on the LAN to access the Internet through it. It also usually provides protective services like firewalling to prevent outsiders from gaining access to the LAN.

NOTE: if you only have your Linux box, and you don't have any other machines, you don't need a real gateway machine. Nonetheless, you may want to configure the input and output firewalls to provide you with some protection from crackers.

NOTE: Howard Mann has another firewall setup, slightly different from mine, that you might want to look at. We have two different approaches to the problem. His aims to be more secure, but it may block off things like the RealAudio and Quake protocols unless modified and you'll need to know exactly what ports to open up. Mine aims to cover the most common 95% of attacks, and the ones it doesn't explicitly cover require either considerable technical knowledge on the part of the attacker ( which leaves out 99% of the crackers out there who are just script-kiddies or wannabes ) or that they already have access to your machine. What you get in return for that slight relaxation of security is no interference at all with protocols that use non-privileged ( 1024 and up ) ports ( ie. RealAudio, Quake, VDOLive ).

Assumptions

• You are using Ethernet and eth0 is the interface to your LAN. Replace eth0 with the appropriate interface name if needed.
• You have already set up dial-up PPP access to XMission on interface ppp0. If you have DSL and you have it on a seperate Ethernet from the other machines, you can substitute the name of it's Ethernet interface for ppp0. If you have DSL and have the DSL modem/router on the same Ethernet as everything else, things get more complicated and what's described here will not work.
• You already have entries in the hosts files so that the machines on your network know each other's names. The hosts file on Linux boxes is /etc/hosts, and contains one line per machine. The first item on the line is the IP address of the machine. The second item, seperated from the first by spaces or tabs, is the hostname. Systems other than Linux ( eg. Windows ) have other provisions for associating hostnames and IP addresses, and you'll need to consult their documentation for details. Unfortunately, setting up a Linux box as a DNS server, while quite doable, is a bit more than I can cover here. I do plan on covering it in another document.
• Your kernel has IP forwarding, firewalling and masquerading compiled in. Standard RedHat 6.0 is built that way. You need to check for the existence of three files:
  1. /proc/sys/net/ipv4/ip_forward indicates that IP forwarding is present.
  2. /proc/net/ip_fwchains indicates that IP firewalling is enabled.
  3. /proc/net/ip_masquerade indicates that masquerading is enabled.
• You are NOT dialed in to XMission at the time. Trust me, you do not want a live connection to the outside world while you are messing around with network configurations. That's an open invitation for the bad guys to take advantage of things.
• You do understand that a normal, personal account on XMission is intended for the use of one person. This setup will let multiple people on multiple machines use your connection for Internet access, which isn't quite what XMission sold you the account for. If you're going to have other people using your connection, you might want to be polite and either have them buy their own account or buy yourself the slightly-more-expensive business account. In short, just because you can give an entire network access through a single personal account doesn't mean you should do that. A little common sense and courtesy should keep you on the right side of the line.

First off, you're going to need to pick IP addresses for the other machines on your network. One thing you want is to pick addresses that aren't used by real machines on the Internet. Luckily, the Internic has thought of this. They have reserved 3 blocks of addresses for private address space. These addresses are guaranteed never to be assigned by Internic to real machines, so you can freely use them for your own machines. The blocks are:

I would recommend you pick one network from the 192.168 block. For our purposes I'll use 192.168.94. You can, if you want, pick a number between 1 and 254 and substitute it for 94. This will give you a single class C network with 256 addresses, a network number of 192.168.94.0, a netmask of 192.168.94.255 and a CIDR prefix of 192.168.94/24.

The first thing to do is to give addresses in this network to all of your machines. The host number for a class C network is the 4th digit of the address. Legal values are in the range 1-254. Host number 0 is used when referring to the network as a whole, and host number 255 is used for broadcast to all hosts on the network. These two numbers cannot be assigned to any machine on the network. First off, pick a host number for each machine on your LAN. In the hosts files, replace the address for each machine with a new one of the form 192.168.94.x, where x is the host number for that machine. For the Linux box, having x be 1 would be convenient, and that's what I'll assume below. Then go into the network configuration for the machine and change the IP address assigned to it's eth0 interface to the 192.168.94.x address you just gave it. On RedHat 6.0 you can do this through the linuxconf program, but it might be faster to just go into the /etc/sysconfig/network-scripts/ifcfg-eth0 file and change the value on the IPADDR line to the correct address. Be sure to preserve the quotes, though, they are needed.

Next step is to enable IP forwarding on your Linux box. If you go into /etc/sysconfig/network, you'll find a FORWARD_IPV4 line. If it is set to YES, forwarding is already turned on. If it's not, you'll need to edit the file so the FORWARD_IPV4 line says YES. Again, preserve any quotes already there. This will not enable routing, we need to do a few things yet before we do that.

A comment about routing. When you configure network interfaces, one of the options is whether to put a default route through that interface. This is either through a button on the linuxconf panel or through the DEFROUTE= line in the ifcfg-ifname file in /etc/sysconfig/network-scripts. You want the interface of your link to the outside world ( your dial-up PPP interface or the interface connected to your DSL box ) to have the default route ( button checked or DEFROUTE="yes" in the ifcfg file ) and all others to not have it ( button unchecked of DEFROUTE="no" ). For normal network setups the RedHat scripts will take care of the routing from there, setting up explicit routes for your local network out the Ethernet interface and pointing a default route for anything it doesn't otherwise know how to route out your outside connection to XMission's routers.

Now we get to the meat of the gateway setup: creating the rules that block dangerous packets and allow other machines on your local network to reach out through the gateway to the rest of the Internet. In RedHat 5.x this was fairly easy, since the setup for firewall rules was straightforward. RedHat 6.0 introduced the Linux 2.2.x kernels, which use a radically different system for firewall rules called IP chains. It also introduced a lot more security options on the network interfaces themselves. The end result is a lot more flexible, but complex enough to require splitting the setup into two scripts and a configuration file. The first script, rc.iprules-boot, is run once at system startup, sets the options on the interfaces properly and creates the IP chains for the second script to fill in. It works in conjunction with the sysctl.conf configuration file, which controls various network-interface and network protocol options The second script, rc.iprules, clears out all the chains and fills in the correct sets of rules. This second script can be run repeatedly after the system is running, so if you need to change the rules all you need to do is edit this script and re-run it. Make sure you aren't connected to XMission at the time, though, since for a moment you'll be completely unprotected and if there are any mistakes in the rules you could be unprotected until you can correct them. The order of commands in these scripts is significant, so don't go re-ordering lines.

You should down load both scripts, place them in /etc/rc.d and make them executable with:

chmod a+x /etc/rc.d/rc.iprules /etc/rc.d/rc.iprules-boot

The first script, rc.iprules-boot, I won't describe in detail here, I'll just highlight what it's doing. The first block of commands creates the firewall rule chains needed by the second script. This must be done only once, since creating a chain that already exists is an error. This is the main motivation for breaking the setup into two scripts: to split the steps that must be done only once from the steps that can be done repeatedly.

The sysctl.conf file, loaded via the sysctl -p /etc/sysctl.conf command during system startup, configures various options for the network interfaces:

• Source address spoofing protection is turned on. The kernel takes the source address of the packet and checks in the routing table to find out the interface packets to that address would go out. If that interface is different from the one the packet is arriving over, the packet is dropped.
• Source routed packets are disabled. In the normal course of things, the route a packet takes is determined by the routing table. Packets that specify their own route are normally used only by crackers or very exotic diagnostic techniques. You aren't likely to need to use any of the diagnostic tricks, so dropping all source-routed packets insures that crackers cannot bypass your firewall.
• Redirects are disabled. A redirect occurs when a machine sends packets over a route it shouldn't, and tells that machine to change it's routing table. On routers this can be dangerous since it allows outside sources to change your routing tables, so it's normally a good idea to not allow it.
• Martians are logged. Martians are packets with source addresses that are literally not of this world, eg. the broadcast address. We log them because if they occur they indicate something is very, very wrong somewhere.
• We always defragment incoming packets before forwarding them. This allows the firewall rules to see the entire packet, instead of having to deal with partial packets.
• We enable SYN cookies. Doing this prevents a denial-of-service attack based on starting the connection process on a large number of connections and then not finishing the handshake.
• TCP timestamps and window scaling are part of the "long fat pipe" additions to TCP. They help smooth things out when dealing with paths that have large transit times ( "long" :) and/or can have large amounts of data in transit on them ( "fat" ).
• We ignore ICMP Echo Request packets ( ping packets ) to broadcast addresses. This insures that your machine cannot be used by an attacker to fan-out a ping-flood attack.
• The set of randomly-selected local ports for outgoing connections is reset to a larger range higher in the set of port numbers. Normal client programs allow the system to select a port number for their outgoing connection. The default is to start from port 1024. This overlaps the set of ports used by things like the X-server and the X11 font server. By resetting the range to run from port 32768 to port 59999, we remove the overlap. You can then safely deny incoming connects to all ports up through 32767, which covers things like X11 servers and most RPC programs that use dynamically-assigned ports, without interfering with normal client programs.

The second script, rc.iprules, actually sets up the firewall rules. This script, unlike the first one, can be run repeatedly. Every time it is run, it will clear out the existing rules and replace them with the ones it defines. This can be handy if you have to change the rules, since you can just edit the script and re-run it. I'll walk through this one one section at a time.

#!/bin/sh

# Set up firewall and forwarding rules

# Set up some variables
lannet="192.168.94.0/24"
loopback="127.0.0.0/8"
any="0.0.0.0/0"
privateA="10.0.0.0/8"
privateB="172.16.0.0/12"
privateC="192.168.0.0/16"

# Static IP address
# staticaddr="999.999.999.999/32"

# External interface name
IFext="ppp0"

This sets up some names for values we'll need later. The first one is the network number for your network as a whole. The second is the local loopback network. The third is a wildcard representing any address. The fourth, fifth and sixth represent the private IP networks that nobody on the Internet should be using. The last line is the name of the network interface that connects you to the outside world. "ppp0" is usually correct for dial-up PPP customers, some strange setups might use "ppp1", DSL customers might use "eth0" ( no local Ethernet ) or "eth1" ( local Ethernet on eth0, DSL connection on eth1 ). Edit this as appropriate.

If you have a static IP address, replace the 999.999.999.999 on the staticaddr line with that address and uncomment that line.

# Clear any existing rules
echo Clearing existing rules
/sbin/ipchains -F input
/sbin/ipchains -F output
/sbin/ipchains -F forward
/sbin/ipchains -F in-icmp
/sbin/ipchains -F in-tcp
/sbin/ipchains -F in-udp
/sbin/ipchains -F acct-in
/sbin/ipchains -F acct-out

These lines clear out the existing firewall chains. On boot you don't need them, but by putting them here you can be sure that, if you re-run the script after boot-up, it'll start from a clean slate just as it would on boot. The input chain contains the rules applied to incoming packets. There are three sub-chains, in-icmp, in-tcp and in-udp, that are branched to from the input chain for ICMP, TCP and UDP packets and which contain rules specific to each protocol. The output chain contains the rules for outgoing packets. The forward chain contains rules controlling which packets can be forwarded from one interface to another. The acct-in and acct-out chains contain rules to record packet traffic over each interface separately. The way Linux applies the rules is fairly straightforward. At any point where a rule's action is taken, an accept action means processing continues while a reject or deny action means the packet is dropped with or without an error being reported to the sender:

1. When a packet is received from another machine on an interface, the input rules are applied to it with the interface of the packet being the interface the packet arrived over. If it matches an input rule, the action given for that rule is taken. If it does not match an input rule, the input policy is used as the default action.
2. The packet's destination address is checked against the addresses of the interfaces on this machine. If it matches one, the packet is addressed to this machine and is put onto the incoming queue for that interface. In this case, processing stops here.
3. If IP forwarding is not enabled, the packet is dropped with an error.
4. The routing table is consulted to determine which interface it should be forwarded out. If no route out is found, an error is generated and the packet is dropped.
5. The forwarding rules are checked, with the interface of the packet being the interface it will be forwarded out of. If a rule matches the packet, the action specified for that rule will be taken. If no rules match the packet, the forwarding policy is used as the default action.
6. Packets originating from this machine enter the processing here. A seperate lookup in the routing table is done to determine the interface to send the packet from and thus the source address of the packet.
7. The output rules are checked, with the interface of the packet being the interface it will be sent over. If a rule matches the packet, the rule's action is taken. If no match is found, the output policy is used.
8. The packet is put onto the outgoing queue for the interface and will be transmitted by the driver when it processes the queue.

# Set up default policies:
echo Setting default policies
#    No forwarding, reject input and allow output
/sbin/ipchains -P input ALLOW
/sbin/ipchains -P output ALLOW
/sbin/ipchains -P forward REJECT

These lines set the default firewall policies that tell the kernel what to do with ackets that don't match any other firewall rules. The input and output policies are to simply accept packets. This means that, unless we explicitly say otherwise, the kernel is allowed to receive and send any packets. We obviously don't in general need to control the local network interfaces, and we put in place rules to block packets as needed on the interface to the outside world. The forwarding policy, though, is to reject packets, that is to not forward them. This policy applies to packets that were not generated by the Linux box itself. It may seem rather bass-ackwards to turn on forwarding and then say to not forward packets, but by doing it this way we insure that packets only get forwarded between the LAN and the outside world in the ways we've said to forward them. We can only set policies on the built-in input, output and forward chains.

#
# Input rules
#
echo Setting input rules

# Make sure accounting rules get called
/sbin/ipchains -A input -j acct-in

# No spoofing of private or local addresses from the outside world
# Also no sending from the outside world to those addresses
# No notification on these, become a black hole but log them
/sbin/ipchains -A input -l -j DENY -i ${IFext} -b -s ${privateA}
/sbin/ipchains -A input -l -j DENY -i ${IFext} -b -s ${privateB}
/sbin/ipchains -A input -l -j DENY -i ${IFext} -b -s ${privateC}
/sbin/ipchains -A input -l -j DENY -i ${IFext} -b -s ${loopback}

These rules provide protection from attackers by blocking all packets from the outside world purporting to come from private IP addresses such as you'd use on a local LAN. The -l option tells the system to log all packets matching these rules in the system log. The -i option says that these rules apply to packets coming in over a named interface, in this case the one to the outside world. The -s option names the source addresses to look at, in the case of these rules the loopback network ( where 127.0.0.1 lives ) and the private class A, B and C networks. The -b option says that this rule is bi-directional, that is it applies to packets with a destination address matching the source addresses listed as well. The -j option names the action to be taken if a packet matches one of these rules. Since these rules apply only to packets from the external interface, they won't interfere with a local LAN.

You may notice that elsewhere I use REJECT, but here I suddenly use DENY. The two sound the same, but they're not. According to the RFCs, when a machine refuses to handle a packet it's supposed to send back an ICMP error indicating the problem. REJECT does precisely that: rejects the packet and informs the sender. DENY says to reject the packet silently and not inform the sender. Instead of getting a connection error right away, his machine will just lock up trying to establish the connection until his software times out. The reason for this is simple: when it comes to cracking I'm a nasty, vicious little bastard who wants to cause the crackers as much heartburn and headache as possible. Since the most likely source of these packets is a cracking attempt, we just turn into a black hole and let the slimes hang there wondering where things went.

If you have a static IP address, you can add this rule:

/sbin/ipchains -A input -l -j DENY -i ${IFext} -s ${staticaddr}

# Block some dangerous or useless ICMP messages
#       5 - routing redirects ( super-source-quench attack )
#       9 - router advertisement
#      10 - router solicitation
#   15,16 - obsolete
/sbin/ipchains -A input -j in-icmp -i ${IFext} -p icmp
/sbin/ipchains -A in-icmp -l -j DENY -p icmp -s ${any} 5
/sbin/ipchains -A in-icmp -l -j DENY -p icmp -s ${any} 9
/sbin/ipchains -A in-icmp -l -j DENY -p icmp -s ${any} 10
/sbin/ipchains -A in-icmp -l -j DENY -p icmp -s ${any} 15
/sbin/ipchains -A in-icmp -l -j DENY -p icmp -s ${any} 16
/sbin/ipchains -A in-icmp -j ACCEPT

Router advertisements and solicitations aren't needed by a simple single-connection setup. ICMP types 15 and 16 are obsolete and should never be seen. ICMP type 5 is a routing redirect message. It's normal use is to tell a machine that a better route to a host or network exists. Well, you only have one route to the world, the one through XMission, so you simply cannot be told to use another route. The most likely reasons for getting such a message are a) someone else has a badly mis-configured router, or b) someone is trying a super-source-quench attack on you. An SSQ attack, put simply, is a redirect telling your machine that the proper router for packets to somewhere is itself. This leaves your machine trying to talk to itself rather than the outside world. Not good.

Note the first command here. This puts a rule on the input chain that matches any ICMP packet coming in over the external interface, and causes processing to jump into the in-icmp chain. The remaining rules fill in the in-icmp chain. The last command says that we should accept any ICMP packet that we didn't deny earlier. If we had omitted that, or specified -j RETURN instead, processing would jump back onto the input chain and continue down it.

# Open holes for a few privileged UDP ports, block all other privileged
# ports
/sbin/ipchains -A input -j in-udp -i ${IFext} -p udp
/sbin/ipchains -A in-udp -j ACCEPT -p udp -d ${any} domain
/sbin/ipchains -A in-udp -j ACCEPT -p udp -d ${any} ntp
/sbin/ipchains -A in-udp -l -j REJECT -p udp -d ${any} 1:32767
/sbin/ipchains -A in-udp -j ACCEPT

These rules apply to UDP packets received from the dial-up link. Ports 1-1023 are privileged ports, which can be used only by programs running as root. Normally these are used by servers on your machine, like DNS. Ports up through 32767 will not be assigned to user client programs because of our earlier resetting of the local port range. The first rule here opens up holes for DNS and the NTP protocol. This allows hostname lookups to happen right, and allows the xntpd time-sync daemon and the ntpdate time-sync program ( used to synchronize your machine's clock to XMission's servers, which are synchronized to the US Naval Observatory atomic clocks ) to work correctly. Then we throw up a wall over the privileged ports, refusing to accept any UDP packets for them. If you are more paranoid, you can delete the second-to-last line and change the ACCEPT in the last line to REJECT, blocking all UDP traffic completely. Note that this may interfere with the operation of some programs using protocols based on UDP.

# Open holes for a few privileged TCP ports for inbound connections,
# block all other privileged and sensitive non-privileged ports
/sbin/ipchains -A input -j in-tcp -i ${IFext} -p tcp
/sbin/ipchains -A in-tcp -j ACCEPT -p tcp -d ${any} telnet
/sbin/ipchains -A in-tcp -j ACCEPT -p tcp -d ${any} ssh
/sbin/ipchains -A in-tcp -j ACCEPT -p tcp -d ${any} ftp
/sbin/ipchains -A in-tcp -j ACCEPT -p tcp -d ${any} ftp-data
/sbin/ipchains -A in-tcp -j ACCEPT -p tcp -d ${any} ntp
/sbin/ipchains -A in-tcp -j ACCEPT -p tcp -d ${any} auth
/sbin/ipchains -A in-tcp -l -j REJECT -p tcp -d ${any} 1:1023
/sbin/ipchains -A in-tcp -l -j REJECT -p tcp -d ${any} 6000
#/sbin/ipchains -A in-tcp -l -j REJECT -p tcp -d ${any} postgres
/sbin/ipchains -A in-tcp -l -j REJECT -p tcp -d ${any} -y
/sbin/ipchains -A in-tcp -j ACCEPT

A similar thing for TCP. We first open holes for Telnet, FTP, NTP and the identd authentication service, then block all privileged ports used by normal services plus port 6000 that your X-windows display will use to listen for TCP connections. The -y option on the second-to-last line is specific to TCP. We can't block all incoming TCP packets, because this would block off half of ordinary client connections and would completely disable your ability to browse the Web, retrieve your mail or use Telnet and FTP to connect to other machines. So we take another approach. The -y option says that this rule applies only to packets that have the TCP SYN bit set and the ACK bit clear. This sort of packet is the very first thing the client program sends to the server to initiate a TCP connection. Since this is an input rule, what it says is that we can send those packets out ( so we can initiate connections to machines in the outside world ) but we will not allow them in over the dial-up line ( so machines in the outside world cannot initiate connections with us ). If an outsider cannot initiated a connection, he can't access your machine. Note that this second-to-last rule will disable normal active-mode FTP connections, requiring you to use passive mode. If this is a problem, you can remove this line at the expense of a reduction in security.

Depending on your preferences, you may wish to remove the lines opening holes for the Telnet, FTP and SSH protocols. If you have hosts.allow set up to restrict access, leaving them open isn't a major problem and does allow you to access your box remotely, a nice feature for those with permanent connections. If you don't intend to remote into your box, you can safely close those holes.

#
# Forwarding rules
#
echo Setting forwarding rules

# Forward within local network without masquerading anything
/sbin/ipchains -A forward -j ACCEPT -s ${lannet} -d ${lannet}
# Masquerade for everything to the outside world
/sbin/ipchains -A forward -j MASQ -s ${lannet} -d ${any}

Finally, the meat of the matter. These are the rules that control forwarding of packets. First off, since we're assuming an Ethernet here where all the local machines can talk to each other directly, the Linux box should never be asked to route between two machines on the local network. The first rule therefore says to refuse to forward any packets between other local machines. This will not affect packets to or from the Linux box itself, since those are not forwarded and forwarding rules do not apply to them. The second line says to masquerade packets between the local network and the outside world. This means that, if other machines send packets to the rest of the Internet, the Linux box will re-write the source address on outgoing packets to appear as if they came from the Linux box, and re-write the destination address on incoming packets back to the machine they originally came from and forward those packets on to the real destination. Yes, there is a lot of deep magic involved in that. If you know enough about networking to handle the explanation without having your eyes glaze over, you probably don't need my help to set this up.

#
# Output rules
#
echo Setting output rules

# Make sure accounting rules get called
/sbin/ipchains -A output -j acct-out

# Never allow things from private network numbers to escape
/sbin/ipchains -A output -l -j REJECT -i ${IFext} -b -s ${privateA}
/sbin/ipchains -A output -l -j REJECT -i ${IFext} -b -s ${privateB}
/sbin/ipchains -A output -l -j REJECT -i ${IFext} -b -s ${privateC}
/sbin/ipchains -A output -l -j REJECT -i ${IFext} -b -s ${loopback}

The input rules were concerned with protecting you from the world. These rules protect the world from you. As I said before, your local loopback network and the private network used by your LAN shouldn't be visible to the world. These rules say that any packets from those addresses that the system thinks should go over the dial-up link to the world should not be sent. This prevents any mistakes you might make in configuration from letting packets with private addresses out into the Internet at large.

#
# Accounting
#
echo Setting accounting rules

# Traffic monitoring rules
/sbin/ipchains -A acct-in  -i lo
/sbin/ipchains -A acct-in  -i ppp0
/sbin/ipchains -A acct-in  -i eth0
/sbin/ipchains -A acct-in  -i dummy0
/sbin/ipchains -A acct-out -i lo
/sbin/ipchains -A acct-out -i ppp0
/sbin/ipchains -A acct-out -i eth0
/sbin/ipchains -A acct-out -i dummy0

These rules make entries for accounting for network traffic. There is one line per network interface, and the packet and byte counts for each interface will be recorded by the rule. These rules don't control the fate of packets, they just count them. You will probably need to edit these rules based on the network interfaces on your machine. On mine, the interfaces are:

• lo - local lookback interface, almost always present.
• ppp0 - dial-up PPP interface.
• eth0 - Ethernet interface to my local LAN.
• dummy0 - dummy interface configured for my static IP address, to insure that my static IP is always usable even when I'm not dialed in.

echo Done
exit 0

These last lines finish off the script.

At this point you should test the scripts. Download both of them and the data file, modify the second as noted above if needed, put the scripts in /etc/rc.d and the sysctl.conf file in /etc and execute the command "chmod a+x /etc/rc.d/rc.iprules*" to make the scripts executable. Run the rc.iprules-boot script once and once only. Then run the rc.iprules script to set up the firewall rules. Test various activities on your LAN, then connect to XMission and test your normal activities there. At the worst, if it interferes with things you can simply log in as root and execute the "/sbin/ipchains -F" commands near the start of rc.iprules to clear out the firewall rules and set everything back to wide open. Since we log all rejected packets, you should have entries in the system log showing any problems.

If all the tests succeeded, add calls to the scripts into /etc/rc.d/rc.local by adding these two lines:

rc.iprules-boot
rc.iprules

There is a useful commands to display firewall statistics:

/sbin/ipchains -L -v -x

This lists the details of each chain and each rule, including the number of packets and bytes matched by each rule or that passed through each chain. You might also want to do a couple of things to keep track of statistics and keep things cleaned up. The first is to add this script to the /etc/cron.daily directory:

#!/bin/sh

outfile=/var/log/ip-accounting

echo "" >>$outfile
echo IP statistics `date` >>$outfile

/sbin/ipchains -L -Z -v -x >>$outfile

exit 0

This will, on a daily basis, dump the counters for the day to the ip-accounting file in the /var/log directory and zero the counters. Call the script anything you want, but make sure to make it executable with chmod a+x script-name or it won't get run. The next would be to go into the /etc/logrotate.conf file and add this stanza:

/var/log/ip-accounting {
        monthly
        rotate 6
        compress
}

This will rename the ip-accounting log file every month, and keep 6 months worth compressed. That will keep the logs from eating up infinite disk space over time.

One last thing. Your Linux box will be fine without any help, since it has direct access to the Internet connection. However, other machines might need some help with some protocols. The problem is that, while the Linux box can masquerade outgoing packets just fine, and can recognize the incoming packets associated with a TCP connection one of your machines initiated readily enough, some protocols like FTP or programs like Quake use either second connections initiated from the Internet back to the originating machine or they use UDP which doesn't have a connection to use as a fingerprint to tie inbound packets back to the correct internal machine. Linux comes with some helper modules that let these protocols and programs work right with masquerading. If you look in /lib/modules/kernel-version/ipv4, you'll find a bunch of modules with names like ip_masq_protocol. A partial list is:

If you want other machines on your network besides the Linux box to use these protocols or programs properly, you can load the appropriate modules into the kernel. In rc.local, right after calling the rc.iprules script, just add a line that says /sbin/modprobe module substituting the name of the module for the protocol in question. Do that for each of the protocols you want working.

At this point, you're ready to reset the system and start routing packets. In RedHat 5.x this could be done without a reboot. Due to the additional setup needed for the Linux 2.2.x kernels in RedHat 6.0, I prefer to reboot the machine to insure that everything gets done in the proper order.

For additional information on masquerading you might want to look at the IP-Masquerade mini-howto located in /usr/doc/HOWTO/mini. There are also others, including ISP-Connectivity. There are also the Firewall-HOWTO and IPCHAINS-HOWTO in the /usr/doc/HOWTO directory. These cover firewalls and ipchains specifically, plus additional software you can use if you feel like setting up a stronger firewall and proxy servers. Other HOWTOs include ISP-Hookup-HOWTO, Intranet-Server-HOWTO and PPP-HOWTO. I have included an HTML version of version 1.0.7 of the IPChains HOWTO. You might also be interested in a few of the O'Reilly books. The book Practical Unix and Internet Security is an excellent general reference on system and network security, and really should be required reading for anyone connecting a significant system like Linux to the Internet. Other useful ones are Essential System Administration and TCP/IP Network Administration. O'Reilly publishes a large line of books, and they are regarded as some of the best references on their subjects. They have a high information density and assume you have a working brain, so don't expect a light read, but they are very informative.

One peculiarity about O'Reilly books: every one has a picture of a different animal or object on the cover. They are so distinctive that many Unix people will recognize the books faster if you say what the cover picture is than if you say the title. Some of the more useful ones are: