Re: Repeated attacks via SSH

From: Kevin Day (toasty_at_dragondata.com)
Date: 10/03/05

  • Next message: Brett Glass: "Re: Repeated attacks via SSH" 
    Date: Sun, 2 Oct 2005 18:05:16 -0500
To: Brett Glass <brett@lariat.org>

    On Oct 2, 2005, at 5:01 PM, Brett Glass wrote:

    > Everyone:
    >
    > We're starting to see a rash of password guessing attacks via SSH
    > on all of our exposed BSD servers which are running an SSH daemon.
    > They're coming from multiple addresses, which makes us suspect that
    > they're being carried out by a network of "bots" rather than a
    > single attacker.
    >
    > But wait... there's more. The interesting thing about these attacks
    > is that the user IDs for which passwords are being guessed aren't
    > coming from a completely fixed list. Besides guessing at the
    > passwords for root, toor, news, admin, test, guest, webmaster,
    > sshd, and mysql, the bots are also trying to get into our mail
    > exchangers via user IDs which are the actual names of users for
    > whom the machines receive mail. In one case, we saw an attempt to
    > use the name of a user who hadn't been on for years but whose
    > address was published ONCE (according to Google and AltaVista) on
    > the Net. Since the attackers are not guessing at hundreds of
    > invalid user names, the only conclusion we can draw is that when
    > one of the bots attacks a mail server, it quickly tries to harvest
    > e-mail addresses from the server's domain from the Net and then
    > tries them, in the hope that those users (a) are enabled for SSH
    > and (b) have weak passwords.
    >
    > SSH is enabled by default in most BSD-ish operating systems, and
    > this makes us a bigger target for these bots than users of OSes
    > that don't come with SSH (not that they're not more vulnerable in
    > other ways!). Therefore, it's strongly recommended that, where
    > practical, everyone limit SSH logins to the minimum possible number
    > of users via the "AllowUsers" directive. We also have a log monitor
    > that watches the logs (/var/log/auth.log in particular) and
    > blackholes hosts that seem to be trying to break in via SSH.
    >
    > --Brett Glass

    This is pretty common, I'm afraid. SSH scanning with brute force
    password guessing has gone through the roof in the last 9-12 months,
    but it's been going on for years.

    We announce a /19 worth of space, and see several hundred ssh
    connects per second across it. The amount of junk port 22 traffic has
    exceeded the amount of junk port 25 traffic for us now.

    The best practice I can advise you with:

    Block port 22 traffic at your ingress for hosts that don't need to
    accept ssh connections. Turn off SSH on boxes that don't need it at
    all. If you only ever need to connect from a small list of hosts,
    block port 22 from anything but those.

    _______________________________________________
    freebsd-security@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-security
    To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"

  • Next message: Brett Glass: "Re: Repeated attacks via SSH"

    Relevant Pages

    • Re: Password Guessing
      ... Geoff Dolman wrote: ... > Other guesses are clearly dictionary attacks: ... > genuine users were potentially denied access if a password guessing ... to SSH, and deny access to all others. ...
      (comp.security.ssh)
    • Re: Repeated attacks via SSH
      ... We're starting to see a rash of password guessing attacks via SSH ... on all of our exposed BSD servers which are running an SSH daemon. ... they're being carried out by a network of "bots" rather than a single ... is that the user IDs for which passwords are being guessed aren't ...
      (FreeBSD-Security)
    • Repeated attacks via SSH
      ... We're starting to see a rash of password guessing attacks via SSH ... is that the user IDs for which passwords are being guessed aren't ...
      (FreeBSD-Security)
    • Re: ssd attacks; worm? and precautionary steps
      ... > responsible for these attacks have a name yet? ... In my ssh server, I do not allow root login remotely and allow only ... > BREAKIN ATTEMPT! ... > passwords now. ...
      (comp.os.linux.security)
    • UPDATE Re: rlogin - security question [expanded to smartcard technology]
      ... explinations of ssh etc. ... 0-13-100092-6) with the words "The Official Sun Microsystems Resource ... place root / users cannot set/change passwords. ... > we are required to allow rlogin access to all by means of .rhosts files. ...
      (SunManagers)
    • Quantcast