<---- template headericclude ----->
SSH Security
FedoraForum.org - Fedora Support Forums and Community
Page 1 of 2 12 LastLast
Results 1 to 15 of 18
  1. #1
    Join Date
    Aug 2011
    Location
    Luton, UK
    Age
    38
    Posts
    291
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    SSH Security

    I've recently started experimenting with SSH, more out of interest/as a learning point than having any serious use in mind at present (short of sending files between my PC and netbook), and was curious about which security options exist for it beyond those I've implemented, and how relatively secure my current set-up would be considered - obviously more secure than a vanilla SSH service, but how much more?

    The steps I've taken so far are:

    - Having passphrase-enabled 2048-bit RSA keys on my netbook and PC
    - Only having Protocol 2 enabled (sshd_config)
    - Changing the default listening port (sshd_config)
    - Denying root login (sshd_config)
    - Reducing LoginGraceTime to 30s (sshd_config)
    - Setting HostbasedAuthentication and RhostsRSAAuthentication to 'no' (sshd_config)
    - Only turning the sshd service on when I'm using it!

    Everything else is as per the F16 default settings. Are there any glaring omissions from this list that immediately stand out? For instance, is there an option that prevents login without having exchanged public keys, and is it recommended that it be used? (I know there'd be a security versus convenience trade-off there, if I wanted to sign in to my home PC from a remote PC I hadn't exchanged keys with yet e.g. at a friend's house)

    Thinking further down the line, would this setup be considered secure enough to reasonably have sshd run on startup, rather than having to turn it on and off with each use? I'm just a home user, rather than securing a business/government organisation's connection, but it doesn't hurt to do a job at least reasonably well!
    I generally use two tools - trial and error. They fix most things eventually!

  2. #2
    Join Date
    Oct 2009
    Posts
    824
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: SSH Security

    Altering the listening port is pointless. It will only block out the dumbest of moronic script kiddies. To demonstrate why this is, run the command "telnet serveripordomain sshlisteningportnumber" --> Notice how it identifies in plaintext, how it is an ssh server? Further, it is quite simple to test services for common protocols, even when they don't identify themselves like that.

    Right, so someone who is only *slightly* above the level of 'complete imbecile', will scan your server for what ports it is listening on, and TEST them for common protocols before beginning their attack.

    What I would definitely add to your list of steps, is denyhosts (or similar). This software will count failed login attempts and shut down that IP address when the failed attempts exceed some threshold that you set. I set mine to 2.

    Now the predominant issue for securing an SSH server is in knowing what you are connecting to. This is primarily a problem on the first connection, when public keys are exchanged. Subsequent connections will compare the exchanged keys and warn you if they don't match. I.e., if the keys don't match, the host you are connecting to must be a fake, trying to steal your password. Note that this attack only works if you are using password-based authentication, and aren't paying attention to the key exchange. Setting PasswordAuthentication to "no" in the sshd_config file will be the biggest step in securing your ssh server. Following this, you will generate user keys on the server and install them on the client. Without the client key, you cannot connect.

  3. #3
    Join Date
    Aug 2011
    Location
    Luton, UK
    Age
    38
    Posts
    291
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: SSH Security

    Right - I'll put my listening ports back to default then, if that makes so little difference. Saves me having to remember to enter the correct port every time!

    As a point of curiosity, if denyhosts blocks an address, can you manually unblock it? I ask because I have a friend who's fairly new to Fedora and who's very keen to learn as much as they can about it, but they tend to be a bit headstrong, and I can see them accidentally banning themselves on a local network

    And just to confirm I'm following correctly; by setting PasswordAuthentication to 'no', if anyone were to attempt to log onto the server without holding a private key that matches a public key already on there, they'd be refused outright? That sounds closer to the sort of security level I like
    I generally use two tools - trial and error. They fix most things eventually!

  4. #4
    Join Date
    Jul 2005
    Age
    63
    Posts
    1,218
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: SSH Security

    denyhosts is good.

    Setting your firewall to only allow access to the port from known addresses that you will be connecting from is better when possible. If you're roaming around the country, it wouldn't be possible. If you're only connecting from school/work/known friends, then a short list of IP addresses that can connect is good.

    Eliminating password logins (or at least remote password logins) is the major thing. Limiting your IP exposure just limits exposure to any exploits that could be discovered in the ssh code in the future.

    Of course - yum update can be your friend in keeping security issues from being a major problem.

  5. #5
    stevea Guest

    Re: SSH Security

    - Having passphrase-enabled 2048-bit RSA keys on my netbook and PC

    This is good. Longest key length available. Passphrase adds another 'part; to the authentication. If you key file is stolen it's still no good. The limitation is that adding keys doesn't prevent other weaker authentication methods like password login unless you disable these.


    - Only having Protocol 2 enabled (sshd_config)
    Uses the stronger amongst of crypt methods.

    - Changing the default listening port (sshd_config)
    This is not true security, but don't discount it if you allow password authentication. If someone is scanning random IPs looking for ssh then this makes your system low profile. Yes script kiddies do this, but there is no reason to think that more aggressive random attackers don't too. . OTOH if someone it trying hard to crack your specific system this provides virtually no protection. I think its a good practice, to avoid most random attacks.

    - Denying root login (sshd_config)
    I've argued this point before, but most PCs have one one or two accounts with any real valuable content. If some jackass hacks your system do you really think its any worse if that have root instead of just your account ? I don't. The "don't login as root" idea makes a lot of sens on timeshare systems of the past and multiuser corporate systems. For home PCs its not worth as much as the alarmists claim. Perhaps a good practice, but it doesn't help if the user-accounts can login and they contain all the goods.

    If you feel this is useful, then restricting ssh logins to just listed accounts is even better. AllowUsers


    - Reducing LoginGraceTime to 30s (sshd_config)
    Makes certain DoS attacks microscopically less practical. Don't care.

    - Setting HostbasedAuthentication and RhostsRSAAuthentication to 'no' (sshd_config)
    Yes these are the weakest athentication culprits, but you should dissallow all authentications you don't need. The following only allows key login.

    ChallengeResponseAuthentication no
    GSSAPIAuthentication no
    KerberosAuthentication no
    PasswordAuthentication no
    PubkeyAuthentication yes
    RSAAuthentication no
    RhostsRSAAuthentication no



    - Only turning the sshd service on when I'm using it!
    This is a 'profile reduction' not real security. I'm not a fan. The point of sshd is to give you access when you are away and that many mean at unpredictable times. So let me suggest an alternative scheme.

    You can make two alternative iptables that are otherwise identical, but one blocks port 22 (or other sshd port) syn packets and the other does not; toggling the acceptance of the "-state NEW ...ACCEPT" feature for port 22. Then you arrange a script that install the more liberal config for just 30 seconds, then restores the more restrictive one. You are basically only allowing a login fo rthe 3 second interfal after the script is triggeed.

    You can use openssl and some of the ssh key-pairs (from known hosts) to encrypt/decrypt the packets, but the message itself should be something like 'passphrase:time'
    $ date +"Beat me with your rhythm sticks:%s"
    Beat me with your rhythm sticks:1341377618
    On the receiving side, after decryption, the passphrase is of course checked, but the date is verified t be accurate with a few seconds (requires use of ntp or chrony) of current time.

    This prevents any connection to the ssh port until you've first sent a magic packet. Then you have a tiny tiny window to try a key login.

    It's still a bit of work for a very minor gain..

    ---

    Bottom line - by disallowing anything but key authentication it means no one can even try a password. If they can't resent a proper key they are bounced. with 2k bit bits there are 2^2048 keys possible and no one can brute-force that. Any thing more is just gravy.


    Everything else is as per the F16 default settings. Are there any glaring omissions from this list that immediately stand out? For instance, is there an option that prevents login without having exchanged public keys, and is it recommended that it be used? (I know there'd be a security versus convenience trade-off there, if I wanted to sign in to my home PC from a remote PC I hadn't exchanged keys with yet e.g. at a friend's house)
    IMO the main weakness in sshd default config is that it allows password and rsa & Challenge authentication. Passwords stink - weak and exploitable.. Very few home users use kerberos and maybe should be disallowed by default.

    No the big issue is to use keys (ideally w/ pass-phrases) and disallow every other authentication method.
    You can centrally manage the user keys instead of allowing users to chenge them. Not much improvement if you allow logins.



    Thinking further down the line, would this setup be considered secure enough to reasonably have sshd run on startup, rather than having to turn it on and off with each use? I'm just a home user, rather than securing a business/government organisation's connection, but it doesn't hurt to do a job at least reasonably well!
    I've seem many corporate nets that have an ssh password-authentiation scheme to the outside world. Yours using keys and then dis-allowing passwAuth is a big boost and prevents script-kiddies. So it's beyond industrial strength. I run similar 24x7.

    ---------- Post added at 01:57 AM ---------- Previous post was at 01:42 AM ----------

    I'm really not a fan of denyhosts, unless you always know in advance what your few specific IPs are it's an overly restrictive system. Think of it this way - you are trying to filter out th bad guys using their 32 or 128 bit IP addresses which are weak identification. That means you exclude some good IPs and include some bad IPs - a lousy leaky filter. When you have a private, controlled access 2048bit keys at your access - denyhosts is silly for ssh. Use keys instead.
    Last edited by stevea; 4th July 2012 at 07:06 AM.

  6. #6
    Join Date
    Aug 2011
    Location
    Luton, UK
    Age
    38
    Posts
    291
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: SSH Security

    I'll have a look at disallowing those other authentications - thank you!

    As for denyhosts; interesting to see a conflicting opinion - searching online, it seems like every man and his dog recommends it! I can see your point though; I suppose having keys locks out attackers regardless. I also misunderstood what denyhosts was initially - just to confirm I've got it right in my head now, rather than being a constantly-running program, it's a script that you run manually/on start-up/whatever, right?

    Is there any value, as a home user or as a corporate user, in having denyhosts cover all services rather than just sshd, or are those same issues stevea mentioned just magnified?
    I generally use two tools - trial and error. They fix most things eventually!

  7. #7
    stevea Guest

    Re: SSH Security

    Quote Originally Posted by droidhacker
    Altering the listening port is pointless. It will only block out the dumbest of moronic script kiddies.

    To demonstrate why this is, run the command "telnet serveripordomain sshlisteningportnumber" --> Notice how it identifies in plaintext, how it is an ssh server? Further, it is quite simple to test services for common protocols, even when they don't identify themselves like that.

    Right, so someone who is only *slightly* above the level of 'complete imbecile', will scan your server for what ports it is listening on, and TEST them for common protocols before beginning their attack.
    The false dichotomy you propose is imbecile vs smart attackers.
    The correct dichotomy is random vs targeted attackers.
    Random attackers of ssh whether dumb script kiddies or the Iranian army are likely to look at port 22 first, foremost and perhaps solely. Yes, a targeted attack against your IP would easily show any ssh port; that doesn't mean mass random attacker will look beyond port 22.

    What I would definitely add to your list of steps, is denyhosts (or similar). This software will count failed login attempts and shut down that IP address when the failed attempts exceed some threshold that you set. I set mine to 2.
    Denyhosts is pointless unless you are using crummy little <100bit passwords. Adds nothing practical to 2048 bit keys.


    Now the predominant issue for securing an SSH server is in knowing what you are connecting to. This is primarily a problem on the first connection, when public keys are exchanged.
    Your vagueness makes your statements wrong without context. There is an exchange of public HOST keys which has absolutely nothing to do with USER auth keys. User authentication keys are never exchanged except at installation.

    There are two symmetric problems. Server identifying the client-user and client user identifying the server. For key authntication , ifyour user authentication key crypt is accepted by the server, then the server can be quite certain that YOU have the private key corresponding to the public key in USER/.ssh/authorized_keys . The client also requires a return crypt demonstrating the server has the corresponding public key. The user public key management and control is lesser, but it's still decent identification.

    When you login with a passwords the server's entire assurance of the user identity is the <username,passwd> credential (which are generally cr*p) and the client's has nearly zero assurance it's not a fake server unless they compare the host keys. You'll get a host key install message, but you get that anytime you access the server by a distinct IP or hostname or if the server got new keys (a new fedora install). It's pretty weak both ways compared to user keys.


    Subsequent connections will compare the exchanged keys and warn you if they don't match. I.e., if the keys don't match, the host you are connecting to must be a faketrying to steal your password.
    That's only one meaning. You get a 'new entry' host-pub-key message every time you access the server by a distinct name. (192.168.1.12 vs myserv, vs myserv.local vs myserv.dyndns.con ...). And those get created w/o breaking the connection. When you get a mismatch message it can mean the sshd server was re-installed (a biannual event for many fedorans). You also ignore that the host protocol setup also supports multiple keys and associated public keys - so it could mean a different key-pair was used. Mismatch in my experience rarely means fake, but it's properly worrisome.

    So this minor level of assurance for the server ident is useless when you get out in the field and find your home server has a new IP address or your laptop doesn't have the pub-host-key for the dynamic dns address.

    If you want real host ident assurance you can setup CA certs through a verisign type service (read the ssh-keygen man page for certificates of authority) - but that's expensive.


    Note that this attack only works if you are using password-based authentication, and aren't paying attention to the key exchange. Setting PasswordAuthentication to "no" in the sshd_config file will be the biggest step in securing your ssh server. Following this, you will generate user keys on the server and install them on the client. Without the client key, you cannot connect.
    Yes - we agree - except <username,passwds> is not the only shabby authentication on th list. RSA/rhosts stuff is perhaps worse. GSSAPI and Kerberos can be good - but if you aren't using them they slow the process, and offer added risk.

  8. #8
    Join Date
    Aug 2010
    Location
    Al Ain, UAE
    Posts
    2,028
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: SSH Security

    Howdy,

    IMHO changing the default port is beneficial, since the dumbest of the dumb script kiddies vastly outnumber the smart arses.

    Changing the port number reduces the network traffic. Otherwise your machine will suffer a pointless brute force attack multiple times per day, as opposed to multiple times per year.

  9. #9
    stevea Guest

    Re: SSH Security

    Quote Originally Posted by Bazu135
    ...

    As for denyhosts; interesting to see a conflicting opinion - searching online, it seems like every man and his dog recommends it! I can see your point though; I suppose having keys locks out attackers regardless. I also misunderstood what denyhosts was initially - just to confirm I've got it right in my head now, rather than being a constantly-running program, it's a script that you run manually/on start-up/whatever, right?

    Is there any value, as a home user or as a corporate user, in having denyhosts cover all services rather than just sshd, or are those same issues stevea mentioned just magnified?
    Lets name the packages. denyhosts digs through security logs and creates new /etc/hosts.deny entries for ssh only, based on failed login attempts. This is like buying insurance after your house burns down. There are millions of script kiddies on the planet and you aren't gonna list all their IPs. If you did you'd soon find you are blocking legit addresses too. Most of us live on private LANs that NAT to public IPs, or else we get dynamically assigned IPs. The IPv6 address case is actually worse.

    The tcp-wrappers package includes a tool 'tcpd' that is inserted between your service (like tftpd or sshd) and the interface. So when you get a new service request or a connection request - tcpd is the first software to see the first packet. tcpd examines /etc/hosts.{allow,deny} and determines id the source IP is allowed for this particular service. If the IP address passes - then the service is exec'd or ... , if not then the packet is dropped.

    So the first problem; Where do you get valid lists of good vs evil IPs ?
    If you only access the service from a few stable IPs - that's perfect. You allow those and deny everything else. But realize that everyone on your private LAN (maybe your company or hotel or conference center, starbucks) may have exactly the same public IP as you and there a reasonable chance some can see your traffic. So not ideal but something.

    If you don't know the IPs in advance (often the case) then maybe you find a web service that lists a few evil-doers months old IPs, but then you have the headache that the list is incomplete and not current and can block valid uses. Imagine the headache when you get to a hotel on the other side of the continent and realize you can't ssh home b/c some previous hotel guest got them on the blacklist.

    Nah - it's a terrible approach. You can't rationally assign IPs to a good or bad pile except in the rare case where you know the few good *fixed* IPs in advance, and can afford to list everything else as bad.

    ----

    Now we can afford to be this arrogant about tcp-wrapper's approach b/c we use ssh keys, or even ssh with very good passwords (100+ bits of entropy). But what is we wanted to make some other service publicly available and that service didn't allow 2k bit keys ?

    My first advice to a home/soho user is DON'T make any service publicly available except ssh using keys and disallowing password login. With ssh you get this great secure key login and after that succeeds - then you can forward ports for any local service like email or cups in a secure protected fashion.

    For example I run a soho mail server here at home that requires access to mail.localdomain ports 25, and 993. My laptop thunderbird settings are setup for that. But when I go on the road I can do this ....
    make (uncomment) an /etc/hosts entry like
    127.0.0.1 mail.localdomain mail
    then I ssh to my home system (not the mailserver) like ....
    ssh -p 443 steveasoho.dyndns.foo -L 25:mail:25 -L 993:mail:993
    then my thunderbird works perfectly with no changes from anywhere and all the traffic is protected by the ssh security. No imap or smtp exploits to worry about.


    Of course if you want to make services available to the general public that's not a reasonable approach. I really don't think the blacklist approach for IPs has a lot of value. A list of verified white-list IPs may be useful. I'd be very reluctant to run a weak protocol like ftpd from any server. http/apache security is an advanced topic far outside my skill set. The point is if you expose a service to public attention you will get exploit attempts. If you can only expose the service to a restricted whitelist that may be useful. If you are dependent on blacklists you are just reducing th number of attacks a bit. sshd with keys/!passwds is the one service an amateur can configure to withstand anything. A vpn like openvpn is another.
    Last edited by stevea; 7th July 2012 at 01:06 AM.

  10. #10
    Join Date
    Aug 2011
    Location
    Luton, UK
    Age
    38
    Posts
    291
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: SSH Security

    This all makes for really interesting reading - I'm glad I asked now!

    It does sound like denyhosts is rendered basically unnecessary if RSA keys are used, so I might go ahead and drop that one. That's an interesting argument re: script kiddies too - but how much is that amount of network traffic (multiple attacks - a lot of traffic? A little?) likely to affect a network, particularly a SOHO one?
    I generally use two tools - trial and error. They fix most things eventually!

  11. #11
    Join Date
    Aug 2010
    Location
    Al Ain, UAE
    Posts
    2,028
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: SSH Security

    I regularly saw 10,000 password attempts per hour on my servers. I fixed it with a simple iptables rate limiting rule. Now kiddies do 4 attempts, then move along.

    iptables -A INPUT -p tcp -m state --syn --state NEW --dport ssh -m limit --limit 1/minute --limit-burst 3 -j ACCEPT
    iptables -A INPUT -p tcp -m state --syn --state NEW --dport ssh -j DROP

    That will defeat even the most patient hacker...
    Last edited by flyingfsck; 5th July 2012 at 10:48 AM.

  12. #12
    Join Date
    Aug 2011
    Location
    Luton, UK
    Age
    38
    Posts
    291
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: SSH Security

    Yikes! I'll definitely have to have a look at that - which log would that info be found in, if any?

    Working from the iptable man page, have I understood that command correctly? I read it as:

    Append to INPUT the rule "if more than one new tcp connection is made to the SSH port per minute, increment a count which will drop all future packets from the sender's address once the count exceeds 3. If the count is 3 or less, accept the packet."
    Assuming that's correct, how long would that 'drop' command last for before resetting, or would it have to be manually reset?

    Apologies for all the questions; the most firewall configuring I've done has been a custom port through the GUI, so I'm trying to learn what I can while I have the chance!
    I generally use two tools - trial and error. They fix most things eventually!

  13. #13
    Join Date
    Aug 2010
    Location
    Al Ain, UAE
    Posts
    2,028
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: SSH Security

    The iptables rate limit module works very well. If you are a legit user who knows your password then SSH works normally, otherwise the slowdown persists for a few minutes. Any brute force attempt from a single IP address turns into a crawl, which makes them give up and go away.

    I can't remember exactly which log file to look at, but it is pretty obvious if you trawl through /var/log.

    The big advantage of doing it this way, is that you cannot accidentally lock yourself out of your own server, as could happen with the ip bannning type of utilities.

  14. #14
    Join Date
    Aug 2011
    Location
    Luton, UK
    Age
    38
    Posts
    291
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: SSH Security

    /var/log/secure seems to be the one; it certainly lists all my ssh logins from various local points - and none from anywhere else, thankfully!

    It wouldn't hurt to implement that rule set then, by the looks of things - if I'm gonna sit and do the job well, that seems like a better system than denyhosts While it sounds unnecessary, I find it never hurts to know how to take something back - so how would one 'undo' adding that to iptable?
    I generally use two tools - trial and error. They fix most things eventually!

  15. #15
    Join Date
    Aug 2010
    Location
    Al Ain, UAE
    Posts
    2,028
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: SSH Security

    Deleting individual rules is painful:
    iptables [-t table] -D chain rulenum
    ie:
    # iptables -L
    # iptables -D INPUT 4

    Usually, it is easier to simply delete them all:
    # iptables -F INPUT

    Read the iptables man page about 10 times. It will eventually make some sense.

Page 1 of 2 12 LastLast

Similar Threads

  1. Replies: 3
    Last Post: 20th May 2012, 07:14 PM
  2. Replies: 3
    Last Post: 4th November 2011, 12:14 AM
  3. GNOME Security - A Remix of the Fedora Security Spin for Security Auditing
    By sullivanmatt in forum Fedora Spins & Remixes
    Replies: 0
    Last Post: 31st May 2010, 06:48 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
[[template footer(Guest)]]