From: Christopher Klaus,cklaus@anshar.shadow.net Reply-To: cklaus,cklaus@shadow.net Newsgroup: comp.answers,news.answers,alt.answers,alt.security,comp.security.misc,comp.security.unix,comp.unix.admin Receive-Date: Mittwoch, 15-Mär-95 00:51:38 Creation-Date: Donnerstag, 09-Mär-95 20:05:02 Message-ID: 3jnn1e$dcn@anshar.shadow.net Date: Thu, 9 Mar 1995 20:05:02 GMT Subject: computer-security/vendor-contacts FAQ Organization: ISS, Inc. Followup-To: poster X-Newsreader: TIN [version 1.2 PL2] UserFlags: Old ReadAccess GlobalFlags: Exported Link HardLink Archive-name: computer-security/vendor-contacts Posting-frequency: monthly Last-modified: 1995/01/02 Version: 2.0 Vendor Contacts FAQ Version: 2.0 ------------------------------------------------------------------------ This Security FAQ is a resource provided by: Internet Security Systems, Inc. 2000 Miller Court West Tel: (404) 441-4531 Norcross, Georgia 30071 Fax: (404) 441-2431 - Computer Security Consulting - Penetration Analysis of Networks - ------------------------------------------------------------------------ To get the newest updates of Security files check the following services: mail info@iss.net with "send index" in message http://iss.net/~iss ftp iss.net /pub/ ------------------------------------------------------------------------ "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 Research Dec HP IBM Next Novell SCO SGI Sun Other important security contacts included are: CERT Contact CIAC Contact 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 ------------------------------------------------------------------------ Cray Research Contact information for Cray Research 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: Technical Service Center Cray Research, Inc. 655F Lone Oak Drive Eagan MN 55121 USA tel. +1-612-683-5600 email. support@cray.com ------------------------------------------------------------------------ DEC, Digital Equipment Corporation Contact information for DEC is as follows: Send security related information to the following person: FIRST Contact: Rich Boren rich.boren@cxo.mts.dec.com, (719) 592-4689 Security patches are issued by Customer Support Centers. ------------------------------------------------------------------------ HP, Hewlett Packard Contact information for HP as follows: For security concerns, questions, or problems, you can contact: security-alert@hp.com Obtaining Patches: Patches and mailing lists are available through the HP SupportLine service. More information is available in their bulletin. The HP SupportLine mail service is available to anyone who can send electronic mail via the Internet. ------------------------------------------------------------------------ IBM, International Business Machines 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. ------------------------------------------------------------------------ Novell, Inc. Contact information for Novell as follows: Phone number: 800-4-UNIVEL Security patches are available from: Compuserve ftp from ftp.novell.com floppy from the Novell support folks ------------------------------------------------------------------------ NeXT Contact information for Next as follows: Technical Support: ask_next@next.com Phone number: 800.848.6398 Address: 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 - Silicon Graphics Incoporated Contact information for SGI as follows: Send security related information to: security-alert@sgi.com If there is no response, try Dave Olson (olson@sgi.com) or Miguel Sanchez (miguel@sgi.com). Inside US: Support line: 1-800-800-4SGI Outside US/Canada: Contact your local SGI support provider FTP Site: ftp.sgi.com (192.48.153.1) When available, patches are placed in the directories security sgi/IRIX4.0 sgi/IRIX5.0 ------------------------------------------------------------------------ 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 For reporting security vulnerabilities and problems, Sun strongly recommends that you report problems to your local Answer Center and your representative computer security response team, such as CERT. In some cases your local Answer Center will accept a report of a security bug even if you do not have a support contract. An additional notification to the security-alert alias is suggested but should not be used as your primary vehicle for reporting a bug. Sun Security Bulletins Sun Security Bulletins are available free of charge as part of our Customer Warning System. It is not necessary to have a Sun support contract in order to receive them. To subscribe to this bulletin series, send mail to the address "security-alert@Sun.COM" with the subject "subscribe CWS your-mail-address" and a message body containing affiliation and contact information. To request that your name be removed from the mailing list, send mail to the same address with the subject "unsubscribe CWS your-mail-address". Do not include other requests or reports in a subscription message. Due to the volume of subscription requests Sun receives, Sun cannot guarantee to acknowledge requests. Please contact the security office if you wish to verify that your subscription request was received, or if you would like your bulletin delivered via postal mail or fax. Sun Security Bulletins are archived on ftp.uu.net (in the same directory as the patches) and on SunSolve. Please try these sources first before contacting the security office for old bulletins. ------------------------------------------------------------------------ Other Resources ------------------------------------------------------------------------ CERT (Computer Emergency Response Team) The CERT (Computer Emergency Response Team). To report a vulnerability contact CERT at: E-mail: cert@cert.org Past advisories and other information related to computer security are available for anonymous FTP from cert.org (192.88.209.5). See the Security Resources FAQ for more information on CERT and vulnerability reporting forms. ------------------------------------------------------------------------ CIAC (Computer Incident Advisory Capability) The CIAC (Computer Incident Advisory Capability) of DoE. To report a vulnerability, contact CIAC at voice: 510-422-8193 fax: 510-423-8002 stu-iii: 510-423-2604 or mail ciac@llnl.gov. Previous CIAC bulletins and other information is available via anonymous ftp from ciac.llnl.gov (ip address 128.115.51.53). See the Security Resources FAQ for more information on CIAC advisories and mailing lists. ------------------------------------------------------------------------ Acknowledgements Thanks go to the following people for providing new or updated information to be included in this FAQ: Dave Millar for helping provide a portion of the information. Steve Cooper, spcooper@llnl.gov ------------------------------------------------------------------------ Copyright This paper is Copyright (c) 1994, 1995 by Christopher Klaus of Internet Security Systems, Inc. Permission is hereby granted to give away free copies electronically. You may distribute, transfer, or spread this paper electronically. You may not pretend that you wrote it. This copyright notice must be maintained in any copy made. If you wish to reprint the whole or any part of this paper in any other medium excluding electronic medium, please ask the author for permission. 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 of Internet Security Systems, Inc. -- Christopher William Klaus Voice: (404)441-2531. Fax: (404)441-2431 Internet Security Systems, Inc. Computer Security Consulting 2000 Miller Court West, Norcross, GA 30071 From: Christopher Klaus,cklaus@anshar.shadow.net Reply-To: cklaus,cklaus@shadow.net Newsgroup: comp.answers,alt.answers,news.answers,alt.security,comp.security.misc,comp.security.unix,comp.unix.admin Receive-Date: Mittwoch, 15-Mär-95 00:51:40 Creation-Date: Donnerstag, 09-Mär-95 20:16:38 Message-ID: 3jnnn6$e0b@anshar.shadow.net Date: Thu, 9 Mar 1995 20:16:38 GMT Subject: computer-security/compromise FAQ Organization: ISS, Inc. Followup-To: poster X-Newsreader: TIN [version 1.2 PL2] UserFlags: Old ReadAccess GlobalFlags: Exported Link HardLink Archive-name: computer-security/compromise-faq Posting-frequency: monthly Last-modified: 1995/01/02 Version: 2.0 Compromise FAQ Version: 2.0 ------------------------------------------------------------------------ This Security FAQ is a resource provided by: Internet Security Systems, Inc. 2000 Miller Court West Tel: (404) 441-2531 Norcross, Georgia 30071 Fax: (404) 441-2431 - Computer Security Consulting - Penetration Analysis of Networks - ------------------------------------------------------------------------ To get the newest updates of Security files check the following services: mail info@iss.net with "send index" in message http://iss.net/~iss ftp iss.net /pub/ ------------------------------------------------------------------------ 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 a machine in this paper. 1. Try to trace/follow the intruder back to his origin via looking at 1. who 2. w 3. last 4. lastcomm 5. netstat 6. snmpnetstat 7. router information. 8. /var/adm/messages (many crackers send e-mail to their "home" accounts) 9. syslog (sends logs to other hosts as well) 10. wrapper logs 11. do a 'finger' to all local users(and check where they last logged in from) 12. history files from shells, such as .history, .rchist, and similiar files. 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: 1. /bin/login 2. all the /usr/etc/in.* files (ie. in.telnetd) 3. and /lib/libc.so.* (on Suns). 4. anything called from inetd Other commonly replaced backdoor binaries: 1. netstat - allows hiding connections 2. ps - allows hiding processes (ie Crack) 3. ls - allows hiding directories 4. ifconfig - hides the fact that promiscuity mode is on the ethernet 5. 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 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, which is available on ftp.cert.org:/pub/tools/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 available on harbor.ecn.purdue.edu:/pub/davy , 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 of common ways that a machine is vulnerable: 1. Do an rpcinfo -p on your machine to make sure it is not running any processes that are not needed. (ie. rexd). 2. Check for '+' in /etc/hosts.equiv. 3. 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. 4. 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. 5. 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). 6. Check your inetd.conf and /etc/services files to find if there are no additional services set up by an intruder. 7. 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). 8. 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). 9. Check if your anonymous ftp (and other services) are configured properly (if you have any of course) See the computer-security/anonymous-ftp FAQ. 10. 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. 11. 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? 12. Check hosts.equiv, .rhosts, and hosts.lpd for having # as comments within those files. If an intruder changes his hostname to #, it will be considered a trusted host and allow him to access your machines. 13. 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 2049/udp) and portmap(111/udp) 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 Wes Morgan (morgan@engr.uky.edu) Alan Hannan (alan@noc1.mid.net) Peter Van Epp Richard Jones Wieste Venema Adrian Rodriguez Jill Bowyer Andy Mell ------------------------------------------------------------------------ Copyright This paper is Copyright (c) 1994, 1995 by Christopher Klaus of Internet Security Systems, Inc. Permission is hereby granted to give away free copies electronically. You may distribute, transfer, or spread this paper electronically. You may not pretend that you wrote it. This copyright notice must be maintained in any copy made. If you wish to reprint the whole or any part of this paper in any other medium excluding electronic medium, please ask the author for permission. 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 of Internet Security Systems, Inc. -- Christopher William Klaus Voice: (404)441-2531. Fax: (404)441-2431 Internet Security Systems, Inc. Computer Security Consulting 2000 Miller Court West, Norcross, GA 30071 From: Christopher Klaus,cklaus@anshar.shadow.net Reply-To: cklaus,cklaus@shadow.net Newsgroup: comp.answers,alt.answers,alt.security,comp.security.misc,comp.security.unix,comp.unix.admin,news.answers Receive-Date: Mittwoch, 15-Mär-95 00:52:49 Creation-Date: Donnerstag, 09-Mär-95 15:15:44 Message-ID: 3jnnlg$dv7@anshar.shadow.net Date: 9 Mar 1995 15:15:44 -0500 Subject: computer-security/security-patches FAQ Organization: ISS, Inc. Followup-To: poster X-Newsreader: TIN [version 1.2 PL2] Distribution: world UserFlags: Old ReadAccess GlobalFlags: Exported Link HardLink Archive-name: computer-security/security-patches Post-Frequency: monthly Last-modified: 1995/01/02 Version: 2.1 Security Patches FAQ Version: 2.1 ------------------------------------------------------------------------ This Security FAQ is a resource provided by: Internet Security Systems, Inc. 2000 Miller Court West Tel: (404) 441-2531 Norcross, Georgia 30071 Fax: (404) 441-2431 - Computer Security Consulting - Penetration Analysis of Networks - ------------------------------------------------------------------------ To get the newest updates of Security files check the following services: mail info@iss.net with "send index" in message http://iss.net/~iss ftp iss.net /pub/faq/ ------------------------------------------------------------------------ Security Patches FAQ for your System: The Patch List As new systems become accessible by networks there is a need for security. Many systems are shipped insecure which puts the responsibility on the customers to find and apply patches. This FAQ will be a guide for the many administrators who want to secure their systems. This FAQ is broken down into the different sections: 1. Generic Things to Look For 2. Type of Operating System and its Vulnerabilities. AIX DEC HPUX NEXT SCO Sun Microsystems SGI 3. Particular Vulnerabilities FTP Sendmail HTTPd (WWW) Rdist IP Spoofing attacks Hijacking terminal connections 4. Unpatched Vulnerabilities (Bugs that the Vendor has not Fixed) ------------------------------------------------------------------------ Part 1 - Generic Things to Look For Firewalling is one of the best methods of stopping pontential intruders. Block all UDP traffic except for DNS and nameserver ports. Block all source routing and rlogin and rsh at the router if possible. Run ISS (Internet Security Scanner) regulary. This package allows an administrator to do an audit of the network and notify him of any security misconfigurations or anomalies that allow intruders in therefore allowing him to take corrective measures before his network is compromised. It is available on aql.gatech.edu:/pub/security/iss Run Tiger regularly. It is available on net.tamu.edu:/pub/security/TAMU Password Security Use one-time password technology like s/key. This package makes sniffing passwords useless since the password that goes over the network is only used once. It is available on ftp:thumper.bellcore.com:/pub/nmh/skey Shadowing passwords is useful against dictionary passwd cracking attacks. Replace passwd with a program that will not allow your users to pick easy passwords. Check for all easy-to-guess passwords with Crack which is available on ftp.cert.org:/pub/tools/crack by Alec Muffett (alecm@sun.com) . Do a rpcinfo -p command and check to make sure rexd is not running. TFTP should be turned off unless needed because it can be used to grab password files remotely. Make sure there is no '+' in /etc/hosts.equiv or any .rhosts. Make sure there are no '#' in /etc/hosts.equiv or any .rhosts. Make sure there are no funny commands in any .forward. Make sure there are no cleartext passwords in any .netrc. Do a showmount -e command to see your exports and make sure they are restricted to only trusted hosts. Make sure all exports have an access list. Use Xauthority when using X11 or openwin. You may want to remove the suid from rdist, chill, pstat, and arp. They are known to cause security problems on generic default machine. Run tripwire regularly. It is available on coast.cs.purdue.edu:/pub/COAST/Tripwire Run COPS regulary. It is available on ftp.cert.org:/pub/tools/cops Run a TCP Wrapper. It is available on ftp.win.tue.nl:/pub/security/tcp_wrappers_6.3.shar.Z Identd may help locate accounts that intruders are using on remote and local machines. It is on ftp.lysator.liu.se:/pub/ident/servers ------------------------------------------------------------------------ Part 2 - Type of Operating System and its Vulnerabilities To find some of the newer patches, using archie and xarchie can be a useful tool. Some caution must be used when using patches obtained from FTP sites. It is known that some ftp sites have been compromised in the past and files were replaced with trojans. Please verify the checksums for the patches. ------------------------------------------------------------------------ AIX Fixdist is a X Windows front end to the AIX PTF (Patch) Database. Fixdist package available at ftp:aix.boulder.ibm.com Fixdist requirements: Software: AIX for RISC System/6000 Version 3.2.4 or above. AIX TCPIP Facilities (bosnet.tcpip.obj) AIXwindows 1.2.0 (X11R4) or AIXwindows 1.2.3 (X11R5). Connection Requirements The fixdist utility communicates to the ftp server using anonymous ftp. There is no mail transport or Telnet requirement. The server is currently available only on the Internet. If you are able to download the utility, you are fully enabled use fixdist. Fixdist does not "install" any PTFs onto your system. It just transfers the fixes to a target directory on your RISC System/6000. To turn off IP Forwarding and Source Routing, add the following to /etc/rc.net: /usr/sbin/no -o ipforwarding=0 /usr/sbin/no -o ipsendredirects=0 /usr/sbin/no -o nonlocsrcroute=0 ------------------------------------------------------------------------ DEC Security kits are available from Digital Equipment Corporation by contacting your normal Digital support channel or by request via DSNlink for electronic transfer. Digital Equipment Corporation strongly urges Customers to upgrade to a minimum of ULTRIX V4.4 and DEC OSF/1 V2.0 then apply the Security Enhanced Kit. - Please refer to the applicable Release Note information prior to upgrading your installation. KIT PART NUMBERS and DESCRIPTIONS CSC PATCH # CSCPAT_4060 V1.0 ULTRIX V4.3 thru V4.4 (Includes DECnet-ULTRIX V4.2) CSCPAT_4061 V1.0 DEC OSF/1 V1.2 thru V2.0 These kits will not install on versions previous to ULTRIX V4.3 or DEC OSF/1 V1.2. The ULTRIX Security Enhanced kit replaces the following images: /usr/etc/comsat ULTRIX V4.3, V4.3a, V4.4 /usr/ucb/lpr " " /usr/bin/mail " " /usr/lib/sendmail " " *sendmail - is a previously distributed solution. /usr/etc/telnetd ULTRIX V4.3, V4.3a only For DECnet-ULTRIX V4.2 installations: /usr/etc/dlogind /usr/etc/telnetd.gw The DEC OSF/1 Security Enhanced kit replaces the following images: /usr/sbin/comsat DEC OSF/1 V1.2, V1.3 V2.0 /usr/bin/binmail /usr/bin/lpr " " /usr/sbin/sendmail DEC OSF/1 V1.2, V1.3 only *sendmail - is a previously distributed solution. /usr/bin/rdist " " /usr/shlib/libsecurity.so DEC OSF/1 V2.0 only ------------------------------------------------------------------------ HPUX In order to retrieve any document that is described in this index, send the following in the TEXT PORTION OF THE MESSAGE to support@support.mayfield.hp.com: send doc xxxxxxxxxxxx Summary of 'Security Bulletins Index' documents Document Id Description HPSBUX9411-019 Security Vulnerability in HP SupportWatch HPSBUX9410-018 Security Vulnerability in xwcreate/gwind HPSBUX9409-017 Security Vulnerability in CORE-DIAG fileset HPSBUX9408-000 Sum and MD5 sums of HP-UX Security Bulletins HPSBUX9408-016 Patch sums and the MD5 program HPSBUX9407-015 Xauthority problem HPSBUX9406-014 Patch file permissions vulnerability HPSBUX9406-013 vhe_u_mnt allows unauthorized root access HPSBUX9405-011 Security Vulnerability in HP GlancePlus HPSBUX9405-009 PROBLEM: Incomplete implementation of OSF/AES standard HPSBUX9405-010 ftpd: SITE CHMOD / race condition vulnerability HPSBUX9405-012 Security vulnerability in Multimedia Sharedprint HPSBUX9404-007 HP-UX does not have ftpd SITE EXEC vulnerability HPSBUX9404-008 Security Vulnerability in Vue 3.0 HPSBUX9402-006 Security Vulnerability in DCE/9000 HPSBUX9402-005 Security Vulnerability in Hpterm HPSBUX9402-004 Promiscuous mode network interfaces HPSBUX9402-003 Security Vulnerability in Subnetconfig HPSBUX9312-002 Security Vulnerability in Xterm HPSBUX9311-001 Security Vulnerability in Sendmail If you would like to obtain a list of additional files available via the HP SupportLine mail service, send the following in the TEXT PORTION OF THE MESSAGE to support@support.mayfield.hp.com: send file_list or to get the newest security patch list: send security_info_list HP-patches and patch-information are available by WWW: 1. with URL http://support.mayfield.hp.com/slx/html/ptc_hpux.html http://support.mayfield.hp.com/slx/html/ptc_get.html 2. or by appending the following lines to your $HOME/.mosaic-hotlist-default and using the --> navigate --> hotlist option. HP has a list of checksums for their security patches. Highly recommended you always compare patches with the checksum for corruption and trojans. ------------------------------------------------------------------------ NEXT There are some security patches on ftp.next.com:/pub/NeXTanswers/Files/Patches SendmailPatch.23950.1 RestorePatch.29807.16 ftp.next.com:/pub/NeXTanswers/Files/Security contains some security advisories. Be sure to check for Rexd and uuencode alias. ------------------------------------------------------------------------ SCO Unix Current releases of SCO UNIX (3.2v4.2) and Open Desktop (3.0) has the following security patches available: uod368b -- passwd oda377a -- xterm, scoterm, scosession, clean_screen These can be downloaded from ftp.sco.com:/SLS. First get the file "info" which lists the actual filenames and descriptions of the supplements. Security problems were made aware by 8LGM in the following programs for SCO: at(C) login(M) prwarn(C) sadc(ADM) pt_chmod These programs, which allowed regular users to become SuperUser (root), affect the following SCO Products: SCO Unix System V/386 Release 3.2 Versions 4.2, 4.1, and 4.0 SCO Open Desktop Lite Release 3.0 SCO Open Desktop Release 3.0 and 2.0 SCO Open Server Network System Release 3.0 SCO Open Server Enterprise System Release 3.0 You need the following patches which are available at ftp.sco.com:/SSE: Binary Patch ------ ------ at(C) sse001 login(M) sse002 prwarn(C) sse003 sadc(ADM) sse004 pt_chmod sse005 To contact SCO, send electronic mail to support@sco.com. ------------------------------------------------------------------------ Sun Microsystems, Inc. SunOS 4.x and Solaris 2.x Patches may be obtained via anonymous ftp from ftp.uu.net:/systems/sun/sun-dist or from local Sun Answer Centers worldwide. Sun makes lists of recommended patches (including security patches) available to customers with support contracts via its Answer Centers and the SunSolve service. The lists are uploaded on an informal basis to the ftp.uu.net patch repository maintained by Sun for other customers, and posted periodically on the comp.security.unix newsgroup. Patches are also available via anonymous ftp from sunsolve1.sun.com:/pub/patches online.sunsolve.sun.co.uk:/patches/SECURITY/ALL Check out the the sunsolve www-page at http://online.sunsolve.sun.co.uk/ Below is a list of security patches that should be implemented. Please use Sun's patch list for the authoritative answer. If you see any discrepencies please notify Christopher Klaus (cklaus@iss.net). 100075-11 rpc.lockd jumbo patch 100103-11 script to change file permissions to a more secure mode 100170-10 jumbo-patch ld-1.144 shared LD_LIBRARY_PATH -Bstatic SPARCworks 100173-09 NFS Jumbo Patch 100178-08 netd "broken server detection" breaks on fast machines 100249-09 automounter jumbo patch 100272-07 security hole in utmp writable 100283-03 in.routed mishandles gateways, multiple routes 100296-04 rpc.mountd exports to the world 100305-14 lpr package 100338-05 system crashes with assertion failed panic.(may be obsolete) 100342-03 NIS client needs long recovery time if server reboots 100359-06 streams jumbo patch 100383-06 rdist can be used to get root access 100421-03 rpc.rexd does not log appropriate accounting messages 100448-01 loadmodule 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-07 C2 Jumbo patch 100567-04 mfree panic due to mbuf being freed twice 100593-03 security hole in utmp writable 100623-03 UFS jumbo patch 100909-02 security hole in utmp writable 101480-01 security hole in utmp writable 101481-01 security hole in utmp writable 101482-01 security hole in utmp writable 102060-01 Fixes the passwd -F hole. 101436-08 Fix for /bin/mail Solaris 2.2 Recommended Patches: 100982-03 SunOS 5.2: fixes for kernel/fs/fifofs 100992-03 SunOS 5.2: streams related panics involving local transport 100999-71 SunOS 5.2: kernel jumbo patch 101014-05 SunOS 5.2: fixes for usr/lib/libsocket 101022-06 SunOS 5.2: NIS/NIS+ jumbo patches 101025-14 SunOS 5.2: Jumbo patch fixes for lp system 101031-02 SunOS 5.2: file descriptor limit is too low on inetd 101090-01 SunOS 5.2: fixes security hole in expreserve 101096-02 SunOS 5.2: fixes for rpcbind 101109-04 SunOS 5.2: fixes problems with ldterm, ptm, pts 101122-07 SunOS 5.2: fixes for the packaging utilities 101301-03 SunOS 5.2: security bug & tar fixes 101348-01 SunOS 5.2: system hangs due to mblk memory leak Solaris 2.3 Recommended Patches: 101317-11 SunOS 5.3: lp jumbo patch 101318-59 SunOS 5.3: Jumbo patch for kernel (includes libc, lockd) 101327-08 SunOS 5.3: security and miscellaneous tar fixes 101331-05 SunOS 5.3: fixes for package utilities 101344-11 SunOS 5.3: Jumbo NFS patch security 101347-02 SunOS 5.3: fixes for ttcompat 101615-02 SunOS 5.3: miscellaneous utmp fixes 101631-02 SunOS 5.3: kd and ms fixes 101712-01 SunOS 5.3: uucleanup isn't careful enough when sending mail 102034-01 SunOS 5.3: portmapper security hole 101889-03 OpenWindows 3.3: filemgr forked executable ff.core has a se Solaris 2.4 Recommended Patches: 101945-13 SunOS 5.4: jumbo patch for kernel 101959-02 SunOS 5.4: lp jumbo patch 101981-01 SunOS 5.4: SECURITY: su can display root password in the co 102007-01 SunOS 5.4: vnode v_count is not maintained correctly 102044-01 SunOS 5.4: bug in mouse code makes "break root" attack poss 102070-01 SunOS 5.4: Bugfix for rpcbind/portmapper Sendmail patches are important. Check out Sendmail section. Turn off IP-Forward on SunOs Kernel and kmem via: "echo ip_forwarding/W 0" | adb -w /vmunix /dev/kmem To turn off source routed packets on Solaris 2.X. Edit /etc/rc.2.d/S69.inet and change ndd -set /dev/ip ip_forwarding 0 ndd -set /dev/ip ip_ip_forward_src_routed 0 reboot. Source routing patch for SunOs 4.1.x ftp.greatcircle.com:/pub/firewalls/digest/v03.n153.Z To Secure a Sun console physically: (for desktop sparc models) $su #eeprom security-mode=command Password: Retype password: # (for other models) $su #eeprom secure=command Password: Retype password: # This restricts access to the new command mode. Remove suid from crash, devinfo. These both are known to be exploitable on some Sun and are rarely used. The following is a package of patches for SunOs from Australian group SERT: ftp.sert.edu.au:/security/sert/tools/MegaPatch.1.7.tar.Z Solaris 2.x Patches Here are some file permission problems that exist on Solaris 2.3 and maybe exist on Solaris 2.4 that you should check and correct. Many file permission problems are fixed with a fix-mode module in the auto-install package: ftp.fwi.uva.nl:/pub/solaris/auto-install/* . After each patch installation, you will need to re-run the fix-mode. 1. Problem: As distributed, /opt/SUNWdxlib contains many _world_ writeable files, including executables. A trojan may be inserted into an executable by any user allowing them access to the accounts of anyone executing it. Solution: "find /opt/SUNWdxlib -exec chmod go-w {} \;" Fix-modes will do a better job correcting permissions. You can do a simple check for trojans with: "pkgchk SUNWdxlib". 2. Problem: By default, /var/nis/{hostname}.dict is _world_ writeable. "man -s4 nisfiles" says "This file is a dictionary that is used by the NIS+ database to locate its files." A quick look at it will show things like "/var/nis/{hostname}/passwd.org_dir". By changing this to, say, "/tmp/{hostname}/passwd.org_dir", it _may_ be possible to replace the NIS+ password (or any arbitrary) map with a bogus one. There are also many files in /var/nis/{hostname} that are world writeable. However, since /var/nis/{hostname} is root owned, mode 700, this shouldn't be a problem. It also shouldn't be necessary. All the files in /var/nis/{hostname} are world readable which is not a good way to have shadow passwords. Solution: By putting a "S00umask.sh" with contents "umask 022" in each /etc/rc?.d it will make sure that all daemons will start with an umask of 022. The default umask really should be 022, not 0. "strings /var/nis/{hostname}.dict" to make sure all the paths are sane, then to correct permissions: "chmod 644 /var/nis/{hostname}.dict" "chmod 700 /var/nis/{hostname}" "chmod 600 /var/nis/{hostname}/*" 3. Problem: /etc/hostname.le0 is _world_ writeable. This allows anyone to change the address of the ethernet interface. Solution: "chmod 644 /etc/hostname.le0" 4. Problem: /var/statmon, /var/statmon/sm, and /var/statmon/sm.bak are _world_ writeable directories. They are used by statd to "provide the crash and recovery functions for the locking services of NFS. You could trick an NFS client into thinking a server crashed. Solution: "find /var/statmon -exec chmod o-w {} \;" 5. Problem: The following files are _world_ writeable: /var/adm/vold.log /var/log/syslog* /var/lp/logs/lpsched /var/lp/logs/lpNet /etc/mnttab /etc/path_to_inst.old /var/saf/_log /etc/rmtab Solution: It may not be possible to tighten up permissions on all the world writeable files out there without breaking something. However, it'd be a good idea to at least know what they are. Something like: "find / -user root \( -type d -o -type f \) -perm -2 -ls" will at least let you know which files may contain bogus information. Checking for other than root, bin, sys, lp, etc. group writeable files would be a good idea as well. 6. Problem: Solaris still ships /usr/kvm/crash mode 2755 which allows anyone to read kmem. Solution: Change permission to 0755. 7. Problem: /etc, /usr/ and /usr/sys may have mode 775 which allows groups to write over files. Solution: Change permissions to 755. ------------------------------------------------------------------------ SGI ftp.sgi.com and sgigate.sgi.com have a "/security" directory. {3.3,4.0,5.0} including sendmail and lpr. lpr allowed anyone to get root access. Patch65 and patch34 correct vulnerability in SGI help system which enabled users to gain root priviledges. Standard System V MD5 Unix Unix Digital Signature patch34.tar.Z: 11066 15627 1674 31253 2859d0debff715c5beaccd02b6bebded patch65.tar: 63059 1220 15843 2440 af8c120f86daab9df74998b31927e397 Check for the Following: Default accounts with no passwords: 4DGifts, lp, nuucp, demos, tutor, guest, tour To Disable IP_Forwarding on SGI: edit /usr/sysgen/master.d change int ipforwarding = 1 to 0; then recompile kernel by autoconfig -f; for IRIX 4.0.5 Remove suid from /usr/sbin/colorview Remove suid from /usr/lib/vadmin/serial_ports on Irix 4.X Remove suid from /usr/lib/desktop/permissions Remove suid from /usr/bin/under /usr/etc/arp is setgid sys in IRIX up to and including 5.2, allowing anyone who can log into your machine to read files which should be readable only by group 'sys'. Remove suid from /usr/sbin/cdinstmgr Remove suid from /etc/init.d/audio chmod g-w /usr/bin/newgrp /usr/sbin/printers has a bug in IRIX 5.2 (and possibly earlier 5.x versions) which allows any user to become root. /usr/sbin/sgihelp has a bug in IRIX 5.2 (and possibly earlier 5.x versions) which allows any user to become root. This is so bad that the patch is FTPable from ftp.sgi.com:/security/, and SGI is preparing a CD containing only that patch. The version of inst which comes with patch 34, which is required for installation of all other patches (even those with lower numbers) saves old versions of binaries in /var/inst/patchbase. It does not remove execution or setuid permissions. Irix has many built-in security knobs that you should know how to turn them on. Manpage Things to look for ------- --------------------------------------------------- login setup /etc/default/login to log all attempts with SYSLOG=ALL, add support for external authentication programs with SITECHECK=/path/to/prog portmap use '-a mask,match' to restrict most of the portmap services to a subset of hosts or networks use '-v' to log all unprivileged accesses to syslog rshd use '-l' to disable validation using .rhosts files use '-L' to log all access attempts to syslog rlogind use '-l' to disable validation using .rhosts files (beware, this was broken prior to IRIX 5.3) fingerd use '-l' to log all connections use '-S' to suppress information about login status, home directory, and shell use '-f msg-file' to make it just display that file ipfilterd IP packet filtering daemon ------------------------------------------------------------------------ Part 3 - Particular Vulnerabilities Ftp Check the Secure Anonymous FTP FAQ for the latest ftp daemons that you need to install. Sendmail Patches IBM Corporation A possible security exposure exists in the bos.obj sendmail subsystem in all AIX releases. The user can cause arbitrary data to be written into the sendmail queue file. Non-privileged users can affect the delivery of mail, as well as run programs as other users. Workaround A. Apply the patch for this problem. The patch is available from software.watson.ibm.com. The files will be located in the /pub/aix/sendmail in compressed tar format. The MD5 checksum for the binary file is listed below, ordinary "sum" checksums follow as well. File sum MD5 Checksum ---- --- ------------ sendmail.tar.Z 35990 e172fac410a1b31f3a8c0188f5fd3edb B. The official fix for this problem can be ordered as Authorized Program Analysis Report (APAR) IX49257 To order an APAR from IBM in the U.S. call 1-800-237-5511 and ask for shipment as soon as it is available (in approximately two weeks). APARs may be obtained outside the U.S. by contacting a local IBM representative. Motorola Computer Group (MCG) The following MCG platforms are vulnerable: R40 R32 running CNEP add-on product R3 running CNEP add-on product The following MCG platforms are not vulnerable: R32 not including CNEP add-on product R3 not including CNEP add-on product R2 VMEEXEC VERSADOS The patch is available and is identified as "patch_43004 p001" or "SCML#5552". It is applicable to OS revisions from R40V3 to R40V4.3. For availability of patches for other versions of the product contact your regional MCG office at the numbers listed below. Obtain and install the appropriate patch according to the instructions included with the patch. The patch can be obtained through anonymous ftp from ftp.mcd.mot.com [144.191.210.3] in the pub/patches/r4 directory. The patch can also be obtained via sales and support channels. Questions regarding the patch should be forwarded to sales or support channels. For verification of the patch file: Results of sum -r == 27479 661 sum == 32917 661 md5 == 8210c9ef9441da4c9a81c527b44defa6 Contact numbers for Sales and Support for MCG: United States (Tempe, Arizona) Tel: +1-800-624-0077 Fax: +1-602-438-3865 Europe (Brussels, Belgium) Tel: +32-2-718-5411 Fax: +32-2-718-5566 Asia Pacific / Japan (Hong Kong) Tel: +852-966-3210 Fax: +852-966-3202 Latin America / Australia / New Zealand (U.S.) Tel: +1 602-438-5633 Fax: +1 602-438-3592 Open Software Foundation The local vulnerability described in the advisory can be exploited in OSF's OSF/1 R1.3 (this is different from DEC's OSF/1). Customers should apply the relevant portions of cert's fix to their source base. For more information please contact OSF's support organization at osf1-defect@osf.org. The Santa Cruz Operation SCO systems are not vulnerable to the IDENT problem. Systems running the MMDF mail system are not vulnerable to the remote or local problems. The following releases of SCO products are vulnerable to the local problems. SCO TCP/IP 1.1.x for SCO Unix System V/386 Operating System Release 3.2 Versions 1.0 and 2.0 SCO TCP/IP 1.2.x for SCO Unix System V/386 Operating System Release 3.2 Versions 4.x SCO TCP/IP 1.2.0 for SCO Xenix System V/386 Operating System Release 2.3.4 SCO Open Desktop Lite Release 3.0 SCO Open Desktop Release 1.x, 2.0, and 3.0 SCO Open Server Network System, Release 3.0 SCO Open Server Enterprise System, Release 3.0 Patches are currently being developed for the release 3.0 and 1.2.1 based products. The latest sendmail available from SCO, on Support Level Supplement (SLS) net382d, is also vulnerable. Contacts for further information: e-mail: support@sco.COM USA, Canada, Pacific Rim, Asia, Latin America 6am-5pm Pacific Daylight Time (PDT) 1-408-425-4726 (voice) 1-408-427-5443 (fax) Europe, Middle East, Africa: 9am-5:30pm British Standard Time (BST) +44 (0)923 816344 (voice) +44 (0)923 817781 (fax) Sequent Computer Systems Sequent customers should contact Sequent Customer Service and request the Fastpatch for sendmail. phone: 1-800-854-9969. e-mail: service-question@sequent.com Silicon Graphics, Inc. At the time of writing of this document, patches/binaries are planned for IRIX versions 4.x, 5.2, 5.3, 6.0, and 6.0.1 and will be available to all SGI customers. The patches/binaries may be obtained via anonymous ftp (ftp.sgi.com) or from your support/service provider. On the anonymous ftp server, the binaries/patches can be found in either ~ftp/patches or ~ftp/security directories along with more current pertinent information. For any issues regarding this patch, please, contact your support/service provider or send email to cse-security-alert@csd.sgi.com . Sony Corporation NEWS-OS 6.0.3 vulnerable; Patch SONYP6022 [sendmail] is available. NEWS-OS 6.1 vulnerable; Patch SONYP6101 [sendmail] is available. NEWS-OS 4.2.1 vulnerable; Patch 0101 [sendmail-3] is available. Note that this patch is not included in 4.2.1a+. Patches are available via anonymous FTP in the /pub/patch/news-os/un-official directory on ftp1.sony.co.jp [202.24.32.18]: 4.2.1a+/0101.doc describes about patch 0101 [sendmail-3] 4.2.1a+/0101_C.pch patch for NEWS-OS 4.2.1C/a+C 4.2.1a+/0101_R.pch patch for NEWS-OS 4.2.1R/RN/RD/aRD/aRS/a+R 6.0.3/SONYP6022.doc describes about patch SONYP6022 [sendmail] 6.0.3/SONYP6022.pch patch for NEWS-OS 6.0.3 6.1/SONYP6101.doc describes about patch SONYP6101 [sendmail] 6.1/SONYP6101.pch patch for NEWS-OS 6.1 Filename BSD SVR4 Checksum Checksum -------------- --------- --------- 4.2.1a+/0101.doc 55361 2 19699 4 4.2.1a+/0101_C.pch 60185 307 25993 614 4.2.1a+/0101_R.pch 35612 502 31139 1004 6.0.3/SONYP6022.doc 03698 2 36652 4 6.0.3/SONYP6022.pch 41319 436 20298 871 6.1/SONYP6101.doc 40725 2 3257 3 6.1/SONYP6101.pch 37762 434 4624 868 MD5 checksums are: MD5 (4.2.1a+/0101.doc) = c696c28abb65fffa5f2cb447d4253902 MD5 (4.2.1a+/0101_C.pch) = 20c2d4939cd6ad6db0901d6e6d5ee832 MD5 (4.2.1a+/0101_R.pch) = 840c20f909cf7a9ac188b9696d690b92 MD5 (6.0.3/SONYP6022.doc) = b5b61aa85684c19e3104dd3c4f88c5c5 MD5 (6.0.3/SONYP6022.pch) = 1e4d577f380ef509fd5241d97a6bcbea MD5 (6.1/SONYP6101.doc) = 62601c61aef99535acb325cf443b1b25 MD5 (6.1/SONYP6101.pch) = 87c0d58f82b6c6f7811750251bace98c If you need further information, contact your vendor. Solbourne Grumman System Support Corporation now performs all Solbourne software and hardware support. Please contact them for further information. e-mail: support@nts.gssc.com phone: 1-800-447-2861 Sun Microsystems, Inc. Sun has developed patches for all supported platforms and architectures, including Trusted Solaris, Solaris x86, and Interactive Unix. Note that Sun no longer supports the sun3 architecture and versions of the operating system that precede 4.1.3. Current patches are listed below. OS version Patch ID Patch File Name ---------- --------- --------------- 4.1.3 100377-19 100377-19.tar.Z 4.1.3_U1 101665-04 101665-04.tar.Z 5.3 101739-07 101739-07.tar.Z 5.4 102066-04 102066-04.tar.Z 5.4_x86 102064-04 102064-04.tar.Z The patches can be obtained from local Sun Answer Centers and through anonymous FTP from ftp.uu.net in the /systems/sun/sun-dist directory. In Europe, the patches are available from mcsun.eu.net in the /sun/fixes directory. The patches are also available through the usual URL on World Wide Web. Sun is issuing Security Bulletin #129 with details on February 22; the patches will become available worldwide during the 24 hours to follow. HTTPd (WWW) There is a bug in NCSA v1.3 HTTP Web server that allows anyone to execute commands remotely. The bug is due to overwriting a buffer. Please get the newest patch from ftp.ncsa.uiuc.edu. Rdist Patches (Unless you really need rdist, chmod 000 rdist works fine.) 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. 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-06 IP Spoofing Vulnerabilities IP Spoofing attacks allow an intruder to send packets as if they were coming from a trusted host and some services based on IP based authenication allow an intruder to execute commands. Because these packets appear to come from a trusted host, it may be possible to by-pass firewall security. IP Spoofing is more detailed in the following papers: "Security Problems in the TCP/IP Protocol Suite" by Steve Bellovin. It is available for ftp from research.att.com:/dist/internet_security/ipext.ps.Z "A Weakness in the 4.2BSD Unix TCP/IP Software," by Robert T. Morris. It is available for ftp from research.att.com:/dist/internet_security/117.ps.Z Some of the services based on IP authenication are: Rsh Rlogin NFS NIS X Windows Services secured by TCP Wrappers access list. It can help turn off these services especially Rsh and Rlogin. You can filter out IP spoofed packets with certian routers with the use of the input filter. Input filter is a feature on the following routers: Bay Networks/Wellfleet, version 5 and later Cabletron with LAN Secure Cisco, RIS software version 9.21 and later Livingston NSC TCP Wrapper in conjunction with Identd can help to stop IP spoofing because then the intruder must not not only spoof the connection to Rsh/Rlogin, they must spoof the information to identd which is not as trivial. TCP Wrapper is available on ftp.win.tue.nl:/pub/security/tcp_wrappers_6. 3.shar.Z Identd is available on ftp.lysator.liu.se:/pub/ident/servers Add the following to TCP Wrappers access list: ALL: UNKNOWN@ALL: DENY This will drops all TCP connections where ident lookup fails. Hijacking terminal connections Intruders are using a kernel module called TAP that initially was used for capturing streams which allows you to view what a person is typing. You can use it to write to someone's steam, thus emulating that person typing a command and allowing an intruder to "hijack" their session. Tap is available on ftp.sterling.com /usenet/alt.sources/volume92/Mar in the following files: 920321.02.Z TAP - a STREAMS module/driver monitor (1.1) 920322.01.Z TAP - a STREAMS module/driver monitor (1.5) repost 920323.17.Z TAP - BIG BROTHERS STREAMS TAP DRIVER (1.24) An intruder needs to install TAP as root. Therefore if you have installed all patches and taken the necessary precautions to eliminate ways to obtain root, the intruder has less chance of installing TAP. You can disable loadable modules on SunOs 4.1.x by editing the kernel configuraion file found in /sys/`arch -k`/conf directory and comment out the following line with a "#" character: options VDDRV # loadable modules Then build and install the new kernel: # /etc/config CONFIG_NAME # cd ../CONFIG_NAME # make # cp /vmunix /vmunix.orig # cp vmunix / # sync; sync; sync Reboot the system to activate the new kernel. You can also try to detect the Tap program by doing the following command: modstat Modstat displays all loaded modules. An intruder could trojan modstat as well therefore you may want to verify the checksum of modstat. ------------------------------------------------------------------------ Part 4 - Unpatched Vulnerabilities This is intended to let consumers know that these holes have already been fully disclosed and everyone already knows about it. These are the vulnerabilities that vendors are suppose to be releasing patches for ASAP. Hopefully this list will stay short and small. Vendor Bug Result Sun5.x no promisc flags Can not tell if machine is sniffing ------------------------------------------------------------------------ Acknowledgements I would like to thank the following people for the contribution to this FAQ that has helped to update and shape it: Jonathan Zanderson (jsz@ramon.bgu.ac.il) Rob Quinn Dr.-Ing. Rudolf Theisen, Gerald (Jerry) R. Leslie Walker Aumann (walkera@druggist.gg.caltech.edu) Chris Ellwood (cellwood@gauss.calpoly.edu) ------------------------------------------------------------------------ Copyright This paper is Copyright (c) 1994, 1995 by Christopher Klaus of Internet Security Systems, Inc. Permission is hereby granted to give away free copies electronically. You may distribute, transfer, or spread this paper electronically. You may not pretend that you wrote it. This copyright notice must be maintained in any copy made. If you wish to reprint the whole or any part of this paper in any other medium excluding electronic medium, please ask the author for permission. 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 of Internet Security Systems, Inc. -- Christopher William Klaus Voice: (404)441-2531. Fax: (404)441-2431 Internet Security Systems, Inc. Computer Security Consulting 2000 Miller Court West, Norcross, GA 30071 From: Christopher Klaus,cklaus@anshar.shadow.net Reply-To: cklaus,cklaus@shadow.net Newsgroup: comp.answers,alt.answers,alt.security,comp.security.misc,comp.security.unix,comp.unix.admin,news.answers Receive-Date: Mittwoch, 15-Mär-95 00:52:50 Creation-Date: Donnerstag, 09-Mär-95 15:20:25 Message-ID: 3jnnu9$e53@anshar.shadow.net Date: 9 Mar 1995 15:20:25 -0500 Subject: computer-security/anonymous-ftp FAQ Organization: ISS, Inc. Followup-To: poster X-Newsreader: TIN [version 1.2 PL2] Distribution: world UserFlags: Old ReadAccess GlobalFlags: Exported Link HardLink Archive-name: computer-security/anonymous-ftp-faq Post-Frequency: monthly Last-modified: 1995/01/02 Version: 2.0 Anonymous FTP FAQ Version: 2.0 ------------------------------------------------------------------------ This Security FAQ is a resource provided by: Internet Security Systems, Inc. 2000 Miller Court West Tel: (404) 441-2531 Norcross, Georgia 30071 Fax: (404) 441-2431 - Computer Security Consulting - Penetration Analysis of Networks - ------------------------------------------------------------------------ To get the newest updates of Security files check the following services: mail info@iss.net with "send index" in message http://iss.net/~iss ftp iss.net /pub/ ------------------------------------------------------------------------ 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: 1. General Description of Setting up an "Anonymous" FTP server. 2. Setting up a chrooted Secure Anonymous FTP server. 3. OS Specific needed information and suggestions. 4. Where to get other FTP daemons 5. How to Know if your Anonymous FTP Server is Secure 6. Archie ------------------------------------------------------------------------ 1. General Description of Setting up an "anonymous" ftp server. 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. Creating this user turns on anonymous ftp. 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). [Warning:] Some MAN pages recommend making the ~ftp directory owned by ftp. This is a big NO-NO, if you want any type of security on your system. 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. [Warning:] 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: To do tar and compress, he wrote a tiny program called `pipe', and statically-linked it. His /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 | \n", 34); exit(1); } -------- CUT HERE ------------ 9. Other things to do: as root: touch ~ftp/.rhosts touch ~ftp/.forward chmod 400 ~ftp/.rhosts chmod 400 ~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. ------------------------------------------------------------------------ 2. Setting up a chrooted Secure Anonymous ftp server. This part was contributed by Marcus J Ranum 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. ------------------------------------------------------------------------ 3. OS Specific needed information and suggestions. These machines may need dev/tcp: Older SVR2 and SVR3 system RTU 6.0 (Masscomp, now Concurrent Real Time UNIX), AT&T 3B1 and 3B2 machines [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. [Note:] 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. [Warning:] For novices: 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 The information can be separated (or like SunOs4.1.1 does not recognize daemon.* so it requires the following form), such as: daemon.info /var/adm/daemon.info daemon.debug /var/adm/daemon.debug daemon.err /var/adm/daemon.err 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. [Warning:] You want to make all logs root only readable for security reasons If a user mistypes his password for his username, it could be compromised if anyone can read the log files. ------------------------------------------------------------------------ 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 ------------------------------------------------------------------------ 5. How to Know if your Anonymous FTP Server is Secure This section is intended for the administrator to go down a small check list of things to make sure his server is not easily compromised. 1. Check to make sure your ftp server does not have SITE EXEC command by telneting to port 21 and typing SITE EXEC. If your ftp daemon has SITE EXEC make sure it is the most current version (ie, Wu-FTP 2.4). In older versions this allows anyone to gain shell via port 21. 2. Check to make sure no one can log in and make files or directories in the main directory. If anyone can log in as anonymous FTP and make files such as .rhosts and .forward, instant access is granted to any intruder. 3. Check to make sure the main directory is NOT owned by ftp. If it is owned by FTP, an intruder could SITE CHMOD 777 the main directory and then plant files to give him instant access. SITE CHMOD command should be removed because anonymous users do not need any extra priviledges. 4. Check to make sure NO files or directories are owned by ftp. If they are, it is possible an intruder could replace them with his own trojan versions. 5. There were several bugs in old daemons, so it is very important to make sure you are running the most current ftp daemons. ------------------------------------------------------------------------ 6. 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.univ-rennes1.fr (French Server) archie.uqam.ca 132.208.250.10 (Canadian Server) archie.wide.ad.jp 133.4.3.6 (Japanese Server) ------------------------------------------------------------------------ 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) Mirsad Todorovac (mirsad.todorovac@etf.hr) Nicholas Ironmonger (ndi@sam.math.ethz.ch) Morten Welinder (terra@diku.dk) Nick Christenson (npc@minotaur.jpl.nasa.gov) Mark Hanning-Lee (markhl@romoe.caltech.edu) Marcus J Ranum ------------------------------------------------------------------------ Copyright This paper is Copyright (c) 1994, 1995 by Christopher Klaus of Internet Security Systems, Inc. Permission is hereby granted to give away free copies electronically. You may distribute, transfer, or spread this paper electronically. You may not pretend that you wrote it. This copyright notice must be maintained in any copy made. If you wish to reprint the whole or any part of this paper in any other medium excluding electronic medium, please ask the author for permission. 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 of Internet Security Systems, Inc. -- Christopher William Klaus Voice: (404)441-2531. Fax: (404)441-2431 Internet Security Systems, Inc. Computer Security Consulting 2000 Miller Court West, Norcross, GA 30071