Stopping brute force ssh attacks on OS X Server 4?

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.

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.

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.

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!

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

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.

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

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!

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

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:

sshd

ssh

scp

sftp

from:

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

.

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