@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.