Section 16.4 Using PortSentry to Lock Out Hackers

   


16.4 Using PortSentry to Lock Out Hackers

graphics/fourdangerlevel.gif

PortSentry is Psionic's Intrusion Detection System (IDS) that also can act as an Adaptive Firewall. It is an excellent product that I have used with great success for several years. Though it is not GPL'ed, individuals and companies may install it for internal use. It allows you to monitor a user-configurable list of TCP and UDP ports for attempted access by possible crackers. When a cracker touches one of these monitored ports, a variety of actions can be taken, including notifying you of what system touched what port and locking that system out of your network either temporarily or permanently.

It is capable of detecting stealth attacks, such as the common cracker technique of sending the initial TCP SYN packet, waiting for a SYN-ACK to indicate that a process is listening on the port, and never sending the third packet of the initial TCP three-way handshake, the ACK packet. As in physics, two objects may not occupy the same space. Therefore, you will not want PortSentry listening on a port where a "real" server will be bound to on the same system. An invocation of PortSentry can listen to either TCP or UDP ports in one of three modes:

  1. Basic port-bound mode (-tcp or -udp). PortSentry will bind to the specified list of ports and listen for connections and react. Because the Linux or UNIX kernel will handle the initial three-way handshaking for TCP, this method will not detect stealth TCP scans or various other stealth scans, such as the FIN, Null, or Xmas scans.

  2. Stealth scan mode (-stcp or -sudp). PortSentry will open a raw socket to listen in Promiscuous mode and trigger if any port in the listed ranges is attacked. Stealth scans will be detected.

  3. Advanced stealth scan mode (-atcp or -audp). PortSentry will open a raw socket to listen and trigger if any port within the specified range that does not already have a process listening on it is attacked. Stealth scans will be detected. The advantage of the advanced stealth scan mode over the previous mode is that it will detect crackers guessing client-side random high port numbers that might be open, in the hope of hijacking existing connections. It also is very sensitive, some might call it a hair trigger if a suitably large range of ports is specified. Another advantage is that crackers will see the port as closed or filtered, not open as would be the case with Basic TCP mode.

    The downside is that it allows a cracker to do a DoS attack by specifying a spoofed source address. While PortSentry's limited documentation expresses great concern about this, unless you are a very well-known site, this is a very unlikely prospect. It may happen unintentionally to internal users on rare occasions (every few months) but this requires only restarting PortSentry.

Most SysAdmins will find advanced stealth mode to be most suitable and will want to run both a TCP and a UDP version. It will detect full connect(), SYN (Half open), FIN, XMAS, NULL, any other TCP scan, and all UDP scans, except small fragments. (Your firewall should be configured to defrag all packets to protect against fragmentation attacks, as discussed in "Fragmentation Attacks" on page 389.) The two stealth modes are available only on Linux at this time, according to the documentation.

PortSentry will notify you of an attack by using the syslog facility; this assumes you will see the log file in a timely manner, notice the problem, and react. Psionic's Logcheck (now LogSentry) program works well for this purpose, with the limitation that it must be invoked manually every hour or so and can have false positives. It was covered in depth in "Using Logcheck to Check Log Files You Never Check" on page 608. An alternative is to use PortSentry's KILL_RUN_CMD capability to cause it to send you e-mail immediately upon its detecting an attack. PortSentry also offers the very valuable Adaptive Firewall capability by interfacing with IP Tables, IP Chains, TCP Wrappers, or by invoking any user-specified command specified in KILL_RUN_CMD. This can be used to have it interface with the Cracker Trap, as discussed in "Using PortSentry with the Cracker Trap" on page 579.

Normally, when running on a firewall, PortSentry will detect only attacks against the firewall itself or broadcast destinations that include the firewall. However, port redirection may be used on the firewall to redirect packets destined for the monitored ports on other systems back to the firewall to allow PortSentry to react. This redirection technique is explained in "Trapping Server Attacks with Port Redirection" on page 575.

The latest version of PortSentry may be downloaded from Psionic's Web site:

www.psionic.com/abacus/portsentry/

To install the downloaded 1.1 version, do the following:

 
 tar -xzovf portsentry-1.1.tar.gz cd portsentry-1.1 

Have a look at the LICENSE and README* files. Improvements in the 1.1 version include support and bug fixing for the 2.4 kernel and IP Tables and netmask support. The README.COMPAT file lists the compatible platforms, which include Linux and popular versions of UNIX, and OSX for the Mac.

