Archive-name: computer-security/anonymous-ftp-faq
Post-Frequency: monthly
Last-modified: 1994/4/28
Version: 1.2

	How to set up a Secure Anonymous FTP Site

	The following is a FAQ on setting up a secure FTP Site.  FTP sites
are known for much abuse by transferring illegal files.  They also open many
oppurtunities for intruders to gain access via misconfigured setups.  And
lastly many versions of ftp servers have had security holes.  This FAQ is
intended to clean up this abuse by allowing administrators to go through this
check list of steps to make sure their FTP is correctly configured and that
they are running the most current ftp daemon.

This is organized in the following fashion, I am breaking into several parts
as follows:

Part 1 - General Description of Setting up an "anonymous" ftp server.
Part 2 - Setting up a chrooted Secure Anonymous ftp server.  
Part 3 - OS Specific needed information and suggestions.
Part 4 - Where to get other FTP daemons
Part 5 - Archie
Part 6 - Acknowledgements.




Part 1 - General Description of Setting up an "anonymous" ftp server.

How do I setup "anonymous" ftp securely?

PLEASE READ ALL NOTES AND WARNINGS!!!

1) Create the user ftp in /etc/passwd.  Use a misc group.  The user`s home
directory will be ~ftp where ~ftp is the root you wish anonymous users to
see.

Use an invalid password and user shell for better security. The entry in the
passwd file should look something like:

	    ftp:*:400:400:Anonymous FTP:/home/ftp:/bin/true

2) Create the home directory ~ftp.  Make the directory owned by root (NOT ftp)
with the same group as ftp.  Thus, owner permissions are for root and group
permissions are for the anonymous users.  Set the permissions for ~ftp to 555
(read, nowrite, execute).

3) Create the directory ~ftp/bin.  This directory is owned by root (group
e.g. wheel) with permissions 111 (noread, nowrite, execute).

4) Copy the program ls into ~ftp/bin.  ls is owned by root with permissions
111 (noread, nowrite, execute).  Any other commands you put in ~ftp/bin 
should have the same permissions as well.

5)  Make the directory ~ftp/etc.  This directory is owned by root with
permissions 111.

6)  Create from scratch the files /etc/passwd and /etc/group in ~ftp/etc.
These files should be mode 444.  The passwd file should only contain root,
daemon, uucp, and ftp.  The group file must contain ftp's group. Use your
/etc/passwd and /etc/group files as a template for creating passwd and group
files going to ~ftp/etc.  You may even change the user names in this file,
they are used only for 'ls' command.  So for example if all files in your
~ftp/pub/linux hierarchy will be maintained by a real user 'balon' with
uid=156 you may put 

        linux:*:156:120:Kazik Balon::

in the ~ftp/etc/passwd file (regardless of his real username).  Leave only
these users who will own files under ftp hierarchy (e.g. root, daemon,
ftp...) and definitely remove *ALL* passwords by replacing them with '*' so
the entry looks like:

	root:*:0:0:Ftp maintainer::
	ftp:*:400:400: Anonymous ftp::

	For more security, you can just remove ~ftp/etc/passwd and
~ftp/etc/group (the effect is that ls -l will not show the directories' group
names).  Wuarchive ftp daemon (and some others) have some extensions based on
the contents of the group/passwd files, so read the appropriate documentation.

7)  Make the directory ~ftp/pub.  This directory is owned by you and has the
same group as ftp with permissions 555.  On most systems (like SunOS) you may
want to make this directory 2555, ie. set-group-id, in order to create new
files with the same group ownership.


Files are left here for public distribution. All folders inside ~ftp/pub
should have the same permissions as 555.

*** Neither the home directory (~ftp) nor any directory below it should be
owned by ftp!  No files should be owned by ftp either.  Modern ftp daemons
support all kinds of useful commands, such as chmod, that allow outsiders to
undo your careful permission settings.  They also have configuration options
like the following (WuFTP) to disable them:

# all the following default to "yes" for everybody
delete          no      guest,anonymous         # delete permission?
overwrite       no      guest,anonymous         # overwrite permission?
rename          no      guest,anonymous         # rename permission?
chmod           no      anonymous               # chmod permission?
umask           no      anonymous               # umask permission?


8) If you wish to have a place for anonymous users to leave files, create
the directory ~ftp/pub/incoming.  This directory is owned  by root with
permissions 733.  Do a 'chmod +t ~ftp/pub/incoming'.  The ftp daemon will
normally not allow an anonymous user to overwrite an existing file, but a
normal user of the system would be able to delete anything.  By setting the
mode to '1733' you prevent this from happening.  In wuftpd you may configure
the daemon to create new files with permissions '600' owned by root or any
other user.  Many  times, incoming directories are abused by exchanging pirated
and pornographic material.  Abusers often create hidden directories there for
this purpose.  Making the incoming directory unreadable by anonymous ftp helps
to some extent.  With ordinary ftp severs there is no way to prevent
directories being created in incoming. The WUarchive ftp server can limit
uploads to certain directories and can restrict characters used in file names
like this:

# specify the upload directory information
upload  /var/spool/ftp  *       no
upload  /var/spool/ftp  /incoming       yes     ftp     staff   0600    nodirs

# path filters                                                                                  # path-filter...
path-filter  anonymous  /etc/msgs/pathmsg  ^[-A-Za-z0-9_\.]*$  ^\.  ^-
path-filter  guest      /etc/msgs/pathmsg  ^[-A-Za-z0-9_\.]*$  ^\.  ^-

Suggestion: Create an extra file-system for your ftp-area (or at least for
your incoming-area) to prevent a denial-of-service attack by filling your
disk with garbage (inside your incoming directory).

	If you have wuftpd you may want to add some ftp extensions like
compression/decompression 'on the fly' or creation of tar files for the
directory hierarchies.  Get the appropriate sources (gzip, gnutar, compress),
compile them and link statically, put in the ~ftp/bin directory and edit the
appropriate file containing the definitions of the allowed conversions.
/usr/bin/tar is already statically-linked.  You may wish to use gnu tar
anyway.

Gary Mills wrote a small program to support the following:
I got compress from ftp.uu.net, in the root directory, I believe, and compiled
it.  To do tar and compress, I wrote a tiny program called `pipe', and
statically-linked it. My /etc/ftpconversions file looks like this:

