celozzi@tron.UUCP (Dominic J Celozzi) (02/18/88)
Wanted: information concerning security of usenet and uucp connections. In particular, consider the following scenario: VAX running Ultrix 2.0 dial-out uucp connections only polls newsfeed once daily Questions: 1) What access (if any) do outsiders have to local system (ie. can they request files on system such as /etc/password) 2) How secure is uucp security - ie USERFILE and L.cmds Can anyone get around them from a remote system? 3) Can "intruders" be traced? Do facilities exist to monitor bad attempts of logging into a Unix system? 4) How secure is the software which implements the exclusions mentioned above (as well as others related)? 5) How can we audit these events? 6) Is there a methodology for auditing local users activity to remote sites - especially over usenet? 7) What facilities/manuals should be examined to ensure security? Please do not begin a discussion concerning the theoretical history of unix vs. "secure" systems. I am only interested in practical applications / practices which will aid in the monitoring of outgoing/incoming activities, as well as those which raise might raise concern to the security guys. Thank you for your cooperation, Dominic J Celozzi UUCP-Path: uunet!umbc3!tron!celozzi
mikel@codas.att.com (Mikel Manitius) (02/21/88)
In article <108@tron.UUCP>, celozzi@tron.UUCP (Dominic J Celozzi) writes: > > Wanted: information concerning security of usenet and uucp connections. Very simple, if you've got a UNIX machine with a modem, it's not secure. -- Mikel Manitius mikel@codas.att.com
daveb@geac.UUCP (David Collier-Brown) (02/21/88)
In article <108@tron.UUCP>, celozzi@tron.UUCP (Dominic J Celozzi) writes: >> Wanted: information concerning security of usenet and uucp connections. In article <2739@codas.att.com> mikel@codas.att.com (Mikel Manitius) writes: >Very simple, if you've got a UNIX machine with a modem, it's not secure. To be a bit more specific (:-)), if you have a normal unix system providing mail which takes the site!site!name notation, you are subject to having the forwarding mechanism ship all sorts of "interesting" things through, and if your normal uucp "security" has been reduced below the default for reasons of usability, you can find yourself executing a virus.. A C-secure unix is no help here: you need a B- or C-secure machine, and a secure communications processor (the A-secure gutted Unix of yore). Uucp is formally insecure. --dave ps: the letters refer to a US security standard. B means your are resistant to penetration and have a second, separate set of non-overridable file permissions (as a minimum). C is less so, and D means "you flunked". -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
kurt@hi.unm.edu (Kurt Zeilenga) (02/22/88)
In article <2739@codas.att.com> mikel@codas.att.com (Mikel Manitius) writes: >In article <108@tron.UUCP>, celozzi@tron.UUCP (Dominic J Celozzi) writes: >> >> Wanted: information concerning security of usenet and uucp connections. > >Very simple, if you've got a UNIX machine with a modem, it's not secure. It's simplier than that. If you got a UNIX machine and it's turned on, it's not secure. :*D >-- > Mikel Manitius > mikel@codas.att.com -- Kurt (zeilenga@hc.dspo.gov)
bzs@bu-cs.BU.EDU (Barry Shein) (02/22/88)
>>Very simple, if you've got a UNIX machine with a modem, it's not secure. >It's simplier than that. If you got a UNIX machine and it's turned >on, it's not secure. :*D That's worse, to boot it single-user you usually turn it off first, -B
trb@ima.ISC.COM (Andrew Tannenbaum) (02/25/88)
I'll address dial-in security and uucp security here.
I don't quite know what usenet security problem is in question.
It's wise to buy a cheap UNIX box and make it your uucp/mail/news
gateway. Don't put any vital info on the machine, and you'll have
nothing to lose. If you are concerned about security, the minimal
expense will we well invested. Connect the gateway to your work
machines with ethernet, and remove any dangerous programs (like rlogin,
for instance) from the gateway machine. If you're serious about
security, you don't put phones on your machine. With the cost of
hardware and the cost of security these days, it's silly to put
uucp lines on a machine that you are worried about.
uucp systems other than BNU (aka honey danber, or the latest AT&T
uucp) use USERFILE, which, while it may be used to restrict access
to remote users, is hard to customize on a per system/per user basis.
The code and documentation is arcane, and has been rewritten many times
by many people in an attempt to get it to work.
You longtime uucp users might say "it works for me..." I suggest that
you spend some time fiddling with the USERFILE setting up different
sites and users at different levels of security, and read the chkpth()
code, and see how goofy it is. It might work in 4.3bsd, but in
general, USERFILE processing is buggy, and most sites simply put
, /
or
, /usr/spool/uucp
in there. Actually, I think ", /" doesn't work in most older uucp's, you
have to put the line in twice because of weird parsing problems with null
USERFILE descriptors.
The BNU Permissions file takes some getting used to. It's more verbose,
more flexible, and cleaner. The Permissions file has been one of the major
selling points for BNU uucp. I have never had a problem bringing up
BNU under new UNIX system, AT&T or BSD based.
If you don't have dial-ins, you don't have intruders logging in over
them. Assuming you want uucp dial-ins, there is a way to make them
quite secure. (I learned this method from Brian Redman - ber of honey
danber fame.) Hack up a copy of login that only allows uucp's to log
in, and only forks uucico. You could post your /etc/passwd to usenet,
and no one would be able to log in over those uucp-only lines. It
would be wise to keep your user dial-in phone numbers secret ("security
through obscurity," as I've heard Karl Heuer, the Walking Lint, call
it). Segregating your user dial-ins from your uucp dial-ins only
involves the base cost of phone lines, it isn't changing the i/o load
any.
It's a good idea to give your uucp dial-in users separate /etc/passwd
entries. This makes it easier to monitor per-user access, both using
the uucp log files and the "last" command to peruse the wtmp records.
If you want to monitor use of uucp or netnews posting, you can use the
log files provided by these systems, or if you find them unsatisfactory,
you can easily write front-end shell scripts to provide your own
logging.
Andrew Tannenbaum Interactive Boston, MA +1 617 247 1155csg@pyramid.pyramid.com (Carl S. Gutekunst) (02/25/88)
Bravo, Andy! Concise, complete, and correct. Just some comments: In article <893@ima.ISC.COM> trb@ima.UUCP (Andrew Tannenbaum) writes: >Actually, I think ", /" doesn't work in most older uucp's, you have to put >the line in twice because of weird parsing problems with null USERFILE >descriptors. Correct. That problem was finally fixed in Tom Truscott's late 4.2BSD version, and is still present in many BSD-based systems, including Sun. For more info, see the 4.3BSD USERFILE(5) man page. >The Permissions file has been one of the major selling points for BNU uucp. The security features of BNU/HDB are *THE* selling point, in my opinion. The 4.3BSD UUCP is nearly the equal of HDB in many repects, and the newest version will be superior in many. But when it comes to security, HDB reigns surpreme and will for the forseeable future. Any site that plans to use UUCP and wants to be secure should be running HDB. <csg>
rob@philabs.Philips.Com (Rob Robertson) (02/27/88)
In article <15477@pyramid.pyramid.com> csg@pyramid.UUCP (Carl S. Gutekunst) writes: >The security features of BNU/HDB are *THE* selling point, in my opinion. The >4.3BSD UUCP is nearly the equal of HDB in many repects, and the newest version >will be superior in many. But when it comes to security, HDB reigns surpreme >and will for the forseeable future. Any site that plans to use UUCP and wants >to be secure should be running HDB. older versions of HDB have a hole whereby clever hackers CAN manage to get a shell. honest rob -- william robertson rob@philabs.philips.com