Unix security FAQ Archive-name: security-faq Last-modified: 1993/12/3 Version: 2.2 Version History: 2.2 LD_LIBRARY_PRELOAD comment 2.1 New story, TAMU package info 2.0 MERGE IN LOTS OF NEW INFORMATION 1.6 Minor revisions, meant to bring it a bit more up to date. 1.5 Structural revision. 1.4 Fixed John Haugh's name, modified entry for "shadow" Added Ulf Kieber's update on the rainbow series Added bit about Karila paper 1.3: Tweak for comp.security.misc/news.answers Updated entry for orange book (foreign purchases) 1.2: Undocumented prior to this --------------------------------------------------------------------------- Almost Everything You Ever Wanted To Know About Security* *(but were afraid to ask!) This document is meant to answer some of the questions which regularly appear in the Usenet newsgroups "comp.security.misc", "comp.security.unix", and "alt.security", and is meant to provide some background to the subject for newcomers to that newsgroup. This FAQ is maintained by Alec Muffett (Alec.Muffett@UK.Sun.COM), with contributions from numerous others; the views expressed in the document are the personal views of the author(s), and it should not be inferred that they are necessarily shared by anyone with whom the author(s) are now, or ever may be, associated. Many thanks go to (in no particular order): Steve Bellovin, Matt Bishop, Mark Brader, Ed DeHart, Dave Hayes, Jeffrey Hutzelman, William LeFebvre, Wes Morgan, Rob Quinn, Chip Rosenthal, Wietse Venema, Gene Spafford, John Wack and Randall Atkinson. Disclaimer: Every attempt is made to ensure that the information contained in this FAQ is up to date and accurate, but no responsibility will be accepted for actions resulting from information gained herein. Questions which this document addresses: Q.1 What are alt.security and comp.security.misc for? Q.2 Whats the difference between a hacker and a cracker? Q.3 What is "security through obscurity" Q.4 What makes a system insecure? Q.5 What tools are there to aid security? Q.6 Where can I get these tools? Q.7 Isn't it dangerous to give cracking tools to everyone? Q.8 Why and how do systems get broken into? Q.9 Who can I contact if I get broken into? Q.10 What is a firewall? Q.11 Why shouldn't I use setuid shell scripts? Q.12 Why shouldn't I leave "root" permanently logged on the console? Q.13 Why shouldn't I create Unix accounts with null passwords? Q.14 What security holes are associated with X-windows (and other WMs)? Q.15 What security holes are associated with NFS? Q.16 How can I generate safe passwords? Q.17 Why are passwords so important? Q.18 How many possible passwords are there? Q.19 Where can I get more information? Q.20 How silly can people get? --------------------------------------------------------------------------- Q.1 What are alt.security and comp.security.misc for? Comp.security.misc is a forum for the discussion of computer security, especially those relating to Unix (and Unix like) operating systems. Alt.security used to be the main newsgroup covering this topic, as well as other issues such as car locks and alarm systems, but with the creation of comp.security.misc, this may change. This FAQ will concentrate wholly upon computer related security issues. The discussions posted range from the likes of "What's such-and-such system like?" and "What is the best software I can use to do so-and-so" to "How shall we fix this particular bug?", although there is often a low signal to noise ratio in the newsgroup (a problem which this FAQ hopes to address). The most common flamewars start when an apparent security novice posts a message saying "Can someone explain how the such-and-such security hole works?" and s/he is immediately leapt upon by a group of self appointed people who crucify the person for asking such an "unsound" question in a public place, and flame him/her for "obviously" being a cr/hacker. Please remember that grilling someone over a high flame on the grounds that they are "a possible cr/hacker" does nothing more than generate a lot of bad feeling. If computer security issues are to be dealt with in an effective manner, the campaigns must be brought (to a large extent) into the open. Implementing computer security can turn ordinary people into rampaging paranoiacs, unable to act reasonably when faced with a new situation. Such people take an adversarial attitude to the rest of the human race, and if someone like this is in charge of a system, users will rapidly find their machine becoming more restrictive and less friendly (fun?) to use. This can lead to embarrasing situations, eg: (in one university) banning a head of department from the college mainframe for using a network utility that he wasn't expected to. This apparently required a lot of explaining to an unsympathetic committee to get sorted out. A more sensible approach is to secure a system according to its needs, and if its needs are great enough, isolate it completely. Please, don't lose your sanity to the cause of computer security; it's not worth it. usenet/comp.sources.misc/volume29 usenet/comp.sources.misc/volume30 usenet/comp.sources.misc/volume32 ------------------------------------------------------------------ Q.2 What's the difference between a hacker and a cracker? Lets get this question out of the way right now: On USENET, calling someone a "cracker" is an unambiguous statement that some person persistently gets his/her kicks from breaking from into other peoples computer systems, for a variety of reasons. S/He may pose some weak justification for doing this, usually along the lines of "because it's possible", but most probably does it for the "buzz" of doing something which is illicit/illegal, and to gain status amongst a peer group. Particularly antisocial crackers have a vandalistic streak, and delete filestores, crash machines, and trash running processes in pursuit of their "kicks". The term is also widely used to describe a person who breaks copy protection software in microcomputer applications software in order to keep or distribute free copies. On USENET, calling someone a "hacker" is usually a statement that said person holds a great deal of knowledge and expertise in the field of computing, and is someone who is capable of exercising this expertise with great finesse. For a more detailed definition, readers are referred to the Jargon File [Raymond]. In the "real world", various media people have taken the word "hacker" and coerced it into meaning the same as "cracker" - this usage occasionally appears on USENET, with disastrous and confusing results. Posters to the security newsgroups should note that they currently risk a great deal of flamage if they use the word "hacker" in place of "cracker" in their articles. NB: nowhere in the above do I say that crackers cannot be true hackers. It's just that I don't say that they are... ------------------------------------------------------------------ Q.3 What is "security through obscurity" Security Through Obscurity (STO) is the belief that any system can be secure so long as nobody outside of its implementation group is allowed to find out anything about its internal mechanisms. Hiding account passwords in binary files or scripts with the presumption that "nobody will ever find it" is a prime case of STO. STO is a philosophy favoured by many bureaucratic agencies, and it used to be a major method of providing "pseudosecurity" in computing systems. Its usefulness has declined in the computing world with the rise of open systems, networking, greater understanding of programming techniques, as well as the increase in computing power available to the average person. The basis of STO has always been to run your system on a "need to know" basis. If a person doesn't know how to do something which could impact system security, then s/he isn't dangerous. Admittedly, this is sound in theory, but it can tie you into trusting a small group of people for as long as they live. If your employees get an offer of better pay from somewhere else, the knowledge goes with them, whether the knowledge is replaceable or not. Once the secret gets out, that is the end of your security. Nowadays there is also a greater need for the ordinary user to know details of how your system works than ever before, and STO falls down a as a result. Many users today have advanced knowledge of how their operating system works, and because of their experience will be able to guess at the bits of knowledge that they didn't "need to know". This bypasses the whole basis of STO, and makes your security useless. Hence there is now a need is to to create systems which attempt to be algorithmically secure (Kerberos, Secure RPC), rather than just philosophically secure. So long as your starting criteria can be met, your system is LOGICALLY secure. Incidentally, "Shadow Passwords" (below) are sometimes dismissed as STO, but this is incorrect, since (strictly) STO depends on restricting access to an algorithm or technique, whereas shadow passwords provide security by restricting access to vital data. ------------------------------------------------------------------ Q.4 What makes a system insecure? Switching it on. The adage usually quoted runs along these lines: "The only system which is truly secure is one which is switched off and unplugged, locked in a titanium lined safe, buried in a concrete bunker, and is surrounded by nerve gas and very highly paid armed guards. Even then, I wouldn't stake my life on it." (the original version of this is attributed to Gene Spafford) A system is only as secure as the people who can get at it. It can be "totally" secure without any protection at all, so long as its continued good operation is important to everyone who can get at it, assuming all those people are responsible, and regular backups are made in case of hardware problems. Many laboratory PC's quite merrily tick away the hours like this. The problems arise when a need (such as confidentiality) has to be fulfilled. Once you start putting the locks on a system, it is fairly likely that you will never stop. Security holes manifest themselves in (broadly) four ways: 1) Physical Security Holes. - Where the potential problem is caused by giving unauthorised persons physical access to the machine, where this might allow them to perform things that they shouldn't be able to do. A good example of this would be a public workstation room where it would be trivial for a user to reboot a machine into single-user mode and muck around with the workstation filestore, if precautions are not taken. Another example of this is the need to restrict access to confidential backup tapes, which may (otherwise) be read by any user with access to the tapes and a tape drive, whether they are meant to have permission or not. 2) Software Security Holes - Where the problem is caused by badly written items of "privledged" software (daemons, cronjobs) which can be compromised into doing things which they shouldn't oughta. The most famous example of this is the "sendmail debug" hole (see bibliography) which would enable a cracker to bootstrap a "root" shell. This could be used to delete your filestore, create a new account, copy your password file, anything. (Contrary to popular opinion, crack attacks via sendmail were not just restricted to the infamous "Internet Worm" - any cracker could do this by using "telnet" to port 25 on the target machine. The story behind a similar hole (this time in the EMACS "move-mail" software) is described in [Stoll].) New holes like this appear all the time, and your best hopes are to: a: try to structure your system so that as little software as possible runs with root/daemon/bin privileges, and that which does is known to be robust. b: subscribe to a mailing list which can get details of problems and/or fixes out to you as quickly as possible, and then ACT when you receive information. >From: Wes Morgan > > c: When installing/upgrading a given system, try to install/enable only > those software packages for which you have an immediate or foreseeable > need. Many packages include daemons or utilities which can reveal > information to outsiders. For instance, AT&T System V Unix' accounting > package includes acctcom(1), which will (by default) allow any user to > review the daily accounting data for any other user. Many TCP/IP packa- > ges automatically install/run programs such as rwhod, fingerd, and > tftpd, all of which can present security problems. > > Careful system administration is the solution. Most of these programs > are initialized/started at boot time; you may wish to modify your boot > scripts (usually in the /etc, /etc/rc, /etc/rcX.d directories) to pre- > vent their execution. You may wish to remove some utilities completely. > For some utilities, a simple chmod(1) can prevent access from unauthorized > users. > > In summary, DON'T TRUST INSTALLATION SCRIPTS/PROGRAMS! Such facilities > tend to install/run everything in the package without asking you. Most > installation documentation includes lists of "the programs included in > this package"; be sure to review it. 3) Incompatible Usage Security Holes - Where, through lack of experience, or no fault of his/her own, the System Manager assembles a combination of hardware and software which when used as a system is seriously flawed from a security point of view. It is the incompatibility of trying to do two unconnected but useful things which creates the security hole. Problems like this are a pain to find once a system is set up and running, so it is better to build your system with them in mind. It's never too late to have a rethink, though. Some examples are detailed below; let's not go into them here, it would only spoil the surprise. 4) Choosing a suitable security philosophy and maintaining it. >From: Gene Spafford >The fourth kind of security problem is one of perception and >understanding. Perfect software, protected hardware, and compatible >components don't work unless you have selected an appropriate security >policy and turned on the parts of your system that enforce it. Having >the best password mechanism in the world is worthless if your users >think that their login name backwards is a good password! Security is >relative to a policy (or set of policies) and the operation of a system >in conformance with that policy. ------------------------------------------------------------------ Q.5 What tools are there to aid security Q.6 ...and... where can I get these tools? ================================================================== *** This is a section which has changed very rapidly over the past *** few months; hence I am changing the format ever so slightly, in *** order to allow for expansion - Alec ================================================================== COPS Dan Farmer, et al. Managed/largely written by Dan Farmer, COPS is a suite of shell scripts which forms an extensive security testing system; there's a rudimentary password cracker, and routines to check the filestore for suspicious changes in setuid programs, others to check permissions of essential system and user files, and still more to see whether any system software behaves in a way which could cause problems. The software comes in two versions - one written in Perl and one (largely equivalent) written in shell scripts. The latest version is very up-to-date on Unix Security holes. COPS V1.04 is available for FTP from cert.org in pub/cops and archive.cis.ohio-state.edu in pub/cops. ------------------------------------------------------------------ Crack Alec Muffett UFC Michael Glad Crack is a program written with one purpose in mind: to break insecure passwords. It is probably the most efficent and friendly password cracker that is publically available, with the ability to let the user to specify precisely how to form the words to use as guesses at users passwords. It also has an inbuilt networking capability, allowing the load of cracking to be spread over as many machines as are available on a network, and it is supplied with an optimised version of the Unix crypt() algorithm. An even faster version of the crypt() algorithm, "UFC" by Michael Glad, is freely available on the network, and the latest versions of UFC and Crack are compatible and can be easily hooked together. Crack v4.1f and UFC are available from: ftp.uu.net (137.39.1.9) In the directory: /usenet/comp.sources.misc/volume28 As: crack/part01.Z to part05.Z ( 5 files ) And ufc-crypt/part01.Z & part02.Z ( 2 files ) NB: For people with access to a Connection Machine: >From: glad@daimi.aau.dk (Michael Glad) > >A UNIX password cracker for the Thinking Machine CM/2 and CM/200 >Connection Machines is available for FTP from > > ftp.denet.dk:/pub/misc/cm200-UFC.tar.Z > > This is a password cracker for the Thinking Machines CM/2 and CM/200 > Connection Machines. It features > > o A standalone dictionary preprocessor accepting a > language of rewrite rules compatible with the one > found in Alec Muffets 'Crack' password cracker as of > release 4.1f. > > o An optimized port of the UFC-crypt: a fast implementation > of the UNIX crypt(3) function developed by Michael Glad and > donated to the Free Software Foundation (FSF). > > o The password cracker itself. It supports restart of crashed > runs and incremental use. Incremental use means that when > you use a fixed dictionary, the cracker can maintain a status > file of already cracked passwords and passwords considered > uncrackable (because they've been tested in previous runs). > Thus it only has to waste CPU cycles on new accounts and accounts > with changed passwords. > > o When run with a _large_ dictionary (a 1 million word dictionary > obtained by preprocessing /usr/dict/words), the cracker can > test in excess of 50,000 passwords a second on a CM/200 with > 8192 processors. ------------------------------------------------------------------ CrackLib Alec Muffett Cracklib is a C LIBRARY containing a routine which may be wired into all sorts of "passwd"-like programs; not just Unix, but with a little effort it could probably go onto VMS (this is being worked upon), or many other systems. Using "CrackLib" allows you to wire proactive password checking into _any_ of your applications; it is an offshoot of the the version 5 "Crack" software, and contains a considerable number of ideas nicked from the new software. CrackLib was posted to "comp.sources.misc", and therefore available from any major usenet archive. A reference copy (+ large dictionary) can be FTP'ed from: black.ox.ac.uk:~ftp/src/security/cracklib25.tar.Z NB: if you search for CrackLib on "Archie", care should be taken to get the package from a comp.sources.misc archive; beware confusing it with a package of the same name, which was hacked into "npasswd". ------------------------------------------------------------------ NPasswd Clyde Hoover Passwd+ Matt Bishop Shadow John F. Haugh II Passwd+ & NPasswd: these programs are written to redress the balance in the password cracking war. They provide replacements for the standard "passwd" command, but prevent a user from selecting passwords which are easily compromised by programs like Crack. The usual term for this type of program is a 'fascist' password program. NPasswd: Currently suffering from being hacked about by many different people, in order to provide compatibility for System V based systems, NIS/YP, shadow password schemes, etc. Version 2.0 is in the offing, but many versions exist in many different configurations. Passwd+: "alpha version, update 3" - beta version due soon. Available from dartmouth.edu as pub/passwd+.tar.Z Shadow: is a set of program and function replacements (compatible with most Unixes) which implements shadow passwords, ie: a system where the plaintext of the password file is hidden from all users except root, hopefully stopping all password cracking attempts at source. In combination with a fascist passwd frontend, it should provide a good degree of password file robustness. >From: jfh@rpp386.cactus.org (John F. Haugh II) >Shadow does much more than hide passwords. It also provides for >terminal access control, user and group administration, and a few >other things which I've forgotten. There are a dozen or more >commands in the suite, plus a whole slew of library functions. Shadow is available from the comp.sources.misc directory at any major USENET archive - relevant files are in: usenet/comp.sources.misc/volume38 usenet/comp.sources.misc/volume39 - the contents of both of which are needed, for a full set of patches. Given that the latest release of Shadow has a hook for "CrackLib" support, it now ranks as a full blown fascist password program, on top of its other functionality. CrackLib support is expected in Passwd+, in the near future. ------------------------------------------------------------------ TCP Wrappers Wietse Venema These are programs which provide front-end filters to MOST of the network services which Unix provides by default. If installed, they can curb otherwise unrestricted access to potential dangers like incoming FTP/TFTP, Telnet, etc, and can provide extra logging information, which may be of use if it appears that someone is trying to break in. >From the BLURB >With these programs you can monitor and control who connects to your >TFTP, EXEC, FTP, RSH, TELNET, RLOGIN, FINGER, and SYSTAT network >services, and many others. > >The programs can be installed without any changes to existing software >or configuration files. By default, they just log the remote host name >and do some sanity checks on the origin of the request. No information >is exchanged with the remote client process. > >Significant differences with respect to the previous release: > > - Easier to install: ready-to-use build procedures for many common > UNIX implementations (sun, ultrix, hp-ux, irix, aix, ...). > > - Support for the System V.4 TLI network programming interface > (Solaris, DG/UX etc.). In case of TLI applications on top of > TCP/IP, the wrappers provide the same functionality as with > socket-based applications. > > - A more secure finger tool for automatic reverse finger probes. > > - New extension language keywords: "severity", to adjust the log > noise level; "allow" and "deny", to keep all access-control rules > within a single file. > > - More support for selective remote username lookups. > > - More workarounds for System V bugs: IRIX username lookups, and > SCO problems with UDP. > > The default mode of operation (no TLI support) should be backwards > compatible with earlier versions. The library interface has changed, > though, and programs that depend on the libwrap.a library will have to > be recompiled before they can be relinked. > > Wietse Venema (wietse@wzv.win.tue.nl) TCP Wrappers are available for anonymous FTP from: cert.org:pub/tools/tcp_wrappers ------------------------------------------------------------------ SecureLib William LeFebvre >From: phil@pex.eecs.nwu.edu >You may want to add a mention of securelib, a security enhancer >available for SunOS version 4.1 and higher. >Securelib contains replacement routines for three kernel calls: >accept(), recvfrom(), recvmsg(). These replacements are compatible with >the originals, with the additional functionality that they check the >Internet address of the machine initiating the connection to make sure >that it is "allowed" to connect. A configuration file defines what >hosts are allowed for a given program. Once these replacement routines >are compiled, they can be used when building a new shared libc library. >The resulting libc.so can then be put in a special place. Any program >that should be protected can then be started with an alternate >LD_LIBRARY_PATH. The latest version of securelib is available via anonymous FTP from the host "eecs.nwu.edu". It is stored in the file "pub/securelib.tar". ------------------------------------------------------------------ ISS Chris Klaus YPX Rob Nauta >Internet Security Scanner (ISS) is one of the first multi-level security >scanners available to the public. It was designed to be flexible and >easily portable to many unix platforms and do its job in a reasonable >amount of time. It provides information to the administrator that will >fix obvious security misconfigurations. > >ISS does a multi-level scan of security, not just searching for one >weakness in the system. To provide this to the public or at least to >the security conscious crowd may cause people to think that it is too >dangerous for the public, but many of the (cr/h)ackers are already aware >of these security holes and know how to exploit them. > >These security holes are not deep in some OS routines, but standard >misconfigurations that many domains on Internet tend to show. Many of >these holes are warned about in CERT and CIAC advisories. This is the >first release of ISS and there is still much room for improvement. [...A simplistic description of ISS might be that it is to the Unix Network Services, what COPS is to the Unix filesystem; ie: a tool to allow a systems administrator to find potential holes, giving him/her a chance to solve the problem BEFORE a cracker attack an occur. ISS and an auxilliary program, YPX, have been recently posted to comp.sources.misc. Because ISS is in a early stage of development, check an "Archie" site for the most up-to-date information...Alec] ------------------------------------------------------------------ TripWire Gene Kim, Gene Spafford [From the Announce file] >Tripwire is an integrity-monitor for Unix systems. It uses several >checksum/signature routines to detect changes to files, as well as >monitoring selected items of system-maintained information. The system >also monitors for changes in permissions, links, and sizes of files and >directories. It can be made to detect additions or deletions of files >from watched directories. > >The configuration of Tripwire is such that the system/security >administrator can easily specify files and directories to be monitored >or to be excluded from monitoring, and to specify files which are >allowed limited changes without generating a warning. Tripwire can also >be configured with customized signature routines for site-specific >checks. > >Tripwire, once installed on a clean system, can detect changes from >intruder activity, unauthorized modification of files to introduce >backdoor or logic-bomb code, (if any were to exist) virus activity in >the Unix environment. > >Tripwire is provided as source code with documentation. The system, as >delivered, performs no changes to system files and does not require root >privilege to run (in the general case). The code has been beta-tested >in a form close to that of this release at over 100 sites world-wide. >Tripwire should work on almost any version of Unix, from Xenix on >80386-based machines to Cray and ETA-10 supercomputers. > >Tripwire may be used without charge, but it may not be sold or modified >for sale. Tripwire was written as a project under the auspices of the >COAST Project at Purdue University. The primary author was Gene Kim, >with the aid and under the direction of Gene Spafford (COAST director). > >Copies of the Tripwire distribution may be ftp'd from ftp.cs.purdue.edu >from the directory pub/spaf/COAST/Tripwire. The distribution is >available as a compressed tar file, and as uncompressed shar kits. The >shar kit form of Tripwire version 1.0 will also be posted to >comp.sources.unix on the Usenet. > >A mailserver exists for distribution and to support a Tripwire mailing >list. To use the mail server, send e-mail to >"tripwire-request@cs.purdue.edu" with a message body consisting solely >of the word "help". The server will respond with instructions on how to >get source, patches, and how to join the mailing list. > >Questions, comments, complaints, bugfixes, etc may be directed to: >genek@mentor.cc.purdue.edu (Gene Kim) >spaf@cs.purdue.edu (Gene Spafford) ------------------------------------------------------------------ TAMU Dave Safford, Doug Schales, Dave Hess >From the ANNOUNCE file: > Texas A&M Network Security Package Update > 7/1/93 > > Dave Safford > Doug Schales > Dave Hess > >This is an updated release of the security tools developed at the >Texas A&M University Supercomputer Center. These tools are available >for anonymous FTP from net.tamu.edu:/pub/security/TAMU. [...] >ORIGINAL DESCRIPTION: > >Last August, Texas A&M University UNIX computers came under extensive >attack from a coordinated group of internet crackers. This package of >security tools represents the results of over nine months of >development and testing of the software we have been using to protect >our estimated five thousand IP devices. This package includes three >coordinated sets of tools: "drawbridge", an exceptionally powerful >bridging filter package; "tiger", a set of convenient yet thorough >machine checking programs; and "netlog", a set of intrusion detection >network monitoring programs. > >KEY FEATURES: > >For full technical details on the products, see their individual README's, >but here are some highlights: > > DRAWBRIDGE: > - inexpensive (PC with two SMC/WD 8013 cards) > - high level filter language and compiler > - powerful filtering parameters > - DES authenticated remote filter management > - O(1) table lookup processing even with dense class B > net filter specifications. > > TIGER: > - checks key binaries against cryptographic > checksums from original distribution files > - checks for critical security patches > - checks for known intrusion signatures > - checks all critical configuration files > - will run on most UNIX systems, and has tailored > components for SunOS, Next, SVR4, Unicos. > > NETLOG: > - efficiently logs all tcp/udp establishment attempts > - powerful query tool for analyzing connection logs > - "intelligent" intrusion detection program > >AVAILABILITY: > >This package is available via anonymous ftp in > > net.tamu.edu: pub/security/TAMU > >Due to the sensitive nature of these tools, we recommend that you >retrieve them from this location. If you do not get them from >net.tamu.edu we suggest that you use our check_TAMU script that uses >cryptographic checksums to check the distribution for any signs of >tampering. The script is available in the anonymous ftp directory above >and from an e-mail server at: > > drawbridge-server@net.tamu.edu > >Note that there are some distribution limitations, such as the >inability to export outside the US the DES libraries used in >drawbridge; see the respective tool README's for details of any >restrictions. (Note that the DES libraries are NOT required to use >drawbridge. They just enable secure remote management of drawbridge.) > >CONTACT: > >Comments and questions are most welcome. Please address them to: > > drawbridge@net.tamu.edu [A wonderful paper about TAMU was presented at the 4th USENIX Security Symposium, and is reprinted in the proceedings of the same - Alec] ------------------------------------------------------------------ SPI >From: Gene Spafford >Sites connected with the Department of Energy and some military >organizations may also have access to the SPI package. Interested (and >qualified) users should contact the CIAC at LLNL for details. >SPI is a screen-based administrator's tool that checks configuration >options, includes a file-change (integrity) checker to monitor for >backdoors and viruses, and various other security checks. Future >versions will probably integrate COPS into the package. It is not >available to the general public, but it is available to US Dept of >Energy contractors and sites and to some US military sites. A version >does or will exist for VMS, too. Further information on availabilty can >be had from the folks at the DoE CIAC. [...A paper on SPI was recently presented at the 1993 USENIX Security symposium; apparently v2.1 has appeared on an anonymous FTP site recently, but whether this is in accordance with licencing agreements is unknown to the author of this FAQ, and anyway, he's forgotten what the IP address was, so...] ------------------------------------------------------------------ TIS Firewall Toolkit Trusted Information Systems, Inc. >From: mjr@tis.com (Marcus J. Ranum) > >Version 1.0 of the TIS network firewall toolkit is now available for >anonymous FTP from ftp.tis.com, in directory pub/firewalls/toolkit > >WHAT IS THE TIS FIREWALL TOOLKIT? >--------------------------------- >Trusted Information Systems, Inc. (TIS) is pleased to provide the TIS >Firewall Toolkit, a software kit for building and maintaining >internetwork Firewalls. It is distributed in source code form, with all >modules written in the C programming language and runs on many BSD UNIX >derived platforms. The Toolkit is being made available for use as >specified in the license agreement (LICENSE). > >The firewall toolkit is a set of programs, configuration practices, and >documentation intended to help individuals who are trying to build >internet firewalls. Included with the kit are complete sources for FTP, >rlogin, and telnet application proxies, user authentication management, >compartmented SMTP, and logging/log reduction. > >USERS' GROUP >------------ >TIS maintains the electronic-mail users' group for >discussion of the toolkit. To join, send electronic mail to >. > >TIS Firewall Toolkit technical questions, license issues, bug reports, >etc. should be addressed to . > >Information about other TIS network security products or commercial >licensing requests should be sent to or by telephone to >(301) 854-6889. > > >The contents of pub/firewalls/toolkit are as follows: >README - This file >fwtk-doc-only.tar.Z - Toolkit documentation >fwtk.tar.Z - Toolkit sources and Makefiles (no documentation) >US-only - Directory containing US-only software. If you > are not accessing this from a site in the US or > canada you will not be able to FTP these files. > The toolkit is still useable without these files. ------------------------------------------------------------------ SOCKS Ying-Da Lee/David Koblas >From: ylee@syl.dl.nec.com (Ying-Da Lee) > >(This is a package that allows hosts behind a firewall the use of >finger, ftp, telnet, xgopher, and xmosaic to access the resources >outside of the firewall while maintaining the security requirements.) > >A new release of SOCKS is available for anonymous ftp from > > host ftp.inoc.dl.nec.com (143.101.112.3), > file pub/security/socks.cstc.4.0.tar.gz > >This version is intended to run with identd user verification (RFC 1413), >which is available as file pub/security/pidentd-2.1.2.tar.gz. > >Both of these are in Gnu's compressed form and required gzip to >uncompress them. If you don't already have that you can also pick up >the file pub/gnu/gzip-1.1.2.tar.Z. Remember to download them in binary >mode. > > >I am enclosing the first part of the README.1st file which describes the >new fearures. Besides SunOS 4.1.x, the new version has also been ported >and tested on ULTRIX 4.3, IRIX 4.0.1, and partially on HPUX, thanks to >Ian Dunkin and Anthony Shipman. > >Hope you can make good use of the package. Enjoy it. > >**** >This is SOCKS, a package consisting of a proxy server (sockd) and client >programs corresponding to finger, whois, ftp, telnet, xgopher, and >xmosaic, as well as a library module (libsocks.a) for adapting other >applications into new client programs. > >The original SOCKS was written by David Koblas , >which included the library module and finger, whois, and ftp clients. > >Clients programs added since the original are: > >-telnet: adapted from telnet.91.03.25 by David Borman . > This version is supposed to be much easier than the previous one > to port to many different systems. >-xgopher: adapted from xgopher ver. 1.2 by Allan Tuchman . >-xmosaic: adapted from xmosaic ver. 1.2 by NCSA staff (contact > Marc Andreesen, ). > >The SOCKS protocol has changed with this version. Since the server and >the clients must use the same SOCKS protocol, this server does not work >with clients of previous releases, and these clients do not work with >servers of previous releases. > >The access control mechanism has been expanded: > >-A list of users can be included along with other fields (source address, > destination address, service/port) for permission/denial of access. >-Identd is used (controlled by option -i and -I) in SOCKS server to try > to verify the actual user-ids. The code uses the library written by > Peter Eriksson and /Pdr Emanuelsson . >-A shell command can optionally be specified with each line. The command > is executed if the conditions of that line are satisfied. This is adapted > from the same feature and code used in the log_tcp package by Wietse > Venema . >-Special entries (#NO_IDENTD: and #BAD_ID:) can be included to specify > shell commands to be executed when the client host doesn't run identd > and when identd's report doesn't agree with what the client prgram says. > >[...] >The package has been ported for ULTRIX 4.3 by Ian Dunkin and Anthony >Shipman, for IRIX 4.0.1 by Ian Dunkin (again), and partially for HPUX by >Anthony Shipman (again!). (We are a small bunch of busy bees) I also >include patches by Craig Metz to SOCKSize xarchie and ncftp. I have not >try these patches out myself though. >[...] ------------------------------------------------------------------ ================================================================== Q.7 Isn't it dangerous to give cracking tools to everyone? That depends on your point of view. Some people have complained that giving unrestricted public access to programs like COPS and Crack is irresponsible because the "baddies" can get at them easily. Alternatively, you may believe that the really bad "baddies" have had programs like this for years, and that it's really a stupendously good idea to give these programs to the good guys too, so that they may check the integrity of their system before the baddies get to them. So, who wins more from having these programs freely available? The good guys or the bad ? You decide, but remember that less honest tools than COPS and Crack tools were already out there, and most of the good guys didn't have anything to help. ------------------------------------------------------------------ Q.8 Why and how do systems get broken into? This is hard to answer definitively. Many systems which crackers break into are only used as a means of entry into yet more systems; by hopping between many machines before breaking into a new one, the cracker hopes to confuse any possible pursuers and put them off the scent. There is an advantage to be gained in breaking into as many different sites as possible, in order to "launder" your connections. Another reason may be psychological: some people love to play with computers and stretch them to the limits of their capabilities. Some crackers might think that it's "really neat" to hop over 6 Internet machines, 2 gateways and an X.25 network just to knock on the doors of some really famous company or institution (eg: NASA, CERN, AT+T, UCB). Think of it as inter-network sightseeing. This view is certainly appealing