#strip prefix:strip postfix:addon prefix:addon postfix:external command:
#types:options:description
 :.Z:  :  :/bin/compress -d -c %s:T_REG|T_ASCII:O_UNCOMPRESS:UNCOMPRESS
 :-z:  :  :/bin/compress -d -c %s:T_REG|T_ASCII:O_UNCOMPRESS:UNCOMPRESS
 :  :  :.Z:/bin/compress -c %s:T_REG:O_COMPRESS:COMPRESS
 :  :  :.tar:/bin/tar cf - %s:T_REG|T_DIR:O_TAR:TAR
 :  :  :.tar.Z:/bin/pipe /bin/tar cf - %s | /bin/compress -c:T_REG|T_DIR:O_COMPRESS|O_TAR:TAR+COMPRESS
 :  :  :.tar:/bin/gtar -c -f - %s:T_REG|T_DIR:O_TAR:TAR
 :  :  :.tar.Z:/bin/gtar -c -Z -f - %s:T_REG|T_DIR:O_COMPRESS|O_TAR:TAR+COMPRESS
 :  :  :.tar.gz:/bin/gtar -c -z -f - %s:T_REG|T_DIR:O_COMPRESS|O_TAR:TAR+GZIP

Here it is:
-----------------8<-------------cut---------------
/* pipe.c: exec two commands in a pipe */

#define NULL (char *)0
#define MAXA 16

main(argc, argv) int argc; char *argv[]; {
    char *av1[MAXA], *av2[MAXA];
    int i, n, p[2], cpid;                                                         
    i = 0; n = 0;
    while ( ++i < argc && n < MAXA ) {
        if ( *argv[i] == '|' && *(argv[i]+1) == '\0' ) break;
        av1[n++] = argv[i];
    }
    if ( n == 0 ) uexit();
    av1[n] = NULL;
    n = 0;
    while ( ++i < argc && n < MAXA )
      av2[n++] = argv[i];
    if ( n == 0 ) uexit();
    av2[n] = NULL;
    if ( pipe(p) != 0 ) exit(1);
    if ( ( cpid = fork() ) == (-1) ) exit(1);
    else if ( cpid == 0 ) {
        (void)close(p[0]);
        (void)close(1);
        (void)dup(p[1]);
        (void)close(p[1]);
        (void)execv(av1[0], av1);
        _exit(127);
    }
    else {
        (void)close(p[1]);
        (void)close(0);
        (void)dup(p[0]);
        (void)close(p[0]);
        (void)execv(av2[0], av2);
        _exit(127);                                                                   }
    /*NOTREACHED*/
}

uexit() {
    (void)write(2, "Usage: pipe <command> | <command>\n", 34);
    exit(1);
}



9) Other things to do:

as root:     touch ~ftp/.rhosts ~ftp/.forward
             chmod 400 ~ftp/.rhosts ~ftp/.forward

ie. make these files zero-length and owned by root.

Due to the last /bin/mail bugs in SunOS:

        touch /usr/spool/mail/ftp; chmod 400 /usr/spool/mail/ftp

Consider an email-alias for the ftp-admin(s) to provide an email-address for
problems-reports.

If you are mounting some disks from other machines (or even your own) to the
~ftp hierarchy, mount it read-only. The correct entry for the /etc/fstab (on
the host with ftpd) is something like:

other:/u1/linux /home/ftp/pub/linux nfs ro,noquota,nosuid,intr,bg 1 0

This mounts under /home/ftp/pub/linux the disk from host 'other' with no     
quota, no 'suid' programs (just in case), interruptible (in case 'other' 
goes down) and 'bg' - so if 'other' is down when you reboot it will not stop
you trying to mount /home/ftp/pub/linux all over again.                      



Part 2 - Setting up a chrooted Secure Anonymous ftp server.

This part was contributed by Marcus J Ranum <mjr@tis.com>

Steps
-----

1) Build a statically linked version of ftpd and put it in ~ftp/bin.
        Make sure it's owned by root.

2) Build a statically linked version of /bin/ls if you'll need one.
        Put it in ~ftp/bin. If you are on a Sun, and need to build
        one, there's a ported version of the BSD net2 ls command
        for SunOs on ftp.tis.com: pub/firewalls/toolkit/patches/ls.tar.Z
        Make sure it's owned by root.

3) Chown ~ftp to root and make it mode 755     THIS IS VERY IMPORTANT

4) Set up copies of ~ftp/etc/passwd and ~ftp/etc/group just as you would                  normally, EXCEPT make 'ftp's home directory '/'   -- make sure
        they are owned by root.

5) Write a wrapper to kick ftpd off and install it in /etc/inetd.conf
        The wrapper should look something like: (assuming ~ftp = /var/ftp)

main()
{
        if(chdir("/var/ftp")) {
                perror("chdir /var/ftp");
                exit(1);
        }
        if(chroot("/var/ftp")) {
                perror("chroot /var/ftp");
                exit(1);
        }
        /* optional: seteuid(FTPUID); */
        execl("/bin/ftpd","ftpd","-l",(char *)0);
        perror("exec /bin/ftpd");
        exit(1);
}

Options:
        You can use 'netacl' from the toolkit or tcp_wrappers to achieve
        the same effect.

        We use 'netacl' to switch so that a few machines that connect to
        the FTP service *don't* get chrooted first. This makes transferring
        files a bit less painful.
        You may also wish to take your ftpd sources and find all the places
        where it calls seteuid() and remove them, then have the wrapper do
        a setuid(ftp) right before the exec. This means that if someone
        knows a hole that makes them "root" they still won't be. Relax and
        imagine how frustrated they will be.

        If you're hacking ftpd sources, I suggest you turn off a bunch of
        the options in ftpcmd.y by unsetting the "implemented" flag in
        ftpcmd.y. This is only practical if your FTP area is read-only.

