UNIX System Administration Handbook - Evi Nemeth [198]
ipchains -A input -i ppp0 -s 10.0.0.0/8 -j DENY
To block TELNET access from the Internet (to port 23) but allow mail and SSH connections (to ports 25 and 22, respectively), we would use rules such as these:
ipchains -A input -i ppp0 -p tcp --dport 23 -j DENY
ipchains -A input -i ppp0 -p tcp --dport 25 -j ACCEPT
ipchains -A input -i ppp0 -p tcp --dport 22 -j ACCEPT
We end the input chain with a rule that forbids all packets not explicitly permitted. It might be interesting to see who is knocking on our door from the Internet, so we add a -l flag after DENY to log all the packets rejected by this rule.
ipchains -A input -i ppp0 -j DENY -l
Finally, we set up IP masquerading (aka NAT, aka PAT) to disguise the private address space used on the internal network 192.168.1.0/24:27
ipchains -A forward -i ppp0 -s 192.168.1.0/24 -d ! 192.168.1.0/24 -j MASQ
Here, we have specified in the matching criteria that the source address must be internal but the destination address must be external (the ! negates the sense of the test) in order for IP masquerading to occur. Internal traffic that happens to pass through this host is not affected.
Since Linux implements PAT rather than true NAT (see the footnote on page 327), it’s not necessary to specify a range of external addresses to be used on the Internet. The Linux gateway uses its own IP address for all external traffic and uses port numbers to multiplex connections from multiple interior hosts.
Once you get used to its notation, ipchains seems like a reasonable way to describe firewall rules, but mixing NAT into the same mechanism seems messy. More examples of ipchains firewalls are available at www.wiley.com/compbooks/sonnenreich.
It is rumored that ipchains will go away in Linux kernels after 2.2 and be replaced by a new filtering mechanism.
PPP configuration for Red Hat
Red Hat uses the same PPP implementation as FreeBSD (the kernel version, not the user version), and it is configured identically. Rather than repeat that description here, we refer you to the FreeBSD PPP configuration section beginning on page 337.
Networking quirks for Red Hat
Unlike most kernels, Linux pays attention to the type-of-service (TOS) bits in IP packets and gives faster service to packets that are labeled as being interactive (low latency). Jammin’! Unfortunately, brain damage on the part of Microsoft necessitates that you turn off this perfectly reasonable behavior.
All packets originating on Windows 95, 98, NT, and 2000 are labeled as being interactive, no matter what their purpose. UNIX systems, on the other hand, usually do not mark any packets as being interactive. If your Linux gateway serves a mixed network of UNIX and Windows systems, the Windows packets will consistently get preferential treatment. The performance hit for UNIX can be quite noticeable.
You can turn off TOS-based packet sorting when you compile the Linux kernel. Just say no to the option “IP: use TOS value as routing key.”
When IP masquerading (NAT) is enabled, it tells the kernel to reassemble packet fragments into a complete packet before forwarding them, even if the kernel must immediately refragment the packet to send it on its way. This reassembly can cost quite a few CPU cycles, but CPUs are fast enough now that it shouldn’t really be an issue on modern machines.
Linux lets you change the MAC-level addresses of certain types of network interfaces. We consider this a bug. Don’t do it.
13.15 NETWORK CONFIGURATION FOR FREEBSD
FreeBSD has all the latest goodies in its networking arsenal: two firewall packages (including NAT), two PPP implementations, support for T/TCP (a somewhat successful attempt to make web connections more efficient), and more.
You perform most FreeBSD network configuration by setting the values of variables in /etc/rc.conf. The system startup scripts also read /etc/defaults/rc.conf, which sets the defaults for most variables. You can also create an /etc/rc.conf.local file for host-specific parameters.
These three files are really just