você está aqui: Home  → Arquivo de Mensagens

Segurança de sistemas AIX

Colaboração: Rubens Queiroz de Almeida

Data de Publicação: 06 de Fevereiro de 1998

Estou anexando um documento que recebi já há algum tempo com relação a aspectos de segurança de sistemas AIX.

Embora antigo, este documento contém informações que podem ser úteis e válidas para qualquer versão do AIX e mesmo para outros sistemas operacionais.

                 Preparing your AIX System for SATAN
                         AIX Security Response Team
                         security@austin.ibm.com
 .........................................................................=

 I.   Purpose of this document
 II.  AIX vulnerabilities probed by SATAN
    1.   NFS export to unprivileged programs
    2.   NFS export via portmapper
    3.   Unrestricted NFS export
    4.   NIS password file access
    5.   rexd access
    6.   Sendmail vulnerabilities
    7.   TFTP file access
    8.   Remote shell access
    9.   Unrestricted X server access
    10.  Writable FTP home directory
    11.  wu-ftpd vulnerability
 III. More information on AIX security
 IV.  More information on internet security topics
 V.   CERT advisory on SATAN

 .........................................................................=
 I.   Purpose of this document
 .........................................................................=

 Everyone is becoming increasingly aware of computer security
 issues. No one wants to lose valuable information to unwanted
 intruders. The SATAN tool was developed to help system administrators
 secure all computers on their networks. The danger exists that this
 tool could be used for unlawful purposes.

 We want to help AIX users secure their systems so SATAN will not
 cause any problems. This document is intended to help AIX users
 understand each of the vulnerabilities probed by SATAN and learn what
 they can do to secure their systems in each of these areas. Many
 books and articles have been written on computer security
 configuration issues and we will refer you to these articles
 when appropriate.

 .........................................................................=
 II. AIX vulnerabilities probed by SATAN
 .........................................................................=

 .........................................................................=
    1.   NFS export to unprivileged programs
 .........................................................................=

 If the nfs mount daemon, rpc.mountd, is started with the -n
 flag it allows mount requests to come from non-privileged ports.
 This is used to allow some older versions of NFS to perform mounts.
 It should not be used. The AIX default is to not use the -n flag.

 For additional security use the nfso utility to turn on kernel port
 checking. The command would be:
  nfso -o nfs_portmon=1 (in AIX version 3 )
  nfso -o portcheck=1   (in AIX version 4 )
 The default in AIX is to NOT do kernel portchecking.

 .........................................................................=
    2.   NFS export via portmapper
 .........................................................................=

 Access to filesystems via portmapper is disabled by default in
 recent versions of AIX. To make sure you have a later version of
 portmapper that fixes this problem, check to make sure your machine
 has the fix for APAR IX32328. That fix has been included in PTFS
 U419992 U419994 U419995.

 Use the following aix cmd to determine if you have applied these ptfs:
 $ lslpp -al U419992 U419994 U419995

 .........................................................................=
    3.   Unrestricted NFS export
 .........................................................................=

 Entering a directory or filesystem in the /etc/export list without
 specifying an access list allows any host who's IP address can be
 resolved to mount the directory. This is not secure. The access list
 should be specified when exporting filesystem objects.

 Exports specifying root access or read/write access also are inherently
 lower security and should be implemented with caution.

 .........................................................................=
    4.   NIS password file access
 .........................................................................=

 The ability to view encrypted passwords when NIS is being used
 and the ability to exploit the information can be curtailed and
 to some extent prevented in a number of ways.

 A) use a /var/yp/securenets file to restrict the NIS services to
 trusted networks.  (see the notes on securenets below).

 B) Make the NIS domain name hard to guess and non-obvious. Employee
 turnover or other security concerns may require domain renaming.
 (use the chypdom command or smit chypdom to change domain names and
 move the /var/yp/<domain_name> directory to the new name)

 C) Require users to use non-trivial passwords.


 Use of the /var/yp/securenets file:

 The implementation of ypserv and ypxfrd that utilize the
 securenets file was shipped in response to APAR ix32328
 Some PTF's that contain that fix are:
 U419992 U419994 and U419995.

 Use the following aix cmd to determine if you have applied these ptfs:
 $ lslpp -al U419992 U419994 U419995

 Both the "ypserv" and "ypxfrd" use a /var/yp/securenets
 file and, if present, only responds to IP addresses in the
 range given. This file is only read when the daemons (both
 ypserv & ypxfrd) start. To get a change in /var/yp/securenets
 to take effect, one must kill and restart the daemons.


 The format of the file is one or more lines of:

 netmask netaddr

 e.g.

 255.255.0.0 128.30.0.0
 255.255.255.0 128.311.10.0

 In the 2nd example, the netmask is 255.255.255.0
 and the network address is 128.311.10.0 . This
 setup will only allow the ypserv to respond to
 those IP addresses which are within the subnet
 128.311.10 range.

 An additional NIS security note is that allowing ypset to
 reset ypbind binding lowers security. ypbind daemons
 shipped in the fix for APAR IX43595 (in PTF U431006)
 disallow ypset's as their default behavior and this is
 strongly recommended.

 Use the following aix cmd to determine if you have applied this ptf:
 $ lslpp -al U431006

 .........................................................................=
    5.   rexd access
 .........................................................................=

 The rexd server allows users to execute commands on remote servers
 in an environment similar to that of the local system.  No validation
 of identity or access permission is performed.  This behavior leads
 many people to believe that the use of rexd is a security vulnerability.

 There are currently no known defects in the rpc.rexd command which
 adversely affect the security of the system.  rpc.rexd is contained in
 the bosnet.nfs.obj.client subsystem.  The most recent PTF for that
 subsystem as of the writing of this document is U436781.

 Use the following aix cmd to determine if you have applied this ptf:
 $ lslpp -al U436781

 The lack of authentication of the identity of the invoker may present
 a security exposure in an untrustworthy environment.  You should weigh
 the risks of a security exposure against the functionality provided when
 you consider enabling this service.

 The problems with rexd are inherent in the design of the server and
 cannot be corrected easily.  The security problems can be limited by
 careful use of NFS exports on the client system and by disabling rexd
 on the server.

 IBM issued CA-92:05 on March 5, 1992 describing a problem with the
 initial configuration of rexd on AIX 3.1 and AIX 3.2 systems.  APAR
 IX21353 was opened to correct this problem.  The problem corrected by
 this APAR no longer exists in AIX 3.2.5 or AIX 4.1.

 In AIX 3.2.5 and 4.1 rexd is disabled by default when shipped.

 .........................................................................=
    6.   Sendmail vulnerabilities
 .........................................................................=

 All AIX versions of /usr/sbin/sendmail are vulnerable to some of the
 attacks described in CA-95:05. The official APARs resolving ALL known
 AIX sendmail vulnerabilities are IX49257 (version 3.2) and IX49604
 (version 4.1).

 AIX users should obtain the emergency patch from Internet
 ftp site software.watson.ibm.com. The file is located in
 /pub/aix/sendmail/sendmail.tar.Z in compressed tar format.
 Please follow the installation instructions in the sendmail.readme
 file located in this same directory.

 Currently, AIX versions 3.2 and 4.1 are based on sendmail version
 5.64. Although this is an old version of sendmail, all known
 sendmail security bugs are fixed by the emergency patch mentioned
 previously.

 If you permit automatic mail forwarding or programs that accept
 mail messages, please be sure there is no way for these programs
 to create a shell or send commands. This type of configuration can
 create a security hole that could be exploited by an unfriendly user.

 .........................................................................=
    7.   TFTP file access
 .........................................................................=

 The tftpd server allows users to retrieve files without requiring an
 account on the remote server.  Tftpd is commonly used by diskless=
 systems
 and X-stations as well.  Tftp does not require the use of a user name or
 password and therefore may grant access to system data when the identity
 of the requestor has not been established.  This may allow unknown users
 to acquire restricted data or to modify user files.

 There are currently no known defects in tftpd which adversely affect the
 security of the system.  The tftpd command is contained in the
 bosnet.tcpip.obj.client subsystem.  The most recent PTF for that=
 subsystem
 as of the writing of this document is U435114.

 The lack of any authentication or identification of the requestor should
 be considered when configuring tftpd.  The tftp service may be=
 restricted
 using the /etc/tftpaccess.ctl file.  This file is documented in
 InfoExplorer under the tftpd command.  This function was added to AIX=
 v3.1
 by APAR IX22628 and is available in the 2014 level PTF.

 Tftp should be configured in /etc/inetd.conf to run as the user=
 "nobody".
 The following line is an example of how to do this.

      tftp    dgram   udp     wait    nobody  /etc/tftpd tftpd -n

 THIS EXAMPLE WILL ALLOW REMOTE USERS TO WRITE FILES ON THE LOCAL SYSTEM.
 If you have no requirement for granting write permission to remote users
 you should consider removing the "-n" flag from the command line given
 above.

 The user "nobody" should own no files or directories on the system.  The
 only files or directories which the user "nobody" should be able to read
 are those with read or write (and execute for directories) permission to
 "other".  Refer to the chmod command in InfoExplorer for details on how=
 to
 manage file and directory permissions.  By properly restricting access=
 to
 "other", you will effectively limit the files and directories which=
 tftpd
 may access and modify.

 IBM released CERT advisory CA:91-19 on October 17, 1991 for the tftpd
 daemon.  The vulnerability described in that advisory is corrected in=
 all
 releases of AIX v3.2 and AIX v4.

 .........................................................................=
    8.   Remote shell access
 .........................................................................=

 The rsh and rlogin commands are used to establish sessions on remote
 servers.  Both commands operate in a similar manner from an access
 perspective.  The file /etc/hosts.equiv or a .rhosts file in the user's
 home directory may be consulted to determine if access is granted.  When
 access is not automatically granted for the rlogin command the remote=
 user
 is prompted for a password.

 The rshd server has had one security related defect.  APAR IX45182
 corrected a defect in which the "-l" option (used to control operation=
 of
 the server) did not work properly.  This APAR was first delivered in PTF
 U432655.  This PTF should be applied to any system which has been
 configured according to the instructions given below.  This problem does
 not exist on any release of AIX v4.

 The rlogind server has had one significant security related defect. =
 APARs
 IX44254 and IX44367 corrected a defect in which any network user was=
 able
 to gain access to the remote system as any user.  These APARs were first
 delivered in PTFs U431620 and U431622 respectively.  Both of these PTFs=
 or
 their superceding PTFs should be installed on all systems.  This problem
 does not exist on any release of AIX v4.

 Two significant enhancements have been made to the rshd server.  APAR
 IX45701 added a facility for restricting use of rshd and rexecd on a=
 user
 by user basis.  This feature may be useful for critical system accounts
 which might be subject to attack via a network connection.  This APAR=
 was
 first delivered in PTF U434068.  APAR IX48235 added additional auditing
 capability.  This feature may be useful when connecting to unsecure
 networks or when you are interested in monitoring rshd usage.  A=
 USER_Login
 audit event will be created for each rshd invocation.  This may be used=
 in
 conjunction with the TCPIP_access event to determine local user and=
 remote
 hostname for each rshd and rexecd.  As of the writing of this document=
 this
 APAR has not been packaged into a PTF.

 Both rshd and rlogind are subject to security violations related to
 use of the /etc/hosts.equiv and $HOME/.rhosts files.  This exposure can
 be removed by adding the "-l" flag to the rshd and rlogind command
 lines in /etc/inetd.conf.  The following two lines are an example of how
 you might do this.

     shell    stream   tcp   nowait  root    /etc/rshd       rshd -l
     login    stream   tcp   nowait  root    /etc/rlogind    rlogind -l

 If you do not wish to grant remote network access to your system, you=
 may
 disable this facility entirely with lines similar to the following.

     #shell    stream   tcp   nowait  root    /etc/rshd       rshd
     #login    stream   tcp   nowait  root    /etc/rlogind    rlogind

 Please refer to InfoExplorer for additional information on configuring
 the /etc/inetd.conf file and the inetd daemon.

 Should you choose to enable rshd and/or rlogind, the use of the
 /etc/hosts.equiv and $HOME/.rhosts files creates a dependency on the
 information in those files and the information which the servers use=
 being
 accurate.  Errors in either file or spoofing of host addresses or names
 are common causes of security exposures.  When the network is not secure
 or trustworthy, consider disabling these services for some or all users=
 or
 enabling the auditing subsystem to track possible attacks.  You may also
 wish to consider use of a firewall or some other form of packet filter=
 to
 restrict access to trustworthy hosts or networks.

 InfoExplorer describes the proper configuration of the /etc/hosts.equiv
 file.  As a general rule, grant access to specific users and specific
 hosts.  You should monitor the existence of .rhosts files and insure=
 that
 users are educated about their proper use.

 The telnet service may be more appropriate in an unsecured network
 environment as it does not support the pre-authentication of users.

 CERT advisory CA-94:09 was released on May 23, 1994 describing the=
 security
 exposure in the rlogin service.

 Use the following aix cmd to determine if you have applied one of these=
 ptfs:
 $ lslpp -al U43xxxx

 .........................................................................=
    9.   Unrestricted X server access
 .........................................................................=

  In 1993 CERT  issued advisory CA-93:17 which documented a xterm=
 vulnerability
 in X11R5 and earlier versions of X11. This problem was resolved by the
 following apars:

    aixterm X11r4 : ix34738 - resolved by U417488 and U419246
    aixterm X11r5 : ix40275 - resolved by ptf U425631
    xterm   X11r4 : ix40279 - resolved by ptf U425255 and U425228
    xterm   X11r5 : resolved by U493250 (3.2.5 Gold)

 Use the following aix cmd to determine if you have applied these ptfs:
 $ lslpp -al U4xxxxx

   If you are using AIX 3.2, please make sure you have all these
 ptfs applied to avoid potential security problems. These fixes
 are shipped as part of the GOLD version of AIX 4.1.  Because of X11's=
 design,
 the client/server can be accessed by any other host on the network. If
 you are on the Internet, your display can be accessed by any machine in
 the world. X11 security issues for AIX are similar to the X11 security=
 problems
 facing other X11 vendors. It is difficult to make X completely secure.
 However, there are access control mechanisms which can be put in place
 to help make your environment more secure. You should never use the
 "xhost +" cmd because this will enable any remote user to read/write
 screen information. Please remove all "xhost +" cmds from any file
 or program on your system. A useful tool for limiting X access, please
 see the /usr/bin/xauth

 The best source of information on securing X is in : O'Reilly &=
 Associates,Inc.
 "X Window System Adminstrator's Guide". Specifically chapter 4 which=
 goes into
 detail about X security. The discussion in this chapter applies to the=
 AIX
 environment.  In additon, the Common Desktop Enviroment (CDE) interface
 available on AIX 4.1 uses XDMCP protocol discussed in this chapter.

 .........................................................................=
    10.  Writable FTP home directory
 .........................................................................=

 In 1992, CERT issued advisory CA-92:09 about an AIX Anonymous FTP
 Vulnerability. This problem was resolved by apar ix23944, which
 was included in the GOLD release of AIX 3.2. Thus, AIX 3.2 and 4.1=
 systems
 are not vulnerable to this problem. The original problem was discovered
 on AIX 3.1. If you are running AIX 3.1, please update to the latest
 release of 3.1, which resolves this problem.

 The following information can be very helpful:

 - -  The ftpd man page has explicit instructions for securely
    configuring your anonymous FTP user and subtree.
 - -  The /usr/lpp/samples/tcpip/anon.ftp file can be used to securely
    set up your anonymous account. (/usr/samples/tcpip/anon.ftp in AIX=
 4.1)
 - -  The CERT tip found at ftp://info.cert.org/tech_tips/anonymous_ftp
    contains applicable information.

 .........................................................................=
    11.  wu-ftpd vulnerability
 .........................................................................=

 This problem only affects users running the wuarchive-ftpd.
 If you do not have this modified version of ftpd, then you are
 not vulnerable to this specific attack. If you are running the
 wuarchive-ftpd, and your version is dated prior to April 8, 1993,
 please take corrective action or remove this daemon.

 You can obtain more information about this service via anonymous ftp
 from wuarchive.wustl.edu (128.252.135.4).

 This service is NOT distributed with AIX.

 .........................................................................=
 III. More information on AIX security
 .........................................................................=

   We publish an AIX security newsletter that is updated whenever
   we have security information that affects AIX users.

   To subscribe to the newsletter:

     mail -s "subscribe security" aixserv@austin.ibm.com < /dev/null

   If you have comments or questions about AIX security, or you
   would like to notify us of a potential problem, please send mail
   to security@austin.ibm.com.

   To order an APAR from IBM in the U.S. call 1-800-237-5511.
   APARs may be obtained outside the U.S. by contacting a
   local IBM representative.

 .........................................................................=
 IV.  More information on internet security topics
 .........................................................................=

    One of the best ftp sites for computer security information is
 ftp://coast.cs.purdue.edu/pub. You might also want to check out
 their WWW home page at http://www.cs.purdue.edu/coast. Their hotlist
 of other security home pages is also very helpful.

   Other WWW sites with pointers to useful security info:
 http://csrc.ncsl.nist.gov/first
 http://ciac.llnl.gov

   There are many listservers and newsgroups that are completely
 dedicated to the topic of computer security. You can find more
 information about these by looking at some of the WWW sites mentioned
 above.

 .........................................................................=
 V.  CERT advisory on SATAN
 .........................................................................=

 CA-95:06                        CERT Advisory
                                 April 3, 1995
          Security Administrator Tool for Analyzing Networks (SATAN)
          ----------------------------------------------------------

 The CERT Coordination Center staff has examined beta version 0.51 of the
 Security Administrator Tool for Analyzing Networks (SATAN). This advisory
 contains information based on our review of this pre-release version. When the
 official release is available, we will distribute an updated advisory. SATAN
 is scheduled for release on April 5, 1995, at 14:00 GMT.

 1. What is SATAN?
 - ------------------
 SATAN is a testing and reporting tool that collects a variety of information
 about networked hosts. The currently available documentation can be found at
          ftp://ftp.win.tue.nl/pub/security/satan_doc.tar.Z

 SATAN gathers information about specified hosts and networks by examining
 network services (for example, finger, NFS, NIS, ftp, and rexd).  It can then
 report this data in a summary format or, with a simple rule-based system,
 investigate potential security problems. Problems are described briefly and
 pointers provided to patches or workarounds. In addition to reporting
 vulnerabilities, SATAN gathers general network information (network topology,
 network services run, types of hardware and software being used on the
 network).  As described in the SATAN documentation, SATAN has an exploratory
 mode that allows it to probe hosts that have not been explicitly specified.
 Thus, SATAN could probe not only targeted hosts, but also hosts outside your
 administrative domain.

 Section 4 below lists the vulnerabilities currently probed by SATAN.


 2. Potential Impact of SATAN
 - ----------------------------
 SATAN was designed as a security tool for system and network administrators.
 However, given its wide distribution, ease of use, and ability to scan remote
 networks, SATAN is also likely to be used to locate vulnerable hosts for
 malicious reasons. It is also possible that sites running SATAN for a
 legitimate purpose will accidentally scan your system via SATAN's exploratory
 mode.

 Although the vulnerabilities SATAN identifies are not new, the ability to
 locate them with a widely available, easy-to-use tool increases the level of
 threat to sites that have not taken steps to address those vulnerabilities. In
 addition, SATAN is easily extensible. After it is released, modified versions
 might scan for other vulnerabilities as well and might include code to
 compromise systems.


 3. How to Prepare for the Release of SATAN
 - ------------------------------------------

 * Examine your systems for the vulnerabilities described below and implement
   security fixes accordingly.

 * In addition to reading the advisories cited for specific vulnerabilities
   below, consult the following documents for guidance on improving the
   security of your systems:
           ftp://info.cert.org/tech_tips/security_info
           ftp://info.cert.org/tech_tips/anonymous_ftp
           ftp://info.cert.org/tech_tips/packet_filtering

 * Contact your vendor for information on available security patches, and
   ensure that all patches have been installed at your site.

 * Use the tools listed in Section 5 to assist you in assessing and improving
   the security of your systems.


 4. Vulnerabilities Probed by SATAN
 - ----------------------------------
 Listed below are vulnerabilities that beta version 0.51 of SATAN tests for,
 along with references to CERT advisories and other documents where applicable.

 Administrators should verify the state of their systems and perform corrective
 actions as necessary. We cannot stress enough the importance of good network
 configuration and the need to install all available patches.

    1. NFS export to unprivileged programs
    2. NFS export via portmapper
    3. Unrestricted NFS export

       See CERT advisory CA-94:15 and CA-94:15.README for security measures you
       can take to address NFS vulnerabilities.

       The following advisories also address problems related to NFS:
              CA-94:02.REVISED.SunOS.rpc.mountd.vulnerability
              CA-94:02.README
              CA-93:15.SunOS.and.Solaris.vulnerabilities
              CA-92:15.Multiple.SunOS.vulnerabilities.patches
              CA-92:12.REVISED.SunOS.rpc.mountd.vulnerability
              CA-91:21.SunOS.NFS.Jumbo.and.fsirand

    4. NIS password file access
       See CERT advisory CA-92:13 for information about SunOS 4.x machines