6) As usual, make a pass through the FTP area and make sure that the files
        are in correct modes and that there's nothing else in there that
        can be executed.

7) Note, now, that your FTP area's /etc/passwd is totally separated from
        your real /etc/passwd. This has advantages and disadvantages.

8) Some stuff may break, like syslog, since there is no /dev/log. Either
        build a version of ftpd with a UDP-based syslog() routine or
        run a second syslogd based on the BSD Net2 code, that maintains
        a unix-domain socket named ~ftp/dev/log with the -p flag.

REMEMBER:
        If there is a hole in your ftpd that lets someone get "root"
        access they can do you some damage even chrooted. It's just
        lots harder. If you're willing to hack some code, making the
        ftpd run without permissions is a really good thing. The
        correct operation of your hacked ftpd can be verified by
        connecting to it and (while it's still at the user prompt)
        do a ps-axu and verify that it's not running as root.                     


Part 3 - OS Specific needed information and suggestions.


Older SVR2 and SVR3 system, RTU 6.0 (Masscomp, now Concurrent Real Time UNIX),
AT&T 3B1 and 3B2 machines - May need dev/tcp:

[dev/tcp]

These ftpd implementations may require a ~ftp/dev/tcp in order for anonymous
ftp to work.  

You have to create a character special device with the appropriate major and
minor device numbers. The appropriate major and minor numbers of ~ftp/dev/tcp
are what the major and minor numbers of /dev/tcp are.

The ~ftp/dev is a directory and ~ftp/dev/tcp is a character special device. 
Make them owned and grouped by root. Permissions for ~ftp/dev is root
read/write/exec and other & group read and exec. The permissions for
~ftp/dev/tcp is root read/write, other & group read.



HPUX

[Logging] If you're using HP's native ftpd, the line in /etc/inetd.conf
should execute ftpd -l, which does extra logging.


SunOS

[Libraries] To set up SunOS to use its shared dynamic libraries, follow these
steps:

1) Create the directory ~ftp/usr.  This directory is owned by root with
permissions 555.

2) Create the directory ~ftp/usr/lib.  This directory is owned by root with
permissions 555. 

3) Copy the runtime loader ld.so into ~ftp/usr/lib for use by ls.  ld.so is
owned by root with permissions 555. 

4) Copy the latest version of the shared C library, libc.so.* into
~ftp/usr/lib for use by ls.  

libc.so.* is owned by root with permissions 555.

***4.1.2(or above) users: you also need to copy  /usr/lib/libdl.so.* to
~ftp/lib.

5) Create the directory ~ftp/dev.  This directory is owned by root with
permissions 111.

6) ~ftp/dev/zero is needed by the runtime loader.  Move into the directory
~ftp/dev and create it with the command: 

	mknod zero c 3 12

chown ~ftp/dev/zero to root.  Make sure it's readable.

***For novices: WARNING!! Don't try to copy /dev/zero to ~ftp/dev/zero!!
This is an endless file of zeroes and it will completely fill your filesystem!

7) If you want to have the local time showing when people connect, create the
directory ~ftp/usr/share/lib/zoneinfo and copy
/usr/share/lib/zoneinfo/localtime

8) If you are bothered by the need for copying your libraries so that you can
use Sun's 'ls', which is dynamically linked, you can try to get a statically
linked copy of 'ls' instead.  The CD-ROM that contains Sun's OS has a
statically-linked version of ls.  In this case, you can dispense with steps
#6-8.

Statically linked versions may be available from the following sources:

	If you want a statically linked "ls" get the GNU fileutils off a
archive site near you and statically link it. 

[Logging] Sun's standard ftpd logs *all* password information.  To correct it,
install patch:

101640-03       SunOS 4.1.3: in.ftpd logs password info when -d option is
used.   

In /etc/inetd.conf find the line that starts with "ftp".  At the
end of that line, it should read "in.ftpd".  Change that to "in.ftpd -dl". 
In /etc/syslog.conf, add a line that looks like:              
                       
daemon.*	               			/var/adm/daemonlog


Note that the whitespace between the two columns must include at least one
TAB character, not just spaces, or it won't work.  Of course your log file
could be anything you want.  Then, create the logfile (touch
/var/adm/daemonlog should do).  Finally, restart inetd and syslogd, either
individually, or by rebooting the system.  You should be good to go.  If you
do not install the patch, make sure the log file is owned by root and mode
600, as the ftp daemon will log *everything*, including users' passwords.





Part 4 - Where to get other FTP daemons

Wuarchive FTP 2.4- A secure FTP daemon that allows improved access-control,
logging, pre-login banners, and is very configurable: 
	Can be ftp'd from ftp.uu.net in "/networking/ftp/wuarchive-ftpd"
directory.  Be certain to verify the checksum information to confirm that you
have retrieved a valid copy. [Warning: Older versions of Wu-FTP are extremely
insecure and in some cases have been trojaned.]

                        BSD        SVR4         
     File               Checksum   Checksum    MD5 Digital Signature
     -----------------  --------   ---------   --------------------------------
     wu-ftpd-2.4.tar.Z  38213  181  20337 362  cdcb237b71082fa23706429134d8c32e
     patch_2.3-2.4.Z    09291    8  51092  16  5558a04d9da7cdb1113b158aff89be8f

     For DECWRL ftpd, sites can obtain version 5.93 via anonymous FTP
     from gatekeeper.dec.com in the "/pub/misc/vixie" directory.

                        BSD        SVR4         
     File               Checksum   Checksum    MD5 Digital Signature
     -----------------  --------   --------- --------------------------------
     ftpd.tar.gz        38443  60  1710 119  ae624eb607b4ee90e318b857e6573500

     For BSDI systems, patch 005 should be applied to version 1.1 of
     the BSD/386 software.  You can obtain the patch file via
     anonymous FTP from ftp.bsdi.com in the "/bsdi/patches-1.1"
     directory.

                        BSD        SVR4         
     File               Checksum   Checksum    MD5 Digital Signature
     -----------------  --------   ---------   --------------------------------
     BU110-005          35337 272  54935 543   1f454d4d9d3e1397d1eff0432bd383cf


