home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / answers / security-faq < prev    next >
Text File  |  1993-12-02  |  78KB  |  1,770 lines

  1. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!spool.mu.edu!agate!ames!koriel!newscast.West.Sun.COM!seven-up.East.Sun.COM!uk-usenet.uk.sun.com!news
  2. From: Alec.Muffett@UK.Sun.COM
  3. Newsgroups: alt.security,comp.security.misc,comp.security.unix,news.answers
  4. Subject: FAQ: Computer Security Frequently Asked Questions
  5. Followup-To: poster
  6. Date: 3 Dec 1993 10:40:34 GMT
  7. Organization: Sun Microsystems, UK
  8. Lines: 1754
  9. Approved: news-answers-request@MIT.Edu
  10. Message-ID: <2dn532$3c1@uk-usenet.uk.sun.com>
  11. NNTP-Posting-Host: uk-usenet.uk.sun.com
  12. Summary: Answers to questions which appear in comp.security.misc
  13. Keywords: Security FAQ
  14. Xref: senator-bedfellow.mit.edu alt.security:13328 comp.security.misc:6574 comp.security.unix:1420 news.answers:15428
  15.  
  16. Archive-name: security-faq
  17. Last-modified: 1993/12/3
  18. Version: 2.2
  19.  
  20.  
  21. Version History:
  22.  
  23. 2.2    LD_LIBRARY_PRELOAD comment
  24. 2.1    New story, TAMU package info
  25. 2.0    MERGE IN LOTS OF NEW INFORMATION
  26. 1.6    Minor revisions, meant to bring it a bit more up to date.
  27. 1.5    Structural revision.
  28. 1.4    Fixed John Haugh's name, modified entry for "shadow"
  29.     Added Ulf Kieber's update on the rainbow series
  30.     Added bit about Karila paper
  31. 1.3:    Tweak for comp.security.misc/news.answers
  32.     Updated entry for orange book (foreign purchases)
  33. 1.2:    Undocumented prior to this
  34. ---------------------------------------------------------------------------
  35.  
  36.     Almost Everything You Ever Wanted To Know About Security*
  37.                *(but were afraid to ask!)
  38.  
  39. This document is meant to answer some of the questions which regularly
  40. appear in the Usenet newsgroups "comp.security.misc", "comp.security.unix", 
  41. and "alt.security", and is meant to provide some background to the
  42. subject for newcomers to that newsgroup. 
  43.  
  44. This FAQ is maintained by Alec Muffett (Alec.Muffett@UK.Sun.COM), with
  45. contributions from numerous others; the views expressed in the document
  46. are the personal views of the author(s), and it should not be inferred
  47. that they are necessarily shared by anyone with whom the author(s) are
  48. now, or ever may be, associated.
  49.  
  50. Many thanks go to (in no particular order): Steve Bellovin, Matt Bishop,
  51. Mark Brader, Ed DeHart, Dave Hayes, Jeffrey Hutzelman, William LeFebvre,
  52. Wes Morgan, Rob Quinn, Chip Rosenthal, Wietse Venema, Gene Spafford,
  53. John Wack and Randall Atkinson.
  54.  
  55. Disclaimer: Every attempt is made to ensure that the information
  56. contained in this FAQ is up to date and accurate, but no responsibility
  57. will be accepted for actions resulting from information gained herein.
  58.  
  59. Questions which this document addresses:
  60.  
  61. Q.1 What are alt.security and comp.security.misc for?
  62. Q.2 Whats the difference between a hacker and a cracker?
  63. Q.3 What is "security through obscurity"
  64. Q.4 What makes a system insecure?
  65. Q.5 What tools are there to aid security?
  66. Q.6 Where can I get these tools?
  67. Q.7 Isn't it dangerous to give cracking tools to everyone?
  68. Q.8 Why and how do systems get broken into?
  69. Q.9 Who can I contact if I get broken into?
  70. Q.10 What is a firewall?
  71. Q.11 Why shouldn't I use setuid shell scripts?
  72. Q.12 Why shouldn't I leave "root" permanently logged on the console?
  73. Q.13 Why shouldn't I create Unix accounts with null passwords?
  74. Q.14 What security holes are associated with X-windows (and other WMs)?
  75. Q.15 What security holes are associated with NFS?
  76. Q.16 How can I generate safe passwords?
  77. Q.17 Why are passwords so important?
  78. Q.18 How many possible passwords are there?
  79. Q.19 Where can I get more information?
  80. Q.20 How silly can people get?
  81. ---------------------------------------------------------------------------
  82.  
  83. Q.1 What are alt.security and comp.security.misc for?
  84.  
  85. Comp.security.misc is a forum for the discussion of computer security,
  86. especially those relating to Unix (and Unix like) operating systems.
  87. Alt.security used to be the main newsgroup covering this topic, as well
  88. as other issues such as car locks and alarm systems, but with the
  89. creation of comp.security.misc, this may change.
  90.  
  91. This FAQ will concentrate wholly upon computer related security issues.
  92.  
  93. The discussions posted range from the likes of "What's such-and-such
  94. system like?" and "What is the best software I can use to do so-and-so"
  95. to "How shall we fix this particular bug?", although there is often a
  96. low signal to noise ratio in the newsgroup (a problem which this FAQ
  97. hopes to address).
  98.  
  99. The most common flamewars start when an apparent security novice posts a
  100. message saying "Can someone explain how the such-and-such security hole
  101. works?" and s/he is immediately leapt upon by a group of self appointed
  102. people who crucify the person for asking such an "unsound" question in a
  103. public place, and flame him/her for "obviously" being a cr/hacker.
  104.  
  105. Please remember that grilling someone over a high flame on the grounds
  106. that they are "a possible cr/hacker" does nothing more than generate a
  107. lot of bad feeling.  If computer security issues are to be dealt with in
  108. an effective manner, the campaigns must be brought (to a large extent)
  109. into the open.
  110.  
  111. Implementing computer security can turn ordinary people into rampaging
  112. paranoiacs, unable to act reasonably when faced with a new situation.
  113. Such people take an adversarial attitude to the rest of the human race,
  114. and if someone like this is in charge of a system, users will rapidly
  115. find their machine becoming more restrictive and less friendly (fun?) to
  116. use.
  117.  
  118. This can lead to embarrasing situations, eg: (in one university) banning
  119. a head of department from the college mainframe for using a network
  120. utility that he wasn't expected to.  This apparently required a lot of
  121. explaining to an unsympathetic committee to get sorted out.
  122.  
  123. A more sensible approach is to secure a system according to its needs,
  124. and if its needs are great enough, isolate it completely.  Please, don't
  125. lose your sanity to the cause of computer security; it's not worth it.
  126.  
  127.         usenet/comp.sources.misc/volume29
  128.         usenet/comp.sources.misc/volume30
  129.         usenet/comp.sources.misc/volume32
  130. ------------------------------------------------------------------
  131.  
  132. Q.2 What's the difference between a hacker and a cracker?
  133.  
  134. Lets get this question out of the way right now:
  135.  
  136. On USENET, calling someone a "cracker" is an unambiguous statement that
  137. some person persistently gets his/her kicks from breaking from into
  138. other peoples computer systems, for a variety of reasons.  S/He may pose
  139. some weak justification for doing this, usually along the lines of
  140. "because it's possible", but most probably does it for the "buzz" of
  141. doing something which is illicit/illegal, and to gain status amongst a
  142. peer group.
  143.  
  144. Particularly antisocial crackers have a vandalistic streak, and delete
  145. filestores, crash machines, and trash running processes in pursuit of
  146. their "kicks".
  147.  
  148. The term is also widely used to describe a person who breaks copy
  149. protection software in microcomputer applications software in order to
  150. keep or distribute free copies.
  151.  
  152. On USENET, calling someone a "hacker" is usually a statement that said
  153. person holds a great deal of knowledge and expertise in the field of
  154. computing, and is someone who is capable of exercising this expertise
  155. with great finesse.  For a more detailed definition, readers are
  156. referred to the Jargon File [Raymond].
  157.  
  158. In the "real world", various media people have taken the word "hacker"
  159. and coerced it into meaning the same as "cracker" - this usage
  160. occasionally appears on USENET, with disastrous and confusing results.
  161.  
  162. Posters to the security newsgroups should note that they currently risk
  163. a great deal of flamage if they use the word "hacker" in place of
  164. "cracker" in their articles.
  165.  
  166. NB: nowhere in the above do I say that crackers cannot be true hackers.
  167. It's just that I don't say that they are...
  168. ------------------------------------------------------------------
  169.  
  170. Q.3 What is "security through obscurity"
  171.  
  172. Security Through Obscurity (STO) is the belief that any system can be
  173. secure so long as nobody outside of its implementation group is allowed
  174. to find out anything about its internal mechanisms.  Hiding account
  175. passwords in binary files or scripts with the presumption that "nobody
  176. will ever find it" is a prime case of STO.
  177.  
  178. STO is a philosophy favoured by many bureaucratic agencies, and it used
  179. to be a major method of providing "pseudosecurity" in computing systems.
  180.  
  181. Its usefulness has declined in the computing world with the rise of open
  182. systems, networking, greater understanding of programming techniques, as
  183. well as the increase in computing power available to the average person.
  184.  
  185. The basis of STO has always been to run your system on a "need to know"
  186. basis.  If a person doesn't know how to do something which could impact
  187. system security, then s/he isn't dangerous.
  188.  
  189. Admittedly, this is sound in theory, but it can tie you into trusting a
  190. small group of people for as long as they live.  If your employees get
  191. an offer of better pay from somewhere else, the knowledge goes with
  192. them, whether the knowledge is replaceable or not.  Once the secret gets
  193. out, that is the end of your security.
  194.  
  195. Nowadays there is also a greater need for the ordinary user to know
  196. details of how your system works than ever before, and STO falls down a
  197. as a result.  Many users today have advanced knowledge of how their
  198. operating system works, and because of their experience will be able to
  199. guess at the bits of knowledge that they didn't "need to know".  This
  200. bypasses the whole basis of STO, and makes your security useless.
  201.  
  202. Hence there is now a need is to to create systems which attempt to be
  203. algorithmically secure (Kerberos, Secure RPC), rather than just
  204. philosophically secure.  So long as your starting criteria can be met,
  205. your system is LOGICALLY secure.
  206.  
  207. Incidentally, "Shadow Passwords" (below) are sometimes dismissed as STO,
  208. but this is incorrect, since (strictly) STO depends on restricting
  209. access to an algorithm or technique, whereas shadow passwords provide
  210. security by restricting access to vital data.
  211. ------------------------------------------------------------------
  212.  
  213. Q.4 What makes a system insecure?
  214.  
  215. Switching it on.  The adage usually quoted runs along these lines:
  216.  
  217.  "The only system which is truly secure is one which is switched off
  218.  and unplugged, locked in a titanium lined safe, buried in a concrete
  219.  bunker, and is surrounded by nerve gas and very highly paid armed
  220.  guards.  Even then, I wouldn't stake my life on it."
  221.  
  222. (the original version of this is attributed to Gene Spafford)
  223.  
  224. A system is only as secure as the people who can get at it.  It can be
  225. "totally" secure without any protection at all, so long as its continued
  226. good operation is important to everyone who can get at it, assuming all
  227. those people are responsible, and regular backups are made in case of
  228. hardware problems.  Many laboratory PC's quite merrily tick away the
  229. hours like this.
  230.  
  231. The problems arise when a need (such as confidentiality) has to be
  232. fulfilled.  Once you start putting the locks on a system, it is fairly
  233. likely that you will never stop.
  234.  
  235. Security holes manifest themselves in (broadly) four ways:
  236.  
  237. 1) Physical Security Holes.
  238.  
  239. - Where the potential problem is caused by giving unauthorised persons
  240. physical access to the machine, where this might allow them to perform
  241. things that they shouldn't be able to do.
  242.  
  243. A good example of this would be a public workstation room where it would
  244. be trivial for a user to reboot a machine into single-user mode and muck
  245. around with the workstation filestore, if precautions are not taken.
  246.  
  247. Another example of this is the need to restrict access to confidential
  248. backup tapes, which may (otherwise) be read by any user with access to
  249. the tapes and a tape drive, whether they are meant to have permission or
  250. not.
  251.  
  252. 2) Software Security Holes
  253.  
  254. - Where the problem is caused by badly written items of "privledged"
  255. software (daemons, cronjobs) which can be compromised into doing things
  256. which they shouldn't oughta.
  257.  
  258. The most famous example of this is the "sendmail debug" hole (see
  259. bibliography) which would enable a cracker to bootstrap a "root" shell.
  260. This could be used to delete your filestore, create a new account, copy
  261. your password file, anything.
  262.  
  263. (Contrary to popular opinion, crack attacks via sendmail were not just
  264. restricted to the infamous "Internet Worm" - any cracker could do this
  265. by using "telnet" to port 25 on the target machine.  The story behind a
  266. similar hole (this time in the EMACS "move-mail" software) is described
  267. in [Stoll].)
  268.  
  269. New holes like this appear all the time, and your best hopes are to:
  270.  
  271.   a: try to structure your system so that as little software as possible
  272.   runs with root/daemon/bin privileges, and that which does is known to
  273.   be robust.
  274.  
  275.   b: subscribe to a mailing list which can get details of problems
  276.   and/or fixes out to you as quickly as possible, and then ACT when you
  277.   receive information.
  278.  
  279. >From: Wes Morgan <morgan@edu.uky.ms>
  280. >
  281. > c: When installing/upgrading a given system, try to install/enable only
  282. > those software packages for which you have an immediate or foreseeable
  283. > need.  Many packages include daemons or utilities which can reveal
  284. > information to outsiders.  For instance, AT&T System V Unix' accounting
  285. > package includes acctcom(1), which will (by default) allow any user to
  286. > review the daily accounting data for any other user.  Many TCP/IP packa-
  287. > ges automatically install/run programs such as rwhod, fingerd, and
  288. > <occasionally> tftpd, all of which can present security problems.
  289. >
  290. > Careful system administration is the solution.  Most of these programs
  291. > are initialized/started at boot time; you may wish to modify your boot
  292. > scripts (usually in the /etc, /etc/rc, /etc/rcX.d directories) to pre-
  293. > vent their execution.  You may wish to remove some utilities completely.
  294. > For some utilities, a simple chmod(1) can prevent access from unauthorized
  295. > users.
  296. >
  297. > In summary, DON'T TRUST INSTALLATION SCRIPTS/PROGRAMS!  Such facilities
  298. > tend to install/run everything in the package without asking you.  Most
  299. > installation documentation includes lists of "the programs included in
  300. > this package"; be sure to review it.
  301.  
  302. 3) Incompatible Usage Security Holes
  303.  
  304. - Where, through lack of experience, or no fault of his/her own, the
  305. System Manager assembles a combination of hardware and software which
  306. when used as a system is seriously flawed from a security point of view.
  307. It is the incompatibility of trying to do two unconnected but useful
  308. things which creates the security hole.
  309.  
  310. Problems like this are a pain to find once a system is set up and
  311. running, so it is better to build your system with them in mind.  It's
  312. never too late to have a rethink, though.
  313.  
  314. Some examples are detailed below; let's not go into them here, it would
  315. only spoil the surprise.
  316.  
  317. 4) Choosing a suitable security philosophy and maintaining it.
  318.  
  319. >From: Gene Spafford <spaf@cs.purdue.edu>
  320. >The fourth kind of security problem is one of perception and
  321. >understanding.  Perfect software, protected hardware, and compatible
  322. >components don't work unless you have selected an appropriate security
  323. >policy and turned on the parts of your system that enforce it.  Having
  324. >the best password mechanism in the world is worthless if your users
  325. >think that their login name backwards is a good password! Security is
  326. >relative to a policy (or set of policies) and the operation of a system
  327. >in conformance with that policy.
  328. ------------------------------------------------------------------
  329.  
  330. Q.5 What tools are there to aid security
  331. Q.6 ...and... where can I get these tools?
  332.  
  333. ==================================================================
  334. *** This is a section which has changed very rapidly over the past
  335. *** few months; hence I am changing the format ever so slightly, in
  336. *** order to allow for expansion - Alec
  337. ==================================================================
  338.  
  339. COPS            Dan Farmer, et al.
  340.  
  341. Managed/largely written by Dan Farmer, COPS is a suite of shell scripts
  342. which forms an extensive security testing system; there's a rudimentary
  343. password cracker, and routines to check the filestore for suspicious
  344. changes in setuid programs, others to check permissions of essential
  345. system and user files, and still more to see whether any system software
  346. behaves in a way which could cause problems.
  347.  
  348. The software comes in two versions - one written in Perl and one
  349. (largely equivalent) written in shell scripts.  The latest version is
  350. very up-to-date on Unix Security holes.
  351.  
  352. COPS V1.04 is available for FTP from cert.org in pub/cops and
  353. archive.cis.ohio-state.edu in pub/cops.
  354. ------------------------------------------------------------------
  355. Crack            Alec Muffett
  356. UFC            Michael Glad
  357.  
  358. Crack is a program written with one purpose in mind: to break insecure
  359. passwords.  It is probably the most efficent and friendly password
  360. cracker that is publically available, with the ability to let the user
  361. to specify precisely how to form the words to use as guesses at users
  362. passwords.
  363.  
  364. It also has an inbuilt networking capability, allowing the load of
  365. cracking to be spread over as many machines as are available on a
  366. network, and it is supplied with an optimised version of the Unix crypt()
  367. algorithm.
  368.  
  369. An even faster version of the crypt() algorithm, "UFC" by Michael Glad,
  370. is freely available on the network, and the latest versions of UFC and
  371. Crack are compatible and can be easily hooked together.
  372.  
  373. Crack v4.1f and UFC are available from:  ftp.uu.net (137.39.1.9)
  374.  
  375. In the directory:       /usenet/comp.sources.misc/volume28
  376. As:                     crack/part01.Z to part05.Z      ( 5 files )
  377. And                     ufc-crypt/part01.Z & part02.Z   ( 2 files )
  378.  
  379. NB: For people with access to a Connection Machine:
  380.  
  381. >From: glad@daimi.aau.dk (Michael Glad)
  382. >
  383. >A UNIX password cracker for the Thinking Machine CM/2 and CM/200
  384. >Connection Machines is available for FTP from
  385. >
  386. >    ftp.denet.dk:/pub/misc/cm200-UFC.tar.Z
  387. >
  388. > This is a password cracker for the Thinking Machines CM/2 and CM/200
  389. > Connection Machines. It features
  390. >
  391. >     o A standalone dictionary preprocessor accepting a
  392. >      language of rewrite rules compatible with the one
  393. >      found in Alec Muffets 'Crack' password cracker as of
  394. >         release 4.1f.
  395. >
  396. >    o An optimized port of the UFC-crypt: a fast implementation
  397. >      of the UNIX crypt(3) function developed by Michael Glad and
  398. >      donated to the Free Software Foundation (FSF).
  399. >
  400. >    o The password cracker itself. It supports restart of crashed
  401. >      runs and incremental use. Incremental use means that when
  402. >      you use a fixed dictionary, the cracker can maintain a status
  403. >      file of already cracked passwords and passwords considered
  404. >      uncrackable (because they've been tested in previous runs).
  405. >      Thus it only has to waste CPU cycles on new accounts and accounts
  406. >      with changed passwords.
  407. >
  408. >    o When run with a _large_ dictionary (a 1 million word dictionary
  409. >      obtained by preprocessing /usr/dict/words), the cracker can
  410. >      test in excess of 50,000 passwords a second on a CM/200 with
  411. >      8192 processors.
  412. ------------------------------------------------------------------
  413. CrackLib        Alec Muffett
  414.  
  415. Cracklib is a C LIBRARY containing a routine which may be wired into all
  416. sorts of "passwd"-like programs; not just Unix, but with a little effort
  417. it could probably go onto VMS (this is being worked upon), or many other
  418. systems.
  419.  
  420. Using "CrackLib" allows you to wire proactive password checking into
  421. _any_ of your applications; it is an offshoot of the the version 5
  422. "Crack" software, and contains a considerable number of ideas nicked
  423. from the new software.
  424.  
  425. CrackLib was posted to "comp.sources.misc", and therefore available from
  426. any major usenet archive.  A reference copy (+ large dictionary) can be
  427. FTP'ed from:
  428.  
  429.      black.ox.ac.uk:~ftp/src/security/cracklib25.tar.Z
  430.  
  431. NB: if you search for CrackLib on "Archie", care should be taken to get
  432. the package from a comp.sources.misc archive; beware confusing it with a
  433. package of the same name, which was hacked into "npasswd".
  434. ------------------------------------------------------------------
  435. NPasswd            Clyde Hoover
  436. Passwd+            Matt Bishop
  437. Shadow            John F. Haugh II
  438.  
  439. Passwd+ & NPasswd: these programs are written to redress the balance in
  440. the password cracking war.  They provide replacements for the standard
  441. "passwd" command, but prevent a user from selecting passwords which are
  442. easily compromised by programs like Crack.
  443.  
  444. The usual term for this type of program is a 'fascist' password program.
  445.  
  446. NPasswd: Currently suffering from being hacked about by many different
  447. people, in order to provide compatibility for System V based systems,
  448. NIS/YP, shadow password schemes, etc.  Version 2.0 is in the offing, but
  449. many versions exist in many different configurations.
  450.  
  451. Passwd+: "alpha version, update 3" - beta version due soon.  Available
  452. from dartmouth.edu as pub/passwd+.tar.Z
  453.  
  454. Shadow: is a set of program and function replacements (compatible with
  455. most Unixes) which implements shadow passwords, ie: a system where the
  456. plaintext of the password file is hidden from all users except root,
  457. hopefully stopping all password cracking attempts at source.  In
  458. combination with a fascist passwd frontend, it should provide a good
  459. degree of password file robustness.
  460.  
  461. >From: jfh@rpp386.cactus.org (John F. Haugh II)
  462. >Shadow does much more than hide passwords.  It also provides for
  463. >terminal access control, user and group administration, and a few
  464. >other things which I've forgotten.  There are a dozen or more
  465. >commands in the suite, plus a whole slew of library functions.
  466.  
  467. Shadow is available from the comp.sources.misc directory at any major
  468. USENET archive - relevant files are in:
  469.  
  470.         usenet/comp.sources.misc/volume38
  471.         usenet/comp.sources.misc/volume39
  472.  
  473. - the contents of both of which are needed, for a full set of patches.
  474.  
  475. Given that the latest release of Shadow has a hook for "CrackLib"
  476. support, it now ranks as a full blown fascist password program, on top
  477. of its other functionality.
  478.  
  479. CrackLib support is expected in Passwd+, in the near future.
  480. ------------------------------------------------------------------
  481. TCP Wrappers        Wietse Venema
  482.  
  483. These are programs which provide front-end filters to MOST of the
  484. network services which Unix provides by default.
  485.  
  486. If installed, they can curb otherwise unrestricted access to potential
  487. dangers like incoming FTP/TFTP, Telnet, etc, and can provide extra
  488. logging information, which may be of use if it appears that someone is
  489. trying to break in.
  490.  
  491. From the BLURB
  492.  
  493. >With these programs you can monitor and control who connects to your
  494. >TFTP, EXEC, FTP, RSH, TELNET, RLOGIN, FINGER, and SYSTAT network
  495. >services, and many others.
  496. >
  497. >The programs can be installed without any changes to existing software
  498. >or configuration files. By default, they just log the remote host name
  499. >and do some sanity checks on the origin of the request. No information
  500. >is exchanged with the remote client process.
  501. >
  502. >Significant differences with respect to the previous release:
  503. >
  504. >    - Easier to install: ready-to-use build procedures for many common
  505. >      UNIX implementations (sun, ultrix, hp-ux, irix, aix, ...).
  506. >
  507. >    - Support for the System V.4 TLI network programming interface
  508. >      (Solaris, DG/UX etc.).  In case of TLI applications on top of
  509. >      TCP/IP, the wrappers provide the same functionality as with
  510. >      socket-based applications.
  511. >
  512. >    - A more secure finger tool for automatic reverse finger probes.
  513. >
  514. >    - New extension language keywords:  "severity", to adjust the log
  515. >      noise level; "allow" and "deny", to keep all access-control rules
  516. >      within a single file.
  517. >
  518. >    - More support for selective remote username lookups.
  519. >
  520. >    - More workarounds for System V bugs: IRIX username lookups, and
  521. >      SCO problems with UDP.
  522. >
  523. >      The default mode of operation (no TLI support) should be backwards
  524. >      compatible with earlier versions. The library interface has changed,
  525. >      though, and programs that depend on the libwrap.a library will have to
  526. >      be recompiled before they can be relinked.
  527. >
  528. >      Wietse Venema (wietse@wzv.win.tue.nl)
  529.  
  530. TCP Wrappers are available for anonymous FTP from:
  531.  
  532.         cert.org:pub/tools/tcp_wrappers
  533. ------------------------------------------------------------------
  534. SecureLib        William LeFebvre
  535.  
  536. >From: phil@pex.eecs.nwu.edu
  537. >You may want to add a mention of securelib, a security enhancer
  538. >available for SunOS version 4.1 and higher.
  539.  
  540. >Securelib contains replacement routines for three kernel calls:
  541. >accept(), recvfrom(), recvmsg().  These replacements are compatible with
  542. >the originals, with the additional functionality that they check the
  543. >Internet address of the machine initiating the connection to make sure
  544. >that it is "allowed" to connect.  A configuration file defines what
  545. >hosts are allowed for a given program.  Once these replacement routines
  546. >are compiled, they can be used when building a new shared libc library.
  547. >The resulting libc.so can then be put in a special place.  Any program
  548. >that should be protected can then be started with an alternate
  549. >LD_LIBRARY_PATH.
  550.  
  551. The latest version of securelib is available via anonymous FTP from the
  552. host "eecs.nwu.edu".  It is stored in the file "pub/securelib.tar".
  553. ------------------------------------------------------------------
  554. ISS            Chris Klaus
  555. YPX            Rob Nauta
  556.  
  557. >Internet Security Scanner (ISS) is one of the first multi-level security
  558. >scanners available to the public.  It was designed to be flexible and
  559. >easily portable to many unix platforms and do its job in a reasonable
  560. >amount of time.  It provides information to the administrator that will
  561. >fix obvious security misconfigurations.
  562. >
  563. >ISS does a multi-level scan of security, not just searching for one
  564. >weakness in the system.  To provide this to the public or at least to
  565. >the security conscious crowd may cause people to think that it is too
  566. >dangerous for the public, but many of the (cr/h)ackers are already aware
  567. >of these security holes and know how to exploit them.
  568. >
  569. >These security holes are not deep in some OS routines, but standard
  570. >misconfigurations that many domains on Internet tend to show.  Many of
  571. >these holes are warned about in CERT and CIAC advisories.  This is the
  572. >first release of ISS and there is still much room for improvement.
  573.  
  574. [...A simplistic description of ISS might be that it is to the Unix
  575. Network Services, what COPS is to the Unix filesystem; ie: a tool to
  576. allow a systems administrator to find potential holes, giving him/her a
  577. chance to solve the problem BEFORE a cracker attack an occur.
  578.  
  579. ISS and an auxilliary program, YPX, have been recently posted to
  580. comp.sources.misc.  Because ISS is in a early stage of development,
  581. check an "Archie" site for the most up-to-date information...Alec]
  582. ------------------------------------------------------------------
  583. TripWire        Gene Kim, Gene Spafford
  584.  
  585. [From the Announce file]
  586.  
  587. >Tripwire is an integrity-monitor for Unix systems.  It uses several
  588. >checksum/signature routines to detect changes to files, as well as
  589. >monitoring selected items of system-maintained information.  The system
  590. >also monitors for changes in permissions, links, and sizes of files and
  591. >directories.  It can be made to detect additions or deletions of files
  592. >from watched directories.
  593. >
  594. >The configuration of Tripwire is such that the system/security
  595. >administrator can easily specify files and directories to be monitored
  596. >or to be excluded from monitoring, and to specify files which are
  597. >allowed limited changes without generating a warning.  Tripwire can also
  598. >be configured with customized signature routines for site-specific
  599. >checks.
  600. >
  601. >Tripwire, once installed on a clean system, can detect changes from
  602. >intruder activity, unauthorized modification of files to introduce
  603. >backdoor or logic-bomb code, (if any were to exist) virus activity in
  604. >the Unix environment.
  605. >
  606. >Tripwire is provided as source code with documentation.  The system, as
  607. >delivered, performs no changes to system files and does not require root
  608. >privilege to run (in the general case).  The code has been beta-tested
  609. >in a form close to that of this release at over 100 sites world-wide.
  610. >Tripwire should work on almost any version of Unix, from Xenix on
  611. >80386-based machines to Cray and ETA-10 supercomputers.
  612. >
  613. >Tripwire may be used without charge, but it may not be sold or modified
  614. >for sale.  Tripwire was written as a project under the auspices of the
  615. >COAST Project at Purdue University.  The primary author was Gene Kim,
  616. >with the aid and under the direction of Gene Spafford (COAST director).
  617. >
  618. >Copies of the Tripwire distribution may be ftp'd from ftp.cs.purdue.edu
  619. >from the directory pub/spaf/COAST/Tripwire.  The distribution is
  620. >available as a compressed tar file, and as uncompressed shar kits.  The
  621. >shar kit form of Tripwire version 1.0 will also be posted to
  622. >comp.sources.unix on the Usenet.
  623. >
  624. >A mailserver exists for distribution and to support a Tripwire mailing
  625. >list.  To use the mail server, send e-mail to
  626. >"tripwire-request@cs.purdue.edu" with a message body consisting solely
  627. >of the word "help".  The server will respond with instructions on how to
  628. >get source, patches, and how to join the mailing list.
  629. >
  630. >Questions, comments, complaints, bugfixes, etc may be directed to:
  631. >genek@mentor.cc.purdue.edu (Gene Kim)
  632. >spaf@cs.purdue.edu (Gene Spafford)
  633. ------------------------------------------------------------------
  634. TAMU             Dave Safford, Doug Schales, Dave Hess
  635.  
  636. From the ANNOUNCE file:
  637.  
  638. >              Texas A&M Network Security Package Update
  639. >                              7/1/93
  640. >
  641. >                       Dave Safford
  642. >                       Doug Schales
  643. >                        Dave Hess
  644. >
  645. >This is an updated release of the security tools developed at the
  646. >Texas A&M University Supercomputer Center.  These tools are available
  647. >for anonymous FTP from net.tamu.edu:/pub/security/TAMU.
  648. [...]
  649. >ORIGINAL DESCRIPTION:
  650. >
  651. >Last August, Texas A&M University UNIX computers came under extensive
  652. >attack from a coordinated group of internet crackers.  This package of
  653. >security tools represents the results of over nine months of
  654. >development and testing of the software we have been using to protect
  655. >our estimated five thousand IP devices.  This package includes three
  656. >coordinated sets of tools: "drawbridge", an exceptionally powerful
  657. >bridging filter package; "tiger", a set of convenient yet thorough
  658. >machine checking programs; and "netlog", a set of intrusion detection
  659. >network monitoring programs.
  660. >
  661. >KEY FEATURES:
  662. >
  663. >For full technical details on the products, see their individual README's,
  664. >but here are some highlights:
  665. >
  666. >    DRAWBRIDGE:
  667. >        - inexpensive (PC with two SMC/WD 8013 cards)
  668. >        - high level filter language and compiler
  669. >        - powerful filtering parameters
  670. >        - DES authenticated remote filter management
  671. >        - O(1) table lookup processing even with dense class B
  672. >            net filter specifications.    
  673. >
  674. >    TIGER:
  675. >        - checks key binaries against cryptographic
  676. >          checksums from original distribution files
  677. >        - checks for critical security patches
  678. >        - checks for known intrusion signatures
  679. >        - checks all critical configuration files
  680. >        - will run on most UNIX systems, and has tailored
  681. >          components for SunOS, Next, SVR4, Unicos.
  682. >
  683. >    NETLOG:
  684. >        - efficiently logs all tcp/udp establishment attempts
  685. >        - powerful query tool for analyzing connection logs
  686. >        - "intelligent" intrusion detection program
  687. >
  688. >AVAILABILITY:
  689. >
  690. >This package is available via anonymous ftp in 
  691. >
  692. >    net.tamu.edu: pub/security/TAMU
  693. >
  694. >Due to the sensitive nature of these tools, we recommend that you
  695. >retrieve them from this location. If you do not get them from
  696. >net.tamu.edu we suggest that you use our check_TAMU script that uses
  697. >cryptographic checksums to check the distribution for any signs of
  698. >tampering. The script is available in the anonymous ftp directory above
  699. >and from an e-mail server at:
  700. >
  701. >    drawbridge-server@net.tamu.edu
  702. >
  703. >Note that there are some distribution limitations, such as the
  704. >inability to export outside the US the DES libraries used in
  705. >drawbridge; see the respective tool README's for details of any
  706. >restrictions. (Note that the DES libraries are NOT required to use
  707. >drawbridge. They just enable secure remote management of drawbridge.)
  708. >
  709. >CONTACT:
  710. >
  711. >Comments and questions are most welcome. Please address them to:
  712. >
  713. >    drawbridge@net.tamu.edu
  714.  
  715. [A wonderful paper about TAMU was presented at the 4th USENIX Security
  716. Symposium, and is reprinted in the proceedings of the same - Alec]
  717. ------------------------------------------------------------------
  718. SPI
  719.  
  720. >From: Gene Spafford <spaf@cs.purdue.edu>
  721. >Sites connected with the Department of Energy and some military
  722. >organizations may also have access to the SPI package.  Interested (and
  723. >qualified) users should contact the CIAC at LLNL for details.
  724.  
  725. >SPI is a screen-based administrator's tool that checks configuration
  726. >options, includes a file-change (integrity) checker to monitor for
  727. >backdoors and viruses, and various other security checks.  Future
  728. >versions will probably integrate COPS into the package.  It is not
  729. >available to the general public, but it is available to US Dept of
  730. >Energy contractors and sites and to some US military sites.  A version
  731. >does or will exist for VMS, too.  Further information on availabilty can
  732. >be had from the folks at the DoE CIAC.
  733.  
  734. [...A paper on SPI was recently presented at the 1993 USENIX Security
  735. symposium; apparently v2.1 has appeared on an anonymous FTP site
  736. recently, but whether this is in accordance with licencing agreements is
  737. unknown to the author of this FAQ, and anyway, he's forgotten what the
  738. IP address was, so...]
  739. ------------------------------------------------------------------
  740. TIS Firewall Toolkit    Trusted Information Systems, Inc.
  741.  
  742. >From: mjr@tis.com (Marcus J. Ranum)
  743. >
  744. >Version 1.0 of the TIS network firewall toolkit is now available for
  745. >anonymous FTP from ftp.tis.com, in directory pub/firewalls/toolkit
  746. >
  747. >WHAT IS THE TIS FIREWALL TOOLKIT?
  748. >---------------------------------
  749. >Trusted Information Systems, Inc.  (TIS) is pleased to provide the TIS
  750. >Firewall Toolkit, a software kit for building and maintaining
  751. >internetwork Firewalls.  It is distributed in source code form, with all
  752. >modules written in the C programming language and runs on many BSD UNIX
  753. >derived platforms.  The Toolkit is being made available for use as
  754. >specified in the license agreement (LICENSE).
  755. >
  756. >The firewall toolkit is a set of programs, configuration practices, and
  757. >documentation intended to help individuals who are trying to build
  758. >internet firewalls.  Included with the kit are complete sources for FTP,
  759. >rlogin, and telnet application proxies, user authentication management,
  760. >compartmented SMTP, and logging/log reduction.
  761. >
  762. >USERS' GROUP
  763. >------------
  764. >TIS maintains the electronic-mail users' group <fwall-users@tis.com> for
  765. >discussion of the toolkit.  To join, send electronic mail to
  766. ><fwall-users-request@tis.com>.
  767. >
  768. >TIS Firewall Toolkit technical questions, license issues, bug reports,
  769. >etc.  should be addressed to <fwall-support@tis.com>.
  770. >
  771. >Information about other TIS network security products or commercial
  772. >licensing requests should be sent to <netsec@tis.com> or by telephone to
  773. >(301) 854-6889.
  774. >
  775. >
  776. >The contents of pub/firewalls/toolkit are as follows:
  777. >README                  - This file
  778. >fwtk-doc-only.tar.Z     - Toolkit documentation
  779. >fwtk.tar.Z              - Toolkit sources and Makefiles (no documentation)
  780. >US-only                 - Directory containing US-only software. If you
  781. >                          are not accessing this from a site in the US or
  782. >                          canada you will not be able to FTP these files.
  783. >               The toolkit is still useable without these files.
  784. ------------------------------------------------------------------
  785. SOCKS            Ying-Da Lee/David Koblas
  786.  
  787. >From: ylee@syl.dl.nec.com (Ying-Da Lee)
  788. >
  789. >(This is a package that allows hosts behind a firewall the use of
  790. >finger, ftp, telnet, xgopher, and xmosaic to access the resources
  791. >outside of the firewall while maintaining the security requirements.)
  792. >
  793. >A new release of SOCKS is available for anonymous ftp from
  794. >
  795. >    host    ftp.inoc.dl.nec.com (143.101.112.3),
  796. >    file    pub/security/socks.cstc.4.0.tar.gz
  797. >
  798. >This version is intended to run with identd user verification (RFC 1413),
  799. >which is available as file pub/security/pidentd-2.1.2.tar.gz.
  800. >
  801. >Both of these are in Gnu's compressed form and required gzip to
  802. >uncompress them.  If you don't already have that you can also pick up
  803. >the file pub/gnu/gzip-1.1.2.tar.Z.  Remember to download them in binary
  804. >mode.
  805. >
  806. >
  807. >I am enclosing the first part of the README.1st file which describes the
  808. >new fearures.  Besides SunOS 4.1.x, the new version has also been ported
  809. >and tested on ULTRIX 4.3, IRIX 4.0.1, and partially on HPUX, thanks to
  810. >Ian Dunkin and Anthony Shipman.
  811. >
  812. >Hope you can make good use of the package.  Enjoy it.
  813. >
  814. >****
  815. >This is SOCKS, a package consisting of a proxy server (sockd) and client
  816. >programs corresponding to finger, whois, ftp, telnet, xgopher, and
  817. >xmosaic, as well as a library module (libsocks.a) for adapting other
  818. >applications into new client programs.
  819. >
  820. >The original SOCKS was written by David Koblas <koblas@netcom.com>,
  821. >which included the library module and finger, whois, and ftp clients.
  822. >
  823. >Clients programs added since the original are:
  824. >
  825. >-telnet: adapted from telnet.91.03.25 by David Borman <dab@cray.com>.
  826. > This version is supposed to be much easier than the previous one
  827. > to port to many different systems.
  828. >-xgopher: adapted from xgopher ver. 1.2 by Allan Tuchman <a-tuchman@uiuc.edu>.
  829. >-xmosaic: adapted from xmosaic ver. 1.2 by NCSA staff (contact
  830. > Marc Andreesen, <marca@ncsa.uiuc.edu>).
  831. >
  832. >The SOCKS protocol has changed with this version.  Since the server and
  833. >the clients must use the same SOCKS protocol, this server does not work
  834. >with clients of previous releases, and these clients do not work with
  835. >servers of previous releases.
  836. >
  837. >The access control mechanism has been expanded:
  838. >
  839. >-A list of users can be included along with other fields (source address,
  840. > destination address, service/port) for permission/denial of access.
  841. >-Identd is used (controlled by option -i and -I) in SOCKS server to try
  842. > to verify the actual user-ids. The code uses the library written by
  843. > Peter Eriksson <pen@lysator.liu.se> and /Pdr Emanuelsson <pell@lysator.liu.se>.
  844. >-A shell command can optionally be specified with each line. The command
  845. > is executed if the conditions of that line are satisfied. This is adapted
  846. > from the same feature and code used in the log_tcp package by Wietse
  847. > Venema <wietse@wzv.win.tue.nl>.
  848. >-Special entries (#NO_IDENTD: and #BAD_ID:) can be included to specify
  849. > shell commands to be executed when the client host doesn't run identd
  850. > and when identd's report doesn't agree with what the client prgram says.
  851. >
  852. >[...]
  853. >The package has been ported for ULTRIX 4.3 by Ian Dunkin and Anthony
  854. >Shipman, for IRIX 4.0.1 by Ian Dunkin (again), and partially for HPUX by
  855. >Anthony Shipman (again!).  (We are a small bunch of busy bees) I also
  856. >include patches by Craig Metz to SOCKSize xarchie and ncftp.  I have not
  857. >try these patches out myself though.
  858. >[...]
  859. ------------------------------------------------------------------
  860. ==================================================================
  861.  
  862. Q.7 Isn't it dangerous to give cracking tools to everyone?
  863.  
  864. That depends on your point of view.  Some people have complained that
  865. giving unrestricted public access to programs like COPS and Crack is
  866. irresponsible because the "baddies" can get at them easily.
  867.  
  868. Alternatively, you may believe that the really bad "baddies" have had
  869. programs like this for years, and that it's really a stupendously good
  870. idea to give these programs to the good guys too, so that they may check
  871. the integrity of their system before the baddies get to them.
  872.  
  873. So, who wins more from having these programs freely available? The good
  874. guys or the bad ? You decide, but remember that less honest tools than
  875. COPS and Crack tools were already out there, and most of the good guys
  876. didn't have anything to help.
  877. ------------------------------------------------------------------
  878.  
  879. Q.8 Why and how do systems get broken into?
  880.  
  881. This is hard to answer definitively.  Many systems which crackers break
  882. into are only used as a means of entry into yet more systems; by hopping
  883. between many machines before breaking into a new one, the cracker hopes
  884. to confuse any possible pursuers and put them off the scent.  There is
  885. an advantage to be gained in breaking into as many different sites as
  886. possible, in order to "launder" your connections.
  887.  
  888. Another reason may be psychological: some people love to play with
  889. computers and stretch them to the limits of their capabilities.
  890.  
  891. Some crackers might think that it's "really neat" to hop over 6 Internet
  892. machines, 2 gateways and an X.25 network just to knock on the doors of
  893. some really famous company or institution (eg: NASA, CERN, AT+T, UCB).
  894. Think of it as inter-network sightseeing.
  895.  
  896. This view is certainly appealing to some crackers, and certainly leads
  897. to both the addiction and self-perpetuation of cracking.
  898.  
  899. As to the "How" of the question, this is again a very sketchy area.  In
  900. universities, it is extremely common for computer account to be passed
  901. back and forth between undergraduates:
  902.  
  903.   "Mary gives her account password to her boyfriend Bert at another
  904.   site, who has a friend Joe who "plays around on the networks".  Joe
  905.   finds other crackable accounts at Marys site, and passes them around
  906.   amongst his friends..." pretty soon, a whole society of crackers is
  907.   playing around on the machines that Mary uses.
  908.  
  909. This sort of thing happens all the time, and not just in universities.
  910. One solution is in education.  Do not let your users develop attitudes
  911. like this one:
  912.  
  913.        "It doesn't matter what password I use on _MY_ account,
  914.             after all, I only use it for laserprinting..."
  915.                 - an Aberystwyth Law student, 1991
  916.  
  917. Teach them that use of the computer is a group responsibility.  Make
  918. sure that they understand that a chain is only as strong as it's weak
  919. link.
  920.  
  921. Finally, when you're certain that they understand your problems as a
  922. systems manager and that they totally sympathise with you, configure
  923. your system in such a way that they can't possibly get it wrong.
  924.  
  925. Believe in user education, but don't trust to it alone.
  926. ------------------------------------------------------------------
  927.  
  928. Q.9 Who can I contact if I get broken into?
  929.  
  930. If you're connected to the Internet, you should certainly get in touch
  931. with CERT, the Computer Emergency Response Team.
  932.  
  933.     To quote the official blurb:
  934.  
  935. >From: Ed DeHart
  936. > The Computer Emergency Response Team (CERT) was formed by the Defense
  937. > Advanced Research Projects Agency (DARPA) in 1988 to serve as a focal
  938. > point for the computer security concerns of Internet users.  The
  939. > Coordination Center for the CERT is located at the Software Engineering
  940. > Institute, Carnegie Mellon University, Pittsburgh, PA.
  941.  
  942. > Internet E-mail: cert@cert.org
  943. > Telephone: 412-268-7090 24-hour hotline:
  944. >     CERT/CC personnel answer 7:30a.m. to 6:00p.m. EST(GMT-5)/EDT(GMT-4),
  945. >     and are on call for emergencies during other hours.
  946.  
  947. ...and also, the umbrella group "FIRST", which mediates between the
  948. incident handling teams themselves...
  949.  
  950. >From: John Wack <wack@csrc.ncsl.nist.gov>
  951. >[...] FIRST is actually a very viable and growing
  952. >organization, of which CERT is a member.  It's not actually true that,
  953. >if you're connected to the Internet, you should call CERT only - that
  954. >doesn't do justice to the many other response teams out there and in the
  955. >process of forming.
  956.  
  957. >NIST is currently the FIRST secretariat; we maintain an anonymous ftp
  958. >server with a directory of FIRST information (csrc.ncsl.nist.gov:
  959. >~/pub/first).  This directory contains a contact file that lists the
  960. >current members and their constituencies and contact information
  961. >(filename "first-contacts").
  962.  
  963. >While CERT is a great organization, other response teams who do handle
  964. >incidents on their parts of the Internet merit some mention as well -
  965. >perhaps mentioning the existence of this file would help to do that in a
  966. >limited space.
  967.  
  968. The file mentioned is a comprehensive listing of contact points per
  969. network for security incidents.  It is too large to reproduce here, I
  970. suggest that the reader obtains a copy for his/her self by the means
  971. given.
  972. ------------------------------------------------------------------
  973.  
  974. Q.10 What is a firewall?
  975.  
  976. A (Internet) firewall is a machine which is attached (usually) between
  977. your site and a wide area network.  It provides controllable filtering
  978. of network traffic, allowing restricted access to certain internet port
  979. numbers (ie: services that your machine would otherwise provide to the
  980. network as a whole) and blocks access to pretty well everything else.
  981. Similar machines are available for other network types, too.
  982.  
  983. Firewalls are an effective "all-or-nothing" approach to dealing with
  984. external access security, and they are becoming very popular, with the
  985. rise in Internet connectivity.
  986.  
  987. For more information on these sort of topics, see the Gateway paper by
  988. [Cheswick], below.
  989. ------------------------------------------------------------------
  990.  
  991. Q.11 Why shouldn't I use setuid shell scripts?
  992.  
  993. You shouldn't use them for a variety of reasons, mostly involving bugs
  994. in the Unix kernel.  Here are a few of the more well known problems,
  995. some of which are fixed on more recent operating systems.
  996.  
  997. 1) If the script begins "#!/bin/sh" and a link (symbolic or otherwise)
  998. can be made to it with the name "-i", a setuid shell can be immediately
  999. obtained because the script will be invoked: "#!/bin/sh -i", ie: an
  1000. interactive shell.
  1001.  
  1002. 2) Many kernels suffer from a race condition which can allow you to
  1003. exchange the shellscript for another executable of your choice between
  1004. the times that the newly exec()ed process goes setuid, and when the
  1005. command interpreter gets started up.  If you are persistent enough, in
  1006. theory you could get the kernel to run any program you want.
  1007.  
  1008. 3) The IFS bug: the IFS shell variable contains a list of characters to
  1009. be treated like whitespace by a shell when parsing command names.  By
  1010. changing the IFS variable to contain the "/" character, the command
  1011. "/bin/true" becomes "bin true".
  1012.  
  1013. All you need do is export the modified IFS variable, install a command
  1014. called "bin" in your path, and run a setuid script which calls
  1015. "/bin/true".  Then "bin" will be executed whilst setuid.
  1016.  
  1017. If you really must write scripts to be setuid, either
  1018.  
  1019.   a) Put a setuid wrapper in "C" around the script, being very careful
  1020.   to reset IFS and PATH to something sensible before exec()ing the
  1021.   script.  If your system has runtime linked libraries, consider the
  1022.   values of the LD_LIBRARY_PATH also.
  1023.  
  1024.   b) Use a scripting language like Perl which has a safe setuid
  1025.   facility, and is proactively rabid about security.
  1026.  
  1027. - but really, it's safest not to use setuid scripts at all.
  1028. ------------------------------------------------------------------
  1029.  
  1030. Q.12 Why shouldn't I leave "root" permanently logged on the console?
  1031.  
  1032. Using a 'smart' terminal as console and leaving "/dev/console" world
  1033. writable whilst "root" is logged in is a potential hole.  The terminal
  1034. may be vulnerable to remote control via escape sequences, and can be
  1035. used to 'type' things into the root shell.  The terminal type can
  1036. usually be obtained via the "ps" command.
  1037.  
  1038. Various solutions to this can be devised, usually by giving the console
  1039. owner and group-write access only , and then using the setgid mechanism
  1040. on any program which has need to output to the console (eg: "write").
  1041. ------------------------------------------------------------------
  1042.  
  1043. Q.13 Why shouldn't I create Unix accounts with null passwords?
  1044.  
  1045. Creating an unpassworded account to serve any purpose is potentially
  1046. dangerous, not for any direct reason, but because it can give a cracker
  1047. a toehold.
  1048.  
  1049. For example, on many systems you will find a unpassworded user "sync",
  1050. which allows the sysman to sync the disks without being logged in.  This
  1051. appears to be both safe and innocuous.
  1052.  
  1053. The problem with this arises if your system is one of the many which
  1054. doesn't do checks on a user before authorising them for (say) FTP.  A
  1055. cracker might be able to connect to your machine for one of a variety of
  1056. FTP methods, pretending to be user "sync" with no password, and then
  1057. copy your password file off for remote cracking.
  1058.  
  1059. Although there are mechanisms to prevent this sort of thing happening in
  1060. most modern vesions of Unix, to be totally secure requires an in-depth
  1061. knowledge of every package on your system, and how it deals with the
  1062. verification of users.  If you can't be sure, it's probably better not
  1063. to leave holes like this around.
  1064.  
  1065. Another hole that having null-password accounts opens up is the
  1066. possibility (on systems with runtime linked libraries) of spoofing
  1067. system software into running your programs as the "sync" user, by
  1068. changing the LD_LIBRARY_PATH variable to a library of your own devising,
  1069. and running "login -p" or "su" to turn into that user.
  1070.  
  1071.  
  1072. >From: chowes@sfu.ca
  1073. >Don't forget LD_LIBRARY_PRELOAD!  You can point it to a library that
  1074. >contains routines to override LD_LIBRARY_PATH routines.  Main advantage
  1075. >is that the library is a lot smaller by virtue of only having the
  1076. >doctored routines, not *every* routine; and also that some people
  1077. >forget to protect both.
  1078.  
  1079. [Just how many more of these LD_* variables ARE there ? - Alec]
  1080.  
  1081.  
  1082. >From: barnett@alydar.crd.ge.com (Bruce Barnett)
  1083. >
  1084. >One more thing you may want to mention is that each network service must
  1085. >be checked to see if there is any security problem.  Not all services
  1086. >use the shell entry in a passwd file.  Therefore having a null password
  1087. >make allow other services to break into the account.
  1088. >
  1089. >For instance, some systems that provide remote file access uses the
  1090. >username and password to verify access.  The shell entry is not used.
  1091. >
  1092. >Therefore it is possible for someone to use the "sync" account to
  1093. >"mount" a Unix file system, getting access to the account without using
  1094. >the shell.
  1095. >
  1096. >To be precise, I used Sun's TOPS service on a Macintosh to mount a Unix
  1097. >file system thru the sync account as it didn't have any password.  I has
  1098. >user ID "1" when I did this.  Don't know if this needs to be added to
  1099. >the FAQ...  I did notify Sun a while ago about this bug....
  1100. ------------------------------------------------------------------
  1101.  
  1102. Q.14 What security holes are associated with X-windows (and other WMs)?
  1103.  
  1104. Lots, some which affect use of X only, and some which impact the
  1105. security of the entire host system.
  1106.  
  1107. I would prefer not to go into too much detail here, and would refer any
  1108. reader reader looking for detailed information to the other FAQ's in
  1109. relevant newsgroups.  (comp.windows.*)
  1110.  
  1111. One point I will make is that X is one of those packages which often
  1112. generates "Incompatible Usage" security problems, for instance the
  1113. ability for crackers to run xsessions on hosts under accounts with no
  1114. password (eg: sync), if it is improperly set up.  Read the question
  1115. about unpassworded accounts in this FAQ.
  1116. ------------------------------------------------------------------
  1117.  
  1118. Q.15 What security holes are associated with NFS?
  1119.  
  1120. Lots, mostly to do with who you export your disks to, and how.  The
  1121. security of NFS relies heavily upon who is allowed to mount the files
  1122. that a server exports, and whether they are exported read only or not.
  1123.  
  1124. The exact format for specifying which hosts can mount an exported
  1125. directory varies between Unix implementations, but generally the
  1126. information is contained within the file "/etc/exports".
  1127.  
  1128. This file contains a list of directories and for each one, it has a
  1129. series of either specific "hosts" or "netgroups" which are allowed to
  1130. NFS mount that directory.  This list is called the "access list".
  1131.  
  1132. The "hosts" are individual machines, whilst "netgroups" are combinations
  1133. of hosts and usernames specified in "/etc/netgroup".  These are meant to
  1134. provide a method of finetuning access.  Read the relevant manual page
  1135. for more information about netgroups.
  1136.  
  1137. The exports file also contains information about whether the directory
  1138. is to be exported as read-only, read-write, and whether super-user
  1139. access is to be allowed from clients which mount that directory.
  1140.  
  1141. The important point to remember is that if the access list for a
  1142. particular directory in /etc/exports contains:
  1143.  
  1144. 1) <nothing>
  1145.  
  1146. Your directory can be mounted by anyone, anywhere.
  1147.  
  1148. 2) <a specific hostname>
  1149.  
  1150. Your directory can be mounted by anyone permitted to run the mount
  1151. command at hostname.  This might not be a trustworthy person; for
  1152. instance, if the machine is a PC running NFS, it could be anyone.
  1153.  
  1154. 3) <a netgroup name>
  1155.  
  1156. If the netgroup:
  1157.  
  1158. a) is empty, anyone can mount your directory, from anywhere.
  1159.  
  1160. b) contains "(,,)", anyone can mount your directory, from anywhere.
  1161.  
  1162. c) contains the name of a netgroup which is empty or contains "(,,)",
  1163.    anyone can mount your directory, from anywhere.
  1164.  
  1165. d) contains "(hostname,,)", anyone on the named host who is permissioned
  1166.    to mount files can mount your directory.
  1167.  
  1168. e) contains "(,username,)", the named user can mount your directory,
  1169.    from anywhere.
  1170.  
  1171. 4) <a word which is neither a hostname or a netgroup>
  1172.  
  1173. If you meant to export the directory to the host "athena" but actually
  1174. type "ahtena", the word "ahtena" is taken as a netgroup name, is found
  1175. to be an empty netgroup, and thus the directory can be mounted by
  1176. anyone, anywhere.
  1177.  
  1178. So, if you aren't careful about what you put into /etc/exports and
  1179. /etc/netgroup you could find that a user with a PC could
  1180.  
  1181.   a) mount your mainframe filestore as a network disk
  1182.   b) edit your /etc/passwd or .rhosts or /etc/hosts.equiv ...
  1183.   c) log into your mainframe as another user, possibly "root"
  1184.  
  1185. Disclaimer: The above information may not be true for all platforms
  1186. which provide an NFS serving capability, but is true for all of the ones
  1187. in my experience (Alec).  It should be noted that the SAFE way to create
  1188. an "empty" netgroup entry is:
  1189.  
  1190.                ngname (-,-,-)
  1191.  
  1192. Which is a netgroup which matches no-one on no-host on no-NIS-domain.
  1193.  
  1194. >From: Mark Crispin <mrc@EDU.Washington.CAC.Tomobiki-Cho>
  1195. >
  1196. >NFS is far more insecure than the FAQ implies.  It does not require
  1197. >any carelessness in export files, since the only thing the export file
  1198. >does is be helpful in disclosing the key that an NFS client needs to
  1199. >unlock your system.  Means exist to guess these keys.  It is prudent,
  1200. >to say the least, to configure your routers to forbid NFS traffic from
  1201. >outside your organization.
  1202.  
  1203. [...this is true; I just haven't had time to document it yet...]
  1204. ------------------------------------------------------------------
  1205.  
  1206. Q.16 How can I generate safe passwords?
  1207.  
  1208. You can't.  The key word here is GENERATE.  Once an algorithm for
  1209. creating passwords is specified using upon some systematic method, it
  1210. merely becomes a matter of analysing your algorithm in order to find
  1211. every password on your system.
  1212.  
  1213. Unless the algorithm is very subtle, it will probably suffer from a very
  1214. low period (ie: it will soon start to repeat itself) so that either:
  1215.  
  1216.   a) a cracker can try out every possible output of the password
  1217.   generator on every user of the system, or
  1218.  
  1219.   b) the cracker can analyse the output of the password program,
  1220.   determine the algorithm being used, and apply the algorithm to other
  1221.   users to determine their passwords.
  1222.  
  1223. A beautiful example of this (where it was disastrously assumed that a
  1224. random number generator could generate an infinite number of random
  1225. passwords) is detailed in [Morris & Thompson].
  1226.  
  1227. The only way to get a reasonable amount of variety in your passwords
  1228. (I'm afraid) is to make them up.  Work out some flexible method of your
  1229. own which is NOT based upon:
  1230.  
  1231.   1) modifying any part of your name or name+initials
  1232.   2) modifying a dictionary word
  1233.   3) acronyms
  1234.   4) any systematic, well-adhered-to algorithm whatsoever
  1235.  
  1236. For instance, NEVER use passwords like:
  1237.  
  1238. alec7         - it's based on the users name (& it's too short anyway)
  1239. tteffum        - based on the users name again
  1240. gillian        - girlfiends name (in a dictionary)
  1241. naillig        - ditto, backwards
  1242. PORSCHE911     - it's in a dictionary
  1243. 12345678     - it's in a dictionary (& people can watch you type it easily)
  1244. qwertyui     - ...ditto...
  1245. abcxyz        - ...ditto...
  1246. 0ooooooo    - ...ditto...
  1247. Computer     - just because it's capitalised doesn't make it safe
  1248. wombat6     - ditto for appending some random character
  1249. 6wombat     - ditto for prepending some random character
  1250. merde3        - even for french words...
  1251. mr.spock     - it's in a sci-fi dictionary
  1252. zeolite     - it's in a geological dictionary
  1253. ze0lite     - corrupted version of a word in a geological dictionary
  1254. ze0l1te     - ...ditto...
  1255. Z30L1T3     - ...ditto...
  1256.  
  1257. I hope that these examples emphasise that ANY password derived from ANY
  1258. dictionary word (or personal information), modified in ANY way,
  1259. constitutes a potentially guessable password.
  1260.  
  1261. For more detailed information in the same vein, you should read the
  1262. APPENDIX files which accompany Crack [Muffett].
  1263. ------------------------------------------------------------------
  1264.  
  1265. Q.17 Why are passwords so important?
  1266.  
  1267. Because they are the first line of defence against interactive attacks
  1268. on your system.  It can be stated simply: if a cracker cannot interact
  1269. with your system(s), and he has no access to read or write the
  1270. information contained in the password file, then he has almost no
  1271. avenues of attack left open to break your system.
  1272.  
  1273. This is also why, if a cracker can at least read your password file (and
  1274. if you are on a vanilla modern Unix, you should assume this) it is so
  1275. important that he is not able to break any of the passwords contained
  1276. therein.  If he can, then it is also fair to assume that he can (a) log
  1277. on to your system and can then (b) break into "root" via an operating
  1278. system hole.
  1279. ------------------------------------------------------------------
  1280.  
  1281. Q.18 How many possible passwords are there?
  1282.  
  1283. Most people ask this at one time or another, worried that programs like
  1284. Crack will eventually grow in power until they can do a completely
  1285. exhaustive search of all possible passwords, to break into a specific
  1286. users' account - usually root.
  1287.  
  1288. If (to simplify the maths) we make the assumptions that:
  1289.  
  1290.   1) Valid passwords are created from a set of 62 chars [A-Za-z0-9]
  1291.   2) Valid passwords are to be between 5 and 8 chars long
  1292.  
  1293. Then the size of the set of all valid passwords is: (in base 62)
  1294.  
  1295.                    100000b62 +
  1296.                   1000000b62 +
  1297.                  10000000b62 +
  1298.                 100000000b62 =
  1299.                 ---------
  1300.                 111100000b62
  1301.  
  1302.               ~= 222000000000000 (decimal)
  1303.  
  1304. A figure which is far too large to usefully undertake an exhaustive
  1305. search with current technologies.  Don't forget, however, that passwords
  1306. CAN be made up with even more characters then this; you can use <space>,
  1307. all the punctuation characters, and symbols (~<>|\#$%^&*) too.  If you
  1308. can use some of all the 95 non-control characters in passwords, this
  1309. increases the search space for a cracker to cover even further.
  1310.  
  1311. However, it's still MUCH more efficient for a cracker to get a copy of
  1312. "Crack", break into ANY account on the system (you only need one), log
  1313. onto the machine, and spoof his way up to root priviledges via operating
  1314. systems holes.
  1315.  
  1316. Take comfort from these figures.  If you can slam the door in the face
  1317. of a potential crackers with a robust password file, you have sealed
  1318. most of the major avenues of attack immediately.
  1319. ------------------------------------------------------------------
  1320.  
  1321. Q.19 Where can I get more information?
  1322.  
  1323. Books:
  1324.  
  1325. [Kochan & Wood]
  1326. Unix System Security
  1327.  
  1328. A little dated for modern matters, but still a very good book on the
  1329. basics of Unix security.
  1330.  
  1331. [Spafford & Garfinkel]
  1332. Practical Unix Security
  1333.  
  1334. This wonderful book is a worthy successor to the above, and covers a
  1335. wide variety of the topics which the Unix (and some non Unix) system
  1336. manager of the 90's will come across.
  1337.  
  1338. >From: Gene Spafford <spaf@cs.purdue.edu>
  1339. >Mention appendix E in "Practical Unix Security."
  1340.  
  1341. Okay: Appendix E contains an extensive bibliography with even more
  1342. pointers to security books than this FAQ contains.
  1343.  
  1344. [Stoll]
  1345. The Cuckoo's Egg
  1346.  
  1347. A real life 1980's thriller detailing the tracing of a cracker from
  1348. Berkeley across the USA and over the Atlantic to Germany.  An excellent
  1349. view from all points: a good read, informative about security, funny,
  1350. and a good illustration of the cracker psyche.  Contains an excellent
  1351. recipie for chocolate chip cookies.
  1352.  
  1353. A videotape of the "NOVA" (PBS's Science Program on TV) episode that
  1354. explained/reenacted this story is available from PBS Home Video.  They
  1355. have a toll-free 800 number within North America.
  1356.  
  1357. I believe that this program was aired on the BBC's "HORIZON" program,
  1358. and thus will be available from BBC Enterprises, but I haven't checked
  1359. this out yet - Alec
  1360.  
  1361. THE TECHNICAL PAPER containing details of the "Cuckoo's Egg" breakin is
  1362. called "Stalking the wily hacker" in an issue of CACM which I will dig
  1363. out and get the proper reference for, in my copious free time - Alec
  1364.  
  1365.  
  1366. [Raymond] (Ed.)
  1367. The New Hackers Dictionary/Online Jargon File
  1368.  
  1369. A mish-mash of history and dictionary definitions which explains why it
  1370. is so wonderful to be a hacker, and why those crackers who aren't
  1371. hackers want to be called "hackers".  The Jargon File version is
  1372. available online - check an archie database for retails. 
  1373. Latest revision: 3.00.
  1374.  
  1375. [Gasser]
  1376. Building a Secure Computer System.
  1377.  
  1378. By Morrie Gasser, and van Nostrand Reinhold; explains what is required
  1379. to build a secure computer system.
  1380.  
  1381. [Rainbow Series] (Especially the "Orange Book")
  1382.  
  1383. >From: epstein@trwacs.fp.trw.com (Jeremy Epstein)
  1384. >The "Rainbow Series" consists of about 25 volumes.  Some of the
  1385. >more interesting ones are:
  1386. >
  1387. >    The "Orange Book", or Trusted Computer Systems Evaluation
  1388. >        Criteria, which describes functional and assurance
  1389. >        requirements for computer systems
  1390. >
  1391. >    Trusted Database Interpretation, which talks both about
  1392. >        trusted databases and building systems out of trusted
  1393. >        components
  1394. >
  1395. >    Trusted Network Interpretation, which (obviously) talks
  1396. >        about networked systems
  1397. >
  1398. >A (possibly) complete list is:
  1399. >    -- Department of Defense Trusted Computer System Evaluation Criteria
  1400. >       (TCSEC), aka the "Orange Book"
  1401. >    -- Computer Security Subsystem Interpretation of the TCSEC
  1402. >    -- Trusted Data Base Management System Interpretation of the TCSEC
  1403. >    -- Trusted Network Interpretation of the TCSEC
  1404. >    -- Trusted Network Interpretation Environments Guideline -- Guidance
  1405. >       for Applying the Trusted Network Interpretation
  1406. >    -- Trusted Unix Working Group (TRUSIX) Rationale for Selecting
  1407. >       Access Control List Features for the Unix System
  1408. >    -- Trusted Product Evaulations -- A Guide for Vendors
  1409. >    -- Computer Security Requirements -- Guidance for Applying the DoD
  1410. >       TCSEC in Specific Environments
  1411. >    -- Technical Rationale Behind CSC-STD-003-85: Computer Security
  1412. >       Requirements
  1413. >    -- Trusted Product Evaluation Questionnaire
  1414. >    -- Rating Maintenance Phase -- Program Document
  1415. >    -- Guidelines for Formal Verification Systems
  1416. >    -- A Guide to Understanding Audit in Trusted Systems
  1417. >    -- A Guide to Understanding Trusted Facility Management
  1418. >    -- A Guide to Understanding Discretionary Access Control in Trusted
  1419. >       Systems
  1420. >    -- A Guide to Understanding Configuration Management in Trusted Systems
  1421. >    -- A Guide to Understanding Design Documentation in Trusted Systems
  1422. >    -- A Guide to Understanding Trusted Distribution in Trusted Systems
  1423. >    -- A Guide to Understanding Data Remanence in Automated Information
  1424. >       Systems
  1425. >    -- Department of Defense Password Management Guideline
  1426. >    -- Glossary of Computer Security Terms
  1427. >    -- Integrity in Automated Information Systems
  1428. >
  1429. >You can get your own copy (free) of any or all of the books by
  1430. >writing or calling:
  1431. >
  1432. >    INFOSEC Awareness Office
  1433. >    National Computer Security Centre
  1434. >    9800 Savage Road
  1435. >    Fort George G. Meade, MD  20755-6000
  1436. >
  1437. >If you ask to be put on the mailing list, you'll get a copy of each new
  1438. >book as it comes out (typically a couple a year).
  1439. ------------------------------------------------------------------
  1440. >From: kleine@fzi.de (Karl Kleine)
  1441. >I was told that this offer is only valid for US citizens ("We only send
  1442. >this stuff to a US postal address").  Non-US people have to PAY to get
  1443. >hold of these documents.  They can be ordered from NTIS, the National
  1444. >Technical Information Service:
  1445. >    NTIS,
  1446. >    5285 Port Royal Rd,
  1447. >    Springfield VA 22151,
  1448. >    USA
  1449. ------------------------------------------------------------------
  1450. >From: Ulf Kieber <kieber@de.tu-dresden.inf.freia>
  1451. >just today I got my set of the Rainbow Series.
  1452. >
  1453. >There are three new books:
  1454. > -- A Guide to Understanding Trusted Recovery in Trusted Systems
  1455. > -- A Guide to Understanding Identification and Authentication in Trusted
  1456. >    Systems
  1457. > -- A Guide to Writing the Security Features User's Guide for Trusted Systems
  1458. >
  1459. >They also shipped
  1460. > -- Advisory Memorandum on Office Automation Security Guideline
  1461. >issued by NTISS.  Most of the books (except three or four) can also be
  1462. >purchased from
  1463. >
  1464. >    U.S. Government Printing Office
  1465. >    Superintendent of Documents
  1466. >    Washington, DC 20402        phone: (202) 783-3238
  1467. >
  1468. >>-- Integrity in Automated Information Systems
  1469. >THIS book was NOT shipped to me--I'm not sure if it is still in
  1470. >the distribution.
  1471. ------------------------------------------------------------------
  1472. >From: epstein@trwacs.fp.trw.com (Jeremy Epstein)
  1473. >...
  1474. >The ITSEC (Information Technology Security Evaluation Criteria) is a
  1475. >harmonized document developed by the British, German, French, and
  1476. >Netherlands governments.  It separates functional and assurance
  1477. >requirements, and has many other differences from the TCSEC.
  1478. >
  1479. >You can get your copy (again, free/gratis) by writing:
  1480. >
  1481. >    Commission of the European Communities
  1482. >    Directorate XIII/F
  1483. >    SOG-IS Secretariat
  1484. >    Rue de la Loi 200
  1485. >    B-1049 BRUSSELS
  1486. >    Belgium
  1487. ------------------------------------------------------------------
  1488. >From: Nick Barron <nikb@uk.co.compulink.cix>
  1489. >
  1490. >...The ITSEC and associated DTI security publications (the "Green
  1491. >Books") are available for *free* (makes a change) from the DTI
  1492. >Commercial Computer Security Centre.  The contact is Fiona Williams on
  1493. >081 977 3222 or as fjw@dsg.npl.co.uk.  Hope that this is of interest.
  1494. >The ITSEC is currently being "harmonised" with the Orange Book...
  1495.  
  1496. Also note that NCSC periodically publish an "Evaluated Products List"
  1497. which is the definitive statement of which products have been approved
  1498. at what TCSEC level under which TCSEC interpretations.  This is useful
  1499. for separating the output of marketdroids from the truth.
  1500.  
  1501.  
  1502. Papers:
  1503.  
  1504. [Morris & Thompson]
  1505. Password Security, A Case History
  1506.  
  1507. A wonderful paper, first published in CACM in 1974, which is now often
  1508. to found in the Unix Programmer Docs supplied with many systems.
  1509. ------------------------------------------------------------------
  1510. [Curry]
  1511. Improving the Security of your Unix System.
  1512.  
  1513. A marvellous paper detailing the basic security considerations every
  1514. Unix systems manager should know.  Available as "security-doc.tar.Z"
  1515. from FTP sites (check an Archie database for your nearest site.)
  1516. ------------------------------------------------------------------
  1517. [Klein]
  1518. Foiling the Cracker: A Survey of, and Improvements to, Password Security.
  1519.  
  1520. A thorough and reasoned analysis of password cracking trends, and the
  1521. reasoning behind techniques of password cracking.  Your nearest copy
  1522. should be easily found via Archie, searching for the keyword "Foiling".
  1523. ------------------------------------------------------------------
  1524. [Cheswick]
  1525. The Design of a Secure Internet Gateway.
  1526.  
  1527. Great stuff.
  1528.  
  1529. Host: research.att.com
  1530. Location: dist/internet_security
  1531.  
  1532.       FILE      rw-rw-r--    33836     Jul 24 1992    gateway.dvi
  1533.       FILE      rw-rw-r--    42373     Aug 19 1991    gateway.ps
  1534.       FILE      rw-rw-r--    674169    Jun 28 12:23   gateway_slides.ps
  1535. ------------------------------------------------------------------
  1536. [Cheswick]
  1537. An Evening With Berferd: in which a Cracker is Lured, Endured & Studied.
  1538.  
  1539. Funny and very readable, somewhat in the style of [Stoll] but more
  1540. condensed.
  1541.  
  1542. Host: research.att.com
  1543. Location: dist/internet_security
  1544.  
  1545.       FILE      rw-rw-r--    41612     Jul 24 1992    berferd.dvi
  1546.       FILE      rw-rw-r--    81747     Jul 24 1992    berferd.ps
  1547. ------------------------------------------------------------------
  1548. [Bellovin89]
  1549. Security Problems in the TCP/TP Protocol Suite.
  1550.  
  1551. A description of security problems in many of the protocols widely used
  1552. in the Internet.  Not all of the discussed protocols are official
  1553. Internet Protocols (i.e.  blessed by the IAB), but all are widely used.
  1554. The paper originally appeared in ACM Computer Communications Review,
  1555. Vol 19, No 2, April 1989. 
  1556.  
  1557. Host: research.att.com
  1558. Location: dist/internet_security
  1559.  
  1560.       FILE      rw-rw-r--    48703     Aug 22 1991    ipext.ps.Z
  1561. ------------------------------------------------------------------
  1562. [Bellovin91]
  1563. Limitations of the Kerberos Authentication System
  1564.  
  1565. A discussion of the limitations and weaknesses of the Kerberos
  1566. Authentication System.  Specific problems and solutions are presented.
  1567. Very worthwhile reading.  Available on research.att.com via anonymous
  1568. ftp, originally appeared in ACM Computer Communications Review but the
  1569. revised version (identical to the online version, I think) appeared in
  1570. the Winter 1991 USENIX Conference Proceedings.
  1571. ------------------------------------------------------------------
  1572. [Muffett]
  1573. Crack documentation.
  1574.  
  1575. The information which accompanies Crack contains a whimsical explanation
  1576. of password cracking techniques and the optimisation thereof, as well as
  1577. an incredibly long and silly diatribe on how to not choose a crackable
  1578. password.  A good read for anyone who needs convincing that password
  1579. cracking is _really easy_.
  1580. ------------------------------------------------------------------
  1581. [Farmer]
  1582. COPS
  1583.  
  1584. Read the documentation provided with COPS.  Lots of hints and
  1585. philosophy.  The where, why and how behind the piece of security
  1586. software that started it all.
  1587. ------------------------------------------------------------------
  1588. [CERT]
  1589. maillists/advisories/clippings
  1590.  
  1591. CERT maintains archives of useful bits of information that it gets from
  1592. USENET and other sources.  Also archives of all the security
  1593. "advisories" that it has posted (ie: little messages warning people that
  1594. there is a hole in their operating system, and where to get a fix)
  1595. ------------------------------------------------------------------
  1596. [OpenSystemsSecurity]
  1597.  
  1598. A notorious (but apparently quite good) document, which has been dogged
  1599. by being in a weird postscript format.
  1600.  
  1601. >From: amesml@monu1.cc.monash.edu.au (Mark L. Ames)
  1602.  
  1603. >I've received many replies to my posting about Arlo Karila's paper,
  1604. >including the news (that I and many others have missed) that a
  1605. >manageable postscript file and text file are available via anonymous ftp
  1606. >from ajk.tele.fi (131.177.5.20) in the directory PublicDocuments.
  1607.  
  1608. These are all available for FTP browsing from "cert.org".
  1609. ------------------------------------------------------------------
  1610. [RFC-1244]
  1611. Site Security Handbook
  1612.  
  1613. RFC-1244 : JP Holbrook & JK Reynolds (Eds.) "The Site Security Handbook"
  1614. covering incident handling and prevention.  July 1991; 101 pages
  1615. (Format: TXT=259129 bytes), also called "FYI 8"
  1616. ------------------------------------------------------------------
  1617. [USENET]
  1618. comp.virus: for discussions of virii and other nasties, with a PC bent.
  1619. comp.unix.admin: for general administration issues
  1620. comp.unix.<platform>: for the hardware/software that YOU use.
  1621. comp.protocols.tcp-ip: good for problems with NFS, etc.
  1622. ------------------------------------------------------------------
  1623.  
  1624. Q.20 How silly can people get?
  1625.  
  1626. This section (which I hope to expand) is a forum for learning by
  1627. example; if people have a chance to read about real life (preferably
  1628. silly) security incidents, it will hopefully instill in readers some of
  1629. the zen of computer security without the pain of experiencing it.
  1630.  
  1631. If you have an experience that you wish to share, please send it to the
  1632. editors.  It'll boost your karma no end.
  1633. ------------------------------------------------------------------
  1634. From: aem@aber.ac.uk
  1635.  
  1636. The best story I have is of a student friend of mine (call him Bob) who
  1637. spent his industrial year at a major computer manufacturing company.  In
  1638. his holidays, Bob would come back to college and play AberMUD on my
  1639. system.
  1640.  
  1641. Part of Bob's job at the company involved systems management, and the
  1642. company was very hot on security, so all the passwords were random
  1643. strings of letters, with no sensible order.  It was imperative that the
  1644. passwords were secure (this involved writing the random passwords down
  1645. and locking them in big, heavy duty safes).
  1646.  
  1647. One day, on a whim, I fed the MUD persona file passwords into Crack as a
  1648. dictionary (the passwords were stored plaintext) and then ran Crack on
  1649. our systems password file.  A few student accounts came up, but nothing
  1650. special.  I told the students concerned to change their passwords - that
  1651. was the end of it.
  1652.  
  1653. Being the lazy guy I am, I forgot to remove the passwords from the Crack
  1654. dictionary, and when I posted the next version to USENET, the words went
  1655. too.  It went to the comp.sources.misc moderator, came back over USENET,
  1656. and eventually wound up at Bob's company.  Round trip: ~10,000 miles.
  1657.  
  1658. Being a cool kinda student sysadmin dude, Bob ran the new version of
  1659. Crack when it arrived.  When it immediately churned out the root
  1660. password on his machine, he damn near fainted...
  1661.  
  1662. The moral of this story is: never use the same password in two different
  1663. places, and especially on untrusted systems (like MUDs).
  1664. ------------------------------------------------------------------
  1665. From: zerkle@cs.ucdavis.edu (Dan Zerkle)
  1666.  
  1667. I've got a good one.
  1668.  
  1669. Our department has a room of workstations for graduate students who have
  1670. not started on a research project.  If you don't have an account, you
  1671. can still use these workstations as terminals.  There is a special,
  1672. null-password account called "terminal".  This account runs a short
  1673. program which accepts a machine name, a user name and a password, then
  1674. runs rlogin to connect you to the machine of your choice.
  1675.  
  1676. Awhile back, I used this system, but accidentally hit RETURN before I
  1677. typed my user name.  Since there was no way to back out, I also hit
  1678. RETURN for the password.
  1679.  
  1680. As it happened, the machine to which I was connecting had an entry in
  1681. the password file like this:
  1682.  
  1683. ::0:1:::    (this is a YP/NIS password entry, missing a "+" symbol)
  1684.  
  1685. You can imagine how startled I was when the terminal program connected
  1686. me and logged me in as root! I sent mail to the system administrator (as
  1687. root, just to irk him), and got the hole patched within a day.
  1688.  
  1689. Ordinarily, the entry in the password file was not a problem.  Normal
  1690. methods of logging in require you to supply a user name.  However, the
  1691. "terminal" login accepted the null string as a user name and passed it
  1692. on (via rlogin) to the host computer.  Thus, purely by accident, I
  1693. managed to break root on that machine.
  1694.  
  1695.                     -Dan
  1696. --------------------------------------------------------------------
  1697. From: BENNETT@dstos3.dsto.gov.au (John Bennett)
  1698.  
  1699. Hi Alec,
  1700.  
  1701. You asked for contributions for "How silly can people get ?"
  1702. Here is a simple but true and possibly oft repeated story...
  1703.  
  1704. My son bought a new car, so we went down to the local office of the
  1705. Royal Automobile Association to insure it.  A Charming Young Lady was
  1706. very helpful and efficient as we sorted out the details of the policy.
  1707. Once the paperwork was written, the CYL went across the office to a
  1708. computer terminal, sat down, and called to another CYL
  1709.  
  1710. "Is the password still (censored, name of computer company) ?".
  1711.  
  1712. Regards,
  1713.  
  1714. John Bennett bennett@dstos3.dsto.gov.au
  1715. -------------------------------------------------------------------
  1716. From: Alec.Muffett@UK.Sun.COM
  1717.  
  1718. - A cautionary tale, about a friend of mine who will probably wish to
  1719.   remain anonymous, for his sins. (Hi, Ian!)
  1720.  
  1721. At a British university with a particularly paranoid (not to say rabid)
  1722. security policy, the systems administrators had changed the permissions
  1723. on the "su" command, removing world execute permission, and making it
  1724. group-execute only to members of the computing services staff. 
  1725.  
  1726. ...however, the staff were not informed enough to remove world-write
  1727. permission from /dev/console. 
  1728.  
  1729. My friend, Ian, attended this university, and on one occasion became
  1730. particularly annoyed at a fellow student-user (let's call him foobar1).
  1731.  
  1732. Foobar1 was apparently nosing round the terminals of everyone in the
  1733. room, peering over the shoulders of his fellow students, and not obeying
  1734. the rules of etiquette. 
  1735.  
  1736. So, in order to "get him back", Ian did this:
  1737.  
  1738. Ian wrote a script which, every so often, would print:
  1739.  
  1740.     BAD SU: foobar1 on tty0a at 12:34:56
  1741.  
  1742. - to the machine's console.  
  1743.  
  1744. Given that "only members of staff can use 'su' to get to root on this
  1745. system", this must have worried the operators mightily. 
  1746.  
  1747. After a few iterations of this cat-and-mouse game, Ian did:
  1748.  
  1749.     SU: foobar1 on tty0a at 12:45:03
  1750.  
  1751. - thirty seconds later, the machine crashed.  The operations team,
  1752. rather than let this horrible hacker run amok on the system, chose to
  1753. pull the plug.  They then arrived in the terminal room, hauled "foobar1"
  1754. out backwards, took him away and shouted at him for an hour or so, until
  1755. they believed that it wasn't him. 
  1756.  
  1757. I believe that Ian apologised to foobar1 eventually, but the systems
  1758. people never *did* sort it out.  The moral of this tale?
  1759.  
  1760. During an incident:
  1761.  
  1762.     1) don't panic - you might do something stupid
  1763.     2) don't trust any audit trail which is open to compromise
  1764. ------------------------------------------------------------------
  1765. Alec Muffett (alec.muffett@sun.co.uk) Sun Microsystems IR, Bagshot, Surrey, UK
  1766.                          #include <stddisclaimer.h>
  1767.  
  1768.  
  1769.