Bruteforce attack through our server

@developerc9740c6fa8b2fbffc

If you’re using port 55242 for SSH instead of the default port 22, those messages are simply telling you that a session was initiated for root and then rather quickly closed out.

If you’re not using 55242 for SSH, then that very well may be a cause for concern and you’d need to investigate further.

When it comes to being compromised, it’s often best to begin looking at migration options and then, setting up a more secure environment. During the migration, you’d evaluate your code, database, etc to ensure that there’s not something that would allow a would-be attacker to get back in.

…

What I would recommend, on a new server is:

1). Deploy with SSH Keys – this disables password authentication with DigitalOcean.

2). Setup a sudo user with their own SSH Key, confirm it works (i.e. you can run commands), then lock the root user. This ensures no-one can login with or attempt to login with the root user. All root-level commands are then executed by the sudo user.

3). Setup firewall rules that deny incoming and allow outgoing by default policy, then only open the ports that you absolutely need open such as SSH (22), HTTP (80), and HTTPS (443). Unless you’re running an e-mail or DNS server, or have some very specific requirement, that’s generally all you need to open as when it comes to NodeJS, Python, etc – you’d be proxying locally or proxying over the private network. Make sure the firewall is active.

4). When it comes to SSH and Port 22, it’s best to restrict by IP. If you don’t have a static IP, this can be a problem as your IP can change at any time. In such a case, I’d recommend setting up a VPN, then restricting access to the VPN IP since it will be static. You’ll have to be connected to the VPN to get in but it’s far more secure.

5). Don’t use sudo users for access when it comes to your sites. Use normal, un-privileged users that can’t login to a shell. Allowing SFTP access to these users is fine, but they should be prevented from logging in to any form of SSH unless it’s absolutely required.

6). Use individual users for each site. You can use www-data for your first site, but create a new user and a new home directory for each site after, even if you use www-data2, www-data3 etc. This will prevent one user from accessing files of another as long as permissions are setup correctly.

7). Make sure you’re not exposing information that shouldn’t be exposed. For example, with PHP, using phpinfo() will provide you with a lot of useful information about your setup, but you don’t want that all exposed to the public.

Beyond the above, the previous information still applies.

@developerc9740c6fa8b2fbffc

At the server level, I would first look over the contents of /var/log/auth.log.

tail -50 /var/log/auth.log

That’ll give you an idea of who has logged in, or attempted to, and whether it was successful or not. If you don’t recognize one of the users, see if they exist.

cat /etc/passwd

One a clean (freshly deployed) Ubuntu 16.04 Droplet, where no additional users have been added, the above file looks like:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-timesync:x:100:102:systemd Time Synchronization,,,:/run/systemd:/bin/false
systemd-network:x:101:103:systemd Network Management,,,:/run/systemd/netif:/bin/false
systemd-resolve:x:102:104:systemd Resolver,,,:/run/systemd/resolve:/bin/false
systemd-bus-proxy:x:103:105:systemd Bus Proxy,,,:/run/systemd:/bin/false
syslog:x:104:108::/home/syslog:/bin/false
_apt:x:105:65534::/nonexistent:/bin/false
lxd:x:106:65534::/var/lib/lxd/:/bin/false
messagebus:x:107:111::/var/run/dbus:/bin/false
uuidd:x:108:112::/run/uuidd:/bin/false
dnsmasq:x:109:65534:dnsmasq,,,:/var/lib/misc:/bin/false
sshd:x:110:65534::/var/run/sshd:/usr/sbin/nologin
pollinate:x:111:1::/var/cache/pollinate:/bin/false

If you see someone you don’t recognize and you’re sure it’s not a user that’s associated with your site or services you’re running, you can remove them using userdel. Be careful there as if you delete a user that is associated with a service, it will fail.

userdel username

Beyond the basics of checking logs and the current system users, run a root kit check using either rkhunter or chrootkit. Using DenyHosts is also a pretty good option to block certain attempts at logging in, though as with any tool that can deny access, you need to be careful not to block and lock yourself out.

http://denyhosts.sourceforge.net/

http://www.chkrootkit.org/

http://rkhunter.sourceforge.net/

…

If you’re not already, use SSH Keys over plain-text password authentication when accessing SSH. An RSA key with a bit size of 4096 bits or even 8192 is ideal, though you can also use ed25519 as well. You’d generate the key(s), download the private key (if you can’t generate them locally) and make sure the public key is in your users authorized_keys file.

SSH Keys are the preferred way to login, though I would also advise making sure your key has a valid passphrase protecting it, otherwise key-based login can be as insecure as password-based login since there’s no valid protection preventing someone from using your key(s) if they get ahold of them.

Once you have SSH Keys setup, completely disable password-based login.

…

Also server side, check permissions on files and directories. If any directories or files are using a chmod of 777, fix it now. There’s no reason to give such higher level access. Files should be at best using a chmod of 644 and directories a chmod of 755 (some may get by with 750).

…

On the WordPress side, check out WordFence:

https://wordpress.org/plugins/wordfence/

Also check your theme files, plugins, etc – make sure they are 100% up to date as well.