Notes for Week 10

  1. Firewalls can be:

  2. A firewall typically has lists of rules affecting packets at one or more points as the packet crosses the firewall:

    1. on input

    2. when the decision is made to forward the packet to a different network

    3. 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.

    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 performed.

    Issues to keep in mind are:

  3. Your firewalls rules are in the file /etc/rc.d/rc.iptables, and are configured for usage in the 265 lab: 
    #!/bin/sh
# Begin rc.iptables
# Insert connection-tracking modules

modprobe nf_conntrack
modprobe xt_LOG

# 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 -F
iptables -X
iptables -Z
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
    See /usr/doc/linux-3.13/filesystems/proc.txt for more information on /proc/sys/net/ipv4/.

  4. 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 
    iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
    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.
    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
    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.
    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.

  5. 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.

  6. 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

  7. 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.

  8. Some things are just a bad idea:

  9. Some generic good ideas:

  10. 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:

  11. How to tell if you have been hacked:

  12. 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:

    1. unplug the system from all network connections;

    2. save all of your data (and verify that the saved data has not been compromised);

    3. re-install the system from scratch;

    4. prevent this from happening again (see above).

  13. 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:

  14. EXERCISE for Week 10:

    1. Use iptables -L -v to examine the firewall configuration you are currently operating.

    2. Modify your firewall configuration to allow ICMP echo requests only from other PCs on your island, and from the instructor's station.

    3. 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).

    4. 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.