using
       NIS, and CA-93:01 for information about HP machines.

    5. rexd access
       We recommend filtering the rexd service at your firewall and commenting
       out rexd in the file /etc/inetd.conf.

       See CERT advisory CA-92:05 for more information about IBM AIX machines
       using rexd, and CA-91:06 for information about NeXT.

    6. Sendmail vulnerabilities
       See CERT advisory CA-95:05 and CA-95:05.README for the latest
information
       we have published about sendmail.

    7. TFTP file access
       See CERT advisory CA-91:18 for security measures that address TFTP
access
       problems. In addition, CA-91:19 contains information for IBM AIX users.

    8. Remote shell access
       We recommend that you comment out rshd in the file /etc/inetd.conf or
       protect it with a TCP wrapper.

    9. Unrestricted X server access
       We recommend filtering X at your firewall. Additional advice about
       packet filtering is available by anonymous FTP from
              ftp://info.cert.org:/pub/tech_tips/anonymous_ftp

    10. Writable FTP home directory
        See CERT advisory CA-93:10.
        Guidance on anonymous FTP configuration is also available from
              ftp://info.cert.org:/pub/tech_tips/anonymous_ftp

    11. wu-ftpd vulnerability
        See CA-93:06, CA-94:07, and CA-94:07.README for more information about
        ftpd.


 Note: In addition to our FTP archive at info.cert.org, CERT documents are
       available from the following sites, and others which you can locate
       by using archie:

 ftp://coast.cs.purdue.edu:/pub/mirrors/cert.org/cert_advisories
           ftp://unix.hensa.ac.uk:/pub/uunet/doc/security/cert_advisories
           ftp://ftp.luth.se:/pub/misc/cert/cert_advisories
           ftp://ftp.switch.ch:/network/security/cert_advisories
           ftp://corton.inria.fr:/CERT/cert_advisories
           ftp://ftp.inria.fr:/network/cert_advisories
           ftp://nic.nordu.net:/networking/security/cert_advisories

 5. Currently Available Tools
 - -----------------------------
 The following tools are freely available now and can help you improve your
 site's security before SATAN is released.

 COPS and ISS can be used to check for vulnerabilities and configuration
 weaknesses.

      COPS is available from ftp://info.cert.org:/pub/tools/cops/*

      ISS is available from
      ftp://ftp.uu.net:/usenet/comp.sources.misc/volume39/iss
      CERT advisory CA-93:14 and CA-93:14.README contain information about ISS.

 TCP wrappers can provide access control and flexible logging to most network
 services. These features can help you prevent and detect network attacks. This
 software is available by anonymous FTP from

           ftp://info.cert.org:/pub/tools/tcp_wrappers/*

 The TAMU security package includes tools to check for vulnerabilities and
 system configuration weaknesses, and it provides logging and filtering of
 network services. This software is available by anonymous FTP from

           ftp://net.tamu.edu:/pub/security/TAMU/*

 The Swatch log file monitor allows you to identify patterns in log file
