Notes for Week 1

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:
1. on input
2. when the decision is made to forward the packet to a different network
3. on output
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:
- 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)

Your firewalls rules are in the file /etc/rc.d/init.d/firewall, and are configured for usage in the 265 lab:

#!/bin/sh

# Insert connection-tracking modules (not needed if built into the kernel).
modprobe ip_tables
modprobe iptable_filter
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ipt_state
#modprobe ipt_LOG

#flush the tables (so this script is reusable)
iptables -F

# set a sane policy:    everything not accepted > /dev/null
iptables -P INPUT    DROP
iptables -P FORWARD  DROP
iptables -P OUTPUT   DROP

# allow local-only connections
iptables -A INPUT  -i lo -j ACCEPT
# free output on any interface to any ip for any service (equal to -P ACCEPT)
iptables -A OUTPUT -j ACCEPT

# permit answers on already established connections
# and permit new connections related to established ones (eg active-ftp)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -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

# Log everything else:  What's Windows' latest exploitable vulnerability?
#iptables -A INPUT -j LOG --log-prefix "FIREWALL:INPUT "

# be verbose on dynamic ip-addresses     (not needed in case of static IP)
#echo 2 > /proc/sys/net/ipv4/ip_dynaddr

# disable ExplicitCongestionNotification - too many routers are still ignorant
echo 0 > /proc/sys/net/ipv4/tcp_ecn

echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo "1" > /proc/sys/net/ipv4/tcp_syncookies

You will need to add lines to your firewall file (after 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 state --state NEW,ESTABLISHED,RELATED -j ACCEPT
```
You can update your firewall rules at any time by running /etc/rc.d/init.d/firewall because it flushes the rules before inserting the new ones.

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.

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 /etc/services, and keep a note of well known ports that are not listed there.
- Pay frequent visits to Cert, SANS, Snort and other sites linked from there.

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

EXERCISE for Week 1:
1. Modify your firewall configuration file so that the policy definition commands immediately follow the flushing of the tables (as shown above). This will prevent accidental entry when you run the firewall script.
2. Modify your firewall configuration to allow ICMP echo requests, but only from other PCs on your island, and from the instructor's station. The iptables commands will require the operand
  -p icmp --icmp-type echo-request
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).

Please send comments or suggestions to the author.