Follow these steps to configure and invoke PortSentry:

  1. Edit portsentry_config.h. If any of these are not to your liking, now is the best time to change them. Most people have no need to change them. The /etc/hosts.deny file only is used if you have selected TCP Wrappers for the Adaptive Firewall option instead of more effective methods, such as IP Tables. If you want to get fancy, you could change the SYSLOG_FACILITY setting from LOG_DAEMON to, perhaps, LOG_LOCAL0, edit /etc/syslog.conf to place these messages in a separate file and monitor them more carefully. While "An Example for Automatic Paging" on page 620 explains how to do this, a better solution would be to use KILL_RUN_CMD to generate e-mail to your pager.

  2. Edit portsentry.conf. It is not a shell script but similar rules apply in that lines beginning with the # character and blank lines are comments and a = is used to assign a quoted value to a variable. You will want to specify what TCP and UDP ports to trigger on and what action to take. While this file is reasonably well-commented, it is important to note that PortSentry only will use the variables that apply to the mode of protection selected by command-line flags. It has commented out suggested values that form a good starting point for customizing it for your site. You may need to adjust these, depending on what services you offer on your system. If it will be running on the firewall, you probably offer only SSH and Ident.

    If you are using basic port-bound mode or the stealth scan mode then you will need to set the TCP_PORTS variable to list the TCP ports on which to listen for attacks, and you will need to set the UDP_PORTS variable for UDP ports. This is a comma-separated list; spaces and tabs are not allowed. Only the basic mode actually will bind to these ports. The stealth mode will open a raw socket, analyze all incoming traffic containing this system's destination address (and broadcast packets), and react to those in the port list. If you select the basic mode, there is a limit on the number of open ports. On Linux 2.2 and 2.4 kernels, this limit normally is 1024 open files. On many UNIX systems, it is 64 per process, including any regular files and standard I/O devices that are open.

    If you will be using advanced stealth scan mode, a different set of variables are used to list the ports. This mode allows listening on a large range of ports that can number in the thousands because it does not bind to the individual ports. For this, list the highest port number to monitor with the ADVANCED_PORTS_TCP and ADVANCED_PORTS_UDP variables. List the ports to ignore, either because you will have a real service on them or because you want to ignore the chatter on them, using the ADVANCED_EXCLUDE_TCP and ADVANCED_EXCLUDE_UDP variables. While the documentation gives dire warnings about listening on ports above 1023, I have not found this to be a problem. Of more importance is the fact that a number of vulnerable and commonly attacked services are above this number.

    I prefer the advanced stealth mode to the others and find that the following works well on a firewall:

     
     #Watch 1080 for socks, 2049 for NFS, and 6000 for X" ADVANCED_PORTS_TCP="6010" ADVANCED_PORTS_UDP="1024" # Default TCP Ident and NetBIOS service ADVANCED_EXCLUDE_TCP="113,139,37" # Default UDP route (RIP), NetBIOS, DHCP, NTP, bootp broadcasts. ADVANCED_EXCLUDE_UDP="520,138,137,67,123,37" 

    The IGNORE_FILE variable's named file lists hosts whose packets you want to ignore completely. If you will be blocking attackers, these will be systems you trust a lot (both the honesty of their SysAdmins and their ability to resist being breached) that need access through your firewall. These might include the SysAdmins' work and home systems if they are well secured. Unlike the Cracker Trap, PortSentry will not even warn you if these systems attack you. This is a strong argument for having PortSentry's Adaptive Firewall action be to invoke the Cracker Trap. The latter will warn about trusted systems attacking without locking them out. This file is machine generated by ignore.csh and thus, should not be edited directly if you invoke ignore.csh.

    The RESOLVE_HOST variable normally is set to "1" (quotes included) to attempt to resolve the host name of the attacking system. This will tell a lot about the circumstances of the attack. If the host name has lots of random characters in it, probably it is an ISP's customer system. If its name is ns2 or dns3 then it probably is someone's compromised DNS server. If its name is www, you probably are dealing with a compromised Web server. If you have a slow DNS server, set it to "0".

    The BLOCK_TCP and BLOCK_UDP variables determine whether PortSentry will operate as an Adaptive Firewall and how. Use "1" to have PortSentry do the blocking, "2" to have it invoke only the command specified in KILL_RUN_CMD (e.g., invoke the Cracker Trap or your own custom IP Tables/IP Chains rules, or even an interface to another firewall for blocking), or "0" to not block. All modes except the Basic TCP mode are subject to spoofed source IP-address DoS attacks. In reality, these are so rare for all but the best-known sites that most SysAdmins should not worry about the risk.

    The KILL_ROUTE variable specifies how PortSentry should block the attacker if you selected "1" for either BLOCK_TCP or BLOCK_UDP. Use either the IP Tables or IP Chains method for Linux. For UNIX, using the route command may be your only easy option. The downside of using a route command is that you will get already blocked for subsequent attacks, except for TCP Basic mode. With IP Tables or IP Chains, unless you specify logging, you will not be bothered again, nor will they be able to get packets in.

    The only major downside to silent Tables/Chains blocking is that if someone repeats his attack so frequently that a significant percentage of your bandwidth is being used, you will not know it. Any of the following will work, depending on which packet filtering you are using:

     
     KILL_ROUTE="/sbin/iptables -I INPUT 1 -s $TARGET$ -j DROP" KILL_ROUTE="/sbin/ipchains -I input 1 -s $TARGET$ -j DENY" KILL_ROUTE="/sbin/ipchains -I input 1 -s $TARGET$ -j DENY -l" 

    If KILL_RUN_CMD is specified, its value will be fed to the shell as a command line. If you specify a mail command, you will get instant notification of an attack. You can specify your own blocking action here. What is the difference between specifying your own blocking command in KILL_ROUTE and specifying it in KILL_RUN_CMD? Nothing but philosophy. To invoke the Cracker Trap, see "Using PortSentry with the Cracker Trap" on page 579. To generate e-mail, the following is typical.

     
     KILL_RUN_CMD="(sleep 3;echo Portsentry $TARGET$ $PORT$ $MODE$; \    tail -10 /var/log/messages)|/bin/mail -s \    '$TARGET$ $PORT$ $MODE$ Portsentry' alert alertpage 

    While PortSentry's KILL_ROUTE command can be used to add an IP Tables or IP Chains blocking rule, it will be lost when the system is rebooted. I see no reason to ever unblock attacking systems for most installations. Using KILL_RUN_CMD to invoke the Cracker Trap's blockip command will block an attacker permanently as it will update the /etc/rc.d/fw.trouble file. If you do not wish to use the Cracker Trap, the same effect can be obtained by copying the skeleton fw.trouble file from the book/crackertrap directory on the CD-ROM and set KILL_RUN_CMD to either of the following:

     
     KILL_RUN_CMD="echo /sbin/iptables -I INPUT 1 -s $TARGET$ \    -j DROP >> /etc/rc.d/fw.trouble" KILL_RUN_CMD="echo /sbin/ipchains -I input 1 -s $TARGET$ \    -j DENY >> /etc/rc.d/fw.trouble" 

    You probably do not want to use the \ but instead have a single long line in portsentry.conf. Finally, add the following to the end of the /etc/rc.d/rc.local file:

     
     . /etc/rc.d/rc.local 

    This will load the rules of the permanently blocked systems.

  3. Deal with portsentry.ignore to list any trusted IPs that are to be ignored. This is where you would list the PortSentry system's interfaces, including the loopback device's IP, and SysAdmins' work and home systems, if thoroughly secured. Starting with version 1.1, a netmask may be used, specifying the number of network bits. You may want to list the appropriate range for your DMZ and you may not.

    You may want to list your internal network's range and you may not. It is a case of security versus convenience. Start by not listing any of these, except your "big money" systems and monitor PortSentry closely. Recently, one client's mail server tried to forward spam to the firewall and got itself locked out, so we decided to make it trusted until the spam was delivered and tossed.

    If some of your trusted IPs are dynamic, you will need to alter this file when they change. Typically, this will be an issue for home systems, either as the PortSentry system itself or to trust them. The trusting of other home systems may not be a problem if one can drop the connection and get a new one on reconnection. If the ignore.csh script is invoked, it will overwrite the portsentry.ignore file to contain the PortSentry system's IPs for its interfaces. If you edit ignore.csh and add the lines

     
     if (-f /etc/rc.d/friends.ignore) then    cat /etc/rc.d/friends.ignore >> $SENTRYDIR/$TMPFILE endif 

    after the line that has the pattern

     
     '0.0.0.0' 

    then you can create the file /etc/rc.d/friends.ignore, chmod it to mode 600, and list trusted systems there.

  4. Build and install. Issue the following command to see what systems it knows how to build for:

     
     make 

    For Linux (except Debian), issue the command

     
     make linux 

    For Debian Linux, issue the command

     
     make debian-linux 

    Install with:

     
     make install 
     
     cp ignore.csh /usr/local/psionic/portsentry/. 
  5. Arrange for PortSentry to be invoked. My preferred method is to add the following to /etc/rc.d/rc.local. If it already is running, it will be killed and restarted for ease of use when tweaking the portsentry.conf file:

     
     echo "Starting portsentry advanced stealth modes" killall portsentry # Generate list of IPs to ignore scans from #   (friends from /etc/rc.d/friends.ignore) /usr/local/psionic/portsentry/ignore.csh # Advanced stealth TCP /usr/local/psionic/portsentry/portsentry -atcp # Advanced stealth UDP /usr/local/psionic/portsentry/portsentry -audp 

    Start PortSentry with the command

     
     /etc/rc.d/rc.local 

    and monitor with

     
     tail -20f /var/log/messages 
  6. Test the configuration. From a nontrusted system (and one which is not your only way to access the system under test), telnet to an alarmed port:

     
     telnet firewall 6000 

    Observe that an entry has been added to /var/log/messages and that a new IP Tables rule has been added by issuing the command

     
     iptables -L -n -v | more 

       
    Top


    Real World Linux Security Prentice Hall Ptr Open Source Technology Series
    Real World Linux Security Prentice Hall Ptr Open Source Technology Series
    ISBN: N/A
    EAN: N/A
    Year: 2002
    Pages: 260

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net