Notes for Week 1

First, a few things to do to get our system environment ready to work:

  1. your instructor will tell you which partition to boot into - always use this partition
  2. login as root
  3. password is lab265
    this is necessary for the instructor to be able to help you with problems - never use a password this simple on a working system
  4. startx
  5. right-click on the desktop and choose "Exit"; click the "Save State" box
  6. krkfixwm
    this fixes a few minor problems with the window manager
  7. edit .xinitrc and remove the "xclock" line
    this will prevent you from having two clocks
  8. useradd -m yourname
  9. passwd yourname
    choose a password that is at least 8-12 characters long, with both upper and lower case letters and numbers, and that you will remember without having to write it down
  10. cp -a GNUstep .xinitrc /home/yourname
  11. chown yourname:yourname /home/yourname -R
    these last two steps will make your X-windows environment the same as root's
  12. logout
  13. log back in as yourname
  14. startx

From this point on you will always log in as yourname, and use the su command to become root when it is necessary. Take some time to explore your X-windows environment; try seamonkey, wprefs, endeavour2, xterm and emacs. To shutdown, exit X-windows and CRTL-ALT-DEL.

  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)

  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

    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)

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

modprobe ip_tables
modprobe iptable_filter
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ipt_state
modprobe ipt_LOG

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

echo "0" > /proc/sys/net/ipv4/tcp_ecn
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
echo "1" > /proc/sys/net/ipv4/tcp_syncookies
echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
echo "0" > /proc/sys/net/ipv4/conf/all/send_redirects
echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
echo "1" > /proc/sys/net/ipv4/conf/all/log_martians

iptables -F
iptables -X
iptables -Z
iptables -t nat -F

iptables -P INPUT    DROP
iptables -P FORWARD  DROP
iptables -P OUTPUT   ACCEPT

iptables -A INPUT  -i lo -j ACCEPT

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

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
    See /usr/src/linux-2.6.16.27/Documentation/filesystems/proc.txt for more information on /proc/sys/net/ipv4/.

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

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

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

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

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

  10. EXERCISE for Week 1:

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

©2008, 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.