Re: SSH scans...

From: Michael H. Warfield (
Date: 12/21/04

  • Next message: L. Walker: "Worm hitting PHPbb2 Forums"
    Date: Mon, 20 Dec 2004 18:40:17 -0500
    To: Steve Kemp <>

    On Mon, Dec 20, 2004 at 10:13:58PM +0000, Steve Kemp wrote:
    > On Mon, Dec 20, 2004 at 10:45:55AM -0800, Raymond Lillard wrote:

    > > This should fail for at least these reasons:

    > > 1. "ssh" should be configured to prohibit root logins

            Reinforce and strengthen... "ssh" should always be configured
    to prohibit root logins.

    > Sometimes not an option. It's useful to backup machines
    > with rsync, or push updates out as root. Having a different
    > named account but still with UID isn't gaining much.

            Always an option. If you don't think it's an option, then
    you aren't thinking about it very intently or very clearly.

            Backups? No problem. Simple user id that is permitted one
    command that does a "sudo" for the server side of the backup. Two layers
    of protection. You only allow that specific "sudo backup_command" on
    connection (which you can do in the ssh configuration) AND you only
    allow "backup_command" in sudoers for that user id. Problem solved.
    Works great with rsync.

            I'm not sure what you mean by "Having a different named account
    but still with UID isn't gaining much". Did you mean "with UID 0"?
    Then I agree. That's bad practice. Have a named account with a simple
    UID and restrict the commands it can execute to only those commands you
    want for that account, which can include "sudo" accounts to provide the
    root access you need. Obviously pay attention to any application with
    shell escapes. :-(

            It may still be challenging to insure that the "rsync" is a backup
    direction and not a "restore" direction which can overwrite your config
    files, but it's still a barrier for the ankle bitters that are doing
    this kind of scanning. A little scripting goes a lllooonnnggg way here.

            "Pushing updates out as root" should be similarly marshalled but
    presents more challenge because you are performing updates to the system.
    Why not configure a "yum" repository back to your own site (and only your
    site) and then only allow that "update" to do a "yum update". That way
    you initiate the request but the remote system is still limited to where
    those updates can come from. You don't need arbitrary or summary update
    capability over that direct channel. There are much better ways to do it.
    (Apt-get for the debian-heads in the audience).

    > > 2. All machines should be configured to prohibit
    > > direct root logins except on the physical console

    > That seems a bit excessive. I usually setup controls by
    > IP address in /etc/hosts.allow, and /etc/hosts.deny. Then
    > limit incoming SSH connections via something like:

            Nope... With sudo available to you, the only time you should
    ever need a direct root login is for maintenance when you can't even
    reach multiuser mode. My biggest problem is that, after a few years
    (NO JOKE HERE), I forget what the root password is when I run into an
    fsck unexpected error and I HAVE to have the root password.

    > AllowUsers skx mp3 foo bar ...

    > That way even if there is a user called 'test' with
    > password 'test' (Extremely unlikely!) they cannot login.

    > > 3. Proper attention to passwords

    > Agreed. Backup with `john the ripper` if you don't think that
    > your users are following whatever password policy you have in
    > place.

            Yes. John the Ripper and Crack are your friends. As are
    cracklib in PAM. Turn on and enforce good password complexity checking.

            This is currently a soapbox for me as we are about to burn someone
    at the stake at my office for failing to conform to the above guidelines.
    If he survives, he won't be making that mistake again!

    > Steve
    > --
    > # Debian System Administration

            Another option... I prohibit all outside network access to
    ssh over IPv4. Since all IPv4 addresses have entire IPv6 networks assigned
    to them, you can always use 6to4 except over NAT (just don't use the
    default EUI of ::1 - bad choice there). If you have to deal with NAT,
    Freenet6 and SixXS both have clients that work over NAT. I have yet
    to find anywhere in the world where I could not get back to my IPv6
    access points and they can not be scanned for. Even ICMP "unreachables"
    come back from false addresses so they can't even be scanned for error
    return addresses. Some of them change their IPv6 address every 15 minutes
    and update DNS using TSIG signed dynamic updates (zone transfers are
    blocked). There is no where on IPv4 where you can stop IPv6 (Teredo
    rolls over firewalls like they weren't even there) so my access
    is better, more reliable, and more secure, over IPv6 than it ever
    was on IPv4.


     Michael H. Warfield    |  (770) 985-6132   |
      /\/\|=mhw=|\/\/       |  (678) 463-0932   |
      NIC whois:  MHW9      |  An optimist believes we live in the best of all
     PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

  • Next message: L. Walker: "Worm hitting PHPbb2 Forums"

    Relevant Pages

    • running programs from user acctount as root
      ... I have recently upgraded from FC6 to Fedora ... So then after several package updates & the total struggle of getting DVD, ... that require root access from my user account. ...
    • Re: [SLE] ksmarttray doesnt reflect true status unless run as root
      ... On Wednesday 26 July 2006 17:39, Stephen Boddy wrote: ... bugging me for the root password every login. ... I would fully expect to have to enter root password for this. ... updates) does not work unless it is run as root. ...
    • Re: [SLE] ksmarttray doesnt reflect true status unless run as root
      ... bugging me for the root password every login. ... I'm using it in the smart sense where it updates the cached channel info, ... do the "smart update" command. ...
    • Re: Is SuSe ready for me yet?
      ... this without having to become root, ... OK, I can believe the non-CLI part, but how can you do updates without ... This then reminds me of the fact that the user has too many rights and ... A user should not be able to do system-wide installation. ...