Conference noted::hackers_v1

        Personally, I would be upset. I would address the issue with
        the superiors of those involved. 
        
        If a security group feels that it is within their charter to
        test the security of my system, then they should a) approach
        me and ask if I am comfortable with the security of my system
        and if I would allow them to test it. Given my permission,
        they should then report to me and me only on any recommendations
        for improved security.
        
        q
        

    
    Indiscrimnate entering of systems by ANYONE, Corporate Anybody
    included, is criminal.  In the case of groups such as you cite,
    it would be terminally stupid as well.
    
    .1 makes some excellent points on how this ought to be carried out.
                                     
    I realize whoever might be involved, in this would probably not have
    any malice in their motives, but if they made a mistake while breaking
    in and accidentally deleted data or destroyed source files, some
    heads would roll.
    
    Dave W.

Hey, it's not my machine.  I think maybe Mark (in the next office) owns it.

But seriously....

Personally, I think this is a good idea.  Corporate 'whoever' should announce
they're doing it, and respect CC manager requests to not probe certain machines.

BTW, how will a system manager distinguish between these break-in attempts and
real break-in attempts?  Too, if the break-in attempts simply try to guess
accounts/passwords, wouldn't it be less wasteful to simply have the system do
these checks itself?

    
    	I think its imperative that if my machine is to get the probe,
    that I be consulted in advance... Probably even be asked for permission
    in advance. I dont want to chase snipes....
    
    	Its too bad that these types of issues are always MANDATED rather
    than offered as a tool for those who may want it!
    
    	-JB

    	To add some statistics to give a little perspective...
    
    	The procedure has been run in Europe over most of the machines
    in Europe at varying intervals over the last couple of years.
    Typically, when a batch of nodes is checked for the first time or
    after a long elapsed interval :-
    1) Approximately 60% have insecure non-privileged accounts with
    names like ALLIN1, GUEST.
    2) Approximately 20% have insecure privileged accounts with names
    like FIELD, USERP.
    3) Originally around 20% had world readable authorisation files,
    but these have become rather rare now.
    4) In an unannounced test involving about 200 nodes only 3 system
    managers noticed their system had been "hacked" and enquired or
    complained.
    
    	Your machine may be one of the 40% that have no very obvious
    weak accounts, and may even be one of the 1% that has an alert and
    conscientious system manager, but this is probably what you are
    sharing the net with.

    I think this is great news.  It's about time that System Security
    was tested within Digital and that System Managers made a 'little'
    bit more aware of the various aspects other than just System
    Backup and Maintainence.

    RE:.2   Not true.  Corporate Security has the right to investigate
    or inspect any aspect of our systems.  And thank G-d they do.
    It has helped me recently in a BIG way.
    This aint Newspeak, so stop trying to get people torched Dave 8-}

I dunno.  Over the last few weeks, I've had a few spurious "failed
login attempts" on one of my accounts.  I'd really like to know
who/what/when.  Is there any way to convince VMS to log date/time
and attempted password into a file that I can examine?

Martin.

    The date and time are in the system accounting file, as well as
    the operator log file if security alarms are enabled for login
    failures.

    The reason VMS doesn't log the attempted password (or account name,
    if there is no such account) is because a noisy line or a typo could
    cause a near-password to be stored.  Then the security of the system
    would rest on the security of the error log.

    I'm occasionally surprised by the "failed login attempts" messages.
    Usually, I have a few detached processes logged in for days at a time,
    and VMS doesn't clear the "failed login count" when I successfully
    log in and connect (via the VMS prompts) to the process.  Thus, my
    account can accumulate several "failed login attempts" before I'm
    ever informed of them.  This may be the problem you noticed.

>    The reason VMS doesn't log the attempted password (or account name,
>    if there is no such account) is because a noisy line or a typo could
>    cause a near-password to be stored.  Then the security of the system
>    would rest on the security of the error log.

But it does!  I remember a while ago when a new employee here must have
forgotten which password he used, and VMS went into its self-defense mode when
he tried logging on.  The console contained several logfail messages, listing
the username AND THE PASSWORD tried. The only exception was "<correct>" listed
when the poor guy actually tried the right password (and VMS still refused to
let him on)  By reading the console log, I could have guessed the guy's
password since several of the attempts were mispellings of a place name.

-Mike

Re .10:

I'm not an expert in the VMS security features, but I support the idea
of not logging passwords.  You don't even need to hypothesize line noise
to get usable passwords it they were logged.  Typographic errors (missing,
extra and transposed characters) are quite common enough to provide
a rich supply of guessable passwords.  It would be trivial to write
a program that finds all the Hamming minimum distance words in a dictionary
from a misspelled password, thus removing the drudgery of actually having
to figure out how badly the luser types (or spells).

I can never recall reading the assertion that passwords are not logged.
Believe me, I'd remember if someone on the net had successfully proved that
their system was capable of logging failed passwords.

Could the user have been typing his password into the "Username:" prompt,
and having it logged that way?  It is an easy mistake to make when you
are not watching what you are typing and you got a login failure, or
when you don't understand what you are doing.  I've known people on
a Tops-10 system to gladly type in their PPN and password when:

1.  They hadn't gotten a monitor dot (Tops-10's prompt) for their LOGIN command,

2.  They hadn't gotten the "Job 69 blah blah blah" banner,

3.  They hadn't gotten a Password: prompt,

	-and-

4.  Their password was echoing on their terminal.

You can be less confused or stupid than that, and still enter your password
to VMS's Username: prompt.
				/AHM

re .11:

No, this was a definite attempt by VMS to log the passwords.  The records read
(vaguely) like this:

%%%%%%%%%%%%%%%%% OPCOM %%%%%%%%%%%%%%%%%%%%%%%

Breakin Attempt on _TTH7:  1-MAY-1986 12:00:00

Username: JONES

Password: FOOBAAR


%%%%%%%%%%%%%%%%% OPCOM %%%%%%%%%%%%%%%%%%%%%%%

Breakin Attempt on _TTH7: 1-MAY-1986 12:00:05

Username: JONES

Password: <correct>


%%%%%%%%%%%%%%%%% OPCOM %%%%%%%%%%%%%%%%%%%%%%%

Breakin Attempt on _TTH7: 1-MAY-1986 12:00:09

Username: JONES

Password: FUBAR


This is very paraphrased, but it's the general idea what I saw.  This was quite
a while ago, so I don't even know what version VMS this was.  Perhaps I should
try to recreate it (and drive my sys$manager out of his tree! :-) )

-Mike

    Right now, the program that checks systems over the network is owned
    by Corporate Network Security. They own the network. If your machine
    is inadequately secure, you jeopardize the security of the whole
    network. Read DIS Policies , 3.10,3.11. If they find that your 
    system is insecure and you as a system manager refuse to take measures
    to secure it, then they will most likely pull your node license,
    thus removing you as a "weak link". There is a very big push going
    on right now for system/network security and this is part of it.
    
    Failed, incorrect passwords won't be recorded if BREAKIN is not
    enabled. BREAKIN can be enabled for five different categories of
    access. The system manager can change the SYSGEN parameters as to
    how many login failures will trigger breakin evasion (when enabled).
    Currently, VMS 4.* allows 3 failed attempts (default) before it becomes 
    a login failure, so you can accumulate a few before it becomes part
    of the accounting file.

re .9, .11:

It happened again!  Someone tried several times to sign-on to a non-existant
account triggering the breakin evasion procedure, and yes, the console logged
the attempted username, the attemped password, as well as time, terminal, pid,
etc. This is VMS V4.4.

-Mike

    I understand the need to protect corporate data, but I think the
    first step is probably to educate system managers, not try to
    break-in first.   I'd like to receive a 'things-to-do' checklist
    when I register a node name.   If it contains things I really
    need to do, not off the wall items, it would be fairly short, simple,
    and do wonders for overall security.
    
    	KC

This whole approach is wrong.  If the NetCops want better security,
 cracking everybody's system isn't the key.  What they should do is
  lobby for some kind of recognition of system managers.

