Re: [Fwd: security]

[smj@littleprojects.org]

On Sat, Jan 29, 2005 at 03:05:35PM +0000, michael wrote:
> On debian-user it was suggested I also post this here, thanks, Michael
> -------- Forwarded Message --------
> From: michael <linux@networkingnewsletter.org.uk>
> To: debian user <debian-user@lists.debian.org>
> Subject: security
> Date: Fri, 28 Jan 2005 09:46:31 +0000
> I notice that frequently many machines around here get attacked by a
> potential hacker (a prog I guess) trying lots of usernames to get in to
> all the machines, using the same set of usernames at the same time. Have
> people seen this on their machines? I'm guessing it's a virus/worm on a
> Windows box doing this but does anybody know more? 
> 
> I've followed & done most of the suggestions listed in chpts 4 & 5 of
> "Securing Debian" HowTo/Manual although I will admit to not following
> and therefore not having got around to firewalling. Other suggestions
> most welcome.
> 

There are a lot of SSH brute force attacking scripts out there right
now.  I see them here at home and I see them try to get into the work
machines all of the time.  A firewall will help you, but you will want
to ensure that SSH is secured as well.

First you must ask yourself:  What do these boxen do that you want to
protect?  Are they web servers?  Are they directly exposed to the
Internet?  Are they file servers?  Are they only exposed to the internal
LAN?  What function do they serve?

Once you know this, you can decide what to do with a firewall should you
decide to use one.

My policy has always been to enable firewalls on all boxes that I
administer, and controlling what I allow in, my personal workstation
being no exception.  Iptables is not that difficult to learn and with a
good understanding of TCP/IP, you can develop a list of rules that suits
the computer very well.

I have NEVER run an Internet-exposed computer without a firewall for
longer than 1 minute.  And I regretted giving them that long.

Iptables has several different targets that it sends matched rules to.
ACCEPT, REJECT, and DROP are the most commonly used.  ACCEPT allows the
connection in, REJECT closes the connection, effectively telling the
other side that the given port is not listening, but DROP sends nothing
back, making port scanners take forever from the attackers perspective.
My friend calls this "making your box a black hole on the Internet".
Packets get in, but no response is ever sent, so the attacker has to
time out the connection himself.

But I digress, your original concern was the SSH scan.  I do the
following to secure all of my SSH connections.  You will need to edit
/etc/ssh/sshd_config:

Debian Woody may do a lot of these by default.  I've been administering 
SSH for a while on many different *NIXes (Solaris, HP/UX, RedHat, etc.)
and don't remember the diffs.

1.  Enable SSH Protocol version 2 ONLY.  SSH Protocol version 1 has some 
    security flaws with known exploits.  This can be done commenting out 
    (or removing)
      Protocol 2,1
    and replacing it with
      Protocol 2

    The downside to doing this is that clients that don't speak SSH protocol
    version 2 cannot connect, but most folks have upgraded nowadays anyways.

2.  Make sure Privilege Separation is turned on by setting:
      UsePrivilegeSeparation yes

    This creates a child process that does not run as root for incoming
    connections.  The benefit of this is that a buffer overflow crashing
    the process will not give the attacker the identity of root.

    The default for this should be yes and I believe Woody comes this
    way.

3.  Make sure root can not log in:
      PermitRootLogin no

    This may be a pain from the perspective of system administration,
    but you really don't want someone to log in as root from remote for
    auditing purposes anyway.  Always su!

4.  Make sure .rhost and hosts.equiv authentication is not used
      RhostsAuthentication no
      IgnoreRhosts yes
      HostbasedAuthentication no

    This is a holdover from the use of .rhosts and /etc/hosts.equiv
    files for authentication.  Do not enable it for it bypasses the 
    password authentication process.

5.  Depending on the laws where you live, a simple login banner can
    protect you.  I usually put in some snappy legalese text that's
    been approved by my employer's legal office in the file /etc/issue.
      Banner /etc/issue

Looking at my own sshd file on Debian Woody, I see that most of these
are set appropriately for my needs.  I hope this helps to some degree.
You should really do a man sshd_config to learn what your options are
and figure out what works best for each machine you administer.

Hope this diatribe helps.

--Shawn