Re: Need urgent help regarding security

From: Josh Paetzel (josh_at_tcbug.org)
Date: 11/18/05

  • Next message: Timothy Smith: "FreeBSD-SA-05:21.openssl and 6.0" 
    To: freebsd-security@freebsd.org
Date: Fri, 18 Nov 2005 12:40:40 -0600

    On Friday 18 November 2005 01:20 am, ray@redshift.com wrote:
    > At 02:42 PM 11/18/2005 +1000, Timothy Smith wrote:
    > | i have seen a similar attack recently doing a brute force ssh.
    > | the number ONE weakness in most poorly run IT systems, is easy
    > | passwords. it's amazingly easy to brute force these systems using
    > | common names or variations of them.
    >
    > Speaking of SSH, if you have to provide SSH service via a public
    > IP# (and you are unable to limit traffic to just specific
    > management/workstation IP#'s), then it's always a good idea to
    > confirm that root login is not enabled in /etc/ssh/sshd_config.
    > This make a brute force attack much more difficult, since a
    > would-be attacker not only has to hit the correct password, but
    > they also have to know a valid username on the system (as opposed
    > to just using 'root') during an attack.
    >
    > Also, if you have access to the router, it's handy to re-write
    > traffic from a higher public port down to port 22 on the server,
    > since that will trip up anyone doing scans looking for a connect on
    > port 22 across a large number of IP's.
    >
    > Anyway, just a couple of ideas I thought might be helpful while on
    > the subject of SSH hardening :-)
    >
    > Ray

    Use public/private keys WITH hardened pass-phrases. If you aren't
    sure how secure your pass-phrases are run john the ripper on them.
    Allow only the bare minimum of remote networks to access ssh. Make
    sure that only the users that need shells have them. Make double
    sure that users for mail/pop do NOT have shells. Often-times
    brute-force attacks will be directed at account names gleamed from
    emails. 

    -- 
Thanks,
Josh Paetzel
_______________________________________________
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: Timothy Smith: "FreeBSD-SA-05:21.openssl and 6.0"

    Relevant Pages

    • Analysis of SSH crc32 compensation attack detector exploit
      ... Analysis of SSH crc32 compensation attack detector exploit ... detector vulnerability to remotely compromise a Red Hat Linux ... Active Internet connections (servers and established) ...
      (Incidents)
    • Re: Somebody is keep trying to ssh into my systems, how can I stop that?
      ... You are mistaken if you think your "secure", portknocking protected ssh ... open port. ... How many netfilter expoits that can successfully attack CLOSED PORTS have ... The object of security is not only to protect against remote priveledge ...
      (comp.os.linux.security)
    • Patching 4.4-RELEASE against SSHv1 exploit
      ... an SSH exploit has been specifically tuned to attack machines running ... FreeBSD 4.x and certain versions of SSH. ... >detector vulnerability to remotely compromise a Red Hat Linux ... >used against systems running OpenSSH 2.1.1 servers which suffer from ...
      (FreeBSD-Security)
    • Re: Need urgent help regarding security
      ... | i have seen a similar attack recently doing a brute force ssh. ... Speaking of SSH, if you have to provide SSH service via a public IP# (and you ... This make a brute force attack much more difficult, ... higher public port down to port 22 on the server, since that will trip up anyone ...
      (FreeBSD-Security)
    • Re: SSH port change
      ... attack attempts :-) ... The port it runs on does not increase or decrease the safety. ... The other reason to change port is because your provider is a bunch of ... Deny everthing from everywhere (on ssh only if you like) exept from ...
      (alt.os.linux.suse)