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-firewall (you will need to be root). Or from the desktop go to "System" > "Administration" > "Firewall" and enter your password if you are not logged in as root.
Disable the firewall if you have not already done so. (Note that the GUI is pretty nice; the drawback is that it might not be present in the next version. See this page to see the many GUI system admin tools that were dropped when RHEL moved from version 5 to 6.)
RHEL/CentOS uses iptables to modify and 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.
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 (and
they are different depending on where you are in the internet).
/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 74.125.141.105 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 ethernet cable to wire our machines, since they should 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 cable (the on-board
ethernet which should be there by default), and the other
should be connected to the additional ethernet cable. For most cases in
the lab,
eth0 will be the embedded NIC and eth1 will be the external NIC, but in
some cases they may have different names (e.g., eth2 and eth3).
For consistency,
connect the built-in adapter to the Internet and external adapter to
the additional cable.
Run /sbin/ifconfig and look to see which IP address is assigned to each device. If the NAT machine is not wired correctly, use an option for ifconfig to disable 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 disable and re-enable 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.
Use ifconfig to disable the original Internet
connection interface and then unplug the cable.
(Note that you'll
need to reconnect the cable when this lab is complete.)
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. 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 (or ip
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 CSE/ECE 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
Use Wireshark 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.
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 mildly beneficial to change the operating port of your ssh service to something other than 22 in a real deployment if you want to avoid attackers.
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 and repeatedly fail to provide a valid password.
Check for entries in the system log once the remote ssh is unable to give a password.
Here are some more sources on this type of SSH attack, if you are interested.