Unix systems security

 Introduction
      I. Classification of the attacks against Unix systems

            Attacks based on some  security  vulnerabilities of the Unix systems
            Denial services attacks
             Passive attacks
            Active attacks
 

      II. CERT's check list index which assists in removing common and known security vulnerabilities under the UNIX Operating System.

  I. Classification
            1. Attacks based on some  security  vulnerabilities of the Unix systems
                      Example of security bugs    (http:/ oliver.efri.hr/~crv/security/)
      There is  unofficial pacth for Linux kernel which  is intended to add protection against two classes of security holes: buffer overflows and symlinks in /tmp.
                        This patch can  can be retrieved from:
                        http://www.false.com/security/linux-stack/

         2. Denial services attacks
 
                2.1. E-mail  Bombing and Spamming

    DESCRIPTION

     Email "bombing" is characterized by abusers repeatedly sending an identical
   email message to a particular address.

     Email "spamming" is a variant of bombing; it refers to sending email to
   hundreds or thousands of users (or to lists that expand to that many
   users). Email spamming can be made worse if recipients reply to the email,
   causing all the original addressees to receive the reply.

       Email bombing/spamming may be combined with email "spoofing" (which alters
   the identity of the account sending the email), making it more difficult
   to determine who the email is actually coming from.

         Email spamming is almost impossible to prevent because a user with a
   valid email address can "spam" any other valid email address,
   newsgroup, or bulletin-board service.

          When large amounts of email are directed to or through a single
   site, the site may suffer a denial of service through loss of
   network connectivity, system crashes, or failure of a service
   because of
          - overloading network connections
          - using all available system resources
          - filling the disk as a result of multiple postings and resulting
            syslog entries

    Prevention

        Unfortunately, at this time, there is no way to prevent email bombing
        or spamming (other than disconnecting from the Internet), and it
        is impossible to predict the origin of the next attack. It is trivial
        to obtain access to large mailing lists or information resources that
        contain large volumes of email addresses that will provide destination
        email addresses for the spam.

 
               2.2. TCP SYN Flooding and IP Spoofing Attacks

             Description

     When a system (called the client) attempts to establish a TCP connection
     to a system providing a service (the server), the client and server
     exchange a set sequence of messages. This connection technique applies
     to all TCP connections--telnet, Web, email, etc.

     The client system begins by sending a SYN message to the server. The
     server then acknowledges the SYN message by sending SYN-ACK message to
     the client. The client then finishes establishing the connection by
     responding with an ACK message. The connection between the client and
     the server is then open, and the service-specific data can be exchanged
     between the client and the server. Here is a view of this message flow:

                Client                                         &nb sp;                    Server
                ------                                         &nb sp;            ------
                SYN-------------------->

                   <--------------------SYN-ACK

                ACK-------------------->

                     Client and server can now
                     send service-specific data

     The potential for abuse arises at the point where the server system has
     sent an acknowledgment (SYN-ACK) back to client but has not yet received
     the ACK message. This is what we mean by half-open connection. The
     server has built in its system memory a data structure describing all
     pending connections. This data structure is of finite size, and it can be
     made to overflow by intentionally creating too many partially-open
     connections.

     Creating half-open connections is easily accomplished with IP
     spoofing. The attacking system sends SYN messages to the victim server
     system; these appear to be legitimate but in fact reference a client
     system that is unable to respond to the SYN-ACK messages. This means that
     the final ACK message will never be sent to the victim server system.

     The half-open connections data structure on the victim server system
     will eventually fill; then the system will be unable to accept any new
     incoming connections until the table is emptied out. Normally there is a
     timeout associated with a pending connection, so the half-open
     connections will eventually expire and the victim server system will
     recover. However, the attacking system can simply continue sending
     IP-spoofed packets requesting new connections faster than the victim
     system can expire the pending connections.

     In most cases, the victim of such an attack will have difficulty in
     accepting any new incoming network connection. In these cases, the
     attack does not affect existing incoming connections nor the ability to
     originate outgoing network connections.

         3. Passive attacks
                    Network monitoring attack  (sniffing).
             4. Active attacks
                     IP  Hijacking.
 
        Go back
 

  •     II. CERT's check list index which assists in removing common and known security vulnerabilities under

    • the UNIX Operating System.
     

                      1.0  Patches
                      2.0  Network security
                           2.1   Filtering
          ENSURE that ONLY those services which are required from outside your domain are allowed through your router filters.
                           2.2  "r" commands
                           2.3  /etc/hosts.equiv
                           2.4  /etc/netgroup
                           2.5  $HOME/.rhosts
                           2.6  NFS
                           2.7  /etc/hosts.lpd 
                           2.8  Secure terminals
                           2.9  Network services
                                2.9.1  /etc/inetd.conf
                                2.9.2  Portmapper
                           2.10  Trivial ftp (tftp)
                           2.11  /etc/services
                           2.12  tcp_wrapper (also known as log_tcp)
                           2.13  /etc/aliases
                           2.14  Sendmail
                           2.15  majordomo
                           2.16  fingerd
                           2.17  UUCP
                           2.18  REXD
                           2.19  World Wide Web (WWW) - httpd
                     3.0  ftpd and anonymous ftp
                           3.1  Versions
                           3.2  Configuration
                           3.3  Anonymous ftp only
                     4.0  Password and account security
                     5.0  File system security
                     6.0  Vendor operating system specific security
                     7.0  Security and the X Window System

    The full version of this document can be retrieved via anonymous ftp from:

    ftp://info.cert.org/pub/tech_tips/AUSCERT_checklist1.1
     

              Go back
     

         II. Security tools 

     
     
    CERT(sm) Coordination Center ( http://www.cert.org ) published a

    List of Security Tools (ftp://info.cert.org/pub/tech_tips/security_tools) that can be used

    to help secure a system and deter break-ins.

     

    Go back

         IV. What to do if there is a break-in in your Unix system. 
                  Intruder Detection Checklist
     

                   1. Examine log files for connections from unusual locations or other
          unusual activity. For example, look at your 'last' log, process
          accounting, all logs created by syslog, and other security logs.
          If your firewall or router writes logs to a different location than the
          compromised system, remember to check these logs also. Note that this is
          not foolproof unless you log to append-only media; many intruders edit
          log files in an attempt to hide their activity.

                   2. Look for setuid and setgid files (especially setuid root files)
          everywhere on your system. Intruders often leave setuid copies of
          /bin/sh or /bin/time around to allow them root access at a later
          time. The UNIX find(1) program can be used to hunt for setuid and/or
          setgid files. For example, you can use the following commands to find
          setuid root files and setgid kmem files on the entire file system:

            find / -user root -perm -4000 -print
            find / -group kmem -perm -2000 -print

          Note that the above examples search the entire directory tree,
          including NFS/AFS mounted file systems. Some find(1) commands
          support an "-xdev" option to avoid searching those hierarchies.
          For example:

            find / -user root -perm -4000 -print -xdev

          Another way to search for setuid files is to use the ncheck(8)
          command on each disk partition. For example, use the following command
          to search for setuid files and special devices on the disk partition
          /dev/rsd0g:

            ncheck -s /dev/rsd0g

                     3. Check your system binaries to make sure that they haven't been
          altered. We've seen intruders change programs on UNIX systems such as
          login, su, telnet, netstat, ifconfig, ls, find, du, df, libc, sync,
          any binaries referenced in /etc/inetd.conf, and other critical
          network and system programs and shared object libraries. Compare the
          versions on your systems with known good copies, such as those from
          your initial installation media. Be careful of trusting backups; your
          backups could also contain Trojan horses.

          Trojan horse programs may produce the same standard checksum and
          timestamp as the legitimate version. Because of this, the standard
          UNIX sum(1) command and the timestamps associated with the programs
          are not sufficient to determine whether the programs have been
          replaced. The use of cmp(1), MD5, Tripwire, and other cryptographic
          checksum tools is sufficient to detect these Trojan horse programs,
          provided the checksum tools themselves are kept secure and are not
          available for modification by the intruder. Additionally, you may
          want to consider using a tool (PGP, for example) to "sign" the output
          generated by MD5 or Tripwire, for future reference.

                   4. Check your systems for unauthorized use of a network monitoring
          program, commonly called a sniffer or packet sniffer. Intruders may
          use a sniffer to capture user account and password information. For
          related information, see CERT advisory CA-94:01 available in

        ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks

                   5. Examine all the files that are run by 'cron' and 'at.' We've seen
          intruders leave back doors in files run from 'cron' or submitted to
          'at.' These techniques can let an intruder back on the system (even
          after you believe you had addressed the original compromise). Also,
          verify that all files/programs referenced (directly or indirectly) by
          the 'cron' and 'at' jobs, and the job files themselves, are not
          world-writable.

                   6. Check for unauthorized services. Inspect /etc/inetd.conf for
          unauthorized additions or changes. In particular, search for entries
          that execute a shell program (for example, /bin/sh or /bin/csh) and
          check all programs that are specified in /etc/inetd.conf to verify
          that they are correct and haven't been replaced by Trojan horse
          programs.

          Also check for legitimate services that you have commented out in
          your /etc/inetd.conf. Intruders may turn on a service that you
          previously thought you had turned off, or replace the inetd program
          with a Trojan horse program.

                   7. Examine the /etc/passwd file on the system and check for modifications
          to that file. In particular, look for the unauthorized creation of new
          accounts, accounts with no passwords, or UID changes (especially UID 0)
          to existing accounts.

                   8. Check your system and network configuration files for unauthorized
          entries. In particular, look for '+' (plus sign) entries and
          inappropriate non-local host names in /etc/hosts.equiv, /etc/hosts.lpd,
          and in all .rhosts files (especially root, uucp, ftp, and other system
          accounts) on the system. These files should not be world-writable.
          Furthermore, confirm that these files existed prior to any intrusion and
          were not created by the intruder.

                   9. Look everywhere on the system for unusual or hidden files (files that
          start with a period and are normally not shown by 'ls'), as these can
          be used to hide tools and information (password cracking programs,
          password files from other systems, etc.). A common technique on UNIX
          systems is to put a hidden directory in a user's account with an unusual
          name, something like '...' or '.. ' (dot dot space) or '..^G' (dot dot
          control-G). Again, the find(1) program can be used to look for hidden
          files, for example:

            find / -name ".. " -print -xdev

            find / -name ".*" -print -xdev | cat -v

          Also, files with names such as '.xx' and '.mail' have been used
          (that is, files that might appear to be normal).

                     10. Examine all machines on the local network when searching for signs of
          intrusion. Most of the time, if one host has been compromised, others
          on the network have been, too. This is especially true for networks
          where NIS is running or where hosts trust each other through the use
          of .rhosts files and/or /etc/hosts.equiv files. Also, check hosts for
          which your users share .rhosts access.