UFW Firewall rules generated in ispconfig don't seem to apply

Allow acces to SSH and then block all other ports that are not listed:

Code:

sudo ufw allow ssh
sudo ufw default deny incoming
sudo ufw default allow outgoing

Add all ports you need (like 80, 443, 8080, etc)
UFW tutorial: https://www.howtoforge.com/tutorial/ufw-uncomplicated-firewall-on-ubuntu-15-04/

 

The UFW firewall in ISPConfig works fine on my systems. ISPConfig is doing the same thing that you did manually now, it runs the ufw command and opens/closes ports. You can use ispconfig debug mode if you want to see in detail what's going on.

 

Perhaps it's not configured because it wasn't installed/enabled when you installed ISPC. However, I prefer using the command line. You can't run a server with only ISPC. It's a great panel, but it can't handle everything.

 

Yes, this indicates that something is wrong. You can use debug mode to get detailed info on the shell to see which commands are run by ispconfig when you change firewall ports: https://www.faqforge.com/linux/debugging-ispconfig-3-server-actions-in-case-of-a-failure/

 

As @till said, debugging mode will show you what it's doing; that is, of course if you have the firewall plugin enabled in the first place, which you might check (/usr/local/ispconfig/server/plugins-enabled/firewall_plugin.inc.php should be a symlink to the corresponding plugins-available file).

You can only do this via the command line. Ports you configure in the ISPConfig gui are open or closed for all clients. Fortunately with how ISPConfig runs ufw commands, you can add such a rule from cli yourself and it will not be overwritten by the gui rule management (ie. you can use both together).

Code:

ufw allow proto tcp from xx.xx.xx.xx to any port 3306 comment 'mysql allowed only from my ip'

That's exactly right, and as you are concerned, it is not nearly as secure as blocking public access to mysql in the firewall. I don't allow public access to any mysql server; I would recommend the same for you if you can get away with it (I know some places do allow (or maybe "require" by policy) public access). Mysql has had remote vulnerabilities in the past. As with all software, it likely will in the future, too. Or maybe the vulnerability isn't even in mysql, but a library it uses; like, say the libidn2 vulnerability that was announced Friday.

Do note: I am not claiming and I don't know if mysql is a vector for exploiting that vulnerability in libidn2 or not, but mysql is linked to that library, and of course name lookup/handling of client hostnames is exactly the type of overlap where allowing public access could make your mysql remotely exploitable, even if users are prohibited logging in via mysql.user restrictions; I'd say it's legitimate cause for concern, and for further investigation and/or immediate patching. Or ... firewalling?