regoli

Q: Stopping brute force ssh attacks on OS X Server 4?

OK, well the new year has brought out a slew of fresh IPs (mostly from Hong Kong, and China) trying to login to my machine (running OS X Yosemite 10.10.1 Server 4.0.3).

 

I have enabled the adaptive firewall (per http://help.apple.com/advancedserveradmin/mac/4.0/#/apd4288B31F-0C3D-4004-9480-4 B7E0AFBB818) and yet the attacks continue unabated.  Multiple IPs from one class C address block, for instance—flipping between three different IPs—are hitting my machine once per second over the course of dozens of hours. Yet the firewall is doing nothing to block those IP(s). They either walk through and try a list of bogus accounts, or continually hammer the root account. 

 

I have configured just a few users access to ssh via the server application. But short of disabling sshd—which is not ideal—what are the strategies for combating these attacks?  Is the best route to use the /etc/hosts.allow and /etc/hosts.deny files to configure access for sshd?


Thanks for any tips!  —michael


Mac mini, OS X Yosemite (10.10.1), Server 4

Posted on Jan 22, 2015 4:40 PM

Close

Q: Stopping brute force ssh attacks on OS X Server 4?

  • All replies
  • Helpful answers

  • by Linc Davis,Helpful

    Linc Davis Linc Davis Jan 22, 2015 5:52 PM in response to regoli
    Level 10 (207,990 points)
    Applications
    Jan 22, 2015 5:52 PM in response to regoli

    The default configuration of the adaptive firewall doesn't actually work, though the documentation doesn't bother to mention that fact. You have to edit the file /etc/af.plist. Change the value of the key "firewall_address" from the default "127.0.0.1" to the IP address of the interface on which the server listens.


    I prefer to augment the AF with sshGuard.

  • by John Lockwood,Helpful

    John Lockwood John Lockwood Jan 23, 2015 2:51 AM in response to regoli
    Level 6 (9,324 points)
    Servers Enterprise
    Jan 23, 2015 2:51 AM in response to regoli

    I fail to see the merit of allowing SSH to be accessible via the Internet at all. Just completely that port in your firewall. Then when you yourself legitimately need to SSH in to your server do it via a VPN connection.

     

    In general the only ports that should be open are 80 for http, 443 for https and various email service ports if your running your own mail server. If your running an MDM then you also need Apple's Push Notification ports open and of course the afore mentioned VPN and its ports.

     

    Other services like SSH, Telnet, VNC, FTP, SFTP, SMB, AFP, NFS, MySQL, etc. etc. should all be completely blocked.

  • by regoli,

    regoli regoli Jan 23, 2015 5:50 AM in response to John Lockwood
    Level 1 (10 points)
    Jan 23, 2015 5:50 AM in response to John Lockwood

    Thank you for the responses! This machine is host to several web sites that require its caregivers—located around the country—to remotely access the machine to update their files. They do this through sftp/ssh. Sounds like with a third party app like sshGuard as Linc Davis mentions, along with configuring a VPN, is the best way to stop this.

     

    John's point is a good one: enable only the services you absolutely need, shut off the rest.

     

    As a stop gap, I had thought of moving the TCP port for ssh higher which would mitigate this to a degree, as all other ports are shut down at the router to prevent port scanning of the machine.  —michael

  • by Linc Davis,

    Linc Davis Linc Davis Jan 23, 2015 7:50 AM in response to regoli
    Level 10 (207,990 points)
    Applications
    Jan 23, 2015 7:50 AM in response to regoli

    There's nothing wrong with allowing SSH access from the Internet if you need it and if the server is properly secured. Password logins should not be allowed unless absolutely necessary. Otherwise, use public-key authentication only.

     

    Changing the SSH port to a non-standard one may reduce the number of scripted attacks shown in the log, but it won't reduce the chance of a successful attack. The kind of attacker who might actually succeed in cracking your server won't be hindered at all by such an ineffective countermeasure. And changing to a high-numbered port (1024 or higher) carries security risks of its own, because such a port could be bound by an unprivileged process.

  • by doso,

    doso doso Jan 23, 2015 1:34 PM in response to regoli
    Level 1 (14 points)
    Servers Enterprise
    Jan 23, 2015 1:34 PM in response to regoli

    I'm investigating the same issue (albeit on Mountain Lion Server). On our linux servers we often use a whitelist to allow ssh only from a fixed set of IP addresses. This solution would suit me well on our OSX server as well, but so far I haven't found how to do that. It seems like the pf program is the one to use, but the documentation is quite overwhelming. Does anyone have an opinion on whether to use pf? Or would it be wiser to use SSHGuard (which I don't know yet either) ?

     

    thanks!

  • by berkinet,

    berkinet berkinet Jan 23, 2015 3:00 PM in response to Linc Davis
    Level 1 (0 points)
    Jan 23, 2015 3:00 PM in response to Linc Davis

    If I am NOT on 10.10 server (I.e. I don't have server.app installed), is there a way to still block specific IP Addresses automatically.

    BTW, I can easily copy serverctl and afctl from another machine where I do run server.app - but, will they actually work on a "non-server" machine?

     

    Note, when I try to run pfctl I get messages like:

    # /sbin/pfctl -t show

    No ALTQ support in kernel

    ALTQ related functions disabled

  • by regoli,

    regoli regoli Jan 24, 2015 8:12 AM in response to berkinet
    Level 1 (10 points)
    Jan 24, 2015 8:12 AM in response to berkinet

    Apparently the adaptive firewall isn't very robust (see above). I have seen it block certain attempts automatically, but it doesn't do so for brute force attempts.   And everything I've read about it says to ignore the message "No ALTQ support in kernel".  (There are several references here and here.)

     

    For more, see: OS X Server: How to enable the adaptive firewall - Apple Support

     

    I use this command when I want to stop an attack immediately from one IP:

    sudo /Applications/Server.app/Contents/ServerRoot/usr/libexec/afctl -a 123.123.123.123

     

    afctl accepts CDIR notation, so this is useful to block an entire class C address from the 123.123.123.0 network:

    sudo /Applications/Server.app/Contents/ServerRoot/usr/libexec/afctl -a 123.123.123.0/24

     

    You can add more time to the block with the -t flag. To view the currently blocked hosts:

    sudo cat /var/db/af/blacklist

  • by adrianmartini,

    adrianmartini adrianmartini Sep 29, 2015 10:42 AM in response to regoli
    Level 1 (4 points)
    Mac OS X
    Sep 29, 2015 10:42 AM in response to regoli

    I've been testing this with email server brute force login (IMAP), and adaptive firewall doesn't appear to work for this either. I've set the appropriate IP for the NIC as well in the configuration.

  • by dreness,

    dreness dreness Sep 29, 2015 11:12 AM in response to regoli
    Level 1 (60 points)
    Sep 29, 2015 11:12 AM in response to regoli

    I deal with this by running SSH on an alternate port, and once I confirm that it's working, I disable the original SSH service. The drawback here is that all the clients need to have their ssh / sftp bookmarks updated. To do this, I add a new file in /Library/LaunchDaemons that is just like /System/Library/LaunchDaemons/ssh.plist except for a few differences:

     

    1) a unique Label, such as com.openssh.sshd2

    2) a unique listener port, defined under Sockets --> Listeners --> SockServiceName, such as 50000

    3) I save this new file as ssh2.plist.

     

    (I also delete the bounjour stuff since I don't want to advertise this port to the local network)

     

    This new SSH service cannot be managed by either the Server GUI or System Preferences - you must use launchctl to start / stop / load / unload the job. I suggest that you don't leap headlong into this if you're not familiar with manually working with launchd jobs.

     

    -dre

  • by keithfromvirginia beach,

    keithfromvirginia beach keithfromvirginia beach Sep 30, 2015 1:30 PM in response to regoli
    Level 1 (20 points)
    Mac OS X
    Sep 30, 2015 1:30 PM in response to regoli

    I have had pretty good luck using Murus (Pro) Firewall to manage the PF component for an SFTP server I run. It is easy to understand what is happening and add or deny IP's as needed as well as services as well as being very affordable at I think about $35 bucks (worth it just to make it easier to manage). Just my two cents. Good Luck!

  • by Grant Bennet-Alder,

    Grant Bennet-Alder Grant Bennet-Alder Sep 30, 2015 2:32 PM in response to Linc Davis
    Level 9 (60,976 points)
    Desktops
    Sep 30, 2015 2:32 PM in response to Linc Davis

    Key-based authentication is discussed in Server help:

    About key-based SSH authentication

    SSH is a network protocol that establishes a secure encrypted channel between your computer and a remote computer. By default, SSH supports the use of password, key, and Kerberos authentication. The standard method of SSH authentication is to supply a user name and password as login credentials. Key-based authentication is more secure than password authentication, because it requires that you have the private key file and know the password that lets you access that key file. A key must be generated for each user account that needs to use ssh. Key-based authentication is helpful for such tasks as automating file transfers and backups and for creating failover scripts because it allows computers to communicate without a user needing to enter a password.

    Important: Key-based authentication has risks. If the private key you generate becomes compromised, unauthorized users can access your computers. You must determine whether the advantages of key-based authentication are worth the risks.

    SSH is frequently used to log in to a remote machine to execute commands, but you can also use it to create a secure data tunnel, forwarding through an arbitrary TCP port. You can also use SSH to transfer files using SFTP and SCP. By default, an SSH server uses the standard TCP port 22.

    OS X Server uses OpenSSH as the basis for its SSH tools. Notably, Open Directory replication is provided through SSH.

    SSH works by setting up encrypted tunnels using public and private keys. Here’s a description of an SSH session:

    • The local and remote computers exchange public keys. If the local computer has never encountered a given public key, SSH and your web browser prompt you to accept the unknown key.
    • The two computers use the public keys to negotiate a session key used to encrypt subsequent session data.
    • The remote computer attempts to authenticate the local computer using RSA or DSA certificates. If this isn’t possible, the local computer is prompted for a local user name and password.
    • After successful authentication, the session begins. A remote shell, a secure file transfer, a remote command, or other action can take place through the encrypted tunnel.

    The following are SSH tools:

    Tool

    Description

    sshd

    A daemon that acts as a server to all other commands

    ssh

    The primary user tool, which includes a remote shell, remote command, and port-forwarding sessions

    scp

    Secure copy, a tool for automated file transfers

    sftp

    Secure FTP, a replacement for FTP

    from:

    https://help.apple.com/serverapp/mac/4.0/#/apd3D410789-F9BD-4D8B-919F-3A19770070 68


    .

  • by regoli,

    regoli regoli Sep 30, 2015 6:48 PM in response to Grant Bennet-Alder
    Level 1 (10 points)
    Sep 30, 2015 6:48 PM in response to Grant Bennet-Alder

    I like that idea! (And it's cool to see this thread suddenly come back to life after almost a year!)

     

    Back to the original thread. As the OS has evolved (and the bandwidth of this Mac Mini server to the commodity meatspace increased), I'm relying especially on one critical line in sshd_config:

    PermitRootLogin no

    I can now watch the failed login attempts try "root" for about 10 tries, and then start on all sorts of ridiculous and nonexistent account names. After about 20 minutes, the attempts stop.

     

    On the dangers (above) of having a corrupted key: Definitely a concern, which is why it's good to create a secondary account for fallback.

     

    They give you two car keys, right?  —mr

  • by essandess,

    essandess essandess May 21, 2016 2:53 PM in response to regoli
    Level 1 (28 points)
    Applications
    May 21, 2016 2:53 PM in response to regoli

    the new year has brought out a slew of fresh IPs (mostly from Hong Kong, and China) trying to login to my machine (running OS X Yosemite 10.10.1 Server 4.0.3).

    ...

    what are the strategies for combating these attacks?  Is the best route to use the /etc/hosts.allow and /etc/hosts.deny files to configure access for sshd?


    Thanks for any tips!  —michael

     

    The following two strategies will almost completely eliminate ssh attacks on your server:

     

    1. Install the pf-based osxfortress configuration. This blackholes thousands and thousands of compromised IPs at the kernel level, as well as blocking hundreds of thousands of domain names at the OS level. Regular updates to the crowd-sourced block lists are automatic.
    2. Harden your sshd configuration beyond what Apple provides out of the box. Most ssh attacks are kiddie scripts that are unable even to talk with a hardened ssh configuration. My sshd attacks in system logs are filled with entries like this:

    May 21 02:42:32 hostname sshd[29704]: fatal: ssh_dispatch_run_fatal: Connection to 58.218.204.215: no matching key exchange method found [preauth]

    (Yes, it is easy to confirm that IP 58.218.204.215 <https://duckduckgo.com/?q=58.218.204.215> is a .cn-based brute-forcer).

     

    Search for "secure secure shell" to harden your ssh configuration. Specifically,

     

    • KexAlgorithms in /etc/ssh/sshd_config and /etc/ssh/ssh_config
    • Delete weak EC moduli from /etc/ssh/moduli
    • Generate strong a ssh_host_ed25519_key and ssh_host_rsa_key
    • Disable password authentication
    • Disable root authentication
    • HostKeyAlgorithms in /etc/ssh/ssh_config
    • Ciphers in /etc/ssh/sshd_config and /etc/ssh/ssh_config
    • MACs in /etc/ssh/sshd_config and /etc/ssh/ssh_config

     

    This ssh configuration with a pf firewall will drive attacks to nearly nothing. Confirm yourself with this pf rule that tosses ssh attacks into a blackholed brute force table:

     

    # Block brute force attacks

    table <bruteforce> persist

    block drop log quick from <bruteforce>

    # ssh really restrictive

    pass in inet proto tcp from any to { lo0 $int_if } port ssh \

      keep state (max-src-conn 5, max-src-conn-rate 5/2, \

      overload <bruteforce> flush global)


    It takes my server weeks to see a single attack show up in my bruteforce table:

     

    sudo pfctl -t bruteforce -Ts