Who in this company has "system manager" as their job description?
 In most cases I know of, including my own, the system manager is
  somebody hired for development who takes care of the system on
   the side.  Training?  I got a system management course where I
    learned all kinds of things about VMS V3.  They're not going to
     send me to "the same course again" to see what's new for V4.
      (Yes, I asked.)

Couple that with the fact that you can't do any kind of worthwhile
 development on VMS unless you have privs.  All developers on my
  system have SETPRV, and I'm not authorized to change that.  If
   somebody leaves a gaping security hole, who gets to clean it up?
    Who takes responsibility?

Sure, I'd love to whip my cluster into perfect shape, but who has the
 time?  Even if time were allotted for system management, there is a
  bias against maintenance work (as opposed to productive work), and
   that means less status in your performance reviews.

What will this system hacking accomplish?  System managers will be
 given more work, which they won't get much credit for.  In fact, they
  will probably get heaps of criticism for it.
   <_Jym_>

    At least you have a system manager...Everyone who logs onto ours
    performs in that role as whenever (s)he feels that it is necessary.

    	Yes. Funding and recognition is required for system managers.
    Look at this positively. If you cannot run a secure system on the
    net without a system manager then that may be your justification
    for one.
    
    	For a time I was system manager of a 5 node cluster, with 200
    users (about 1/3 of them with SETPRV), but fortunately I had an
    understanding manager who accepted that I spent approximately 1
    day per week on system management.

    Re. .16. Uuugh Jymbo, weren't we both together in an "Advanced System
    Management" course a couple years ago?? Seems to me I remember you
    and me muching free donuts together.
    
    -- B

{RE .19} - Right you are.  I wasn't even going to mention that one, but
 the fact of the matter is that I was actually sent to two courses.  The
  first one was just "System Management," taught at Bedford, where I
   learned all about VMS V3 (like I said before).  The second one was
    "Advanced System Management," taught by some consultants.

That one's not even worth mentioning.  I didn't learn a thing!  The main
 lesson of the course was to use command procedures to help users set
  things up.  Quite the revelation, eh?  Then they brought in this guest
   speaker with an MBA who told us to push everyone around!  assert our-
    selves!  demand newer machines and more disks!

Well, at least we got free donuts!
 <_Jym_>

    Latest information from the folks that are doing this is that their
    probe doesn't activate the evasion function because it has a timer
    to prevent that, and that they don't do anything to any files (or
    even look around) if they do get in - just report the situation
    to the system manager and themselves.
    

Re .14:

Good enough for me.  Sorry to doubt you, but a combination of reading
discussions of this topic and the fact that it apparently wasn't turned on
on my cluster in MR (I'm glad) made me question its existance.

Re .16:

I was a "user rep" for a cluster.  I was the interface between the infinite
thermal sea of users and the poor guy in the operations group who was
responsible for system software massage.  As long as it didn't take
a whole hell of a lot of my time, it was worth brownie points on my
reviews.

I did some portion of the things one might ascribe to a system mangler
(those things I could figure out, and didn't want to compose a request
to the operations guy for).  But when I read in one of those MIS security
policies that the "System Manager" was personally responsible for this,
that and the other thing, I resolved that if anyone asked me, I was
not the "System Manager".  There was never enough time to do things
right, you see.
				/AHM/SIGH

Hey, we do things right, here in PXO!

We have an SMT!  (System Management Team)

And we only have one node!!!

(what this really means is that since I, the former System Munger, transfered
 to FS the SWS guys sort of took over and formed an addhoc commitee.)

Makes for great security!  Just try and get any privileges from a group
of 'gurus'  Ha.

All seriousness aside though,  I think it would be a good idea to have
formal system managers and give them proper training and a real title.

A security checklist for EASYnet access would be fantastic.  I'm not
even sure how we got our node assignment and I was manager at the time!

Someone in AQO sort of got us a number, but we have never found out
what the proper channel really was, and how to get more nodes registered...

(enough of this mumbling for now)

Scott Hesterman