Building a Linux firewall
Even with generic tables to work with, you may not always get the rules the way you want them. It's nice to be able to check your work. The ipfwadm utility offers the -c option to check packets against your rules. For example, to check if a packet from some host can send mail to an internal host other than warbird, we can run:
# ipfwadm -F -c -P tcp -S >188.8.131.52 1024 \ -D 192.168.1.5 25 -I 184.108.40.206
This would yield the response packet denied. When using -c to check a rule, you need to be very specific and supply a source address and port, destination address and port, and an interface address.
The other way to test your environment is with live traffic. If you suspect traffic is not being forwarded because of your ruleset, you can use tcpdump to monitor the traffic coming into and going out of the firewall. It becomes fairly obvious if the firewall is not allowing legitimate traffic to go through. For example, when I set up the rules to allow mail through, I noticed it took an exceptionally long time to send a message. tcpdump revealed that the receiver, mccoy in this case, was sending IDENT messages back to the source but they were being blocked by the firewall. By adding a rule to allow IDENT messages, mail went much faster. Creating this rule is left as an exercise for the reader.
For rudimentary logging, a rule may be set with the -k option, which will cause the kernel to print out a message via syslog for all matching packets. However, setting up the kernel to understand the -k option is not straightforward. The kernel needs to be compiled with CONFIG_IP_FIREWALL_VERBOSE defined. To do this, just add the definition to the Makefile in the net/inet directory in the kernel source directory. Unfortunately, the code defined in the CONFIG_IP_FIREWALL_VERBOSE section of ip_fw.c does not compile cleanly in 1.2.x distributions. The fix is simple and implemented in the latest 1.3.x versions of the kernel.
If you set up the kernel to support the -k option you will receive output in the /var/adm/messages file similar to that shown in Figure 9.
The firewall we just built can be replaced by almost any router you can purchase from a vendor. However, turning a Linux machine into a packet filtering router is a cheap and very effective alternative.
There are several limitations to the firewall code. Its inadequate logging capabilities are a big miss; documentation is lacking; and the inability to filter on IP options do not allow the filtering router to be as flexible as it might be.
For many environments, the firewall facilities of the Linux kernel can be more than sufficient, but for those who need commercial-grade firewall software for Linux, or software that can run under Linux, there are solutions. The shareware ipfirewall code from Daniel Boulet, mentioned earlier in this article, addresses several of the problems just stated. Also, the commercial Mazama Packet Filter from Mazama Software Labs is a real “bells and whistles” product. It comes complete with nice documentation, a filter “language” for defining the rulesets (this is a winner), a GUI for very simple administration, and fixes for the technical problems (such as IP options and TCP SYN/ACK filtering).
One last concept not mentioned in this article is that of IP Masquerading. Very perceptive readers will notice the network warbird is on (192.168.1.0) is a private IP address. That is, it not one assigned by the InterNIC, but can be used for local or private IP-based networks not connected to the Internet. I can get away with using this addressing scheme because the machine called relay is a commercial firewall that performs masquerading (otherwise known as address hiding). All connections going out of the 20.2.51 or 192.168.1 networks have a source address of relay from the perspective of the remote machine. As you might be able to guess from its name, relay is also an application proxy gateway. Linux also has the ability to hide addresses, but that is a topic for another article.
Chris Kostick (email@example.com) is a Senior Computer Scientist at Computer Sciences Corporation's Network Security Department. He enjoys working with Linux but considers himself a latecomer because he started out at kernel version 1.1.18. As far as computers go, he's not sure if he has more fun debugging TCP/IP problems or playing Doom.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Parsing an RSS News Feed with a Bash Script
- Tips for Optimizing Linux Memory Usage
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- SourceClear Open