31 Oct
2016
31 Oct
'16
1:49 a.m.
And there is a genius from Trinidad trying very hard to get into my
system with username "SHSTEM" all the time :)
On 10/26/2016 12:24 AM, Kari Uusim?ki wrote:
You can limit different types of logins in different ways.
E.g. by defining when you can login in the UAF.
Anyhow, I wouldn't be too concerned about those scripties. The DECUS
server in Finland has been online since early 90's and noone has ever
succeeded to break in.
Telnet was enabled until about a year ago and the SYSTEM account has
been enabled normally.
Two settings are recommended to make the life bitter for the
scripties. First extend the breakin system parameters to make the
waiting time really long and second limit the maximum sessions of
telnet or ssh. Then the scripties will try for a while, but soon
they'll be bored and find an easier target. And your system will not
be much affected.
Kari
On 26.10.2016 3:01, Sampsa Laine wrote:
--
Supratim Sanyal
/*Named must your fear be before banish it you can. - Yoda*/
39.19151 N, 77.23432 W | Ph: +1 469 SANYALS (+1 469 726 9257) |
www.sanyal.org <http://www.sanyal.org/>
Sent via FossaMail <http://www.fossamail.org> on Windows 10 Professional
64-bit / Intel Mobile Core 2 Duo P8700 @ 2533 MHz
<https://www.facebook.com/supratim.sanyal>
On 25 Oct
2016, at 22:23, Johnny Billquist <bqt at softjar.se> wrote:
On 2016-10-25 19:51, G. wrote:
Here?s the weird thing about VMS (well I guess it?s the TCP/IP
Layered Product generating the events so maybe the weird thing about
both MULTINET and HP?s TCP/IP LP):
- DECNET logins are shown as REMOTE/NETWORK
- TCP/IP logins are shown as _LOCAL_.
I always wondered where the logic behind that was.
Is there any way to limit logins to say JUST NETWORK because that
would effectively disable TCP/IP logins, no?
Sampsa
On Tue, 25 Oct 2016 17:48:45 +0300, Sampsa Laine
wrote:
> Also, is renaming the SYSTEM account likely to break stuff? They
> seem to be
> targeting that specific username so I figured I?d change it to
> STALIN or
> something?
Instead of renaming it, you may want to disable interactive logins
for the
SYSTEM account altogether, or you may want to investigate about
tightening
timeouts for the intrusion detection function (see SHOW INTRU
command), so
that VMS will not allow logins from accounts for which a certain
threshold
has been reached, even if the attacker guesses the password. :)
Totally agree on
disabling interactive logins. But I would perhaps
limit that to just network logins. (I believe VMS can also make that
distinction.)
However, if the intrusion system disables the account, it becomes a
rather ugly DOS vector. Not sure how they were thinking there?