topic Re: TCPIP Login Failures in Operating System - OpenVMS

TCPIP Login Failures

DECxchange — Tue, 30 Oct 2007 13:36:06 GMT

Hello,
I am using TCP/IP services on OpenVMS 8.3 on an Alpha system (workstation, server, doesn't matter. This question also applies to VMS 8.2, 7.3-2 and -1, as this occurs on these OS versions as well.

Anyway, I notice that on occasion, somebody is trying to gain access to my system via TCP/IP by guessing such usernames as admin, administrator, and other English names. It seems this is done by a computer program because I will get several of these tries per second. You can see this occurring by using the Accounting utility in OpenVMS.

The accounting utility will log the username that was attempted and the login failure message. My question is the following. Is there a way to determine (through the accounting utility, SDA, or other means) what password they are guessing?

Is it possible to have a watchdog program that can be triggered by a system event to notify when these username/password attacks begin? Right now I am discovering them by periodically monitoring system activity or checking the accounting file. It would be nice to have the system notify me automatically when these attacks begin.

So far, I have not been broken into, but it would be nice to manage this better than by accidental discovery.

Thanks!

Re: TCPIP Login Failures

Steven Schweda — Tue, 30 Oct 2007 14:02:46 GMT

Logging failing passwords can cause trouble,
because if someone gains access to legitimate
password typos, this info can help an
evil-doer to guess correct passwords.

On the bright side, the most common FTP
attack (on my system, at least) is for user
"Administrator", which, with a 12-character
user-name limit, is seen as "Administrato",
so, unless you actually have an
"Administrato" account, these should be
pretty harmless.

SSH attacks seem to lead pretty quickly to:
Status: %LOGIN-F-EVADE, break-in evasion in effect
so I figure that they're pretty unlikely to
succeed, too.

So far, I've been satisfied with (roughly)
daily inspection of the output from ANAL
/AUDI /FULL /SINC = previous_date-time, but I
assume that there's software out there which
would let you scan the OPCOM messages, and
then let you do what you want when you see
something interesting.

Re: TCPIP Login Failures

John Gillings — Tue, 30 Oct 2007 16:51:20 GMT

Make sure you have LOGFAILURE and BREAKIN ALARMS and AUDITS enabled for all potential sources. Check parameters and make sure you understand how breakin detection and evasion works. See:

$ MCR SYSGEN SHOW/LGI

In particular, make sure your LGI_BRK_LIM is set appropriately.

Rather than scanning the accounting file, try SHOW INTRUSIONS. You'll see something like this:

$ show intru
Intrusion Type Count Expiration Source
--------- ---- ----- ---------- ------
NETWORK SUSPECT 3 31-OCT-2007 08:32:12.86 cracker.central.com::TELNET_0A02FDFE

Suspects are probably just fat fingered users getting their passwords wrong, but INTRUDER maybe something to be concerned about.

For retrospective analysis, look in the security journal (ANALYZE/AUDIT).

There are a few potential ways to automate monitoring. If you're at a terminal, use REPLY/ENABLE=SECURITY. You'll see the audit alarms as they happen.

If you have a console manager, you may have a mechanism for scanning console output for BREAKIN audit messages. Failing that you could build yourself an audit listener to watch for them, or the "poor man's" approach would be a DCL procedure to poll SHOW INTRUSION and scan for intruder records.

>So far, I have not been broken into

Unless you have very lax password policies, and/or users who release their passwords, I'd go so far as to say it's all but impossible to crack an OpenVMS host using any form of dictionary attack (especially if they're using windows standard usernames!). If you're concerned, you can boost your protection by adjusting the LGI parameters to be more severe.

One fairly simple, and usually benign approach is to increase LGI_BRK_TMO and/or LGI_HID_TIM. The default is 5 minutes. Increase them to 1 or 2 DAYS. Any automated attack will be detected in a few seconds, but future attempts will fail from that source for the next few days. The cracker won't see anything other than "invalid password", but the system will refuse access even if they chance on a valid username/password pair. Every failure will just extend the blackout period.

>Is there a way to determine (through the
>accounting utility, SDA, or other means)
>what password they are guessing?

It's a while since I've looked, but I think once a source is declared an intruder, the BREAKIN audits log both the username and password. You need SECURITY privilege to see them in the audit journal.

If it were my system, I'd turn on maximum auditing and request professional assistance from my local law enforcement. This kind of activity is illegal in most jurisdictions. I'd be doing my best to track down and prosecute the perpetrators.

Re: TCPIP Login Failures

DECxchange — Tue, 30 Oct 2007 17:00:00 GMT

Hello,
Thanks for your responses! In fact, somebody has tried several times in the past FTP into my system as administrato. Perhaps we're dealing with the same hacker? I have a record of the IP address that is trying to get in.

I've thought in the past of contacting a law enforcement agency about this but I wasn't sure who to contact.

Anyway, thanks again! I'll give your suggestions a try.

Re: TCPIP Login Failures

Steven Schweda — Tue, 30 Oct 2007 17:19:24 GMT

> Perhaps we're dealing with the same hacker?

Or the same program.

> I have a record of the IP address [...]

Only one? Keep trying.

Event time: 1-JAN-2007 13:17:58.62
[...]
Process name: TCPIP$FTPC00031
Username: Administrato
[...]
Remote node fullname: 207.44.196.44

Event time: 29-JAN-2007 06:53:32.40
[...]
Process name: TCPIP$FTPC0009E
Username: Administrato
[...]
Remote node fullname: 201.216.236.100

Event time: 5-FEB-2007 19:33:23.70
[...]
Process name: TCPIP$FTPC000CE
Username: Administrato
[...]
Remote node fullname: 80.53.119.218

Event time: 19-FEB-2007 19:52:04.05
[...]
Process name: TCPIP$FTPC00104
Username: Administrato
[...]
Remote node fullname: 69.30.200.66

Event time: 4-MAR-2007 18:34:00.28
[...]
Process name: TCPIP$FTPC0014B
Username: Administrato
[...]
Remote node fullname: 210.192.96.48

Event time: 13-MAR-2007 08:39:15.09
[...]
Process name: TCPIP$FTPC0017A
Username: Administrato
[...]
Remote node fullname: 59.188.13.74

Event time: 19-MAR-2007 20:00:24.05
[...]
Process name: TCPIP$FTPC0018D
Username: Administrato
[...]
Remote node fullname: 200.105.74.106

Event time: 22-MAR-2007 07:18:57.60
[...]
Process name: TCPIP$FTPC0019C
Username: Administrato
[...]
Remote node fullname: 211.23.151.19

Event time: 26-MAR-2007 01:24:19.42
[...]
Process name: TCPIP$FTPC00002
Username: Administrato
[...]
Remote node fullname: 70.84.240.10

Event time: 21-APR-2007 18:06:50.00
[...]
Process name: TCPIP$FTPC000A8
Username: Administrato
[...]
Remote node fullname: 61.19.124.107

Event time: 27-JUN-2007 07:40:28.83
[...]
Process name: TCPIP$FTPC0004B
Username: Administrato
[...]
Remote node fullname: 219.239.34.200

and so on.

Re: TCPIP Login Failures

DECxchange — Tue, 30 Oct 2007 18:05:59 GMT

Hello,
On 11-Jul-2007, the IP address of Administrato was 60.32.141.186. I've had subsequent attacks, but that is the first accounting record I found. I just tried to FTP to this system and I got a "220 FTP OK" and then a login prompt.

Anyway, this is not the only IP address that runs this FTP login program, at least 3 times a second, guessing passwords. The point I was making is that I wanted to see what passwords this or other systems were guessing, just to see what these fools are trying to do!

Anyway, I'll try the security commands suggested by the other responder to my note.

BTW, I'll bet I'm not the only VMS or other system that has experienced this. If you do a:

$ acc/user=(-SYSTEM,-TCPIP$FAILSAFE,...)

You'll see who's trying to login to your system over the internet. Then you can do a

$ acc/ident=/full

you'll get the IP address.

Thanks again, folks!

Re: TCPIP Login Failures

DECxchange — Tue, 30 Oct 2007 21:32:15 GMT

Hello,
Regarding John Gillings' response about using $ show intrusion, I do recall doing that at the time, but it did not show up any intruder records. That led me to believe that repeat FTP login failures are not tracked by the show intrusion program.

I'm not under attack now, but next time I will be sure to verify show intrusion.

BTW, my LGI sysgen parameters are the default values you get when you would install OpenVMS 8.3.

Anyway, thanks again!

Re: TCPIP Login Failures

Kevin Carter_3 — Wed, 31 Oct 2007 18:29:52 GMT

Have you considered configuring the TCPIP services to only accept connections from the networks you know are valid? I realize this approach might not work depending on the number of networks. We only allow connections from 3 networks, all others are just dropped.

Re: TCPIP Login Failures

DECxchange — Wed, 31 Oct 2007 18:42:11 GMT

Kevin,
Thanks for your response. I'm not sure I understand what you mean by configuring TCPIP to only accept connections from networks I know are valid? Is this something you can do from the tcpip$config program, the TCPIP, or the NCL command utility? I guess I'm not familiar with this.
I'm not overly concrned about somebody actually breaking into my system. I would just like to find out if there are some countermeasures, like determining the origin or the nature of the breakin attempts. Maybe it's possible to build a knowledge base of the types of breakins and protect against those specifically, rather than shutting certain things down? I think this is a valid question, especially when somebody is trying to gain unauthorized access to your system.

Thanks again!

Re: TCPIP Login Failures

Steven Schweda — Wed, 31 Oct 2007 21:53:14 GMT

> [...] Is this something you can do from the
> tcpip$config program, the TCPIP, [...]

TCPIP HELP SET COMMUNICATION /REJECT
(or /ACCEPT)

That covers _all_ services. For an
individual service, there's:

TCPIP HELP SET SERVICE /REJECT
(or /ACCEPT)

The lists have limited length, so rejecting
very many hosts or networks individually is
not possible this way. And if you're trying
to offer freeware to the universe, limiting
access to only your close friends does rather
defeat the purpose.

> [...] countermeasures, like determining the
> origin or the nature of the breakin
> attempts.

Other than complaining to the ISP of the
hijacked Windows system, I don't know what
you can do. The true origin is probably
hidden behind the intermediate victim.

I haven't seen them much lately, but
anonymous FTP attacks with
ident:Xgpuser@home.com (where "X" would be
any upper-case letter) were pretty common for
a long time. Things like that could be
handled nicely if the FTP server had some
kind of call-out to a user-supplied
accept-reject command procedure. I haven't
heard of one being added yet, however.

Re: TCPIP Login Failures

Willem Grooters — Tue, 13 Nov 2007 05:51:14 GMT

I experience similar attempts at times and therefore I routinely check via accounting and audit on a daily basis. Indeed, I see "Administrato"(r) and "root" used quite often. I don't rely on the IP addresses: these people may use a anonymizer, broke into another system and used that, or have installed a bot creating a zombie box to 'guess' access to a number of sites (and communiate it back to the 'real' machine).

Requiering a second password could frustrate any attempt - I think these programs can cope with that - but I'm not sure if that can be set to be a requirement of specific interface. Would be nice if that were true!

Setting the LGI-flags can turn out very frustrating: if users usually access the VMS box from a Citric server over IP (telnet, FTP, HTTP), the _whole_ Citrix server will be locked out durung this period when too many failed attempts are signalled - no matter what username or IP protocol is used (based on own experience).
That might not be what you want.

If you want a "watchdog", you can think of PointSecure's System Detective. FWIK, that offers you the logging facilities you want, and probably more. It could be quite expensive but if you can afford the cost, it might be what you need. (I don't know if PointSecure offers hobbyist licenses either, it would be a nice thing if they did!).

Re: TCPIP Login Failures

Richard W Hunt — Tue, 04 Dec 2007 15:34:03 GMT

There are LGI_callout and PASSWORD POLICY callouts that could trap the attempt and send information to files. If you see the attempt to login ADMINISTRATOR you could just call out a bunch of GETJPI items and see what is going on. You would also see the password being used for the attempt if you were in the PASSWORD POLICY module, entry point POLICY_CLEARTEXT.

Re: TCPIP Login Failures

John Gillings — Tue, 04 Dec 2007 21:43:52 GMT

Richard,

>You would also see the password being used
>for the attempt if you were in the
>PASSWORD POLICY module, entry point
>POLICY_CLEARTEXT.

Not quite... These are two very distinct entities.

The password policy module implemented in VMS$PASSWORD_POLICY.EXE and controlled by SYSGEN parameter LOAD_PWD_POLICY is called only from the SET PASSWORD command when a user is changing passwords. It is not called during any kind of login.

The LGI_CALLOUTS module is a used to get control of the login process. It's horribly complex and difficult to get working properly (you think you had trouble with password policies! ;-). It also seems to me that LGI_CALLOUTS has been superceeded by the new ACME mechanism, but I'm not sure if that's been let out into the wild for ordinary people to develop their own ACME modules.

LGI_CALLOUTS and/or ACME could be used to track login attempts and implement special cases for certain usernames. If you go down this track, make sure the behaviour of the login, as perceived by the user doesn't make it obvious that you're doing anything very different (like a different failure message).

For ADMINISTRATOR or ROOT or any other obviously non-OpenVMS username I'd be tempted to put an extra delay before the Password prompt, and another before "User authorization failure" message, and I'd log the username/password pairs. I'd also allow the attempt to go throught the normal mechanism so that the normal intrusion detection mechanism was invoked.