jim g

With all the wanna be hackers running these ssh scripts to try to find no
password accounts or default passwords, how do you handle these people? I
use a program called fail2ban (Python script) that works well by blocking
the ip for 15 minutes on 4 invalid ssh logins. I have also tried changing
the port that ssh listens on to 10022. That works well but I found that I
have issues using sftp to my other servers.

Let me know how you handle these people and if you are successful.

Jim

johnny rebel

Hey,

I try and prevent them in the first place! I use a combination of
three things, different port, iptables, and tcpd. As I normally only
have a few addresses that I come from, I find this to be an ideal
combination in my cir***stance. I like the sound of that fail2ban on
top of that. I may have to look at that!

JR.

--

Bill will have to take Linux from my cold, dead flippers.

-Tux.

slackerama

Well like you, I use a similar program called DenyHosts that works
equally as well. Your best bet is to run ssh on a different port
(although a dedicated cracker will find it) use a program like
Fail2Ban or DenyHosts and simply disable password logins and use
public keys.

If public keys will not work in your environment, then re-enable
password logins and use the AllowUsers variable to list local accounts
that can use ssh.

john thompson

1) Configure sshd to only accept logins from specific users.
2) Ensure that these accounts have safe passwords.
3) ********ly deny remote "root" logins.
4) Use a script like "DenyHosts" or "BreakinGuard" to monitor access
attempts and automatically block IPs that generate some arbitrarily
small number of failed attempts in some arbitrarily brief period of
time.
5) Optionally reenable blocked hosts after some arbitrarily long period
of time.

--

John (john@os2.dhs.org)

randy yates

"Jim G" <jgrago@NOSPAM.twcny.rr.com> writes:


Hi Jim,

Regarding sftp, I've used scp -P portnumber (instead) with good success.
--
% Randy Yates % "...the answer lies within your soul
%% Fuquay-Varina, NC % 'cause no one knows which side
%%% 919-577-9882 % the coin will fall."
%%%% <yates@ieee.org> % 'Big Wheels', *Out of the Blue*, ELO
http://www.digitalsignallabs.com

f. michael orr

I make use of two sshd daemons. The standard SSH port is blocked at the
edge firewall to prevent outside connections. A non-standard port is
used to allow connections from the outside to thwart the simplest worms
and automated dictionary attacks. I also make use of the PAM config
files to silently lock a userid after 5 invalid passwords on both SSH
ports (but not on the local console), and cron a reset so the lockouts
are temporary. Because it is a silent lockout, even a dictionary attack
against the non-standard port is unlikely to succeed.

If you are dealing with a very small number of legitimate users, another
extremely useful technique is to require 'portknocking'. Google that; it
basically makes use of iptables and the 'recent' module to require a
specific sequence of ports to be touched by a client within a very small
window of time before the server will even begin to listen to any
requests. Nothing (other than iptables) need even be listening on those
ports. A small Perl or even VBasic script can then be distributed to
perform the portknocking, with random ports thrown in between to
discourage traffic mapping. Once the port-knocking is completed, the
source IP address has the right to try to authenticate against the
machine, but all of the above rules still apply. In addition, it can be
set up that the source IP has a 'grace period' (say 30 minutes) after
portknocking where it doesn't need to portknock again, so that standard
communications tools can be used without modification.

We were getting hammered by attempts before I implemented these
measures. Since then, I have yet to see any one yet get to the point of
trying a dictionary attack against our servers.

jim g

I am looking into this port knocking. Looks like it may be what I need. I
have 11 servers that get hammered with these dictionary attacks.

Thanks
Jim

ibuprofin

Are you accepting SSH connections from the entire world? Why? If
you are accepting such connections from a limited number of hosts and
you have users on those "authorized" hosts that are rattling the keys,
then maybe you need to re-think the idea of allowing those hosts. (My
firewall allows connections through from a /22 and two /24s "outside"
because I can't see any reason to allow connections from you or anyone
else that I haven't approved in advance, and I really don't expect
authorized users to be connecting from Korea, Kenya, Kuwait or
Kazakhstan or a lot of other places either)

Why allow them in the first place? (I dislike auto-blocking
mechanisms like this, as they can be used to have you shoot your
own foot. Requiring four invalid logins [over how long?] to trigger
the response reduces, but does not eliminate the chance to self-DOS your system.)


That's a good technique, but your secret port-number selector needs work.

Set access rules that ONLY allow sftp access to those specific IP
addresses. Are you a "world traveler" who may suddenly travel to
some exotic locations and need access without being able to pre-allow
the appropriate addresses? Set up a 'port-knocking' function, where
you must first attempt a connection to some specific _closed_ port

[compton ~]$ ls -l | tail -200 | head -1 | awk '{ print $5 }'
6365
[compton ~]$

like 'telnet server 6365' and have your firewall then open a rule to
that source IP for a minute that allows you to connect to whatever
port you've hidden the server on. You then SSH/sftp/what-ever in, and
the firewall 'ESTABLISHED' rule maintains the connection after the one
minute period. Note to the whiners who think this is security by
obscurity, you STILL NEED TO AUTHENTICATE - it's not replacing the
existing authentication mechanism. All it's doing is ignoring those
who don't know how to even start to connect. Also. I'm showing use of
'telnet' to generate the 'knock' packet to the CLOSED port because
that client is easy to use - you could equally try using your web
browser if that's the only application you can use - but it doesn't
matter because no connection will be made. If you're worrying
about someone tripping over the knock port while port-scanning, you
can add firewall rules that close the temporarily opened port if they
hit a nearby port before hitting the one where the server is (which
means having your server on [say] 2019, and having "close it" sensors
on 2007 and 2030 in this example).


What connection attempts?

Old guy

johnny rebel

I was getting hammered - until I changed the listening port... I went
from about 50 hits a day (easy), to nothing. Portknocking will send
your logs into a tizzy depending what you are logging. May a
combination of both a different port and portknocking would do great for
you. I personally put sshd well above the "ideal" scan range for most.

JR.


--

Bill will have to take Linux from my cold, dead flippers.

-Tux.

randy yates

Johnny Rebel <rebelATT@magmaDOTT.ca> writes:

JR, I agree. Moving my port number and blocking connections to all but a
few usernames reduced my sshd logs from a bunch to zero for quite a few
months now.

These other techniques are great, but probably overkill for anyone not
running a site with top secret classified information.
--
% Randy Yates % "I met someone who looks alot like you,
%% Fuquay-Varina, NC % she does the things you do,
%%% 919-577-9882 % but she is an IBM."
%%%% <yates@ieee.org> % 'Yours Truly, 2095', *Time*, ELO
http://www.digitalsignallabs.com