Cloudron Forum

@dfoy yes, let us know what they say. Happy to make fixes, if any needed.

@imc67 essentially the patch for this is https://git.cloudron.io/cloudron/box/-/commit/eb0662b2455e0687ab3ce5dd02d2466e16670092 so two files need to be adjusted. The .ejs file is a template which will result in /etc/nginx/applications/my.<domain.com>.conf so besides the editing the .ejs file additionally edit that file and then systemctl restart nginx and systemctl restart box.

@wind-gmbh FWIW, we don't use the upstream distro packages. We use the packages straight from nginx.org since they provide better security fixes - https://nginx.org/packages/ubuntu/pool/nginx/n/nginx/ . Looks like https://nginx.org/packages/ubuntu/pool/nginx/n/ is the pre-built modules they have.

@reachableceo thanks for the update!

@jodumont I recently posted about crowdsec under feature requests.

I think crowdsec is more appropriate, afaik, for cloudron

@girish Awesome. Thank you for the help!

hey @nebulon,
no, only 2-3 ports tcp/udp (wireguard/snmp/ssh)
and it happened inbetween again, without any reboots/upgrades/etc. I got notfied by network mgmgt system, that my cloudron server is down - luckily it was just the firewall…

@fbartels I do believe you.

@nebulon Fantastic, thank you!

@girish said in Restrict Dashboard Access - Cloudron v6.1.2:

@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 /etc/ufw/after.rules to contain:

# 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 all with allow from xxx.xxx.xxx.xxx with periodic firewall disable for let's encrypt.

Tha

@d19dotca said in Why does cloudron block ports?:

@cumpal Cloudron expects to be the only one running on the server, so for security reasons it locks it down unless needed by Cloudron or any of the apps on it. If you need to modify it, I think you can just update the firewall rules manually in Ubuntu, though I've not done that part myself as no need for it yet. but hopefully that at least explains why it's locked down. You may want to review the Cloudron docs on security features too.

@girish said in Why does cloudron block ports?:

In addition to what @d19dotca said, you can whitelist extra ports using https://docs.cloudron.io/networking/#whitelist-ports . Please use this at your own risk, we don't recommend installing other software alongside cloudron .

Thanks for these replies! I got them working.

There is an allow list file, but you have to access it from ssh. It should be in the docs.

@chymian-0 Did you whitelist the ports or did you use iptables/ufw directly? We only support https://docs.cloudron.io/networking/#whitelist-ports

@robi Wow Robi, this is a great feature request!!! Just yesterday one of my Cloudron instances got a lot of traffic to email for a bruteforce attack.

@girish I think this feature have to put on the top of the list to improve safety but also to reduce workload of instances and network traffic...

Schermata 2021-01-13 alle 09.49.21.png

This is a statping how network performances was impacted before and later bruteforce.

Also, need a robust alert system - email or other - to let us know that something is happens.

Thanks for the heads up. We don't really use any of these tools but something to keep in mind. We do use ipset for the firewall block list, but it seems to work fine with Ubuntu 20 though.

@shai said in Format for IP Blocking:

If you are curious, blocking China and Russia came to 19,000 rows. Cloudron didn't stutter.

The firewall does. It will take progressively longer to make fw changes as you keep adding IP blocks. Not an issue for one time things, but something to keep in mind.

@mehdi my thoughts / use case exactly.

Doing so with ipchains is a pain (thanks Docker's intervention to firewall); and ufw just doesn't handle all of the use cases (thanks Docker again).

Super!
I have used this script now via cron and everything seems to work fine, including a significant reduction of "denied" mail attempts in the mail log.

I've added the following lines to keep the last 20 url lists, compressed with 7z (which I prefer for compression), for analysis (if needed):

7z a -mx9 "${current_datetime}.7z" "formatted_$output_file" rm "formatted_$output_file" rm "$output_file" ls -td *.7z | grep -v '/$' | tail -n +20 | while IFS= read -r f; do rm -f "$f"; do>

Also: If you use the script, don't just blindly add url-lists. I already managed to lock myself out once by adding the "standard" Firehol list (https://iplists.firehol.org/files/firehol_level1.netset)

@girish said in Firewall IP blocking: IPv6 not possible:

I guess this post was before we had IPv6 support. IPv6 is supported in the firewall by now.

Indeed 😊

@jdaviescoates Correct, if you use Gandi API you are using wildcard certs and good.

When a cert is issued, most of the current certificate providers these days "log" the domain name as part of the https://en.wikipedia.org/wiki/Certificate_Transparency project. These reports can then be scanned later. For example, go to https://crt.sh/ and search for say %google.com%. This gives various subdomains of google. When you use wildcard certs, only *.domain.com is logged and thus the subdomain is hidden. So, if you install searx at mysecretsearch.domain.com, there is no way for anyone to know the subdomain mysecretsearch since DNS has no subdomain search.