I thought I'd take a step back and write a bit about what the setup is on the server some for those new/getting into, or with an interest in infosec (wait, it's cyber security now..my bad).
The server I'm using to study and write about is a sample server we have on the internet. It's not quite a honeypot, as I am not deliberately leaving known vulnerabilities open. Instead I'm running some common services, with unimportant hobby data to mimic real-world use. Intent is to track changes and attacks against it. That said, on to the high level basics..
1. Network - The server has 8 IPs assigned and is on a wide open datacenter network. It is not using cloudflare or other network providers that may offer some network attack mitigation. All standard ports for tools and services were left unchanged. *This is fairly common to see, but is not a security sound thing to do. In a properly secured server we'd expect / recommend common services be moved. This won't impact an attacker scoping out your server directly, but it will at least cut your system from the target list of automated internet scans for these ports by scripters.
2. Server - Since the pretend mission of the system is as to host a hobby website, db, panel and a free multiplayer game, email, etc.. I reviewed using Red Hat, CentOS, Debian, and Ubuntu. Conducting research indicated that Ubuntu was growing in use for these sorts of things, so I went with Ubuntu's LTS (18.0.4) with basic packages as required for use.
3. Security Configs - System has a basic host-based firewall to drop packets to unused ports, and fail2ban installed and with jails setup for ssh and a few other services. While I intentionally followed some common internet new user server guides in initial configuration I also made some tweaks with the configs there where I thought the guides were simply allowing too many chances for password guessing. Essentially, an entity from an IP makes a connection attempt to the server being watched, in this case lets go with port 22 (SSH). After a number of minimal login fails within a set time period will cause fail2ban to modify the host based firewall with the attacker source IP. These "Jails" are then logged, which is what I'm collating to network provider. The segment in part 1 of this series just happened to be the largest offender. In the next segments I'll conduct a vulnerability assessment now after 3 months of install to see what services have developed vulnerabilities, what likely attack vectors/risks exist. We'll then walk through a remote recon of the server so see which tools are the most effective in this case, and some ideas of how we might try gaining remote access. Finally, we'll go over remediation/mitigations to better secure the server, .