Public Domain Sources:
   ftp.uu.net            ~ftp/systems/unix/bsd-sources/libexec/ftpd
   gatekeeper.dec.com    ~ftp/pub/DEC/gwtools/ftpd.tar.Z


Part 5 - Archie

Searches FTP sites for programs.  Login into these sites as archie
or use client software for faster access.  To get your own anonymous
site added to Archie's search list, e-mail archie-updates@bunyip.com.

    archie.ac.il               132.65.20.254    (Israel server)
    archie.ans.net             147.225.1.10     (ANS server, NY (USA))
    archie.au                  139.130.4.6      (Australian Server)
    archie.doc.ic.ac.uk        146.169.11.3     (United Kingdom Server)
    archie.edvz.uni-linz.ac.at 140.78.3.8       (Austrian Server)
    archie.funet.fi            128.214.6.102    (Finnish Server)
    archie.internic.net        198.49.45.10     (AT&T server, NY (USA))
    archie.kr                  128.134.1.1      (Korean Server)
    archie.kuis.kyoto-u.ac.jp  130.54.20.1      (Japanese Server)
    archie.luth.se             130.240.18.4     (Swedish Server)
    archie.ncu.edu.tw          140.115.19.24    (Taiwanese server)
    archie.nz                  130.195.9.4      (New Zealand server)
    archie.rediris.es          130.206.1.2      (Spanish Server)
    archie.rutgers.edu         128.6.18.15      (Rutgers University (USA))
    archie.sogang.ac.kr        163.239.1.11     (Korean Server)
    archie.sura.net            128.167.254.195  (SURAnet server MD (USA))
    archie.sura.net(1526)      128.167.254.195  (SURAnet alt. MD (USA))
    archie.switch.ch           130.59.1.40      (Swiss Server)
    archie.th-darmstadt.de     130.83.22.60     (German Server)
    archie.unipi.it            131.114.21.10    (Italian Server)
    archie.univie.ac.at        131.130.1.23     (Austrian Server)
    archie.unl.edu             129.93.1.14      (U. of Nebraska, Lincoln (USA))
    archie.uqam.ca             132.208.250.10   (Canadian Server)
    archie.wide.ad.jp          133.4.3.6        (Japanese Server)



Part 6 - Acknowledgements

Thanks to the following people for suggestions that help shape this FAQ:

Tomasz Surmacz (tsurmacz@asic.ict.pwr.wroc.pl)
Wolfgang Ley (Ley@rz.tu-clausthal.de) 
Russel Street (russells@ccu1.auckland.ac.nz) 
Gary Mills (mills@CC.UManitoba.CA) 
Morten Welinder (terra@diku.dk) 
Nick Christenson (npc@minotaur.jpl.nasa.gov) 
Mark Hanning-Lee (markhl@romoe.caltech.edu)
Marcus J Ranum <mjr@tis.com>


Copyright

This paper is Copyright (c) 1994 by Christopher Klaus

	Permission is hereby granted to give away free copies.  You may 
distribute, transfer, or spread this paper.  You may not pretend that you
wrote it.  This copyright notice must be maintained in any copy made.  


Disclaimer

	The information within this paper may change without notice. Use of
this information constitutes acceptance for use in an AS IS condition.
There are NO warranties with regard to this information. In no event shall
the author be liable for any damages whatsoever arising out of or in
connection with the use or spread of this information.  Any use of this
information is at the user's own risk.



Address of Author

	Please send suggestions, updates, and comments to:	
 
	Christopher Klaus <cklaus@shadow.net>
-- 
Christopher William Klaus  <cklaus@shadow.net>  <iss@shadow.net>
Internet Security Systems, Inc.   
2209 Summit Place Drive,Dunwoody 
GA 30350-2430. (404)998-5871.



Archive-name: computer-security/compromise-faq 
Posting-frequency: monthly
Last-Modified: 1994/04/28
Version: 1.5


	Compromise:  What if your Machines are Compromised by an Intruder.

	This FAQ deals with some suggestions for securing your Unix machine
after it has already been compromised.  Even if your machines have not been
compromised, there are many helpful tips on securing machine in this paper. 
I would appreciate any suggestions.  This FAQ will be posted monthly.  


1.  Try to trace/follow the intruder back to his origin via looking at 
  a) who
  b) w
  c) last
  d) lastcomm
  e) netstat
  f) snmpnetstat
  g) and router information. 
  h) /var/adm/messages (many crackers send e-mail to their "home" accounts)
  i) syslog (sends logs to other hosts as well)
  j) wrapper logs
  k) do a 'finger' to all local users(and check where they last logged in from)


	Footnote: 'who', 'w', 'last', and 'lastcomm' are commands that  rely
on /var/adm/pacct, /usr/adm/wtmp, and /etc/utmp to report the information to
you.  Most backdoors will keep the intruder from being shown in these logs. 
Even if the intruder has not installed any backdoors yet, it is trivial to
remove any detection in these logs.  But they may just forget about one or two
of them.  Especially if you have some additional, non-standard ones.


	Suggestion: Install xinetd or tcp_wrapper that will log all 
connections to your machine to see if someone is knocking on its doors.
Forward syslogs to another machine so intruder will not easily detect  the
logs and modify. Other possibilities: netlog from net.tamu.edu:/pub/security.


	It might be wise to monitor the intruder via some ethernet sniffer
to see how he is exploiting his systems before taking corrective measures.

2.  Close the machine from outside access.  Remove from network to stop
further access via intruder.  If the intruder finds out that the
administrator is unto him, he may try to hide his tracks by rm -rf /.  

