Today we will examine firewalls and NAT in Linux.
The first thing we need to do to learn about how Linux manages a firewall is to disable it and start from scratch. We will use the provided GUI to do this. From a shell, enter system-config-securitylevel (you will need to be root). Or from the desktop go to "System" > "Administration" > "Security Level and Firewall" and enter your password if you are not logged in as root.
Disable the firewall.
RHEL/Fedora uses NetFilter/iptables to filter packets (firewall). We will use the 'iptables' program, which is found in /sbin/ on our systems, to make filtering rules. It would be helpful to first scan the man-pages for iptables. /sbin/iptables will edit the file at /etc/sysconfig/iptables for us, which holds the rules. It is not recommended to edit this file manually.
Do /sbin/iptables -L to look at the current rules. Since we disabled the firewall, the default chains (FORWARD, INPUT, and OUTPUT) should be cleared of all rules controlled by the security level tool. For this part, make sure your browser isn't using a proxy. Refer to lab 9 if you forget how to do this. Become root.
Let's add a rule.
/sbin/iptables --append OUTPUT --protocol tcp --destination
www.lafayette.edu --jump DROP
(the long options are used to clarify what is going on)
This will drop all outgoing tcp packets with destination www.lafayette.edu. Instead of using Squid as a proxy to deny access to www.lafayette.edu, our firewall justs drops the packets. Notice that the browser will wait for a response and eventually time out.
Let's add that same rule, but REJECT instead of DROP, and insert it at the top of the chain. As the man-pages say, we traverse a chain from top to bottom until a definitive target (not ACCEPT) is reached, or until the chains end. Placing our new rule at the top of the chain will ensure that a packet to www.lafayette.edu will be REJECTed and not DROPped. Take notice of the browser's error message now.
Google is a bit harder to block, because its domain has multiple hosts.
/sbin/iptables --append OUTPUT --protocol tcp --destination www.google.com --jump DROP
This should stop packets from going to all IP addresses for www.google.com that our DNS server knows about. Use 'host' to compare the IPs to what our new rule shows.
Try 64.233.169.99 from your browser. We can only block the IPs we know of, so if our DNS results ever change, we will not be protected from Google.
Let's clean up that mess by flushing the OUTPUT chain. Check the man-pages for syntax. Go ahead and enable the firewall and take a look at the rules it sets up.
We will use another (non-red, non-grey) ethernet cables to wire our machines, since they have a connection to the local DHCP server. One person should be the NAT server and the other should be the client.
Server:
The server must have two network connections. One adapter should be
connected to the Internet via the regular gray cable, and the other
should be connected to the additional line. For most cases in the lab,
eth0 will be the embedded NI and eth1 will be the external NIC.
For consistency,
connect the built-in adapter to the Internet and external adapter to
the additional cable.
Do /sbin/ifconfig
If the NAT machine is not wired correctly, ifdown the interfaces
and make
the proper connections.
Restart the network connections: /etc/init.d/network restart but
verify with route that the gateway in use is the right one (if
not, you'll need to ifdown and ifup the
Internet-connected interface so
that it is the last one to assign your gateway).
Client:
You will only need to connect to the NAT machine via the
local cable. Do not connect to the internet.
ifdown and disconnect the Internet connection.
Server:
Now that your networking is functional, take a look at the
IP
Masquerading instructions at the Linux Documentation Project. In
particular, we will be using section 3.4.1 -- Configuring IP Masquerade
on Linux 2.6.x and 2.4.x Kernels. Copy the sample firewall code
rc.firewall-iptables into /etc/rc.d/rc.firewall-iptables (make sure you
didn't wrap any lines!) and chmod 700 so that it is executable.
We need to make slight changes to this script. First, find your path to iptables, it should be /sbin/iptables. Make sure the proper path is defined near the top of the script. Also, check that EXTIF and INTIF are set correctly for your machine. EXTIF is the external facing interface (the Internet), while INTIF is the internal facing interface (the local network, 192.168.x.x).
Go ahead and run the script. This will change your existing firewall. Notice that the chain RH-Firewall-1-INPUT no longer has any references. The script will configure the kernel using the iptables modules for IP masquerading. If you want these changes to persist after reboot, you should add the rc.firewall-iptables script to the proper run-level startup script(s).
Client:
You need to set the NAT machine as your gateway. Get the local network
IP of your partner's machine and use a route add ... command to
add the default gateway. Remove any old gateway, route del ... ,
if necessary.
Now the client should be able to access the Internet through the NAT server. To verify this, first telnet to some EECS machine (128.180.120.x) on port 25. If you get through to Sendmail, we are set up correctly. If DNS is working, you could also try telnet www.lehigh.edu 80 . Now try using your browser to surf the Web.
Troubleshooting:
Make sure you have appropriate DNS servers in /etc/resolv.conf
Remove hardware addresses from /etc/sysconfig/network-scripts/ifcfg-ethX
to be able to use ifdown and ifup (only if they give you errors).
Use Ethereal to get a closer look at what is being forwarded out.
For the next part, allow the SSH service through your firewall.
Sometime in 2005, brute-force dictionary attacks on SSH services became widespread. Here is an example of failed ssh attempts in one day on Prof. Davison's machine. There are several ways to solve this problem. If you have iptables > 1.3.5 you can use the 'recent' module and make rules with iptables that will stop the problem. Our RHEL systems do not have a new enough version of iptables.
Note: It is a good idea to deny remote access to the root account. You can do this by setting the PermitRootLogin to 'no' in the sshd configuration file, /etc/ssh/sshd_config . It may also be beneficial to change the operating port of your ssh service to something other than 22.
We will stifle the SSH attack problem by running a program called fail2ban that can continuously monitor our ssh log file, /var/log/secure . If too many failed attempts are made within a certain "find time", the offending IP will be banned for a predetermined period of time.
Follow these instructions to get fail2ban up and running.
Now get an address blocked by using ssh from some other machine to connect to your system.
Check log at /var/log/fail2ban.log
Here are some more sources on this type of SSH attack, if you are interested.
In order to sign the lab completion sheet, you will need to: