lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C1A9A19.2070802@soul-dev.com>
Date: Thu, 17 Jun 2010 16:56:41 -0500
From: "Mr. MailingLists" <mailinglists@...l-dev.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: targetted SSH bruteforce attacks

Hello Gary/List!

On 6/17/2010 6:48 AM, Gary Baribault wrote:
> Hello list,
> 
>     I have a strange situation and would like information from the
> list members. I have three Linux boxes exposed to the Internet. Two of
> them are on cable modems, and both have two services that are publicly
> available. In both cases, I have SSH and named running and available
> to the public. Before you folks say it, yes I run SSH on TCP/22 and no
> I don't want to move it to another port, and no I don't want to
> restrict it to certain source IPs.

Since almost every angle of securing SSHD publicly have already been listed I will not
delve into that, so take my advice with a grain of salt.

In my environment, in order to access any of what I call trusted resources (such as ssh) I
require myself to have VPN connectivity. This eliminates the need of having SSHD listen
publicly, and as expected, eliminated all unknown hosts accessing my box via SSHD. It also
made my auth log much shorter and manageable as well :), but it is also more boring.

I'm guessing this wont work for your situation (seeing that you don't want to change the
public port either).

Otherwise, as said before:
Changing the port will absolutely reduce the number of hits, and concurrent attack attempts.

Use of port-knocking techniques will also achieve the above, and the use of PKA will
almost (almost, nothing is certain, hehe Debian) eliminate the chance of the opposition
recreating your private key.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