@anwarnajjar You can set this as a rule in your Cloud firewall. Cloudron itself doesn't have built-in support for this yet. For example, in DO, you can use their firewall - https://www.digitalocean.com/docs/networking/firewalls/how-to/configure-rules/
@girish thank you! Is there any recommendations on how to do it from the command line? For those, who are not so happy about cloud provider?
May I use ufw with Docker addition?
By the way, blocking dashboard will also block updating SSL certificates, unless CloudRon can switch to DNS validation with appropriate certbot modules?
@potemkin_ai UFW and Docker are not compatible. I haven't looked into the repo you linked yet.
I didn't test the solution yet, found it with people referring as a working one, so I have hopes.
The idea is to modify
# BEGIN UFW AND DOCKER *filter :ufw-user-forward - [0:0] :ufw-docker-logging-deny - [0:0] :DOCKER-USER - [0:0] -A DOCKER-USER -j ufw-user-forward -A DOCKER-USER -j RETURN -s 10.0.0.0/8 -A DOCKER-USER -j RETURN -s 172.16.0.0/12 -A DOCKER-USER -j RETURN -s 192.168.0.0/16 -A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN -A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16 -A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8 -A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12 -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 192.168.0.0/16 -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 10.0.0.0/8 -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 172.16.0.0/12 -A DOCKER-USER -j RETURN -A ufw-docker-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW DOCKER BLOCK] " -A ufw-docker-logging-deny -j DROP COMMIT # END UFW AND DOCKER
Why not just enable 2FA on the dashboard?
It's a different security layer. 2FA relies on the code, which is much more complicated, as opposed to network level filtering.
What is more complicated could have more issues.
So, whenever possible, I close any code from outside access - everything have bugs, some of them are in security space, even if you are OpenBSD
Do you believe this could become part of the system?
I would really like to
deny from allwith
allow from xxx.xxx.xxx.xxxwith periodic firewall disable for let's encrypt.