EZ Firewalling & Routing
- What Is A Firewall?
- Netfilter: IPTables
- Clearing Tables
- LAN-Node Needs
- Router/Server Needs
- @ IPTABLES HOWTO:Linuxguruz.org
- @ "Firewalling with Netfilter/Iptables", Knowplace.org
- "Learning the bash shell", Newham/Rosenblatt:O'Reilly
- "Linux Installation and Configuration", LeBlanc/Yates:CoriolisOpen Press
This tip applies largely to RedHat/Fedora-based installations, your mileage may vary. You must already have a working network; that is, you can successfully ping all the hosts on your LAN, and have a route to the Web through a gateway (see also, SOHO Networking).
What Is A Firewall?
Being connected to the world has its advantages and its drawbacks. The biggest drawback is that you are opening a portal through which sociopathic techno-deviates can instigate a plethora of naughty, destructive and downright illegal acts, sometimes without your ever even knowing they were (are) there. According to a Dec/2004 article on pcauthority.com.au, a two-week test of six out-of-the-box systems by marketing communications firm AvanteGarde showed that poorly protected OSs get hacked for remote use very quickly. Some, like WindowsXP, in as little as 30 seconds connected to the internet. The best performer (most secure - never compromised!) was a PC running un-modified Linspire Linux. That's because 1) Linspire comes pre-configured with a good firewall, and 2) [crackers] have tunnel vision regarding Windows. It goes without saying that, had the crackers really been trying, the one open port on the Linspire-enabled machine may have eventually been exploited.
A "firewall" is an insulating shield of some strength that keeps the heat on the right side - out. It gets its name from the firewall of a car, whose purpose is to shield the passengers from the dirty, noxious engine compartment. An operating system's (OS) firewall performs a "quality control" check on information packets entering and leaving processes running on the OS.
When asked how he was going to produce 100% defect-free cars, Volkswagon America's first General Manager replied, "We're not going to let anything bad into the factory." What he instituted was a radical method: 100% inspection of every single part coming into the factory. That is how we are going to protect our server's users - by not letting anything bad enter our processes, by inspecting 100% of the incoming data packets. There are two types of firewalls: stateless and stateful. Session-based hookups like virtual private networks (VPN) require special firewalls to handle states of sessions. We will build a stateless firewall for home use, where all you need is outgoing email, messaging and Web access from machines on your private LAN.
IPTABLES is the preferred firewalling scheme on Linux kernels 2.4.x and up. See the IPTABLES HOWTO to get it going if you do not have this kernel. On RedHat 7.1 and up, simply invoke "ntsysv", select iptables to startup at boot, turn off ipchains, and reboot.
Processes on our OS receive inputs (data packets), perform operations on the input data or just forward data to another process, and cause data outputs. Processes are things like browser applications, FTB and Web servers, SSH servers, print servers, and mail programs, for example.
Outside the processes, data streams are cut up into into "packets" or discrete bundles, like cars in a train. Each packet is enclosed in a wrapper that defines what protocol (TCP, UDP, ICMP) it is formatted for, what time it was originated, where it is from, and where it is going.
At its perimeter, a net process looks like this:
_______ | | -->[Routing ]--->|FORWARD|------->--> [Decision] |_______| ^ | | v ______ _____ | | | | |OUTPUT| |INPUT| |______| |_____| _____________ ^ | | | | +---->|Local Process|----+ |_____________|
The process is connected to the data stream by three "chains" through which data packets either flow into and out of, or around the process. These chains are lists or tables of rules and filters that sift packets for certain criteria (protocol, source, destination), and act on the packets if needed (policy).
For example, if the policy of the input chain is "DROP", all packets will be dropped on the floor unless there are rules which temporarily change that policy to "ACCEPT".
"REJECT" does the same as DROP, but also sends a message to the originator telling him his data was rejected.
Initially, if you have not set up a firewall or have not had one set up during installation of your Linux distribution, your three basic chains will have no rules and will all have policy set to "ACCEPT" -- a dangerous condition. To find out what is in your chain tables, ask IPTABLES to list its rules:
# iptables -L
Which, at this point, should list:
Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
If this not what you get, then there may be a firewall active, and you should find out what is generating it, and turn it off. If you do not want to do that right now, you can ignore it, clear all the tables and get to our starting point, above, by issuing these commands to flush all rules and set the basic policies to ACCEPT (a wide-open firewall!):
# iptables -F # iptables -P INPUT ACCEPT # iptables -P FORWARD ACCEPT # iptables -P OUTPUT ACCEPT
We can set the input chain policy to DROP using this rule:
# iptables -P INPUT DROP
No data can enter any process on our OS now. If we do the same for forward:
# iptables -P FORWARD DROP
Now no packets can be routed through our firewall, but we can still send packets out. We have pretty much locked ourselves away from harm. If no further rules are implemented we have what I would call a "medium" firewall, because there are still some holes here and there not covered by IPTABLES. Unfortunately, with this set of policies and no specific routing rules, you cannot use your LAN for much productive work. For instance, you cannot FTP or SSH to your server.
For a laptop or other workstation that is not going to be routing packets for other hosts (computers), you can set up a pretty safe firewall with these commands.
These three rules explicitly set the basic policies, as before:
# iptables -P INPUT DROP # iptables -P OUTPUT ACCEPT # iptables -P FORWARD ACCEPT
These two allow only folks on our local network to SSH into us (port 22), and access our Apache web server on the standard port 80:
# iptables -A INPUT -i 192.168.1.0/24 -p TCP --destination-port 22 -j ACCEPT # iptables -A INPUT -i 192.168.1.0/24 -p TCP --destination-port 80 -j ACCEPT
This one allows us (lo) to access the Apache server on our own machine:
# iptables -A INPUT -i lo -p TCP --destination-port 80 -j ACCEPT
This last one is important - it accepts all packets which are being returned on connections WE originated to outside entities. This allows us to surf the web, and stuff like that:
# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
I like to put these in a shell script that can be used manually or from other scripts to start/stop/restart the firewall. For a non-routing workstation or laptop, put this rc.firewall script into your /etc/rc.d directory as "rc.firewall". Adjust the variables to suit your environment. chmod 755 the script to permit execution.
|IPTABLES||where the "iptables" command is located, in RedHat, "/sbin/iptables"|
|WAN_IFACE||the incoming interface used to connect to the world, e.g., "eth0" for your ethernet, "wlan0" for your wireless|
|WAN_IP||your fixed ip address|
|LAN_IFACE||your outgoing network card (in this case I only have one, so it is the same as my WAN)|
|LAN_IP||the network address and address range of your LAN|
(There are a couple of other commands in the script to prevent common naughty uses of un-suspecting machines.) Then you can add this line to your /etc/rc.local file to execute it on boot to start up your firewall at boot time:
Here is a more elaborate and effective firewall script from Linuxguruz.org that I use on my router/server to isolate my LAN from the modem connection, but which allows all normal LAN-originated traffic in and out. There are numerous special cases addressed to prevent various kinds of explicit attacks. I leave it to the reference sources I listed above to give you the whys and wherefores.
- You cannot get anywhere
- Issue the command "iptables -L" and inspect your rules. Clear your tables (see "Clearing Tables") and try connecting. If you can connect with empty tables, then you either made a typo or an error in setting IP addresses, or some such thing. Recheck your work, as they say in school.
- Your script will not execute
- You didn't chmod 755 the script.
Most of this I learned at Linuxguruz.org