3.  Check the binaries with the originals.  Especially check the following
binaries because they are commonly replaced backdoors for regaining access: 

  a) /bin/login
  b) all the /usr/etc/in.* files (ie. in.telnetd)
  c) and /lib/libc.so.* (on Suns).
  d) anything called from inetd


	Other commonly replaced backdoor binaries:
  a) netstat - allows hiding connections
  b) ps - allows hiding processes (ie Crack)
  c) ls - allows hiding directories
  d) ifconfig - hides the fact that promiscuity mode is on the ethernet
  e) sum - fools the checksum for binaries, not necessarily replaced anymore
because its possible to change the checksum of the binaries to the correct
value without modifying sum. *EMPHASIZE* Do NOT Rely on sum.

	Use 'ls -lac' to find the real modification time of files.  Check
/etc/wtmp (if you still have one) for any system time adjustments.  Check the
files with the distribution media (CD or tape) or calculate MD5 checksums and
compare them with the originals kept offline (you did calculate them sometime
ago, didn't you?) Suggestion: cmp(1) the files with copies that are known to
be good.

	Another popular backdoor is suid'ing a common command (ie.
/bin/time) to allow root access with regular accounts.

To find all suid programs you may use:

        find / -type f -perm -4000 -ls


	To be thorough you may need to re-load the entire OS to make sure
there are no backdoors.  Tripwire helps prevent modifying binaries and system
files (ie. inetd.conf) on the system, without the administrator knowing.

4.  Implement some password scheme for your users to verify that they change
their passwords often.  Install anlpasswd, npasswd, or passwd+ in place of
passwd (or yppasswd) so that your users are forced to set reasonable
passwords. Then run Crack to make sure that your users aren't bypassing the
password check.  Crack ensures that users are picking difficult passwords. 
With the network, clear text passwords are a problem.  Other possible
choices:  smart hubs (stops ethernet sniffing of the whole LAN) and one-time
password technology.


5.  Check all the users' .rhosts and .forward files to make sure none of them
are weird or out of the ordinary. If .rhosts file contains '+ +', the account
can be accessed anywhere by anyone without a password.  COPS has a scripts
for checking .rhosts.

         find / -name .rhosts -ls -o -name .forward -ls

Look also for all the files created/modified in the time you are suspecting
the break-in has taken place, eg:

        find / -ctime -2 -ctime +1 -ls

To find all the files modified not less than one day ago, but not more than 2.

