Zachary, I assume every possible attack will happen. What I am trying to find out what is really possible. I also am trying to blow the whistle on BS that everybody passes on to everyone else because everyone is saying it, so repeating it makes you part of the crowd.

Your comments are not like that. Those attacks you had to deal with were real and their agony has generated a focus and sure knowledge this is easy to spot

Regarding port 3306 where mysql is working as a remote server, can you think of a practical way to hack it?

@dan677915

I mentioned phpMyAdmin and Adminer as they are database management tools that are written in PHP (and you’ve tagged this post as LAMP). With these tools, you can access a database on a local or remote MySQL server and modify the contents of a database as it is needed. Of course, you could do this without either and opt for a direct route with PHP only (connect via PDO, execute the queries needed, etc).

In regards to ports, much like Windows, whatever you don’t lock down is wide open by default. OS’s are designed for general purpose, so there’s no way for an OS, by default, to know what ports you do and do not need open, or which ports you want to restrict access to. That’s where solutions such as iptables come in to play and, as a result of the rather complex state of iptables, that’s why ufw was created (as a wrapper around iptables to provide more simplified ways of modifying rules). Of course, these are only two solutions; there’s dozens more.

–

For instance, let’s take a standard Debian 8.x installation. If I deploy Debian 8.x to a fresh Droplet, all ports are open by default. There are no limitations in place and as long as I know how, I can connect to any of them in some way, shape or form. This is far from ideal, especially on a public facing server (i.e. a server that will allow the public to access and connect).

Since I don’t want the public to be able to connect wherever they’d like, I want to use a firewall to block access to all ports except those that I specifically allow. Why? There’s no need to allow anyone to be able to connect to any port they’d like and further more, it is a security issue as there’s always someone out there that’s smarter than me.

To lock down the server, thus preventing access to any and all ports, I’ll first start by allowing my IP through and allowing SSH’s Port (by default, Port 22), this way I won’t be blocked and my connection won’t drop in the midst of me working to add my rules. If I didn’t whitelist my IP and the current SSH Port, should my connection drop, I’m locked out.

Once these rules are in place, I’ll implement a deny all rule and then proceed to only add allow rules indicating the ports that I specifically want others to be able to access.

–

For simplicity, I’ll use UFW as an example here. UFW is pre-installed on Ubuntu, but not on Debian, so since I’m using Debian in this example, I need to install UFW.

apt-get install -y ufw

UFW is now installed, but not active (which is a good thing, we don’t want to turn it on right now). So, as mentioned above, I’ll add SSH first.

ufw allow 22/tcp

This tells UFW to allow connections on Port 22 using TCP, which is how we’d normally be connecting using Terminal, PuTTy etc.

Now I need to add my IP address:

ufw insert 1 allow from 0.0.0.0

This tells UFW to allow connections from my IP (you’d replace 0.0.0.0 with your local IP, of course) and to place this rule at the very top of the list. Why? If this rule, for example, is at the bottom of the list and we’ve already set up our deny all rule, I’ll still be denied as UFW (and iptables) follows rule order.

Now that I’m safe and SSH is allowed, I’ll now implement my deny all rule.

ufw default deny incoming

This tells UFW to set the default policy to deny all incoming connections, thus, connections on other ports will now be denied unless it’s Port 22 and the connection is from my IP. Since this isn’t ideal on a public server, and I plan on serving web content, and I need to be able to connect to update packages and software, I’ll need to add ports that I want to allow connections to and from. This is where those Ports I mentioned above come in to play.

I need to allow HTTP & HTTPS (for basic requests and secure requests).

ufw allow 80/tcp
ufw allow 443/tcp

I also need to allow DNS to resolve from requests made internally. By this, I mean when we run apt-get update and apt-get upgrade. If we’re blocking DNS, requests to repo’s are not going to resolve. For internal connections, we need to allow DNS using UDP instead of TCP.

ufw allow 53/udp

Now, if we happen to be running a DNS server, such as Bind, on our Droplet, we’d also want to allow TCP for DNS.

ufw allow 53/tcp

With these rules in place, we’re now allowing HTTP, HTTPS, SSH and DNS while denying access to anything else. Now I simply need to enable UFW.

service ufw start

You can now use

ufw status

To view which rules you’ve set and:

ufw --help

to view other actions that can be taken.

@dan677915

In regards to some ports being open and the question of why can’t hackers break through, it’s not that they can’t, it’s a matter of how effective would it be to try and what happens when they try.

A firewall is not the only solution. Ideally, you would also implement connection limits that prevent a single client from being able to make more than X connections per second. If they do, the client is flagged and added to a list that either blocks further connections for X minutes/hours or implements rate limiting (i.e. throttling, which then slows the rate of connections until they are under a threshold).

This means that if I, as a client, attempt to connect to any server with such rules in place at a rate of 99 requests per second and server X is limiting connections to 10 connections per second, after I hit #10, the rest of my connections are either going to be blocked or heavily limited in terms of success rate, speed etc.

For example, let’s take a basic Brute Force attack as an example. These are automated attacks (as no one in their right mind would sit and try to do this manually). When a BF attack hits, it’s trying to guess a password using a predefined list of commonly used and commonly exploited passwords. If these fail, it then tries a smarter approach to guessing based on whatever tables it’s provided with. This can effectively kill connections to your server if you don’t have something in place to block the overload as more than likely, the person(s) attacking are going to attempt to connect as quick and as often as possible, far surpassing the 99/CPS that I mentioned.

If they are allowed to run their attack (even if they never successfully get in), you’re going to run out of resources to serve additional requests. If you’re on a HA setup, then all of your servers are going to end up being flooded as the HA proxy begins to serve from the next server in line until it runs out of servers to switch over to.

Now you’re down and they’re just waiting for you to come back up to try again (and it will happen).

You can either allow it, or do something about it. Of course, more than likely, they will be connecting from multiple IP’s, so your block list is going to grow, though it’s better to deal with a huge list of IP’s in a table than it is to allow your service(s) to cause major issues for clients.

–

That said, if you do become the target of an attack, beyond these solutions, I’d get in touch with DigitalOcean ASAP. Since you do not have control over the hardware end, software solutions are what you’re limited to. DigitalOcean could, however, work with you to implement something more effective in the short term.