Followup to UUCP/USENET security question.

Matt Goheen matt at srs.UUCP
Thu Sep 5 00:45:57 AEST 1985



    A couple of weeks ago I asked the net about the security of the
uucp/news system.  I received several responces to the query and
several requests for either a followup or results via mail.  There
were enough requests to facilitate a followup posting.

    Basically, every responce stated that UUCP was quite secure but
not airtight (what is?).  NETNEWS, as one can imagine, is very secure
in itself (but not TO itself, news articles can and are easily forged),
but does all it's work via UUCP.  Several points were mentioned and
are summerized below:

    1) Call out.  Don't let anyone call you.  It is easy to forge
       a system name (once you know it!) to uucico.

    2) Call only sites you trust.  Once the system you call has
       been validated, it has access to your system...even if
       uucico isn't a very user friendly shell, it's still
       running on YOUR system.

    3) Naturally, restrict UUCP access.  This means letting only
       the bare essentials be run by UUXQT.  An L.cmds file that
       contains only rmail, rnews, cunbatch and uusend (or even
       less, depending on your configuration).  Make SURE there
       are no programs in your L.cmds file that allow shell escapes!
       Make sure all the protections are correct.  In the USERFILE,
       restrict the path for copying via UUCP.

    There were other things mentioned which I know less about.  A
mention was made reguarding the use of a sequence verifier to
acknowledge logins.  In the manual _System Administration for the
Sun Workstation_ there is a reference to this feature but not
a description of how to use it.  In any case, if a login fails
during transmission, the sequence numbers become unsynced and
have to be reset MANUALLY.  The manual says, "Note that this
feature is rarely used."  I can see why.
    
    Another feature that can be used if desired is the use of
callback during uucp verification.  To use this, an entry is
made in the USERFILE between the system name and the allowable
path.  For example, a line like "joe,blow c /usr/spool/uucppub"
would allow machine "blow" to log in to account "joe" and then
the local machine would hang up and call "joe" back.

    If these precautions are followed, it would appear that the
system is pretty secure.  The main consideration is that of
calling.  If no one calls you, there is no dial-in threat as there
is no getty running on the dial lines.  Lucky that everyone isn't
as self-conscious as we are or no one would allow call-in!

    A mention was made of "honeydanber UUCP".  I don't know what
it is.  It was mentioned as a secure version of UUCP.  Try
talking to Tom Kessler about this as he was one who mentioned it.

    Finally, there are a couple of books that may be of some help
when they are released.  Dave Fiedler said he was just finishing
a book on Unix system administration with a chapter on security,
however, it won't cover 4.2.  He also mentioned that Hayden is
coming out with a book JUST on security.  There is also a security
mailing list that one can join.

    Well, that's about it.  Here is a list of people that may be able
to supply you with further information, or you can ask me (only about
4.2 please).  Thanks to all that responded, but we decided to hire
a security guard armed with a pair of wire cutters next to the dial
line running a "tail -f /usr/spool/uucp/LOGFILE" on his security
console (must credit Tom Kessler for the idea).


Dave Fiedler
	-->  {harpo,astrovax,whuxcc,clyde}!infopro!dave

Tom Kessler
	-->  {allegra,seismo}!rochester!ur-laser!tomk

Chuq Von Rospach
	-->  {decwrl,hplabs,ihnp4}!nsc!chuqui

Gene Spafford
	-->  seismo!gatech!spaf

Security mailing list request
	-->  denelcor!denelvx!sec-request


-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
-								-
- UUCP:						Matt Goheen	-
-    ...{allegra,seismo}!rochester!srs!matt	S.R. Systems	-
-						Rochester, NY	-
-								-
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-



More information about the Comp.unix.wizards mailing list