All .login, .logout, .profile, .cshrc files are also worth looking at (at
least for the modification date/time).  Make sure there are no '.rhosts' for
the locked or special accounts (like 'news', 'sundiag', 'sync', etc.)        
The shell for such accounts should be something like '/bin/false' anyway (and
not '/bin/sh') to make them more secure. Also search for directories that have
like ". ", ".. " as names.  They are usually found in /tmp , /var/tmp,
/usr/spool/* and any other publicly writeable directory.


6.  Check to make sure your NFS exports are not world writable to everyone.
NFSwatch, a program by David Curry, will log any NFS transactions that are
taking place.  Try 'showmount -e' to see whether system agrees with your
opinion of what are you exporting and where.  There are bugs in some nfsd
implementations which ignore the access lists when they exceed some limit (256
bytes).  Check also what are you IMPORTING!!!  Use 'nosuid' flag whenever
possible. You do not want to be cracked by a sysadm from another host (or a
cracker there) running suid programs mounted via NFS, do you?


7.  Make sure you have implemented the newest sendmail daemon. Old sendmail
daemons allowed remote execution of commands on any Unix machine. See the
computer-security/security-patch FAQ.

8.  Try to install all the security patches available from the vendor on your
machine.  See the computer-security/security-patch FAQ.

9.  Here is a check list:

 o Do an rpcinfo -p  on your machine to make sure it is not running any
processes that are not needed. (ie. rexd). 

 o Check for '+' in /etc/hosts.equiv.

 o Check whether tftp is disabled on your system.  If not - disable it, or at
least use '-s' flag to chroot it to some safe area, if you really can't live
without it (it is mostly used for booting up Xterminals, but sometimes can be
avoided by NFS-mounting appropriate disks).  Under no circumstances you should
run it as root.  Change the line describing it in /etc/inetd.conf to something
like:

    tftp dgram  udp  wait  nobody  /usr/etc/in.tftpd  in.tftpd -s /tftpboot

or better yet, use tcpd wrapper program to protect it from addresses which
should not get access to tftp and log all other connections:

    tftp dgram  udp  wait  nobody  /usr/etc/tcpd  in.tftpd -s /tftpboot

and edit appropriately /etc/hosts.allow to restrict access to in.tftpd to
only those addresses that really need it.                                      

 o Check crontabs and at-jobs.  Make sure there are no delayed bombs which
will explode after you think you have got rid of all the nasty things left by
a intruder.

 o Check /etc/rc.boot /etc/rc.local  (SYSV: /etc/rc?.d/* ) and other files
cruicial for the system startup.  (The best would be if you could compare them
with the copies kept off-line).  Check all other files containing system
configuration (sendmail.cf, sendmail.fc, hosts.allow, at.allow, at.deny,
cron.allow, hosts, hosts.lpd, etc.)  In 'aliases' look for aliases expanding
to some unusual programs (uudecode is one but example).

 o Check your inetd.conf and /etc/services files to find if there are no
additional services set up by an intruder.

 o Copy all the log files you still have (pacct, wtmp, lastlog, sulog, syslog,
authlog, any additional logs you have set up earlier) to some safe place
(offline) so you may examine them later.  Otherwise, do not be surprised if
they disappear the next day when the cracker realises he forgot to remove one
of them.  Use your own imagination to find what other traces he could have
left in your system (What about /tmp/* files?  Check them BEFORE you reboot).

 o Make backup copy of /etc/passwd (best offline) then change all root
passwords (after verifying that 'su' and 'passwd' are not the trojan versions
left by an intruder).  It may sound like a horrible thing to do         
(especially if you have something like 2000 users) but *do* lock them all by
putting '*' in the password field.  If the intruder has a copy of your
passwords file he may possibly sooner or later guess all the passwords
contained there (It is all the matter of proper dictionaries).  In fact he    
could have inserted few passwords that he only knows for some users who for
example have not logged in for a long time.

	On the NIS servers check not only the real /etc/passwd /etc/groups etc
files but also those used for building NIS maps (if they are different).

 o Check if your anonymous ftp (and other services) are configured properly
(if you have any of course)  See the computer-security/anonymous-ftp FAQ.

 o If you want to make your life easier next time (or if you still cannot get
rid of an intruder) consider installing 'ident' daemon.  Together with tcpd on
a set of hosts it can be used to find what accounts the intruder is using.

 o Make sure the only 'secure' terminal is console (if at all).  This way you
prevent root logins just from the net.  Maybe it is not a big deal as if
somebody knows the root password he may already know other peoples' passwords
too, but maybe not?

 o And remember...  There are so many ways that somebody could have modified
your system, that you really have to have your eyes and ears wide open for a
loooooong long time.  Above, are the pointers just to the most obvious things
to check.


10.  Mail all the sites that you were able to find out that the intruder was
going through and warn them.  Also, CC: cert@cert.org.  Check all the sites in
your near-by, ie. in your domain/institution/whatever.  It's usually trivial
for a hacker to get to another system by a simple 'rlogin' if the two systems
have a common subset of users (and using .rhosts to make the access easier).


11.  A preventive from stopping many intruders from even trying your network
is to install a firewall.  

	Side-effects: Firewalls may be expensive; filtering may slow down the
network. Consider blocking nfs (port 2048) and portmap(111) on your router.
The authentication and access controls of these protocols is often minimal. 
Suggestion: Block all udp ports except DNS and NTP ports. Kill all source
routing packets.  Kill all ip-forwarding packets.


Acknowledgements

Thanks to the following people for adding and shaping this FAQ:

Tomasz Surmacz <tsurmacz@asic.ict.pwr.wroc.pl>
Wes Morgan (morgan@engr.uky.edu)
Peter Van Epp <vanepp@sfu.ca>
Richard Jones <electron@suburbia.apana.org.au>
Wieste Venema <wietse@wzv.win.tue.nl>


Copyright

This paper is Copyright (c) 1994 by Christopher Klaus

	Permission is hereby granted to give away free copies.  You may 
distribute, transfer, or spread this paper.  You may not pretend that you
wrote it.  This copyright notice must be maintained in any copy made.  


Disclaimer

	The information within this paper may change without notice. Use of
this information constitutes acceptance for use in an AS IS condition.
There are NO warranties with regard to this information.  In no event shall
the author be liable for any damages whatsoever arising out of or in
connection with the use or spread of this information.  Any use of this
information is at the user's own risk.



Address of Author

	Please send suggestions, updates, and comments to:	
 
	Christopher Klaus <cklaus@shadow.net>


-- 
Christopher William Klaus  <cklaus@shadow.net>  <iss@shadow.net>
Internet Security Systems, Inc.   
2209 Summit Place Drive,Dunwoody 
GA 30350-2430. (404)998-5871.



Archive-name: computer-security/security-patches 
Posting-frequency: monthly
Last-modified: 1994/28/04
Version: 0.1

	Security Patches FAQ for your System: The Complete List


	As new systems become accessible by networks there is a need for
security.  Many systems are shipped by default insecure which puts the
responsibility on the customers to get and apply patches.  This FAQ will be a
guide for the many administrators who want to secure their systems.

	This FAQ will be broken down into the different sections:
1) Type of Operating System and its Vulnerabilities.
2) Particular Vulnerabilities (ie. rdist and sendmail)

	This is an alpha version.

1) Type of Operating System and its Vulnerabilities

Sun Microsystems, Inc.  SunOS 4.0.3/4.1/4.1.1 

	Patches may be obtained via anonymous ftp from ftp.uu.net (in the
sun-dist directory) or from local Sun Answer Centers worldwide.

100075-09	rpc.lockd jumbo patch
100103-11	script to change file permissions to a more secure mode
100170-09	jumbo-patch ld-1.144 shared LD_LIBRARY_PATH -Bstatic SPARCworks
100173-09	NFS Jumbo Patch
100178-07	netd "broken server detection" breaks on fast machines
100249-04	automounter jumbo patch
100272-07	dump,in.comsat,syslogd,in.talkd,shutdown,write utmp writable
100283-03	in.routed mishandles gateways, multiple routes
100296-04	netgroup exports to world
100296-04       rpc.mountd exports to the world
100305-09	lpd can be used to delete any file on the system
100305-13       lpr package
100338-05	system crashes with assertion failed panic
100342-03	NIS client needs long recovery time if server reboots
100359-06	streams jumbo patch
100377-05	Sendmail.mx doesn't recognize wildcard, forward, uid's > 32767
100377-07       sendmail + sendmail.mx
100383-05	rdist security enhancement
100383-06       rdist can be used to get root access
100421-03       rpc.rexd does not log appropriate accounting messages
100448-01       loadmodule security problem
100482-03	ypserv sends maps to anyone who guesses domainname
100482-04       ypxfrd exporting NIS maps to everybody
100507-04	tmpfs jumbo patch
100527-03	rsh uses old-style selects instead of 4.0 selects
100536-02	NFS can cause panic: assertion failed crashes
100557-02	ftp Jumbo patch
100564-03	C2 Jumbo patch
100567-03	mfree panic due to mbuf being freed twice
100593-03	dump,in.comsat,syslogd,in.talkd,shutdown,write utmp writable
100623-02	UFS jumbo patch
100909-02	dump,in.comsat,syslogd,in.talkd,shutdown,write utmp writable
101480-01	dump,in.comsat,syslogd,in.talkd,shutdown,write utmp writable
101481-01	dump,in.comsat,syslogd,in.talkd,shutdown,write utmp writable
101482-01	dump,in.comsat,syslogd,in.talkd,shutdown,write utmp writable

Patch the following:

Turn off IP Forwarding

Turn off Source Routings

Turn on NFS Priv Port Checking

Remove /dev/nit





2) Particular Vulnerabilities

Sendmail Patches

        SunOS 5.x       101077-06
        SunOS 4.1.x     100377-07


Rdist Patches

Apollo Domain/OS SR10.3 and SR10.3.5 (Fixed in SR10.4)

a88k PD92_P0316
m68k PD92_M0384

Cray Research, Inc. UNICOS 6.0/6.E/6.1  Field Alert #132   SPR 47600

IBM  RS/6000 AIX levels 3005, 2006, 2007, and 3.2  apar ix23738
Patches may be obtained by calling Customer Support at 1-800-237-5511.

MIPS  RISCos versions 4.50 through 4.52 (not required for 5.0)
      Patches are available via anonymous ftp at ftp.mips.com.
      The file is /pub/rdist.CERT.tar.

NeXT Computer, Inc.  NeXTstep Release 2.x
     Rdist available on the public NeXT FTP archives.

Silicon Graphics   IRIX 3.3.x/4.0 (fixed in 4.0.1)
        Patches may be obtained via anonymous ftp from sgi.com in the
        sgi/rdist directory.

Solbourne	OS/MP 4.1A	Patch ID P911121003

Sun Microsystems, Inc.  SunOS 4.0.3/4.1/4.1.1  Patch ID 100383-03



Copyright

This paper is Copyright (c) 1994 by Christopher Klaus

	Permission is hereby granted to give away free copies.  You may 
distribute, transfer, or spread this paper.  You may not pretend that you
wrote it.  This copyright notice must be maintained in any copy made.  


Disclaimer

	The information within this paper may change without notice. Use of
this information constitutes acceptance for use in an AS IS condition.
There are NO warranties with regard to this information. In no event shall
the author be liable for any damages whatsoever arising out of or in
connection with the use or spread of this information.  Any use of this
information is at the user's own risk.



Address of Author

	Please send suggestions, updates, and comments to:	
 
	Christopher Klaus <cklaus@shadow.net>


-- 
Christopher William Klaus  <cklaus@shadow.net>  <iss@shadow.net>
Internet Security Systems, Inc.   
2209 Summit Place Drive,Dunwoody 
GA 30350-2430. (404)998-5871.



Archive-name: computer-security/vendor-contacts 
Posting-frequency: monthly
Last-modified: 1994/04/28
Version: 1.4

"It [Vendor Security Contact FAQ] is the kind of thing that makes you look
good at work when your boss decides he's joe security and wants a patch (for
like rdist - duh!) yesterday..." -- Tim Scanlon, System Analyst



	Vendor Security Contacts: Reporting Vulnerabilities 
	and Obtaining New Patches


	The following FAQ is a list of security contacts to reach at various
vendors for reporting security vulnerabilities and obtaining new security
related patches.  
	With the rising number of people and hosts gaining access to the
Internet, the basic integrity of the Net needs to be maintained.  Many of
security incidents that happen on Internet could have been avoided by
installing security patches that are available by vendors.  It is important
to get the recent patches and ensure that your systems are configured
properly.  With intruders and their underground network having quick access
to security vulnerabilities, it is important that administrators have
security information available and not rely on just One organization.

	Here are the security contacts that information is available for:
A/UX, Cray, Dec, HP, IBM, Next, SCO, SGI, and Sun.  

	When reporting a new security bug, try to be as specific as
possible about how to reproduce it, which OS release (uname -a), and any
other release numbers of software that are involved.




A/UX

Contact information for A/UX as follows:

Send security related information to the following people:
	Erik E. Fair fair@apple.com
	and CC: staff@apple.com

	antonio@aux.support.apple.com (A/UX support person).




Cray

Contact information for Cray as follows:

Cray Research customers should first direct questions and concerns to on-site
support personnel (if provided by their service contract).  Other contacts
should be made through the

  Technical Service Center
  Cray Research, Inc.
  655F Lone Oak Drive
  Eagan MN 55121 
  USA

  tel. +1-612-683-5600
  email. support@cray.com



Dec

Contact information for Dec as follows:

Send security related information to the following people:

FIRST Contact:  Rich Boren rich.boren@cxo.mts.dec.com (719) 592-4689
        
Security patches are issued by Customer Support Centers.




HP

Contact information for HP as follows:

        
	For security concerns, questions, or problems, you can contact:
        
        security-alert@hp.com

	
Obtaining Patches:

The HP SupportLine mail service is available to anyone who can send electronic
mail via the Internet.

If you have access to the Internet or can send electronic mail via an Internet
mail forwarder, you can use the HP SupportLine mail service.


********************************************************************************
*                How do I access the HP SupportLine mail service?              *
********************************************************************************


o  To obtain a copy of the HP SupportLine mail service user's guide, send the
following in the TEXT PORTION OF THE MESSAGE to support@support.mayfield.hp.com
(no Subject is required):

   send guide

Note: The HP SupportLine mail service user's guide is formatted using nroff. If
you would like an ASCII version of the user's guide or if you are utilizing a
non-UNIX mail reader, replace "send guide" with "send guide.txt".

o  Once your request is received, the HP SupportLine mail service will send you
a copy of the user's guide.

o  If you encounter any problems using the HP SupportLine mail service, report
them to support-feedback@support.mayfield.hp.com

********************************************************************************
*                     What mailing lists are available?                        *
********************************************************************************

The following is a list of all mailing lists available via the HP SupportLine
mail service:

mailing_list_name    Description
-----------------    -----------
hpux_all_patch       weekly digest of all new hp-ux patches
hpux_300_patch       weekly digest of all new hp-ux s300_400 patches
hpux_700_patch       weekly digest of all new hp-ux s700 patches
hpux_800_patch       weekly digest of all new hp-ux s800 patches

dom_all_patch        weekly digest of all new domain patches
dom_m68k_patch       weekly digest of all new domain m68k patches
dom_a88k_patch       weekly digest of all new domain a88k patches

technical_tips       weekly digest of new HP Technical Tips
existing_news        monthly digest of new Existing Product News
general_news         monthly digest of new HP General News
new_products         monthly digest of new HP Product Information
security_info        Latest digest of new HP Security Bulletins
security_info_list   Index of available HP Security Bulletins


o  To subscribe to an  HP SupportLine mail service mailing list, send the
following in the TEXT PORTION OF THE MESSAGE to support@support.mayfield.hp.com
(no Subject is required):

   subscribe mailing_list_name  (i.e. subscribe hpux_all_patch)

On a weekly or monthly basis, the HP SupportLine mail service will create and
distribute the requested mailing_list_name digest directly to your mailbox.


********************************************************************************
*                     How do i get a Patch from HP?                            *
********************************************************************************

If you know the name of the patch needed, Email to:

support@support.mayfield.hp.com 

with the body of the message stated as:

"send PHKL_9999"

The patch will automatically be mailed back to you with a mail unpacker 
script (patch_maker).

If you just want the README for the patch, Email a message to:

support@support.mayfield.hp.com

with the body of the message stated as:

"send doc PHKL_9999"

The patch README will be mailed back to you.

       
	Response Center Customers: 1-800-633-3600
        BasicLine Customers:  1-415-691-3888
        Also try email to bkelley@cup.hp.com

        Outside the U.S., contact your local Response Center.




IBM

Contact information for IBM as follows:


  IBM support @ 1-800 237-5511
  Email to services@austin.ibm.com 
       

  Send security related information to Nick Trio (nrt@watson.ibm.com,
a.k.a. postmaster@ibm.com) Unix person on IBM's Computer Emergency Response
Team) and Alan Fedeli (fedeli@vnet.ibm.com).

  There are some security patches on anonymous FTP software.watson.ibm.com
in pub/aix3 for AIX.

Security patches are issued through your IBM sales office.

Some of the following patches that are available are:
Patch: ix22628   Fix: Corrects TFTP from allowing people to grab /etc/passwd.



Next

Contact information for Next as follows:

Technical Support at "ask_next@next.com"   
Phone number: 800.848.6398.

Address is 900 Chesapeake Drive; Redwood City, CA; 94063.



SCO

Contact information for The Santa Cruz Operation (SCO):

Send security related information to:

  security-alert@sco.com

Security patches are issued on an as-needed basis and will be available
at ftp.sco.com and its mirrors.

When submitting information about a security problem, please include
output of the following commands:

  uname -X
  swconfig
  hwconfig -h        (if hardware-related)

and as much detail about the problem as you can muster.



SGI

Contact information for SGI as follows:
 
Send security related information to:

  security-alert@sgi.com

If there is no response, try Dave Olson olson@anchor.esd.sgi.com.

	Support line 1-800-800-4SGI and ask what patches are available.
	
	There are some security patches on anonymous FTP sgi.com in
directory sgi/IRIX4.0 (or 5.0 if the system is IRIX5).

Security patches are issued through your SGI sales office.



Sun

Contact information for Sun as follows:

  email: security-alert@sun.com
  phone: 415-688-9081
  Fax:   415-688-9101

postal:
  Sun Security Coordinator
  MS MPK2-04
  2550 Garcia Avenue
  Mountain View, CA 94043-1100

Sun produces "Sun Security Bulletin" - ask security coordinator for it.


Other Resources

   The CERT (Computer Emergency Response Team) advisory mailing list.  Send
e-mail to cert@cert.org, and ask to be placed on their mailing list.  Past
advisories and other information related to computer security are available
for anonymous FTP from cert.org (192.88.209.5).

   The CIAC (Computer Incident Advisory Capability) of DoE.  To report a
vulnerability, call CIAC at (510) 422-8193 or send e-mail to ciac@llnl.gov.
Previous CIAC bulletins and other information is available via anonymous
ftp from irbis.llnl.gov (ip address 128.115.19.60).  


Standard Form From CERT

Here is the form CERT provides for reporting new vulnerabilities found
in Unix platforms.

			CERT Coordination Center
		Product Vulnerability Reporting Form


			 Reporter Information

Reporter name			: 
Reporter e-mail			: 
Reporter phone / fax		:
Reporter affiliation and address: 

Reported to vendor: Y/N
	Date of report		: 
	Vendor contact name	: 
	Vendor contact phone	:
	Vendor contact e-mail	: 
	Vendor reference number	: 
		

===============================================================================
			     Policy Info

Reporter Considerations
	Pass name to vendor?	: 
	Use name in advisory?	: 

Special considerations (e.g. restrictions on dissemination): 

===============================================================================
			    Technical Info

Vulnerability number (after assigned by CERT)	: 

Problem Description: 

Impact: 

Currently being exploited?	: Y/N

Exploitation: 

Systems and/or configurations vulnerable
	System		: 
	OS version	: 
	Verified/Guessed: 

Workarounds and/or fixes: 

Problem Analysis: 

Source code, logs, or other supporting technical info: 



Acknowledgements

Thanks Dave Millar for helping provide a portion of the information.


Copyright

This paper is Copyright (c) 1994 by Christopher Klaus

	Permission is hereby granted to give away free copies.  You may 
distribute, transfer, or spread this paper.  You may not pretend that you
wrote it.  This copyright notice must be maintained in any copy made.  


Disclaimer

	The information within this paper may change without notice. Use of
this information constitutes acceptance for use in an AS IS condition.
There are NO warranties with regard to this information. In no event shall
the author be liable for any damages whatsoever arising out of or in
connection with the use or spread of this information.  Any use of this
information is at the user's own risk.



Address of Author

	Please send suggestions, updates, and comments to:	
 
	Christopher Klaus <cklaus@shadow.net>



-- 
Christopher William Klaus  <cklaus@shadow.net>  <iss@shadow.net>
Internet Security Systems, Inc.   
2209 Summit Place Drive,Dunwoody 
GA 30350-2430. (404)998-5871.
