Re: Help with tracking down intrusion record logs - VMS

This is a discussion on Re: Help with tracking down intrusion record logs - VMS ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) > > and SYS$MANAGER:AA.OUT has W:RE protection, so that I can easily include > > it in my (non-SYSTEM) e-mail. (My own login.com also defines "AA".) > > Boy, am I glad you're not responsible for ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: Help with tracking down intrusion record logs

  1. Re: Help with tracking down intrusion record logs

    From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)

    > > and SYS$MANAGER:AA.OUT has W:RE protection, so that I can easily include
    > > it in my (non-SYSTEM) e-mail. (My own login.com also defines "AA".)

    >
    > Boy, am I glad you're not responsible for security on my system. I'd
    > never make security information world readable.


    I don't consider these data particularly secret, or I'd use an ACL
    here, too. Of course, I am the only user on this system, and I also
    don't consider myself to be a big security threat, but what's the worry
    about, stuff like, say:

    Security alarm (SECURITY) and security audit (SECURITY) on ALP, system id: 1119
    Auditable event: Network login failure
    Event time: 21-AUG-2007 16:01:18.62
    PID: 2021F262
    Process name: TCPIP$SS_BG5702
    Username: TCPIP$SSH
    Remote node fullname: SSH_PASSWORD:VDS145.SIVIT.ORG
    Remote username: SSH_50F8D093
    Status: %LOGIN-F-NOTVALID, user authorization failure

    If it were such a big secret, I wouldn't be e-mailing it to some ISP
    which harbors out-of-control Windows systems.

    ------------------------------------------------------------------------

    Steven M. Schweda sms@antinode-org
    382 South Warwick Street (+1) 651-699-9818
    Saint Paul MN 55105-2547

  2. Re: Help with tracking down intrusion record logs

    Steven M. Schweda wrote:
    > From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)
    >
    >
    >>>and SYS$MANAGER:AA.OUT has W:RE protection, so that I can easily include
    >>>it in my (non-SYSTEM) e-mail. (My own login.com also defines "AA".)

    >>
    >> Boy, am I glad you're not responsible for security on my system. I'd
    >> never make security information world readable.

    >
    >
    > I don't consider these data particularly secret, or I'd use an ACL
    > here, too. Of course, I am the only user on this system, and I also
    > don't consider myself to be a big security threat, but what's the worry
    > about, stuff like, say:
    >
    > Security alarm (SECURITY) and security audit (SECURITY) on ALP, system id: 1119
    > Auditable event: Network login failure
    > Event time: 21-AUG-2007 16:01:18.62
    > PID: 2021F262
    > Process name: TCPIP$SS_BG5702
    > Username: TCPIP$SSH
    > Remote node fullname: SSH_PASSWORD:VDS145.SIVIT.ORG
    > Remote username: SSH_50F8D093
    > Status: %LOGIN-F-NOTVALID, user authorization failure
    >
    > If it were such a big secret, I wouldn't be e-mailing it to some ISP
    > which harbors out-of-control Windows systems.
    >


    The problem, AFAIK, is that if a user gets out of sync with the prompts on a
    login failure, and types his password in to Username:, it will show up in
    the Username: field (in plain text) in this file, which, if world-readable,
    any enterprising nogoodnik could scrape up.

    I think ana/audit used to put the attempted passwords in the log, which
    are sometimes very interesting, but I think it no longer does this.

    (For example, if you see JOE_USER with 3 failed login attempts followed
    by a successful login, with the 3 passwords being "password", "passw0r"
    and "pasw0rd", it's a good guess his real password is "passw0rd". Or
    if you see a failed attempt by JO_USER to login with "passw0rd" followed
    immediately by JOE_USER logging in successfully, you can be pretty sure
    of the same thing. I think this is why VMS stopped displaying the failed
    passwords.)

    You can get valid usernames from successful logins. Don't know how useful
    this is on VMS, though, since the security is based on the password (hidden,
    encrypted), not the username, which is easily visible. It might help with
    social engineering to know a valid but obscure username.

    Does anyone know of any other reasons why analyze/audit's output needs to
    be kept secure? Or is it just on general principle?

    --
    John Santos
    Evans Griffiths & Hart, Inc.
    781-861-0670 ext 539

+ Reply to Thread