Usenet Security

[Doug Blair]

Dominic:

I sent this to you via email, but afterwords I realized
that I'd written a small book! :-) Perhaps this information
will be helpful to other new installations on the net, so I'm
posting it as well. I don't claim that all this is 100% applicable
to your situation butr it should get you started.

> Wanted: information concerning security of usenet and uucp connections.

One of the best discussions around on this is found in the book:
Unix Communications by The Waite Group. It's a Howard Sams book for
about $20.00.  Same price range is Unix System Administration by
David Fielder and Bruce Hunter. Both should be in any major chain-
type bookstore (B. Dalton, Walden Books, etc) that has a computer
book depoartment.  We faced many of these problems in setting up
our unix and after digesting these books felt we had a good grasp
of the problems.

> Questions: 1) What access (if any) do outsiders have to local system
> 	      (ie. can they request files on system such as 
> 			     /etc/password)

Outside users can only do what you allow them to do. To restrict
individual's access you must change the permissions on sensitive
files or perhaps make them login in a restricted shell like rsh.

Outside systems can only execute a few selected commands (which
are stored in /usr/lib/uucp/Permissions under HDB on our system).
I think the corresponding file is L.cmds in non-HDB systems. Usually
these are limited to rnews, rmail and lp. HDB allows you to
specify which systems can execute which other commands you want to
allow, if any.

Under normal conditions outside systems, even those that login with
a "generic id" like nuucp, can only request or send files to the
/usr/spool/uucppublic directories. Those files must first be put
there by a command on your local system like uuto, so unless one
of your users puts the passwd file there intentionally it's pretty
solid.

> 	   2) How secure is uucp security - ie USERFILE and L.cmds
> 	      Can anyone get around them from a remote system?

It's important to realize the difference between a remote system
and a remote user - someone logged in from an outside site. If
one of your normal users loses their passwords then a nasty
human can log in and do all the things the regular user can do.
The best way to fight this kind of loss seems to be in enforce
password aging and make LOTS of REGULAR backup files.  Such a
bad guy appears the same wether logged in via terminal or
via cu or tip from another computer.

The only normal linkage between your computer system and another
is one that you set up youself - usually uucp. We are interconnected
with only three other sites for unattended operation of our system.
None of these has given the others permission to request any kind
of job on our system other than rnews and rmail, so even if a
user on one of those systems examines their phone number and
password files to determine how their machine logs into ours, the
only thing they could do is send us news or mail.  Once the
machine login has been used the tty comes up in a different
shell: uucico instead of sh, csh or ksh.  uucico's activities
are limited to the commands in the Permissions file and the
publlic directories.

> 	   3) Can "intruders" be traced?  Do facilities exist to monitor
> 	      bad attempts of logging into a Unix system?

I've forgotten (OK, deleted the line) if you're a ucb site. The lastlog
file will give you an idea of how often a login is being used (a non-
machine login at 2am is unusual, right?).  You can run a short script
from cron to see who's logged in and what they're doing every 5-10
minutes, sort and grep this to find something unusual, but even the
most sophisticated systems can't do anything more than determine which
login is being used for unauthorized activity - you still have no
way of finding out who is using the terminal associated with the
login.

Yes, you can monitor bad login attempts. The standard login program
does not, but there is a public domain modified version of login
that I've seen posted to the net for use on public access unix
systems such as chinet.  This program writes all of the data associated
with any login not successful on the first attempt to a logfile
which you can later review.  Any attempt to login unsuccessfully
several times in succession using the same user id can be trapped
and a "Sorry" message sent to the terminal (this by way of
apologising to the person who has forgotten their password). I know
the source is on chinet and can sent it to you....

> 	   4) How secure is the software which implements the exclusions
> 	      mentioned above (as well as others related)?

You'll have to look at the sourcecode and judge for yourself.

> 	   5) How can we audit these events?

See above

> 	   6) Is there a methodology for auditing local users activity to
> 	      remote sites - especially over usenet?

usenet is a collection of programs which does nothing more than transfer
news articles around the net - this via uucp.  So the uucp monitoring
facilities will indicate how much traffic is going on.  The uulog
program dumps a log of the systems called, size of files sent, owners
of these files, times sent and so forth, but doesn't normally show
the type of content of those files.  This can be used to estimate
wether files are news articles (because the owner would be the owner
of postnews, usually news or usenet), mailed replys to articles (owned
by individual users) or machine to machine transfers (owned by the
machine's login).

The uulog file will also show attempts to execute programs from
remote sites (with messages like "/usr/bin/cu attempted - access to
remote file system denied").

It is important to remember that your machine is only connected
to neighboring machines - so any command it gets only works if you've
said it can do so in your Permissions file.  uulog will document
all such attempts.

> 	   7) What facilities/manuals should be examined to ensure security?

Virtually ALL of a normal (ie: non-defense-department-super-secret) unix
installation's security problems can be resolved by addressing PHYSICAL
security: don't let anyone see your password, never leave a terminal
while logged in, lock the door to your office on your lunch hour, never
write your passowrd in your wallet, change passwords frequently, etc etc.

The next issue (after access to terminals and logins) is restricting
access to sensitive data - payrolls, acedemic records, manuscripts,
engineering data, etc.  I think the user-group-world permissions do
a fair job of this for most small/medium business installations and
most academic situations. 

There are lots of books on system security which tell you of the
obvious loopholes (like getting an unrestricted shell via the !
shell escape in vi) which you should read but I think the most
overlooked loophole is the number of people to whom you give
permission to become superuser for a quick "just this one time
because I'm not at my terminal" kind of job. I was amazed at the
number of times I did this in my first two months.  TGhe tasks
accomplished by superuser and root logins are special enough to
only be done by one or two people.  That's WHY unix systems have
system administrators.

There you have it - some secure thoughts from a budding unix
administrator!  Hope this helps....

Doug Blair
---

-- 
===============================================================================
| Doug Blair                                  ... ihnp4!laidbak!obdient!blair |
|               "I'm not a Consultant, but I play one on TV."                 |
| Obedient Software Corporation,  1007 Naperville Road,   Wheaton, IL   60187 |
===============================================================================