bill@carpet.WLK.COM (Bill Kennedy) (10/03/88)
One of my neighbor sites was recently vandalized by an electronic
intruder. That puts my site in some jeopardy because one of the
files compromised was the uucp Systems file. My site was similarly
vandalized a year or so ago and for all I know the intruder that
attacked my neighbor got the info from my system :-(
I would like to know if one or more of the more seasoned System
Administrators could post some preventative measures that those of
us with less experience could use. I'm aware that there's little
to protect you from an expert renegade, but I mean the sorts of
things to keep out a journeyman prowler.
On my system, for example, I did not have my root crontab restricted
enough and that's how the intruder got root privileges. I'm as
puzzled today as I was shocked when it happened. Further, I am not
asking for anything that would make it easier for a malicious reader
to become an intruder, just a general check up kind of thing, what
things can have setuid, what shouldn't, what kinds of permissions
should be on the contents of certain directories, etc. Yes, please
even include the obvious like "guest" accounts, I'll bet there are
still some around.
I'm looking forward (and I'll bet a lot more of the greener SA's) to
reading your recommendations. Thanks!
--
Bill Kennedy Internet: bill@ssbn.WLK.COM
Usenet: { killer | att | rutgers | uunet!bigtex }!ssbn!billmohamed@hscfvax.harvard.edu (Mohamed Ellozy) (10/03/88)
In article <167@carpet.WLK.COM> bill@carpet.WLK.COM (Bill Kennedy) writes: > >I would like to know if one or more of the more seasoned System >Administrators could post some preventative measures that those of >us with less experience could use. I'm aware that there's little >to protect you from an expert renegade, but I mean the sorts of >things to keep out a journeyman prowler. > Read the article by Grampp and Morris in the October 1984 UNIX issue of the AT&T Bell Laboratories Technical Journal, then the book byWood and Kochan entitled UNIX Sytem Security (Hayden Books, 1985, ISBN 0-8104-6267-2.
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (10/03/88)
I've found that Pat Wood's _UNIX System Security_, while SysV-intensive, is nonetheless a very good all-around sort of guide to the more common but not necessarily obvious problems of keeping your system buttoned down tight. Find a copy; I last saw it (right after publication, I think) about 2 years ago - should be readily findable in most computer-related bookstores. It'll give you a good outlook, a mindset suited to detecting those sorts of problems. --Karl
spaf@cs.purdue.edu (Gene Spafford) (10/03/88)
Here's a very rough list of things to check:
1) make sure / /bin /usr /usr/bin /etc /usr/spool
and any other bin directories are all mode 755 or less (ie, 555,
751, etc).
2) Allow NO accounts without passwords, including uucp.
3) Don't have any accounts other than root with uid 0
4) Make sure no files in any bin or /etc are writeable by anyone
other than user root (or bin, if you have things set up that way --
if you do, don't have bin's entry in /etc/passwd with a
runnable shell or password).
5) crontab, mem, kmem, uucp/L.sys should not be readable by
world. Crontab should probably be mode 600. The rest should
be something like 440. Programs that read kmem to display
status should be setGid to some group (named, kmem, for instance).
6) On many systems, "at" is a security hole. If no one uses it,
disable it.
7) Don't run anything out of crontab as root unless you absolutely
must. For instance, to run the nightly news scripts, use "su"
in the crontab file to run the scripts as user news.
E.g.,
40 1 0 0 0 su news </usr/lib/news/nightly
8) Keep a list of all setuid/setgid files on your system (use
"find", for instance). Keep the list off-line. Recheck it
periodically and see if any files have changed size or modification
time (or had those bits added or deleted).
9) If your system logs bad login attempts to the console, or
bad attempts to change passwords, then be sure to audit your
logs -- frequently!
10) On BSD systems, don't have any setuid/setgid shell scripts --
unless you know that the security hole with them has been fixed
on your system.
11) Don't have the "." directory in the PATH variable for root
or for any privileged user.
12) Don't have any special versions of "su" around that don't
require a password.
13) If you're running in an NFS environment, don't have
any workstations located where untrusted individuals can
reboot them.
None of these is hard and fast "must do's", but if you don't
understand why I recommend them, you probably shouldn't
avoid them. I know how to use all but 8 & 9 to break into
systems, and I am certainly not the only one. There are other
considerations, but they are more specific and might give
clues to someone wanting to know how to break into a system,
so I won't go into detail here.
--
Gene Spafford
NSF/Purdue/U of Florida Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spafziegler@lznv.ATT.COM (J.ZIEGLER) (10/04/88)
In article <167@carpet.WLK.COM>, bill@carpet.WLK.COM (Bill Kennedy) writes: > I would like to know if one or more of the more seasoned System > Administrators could post some preventative measures that those of > us with less experience could use. Please, please, please!! Anyone with knowledge enough to answer this question, DO NOT POST IT TO THE NET!!!! Electronic mail and net postings are grossly inappropriate places to discuss security. If you have recommendations about books or articles to read, those can be posted. Specific recommendations should be communicated in person or by telephone. Hackers do not need encouragement or challenges, much less the helpful hints that such responses would undoubtedly contain. 'Nuff said. Joe Ziegler AT&T Bell Laboratories att!lznv!ziegler The opinions expressed are the explicit policy of my company.
peo@pinocchio.Encore.COM (Paul Orman) (10/04/88)
bill@carpet.WLK.COM (Bill Kennedy) writes: > I would like to know if one or more of the more seasoned System > Administrators could post some preventative measures that those of > us with less experience could use. I'm aware that there's little > to protect you from an expert renegade, but I mean the sorts of > things to keep out a journeyman prowler. I certainly am not one of the "more seasoned System Administrators" but I do know a good place to start with system security is the: National Computer Security Center 9800 Savage Rd. Fort Meade, MD 20755-6000 301-688-8742 Call and ask for the "RAINBOW" package. This is slightly overkill since the NCSC normally sends this package out to hardware and software vendors wishing to have their products security "rated" by US Gov. standards and tons of the material deal with the security ratings, however it does have much information that can be applied directly to a UN*X based system. Other interesting reading on security issues would be "UNIX REVIEW" volume 6 number 2. Of special interest is the article "A loss of Innocence" by Patrick Wood. The information supplied in these sources should be more than enough to put together as secure a system as one desired (within present day limitations - of course). ............................................................................... Paul Orman - encore!peo | I don't know enough to speak for Sys Admin peo@multimax.ARPA | myself, let alone my employer. ENCORE Computer Corporation |
rfarris@serene.CTS.COM (Rick Farris) (10/04/88)
In article <167@carpet.WLK.COM> bill@carpet.WLK.COM (Bill Kennedy) writes: >One of my neighbor sites was recently vandalized by an electronic >intruder. >On my system, for example, I did not have my root crontab restricted >enough and that's how the intruder got root privileges. >Bill Kennedy Internet: bill@ssbn.WLK.COM Darn! That's clever. I'll bet they did a crontab -l to a file they could write, and then put a command in to copy L.sys to a file they would own, eh? Awesome. How does one deal with this? I'd also like to pick up some more security tips. I would like to allow more shell accounts on my system, but I'm worried about security. I understand the concern for security, is there a mailing list or something where we could discuss these issues? Rick Farris rfarris@serene.cts.com voice (619) 259-6793 POB M KCBIW public access 259-7757 Del Mar CA 92014 ...!uunet!serene!rfarris serene.uucp 259-3704
pmech@oucsace.cs.OHIOU.EDU (Paul J. Mech) (10/04/88)
In article <5014@medusa.cs.purdue.edu>, spaf@cs.purdue.edu (Gene Spafford) writes: > > 2) Allow NO accounts without passwords, including uucp. > One place to watch out for is that many systems come with a hardware-vendor maintainence uid, often with root permissions. I have broken into (in each case at the request of the system's owner) three separate systems (a VAX, a Tower, and an Isotron/OSI) with this approach, and if not granted root privileges immediately, gained root access within 5 min. This is a massive hole that frequently has not been clearly documented. Paul J. Mech
dpw@unisec.usi.com (Darryl P. Wagoner) (10/04/88)
In article <1454@lznv.ATT.COM> ziegler@lznv.ATT.COM (J.ZIEGLER) writes: >In article <167@carpet.WLK.COM>, bill@carpet.WLK.COM (Bill Kennedy) writes: > >Please, please, please!! Anyone with knowledge enough to answer >this question, DO NOT POST IT TO THE NET!!!! Electronic mail and >net postings are grossly inappropriate places to discuss security. Yes, this is very good advice and no matter what don't post info on security books like Unix System Security by Pat Wood; this would be a hackers guide to breaking in. So don't tell anyone about this book or others like it. :-) It will keep a lot of SA's in the dark while the hackers rape their systems. As more and more Unix boxs start to pop up there will be more and more novice SAs running them. At one time I could see the merit in this thinking, but that time has passed. I would say that there will be many more SAs out there that will be helped by this information than hackers that will learn how to break in. -- Darryl Wagoner dpw@unisec.usi.com UniSecure Systems, Inc.; OS/2, Just say No! Round Rock, Tx; (512)-255-8751 (home) (512)-823-3774 UUCP: {ut-sally!uiucuxc!kitty}!unisec!dpw
pmech@oucsace.cs.OHIOU.EDU (Paul J. Mech) (10/04/88)
In article <1454@lznv.ATT.COM>, ziegler@lznv.ATT.COM (J.ZIEGLER) writes: > > Please, please, please!! Anyone with knowledge enough to answer > this question, DO NOT POST IT TO THE NET!!!! Electronic mail and > net postings are grossly inappropriate places to discuss security. > You are of course correct. My news admin says that there is no way to stop my previous article. Appologies. pjm
merlyn@intelob.intel.com (Randal L. Schwartz @ Stonehenge) (10/04/88)
In article <5014@medusa.cs.purdue.edu>, spaf@cs (Gene Spafford) writes: | | Here's a very rough list of things to check: [...] | 9) If your system logs bad login attempts to the console, or | bad attempts to change passwords, then be sure to audit your | logs -- frequently! [...] | I know how to use all but 8 & 9 to break into | systems, and I am certainly not the only one. Arrgggh. No. If you have a feature that "logs bad login attempts to the console" TURN IT OFF. This is a *bad* *idea* (as Dave Barry would put it). This has been discussed in security circles, and even on this net, if I remember correctly. If you don't see how this is a bad idea, send me mail. I'll reply, mailers willing. Yours for a more secure future, -- Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 on contract to BiiN Technical Information Services (for now :-), in a former Intel building in Hillsboro, Oregon, USA <merlyn@intelob.intel.com> or ...!tektronix!inteloa[!intelob]!merlyn Standard disclaimer: I *am* my employer!
karl@ddsw1.MCS.COM (Karl Denninger) (10/05/88)
In article <1454@lznv.ATT.COM> ziegler@lznv.ATT.COM (J.ZIEGLER) writes: >Please, please, please!! Anyone with knowledge enough to answer >this question, DO NOT POST IT TO THE NET!!!! Electronic mail and >net postings are grossly inappropriate places to discuss security. Wrong Sir. Hackers already know these things. Novice admins don't. Who gets burned? Not the hacker. And few of their kind will be helped. The most important item in any type of preventative measure is _information_. The more information, the better. You can't plug a hole you don't know exists. Nearly _all_ holes can be effectively defused IF you know they exist. -- Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl) Data: [+1 312 566-8912], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality solutions at a fair price"
bill@ssbn.WLK.COM (Bill Kennedy) (10/05/88)
In article <1454@lznv.ATT.COM> ziegler@lznv.ATT.COM (J.ZIEGLER) writes: >In article <167@carpet.WLK.COM>, bill@carpet.WLK.COM (Bill Kennedy) writes: [ deleting what I wrote ] > >Please, please, please!! Anyone with knowledge enough to answer >this question, DO NOT POST IT TO THE NET!!!! Electronic mail and >net postings are grossly inappropriate places to discuss security. Darn it Joe, you're wrong, dead wrong! You're reacting as though we're publishing the latest technique. That's not what I asked and it's not what's coming back. Rather than just arbitrarily flog you, let me provide an example. Gene Spafford says that "at" can be a problem and if you don't need it, get rid of it. There's a world of difference between what he said and what I read from your article "For God's sake don't show 'em how to use `at' to crack" Not a bit. Gene, a generally accepted veteran says "if you don't need `at' get rid of it". I've been an SA for three years, I didn't know that, so I went and looked. Guess what? Gene's as dead right as you are dead wrong. Will I share the technique? Not on your life! BTW no one need try "at" at ssbn. >If you have recommendations about books or articles to read, those >can be posted. Specific recommendations should be communicated in >person or by telephone. That guarantees connectivity delays that could be moot before they were heard. Sorry Joe, the sky isn't falling (nor did you say it was). This is where the rubber meets the road and the articles and email I have collected thus far have been immensely useful. (small) flame on... You're representative of the paranoia that makes learning so difficult. Your remarks reinforce a comment (made in ironic jest) that UNIX is an "oral tradition". Don't look through a cellophane navel, those people are out there. I asked for some simple things to check. I got 'em, thousands of others did too. If it only triggered an awareness, I'm right are you're wrong. (small) flame off.. > Hackers do not need encouragement or >challenges, much less the helpful hints that such responses would >undoubtedly contain. 'Nuff said. > > Joe Ziegler > AT&T Bell Laboratories > att!lznv!ziegler > >The opinions expressed are the explicit policy of my company. I have seen nothing posted or in mail that even hinted at technique. I would be standing by your flagpole satuting with you if someone had said anything about "how". I asked "what", the responses are "what", 'Nuff said. Cheap shot on... In almost every response, posted or not, people say "NO ACCOUNTS WITH NO PASSWORD, NOT EVEN nuucp!" >The opinions expressed are the explicit policy of my company. Then why does your company have uucp logins without passwords? I agree with Jonathan (SA att-mt) that anyone could masquerade as anyone else, but dammit! Not without a valid password! Cheap shot off.. I took up space and bandwidth (rather a lot of it) to show the myopia that we have. My apologies to Joe, he didn't know he was waltzing into my minefield. What's more important is that he (Joe) is in the majority. He thinks it's *wrong* to think or talk about good security health. God love him, he has missed the entire point. We're *all* out here, we're *all* vulnerable. I welcome all the email I got, I'm preparing a summary for the net. The summary, like what I've read here so far, will contain no technique, just preventative medicine. -- Bill Kennedy usenet {killer,att,rutgers,sun!daver,uunet!bigtex}!ssbn!bill internet bill@ssbn.WLK.COM
peter@ficc.uu.net (Peter da Silva) (10/05/88)
There was a wonderful 18th Century document urging people not to keep a discussion of security or insecurity of locks secret posted to comp.risks recently. It might be worthwhile to repost it in this forum. "Rogues are very keen in their profession, and already know much more than we can teach them respecting their several kinds of roguery. Rogues knew a good deal about lockpicking long before locksmiths discussed it among them- selves, as they have lately done..." -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" peter@ficc.uu.net
spaf@cs.purdue.edu (Gene Spafford) (10/05/88)
In article <2968@mipos3.intel.com> merlyn@intelob.intel.com (Randal L. Schwartz @ Stonehenge) writes: >Arrgggh. No. If you have a feature that "logs bad login attempts to >the console" TURN IT OFF. This is a *bad* *idea* (as Dave Barry would >put it). This has been discussed in security circles, and even on >this net, if I remember correctly. The way it is often IMPLEMENTED it is a bad idea. The IDEA of auditing is standard security practice and the capability is a required part of getting a multi-level secure rating on an OS (B2 and above? I forget). If you don't know when someone is trying to break in, you can't take action against them -- maintaining an audit and reviewing it frequently is the only way to do this. For this kind of audit feature to not be misused, you must sure that no one other than a trusted individual (i.e., sysadmin) has any access to the console log. Of course, that is a good idea anyhow, since most system consoles allow the user to halt the machine and come back up single user. The only problem with logging bad attempts to the console is when someone mixes up and types their password for the account name. That happens infrequently, and if trusted personnel are the only ones to see the record, it isn't a problem -- especially if the notify the account holder that the password has been compromised. I stand by my recommendation. -- Gene Spafford NSF/Purdue/U of Florida Software Engineering Research Center, Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004 Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf
merlyn@intelob.intel.com (Randal L. Schwartz @ Stonehenge) (10/05/88)
In article <2968@mipos3.intel.com>, I wrote: | In article <5014@medusa.cs.purdue.edu>, spaf@cs (Gene Spafford) writes: | | | | Here's a very rough list of things to check: | [...] | | 9) If your system logs bad login attempts to the console, or | | bad attempts to change passwords, then be sure to audit your | | logs -- frequently! | [...] | | I know how to use all but 8 & 9 to break into | | systems, and I am certainly not the only one. | | Arrgggh. No. If you have a feature that "logs bad login attempts to | the console" TURN IT OFF. This is a *bad* *idea* (as Dave Barry would | put it). This has been discussed in security circles, and even on | this net, if I remember correctly. OK, enough people mailed me (hint: stop sending mail!!) saying "How?", and one person even said "If you were trying to keep this from bad guys by not posting, how do you know I am not a bad guy?" Good point. 4.3bsd for example logs just the username to the console. This would seem secure, but in all the times you have logged in, have you never-ever-ever because of network delays, or not paying attention, accidentally entered your password when it said "username"? THAT'S THE PROBLEM. Those that have looked into this have noticed that the "bad login" log almost always contains a valid password *in the clear* during any typical work day. Their conclusion: if a bad login log is maintained, it should have "login failed", but no username if not a valid username. Those that have said "my console log is in a secure place" are only slightly better off. Do you still want a piece of paper that is known to have hardcopy of at least one good password per day floating around the comp center? Enough rambling. Back to hacking with "at"... :-) -- Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 on contract to BiiN Technical Information Services (for now :-), in a former Intel building in Hillsboro, Oregon, USA <merlyn@intelob.intel.com> or ...!tektronix!inteloa[!intelob]!merlyn Standard disclaimer: I *am* my employer!
romkey@asylum.UUCP (John Romkey) (10/05/88)
In article <1454@lznv.ATT.COM> ziegler@lznv.ATT.COM (J.ZIEGLER) writes: >Please, please, please!! Anyone with knowledge enough to answer >this question, DO NOT POST IT TO THE NET!!!! Electronic mail and >net postings are grossly inappropriate places to discuss security. Security through obscurity does NOT work. Over and over again people have tried to protect their systems through ignorance. If the information exists anywhere, expect the crackers to find it. If it isn't written down, expect them to figure it out. It's amazing what you can do with a manual set, a bored mind and a terminal. By hiding this information you're not disadvantaging the serious crackers or even the semi-serious ones. You're only really hurting the system administrators who could use it to try to protect their systems. On the other hand, it would be pretty lame to just send a note in to net.* about the latest greatest way to break into 4.3 or VMS until a fix for it has been found and it has been communicated through some more subtle means. Also, while it's pretty reasonable to post guidelines about how to secure systems, people who follow these guidelines should also not believe their systems are really secure. If your system is connected to a network or is physically accessible, it's probably not secure. -- - john romkey UUCP: romkey@asylum.uucp ARPA: romkey@xx.lcs.mit.edu ...!ames!acornrc!asylum!romkey Telephone: (415) 594-9268
pjh@mccc.UUCP (Pete Holsberg) (10/06/88)
Could we stop calling those people who break in "hackers"? Let's not continue to support the public's gross misuse of that once-honorable appellation.
jhc@att.ATT.COM (Jonathan Hawbrook-Clark) (10/06/88)
In article <233@ssbn.WLK.COM> bill@ssbn.WLK.COM (Bill Kennedy) writes: >Then why does your company have uucp logins without passwords? I agree >with Jonathan (SA att-mt) that anyone could masquerade as anyone else, >but dammit! Not without a valid password! Actually this isn't true, we *do* have passwords on the nuucp login, it's just that we choose to finesse the entire login procedure and dump callers straight into the program they were going to invoke anyway. This is done partially in the name of security, and partially for convenience. The problem of having unique logins/passwords for each site boils down to one of key security. The security of having a key which is fairly widely known, held in cleartext, and never changed, is minimal. So we wouldn't trust it anyway. -- Jonathan Clark jonathan@mtune.att.com, attmail!jonathan Any affiliation is given for identification purposes only. The Englishman never enjoys himself except for some noble purpose.
ejnihill@sactoh0.UUCP (Eric J. Nihill) (10/06/88)
In article <1834@ddsw1.MCS.COM>, karl@ddsw1.MCS.COM (Karl Denninger) writes: > In article <1454@lznv.ATT.COM> ziegler@lznv.ATT.COM (J.ZIEGLER) writes: > >Please, please, please!! Anyone with knowledge enough to answer > >this question, DO NOT POST IT TO THE NET!!!! Electronic mail and > >net postings are grossly inappropriate places to discuss security. > > > The more information, the better. You can't plug a hole you don't know > exists. Nearly _all_ holes can be effectively defused IF you know they > exist. > As a SA , a fairly new SA, I would be interested in learning about what security leaks are out there. I am all to well aware that there are many on both sides of the fence with more knowledge than I and some are always wanting to prove it. However, the danger of posting it to the net is not that you will teach the knowledgeable, but may provide the missing link to those that are stymied by the current protection scheme of the system that they are on. I am for the distribution of knowledge, but only to the appropiate people. One way to do that would to be send out any request for security information via mail. Address ..foo!bar!root By sending to root only, you are putting a semi-control on the distribution. The "sysop, postmaster, etc." may not always be root. Yes, send me any information that you may think I should know regarding security, but send it to root. Eric ...pacbell!sactoh0!root -- ################################################################# # Sign In Triplicate before # Serving The State Capitol Of # # Discarding:________________ # California: sactoh0 # #################################################################
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (10/06/88)
>> I would like to know if one or more of the more seasoned System >> Administrators could post some preventative measures that those of >> us with less experience could use. > >Please, please, please!! Anyone with knowledge enough to answer >this question, DO NOT POST IT TO THE NET!!!! Electronic mail and >net postings are grossly inappropriate places to discuss security. > >If you have recommendations about books or articles to read, those >can be posted. Specific recommendations should be communicated in >person or by telephone. Hackers do not need encouragement or >challenges, much less the helpful hints that such responses would >undoubtedly contain. 'Nuff said. I've always wondered if perhaps the main proponents of this line of thinking were the hackers themselves. After all they have alternate methods of spreading this information among themselves, and it wouldn't do them any good to see the information be given to the many system administrators on the net. The discussion about this has taken place many times on the net. I believe that the current (?) concensus of opinion is to post enough information to allow people to fix their systems. This doesn't mean post cookbook recipes for breaking in, but fixes to known problems and how to avoid them. Also it put's vendors under much more pressure to fix problems expediently. -- Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532
mark@drd.UUCP (Mark Lawrence) (10/06/88)
Quoting something I've kept around and is now, again, apropo: From: Robert Mathiesen <SL500000%BROWNVM.BITNET@MITVMA.MIT.EDU> Subject: lockpicking Apropos of Randy D. Miller's surprise that information on lockpicking is so readily available, I cannot resist quoting Charles Tomlinson's Rudimentary Treatise on the Construction of Locks, published about 140 years ago. His words are also relevant to much of the discussion on computer security which has gone on in this Forum. "A commercial, and in some respects a social, doubt has been started within the last year or two, whether or not it is right to discuss so openly the security or insecurity of locks. Many well-meaning persons suppose that the discus- sion respecting the means for baffling the supposed safety of locks offers a premium for dishonesty, by showing others how to be dishonest. This is a fal- lacy. Rogues are very keen in their profession, and already know much more than we can teach them respecting their several kinds of roguery. Rogues knew a good deal about lockpicking long before locksmiths discussed it among them- selves, as they have lately done. If a lock -- let it have been made in what- ever country, or by whatever maker -- is not so inviolable as it has hitherto been deemed to be, surely it is in the interest of *honest* persons to know this fact, because the *dishonest* are tolerably certain to be the first to apply the knowledge practically; and the spread of knowledge is necessary to give fair play to those who might suffer by ignorance. It cannot be too ear- nestly urged, that an acquaintance with real facts will, in the end, be better for all parties. Some time ago, when the reading public was alarmed at being told how London milk is adulterated, timid persons deprecated the exposure, on the plea that it would give istructions in the art of adulterating milk; a vain fear -- milkmen knew all about it before, whether they practised it or not; and the exposure only taught purchasers the necessity of a little scrutiny and caution, leaving them to obey this necessity or not, as they pleased. ..... The unscrupulous have the command of much of this kind of knowledge without our aid; and there is moral and commercial justice in plac- ing on their guard those who might possibly suffer therefrom. We employ these stray expressions concerning adulteration, debasement, roguery, and so forth, simply as a mode of illustrating a principle -- the advantage of pub- licity. In respect to lock-making, there can scarcely be such a thing as dis- honesty of intention: the inventor produces a lock which he honestly thinks will possess such and such qualities; and he declares his belief to the world. If others differ from him in opinion concerning those qualities, it is open to them to say so; and the discussion, truthfully conducted, must lead to public advantage: the discussion stimulates curiosity, and curiosity stimu- lates invention. Nothing but a partial and limited view of the question could lead to the opinion that harm can result: if there be harm, it will be much more than counterbalanced by good." The subsequent development of lockmaking in the course of the next 140 years has long since demonstrated the correctness of Tomlinson's argument in his own field. I do not doubt that it is equally applicable in the area of com- puter security. -- DRD Corporation @ 5506 South Lewis | [uunet!apctrc,romed,tulsun]!drd!mark Tulsa, IT 74105 (918)743-3013 | mlawrence@jarsun1.ZONE1.COM
yba@arrow.bellcore.com (Mark Levine) (10/06/88)
In article <307@mccc.UUCP> pjh@mccc.UUCP (Pete Holsberg) writes: > >Could we stop calling those people who break in "hackers"? Let's not >continue to support the public's gross misuse of that once-honorable >appellation. Strongly seconded. Break-in artists are also called "crackers", but this also has a few time-honored traditional meanings. I don't know what the appropriate forum is, but if one can be suggested, I think the floor should be opened for nominations for "buzzword meaning intruder which the media finds acceptably catchy". Maybe ACM will adopt dissemination of same as part of their public relations charter. The appropriate choice should immediately imply a catchy phrase to describe the intruder's opposite number in the security business. Where to follow-up? Eleazor bar Shimon, once and future Carolingian yba@sabre.bellcore.com
dragon@trwspf.TRW.COM (Roger Vossler) (10/06/88)
In article <908@sword.bellcore.com> yba@sabre.bellcore.com (Mark Levine) writes: *In article <307@mccc.UUCP> pjh@mccc.UUCP (Pete Holsberg) writes: *> *>Could we stop calling those people who break in "hackers"? Let's not *>continue to support the public's gross misuse of that once-honorable *>appellation. * *Strongly seconded. Break-in artists are also called "crackers", but *this also has a few time-honored traditional meanings. I don't know *what the appropriate forum is, but if one can be suggested, I think the The last time I checked, people who exhibit the behavior known as "breaking and entering" were called "criminals". Since I was born and raised in Florida, "crackers" is not approporiate. I still maintain that "hacking" is an honorable activity. -- Roger Vossler BIX: rvossler dragon@trwspf.trw.com ...!trwrb!trwspf!dragon
nate@mipos2.intel.com (Nate Hess) (10/06/88)
In article <307@mccc.UUCP>, pjh@mccc (Pete Holsberg) writes: >Could we stop calling those people who break in "hackers"? Let's not >continue to support the public's gross misuse of that once-honorable >appellation. I agree. As an alternative that I would like to see the media pick up on, how about "cracker"? --woodstock -- "What I like is when you're looking and thinking and looking and thinking...and suddenly you wake up." - Hobbes woodstock@sc.intel.com ...!{decwrl|hplabs!oliveb|amd}!intelca!mipos3!nate
dhesi@bsu-cs.UUCP (Rahul Dhesi) (10/06/88)
There are numerous security bugs in /bin/cc, /bin/awk, /bin/login, and
/usr/lib/uucp/L.sys, to say nothing of /usr/lib/cpp. There are also a
number of security loopholes in all UNIX kernels on all systems. I
cannot tell you what these are, since this would allow people to break
into your system.
GET RID OF ALL THESE FILES! Delete your kernel too; it's probably in
/unix or /vmunix or some similarly-named file. If possible, just shut
your system down, or at least disable all logins. Switch to VAX/VMS if
necessary (but keep it in stand-alone mode, you never know what users
might do if you let them log in). Sorry, I just cannot afford to
explain further since this would seriously compromise the security of
every UNIX system anywhere. Nor am I willing to give any answers by
email, since I can't be sure that you aren't just a nasty intruder
trying to get into my system.
P.S. This is a joke. Actually, not a joke, it's too pathetic to be
funny. It's a little satire on these constantly-appearing suggestions
that are so vague as to be meaningless. Not directed at any one
person.
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesiziegler@lznv.ATT.COM (J.ZIEGLER) (10/07/88)
I'm tired of flames in my mailbox. What I said was simply that news postings and email are inappropriate places for discussing security. I DID NOT SAY THAT SUCH THINGS SHOULD NOT BE DISCUSSED OPENLY. There are three main problems that I see with discussing such things via news or email: 1) Not everyone who posts responses is knowledgeable about computer security, including many of those who think they are. Some of the advice will be wrong, and could lead to less security, not more. It is not possible to police this, so your best approach as a sysadmin is to ignore any security advice from someone you don't know and trust. 2) Such communications methods are not secure, and correct information could be modified in transit such that the recipient is not getting valid advice, but is being misled. See above. This applies even if you are mailing to root, as someone suggested, so I don't recommend that approach. 3) Not all sysadmins are competent, and certainly not all of them read the net. You have to weigh the expected advantage of posting such information against the expected disadvantage. I'm afraid that many more "crackers" than sysadmins will be reading the net, and I quite frankly don't want to give them ANY assistance whatsoever. If I felt that a net posting would prevent far more breakins than it would cause, I would be all for it. At this particular point in time, I believe just the opposite to be true. I do not advocate, nor have I ever advocated, secrecy and ignorance as a method of computer security. I know that it doesn't work. My goal is to protect the innocent and avoid helping the guilty. It appears that my previous posting was in fact not "'Nuff said". I hope this is. If you wish to discuss the philosophy of discussing security with me, send me email, don't clog the net. And don't bother flaming me. I won't answer. Joe Ziegler AT&T Bell Laboratories Lincroft, New Jersey (201) 576-2945 att!lznv!ziegler
lkw@csun.edu (Larry Wake) (10/07/88)
The call has gone out to promote a new term for "the media" to use when
referring to system intruders. Most of the traditional names have
various drawbacks:
hacker: Besides being a once-honorable term for those who grind,
the general public already uses this word to refer to
golfers. Even with their similar taste in clothes, it's
still easy to distinguish the two groups, as golf typically
involves spending at least brief periods of time outdoors.
Also, for silly plastic clothing accessories, golfers prefer
green plastic eyeshades to pocket protectors.
cracker: Really only accurate if they're breaking into systems at the
Bank of Atlanta or BellSouth.
syscrack: Bleah. Do *you* really want to say this? It's at least as
bad as "sysadmin" or "sysop."
asshole: Satisfying, yes. Accurate, yes. But it won't get you
quoted in Newsweek or USA Today (aka "McPaper" or "My Daily
Reader"). If you're looking to get published in the latter
paper, you should instead provide a cute line drawing of a
stick figure with devil's horns placing a bundle of
dynamite sticks under a tape drive or a card sorter.
I'm holding out for "bad guy," a la Morris and Thompson. It's accurate,
pithy, yet obscure enough to sound like real computeroid jargon.
--
Larry Wake lkw@csun.edu
CSUN Computer Center uucp: {hplabs,rdlvax}!csun!lkw
Mail Drop CCAD sun!tsunami!valley!csun!lkw
Northridge, CA 91330 BITnet: LKW@CALSTATEjack@swlabs.UUCP (Jack Bonn) (10/08/88)
In article <2975@mipos3.intel.com> merlyn@intelob.intel.com (Randal L. Schwartz @ Stonehenge) writes: >4.3bsd for example logs just the username to the console. This would >seem secure, but in all the times you have logged in, have you >never-ever-ever because of network delays, or not paying attention, >accidentally entered your password when it said "username"? THAT'S >THE PROBLEM. Those that have looked into this have noticed that the >"bad login" log almost always contains a valid password *in the clear* >during any typical work day. Maybe this is a little too simple minded, but why not just log failed attempts to valid usernames? This could even be kept online with universal read permission, since there would be nothing to hide here. Then, with proper tools, a list of those usernames which have failures above a certain threshold (maybe "1") could be identified as potential targets and could be periodically mailed to the administrator. Mail seems to be tougher to ignore than a console log. -- Jack Bonn, <> Software Labs, Ltd, Box 451, Easton CT 06612 uunet!swlabs!jack (UUCP) jack%swlabs.uucp@uunet.uu.net (INTERNET)
dave@lsuc.uucp (David Sherman) (10/10/88)
In article <2316@att.ATT.COM> jhc@att.ATT.COM (Jonathan Hawbrook-Clark) writes: >In article <233@ssbn.WLK.COM> bill@ssbn.WLK.COM (Bill Kennedy) writes: >>Then why does your company have uucp logins without passwords? I agree >>with Jonathan (SA att-mt) that anyone could masquerade as anyone else, >>but dammit! Not without a valid password! > >The problem of having unique logins/passwords for each site boils >down to one of key security. The security of having a key which is >fairly widely known, held in cleartext, and never changed, is >minimal. So we wouldn't trust it anyway. As I have indicated in private mail to jhc, following the discussion in comp.mail.uucp, the above argument is simply wrong. If there are individual logins and passwords, then the key is NOT "fairly widely known". It exists in exactly ONE place, namely the L.sys file of the uucp neighbour. If the neighbour's security is compromised, then the neighbour has to worry about all kinds of things, of which the possibility of someone calling att to pick up mail is pretty trivial. So far the only argument I have heard from AT&T to justify not having separate logins and passwords is that there would be some administrative cost to setting this up. Since it could be assisted with shell scripts, and since "att" is THE gateway into a giant organization, I do not consider this to be justification for a policy which deliberately slows down the passage of uucp traffic emanating from AT&T. (The policy is the policy of not sending mail unless they call you.) David Sherman The Law Society of Upper Canada -- { uunet!attcan att pyramid!utai utzoo } !lsuc!dave
dave@galaxia.zone1.com (David H. Brierley) (10/11/88)
In article <2985@mipos3.intel.com> woodstock@sc.intel.com (Nate Hess) writes: >In article <307@mccc.UUCP>, pjh@mccc (Pete Holsberg) writes: >>Could we stop calling those people who break in "hackers"? Let's not >>continue to support the public's gross misuse of that once-honorable >>appellation. > >I agree. As an alternative that I would like to see the media pick up >on, how about "cracker"? Why do we need to make up words to add to our already overburdened language when there are many existing words that are perfectly applicable for these people? Instead of calling them "hackers", which many of us regard as a title of some esteem, and instead of trying to get the media to call them "crackers", which brings to mind someone that is mentally unbalanced, how about choosing any of the words from the following list: criminal, hoodlum, thief, burgular, vandal, terrorist, etc. Obviously, not all of the words apply in all cases. For example, it is stretching the point to call a teenager, who is just attempting to show of to his or her friends and has no intention of causing harm to your system or any of the information stored on your system, a terrorist. On the other hand, if you detect a break-in on your machine would you assume that it was "just a kid" or would you assume that it was a vandal/terrorist/industrial spy. I know that I would assume the worst. -- David H. Brierley Home: dave@galaxia.zone1.com ...!rayssd!galaxia!dave Work: dhb@rayssd.ray.com {sun,decuac,gatech,necntc,ukma}!rayssd!dhb
nevin1@ihlpb.ATT.COM (Liber) (10/12/88)
In article <1458@lznv.ATT.COM> ziegler@lznv.ATT.COM (J.ZIEGLER) writes: |What I said was simply that |news postings and email are inappropriate places for discussing |security. And in the same article, he writes: | 2) Such communications methods are not secure, and | correct information could be modified in transit | such that the recipient is not getting valid | advice, but is being misled. This sounds like a security problem. Why did you post it to the net?? Aren't you going against your own advice?? Seems a bit ironic, doesn't it? -- _ __ NEVIN J. LIBER ..!att!ihlpb!nevin1 (312) 979-4751 IH 4F-410 ' ) ) "I catch him with a left hook. He eels over. It was a fluke, but there / / _ , __o ____ he was, lying on the deck, flat as a mackerel - kelpless!" / (_</_\/ <__/ / <_ As far as I know, these are NOT the opinions of AT&T.
john@frog.UUCP (John Woods) (10/13/88)
In article <2985@mipos3.intel.com>, nate@mipos2.intel.com (Nate Hess) writes: > In article <307@mccc.UUCP>, pjh@mccc (Pete Holsberg) writes: > >Could we stop calling those people who break in "hackers"? Let's not > >continue to support the public's gross misuse of that once-honorable > >appellation. > I agree. As an alternative that I would like to see the media pick up > on, how about "cracker"? The real problem is that horrible little children read third-hand accounts of someone's discovery of an interesting security flaw, breaks into someone's computer with it, and brands themselves a "hacker" in the belief that they somehow understand something. The ``hackers'' stole the term away from those who sought understanding (the original hackers), and they told the media their self-chosen appellation. I think the only solution is to choose a new name for Real Hackers. How about Roz Chast's suggestion of "Data Stylist"? -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu Goooooood Morning Discovery! -Robin Williams Abracadabra, 'press to MECO', America is back in space!
peter@ficc.uu.net (Peter da Silva) (10/14/88)
In article <1218@X.UUCP>, john@frog.UUCP (John Woods) writes: > I think the only solution is to choose a new name for Real Hackers. How about > Roz Chast's suggestion of "Data Stylist"? Wheel, wizard, guru, firefighter, cybernetic entomologist, language-lawyer, and so on are all in use. Pick whichever one best fits your case, or use one of the ones I forgot. I like guru myself. But "Data Stylist"? That sounds like a bad joke from "Robotman". GURU MEDITATION #80000004.0001B304 -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" peter@ficc.uu.net
jim@eda.com (Jim Budler) (10/17/88)
In article <1218@X.UUCP> john@frog.UUCP (John Woods) writes: >In article <2985@mipos3.intel.com>, nate@mipos2.intel.com (Nate Hess) writes: >> In article <307@mccc.UUCP>, pjh@mccc (Pete Holsberg) writes: >> >Could we stop calling those people who break in "hackers"? Let's not >> >continue to support the public's gross misuse of that once-honorable >> >appellation. I agree, but... (see below) >somehow understand something. The ``hackers'' stole the term away from those >who sought understanding (the original hackers), and they told the media their >self-chosen appellation. I'm afraid that the term 'hackers' has gone the way of the term 'celophane'. To continue to fight it would be as futile as 3M continuing to use Celophane as if it were a trademark. >I think the only solution is to choose a new name for Real Hackers. How about I agree completely. >Roz Chast's suggestion of "Data Stylist"? Ugh! Come on!!! Do you call a garbageman a 'Sanitation Engineer'? Ooops, not a very good comparison. Its late, I can't think of a better one. To make it in media you have to have short, simple, *non-elitist* labels. Like Ham, Hacker (sorry), etc. Before I went with Data Stylist, I would go for: Data Ham (maybe with ARRL approval?) Bit Ham (maybe with ARRL approval?) Data Spam :-) Bit Spam :-) {Data,Bit,} Munger Nerd (sorry, but today it has better media connotations, see various TV shows and movies) I certainly don't know... >John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 > Goooooood Morning Discovery! -Robin Williams Hey, yeah, good morning Robin! That astronaut (female) who was responsible for the media, etc. and managed to think of, much less accomplish, the idea of having Robin Williams call out good morning to the astronauts is one *great* imaginative thinker. I know, wrong newsgroup, but I can't resist: HOORAY Discovery. -- uucp: {decwrl,uunet}!eda!jim Jim Budler internet: jim@eda.com EDA Systems, Inc.
todd@nmtsun.nmt.edu (Todd/Dr. Nethack) (10/23/88)
In article <1834@ddsw1.MCS.COM> karl@ddsw1.UUCP (Karl Denninger) writes: >In article <1454@lznv.ATT.COM> ziegler@lznv.ATT.COM (J.ZIEGLER) writes: >>Please, please, please!! Anyone with knowledge enough to answer >>this question, DO NOT POST IT TO THE NET!!!! Electronic mail and >>net postings are grossly inappropriate places to discuss security. > >Wrong Sir. >Wrong sir.. I will disagree strongly with that.. There are many system admins. who have no time to spend reading the postings. (I site this based on various experiences with educational institutions) You will fuel the student hacker and his/her/its curiousity about what can be done on their system. The sysadmin, has no idea what has hit him.. And if the hacker is dangerous, or destructive.. that can be VERY bad for the host system, and other systems that are connected to it. > Not many of the things I have seen!! >And few of their kind will be helped. This is something one should never offer to do under any circumstances. >the more information, the better. >You can't plug a hole you don't know... >Nearly _all_ holes can be effectively defused IF you know they >exist. That is now down to the means of communicating the problems.. and I for one think that posting of various holes and hacking techniques is not what needs to be done. You do want security don't you? --nethack -- todd@jupiter.nmt.edu / nmtsun!todd Dr. Nethack: Box 3693 c/s Socorro, Nm. 87801
todd@nmtsun.nmt.edu (Todd/Dr. Nethack) (10/23/88)
Hmm... lots of flames lately..
Are you sure you guys think that no passwd on uucp is the only way to keep
someone out? ;-)
Maybe you should have a tiger team attack your machine, that could teach you
a bunch..
But all this useless drivel over uucp passwords and Joe is mildly stupid.
There are ways too many to count on how to get access..
If I were not such a nice guy about it, I could be in jail by now!!
I really don't think that mild arguements over where, will not lead to how
discussions..
People are curious about things.. (like cats) It will come up.. and it
should not be posted.. it needs to be handled in E-mail!!
--nethack
--
todd@jupiter.nmt.edu / nmtsun!todd Dr. Nethack: Box 3693 c/s Socorro, Nm. 87801dpw@unisec.usi.com (Darryl P. Wagoner) (10/23/88)
In article <1325@nmtsun.nmt.edu> todd@nmtsun.nmt.edu (Todd/Dr. Nethack) writes: >In article <1834@ddsw1.MCS.COM> karl@ddsw1.UUCP (Karl Denninger) writes: >>In article <1454@lznv.ATT.COM> ziegler@lznv.ATT.COM (J.ZIEGLER) writes: > >I will disagree strongly with that.. >There are many system admins. who have no time to spend reading the postings. >(I site this based on various experiences with educational institutions) >You will fuel the student hacker and his/her/its curiousity about what can >be done on their system. This assumes that NO ONE at that site is going to find out the hole and expose it. We all know what assuming will do. This, if anything is a false sense of security. IF no one will post holes to the net so I don't need to waste my time to find out and fix them either. I am perfectly safe as long as no one posts a hole I don't know about. If you believe this I have a bridge in SF that makes a mint in tolls that I need to get ride for tax reason. :-) The problem with this logic (besides being wrong) is that it will keep the systems admins in the dark while the crackers pass around the holes that they have found in the system. -- Darryl Wagoner dpw@unisec.usi.com UniSecure Systems, Inc.; OS/2, Just say No! Round Rock, Tx; (512)-255-8751 (home) (512)-823-3774 UUCP: {ut-sally!uiucuxc!kitty}!unisec!dpw
pda@stiatl.UUCP (Paul Anderson) (10/24/88)
In article <1146@unisec.usi.com> dpw@unisec.USI.COM (Darryl P. Wagoner) writes: ... about not discussing holes ... >The problem with this logic (besides being wrong) is that it will keep >the systems admins in the dark while the crackers pass around the holes >that they have found in the system. I second that. I remember my undergrad collegiate underground days- I often taught our admins at RPI about security. I regularly encouraged attacks on the mainframe and funny-$ for those who succeeded. And on Monday mornings I would walk into the Computing Services office and let them know where the holes were so that they could get plugged. They'd be mad as hell and indignant, because the felt that security-by-ignorance was valid security. I was regularly proving them wrong: and giving them a tighter system. It would have been just as easy not to say anything- and have open access to anything I wanted. Because nothing would have been said, the Computing Services dept would have thought their system secure. Ignorance is no defence. All effective assaults on security systems are due to holes 'in the system': operator shortcuts, coding bugs, hardware faults. We are bright people. We are taught to be innovative and have a never-say-die attitude. SO, what's gonna stop someone from breaking in? Only the possibility of teaching new sysadmins to cover as many HW and SW holes as possible. Funny thing about telecommunications: everything travels fast- even stuff the government doesn't want us to know... :-) paul -- Paul Anderson gatech!stiatl!pda Sales Technologies, Inc 3399 Peachtree Rd, NE X isn't just an adventure, Atlanta, GA (404) 841-4000 X is a way of life...
bill@carpet.WLK.COM (Bill Kennedy) (10/25/88)
There are two purposes to this follow-up. First my apologies for not
posting the promised summary. I have it, but it's at my home site in
Texas and I am in California on assignment. I will post it as soon as
I get back.
Second, I see two threads in the discussion. One says "gosh, let's not
talk about it" and the other (with which I agree) says "we'd better talk
about it or we're going to get ugly surprises".
I have some experience as an intruder. I was specifically assigned, by my
(a previous) employer, to crack security in the data center. This was a
large IBM mainframe shop, so the analogy isn't perfect. The first thing
we did was to copy all of the company's financial and personnel files to
tape. They were all very carefully password and date protected. I used
an IBM utility, iebcopy, which knew nothing of the protection schemes and
proceeded without any intervention by the security imposed. Having saved
and verified the copy, I then proceeded to overwrite those data sets with
sarcastic remarks about the security. The correct data were restored when
the first howls were heard the following morning.
The security people were, of course, furious but the simple fact was that
the data were compromised and there wasn't a thing they could do about it.
Ironically, security within the company was pretty strict, but a vandal
logged in from TSO could have shredded us. I was also able to anger the
security people with an attache case filled with bricks. I went by that
big pretty window that showed off the mainframe and threw in the case with
a sheet of greenbar paper taped to the side inscribed "BOMB". After it
shattered the glass it skidded across the floor and came to rest beneath
the system console where it "detonated".
Those are two examples taken from real life in a Fortune 100 company who
lives and dies by its computing center. Moving back to our own world for
a moment... My site has had a malicious intruder, one of my news/mail
neighbors has too. I fear that my neighbor got cracked because my own
security was lax. I don't think this can be overdiscussed. I don't think
we need to publish technique ("here's how I got past cron"), but we can
share common sense ideas, experience, and general precautions to keep out
the `tourists'. An accomplished vandal *will* penetrate and vandalize your
system unless you have it physically secure (which means no phone lines).
It's a fact, let's accept that. I want to explore those things we can do
to deter the amateur or journeyman jerk.
In (merciful) conclusion, I noticed a leak at my site. My Telebit modems
were set up to force DCD high regardless of carrier presence. This was
OK for uucp and other things that terminate normally, but if I was logged
in from here (worse, shudder, in su'd to root) and just took a disconnect
then the next thing to call that line picked up where I left off. The
modem did the right thing but the SIGHUP never got through so the process
just lived on. What now? I have my modems make DCD follow `real' carrier
detect and suffer the inconveniences setting them up.
--
Bill Kennedy Internet: bill@ssbn.WLK.COM
Usenet: { killer | att | rutgers | uunet!bigtex }!ssbn!billpjh@mccc.UUCP (Pete Holsberg) (10/27/88)
In article <170@carpet.WLK.COM> bill@ssbn.WLK.COM (Bill Kennedy) writes:
...I was also able to anger the
...security people with an attache case filled with bricks. I went by that
...big pretty window that showed off the mainframe and threw in the case with
...a sheet of greenbar paper taped to the side inscribed "BOMB". After it
...shattered the glass it skidded across the floor and came to rest beneath
...the system console where it "detonated".
Was that window facing the outside world? Did you have to pay for it?
--
Pete Holsberg UUCP: {...!rutgers!}princeton!mccc!pjh
Mercer College CompuServe: 70240,334
1200 Old Trenton Road GEnie: PJHOLSBERG
Trenton, NJ 08690 Voice: 1-609-586-4800bill@ssbn.WLK.COM (Bill Kennedy) (10/31/88)
In article <363@mccc.UUCP> pjh@mccc.UUCP (Pete Holsberg) writes: >In article <170@carpet.WLK.COM> I wrote: [ I broke the data center window, description deleted ] > >Was that window facing the outside world? Did you have to pay for it? No, the window faced inside to a courtyard and the building access was limited to badge carrying employees. Also no, I didn't have to pay for it. I fear I may have obscured my own point. I don't think that there is anything that can secure a computer site from an accomplished and determined vandal (I call them renegade programmers). Further, physical security is just as important as any other kind. Some would say it's more important. A large part of security (in my opinion) is plain old common sense. That's why I told the window breaking tale. Companies like to show off their frammis-mongo data centers with big windows, etc. A disgruntled employee (not yet terminated) or neo-terrorist could mortally wound such a firm by tossing something through the window as I did (as part of an *assigned* duty). Recently the GAO criticized the U.S. Air Force and Lockheed Missles & Space Company for poor security at the "Blue Cube" (a satellite control center). They said that any terrorist with a hand grenade could disable it. That was true as recently as last Thurday as I drove by it unless there's something new in that big air chute. I'll not consume much more bandwidth with this but there has been a meddler messing with the nuucp log in on this system. Sure, they get dropped into uucico and have to figure out what to do with that, but it still makes me nervous (I wish I worked for the phone company and could ANI the jerk!). OK, so in a week or less the no password nuucp account will be history, it would be sooner if I could be sure that all the legitimate neighbors had their new ID's and passwords. It's no fun having a complicated log in procedure. If I had a big fancy computer it would be no fun putting it in a fortress. But I'll conclude with a decent analogy. Look around at your telephone company offices that contain switching equipment. See any windows? See any frame (wood) construction? Nope, they are as physically secure as practical. -- Bill Kennedy usenet {killer,att,rutgers,sun!daver,uunet!bigtex}!ssbn!bill internet bill@ssbn.WLK.COM
todd@nmtsun.nmt.edu (Todd/Dr. Nethack) (11/06/88)
>...I was also able to anger the >...security people with an attache case filled with bricks. I went by that >...big pretty window that showed off the mainframe and threw in the case with On an un-named campus in California, I kept trying to convince the sysadmins to move or barricade a window (behind which sits a Vax 11-785 and the admin. IBM) They did not think it was any big deal.. also when they challenged me saying no one could break the security on the IBM, (since its so tight, DOD uses the same stuff.. etc) I told them, the easiest thing to do would be to tap the dialups (yes there are dialups on there grading/bookeeping mainframe) and wait for the Operator, we'll call him "Joe" to log in from his pc at home.. which he does all the time. Needless to say, they just insisted that nobody else would be smart enough to do such a thing.. (instead of locking or moving the MC-10 outside the building). They recently decided to network their Unix lab, to the Vax, and the Vax is already hooked (via a "secure" link) to the IBM.. and the Unix lab security? Call it nearly equal to /dev/null. My favorite idea was to make a tesla coil and walk up to the window and zap the brains out of the Vax.. alternately and cheaper.. is the "hit and run" Arson, or a firearm of somekind would turn that nice machine into so much sheet metal.. You were lucky that they still liked you after that "bomb" trick.. I had people convinced all I wanted to do was break into the computers, instead of provided viable answers to possible future problems.. There is one person there that still listens to me.. (we'll call him "Ed") Ed is still in contact with me on how to fix/secure various things.. Too bad his operators are power hungry paranoid facists!! Anyway.. back to work.. --nethack -- todd@jupiter.nmt.edu / nmtsun!todd Dr. Nethack: Box 3693 c/s Socorro, Nm. 87801
dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (11/12/88)
In article <1386@nmtsun.nmt.edu> todd@nmtsun.nmt.edu (Todd/Dr. Nethack) writes: # > ...I was also able to anger the ...security people with an # > attache case filled with bricks. I went by that big # > pretty window that showed off the mainframe and threw in # > the case with # On an un-named campus in California, I kept trying to # convince the sysadmins to move or barricade a window (behind # which sits a Vax 11-785 and the admin. IBM) # They did not think it was any big deal.. also when they # challenged me saying no one could break the security on the # IBM, (since its so tight, DOD uses the same stuff.. etc) # I told them, the easiest thing to do would be to tap the # dialups (yes there are dialups on there grading/bookeeping # mainframe) and wait for the Operator, we'll call him "Joe" to # log in from his pc at home.. which he does all the time. # Needless to say, they just insisted that nobody else would be # smart enough to do such a thing.. (instead of locking or # moving the MC-10 outside the building). # They recently decided to network their Unix lab, to the Vax, # and the Vax is already hooked (via a "secure" link) to the # IBM.. and the Unix lab security? Call it nearly equal to # /dev/null. # My favorite idea was to make a tesla coil and walk up to the # window and zap the brains out of the Vax.. alternately and # cheaper.. is the "hit and run" # Arson, or a firearm of somekind would turn that nice machine # into so much sheet metal.. # You were lucky that they still liked you after that "bomb" # trick.. I had people convinced all I wanted to do was break # into the computers, instead of provided viable answers to # possible future problems.. # There is one person there that still listens to me.. (we'll # call him "Ed") Ed is still in contact with me on how to # fix/secure various things.. Too bad his operators are power # hungry paranoid facists!! # Anyway.. back to work. My friend was more subtle: he left a brick on the person's desk with a paper wrapping saying "This could have been a bomb". The desk was in a very secure area. {My friend was with Army Intelligence and the place was a contractor's facility}. Someone else was asked to penertrate an installation one time and evehtually told his boss he had. He turned over copies of the master tapes for the computer center. At Rocketdyne my secretary got locked out of her safes. Someone exchanged the pad locks while they were open. Of course the person was an attractive male who flirted with her. But even so .... Sometimes concrete proof is the only way to convince people. 'Nuff said. -- =Dennis L. Mumaugh Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.com