Re: need help with openssh attack
On Thu, Dec 29, 2011 at 4:51 PM, Thijs Kinkhorst <thijs@debian.org> wrote:
> On Thu, December 29, 2011 16:37, Nicolas Carusso wrote:
>>
>> How about creating a Referense list with all the suggestions that we are
>> doing?
>> If all of you agree, Let's start now.
>>
>> SECURITY LIST
>> ******************
>
> There's already the Securing Debian HOWTO:
> http://www.debian.org/doc/manuals/securing-debian-howto/
>
> Perhaps it's an idea to see if your suggestions are in there, and if not,
> to suggest additions/changes/patches to the Debian Documentation project.
> You can get in contact through debian-doc@lists.debian.org.
chroot is done other way than the guide now days, so the patch is indeed needed.
I've seen the "change port 22" tip since I know ssh, and I still see
servers "hacked" in 2012.
Also, I see neither in the guide, neither in the points stated here,
talk about disabling unneeded forwarding.
I think one big step, is to try to understand each option in the
sshd_config man page, and to test the results in each environment, and
each admin evaluate each option to _house_ policies.
SSH in the main firewall? is this the policy?
AllowTcpForwarding
Specifies whether TCP forwarding is permitted. The default is
“yes”.......
By fortune, the default for GatewayPorts is "no", but if that is not
your policy...
But maybe other defaults doesn't like you:
MaxAuthTries
Specifies the maximum number of authentication attempts permitted
per connection. Once the number of failures reaches half this
value, additional failures are logged. The default is 6.
MaxSessions
Specifies the maximum number of open sessions permitted per net‐
work connection. The default is 10.
There are lot of other options, about timeouts, MaxStartups,
PermitEmptyPasswords, PermitTunnel, StrictModes
Maybe that if you read the manual of the tool just installed, you
start finding incomplete "security lists", etc.
Anyway... at the end... As well as you can search for filezilla XMLs
indexed online (ip/user/pass of lot of environments), I've seen
public+private keys (+amazon IDs) in bitbucket pushed as "mydotfiles"
and indexed by search engines.
While the sysadmin fights to secure ARP, TCP, IP, DNS, SSL and then
the services over, and the ssh developer does privilege separations
and its security stuf, the web developer will index the credentials in
a search engine. Put the credentials in a plain email, worldwide
messenger service, post-it in the tasks table or in a shared folder
with anonymous access for a co-worker.
Step one to know how to secure a service in your server: do you know
how to attack such service ? Do you know the common threats available
in the net to attack such service ? then play chess
Not every SSH attack will be "a worm that exploits a code fault in
port 22 of random network ranges". But maybe you get an attack of just
another tech person like you trying to do "it" (DoS the service (or
the server), be root, do the machine heat ram and kill other process,
etc). Or maybe you get someone that just got the credentials from
anyplace. That young student doing practices by 1 month has access to
all company backups ?
And... last but not least: system/security updates is not enough in
some environments, so maybe add to the list:
* maintenance (renew ssh keys periodically or on events, delete rules
for old users/groups/hosts, etc)
As well as, if you follow best practices and makes some cpu parse your
logs by you... "report attackers" maybe other "task" of the
maintenance process. You "can" report any abuse to the responsible
internet providers, but that does not implies "results". Some attacks
will be in the ssh log, and others in the iptables ulogd.
Did you already configured your firewalls, network, and sshd_config?
good job! next chapter: your desktop ~/.ssh/config also allow the same
and more options (disable unused protos, ciphers, methods, etc). If
you're root of ssh client
machines, you should do the same in each one.
Greetings,
this mail is too long to see if I can DoS Debian servers delivering it. ;-P
--
Iñigo
Reply to: