After panel port change fail2ban does not ban new port

nsuro commented 6 years ago

Operating System (OS/VERSION):

Debian 9

VestaCP Version:

0.9.8 20

Installed Software (what you got with the installer):

nginx, php-fpm, iptables, fail2ban, vsftpd, exim, dovecot, spamassassin, clamav, roundcube, mysql, postgresql

Steps to Reproduce:

Change Vesta panel port to something other than the default 8083

Related Issues/Forum Threads:

https://forum.vestacp.com/viewtopic.php?f=10&t=16585

Other Notes:

After having to change the default port the panel runs on I noticed that the iptable chain was not updated. At the moment failed login attempts trigger a ban but only on the original port leaving the panel still accessible.

Port for fail2ban is set in v-add-firewall-chain . Editing the port there and reloading fail2ban fixes the issue for now. As others suggested in the forum it would be nice to be able to set the port on install or in the vesta.conf file.

I think a simple solution for now would be to block all ports on a panel ban. I will try to see about that as soon as I get a chance. Not sure if you can just change 8083 to 1-65535 in v-add-firewall-chain?

darkworks commented 6 years ago

to change vesta port in vesta firewall change 8083 to your new desire port lets say 8000 then edit : nano /usr/local/vesta/nginx/conf/nginx.conf

# Vhost
    server {
        listen          8083;   #  change it to 8000

save and restart vesta like
/etc/init.d/vesta restart

nsuro commented 6 years ago

Yes that is how the panel port is changed but the issue is that fail2ban does not work after that change.

nsuro commented 6 years ago

I tested changing this line in v-add-firewall-chain from VESTA) port=8083; protocol=TCP ;; To VESTA) port='1:65535'; protocol=TCP ;;

This blocked access on all ports for my IP instead of just 8083. Maybe not the best way to handle it as I was locked out of every thing. Would either have to wait for ban to expire or login through console to unban.

Not sure if this is how you guys would like to address the issue, but just a suggestion :smiley: Thanks for all your hardwork!!

coldplug commented 6 years ago

Hello,

In order for fail2ban to ban on correct port, you need to change this file: /usr/local/vesta/data/firewall/chains.conf

It is not documented well (if anywhere) and vestacp forum is full of this issue and there is no single answer to that even from vestacp stuff - looks like they don't know this setting either.

Restart firewall after change. Good luck

nsuro commented 6 years ago

That looks like it would be best since it might not get wiped after upgrade then. But it doesn't seem to work exactly though on debian 9.

Change the port in chains.conf
Run v-update-firewall to get iptables to update (restarting fail2ban or vesta didn't update)
Reboot and found new port was still there
Check chains.conf and found was back to original after reboot
Now anytime v-update-firewall is run it sets it back to the original.

I'll try on fresh installs to see if its just messed something up ;)

coldplug commented 6 years ago

Ah, I see. Something changes the file on boot. I might look at it when I get time. In a meantime, put sed replace in /etc/rc.local or whatever Debian executes at the end of boot process:

sed -i "/SSH/c\CHAIN='SSH' PORT='2222' PROTOCOL='TCP'" /usr/local/vesta/data/firewall/chains.conf

On Centos this successfully reverted back the change.

pablobae commented 5 years ago

I've detected that today. Did you found what it the cause of reverted back the file on boot?

pablobae commented 5 years ago

I answer my question: v-add-firewall-chain overwritte the file on boot,

# Preserving chain chains=$VESTA/data/firewall/chains.conf check_chain=$(grep "CHAIN='$chain'" $chains 2>/dev/null) if [ -z "$check_chain" ]; then echo "CHAIN='$chain' PORT='$port' PROTOCOL='$protocol'" >> $chains fi

but... what's the problem?? The problem is that all services port (except vestaport) are hardcoded on that file , so If you have changed your default ports of services like ssh, ftp, etc... (to improve your server security) v-add-firewall-chain will create chains with the incorrect port... and due this, fail2ban won't block any attack!

# Checking known chains case $chain in SSH) port=22; protocol=TCP ;; FTP) port=21; protocol=TCP ;; MAIL) port='25,465,587,2525,110,995,143,993'; protocol=TCP ;; DNS) port=53; protocol=UDP ;; WEB) port='80,443'; protocol=TCP ;; DB) port='3306,5432'; protocol=TCP ;; VESTA) port=$vestaport; protocol=TCP ;; *) check_args '2' "$#" 'CHAIN PORT' ;; esac

I think that ports should not be hardcoded in any script,or at least check the services config file to get if the port has been changed, this is done in v-update-firewall with ssh for example:

# Checking custom OpenSSH port sshport=$(grep '^Port ' /etc/ssh/sshd_config | head -1 | cut -d ' ' -f 2) if [[ "$sshport" =~ ^[0-9]+$ ]] && [ "$sshport" -ne "22" ]; then sed -i "s/PORT='22'/PORT=\'$sshport\'/" $rules fi

Other option could be use the file /usr/local/vesta/data/firewall/ports.conf to read the ports, so if any user change any port service, he should update this file too editing the service port.

outroll / vesta