Notes for Week 10
Firewalls can be:
simple filters or state-specific (incorporating some knowledge of the state of, ie., the
TCP connection, into the filter)
permissive or paranoid - a permissive firewall has a default forwarding policy of acceptance
(which means that all packets not specifically filtered are allowed across the firewall), while
a paranoid firewall has a default forwarding policy of denial (which means that all packets
not specifically filtered are dropped)
A firewall typically has lists of rules affecting packets at one or more points as the packet
crosses the firewall:
At each stage, the list of rules is examined in order, and the first rule whose filter
matches the packet in question is performed; if no rules match, the default policy is
- on input
- when the decision is made to forward the packet to a different network
- on output
We will be using iptables to implement our firewalls. Note that the OUTPUT filter chain applies only
to packets whose source is the firewall system itself. Similarly, the INPUT chain applies only to
packets destined to sockets (software implementation of ports) on the firewall system. All packets whose source and destination are not
the firewall system go through the FORWARD chain only.
Issues to keep in mind are:
knowledge of a host's existence is the first step in hacking the host - never allow
information about which hosts exist or what users log in to those hosts to leave
your network; the obvious exception being servers whose clients are outside of your network
design every filter to be specific in terms of both source and destination, as well
as service, and keep in mind both sides of a conversation - it doesn't do any good to allow
web requests into your network if the responses can't get out
when testing a firewall, test the services you have affected from both directions
(into and out of your network); then test the services which you did not try to affect,
to make sure they behave as desired
use firewall rules to obtain accounting information (packet and byte counts for those
packets which match the filter)
in addition to firewalling services, firewall against pings, SNMP packets and packets coming
from reserved IP addresses (which should never exist on the Internet):
- 0.0.0.0 - 0.255.255.255
- 10.0.0.0 - 10.255.255.255
- 100.64.0.0 - 100.127.255.255
- 127.0.0.0 - 127.255.255.255
- 169.254.0.0 - 169.254.255.255
- 172.16.0.0 - 172.31.255.255
- 192.0.0.0 - 192.0.0.7
- 192.0.2.0 - 192.0.2.255
- 192.168.0.0 - 192.168.255.255
- 198.18.0.0 - 198.19.255.255
- 198.51.100.0 - 198.51.100.255
- 203.0.113.0 - 203.0.113.255
- 240.0.0.0 - 255.255.255.254
Your firewalls rules are in the file /etc/rc.d/rc.iptables, and are configured for usage in the 265 lab:
See /usr/doc/linux-3.13/filesystems/proc.txt for more information on /proc/sys/net/ipv4/.
# Begin rc.iptables
# Insert connection-tracking modules
# Enable Broadcast Echo Protection
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# Disable Source Routed Packets
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
echo 0 > /proc/sys/net/ipv4/conf/default/accept_source_route
# Enable TCP SYN Cookie Protection
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
# Disable ICMP Redirect Acceptance
echo 0 > /proc/sys/net/ipv4/conf/default/accept_redirects
# Do not send Redirect Messages
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
# Drop Spoofed Packets coming in on an interface, where responses
# would result in the reply going out a different interface.
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter
# Log packets with impossible addresses.
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
echo 1 > /proc/sys/net/ipv4/conf/default/log_martians
# Be verbose on dynamic ip-addresses (not needed in case of static IP)
echo 2 > /proc/sys/net/ipv4/ip_dynaddr
# Disable Explicit Congestion Notification
# too many routers are still ignorant
echo 0 > /proc/sys/net/ipv4/tcp_ecn
# Set a known state
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# These lines are here in case rules are already in place and the
# script is ever rerun on the fly. I want to remove all rules and
# pre-existing user defined chains before I implement new rules.
iptables -t nat -F
# Allow local-only connections
iptables -A INPUT -i lo -j ACCEPT
# Allow pings
iptables -A INPUT -p icmp -m icmp --icmp-type echo-request -j ACCEPT
# Allow ssh from instructor's station in 265 lab
iptables -A INPUT -s 192.168.1.150 -p tcp --dport 22 -j ACCEPT
# Permit answers on already established connections
# and permit new connections related to established ones
# (e.g. port mode ftp)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
You will need to add lines to your firewall file (just before the last line)
for each type of service you will accept connections for.
For instance, if you will be providing web service to anyone, add the line
If you will be listening for UDP requests (-p udp), you will of course omit the options
"-m conntrack --ctstate NEW,ESTABLISHED,RELATED" since UDP is not a connection (state) oriented protocol.
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
While this is technically true, in practice both UDP and ICMP "connections" effectively exist as long as there is two-way socket
traffic within a certain time frame. This is important for maximum efficiency on media streaming using UDP, and because
ICMP can be used for error reporting on other connections, it can be treated as a "related" connection.
It is important to realize that our firewall rule
You can update your firewall rules at any time by running /etc/rc.d/rc.iptables because
it flushes the rules before inserting the new ones.
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
can apply to UDP and ICMP packets as well. Therefore it should be at the end of the filter chain.
If you will only be serving to a restricted range of IP addresses, add those restrictions
to your firewall (ie., -s ip-addr/mask) for those ranges you are serving.
Many hack exploits utilize buffer overflows. For instance, a very long GET request is sent to an HTTP server that does not
adequately check incoming message lengths. The long message overflows the buffer which the programmer set aside for
incoming messages, and the overflow data overwrites part of the server program. That data contains machine code which
accomplishes the ends of the hack; usually a large number of NOPs ("no operation", an instruction which executes successfully but
does not do anything) are followed by the attack code, and this is repeated multiple times to increase the chances that the
attack code is executed. Typical hacks are the "apache-scalp" exploit, with a payload of 28898 bytes, and the
"apache-nosejob" exploit, with a payload of 31413 bytes.
The best procedure is to always check that the length of incoming data is appropriate.
But these observations lead us to suspect that firewalling by packet length may also be an effective means of thwarting some exploits:
iptables -A INPUT -p tcp --dport 80 -m length --length max-length+1:65535 -j DROP
Note that the maximum allowable packet length max-length is the length of the IP protocol data unit. Therefore, if you
are using Wireshark to determine the maximum packet length ("frame bytes on wire"), you should subtract 14 bytes for the Ethernet header; that will be
the value you should use for max-length.
Be sure that this rule precedes any rule which might accept an http request. Note that any packet received after the
initial "3-way handshake" (SYN, SYN/ACK and ACK) is part of an "established" connection.
The example was using HTTP; in principle this could be applied to other services (but not all!) as well.
Note that the length firewall rule can sometimes be used as a defense during a distributed denial of service attack (DDoS). Most
packets received during a DDoS attack have either uniform length, uniform time to live (TTL), or both. A similar rule dropping on TTL
would look like:
iptables -A INPUT -p tcp --dport 80 -m ttl --ttl-eq ttl-of-incoming-packets -j DROP
On March 27, 2013, the New York Times reported that Spamhaus was the target of a very nasty (not to mention socially irresponsible) DDoS attack
by clients of Cyberbunker. The attack was directed through the root Domain Name Servers (DNS), which amplified the effect of the attack,
but which also disrupted traffic on the Internet worldwide. Such an attack utilizes IP spoofing, in which a PC sends packets whose
source IP address is the DDoS target. Since very few ISPs (Internet Service Providers) filter out packets which do not come from their registered users
(which itself is just plain lazy), these attacks can be very difficult to deal with: the root DNS servers must
answer requests for the Internet to function. Another way to prevent such an attack is output throttling on the client side; this could be done
with a firewall rule limiting output packet frequency on the DNS source port (53):
iptables -A OUTPUT -p udp --sport 53 -m limit --limit 10/second -j DROP
Adjusting the limit is tricky, since many web pages refer to dozens of servers. Since by design the largest DNS packet is 315 bytes long, this limit would
restrict any given PC to about 25 Kbits/second. The attacks referred to above reached a peak of over 300 Gbits/second, which with throttled clients
would require a botnet of 12 million PCs, a number far in excess of the "thousands" used.
Some things are just a bad idea:
Serving telnet or FTP or anything using unencrypted passwords is just dumb. The
unspeakable corollary is never su over a telnet session.
Serving SMB over the Internet - Microsoft has a history of using easy-to-break password encryption.
If you really need to share files across the Internet, use sftp.
Using any of the RPC services - they provide huge security holes because of their use of hosts.equiv.
- Some generic good ideas:
Don't even let someone know you exist if you don't have to (ie., don't answer ICMPs,
especially broadcasts, don't run a finger or NIS server for external consumption, etc.)
Don't run any software unless you really need it.
Make sure that your software is current; most hacker exploits are fixed as soon as
they are discovered (at least in the UNIX community), but unless you have installed the
relevant fixes you are still vulnerable.
Restrict access to specific IP addresses or ranges of addresses whenever possible.
Many services have the capability to restrict service to a set of static IP addresses (see, for example,
/etc/hosts.lpd, /etc/lpd.perms, /etc/hosts.allow, /etc/hosts.deny, /etc/smb.conf, /etc/nwserv.conf,
/etc/httpd/httpd.conf). Of course it is also possible to implement all of those restrictions
via firewall commands; the down side to that is a little more overhead, the up side is that
all of your restrictions are implemented in one place.
Keep web, e-mail, file service on separate computers (with unrelated root passwords).
That way if one is hacked, the rest may still be safe.
Never use root when you don't have to. Log in as an ordinary user, su to root when
necessary and then exit as soon as possible. You'll get a little more practice typing in
the root password, but you won't accidentally cause as much harm if you do something wrong.
Backup frequently, using multiple generations and offsite storage.
Instead of startx, try startx -- -nolisten tcp (did you know X automatically listens on tcp port
6000? of course, it is configured to not accept any connections, but knowing of the existence
of a PC, ie., through a port scan, is the first step in hacking into it).
Know how to use /etc/services to identify port numbers. Particular ports of interest are:
- 22 - Secure Shell (SSH)
- 25 - Simple Mail Transfer Protocol (SMTP)
- 53 - Domain Name Server (DNS)
- 80 - HyperText Transfer Protocol (HTTP)
- 123 - Network Time Protocol (NTP)
- 137 - NetBios Name Service (NBNS)
- 138 - NetBios Datagram Service
- 139 - NetBios Session Service (NBSS)
- 143 - Internet Message Access Protocol (IMAP)
- 161 - Simple Network Management Protocol (SNMP)
- 194 - Internet Relay Chat Protocol (IRC)
- 220 - Internet Message Access Protocol v3 (IMAP3)
- 389 - Lightweight Directory Access Protocol (LDAP)
- 443 - HTTP over Secure Socket Layer (SSL) (HTTPS)
- 445 - Microsoft DS
- 515 - Print Spooling (LPD)
- 636 - LDAP over SSL (LDAPS)
- 6000-6063 - X Windows
Pay frequent visits to Cert, SANS,
and other sites linked from there.
Read the Mandiant report on APT1.
The most common danger comes not from technology but from human fallibility. Called
"social engineering" or "spear-phishing", the most successful ruse used by hackers attempts to entice users into reading
and acting on e-mails with links to malware. Several things can be done to fight these methods:
The most helpful is to educate your users never to click on links in e-mails. Browsers which display URLs in the status bar
can be useful in showing your users that the link they want to click is not the URL displayed in the e-mail.
Train your users not to open attachments in e-mails; they can transfer files using secure FTP or shared file space.
Configure mail clients to not execute scripts or run plugins.
Firewall output on all ports not specifically necessary for users to do their jobs.
How to tell if you have been hacked:
Keep an md5sum for every critical file on your system, and check them periodically.
Often a simple check like ls -l /bin will
show that some binaries have been modified since you installed your system.
If an ls -al of /
or one of the top level directories shows a hidden directory, it may be part of a rootkit
which the hacker has installed on your system to facilitate his work.
Usually a hacker will
remove traces of his intrusion from your log files, and will install versions of binaries such
as ls, ps and netstat which will hide his tracks.
What to do if you have been hacked:
The bad news is you have to reinstall your entire system. I can't say that
strongly enough. You may be able to find and fix a couple of things that have been
touched, but there are probably a whole host of things which may not be found
for a long time, if at all. Many times, the programs which come out of
the rootkit make it impossible to clean up without reformatting. So the
things to do are:
- unplug the system from all network connections;
- save all of your data (and verify that the saved data has not been compromised);
- re-install the system from scratch;
- prevent this from happening again (see above).
Privacy is difficult on today's Internet. Everyone must make decisions about how private they want to be; you can't have a large
Facebook or LinkedIn presence and expect any privacy. But there are a few things you can do that will help:
- Do not accept third-party cookies in your browser.
- Clear your cookies frequently.
- Do not save any bookmarks on smart phones or tablets which are cloud-aware if you want
your use of them to remain private; most such devices automatically make copies of your bookmarks on their cloud
- Erase cache files every time you quit your browser (i.e., .cache/*).
EXERCISE for Week 10:
Use iptables -L -v to examine the firewall configuration you are currently operating.
Modify your firewall configuration to allow ICMP echo requests only from other PCs on your island,
and from the instructor's station.
Use nc to port scan the computers on your island. Try nc -z -v -w1 ip-address
1-1023 for starters.
You might want to try a wider port range (see /etc/services).
Use netstat --ip -apn to find out which internet sockets are in use on your system, and by whom.
Compare the port designations to those in /etc/services. Which ones are dynamic client-side ports?
Compare the output with that of
cat /proc/net/tcp and cat /proc/net/udp.
©2015, Kenneth R. Koehler. All Rights Reserved. This document may be freely reproduced provided that this copyright notice is included.
Please send comments or suggestions to the author.