Building a Linux firewall
The growth of the Internet has prompted many organizations to become security-conscious. Documented and undocumented incidents of security violations, expanded research about security issues, and even media hype have brought about the potential for at least partial solutions for securing a networked environment—without completely isolating the network from the outside world. Leading the pack of solutions is the firewall. Just about everyone has defined what a firewall is, so I won't be any different. A firewall is a device or collection of devices that restricts the access of “outside” networks to “inside” networks. Not surprisingly, Linux can play a part in this arena.
There are currently three models used to classify firewalls. Fundamentally, the current industry classifications are application proxy gateway, circuit level relay, and packet filter.
An application proxy gateway is what most people think of when they talk about firewalls. Also known as a bastion host, it is used to completely sever the connectivity between outside and inside networks. Connections are made via proxy processes to the bastion host. The bastion host in turn will establish a connection to the real destination and handle communications between the two connections.
There are several advantages to a proxy gateway. First, because the proxies are at the application level, they can take advantage of application protocols. For example, protocols providing authentication—such as TELNET, FTP, and HTTP—can be intercepted at the proxy and stronger authentication mechanisms applied (such as S/Key) without adversely affecting the remote client. Also, protocol-specific rules can be applied by the proxy. A rule can be established that allows FTP GETs through the gateway, but not FTP PUTs. Another advantage is the extensive logging that can be provided at the application level. It is important to note that the bastion performs no IP routing functions. All communications are through proxy processes. The firewall toolkit FWTK, available as freeware from TIS, is an example of a firewall application level gateway.
A circuit-level relay functions in a manner similar to an application proxy gateway, except the proxies employed for a circuit relay are normally not application-aware. Because of this, you lose many of the detailed logging capabilities and precise rule definitions you have in an application proxy gateway. The important concept remains the same in that a connection is established via proxies and IP packets are not forwarded through the firewall. SOCKS is an implementation of a circuit level relay based firewall.
Packet filtering is the most common type of firewall available. It works on the concept of forwarding packets based on rules. Those rules typically take into consideration source and destination IP address, source and destination port numbers, the protocol being transported, TCP flags, IP flags or options, and other information, such as the interface, over which the packet arrived. The primary difference between a packet filtering firewall and the others is IP forwarding. A packet filtering firewall is usually a router, and its function in life is to forward packets. This means that while you can control what machines on the outside can talk to certain machines on the inside (and which applications), you now rely on the application to protect itself from harm. For some applications, this isn't a particularly wise decision. Nonetheless, packet filtering can be very useful, is widely available and typically inexpensive.
A Linux machine can function as any one or as all three (i.e., as a hybrid) of these firewall types) of the firewall types. Without add-ons however, the Linux kernel has the ability to function as a packet filter routing device, using the ipfirewall code written by Daniel Boulet and Ugen J.S. Antsilevich. For most 1.2.x and 1.3.x kernels, the firewall code (ip_fw.c) is based on the port by Alan Cox and Jos Vos. Boulet has released version 2.0e (as of this writing) of his ipfirewall code as shareware. I have yet to install the new release, so any discussion I have is based on the ip_fw.c code—specifically kernel 1.2.13.
In order to use this built-in firewall capability, you need to understand a bit about how TCP/IP works. Trying to set up a firewall from scratch without understanding networking is a sure route to disaster. If you want a “plug and play” firewall solution for Linux, one is mentioned at the end of this article. To learn more about TCP and IP, recommended reading is TCP/IP Illustrated, Volume 1 by W. Richard Stevens. Also, the 3rd edition of Douglas Comer's Internetworking with TCP/IP is excellent bedtime reading.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Mediated Reality: University of Toronto RWM Project
- New Products
- Using Salt Stack and Vagrant for Drupal Development
- Dart: a New Web Programming Experience
- OpenOffice.org Off-the-Wall: ToCs, Indexes and Bibliographies in OOo Writer
42 min 3 sec ago
- Kernel Problem
10 hours 44 min ago
- BASH script to log IPs on public web server
15 hours 11 min ago
18 hours 47 min ago
- Reply to comment | Linux Journal
19 hours 20 min ago
- All the articles you talked
21 hours 43 min ago
- All the articles you talked
21 hours 46 min ago
- All the articles you talked
21 hours 48 min ago
1 day 2 hours ago
- Keeping track of IP address
1 day 4 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?