T.R | Title | User | Personal Name | Date | Lines |
---|
432.1 | If he cannot get too close | PASTIS::MONAHAN | | Wed Mar 25 1987 19:50 | 35 |
| For an outside hacker to make use of any VMS security bug I
have ever heard of, or most of the nasty things we have been discussing
in connection with physical access, requires that he first gets
control of some process. So very high on the list of priorities
has to be :-
1) Make sure any captive accounts are really captive. This really
needs a checklist on its own, and there is one in the Securpack
documentation that we could take as a start.
2) A default DECnet account that allows things like TELL.COM to
be used is just as useful to a hacker with a good security bug.
3) Rather less under the control of a system manager (unless he
has users who will accept being forced to use generated passwords)
is any account with a poor choice of password. The best thing here
is education, but it can be difficult to find the time.
4) Both routinely, and especially after a product installation,
check for world writeable files. A couple of layered products have
left these after an installation, and an external hacker can patch
one over DECnet, and then just wait for it to be used by a privileged
user.
Given the above, your system should be fairly safe against a
hacker who does not have authorised access, and does not have access
to the machine or console terminal?????
Forgetting the problems if physical access is possible, since
there is already a note for that here, maybe we need a separate
note for protection against misuse by hackers with legitimate
authorised access, since I am sure there will be more to say for
the case where the hacker has neither.
Dave
|
432.2 | | MKTUP1::EIBEN | | Wed Mar 25 1987 21:52 | 9 |
| In the spirit of this note.... MKTUP1 currently makes Public Domain
Software for CPM / MSDOS and VMS available. I believe, I have been
already 'educated' to change some things - but aside from 'physical
access' -- I would like to invite 'hackers' to 'come over the net'
and tell me what they found needs help.
Rgds,
Bernie - knowing that 'safety will be a MAJOR ARGUMENT soon'.
|
432.3 | | TLE::BRETT | | Wed Mar 25 1987 23:16 | 10 |
|
Given the currently wide-open nature of the unencrypted ethernet,
and the (literally) 1000's of passwords that pass along it each
and every day, and combine that with the large numbers of proxy
logins to privileged a/c's; securing the little machine in your
office, or the large machine in the machine room has GOT to be
regarded as a joke - why bother locking the windows when the
front door is wide open?
/Bevin
|
432.4 | flame... | KIM::BARKER | ITS FUN TO DO THE IMPOSSIBLE... | Thu Mar 26 1987 01:43 | 28 |
| (flame-on)
re: .-1
>
> ...securing the little machine in your office, or the large machine in the
> machine room has GOT to be regarded as a joke - why bother locking the windows
> when the front door is wide open?
>
If we all considered it a joke, we never would get anywhere! Perhaps if we ALL
did attempt to secure the "little machine..." in our office, then the whole
system would be considerably more secure than it currently is. Besides,
Wouldn't locking the windows be a start anyhow?
My reason for starting this particular note was so everyone that had an
idea for advancing the security of their own system can be shared with everyone
else that is interested. Perhaps if enough ideas can be accumulated more of
the currently open windows can be closed.
Please keep the remainder of this note dedicated to new ideas, if you want
to argue about the current security of the net or others, we can open another
discussion...
(flame off)
John
|
432.5 | | KRAKAR::WARWICK | Village tours start here | Thu Mar 26 1987 08:37 | 12 |
|
If you have a MicroVMS system, be sure to change the passwords on
(or delete...) the USER and USERP accounts. USERP is obviously
especially dangerous.
To make you system less susceptible to attack over the network,
get rid of the EXEC NONPRIVILEGED and PRIVILEGED accounts, and use
DEF OBJECT xxx PASSWORD yyyy USER zzzz on all objects that you want
to be able to use. This should make sure that TELL can't be used
on your system.
Trev
|
432.6 | Security needs continual assessment | UTRTSC::ROBERTS | Nigel, TSC Utrecht, UTO-23.9b, DTN 838-2679 | Thu Mar 26 1987 09:08 | 34 |
| When somebody like Bevin makes a statement like that, it just has
to be taken seriously. Getting excited about it isn't too productive.
What is wrong with the "window-closing" philosophy is that it lulls
users, and worse, security managers into a false sense of security.
How many breakins, I wonder, result from incorrect application of
an inappropriately high level of security?
For example, captive accounts are a particularly thorny problem.
I've seen captive accounts believed secure by their creators which
only required a ^Y to break out of! Any difficulties that might
ensue in this case come from underestimation of the problem, not from
operating system weaknesses.
The "front door" mentioned won't go away just by looking at the
windows instead. It's inherent in the way the Ethernet works.
The only reason it doesn't _seem_ to be causing problems at the moment
is that it requires a certain amount of technical know-how. (I don't know
how to do it at the moment, and I don't expect to have the need to
find out, but I do know that I _could_ find out).
How to advance the security of your own system? I would answer this
in one word. EDUCATION. And this should include self-education. It
also should include educating the user community to potential
problems, so that they don't have blind faith in the security of
the system.
Discussing how to increase security is a good idea, despite the
occasional screams of "RTFM" -- but it should be coupled with a
discussion of the human problems involved in security management.
It's not just a technical solution.
-Nigel-
|
432.7 | How about "accounting"? | FROST::HARRIMAN | Criticism - It's only talk | Thu Mar 26 1987 11:38 | 32 |
| Right on, .6!
I remember this discussion happening before regarding captive command
procedures. The DCL command procedures conference was an excellent
source of ideas about securing captive command procedures as was,
not surprisingly, the SECURPAK manual. For instance, just changing
your INQUIRE statements to READ/PROMPT/etc SYS$COMMAND removes all
those nasty little DCL side effects like 'F$PID(LOGOUT). Letting
hackers loose on your code before you let it out for general use
is a great suggestion; I have been doing that for awhile, if the
hackers are on your side it helps a LOT.
As for securing all of our little systems: Clearly this is not 100%
bombproof. However a good security manager understands that 100%
security is not realistically possible and that given the criteria
and the fact that DEC is NOT the Pentagon, our focus should address
accountability as well as prevention. If I have a successful login
OR an unsuccessful login attempt over the network, if my accounting
is enabled I get the account name that attempted the login. If I
have ACL's enabled I find out who deleted a file from a CMS library
without using CMS to do it. If I have the obvious account/password
combinations removed (SYSTEM/MANAGER, come on!) and set a minimum
password length, it makes guesses more difficult.
Even failing that, I get the soft equivalent of a "paper trail"
so I can spend a little time to find what I'm looking for. If everyone
on the E-net did that it would be difficult to hide yourself. Of
course, there are limitations. Your uVAX-I might not like image
accounting enabled on an RD-52 system disk for long. However you
don't need image accounting to do good accounting.
/pjh
|
432.8 | Secure the perimeter | WKRP::LENNIG | Dave, SWS, @CYO Cincinnati | Thu Mar 26 1987 11:50 | 15 |
| Until operating systems and layered products/applications have no
bugs or design errors which allow authorized users to perform
unauthorized activities, the only hope for security is to secure
the perimeter. Once an intrusion occurs (unauthorized user gains
access masking as an authorized user) by definition the system has
been compromised. You must trust your authorized users to not perform
any unauthorized activities, given the current state of affairs.
You can apply all the protection you want to objects; they are useless
if a means exists to get past them. You can audit every action; being
informed that the bank has been robbed doesn't make it secure, and
the smart burglar either won't set off any alarms, or will get in
and out before they can be apprehended.
Dave
|
432.9 | | MKTUP1::EIBEN | | Thu Mar 26 1987 13:50 | 17 |
| re .-1 - sounds a little bit 'inconsistent' to me ..
On one side we're proud of 'networks' and communications [even as
'cheap' as incoming phone-lines] - on the other side, You talk
about a [pretty aged] 'perimeter'! What is that one in todays
world ?? ALL of DEC's [or the customers] buildings incase he has
no incoming phone-lines ?? - WE ARE IN NEED of betterments.
SECURPACK was a good marketing-job - it didn't however change
much of the reality that SECURITY is EITHER INHERENT {i.e. 'designed
in' from the beginning into the OS} or non-existant {LAYERED PRODUCTS
HAVE NO DEALINGS reguarding SECURITY , they can be 'buggy as hell'
as long as 'security' is at the OS-base !!}
Rgds,
Bernie [ let's get the 'unwanted features' out into the open - so
that guys valuing their 'data' can take needed actions].
|
432.10 | The Perimeter | WKRP::LENNIG | Dave, SWS, @CYO Cincinnati | Thu Mar 26 1987 18:09 | 29 |
| Compromise of security comes in one of two forms
1) monitoring the operation of the system, a passive and non-directed
activity (ie tapping the communications line or receiving RF,
hoping to hear something interesting)
2) active penetration towards a specific goal (login or otherwise
cause specific code to be executed to obtain desired information)
This indirectly defines the perimeter of which I speak. If I can't
successfully perform either action, then the system is secure.
Point (1) is being addressed today by such means as copper-clad
computer rooms, encryted communications, TEMPEST specifications,
physical plant security, such that the activities of authorized
users can't be monitored. Point (2) can only be addressed be proper
management of the passwords and accounts which allow entry to the
system. ONCE I AM IN (ie once I successfully pretend I'm an authorized
user) the system has been compromised.
If I enter as user X, his files and anything he has access to is mine.
If user X is privileged, or can cause code to execute in a privileged
context, nothing on the system is safe. The operating system and
applications on the system can attempt to prevent me from 'causing
code to execute in a privileged context', but bugs and design errors
DO occur. And if I successfully masquerade as a privileged user,
things are even simpler. The point is, that once I'm past the
perimeter, it becomes enourmously more difficult, if not impossible,
to protect information on the system.
Dave
|
432.11 | Is this horse dead yet? | FROST::HARRIMAN | Criticism - It's only talk | Thu Mar 26 1987 19:21 | 52 |
| Just how much security do you need or want?
If we're talking about "absolute" security then you can't have it
with Ethernet, T1 lines, or anything short of a radiation-hardened
computer room under a mountain with a single terminal hard-wired
in the same room as the computer, disks, and tape(s), as well as
physical identity checking of the user (or users) with a
classification rating, etc, etc. I believe that's what they call
"Class A" security?
You speak about the perimeter, but the perimeter in the DEC world
is generally VERY easy to crack, nor is it realistically possible
given those constraints to make the environment class-A secure.
If you have two machines and they are connected by a wire and that
wire is "unattended" at any point in the path, you are not secure.
The software is another story altogether. Privileged functions should
know their caller. Installed sections cannot have traceback; this
supposedly makes it more difficult to figure out how to run them
outside of their intended context, right?
I remember reading that DOD rated VMS V4 as a class C secure operating
system; I am not certain about what constitutes a class C security
rating but I believe the reference monitor has something to do with
it.
The point is the pieces are there; using them, or even wanting to
use them, is totally up to the user/customer. All of these safeguards
take effort, and there is an appreciably large amount of effort
which needs to be expended to make them work. Many system managers
do not have the time to constantly monitor their system for intrusions.
Letting SECURPAK tell you that someone tried to break in yesterday
sometime is little comfort, since they could have been successful
between then and now. I understand there are books on this subject,
DEC even has a "Guide to VAX/VMS Security" (even read it!)... A
system manager or the people who run the system have to make a
conscious decision about how much security is enough security. I
firmly believe that absolute security is impossible, to believe
so is to fool yourself. To baby-sit a system looking for that burglar
to hit is pretty boring, especially if they don't know you're there.
Plus it's a waste of money to pay someone to do that. That's what
the reference monitor is for.
There has GOT to be a balance between security and productivity.
My workstation cannot be insulated from the rest of the corporation
without a large cost to me, I pay by losing the ability to do things
like this :-) but really, this has been said in the last 30 or so
replies in the last two major topics - physical and "logical" security
are two completely different topics and (it seems) should have a
different focus.
/pjh
|
432.12 | Don't delete -- DISUSER! | ANYWAY::GORDON | Indoor Stargazer | Thu Mar 26 1987 23:37 | 10 |
432.13 | "2 mumbleVAXen, huh?" | FROST::HARRIMAN | Deep Talk | Fri Mar 27 1987 12:07 | 25 |
432.14 | Information overload... | ANYWAY::GORDON | Indoor Stargazer | Mon Mar 30 1987 16:52 | 19 |
432.15 | Still haven't resolved this yet | FROST::HARRIMAN | DEBATES...DISCUSSIONS | Mon Mar 30 1987 19:19 | 34 |
|
Re: Doug
it's all right, you're forgiven :-)
Seriously; I was thinking about this some more. There has got to
be a way that we all can tell (or at least be more intelligent about)
what information we *should* be investigating further. Maybe by
*excluding* certain information which is normally put into logs.
I suppose these ideas should be QARed to the SECURPAK people but
I don't know if they have a place for that.
Anyway, why not build in the capability (somewhere!) to EXCLUDE
things like JOBCTL, certain network objects, etc. Maybe you should
set up network objects off of object 0 and give them passwords.
If you're really paranoid then shut your network off at night.
It seems kind of silly to have to go through all this, especially
once it starts interfering with "normal" operations, like
across-the-world mail transfers, overnight file transfers, etc.
Yes, if you have a small system which is not a router or shouldn't
have a lot of traffic like a VSII or something then it's safe to
say a "security alarm" is a big event. However on a major router
for a plant which does very little but route DECNET traffic to and
fro then it's another ball game.
Perhaps this is a thing to "add to the checklist" (remember .0?)
Know what you are going to use your machine for before you decide
the level of security for it. Some kinds of security are not exactly
appropriate for workstations but are definitely needed on machoVAXen.
/Paul_J
|
432.16 | Disabling other accounts... | MONSTR::DUTKO | Nestor Dutko, VMS/VAXclusters CSSE | Wed Apr 01 1987 14:35 | 13 |
432.17 | There is a place | JETSAM::NORRIS | What is it, Miss Pfeffernuss? | Tue Apr 07 1987 14:08 | 9 |
| Re .15
> I suppose these ideas should be QARed to the SECURPAK people but
> I don't know if they have a place for that.
If you have any suggestions on how to improve SECURPACK please mail
then to me or post them in the SECURPACK conference on ANCHOR::.
We will be looking at starting an update to the product.
Ed
|
432.18 | add_user.com (or disable_user.com) | TOHOKU::TAYLOR | DECmacs on a VAXintosh | Wed Apr 08 1987 21:42 | 476
|