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 regularlyappear in the Usenet newsgroups "comp.security.misc" and
"alt.security",and is meant to provide some background to the subject for
newcomers tothat newsgroup.This FAQ is maintained by Alec Muffett (aem@aber.ac.uk,
uknet!aber!aem),with contributions from numerous others [perhaps]. The views
expressedin the document are the personal views of the author(s), and it shouldnot
be inferred that they are necessarily shared by anyone with whom theauthor(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 informationcontained in this FAQ is up to date and accurate, but
no responsibilitywill 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 Isn't it dangerous to give cracking tools to
everyone?Q.7 Where can I get these tools?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 wellas 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-suchsystem 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 FAQhopes 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 holeworks?" and
s/he is immediately leapt upon by a group of self appointedpeople who crucify the
person for asking such an "unsound" question in apublic place, and flame him/her
for "obviously" being a cr/hacker.Please remember that grilling someone over a
high flame on the groundsthat they are "a possible cr/hacker" does nothing more
than generate alot of bad feeling. If computer security issues are to be dealt
with inan 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 rapidlyfind their machine becoming more
restrictive and less friendly (fun?) touse.This can lead to embarrasing
situations, eg: (in one university) banninga head of department from the college
mainframe for using a networkutility that he wasn't expected to. This apparently
required a lot ofexplaining 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'tlose your sanity to the
cause of computer security; it's not worth it.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 thatsome person
persistently gets his/her kicks from breaking from intoother peoples computer
systems, for a variety of reasons. S/He may posesome weak justification for doing
this, usually along the lines of"because it's possible", but most probably does it
for the "buzz" ofdoing something which is illicit/illegal, and to gain status
amongst apeer group.Particularly antisocial crackers have a vandalistic streak,
and deletefilestores, 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 tokeep or
distribute free copies.On USENET, calling someone a "hacker" is usually a
statement that saidperson holds a great deal of knowledge and expertise in the
field ofcomputing, and is someone who is capable of exercising this expertisewith
great finesse. For a more detailed definition, readers arereferred 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 usageoccasionally
appears on USENET, with disastrous and confusing results.Posters to the security
newsgroups should note that they currently riska 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 a system of any sortcan be secure so long as nobody outside of its
implementation group isallowed to find out anything about its internal mechanisms.
Hidingaccount 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 (military,governmental, and industrial), and it used to
be a major method ofproviding "pseudosecurity" in computing systems.Its usefulness
has declined in the computing world with the rise of opensystems, networking,
greater understanding of programming techniques, aswell 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 impactsystem security, then s/he isn't dangerous.Admittedly,
this is sound in theory, but it can tie you into trusting asmall group of people
for as long as they live. If your employees getan offer of better pay from
somewhere else, the knowledge goes withthem, whether the knowledge is replaceable
or not. Once the secret getsout, that is the end of your security.Nowadays there
is also a greater need for the ordinary user to knowdetails of how your system
works than ever before, and STO falls down aas a result. Many users today have
advanced knowledge of how theiroperating system works, and because of their
experience will be able toguess at the bits of knowledge that they didn't "need to
know". Thisbypasses the whole basis of STO, and makes your security useless.Hence
there is now a need is to to create systems which attempt to bealgorithmically
secure (Kerberos, Secure RPC), rather than justphilosophically secure. So long as
your starting criteria can be met,your system is LOGICALLY secure."Shadow
Passwords" (below) are sometimes dismissed as STO, but this isincorrect, since
(strictly) STO depends on restricting access to analgorithm or technique, whereas
shadow passwords provide security byrestricting 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 continuedgood
operation is important to everyone who can get at it, assuming allthose people are
responsible, and regular backups are made in case ofhardware problems. Many
laboratory PC's quite merrily tick away thehours like this.The problems arise when
a need (such as confidentiality) has to befulfilled. Once you start putting the
locks on a system, it is fairlylikely 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 personsphysical access to the
machine, where this might allow them to performthings that they shouldn't be able
to do.A good example of this would be a public workstation room where it wouldbe
trivial for a user to reboot a machine into single-user mode and muckaround with
the workstation filestore, if precautions are not taken.Another example of this is
the need to restrict access to confidentialbackup tapes, which may (otherwise) be
read
by any user with access tothe tapes and a tape drive, whether they are meant to
have permission ornot.2) Software Security Holes- Where the problem is caused by
badly written items of "privledged"software (daemons, cronjobs) which can be
compromised into doing thingswhich they shouldn't oughta.The most famous example
of this is the "sendmail debug" hole (seebibliography) which would enable a
cracker to bootstrap a "root" shell.This could be used to delete your filestore,
create a new account, copyyour password file, anything.(Contrary to popular
opinion, crack attacks via sendmail were not justrestricted to the infamous
"Internet Worm" - any cracker could do thisby using "telnet" to port 25 on the
target machine. The story behind asimilar hole (this time in EMACS) 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.3)
Incompatible Usage Security Holes- Where, through lack of experience, or no fault
of his/her own, theSystem Manager assembles a combination of hardware and software
whichwhen used as a system is seriously flawed from a security point of view.It is
the incompatibility of trying to do two unconnected but usefulthings which creates
the security hole.Problems like this are a pain to find once a system is set up
andrunning, so it is better to build your system with them in mind. It'snever too
late to have a rethink, though.Some examples are detailed below; let's not go into
them here, it wouldonly spoil the surprise.4) Choosing a suitable security
philosophy and maintaining it.>From: Gene Spafford <spaf@cs.purdue.edu>>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?1) "COPS"
Managed by Dan Farmer, this is a long established suite of shell scriptswhich
forms an extensive security testing system; There is a rudimentarypassword
cracker, and routines to check the filestore for suspiciouschanges in setuid
programs, others to check permissions of essentialsystem and user files, and still
more to see whether any system softwarebehaves 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 isvery up-to-date on
Unix Security holes.2) "Crack" (+ "UFC").Written by Alec Muffett, this is a
program written with one purpose inmind: to break insecure passwords. It is
probably the most efficent andfriendly password cracker that is publically
available, with the abilityto let the user to specify precisely how to form the
words to use asguesses at users passwords.It also has an inbuilt networking
capability, allowing the load ofcracking to be spread over as many machines as are
available on anetwork, 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 andCrack
are compatible and can be easily hooked together.3) NPasswd (Clyde Hoover) &
Passwd+ (Matt Bishop)These programs are written to redress the balance in the
passwordcracking war. They provide replacements for the standard "passwd"command,
but prevent a user from selecting passwords which are easilycompromised by
programs like Crack.Several versions of these programs are available on the
network, hackedabout to varying degrees in order to provide compatibility for
System Vbased systems, NIS/YP, shadow password schemes, etc. The usual term for
this type of program is a 'fascist' password program.4) "Shadow" - a Shadow
Password SuiteThis program suite (by John F Haugh II) is a set of program and
functionreplacements (compatible with most Unixes) which implements shadow
passwords, ie: a system where the plaintext of the password file ishidden from all
users except root, hopefully stopping all passwordcracking attempts at source. In
combination with a fascist passwdfrontend, it should provide a good degree of
password file robustness.>From: jfh@rpp386.lonestar.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.
5) TCP Wrappers (Wietse Venema)These are programs which provide a front-end filter
to many of thenetwork services which Unix provides by default. If installed, they
cancurb otherwise unrestricted access to potential dangers like incomingFTP/TFTP,
Telnet, etc, and can provide extra logging information, whichmay be of use if it
appears that someone is trying to break in.6) SecureLib>From:
phil@pex.eecs.nwu.edu (William LeFebvre)>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.7) SPI>From: Gene Spafford <spaf@cs.purdue.edu>>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.Q.6 Isn't it
dangerous to give cracking tools to everyone?That depends on your point of view.
Some people have complained thatgiving unrestricted public access to programs like
COPS and Crack isirresponsible because the "baddies" can get at them easily.
Alternatively, you may believe that the really bad "baddies" have hadprograms like
this for years, and that it's really a stupendously goodidea to give these
programs to the good guys too, so that they may checkthe integrity of their system
before the baddies get to them.So, who wins more from having these programs freely
available? The goodguys or the bad ? You decide, but remember that less honest
tools thanCOPS and Crack tools were already out there, and most of the good guys
didn't have anything to help.Q.7 Where can I get these tools?COPS: V1.04,
available for FTP from cert.sei.cmu.edu in pub/cops and archive.cis.ohio-
state.edu in pub/cops.Crack/UFC: Crack v4.1f and UFC Patchlevel 1. Available
from any major USENET archive (eg: ftp.uu.net) in volume 28 of comp.sources.misc.
NPasswd: Currently suffering from being hacked about by many different people.
Version 2.0 is in the offing, but many versions exist in many different
configurations. Will chase this up with authors - AEMPasswd+: "alpha version,
update 3" - beta version due soon. Available from dartmouth.edu as
pub/passwd+.tar.ZShadow: This is available from the comp.sources.misc directory
at any major USENET archive (see entry for Crack)TCP Wrappers: Available for
anonymous FTP: cert.sei.cmu.edu: pub/network_tools/tcp_wrapper.shar
ftp.win.tue.nl: pub/security/log_tcp.shar.ZSecurelib: 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".Q.8 Why and how do systems get broken into?
This is hard to answer definitively. Many systems which crackers breakinto are
only used as a means of entry into yet more systems; by hoppingbetween many
machines before breaking into a new one, the cracker hopesto confuse any possible
pursuers and put them off the scent. There isan advantage to be gained in
breaking into as many different sites aspossible, 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 Internetmachines, 2 gateways and an
X.25 network just to knock on the doors ofsome really famous company or
institution (eg: NASA, CERN, AT+T, UCB).Think of it as inter-network sightseeing.
This view is certainly appealing to some
crackers, and certainly leadsto both the addiction and self-perpetuation of
cracking.As to the "How" of the question, this is again a very sketchy area. In
universities, it is extremely common for computer account to be passedback and
forth between undergraduates: "Mary gives her account password to her boyfriend
Bert at another site, who has a friend Joe who "plays around on the networks".
Joe finds other crackable accounts at Marys site, and passes them around amongst
his friends..." pretty soon, a whole society of crackers is playing around on the
machines that Mary uses.This sort of thing happens all the time, and not just in
universities.One solution is in education. Do not let your users develop
attitudeslike this one: "It doesn't matter what password I use on _MY_
account, after all, I only use it for laserprinting..."
- an Aberystwyth Law student, 1991Teach them that use of the computer is a group
responsibility. Makesure that they understand that a chain is only as strong as
it's weaklink.Finally, when you're certain that they understand your problems as a
systems manager and that they totally sympathise with you, configureyour system in
such a way that they can't possibly get it wrong.Believe in user education, but
don't trust to it alone.Q.9 Who can I contact if I get broken into?If you're
connected to the Internet, you should certainly get in touchwith CERT, the
Computer Emergency Response Team. To quote the official blurb:>From: Ed
DeHart> The Computer Emergency Response Team (CERT) was formed by the Defense>
Advanced Research Projects Agency (DARPA) in 1988 to serve as a focal> point for
the computer security concerns of Internet users. The> Coordination Center for
the CERT is located at the Software Engineering> Institute, Carnegie Mellon
University, Pittsburgh, PA.> Internet E-mail: cert@cert.sei.cmu.edu> Telephone:
412-268-7090 24-hour hotline:> CERT/CC personnel answer 7:30a.m. to 6:00p.m.
EST(GMT-5)/EDT(GMT-4),> and are on call for emergencies during other hours.
...and also, the umbrella group "FIRST", which mediates between theincident
handling teams themselves...>From: John Wack <wack@csrc.ncsl.nist.gov>>[...] FIRST
is actually a very viable and growing>organization, of which CERT is a member.
It's not actually true that,>if you're connected to the Internet, you should call
CERT only - that>doesn't do justice to the many other response teams out there and
in the>process of forming.>NIST is currently the FIRST secretariat; we maintain an
anonymous ftp>server with a directory of FIRST information (csrc.ncsl.nist.gov:
>~/pub/first). This directory contains a contact file that lists the>current
members and their constituencies and contact information>(filename "first-
contacts").>While CERT is a great organization, other response teams who do handle
>incidents on their parts of the Internet merit some mention as well ->perhaps
mentioning the existence of this file would help to do that in a>limited space.The
file mentioned is a comprehensive listing of contact points pernetwork for
security incidents. It is too large to reproduce here, Isuggest that the reader
obtains a copy for his/her self by the meansgiven.Q.10 What is a firewall?A
(Internet) firewall is a machine which is attached (usually) betweenyour site and
a wide area network. It provides controllable filteringof network traffic,
allowing restricted access to certain internet portnumbers (ie: services that your
machine would otherwise provide to thenetwork as a whole) and blocks access to
pretty well everything else.Similar machines are available for other network
types, too.Firewalls are an effective "all-or-nothing" approach to dealing with
external access security, and they are becoming very popular, with therise in
Internet connectivity.For more information on these sort of topics, see the
Gateway paper by[Cheswick], below.Q.11 Why shouldn't I use setuid shell scripts?
You shouldn't use them for a variety of reasons, mostly involving bugsin the Unix
kernel. Here are a few of the more well known problems,some of which are fixed on
more recent operating systems.1) If the script begins "#!/bin/sh" and a link
(symbolic or otherwise)can be made to it with the name "-i", a setuid shell can be
immediatelyobtained because the script will be invoked: "#!/bin/sh -i", ie: an
interactive shell.2) Many kernels suffer from a race condition which can allow you
toexchange the shellscript for another executable of your choice betweenthe times
that the newly exec()ed process goes setuid, and when thecommand interpreter gets
started up. If you are persistent enough, intheory you could get the kernel to
run any program you want.3) The IFS bug: the IFS shell variable contains a list of
characters tobe treated like whitespace by a shell when parsing command names. By
changing the IFS variable to contain the "/" character, the command"/bin/true"
becomes "bin true".All you need do is export the modified IFS variable, install a
commandcalled "bin" in your path, and run a setuid script which calls"/bin/true".
Then "bin" will be executed whilst setuid.If you really must write scripts to be
setuid, either a) Put a setuid wrapper in "C" around the script, being very
careful to reset IFS and PATH to something sensible before exec()ing the script.
If your system has runtime linked libraries, consider the values of the
LD_LIBRARY_PATH also. b) Use a scripting language like Perl which has a safe
setuid facility, and is proactively rabid about security.- but really, it's
safest not to use setuid scripts at all.Q.12 Why shouldn't I leave "root"
permanently logged on the console?Using a 'smart' terminal as console and leaving
"/dev/console" worldwritable whilst "root" is logged in is a potential hole. The
terminalmay be vulnerable to remote control via escape sequences, and can beused
to 'type' things into the root shell. The terminal type canusually be obtained
via the "ps" command.Various solutions to this can be devised, usually by giving
the consoleowner and group-write access only , and then using the setgid mechanism
on any program which has need to output to the console (eg: "write").Q.13 Why
shouldn't I create Unix accounts with null passwords?Creating an unpassworded
account to serve any purpose is potentiallydangerous, not for any direct reason,
but because it can give a crackera toehold.For example, on many systems you will
find a unpassworded user "sync",which allows the sysman to sync the disks without
being logged in. Thisappears to be both safe and innocuous.The problem with this
arises if your system is one of the many whichdoesn't do checks on a user before
authorising them for (say) FTP. Acracker might be able to connect to your machine
for one of a variety ofFTP methods, pretending to be user "sync" with no password,
and thencopy your password file off for remote cracking.Although there are
mechanisms to prevent this sort of thing happening inmost modern vesions of Unix,
to be totally secure requires an in-depthknowledge of every package on your
system, and how it deals with theverification of users. If you can't be sure,
it's probably better notto leave holes like this around.Another hole that having
null-password accounts opens up is thepossibility (on systems with runtime linked
libraries) of spoofingsystem software into running your programs as the "sync"
user, bychanging the LD_LIBRARY_PATH variable to a library of your own devising,
and running "login -p" or "su" to turn into that user.Q.14 What security holes are
associated with X-windows (and other WMs)?Lots, some which affect use of X only,
and some which impact thesecurity of the entire host system.I would prefer not to
go into too much detail here, and would refer anyreader reader looking for
detailed information to the other FAQ's inrelevant newsgroups. (comp.windows.*)
One point I will make is that X is one of those packages which oftengenerates
"Incompatible Usage" security problems, for instance theability for crackers to
run xsessions on hosts under accounts with nopassword (eg: sync), if it is
improperly set up. Read the questionabout unpassworded accounts in this FAQ.Q.15
What security holes are associated with NFS?Lots, mostly to do with who you export
your disks to, and how. Thesecurity of NFS relies heavily upon who is allowed to
mount the filesthat a server exports, and whether they are exported read only or
not.The exact format for specifying which hosts can mount an exporteddirectory
varies between Unix implementations, but generally theinformation is contained
within the file "/etc/exports".This file contains a list of directories and for
each one, it has aseries of either specific "hosts" or "netgroups" which are
allowed toNFS mount that directory. This list is called the "access list".The
"hosts" are individual machines, whilst "netgroups" are combinationsof hosts and
usernames specified in "/etc/netgroup". These are meant toprovide a method of
finetuning access. Read the relevant manual pagefor more information about
netgroups.The exports file also contains information about whether the directoryis
to be exported as read-only, read-write, and whether super-useraccess is to be
allowed from clients which mount that directory.The important point to remember is
that if the access list for aparticular directory in /etc/exports contains:1)
<nothing>Your directory can be mounted by anyone, anywhere.2) <a specific
hostname>Your directory can be mounted by anyone permitted to run the mountcommand
at hostname. This might not be a trustworthy person; forinstance, if the machine
is
a PC running NFS, it could be anyone.3) <a netgroup name>If the netgroup:a) is
empty, anyone can mount your directory, from anywhere.b) contains "(,,)", anyone
can mount your directory, from anywhere.c) contains the name of a netgroup which
is empty or contains "(,,)", anyone can mount your directory, from anywhere.d)
contains "(hostname,,)", anyone on the named host who is permissioned to mount
files can mount your directory.e) contains "(,username,)", the named user can
mount your directory, from anywhere.4) <a word which is neither a hostname or a
netgroup>If you meant to export the directory to the host "athena" but actually
type "ahtena", the word "ahtena" is taken as a netgroup name, is foundto be an
empty netgroup, and thus the directory can be mounted byanyone, anywhere.So, if
you aren't careful about what you put into /etc/exports and/etc/netgroup you could
find that a user with a PC could a) mount your mainframe filestore as a network
disk b) edit your /etc/passwd or .rhosts or /etc/hosts.equiv ... c) log into
your mainframe as another user, possibly "root"Disclaimer: The above information
may not be true for all platformswhich provide an NFS serving capability, but is
true for all of the onesin my experience (AEM). It should be noted that the SAFE
way to createan "empty" netgroup entry is: ngname
(-,-,-)Which is a netgroup which matches no-one on no-host on no-NIS-domain.[ I am
STILL working on PC NFS packages / ethics at the moment - AEM ]Q.16 How can I
generate safe passwords?You can't. The key word here is GENERATE. Once an
algorithm forcreating passwords is specified using upon some systematic method, it
merely becomes a matter of analysing your algorithm in order to findevery password
on your system.Unless the algorithm is very subtle, it will probably suffer from a
verylow period (ie: it will soon start to repeat itself) so that either: a) a
cracker can try out every possible output of the password generator on every user
of the system, or b) the cracker can analyse the output of the password program,
determine the algorithm being used, and apply the algorithm to other users to
determine their passwords.A beautiful example of this (where it was disastrously
assumed that arandom number generator could generate an infinite number of random
passwords) is detailed in [Morris & Thompson].The only way to get a reasonable
amount of variety in your passwords(I'm afraid) is to make them up. Work out some
flexible method of yourown which is NOT based upon: 1) modifying any part of your
name or name+initials 2) modifying a dictionary word 3) acronyms 4) any
systematic, well-adhered-to algorithm whatsoeverFor instance, NEVER use passwords
like:alec7 - it's based on the users name (& it's too short anyway)
tteffum - based on the users name againgillian - girlfiends name
(in a dictionary)naillig - ditto, backwardsPORSCHE911 - it's in a
dictionary12345678 - it's in a dictionary (& people can watch you type it
easily)qwertyui - ...ditto...abcxyz - ...ditto...0ooooooo -
...ditto...Computer - just because it's capitalised doesn't make it safe
wombat6 - ditto for appending some random character6wombat - ditto
for prepending some random charactermerde3 - even for french words...
mr.spock - it's in a sci-fi dictionaryzeolite - it's in a
geological dictionaryze0lite - corrupted version of a word in a geological
dictionaryze0l1te - ...ditto...Z30L1T3 - ...ditto...I hope that
these examples emphasise that ANY password derived from ANYdictionary word (or
personal information), modified in ANY way,constitutes a potentially guessable
password.For more detailed information in the same vein, you should read the
APPENDIX files which accompany Crack [Muffett].Q.17 Why are passwords so
important?Because they are the first line of defence against interactive attackson
your system. It can be stated simply: if a cracker cannot interactwith your
system(s), and he has no access to read or write theinformation contained in the
password file, then he has almost noavenues of attack left open to break your
system.This is also why, if a cracker can at least read your password file (andif
you are on a vanilla modern Unix, you should assume this) it is soimportant that
he is not able to break any of the passwords containedtherein. If he can, then it
is also fair to assume that he can (a) logon to your system and can then (b) break
into "root" via an operatingsystem hole.Q.18 How many possible passwords are
there?Most people ask this at one time or another, worried that programs likeCrack
will eventually grow in power until they can do a completelyexhaustive search of
all possible passwords, to break into a specificusers' account - usually root.If
(to simplify the maths) we make the assumptions that: 1) Valid passwords are
created from a set of 62 chars [A-Za-z0-9] 2) Valid passwords are to be between 5
and 8 chars longThen the size of the set of all valid passwords is: (in base 62)
100000 + 1000000 +
10000000 + 100000000 =
--------- 111100000 (base 62)A figure which
is far too large to usefully undertake an exhaustivesearch with current
technologies. Don't forget, however, that passwordsCAN be made up with even more
characters then this; you can use <space>,all the punctuation characters, and
symbols (~<>|\#$%^&*) too. If youcan use some of all the 95 non-control
characters in passwords, thisincreases the search space for a cracker to cover
even further. However, it's still MUCH more efficient for a cracker to get a copy
of"Crack", break into ANY account on the system (you only need one), logonto the
machine, and spoof his way up to root priviledges via operatingsystems holes. Take
comfort from these figures. If you can slam the door in the faceof a potential
crackers with a robust password file, you have sealedmost of the major avenues of
attack immediately.Q.19 Where can I get more information?Books:[Kochan & Wood]Unix
System SecurityA little dated for modern matters, but still a very good book on
thebasics of Unix security.[Spafford & Garfinkel]Practical Unix SecurityThis
wonderful book is a worthy successor to the above, and covers awide variety of the
topics which the Unix (and some non Unix) systemmanager of the 90's will come
across.>From: Gene Spafford <spaf@cs.purdue.edu>>Mention appendix E in "Practical
Unix Security."Okay: Appendix E contains an extensive bibliography with even more
pointers to security books than this FAQ contains.[Stoll]The Cuckoo's EggA real
life 1980's thriller detailing the tracing of a cracker fromBerkeley across the
USA and over the Atlantic to Germany. An excellentview from all points: a good
read, informative about security, funny,and a good illustration of the cracker
psyche. Contains an excellentrecipie for chocolate chip cookies.A videotape of
the "NOVA" (PBS's Science Program on TV) episode thatexplained/reenacted this
story is available from PBS Home Video. Theyhave a toll-free 800 number within
North America.I believe that this program was aired on the BBC's "HORIZON"
program,and thus will be available from BBC Enterprises, but I haven't checkedthis
out yet - AEM[Raymond] (Ed.)The New Hackers Dictionary/Online Jargon FileA mish-
mash of history and dictionary definitions which explains why itis so wonderful to
be a hacker, and why those crackers who aren'thackers want to be called "hackers".
The Jargon File version isavailable online - check an archie database for retails.
Latestrevision: 2.99.[Gasser]Building a Secure Computer System.By Morrie Gasser,
and van Nostrand Reinhold; explains what is requiredto build a secure computer
system.[Rainbow Series] (Especially the "Orange Book")>From:
epstein@trwacs.fp.trw.com (Jeremy Epstein)>The "Rainbow Series" consists of about
25 volumes. Some of the>more interesting ones are:>> The "Orange Book", or
Trusted Computer Systems Evaluation> Criteria, which describes
functional and assurance> requirements for computer systems>>
Trusted Database Interpretation, which talks both about> trusted
databases and building systems out of trusted> components>>
Trusted Network Interpretation, which (obviously) talks> about
networked systems>>A (possibly) complete list is:> -- Department of Defense
Trusted Computer System Evaluation Criteria> (TCSEC), aka the "Orange
Book"> -- Computer Security Subsystem Interpretation of the TCSEC> --
Trusted Data Base Management System Interpretation of the TCSEC> -- Trusted
Network Interpretation of the TCSEC> -- Trusted Network Interpretation
Environments Guideline -- Guidance> for Applying the Trusted Network
Interpretation> -- Trusted Unix Working Group (TRUSIX) Rationale for
Selecting> Access Control List Features for the Unix System> --
Trusted Product Evaulations -- A Guide for Vendors> -- Computer Security
Requirements -- Guidance for Applying the DoD> TCSEC in Specific
Environments> -- Technical Rationale Behind CSC-STD-003-85: Computer
Security> Requirements> -- Trusted Product Evaluation Questionnaire
> -- Rating Maintenance Phase -- Program Document> -- Guidelines for
Formal Verification Systems>
-- A Guide to Understanding Audit in Trusted Systems> -- A Guide to
Understanding Trusted Facility Management> -- A Guide to Understanding
Discretionary Access Control in Trusted> Systems> -- A Guide to
Understanding Configuration Management in TrustedSystems> -- A Guide to
Understanding Design Documentation in Trusted Systems> -- A Guide to
Understanding Trusted Distribution in Trusted Systems> -- A Guide to
Understanding Data Remanence in Automated Information> Systems> --
Department of Defense Password Management Guideline> -- Glossary of Computer
Security Terms> -- Integrity in Automated Information Systems>>You can get
your own copy (free) of any or all of the books by>writing or calling:>>
INFOSEC Awareness Office> National Computer Security Centre> 9800
Savage Road> Fort George G. Meade, MD 20755-6000> Tel +1 301 766-8729
>>If you ask to be put on the mailing list, you'll get a copy of each new>book as
it comes out (typically a couple a year).>From: kleine@fzi.de (Karl Kleine)>I was
told that this offer is only valid for US citizens ("We only send>this stuff to a
US postal address"). Non-US people have to PAY to get>hold of these documents.
They can be ordered from NTIS, the National>Technical Information Service:>
NTIS,> 5285 Port Royal Rd,> Springfield VA 22151,> USA>
order dept phone: +1-703-487-4650, fax +1-703-321-8547>From: Ulf Kieber
<kieber@de.tu-dresden.inf.freia>>just today I got my set of the Rainbow Series.>
>There are three new books:> -- A Guide to Understanding Trusted Recovery in
Trusted Systems> -- A Guide to Understanding Identification and Authentication in
Trusted> Systems> -- A Guide to Writing the Security Features User's Guide for
Trusted Systems>>They also shipped> -- Advisory Memorandum on Office Automation
Security Guideline>issued by NTISS. Most of the books (except three or four) can
also be>purchased from>> U.S. Government Printing Office>
Superintendent of Documents> Washington, DC 20402 phone: (202)
783-3238>>>-- Integrity in Automated Information Systems>THIS book was NOT shipped
to me--I'm not sure if it is still in>the distribution.>From:
epstein@trwacs.fp.trw.com (Jeremy Epstein)>...>The ITSEC (Information Technology
Security Evaluation Criteria) is a>harmonized document developed by the British,
German, French, and>Netherlands governments. It separates functional and
assurance>requirements, and has many other differences from the TCSEC.>>You can
get your copy (again, free/gratis) by writing:>> Commission of the European
Communities> Directorate XIII/F> SOG-IS Secretariat> Rue de la
Loi 200> B-1049 BRUSSELS> BelgiumAlso note that NCSC periodically
publish an "Evaluated Products List"which is the definitive statement of which
products have been approvedat what TCSEC level under which TCSEC interpretations.
This is usefulfor separating the output of marketdroids from the truth.Papers:
[Morris & Thompson]Password Security, A Case HistoryA wonderful paper, first
published in CACM in 1974, which is now oftento found in the Unix Programmer Docs
supplied with many systems.[Curry]Improving the Security of your Unix System.A
marvellous paper detailing the basic security considerations everyUnix systems
manager should know. Available as "security-doc.tar.Z"from FTP sites (check an
Archie database for your nearest site.)[Klein]Foiling the Cracker: A Survey of,
and Improvements to, Password Security.A thorough and reasoned analysis of
password cracking trends, and thereasoning behind techniques of password cracking.
Your nearest copyshould be easily found via Archie, searching for the keyword
"Foiling".[Cheswick]The Design of a Secure Internet Gateway.Great stuff. It's
research.att.com:/dist/Secure_Internet_Gateway.ps[Cheswick]An Evening With
Berferd: in which a Cracker is Lured, Endured and Studied.Funny and very readable,
somewhat in the style of [Stoll] but morecondensed.
research.att.com:/dist/berferd.ps[Bellovin89]Security Problems in the TCP/TP
Protocol Suite.A description of security problems in many of the protocols widely
usedin the Internet. Not all of the discussed protocols are officialInternet
Protocols (i.e. blessed by the IAB), but all are widely used.The paper originally
appeared in ACM Computer Communications Review,Vol 19, No 2, April 1989.
research.att.com:/dist/ipext.ps.Z[Bellovin91]Limitations of the Kerberos
Authentication SystemA discussion of the limitations and weaknesses of the
KerberosAuthentication System. Specific problems and solutions are presented.Very
worthwhile reading. Available on research.att.com via anonymousftp, originally
appeared in ACM Computer Communications Review but therevised version (identical
to the online version, I think) appeared inthe Winter 1991 USENIX Conference
Proceedings.[Muffett]Crack documentation.The information which accompanies Crack
contains a whimsical explanationof password cracking techniques and the
optimisation thereof, as well asan incredibly long and silly diatribe on how to
not choose a crackablepassword. A good read for anyone who needs convincing that
passwordcracking is _really easy_.[Farmer]COPSRead the documentation provided with
COPS. Lots of hints andphilosophy. The where, why and how behind the piece of
securitysoftware that started it all.[CERT]maillists/advisories/clippingsCERT
maintains archives of useful bits of information that it gets fromUSENET and other
sources. Also archives of all the security"advisories" that it has posted (ie:
little messages warning people thatthere is a hole in their operating system, and
where to get a fix)[OpenSystemsSecurity]A notorious (but apparently quite good)
document, which has been doggedby being in a weird postscript format.>From:
amesml@monu1.cc.monash.edu.au (Mark L. Ames)>I've received many replies to my
posting about Arlo Karila's paper,>including the news (that I and many others have
missed) that a>manageable postscript file and text file are available via
anonymous ftp>from ajk.tele.fi (131.177.5.20) in the directory PublicDocuments.
These are all available for FTP browsing from "cert.sei.cmu.edu".[RFC-1244]Site
Security HandbookRFC-1244 : JP Holbrook & JK Reynolds (Eds.) "The Site Security
Handbook"covering incident handling and prevention. July 1991; 101 pages(Format:
TXT=259129 bytes), also called "FYI 8"[USENET]comp.virus: for discussions of virii
and other nasties, with a PC bent.comp.unix.admin: for general administration
issuescomp.unix.<platform>: for the hardware/software that YOU use.
comp.protocols.tcp-ip: good for problems with NFS, etc.Q.20 How silly can people
get?This section (which I hope to expand) is a forum for learning byexample; if
people have a chance to read about real life (preferablysilly) security incidents,
it will hopefully instill in readers some ofthe zen of computer security without
the pain of experiencing it.If you have an experience that you wish to share,
please send it to theeditors. It'll boost your karma no end.
---------------------------------------------------------------------------
aem@aber.ac.uk: The best story I have is of a student friend of mine(call him Bob)
who spent his industrial year at a major computermanufacturing company. In his
holidays, Bob would come back to collegeand play AberMUD on my system.Part of
Bob's job at the company involved systems management, and thecompany was very hot
on security, so all the passwords were randomstrings of letters, with no sensible
order. It was imperative that thepasswords were secure (this involved writing the
random passwords downand locking them in big, heavy duty safes).One day, on a
whim, I fed the MUD persona file passwords into Crack as adictionary (the
passwords were stored plaintext) and then ran Crack onour systems password file.
A few student accounts came up, but nothingspecial. I told the students concerned
to change their passwords - thatwas the end of it.Being the lazy guy I am, I
forgot to remove the passwords from the Crackdictionary, and when I posted the
next version to USENET, the words wenttoo. It went to the comp.sources.misc
moderator, came back over USENET,and eventually wound up at Bob's company. Round
trip: ~10,000 miles.Being a cool kinda student sysadmin dude, Bob ran the new
version ofCrack when it arrived. When it immediately churned out the rootpassword
on his machine, he damn near fainted...The moral of this story is: never use the
same password in two differentplaces, and especially on untrusted systems (like
MUDs).-- aem@aber.ac.uk aem@uk.ac.aber aem%aber@ukacrl.bitnet mcsun!uknet!aber!aem
- send (cryptographic) comp.sources.misc material to: aem@aber.ac.uk -