SSH port scanners
Tom Linden
these.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Ron Johnson
> These guys are a nuisance, what are others doing, if anything about
> these.
Don't know about firewalls, but Linux distros usually have tools
which detect such break-in attempts and auto-block those IP addresses.
--
Ron Johnson, Jr.
Jefferson LA USA
Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!
Richard B. Gilbert
> These guys are a nuisance, what are others doing, if anything about
> these.
>
Most ISPs prohibit port scans. Enforcement is somewhere between lax and
nonexistent! If the port scan is coming from a "civilized" network, you
can try complaining to the perpetrator's ISP and see what happens. If
it's coming, as many do, from China, Korea, Singapore, Russia, Poland,
etc, just block the source at your firewall, if your firewall allows
that. If your firewall doesn't allow that, try getting a better one.
My router/firewall automagically blocks any conncection that was not
initiated from inside my network. That may, or may not, be practical
for you.
Steven M. Schweda
> These guys are a nuisance, what are others doing, if anything about
> these.
I just send the appropriate section of an ANAL /AUDI /FULL report to
the ISP. It's rare to get a repeat from the same address, but if I see
one, I use TCPIP SET SERV SSH /REJE = HOST = xx.xx.xx.xx. (Only 18 so
far, so I haven't had to remove any yet.)
Most of the entries seem to include a line like:
Status: %LOGIN-F-EVADE, break-in evasion in effect
so I don't worry much about anyone actually getting in. Average rate
here is about 1-2 attacks/day. Some are one or two tries, some are
hundreds.
------------------------------------------------------------------------
Steven M. Schweda sms@antinode-org
382 South Warwick Street (+1) 651-699-9818
Saint Paul MN 55105-2547
Tom Linden
wrote:
> From: "Tom Linden" <t...@kednos-remove.com>
>
>> These guys are a nuisance, what are others doing, if anything about
>> these.
>
> I just send the appropriate section of an ANAL /AUDI /FULL report to
> the ISP. It's rare to get a repeat from the same address, but if I see
> one, I use TCPIP SET SERV SSH /REJE = HOST = xx.xx.xx.xx. (Only 18 so
> far, so I haven't had to remove any yet.)
Can you use wild cards to block out an entire, say, class C?
>
> Most of the entries seem to include a line like:
>
> Status: %LOGIN-F-EVADE, break-in evasion in effect
>
> so I don't worry much about anyone actually getting in. Average rate
> here is about 1-2 attacks/day. Some are one or two tries, some are
> hundreds.
>
> ------------------------------------------------------------------------
>
> Steven M. Schweda sms@antinode-org
> 382 South Warwick Street (+1) 651-699-9818
> Saint Paul MN 55105-2547
--
Steven M. Schweda
> > one, I use TCPIP SET SERV SSH /REJE =3D HOST =3D xx.xx.xx.xx. (Only 1=
> Can you use wild cards to block out an entire, say, class C?
Let's see. I know that your fingers aren't broken, ...
tcpip help set serv /reje
Look for "NETWORKS=networks".
Michael Moroney
>On 05/30/07 08:36, Tom Linden wrote:
>> These guys are a nuisance, what are others doing, if anything about
>> these.
>Don't know about firewalls, but Linux distros usually have tools
>which detect such break-in attempts and auto-block those IP addresses.
I have a half-completed program that gets a breakin attempt notification
from the audit server, and does the equivalent of the set serv /reject of
the offending IP address, which is being created for this very reason.
The portscanner's IP address will automatically be disabled after about 5
attempts. I'll make it available when ready.
Another option is to have SSH use a nonstandard port so the portscanners
won't find it, but I don't know offhand how to do this on VMS.
Uusimäki
My VMS machine was also attacked by some SSH port cracking attempts.
When the SSH session limit was at default value (10000) the repeating
attempts did consume a lot of memory and the machine became really slow.
As a countermeasure I limited sessions to 20 and after that it wasn't
that bad anymore, but they still kept coming. One day I got really mad
at the crackers and changed the SSH port number to a nonstandard one and
after that day I haven't had a single attempt. I can recommend it as a
solution for a known user community, but if your machines are public
servers, it might be a problem, though.
IMHO the default limit is unnecessary high. There aren't very many
Alphas which can handle 5000 interactive sessions. I think the vast
majority of AlphaServers running VMS host less that 1000 simultaneous
SSH sessions. Large clusters and the biggest GS series AlphaServers
might have more than that.
Ron Johnson
How many "enterprise" Alphas host thousands of meat-bag connections
anymore? Isn't it all pooled client-server connections, etc?
> Tom Linden wrote:
>> These guys are a nuisance, what are others doing, if anything about
>> these.
>>
P. Sture
mor...@world.std.spaamtrap.com (Michael Moroney) wrote:
> Ron Johnson <ron.l....@cox.net> writes:
>
> >On 05/30/07 08:36, Tom Linden wrote:
> >> These guys are a nuisance, what are others doing, if anything about
> >> these.
>
> >Don't know about firewalls, but Linux distros usually have tools
> >which detect such break-in attempts and auto-block those IP addresses.
>
> I have a half-completed program that gets a breakin attempt notification
> from the audit server, and does the equivalent of the set serv /reject of
> the offending IP address, which is being created for this very reason.
> The portscanner's IP address will automatically be disabled after about 5
> attempts. I'll make it available when ready.
That would be gratefully received!
> Another option is to have SSH use a nonstandard port so the portscanners
> won't find it, but I don't know offhand how to do this on VMS.
From the TCPIP help:
SET
SERVICE
Defines a new entry or modifies an existing entry in the services
database.
The /FILE, /PORT, /PROCESS_NAME, and /USER_NAME qualifiers are
required when defining a new entry and optional when modifying an
existing one.
For changes to service parameters to take effect, you must
disable and reenable the service.
But:
TCPIP> set serv ssh/port=2222/process=TCPIP$SSH
%TCPIP-E-SERVERROR, cannot process service request
-TCPIP-E-QUALREQ, qualifier value for USER_NAME is required
TCPIP> set serv ssh/port=2222/process=TCPIP$SSH/user=TCPIP$SSH
%TCPIP-E-SERVERROR, cannot process service request
-TCPIP-E-QUALREQ, qualifier value for FILE is required
TCPIP> set serv ssh/port=2222/process=TCPIP$SSH/user=TCPIP$SSH/ -
file=TCPIP$SYSTEM:TCPIP$SSH_RUN.COM
%TCPIP-E-INVRECORD, invalid information
-RMS-F-DUP, duplicate key detected (DUP not set)
So you need to delete the service, then recreate it.
More coffee required!
--
Paul Sture
VAXman-
$ tcpip disable service ssh
$ tcpip set noservice ssh
$ tcpip set service ssh /port=2222 /proc=tcpip$ssh/user=tcpip$ssh -
_$ /file=tcpip$system:tcpip$ssh_run.com /proto=tcp/limit=10000 -
_$ /log=(all,file=tcpip$ssh_device:[tcpip$ssh]tcpip$ssh_run.log)
$ tcpip enable service ssh
I usually put mine at a higher port (22022).
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
"Well my son, life is like a beanstalk, isn't it?"
P. Sture
VAXman- @SendSpamHere.ORG wrote:
Thank you kind sir.
Having been bitten by this one before, with third party products, I
decided to put the above in a command file.
Oops, the prompt for deleting the service screws up. The following shows
procedure execution with verify switched on. The truncated display is
presumably the prompt echo:
$ tcpip set noservice ssh
Service Port Proto Process Address
SSH 22 TCP TCPIP$SSH 0.0.0.0
$ tcpip set
/file=tc
/log=(al
$ tcpip enab
Interrupt
The solution is to insert a define/user before the "set noservice"
command:
$! ssh_config_port.com
$! -------------------
$ tcpip disable service ssh
$ define /user sys$input sys$command
$ tcpip set noservice ssh
$ tcpip set service ssh /port=22022 /proc=tcpip$ssh/user=tcpip$ssh -
/file=tcpip$system:tcpip$ssh_run.com /proto=tcp/limit=10000 -
/log=(all,file=tcpip$ssh_device:[tcpip$ssh]tcpip$ssh_run.log)
$ tcpip enable service ssh
> I usually put mine at a higher port (22022).
To make life harder for port scanners?
--
Paul Sture
VAXman-
The
$ tcpip set noservice ssh
will query the user with a prompt:
Service Port Proto Process Address State
SSH 22 TCP TCPIP$SSH 0.0.0.0 Disabled
Remove? [N]:
Thus, when you put it into a command procedure this behavior required that
you assign input to come from SYS$COMMAND and not the command procedure. I
don't see any documented qualifer which would turn off this "Micro$oft-like
are-you-sure?" query.
>> I usually put mine at a higher port (22022).
>
>To make life harder for port scanners?
It doesn't make it any harder. However, higher ports are usually utilized
by clients connecting to external services. The lower port numbers are the
(typically) defined server ports. If you look at the URL I posted several
day ago in the substandard disaster recovery product thread, you will see a
fairly dense population of port numbers defined below 10K. While it is not
a guarantee that a port scanner will NOT find your ssh server, I have found
that my ssh server has been left alone since I started putting that port at
22022.
P. Sture
VAXman- @SendSpamHere.ORG wrote:
<snip>
> >> $ tcpip disable service ssh
> >> $ tcpip set noservice ssh
> >> $ tcpip set service ssh /port=2222 /proc=tcpip$ssh/user=tcpip$ssh -
> >> _$ /file=tcpip$system:tcpip$ssh_run.com /proto=tcp/limit=10000 -
> >> _$ /log=(all,file=tcpip$ssh_device:[tcpip$ssh]tcpip$ssh_run.log)
> >> $ tcpip enable service ssh
> >>
For completeness, I've just compared that with the contents of
TCPIP$CONFIG.COM, and the only significant addition that suggests is
/reject=message="TCPIP SSH Connection refused"
> The
>
> $ tcpip set noservice ssh
>
> will query the user with a prompt:
>
> Service Port Proto Process Address State
>
> SSH 22 TCP TCPIP$SSH 0.0.0.0 Disabled
> Remove? [N]:
>
> Thus, when you put it into a command procedure this behavior required that
> you assign input to come from SYS$COMMAND and not the command procedure. I
> don't see any documented qualifer which would turn off this "Micro$oft-like
> are-you-sure?" query.
>
/noconfirm is valid here. (buried in the help for
Caveat: The service name accepts wildcards.
>
> >> I usually put mine at a higher port (22022).
> >
> >To make life harder for port scanners?
>
> It doesn't make it any harder. However, higher ports are usually utilized
> by clients connecting to external services. The lower port numbers are the
> (typically) defined server ports. If you look at the URL I posted several
> day ago in the substandard disaster recovery product thread, you will see a
> fairly dense population of port numbers defined below 10K. While it is not
> a guarantee that a port scanner will NOT find your ssh server, I have found
> that my ssh server has been left alone since I started putting that port at
> 22022.
Understood, thanks.
--
Paul Sture