[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::hackers_v1

Title:-={ H A C K E R S }=-
Notice:Write locked - see NOTED::HACKERS
Moderator:DIEHRD::MORRIS
Created:Thu Feb 20 1986
Last Modified:Mon Aug 03 1992
Last Successful Update:Fri Jun 06 1997
Number of topics:680
Total number of notes:5456

432.0. "CHECK_LIST TO SECURE A VAX..." by KIM::BARKER (ITS FUN TO DO THE IMPOSSIBLE...) Wed Mar 25 1987 15:38

Use this note to define the things that should be done to secure a VAX
running VMS as much as can possible.

T.RTitleUserPersonal
Name
DateLines
432.1If he cannot get too closePASTIS::MONAHANWed Mar 25 1987 19:5035
    	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.2MKTUP1::EIBENWed Mar 25 1987 21:529
    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.3TLE::BRETTWed Mar 25 1987 23:1610
    
    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.4flame...KIM::BARKERITS FUN TO DO THE IMPOSSIBLE...Thu Mar 26 1987 01:4328
(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.5KRAKAR::WARWICKVillage tours start hereThu Mar 26 1987 08:3712
    
    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.6Security needs continual assessmentUTRTSC::ROBERTSNigel, TSC Utrecht, UTO-23.9b, DTN 838-2679Thu Mar 26 1987 09:0834
    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.7How about "accounting"?FROST::HARRIMANCriticism - It's only talkThu Mar 26 1987 11:3832
    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.8Secure the perimeterWKRP::LENNIGDave, SWS, @CYO CincinnatiThu Mar 26 1987 11:5015
    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.9MKTUP1::EIBENThu Mar 26 1987 13:5017
    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.10The PerimeterWKRP::LENNIGDave, SWS, @CYO CincinnatiThu Mar 26 1987 18:0929
    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.11Is this horse dead yet?FROST::HARRIMANCriticism - It's only talkThu Mar 26 1987 19:2152
    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.12Don't delete -- DISUSER!ANYWAY::GORDONIndoor StargazerThu Mar 26 1987 23:3710
432.13"2 mumbleVAXen, huh?"FROST::HARRIMANDeep TalkFri Mar 27 1987 12:0725
432.14Information overload...ANYWAY::GORDONIndoor StargazerMon Mar 30 1987 16:5219
432.15Still haven't resolved this yetFROST::HARRIMANDEBATES...DISCUSSIONSMon Mar 30 1987 19:1934
    
    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.16Disabling other accounts...MONSTR::DUTKONestor Dutko, VMS/VAXclusters CSSEWed Apr 01 1987 14:3513
432.17There is a placeJETSAM::NORRISWhat is it, Miss Pfeffernuss?Tue Apr 07 1987 14:089
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.18add_user.com (or disable_user.com)TOHOKU::TAYLORDECmacs on a VAXintoshWed Apr 08 1987 21:42476