entries
 and associate them with actions. This tool is available from

           ftp://ee.stanford.edu:/pub/sources/swatch.tar.Z


 6. Detecting Probes
 - -------------------
 One indication of attacks by SATAN, and other tools, is evidence of a heavy
 scan of a range of ports and services in a relatively short time.  Many UNIX
 network daemons do not provide sufficient logging to determine if SATAN is
 probing the system. TCP wrappers, the TAMU tools, and Swatch can provide the
 logging you need.


 7. Using SATAN
 - ---------------
 Running SATAN on your systems will provide you with the same information an
 attacker would obtain, allowing you to correct vulnerabilities. If you choose
 to run SATAN, we urge you to read the documentation carefully. Also,
 note the following:

 * It is easy to accidentally probe systems you did not intend to. If this
   occurs, the probed site may view the probe(s) as an attack on their
   system(s).

 * Take special care in setting up your configuration file, and in selecting
the
   probe level when you run SATAN.

 * Explicitly bound the scope of your probes when you run SATAN. Under "SATAN
   Configuration Management," explicitly limit probes to specific hosts and
   exclude specific hosts.

 * When you run SATAN, ensure that other users do not have read access to your
   SATAN directory.

 * In some cases, SATAN points to CERT advisories. If the link does not work
   for you, try getting the advisories by anonymous FTP.


 8. Getting more information about SATAN
 - ---------------------------------------
 As noted above, SATAN documentation is available from
           ftp://ftp.win.tue.nl/pub/security/satan_doc.tar.Z

 Additional documents are available through a mail server set up by one of the
 authors.

 Send mail to
           majordomo@wzv.win.tue.nl

 Put the following text in the body (not subject):
         get satan mirror-sites
         get satan release-plan
         get satan description
         get satan admin-guide-to-cracking.101

 The last document contains "Improving the Security of Your Site by Breaking
 Into It," a 1993 paper in which the authors give their rationale for creating
 SATAN.

 -------------------------------------------------------------------------
 The CERT Coordination Center staff thanks Dan Farmer and Wieste Venema
 for the
 the opportunity to examine pre-release versions of SATAN. We also appreciate
 the interaction with the response teams at AUSCERT, CIAC, and DFN-CERT, and
 feedback from Eric Allman.
 -------------------------------------------------------------------------

 If you believe that your system has been compromised, contact the CERT
 Coordination Center or your representative in the Forum of Incident
 Response and Security Teams (FIRST).

 If you wish to send sensitive incident or vulnerability information to
 CERT staff by electronic mail, we strongly advise that the e-mail be
 encrypted.  The CERT Coordination Center can support a shared DES key, PGP
 (public key available via anonymous FTP on info.cert.org), or PEM (contact
 CERT staff for details).

 Internet E-mail: cert@cert.org
 Telephone: +1 412-268-7090 (24-hour hotline)
            CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4),
            and are on call for emergencies during other hours.
 Fax: +1 412-268-6989

 Postal address:  CERT Coordination Center
                  Software Engineering Institute
                  Carnegie Mellon University
                  Pittsburgh, PA 15213-3890
                  USA

 CERT advisories and bulletins are posted on the USENET newsgroup
 comp.security.announce. If you would like to have future advisories and
 bulletins mailed to you or to a mail exploder at your site, please send mail
 to cert-advisory-request@cert.org.

 Past advisories, CERT bulletins, information about FIRST representatives, and
 other information related to computer security are available for anonymous
 FTP from info.cert.org.



 Copyright 1995 Carnegie Mellon University
 This material may be reproduced and distributed without permission provided it
 is used for noncommercial purposes and the copyright statement is included.

 CERT is a service mark of Carnegie Mellon University.

 -------------------------------------------------------------------------
 -------------------------------------------------------------------------

 AIX Service Bulletin

 September 8, 1994

 International Business Machines Corporation
 RISC System/6000 Division
 AIX Service and Support
 11400 Burnet Road
 Austin, TX 78758i


 Subject: Potential Security Exposure

 IBM has become aware of a potential security exposure in all releases
 and levels of AIX Version 3 that could allow local and remote users to
 obtain unauthorized root authority.  This unauthorized root authority
 may be obtained through the use of:

   o  The vi editor

   o  Remote login

   o  The batch (bsh) queue

   o  Network Information Service (NIS)

 You may obtain emergency fixes to eliminate the potential security
 exposure without disabling the remote login, batch queue, or NIS
 functions from the IBM Support Center or via anonymous FTP from:

   software.watson.ibm.com:/pub/aix/security.tar

 Officially released fixes, IX43595, IX44254, IX44381, and IX44685,
 can be obtained using FixDist in the U.S., or from the IBM Support
 Center.

 Customers can also chose to perform the procedures outlined on the
 attached pages to immediately eliminate the potential exposure,
 although this will disable the remote login, batch queue, and NIS
 fucntions.

 Additionally, IBM has become aware of a potential problem affecting
 only AIX Version 3.2.5 that could allow a user program to abnormally
 terminate ("crash") a system, requiring a system reboot.  A fix for
 this problem, IX44274, can be obtained using FixDist in the U.S., or
 from the IBM Support Center.

 For information on contacting the IBM Support Center, call
 800-IBM-4FAX and request document number 1760.


 Procedure to Eliminate AIX Version 3 Unauthorized Root Authority
 Security Exposure

 1.  Login as root

 2.  To ensure that root's shell is /bin/ksh, use the following
     command:

       /bin/ksh

 3.  To ensure that your current directory is root (/), use the
     following command:

       cd /

 The following steps eliminate the ability to obtain unauthorized
 root authority through the use of the vi editor.  The vi editor may
 be used to accomplish these steps.

 4.  Determine the version of the vi editor using the following
     command:

       strings /usr/bin/vi | grep ex_data

     If the second column of output is '1.6' or '1.7', then perform
     steps 5 and 6, otherwise skip to step 7.

 5.  Create or edit the existing .exrc file in the home directory of
     every user, starting with root, and insert the following as the
     first line:

       set nosourceany noexrc

 6.  Set the owner and permissions of the .exrc file using the following
     command, substituting the user name for '<user>':

       chown <user> ~<user>/.exrc=

       chmod 600 ~<user>/.exrc=

 The following steps eliminate the ability to obtain unauthorized root
 authority through the use of remote login by disabling remote login
 using the rlogin and rsh commands.

 7.  Edit the /etc/inetd.conf file.  If the following line exists,
     comment it out by inserting a # in the first column of the line:

       login  stream  tcp  nowait  root  /etc/rlogind  rlogind

 8.  Enter the following commands to make the change take immediate
     effect:

       /usr/bin/inetimp

       /usr/bin/refresh -s inetd

 The following step eliminates the ability to obtain unauthorized root
 authority through the use of the batch (bsh) queue by disabling the
 batch queue.

 9.  Enter the following command to disable the batch queue:

       /usr/bin/chque -qbsh -a"up = FALSE"

 The following steps eliminate the ability to obtain unauthorized root
 authority through the use of NIS by disabling NIS on the client.

 10.   Copy the /etc/hosts, /etc/passwd, /etc/security/passwd, /etc/group,
       /etc/security/group and any other NIS served files from the NIS
       master to the NIS client.

 11.   Enter the following command on the NIS client to disable NIS on
       the client:

         /usr/etc/yp/rmyp -c


Veja a relação completa dos artigos de Rubens Queiroz de Almeida