invalid ssh attempts

On Mon, 05 Dec 2005 07:29:01 -0800, Scott en Aztlán wrote:
> On Mon, 05 Dec 2005 06:42:40 GMT, Mungo <reallydontmail@me.com> wrote:
>
>>I'm still trying to figure out how they came up with a few of the account
>>names the worm is trying. Not exactly your every day names.
>
> Indeed - either a couple of the script kiddies made EXTREMELY lucky
> guesses, or they somehow gained some sort of information regarding the
> valid usernames on my system.

Just a wilde guess but: maybe they timed the replys of some other
autenticated service beforehand. Say a webform, POP, FTP, or whatever?

> BTW, I heartily second the use of the "recent" option in iptables - it
> has virtually eliminated the brute-force SSH attacks.

http://slackworld.berlios.de/04/tips.html#ssh_attacks

Allong with this (or if one cannot use iptables for some reason), you
could force clients to reply some ident query using tcpwrappers. I.e.: put
something like the following in /etc/hosts.allow :

someuser@.somedomain.lan, 1000@somedomain.lan

(The string before ``@'' is ofcource what the connecting host should reply
with - "fakeident" should comein handy here - for us to allow them even to
provide their acctual username.)

This will set them back another 5sec for every failed try per default. But
that too can be changed putting a sleep (or usleep) in /etc/hosts.deny
maybe like the following:

ALL: ALL: twist ( sleep 10 )

--
-Menno.

Jan Pompe said the following on 2005-12-05 16:15:
> Unruh wrote:
>
>> John Sandell <jsandell@att.net> writes:
>>
>>
>>
>>> Is it unusual to get attempted ssh logins almost every day for months?
>>
>>
>>
>>> Example:
>>
>>
>>
>>> Jul 7 03:40:50 hp1 sshd[22604]: Invalid user zulgaftp from
>>> ::ffff:212.37.192.44
>>
>>
>>
>>
>>> That day, there were 5667 attempts...
>>
>>
>>
>>> Is this common?
>>
>>
>>
>> Yes. The latest game is to throw logon attempts at ssh with weak
>> passwords,
>> hoping that someone somewhere left a hole in their ssh.
>> It is usual to get 5000 attempts per day.
>
>
> So a good idea would be to put a delay between retries from the one site
> as someone above suggested?

Yes. If this does not interfere with valid use. In that case, an
automatic blocking tool that denies access after a number of failed
login attempts (DenyHosts i.e.) could prove itself useful.

But of course this is not enough in itself and shouldn't be. However,
with secure passwords and user names combined with the "AllowUsers"
option in your sshd_config these attempts are in most cases merely a
nuisance that clog up your logs.

The login attempts create far too much noise to go by undetected.

--
Jon Solberg (remove "nospam" from email address).

On Mon, 05 Dec 2005 18:18:18 +0100, Jon Solberg wrote:

> with secure passwords and user names combined with the "AllowUsers"
> option in your sshd_config these attempts are in most cases merely a
> nuisance that clog up your logs.

Indeed. Only rather then "AllowUsers" i set:

# Allow only users that are in group "ssh"
AllowGroups ssh

And put users (who need SSH access) in the ssh group (using "vipw"). This
had the benefit of central administation, allong with allowing to add cq
delete users without having to restart sshd.

> The login attempts create far too much noise to go by undetected.

On the other side of the coin tough: acctual brakeins might go unnoticed
in all the noise ...

--
-Menno.

Menno Duursma wrote:
> On Tue, 06 Dec 2005 02:15:53 +1100, Jan Pompe wrote:
>
>>Unruh wrote:
>>
>>>John Sandell <jsandell@att.net> writes:
>
>
>>>>Is this common?
>>>
>>>Yes. The latest game is to throw logon attempts at ssh with weak passwords,
>>>hoping that someone somewhere left a hole in their ssh.
>>>It is usual to get 5000 attempts per day.
>>
>>So a good idea would be to put a delay between retries from the one site
>>as someone above suggested?
>
>
> I'd think so. If the system supports PAM, maybe also for usernames:
> http://www-uxsup.csx.cam.ac.uk/~pjb1...ect/pam_delay/
>
i have PAM I'll take a look thanks seems a better solution to using the
firewall.

On 2005-12-05, John Sandell <jsandell@att.net> wrote:

> Is it unusual to get attempted ssh logins almost every day for months?

Nope. Happens all the time. Literally.

> Example:
>
> Jul 7 03:40:50 hp1 sshd[22604]: Invalid user zulgaftp from
>::ffff:212.37.192.44

Send a complaint and a copy of the logs documenting the attempts to the
abuse address for the owner of the IP block:

[john@vector john]$ whois 212.37.192.44|grep abuse
% http://www.ripe.net/db/news/abuse-pr...-20050331.html
abuse@internet-fr.net for spam complaints

If you're lucky they'll investigate and either pull the plug on that
machine or have the owner fix the problem. Or both.

> That day, there were 5667 attempts...
>
> Is this common?

These come from scripted attacks running on compromised machines. If most
of the attemps come from a single IP address, you can make a firewall rule
to block them completely.

--

John (john@os2.dhs.org)

try authfail

On Mon, 05 Dec 2005 02:29:40 +0000, John Sandell wrote:

>
> Is it unusual to get attempted ssh logins almost every day for months?
>
> Example:
>
> Jul 7 03:40:50 hp1 sshd[22604]: Invalid user zulgaftp from
> ::ffff:212.37.192.44
>
>
> That day, there were 5667 attempts...
>
> Is this common?
>
> John Sandell

Menno Duursma wrote:

> Allong with this (or if one cannot use iptables for some reason), you
> could force clients to reply some ident query using tcpwrappers. I.e.: put
> something like the following in /etc/hosts.allow :
>
> someuser@.somedomain.lan, 1000@somedomain.lan
>
> (The string before ``@'' is ofcource what the connecting host should reply
> with - "fakeident" should comein handy here - for us to allow them even to
> provide their acctual username.)
>
> This will set them back another 5sec for every failed try per default. But
> that too can be changed putting a sleep (or usleep) in /etc/hosts.deny
> maybe like the following:
>
> ALL: ALL: twist ( sleep 10 )

This is a great idea as long as one keeps the twist directive at
the end of the hosts.deny file. I use DenyHosts, which
automatically puts newly detected bad IPs at the end of that
file, and so I can't use your idea. If I put a twist directive
in the hosts.allow file (and it gets executed), then the
hosts.deny file would not get processed. Too bad there is no way
to change the default behavior of "process one directive then
exit" that is used for the hosts.{allow,deny} files...