adguard on upcoming Cloudron v6 DDoS reflection/amplification
-
@robi If I understand correctly, you are suggesting that we restrict the app to only private IPs by default. Maybe the IP blocks in https://en.wikipedia.org/wiki/Reserved_IP_addresses ? Thing is I would say the most common deployment of Cloudron is on a VPS and with that as the default a big chunk of people won't be able to use the app out of the box.
I think a good solution is to add a app level firewall to Cloudron. I think it's something we can easily add for next release.
@girish
Not what I said, but in effect yes.What I am suggesting is to limit it to an actual interface not an IP. Anything flowing through a VPN interface for example which is a higher abstraction.
Since private networks use RFC1918 addressing that's what ends up flowing through those interfaces. Hence the effect.
Having a by default secure install is the only option IMO.
Anyone installing it will need to configure it properly, be it for VPN access and network interfaces, or by going lower into the networking stack and using IP:port settings.It's also a question of liability for you, allowing deployment for DDoS or not.
Subsequent modification is the users responsibility.
Even if you had an app level firewall, how will it dynamically configure itself for a new client IP every hour? (there are ways but beyond the scope of this discussion)
-
I am reading up on what the upstream project recommends because IMO it's actually fairly easy to do an IP based rate limit in the app itself. There are several issues around this:
-
I am reading up on what the upstream project recommends because IMO it's actually fairly easy to do an IP based rate limit in the app itself. There are several issues around this:
-
@girish
Playing around with ADGuard today. The inbuilt IP limiter works great and correctly blocks amp attacks.Only issue i found was the ability to use DDNS hostnames as a whitelist for dynamic IP nets. CIDR works just aswell i guess...
@dylightful said in adguard on upcoming Cloudron v6 DDoS reflection/amplification:
Playing around with ADGuard today. The inbuilt IP limiter works great and correctly blocks amp attacks.
Do you mean the requests per second limit?
Which setting blocks amp attacks?Only issue i found was the ability to use DDNS hostnames as a whitelist for dynamic IP nets. CIDR works just aswell i guess...
I had an issue with this too, as I couldn't come up with a CIDR address that would exclude some of the abusing IPs without blocking my own (same network provider).
-
@dylightful said in adguard on upcoming Cloudron v6 DDoS reflection/amplification:
Playing around with ADGuard today. The inbuilt IP limiter works great and correctly blocks amp attacks.
Do you mean the requests per second limit?
Which setting blocks amp attacks?Only issue i found was the ability to use DDNS hostnames as a whitelist for dynamic IP nets. CIDR works just aswell i guess...
I had an issue with this too, as I couldn't come up with a CIDR address that would exclude some of the abusing IPs without blocking my own (same network provider).
@robi you might have to put it behind a firewall then and only allow internal - you could then have your servers vpn in to your box to query it (I do that for one of my friends).
There's another thread about making apps accessible only from OpenVPN - that would be a neat use case. -
@robi you might have to put it behind a firewall then and only allow internal - you could then have your servers vpn in to your box to query it (I do that for one of my friends).
There's another thread about making apps accessible only from OpenVPN - that would be a neat use case.Would that be OK to configure the firewall on the machine where cloudron is running? In the documentation says to not touch iptables/ufw and similar stuff, so I guess it's not a good idea. Yet, since this is a very serious matter of having AdGuard running wild out there, I would propose to have the app configure the firewall itself -- instead of relying to 3rd party firewalls -- and make this configurable (enable/disable).
Upon installation, it could ask you what you would like to do:
- Block port 53 - allow internal traffic only for AdGuard (recommended)
- Do not configure firewall.
WDYT?
-
Would that be OK to configure the firewall on the machine where cloudron is running? In the documentation says to not touch iptables/ufw and similar stuff, so I guess it's not a good idea. Yet, since this is a very serious matter of having AdGuard running wild out there, I would propose to have the app configure the firewall itself -- instead of relying to 3rd party firewalls -- and make this configurable (enable/disable).
Upon installation, it could ask you what you would like to do:
- Block port 53 - allow internal traffic only for AdGuard (recommended)
- Do not configure firewall.
WDYT?
-
@drpaneas did you see the docs at https://docs.cloudron.io/apps/adguard-home/#securing-installation already?
@nebulon yes of course I've read those. My proposal is to have cloudron blocking the port 53 during the installation automatically -- instead of asking the user to do it manually in the docs. In that way we make AdGuard installation more secure by default, instead of relying to the end user to take care of it.
-
This was something that came up early on when we were discussing AdGuardHome and PiHole. Most folks recommend only exposing something like this via a VPN without binding to 53 on your public network interface. A VPN still allows people to use it from anywhere but adds a layer of authentication.
The way things are now, it's very likely that folks misconfigure their DNS server. Part of Cloudron's draw is that users don't have to think so hard about "doing the right thing". The best way to do that would be to not bind only to a VPN interface and support the VPN setting the DNS server as the default.
A setting to "do the wrong thing" could be there for folks that really know what they are doing, but maybe a little more difficult to get to so someone who enables it will also know how to manage their firewalls. Either through their VPS provider or on the machine.
Personally, I host mine at home and access over a VPN.
-
-
One idea might be to fix the package to block all clients by default. I think we just need to put some wildcard to deny all the IP addresses. Would that make things better? This way user has a UI to manually white list their client IP addresses.
-
@girish that doesn't work for most clients as they have dynamic IPs.
Unless there's an auth of some sort, port knocking or VPN access to it.
Let's go Wireguard.
-
@robi sure. The goal was only to make the user a bit more aware of the security settings. It doesn't solve anything else, as you say.
@girish I think a reasonable default would be to blacklist all non-local IPs (RFC 1918) by default. That way, connecting from VPNs should work, connecting from LAN should work, but connecting from public internet would require manual white-listing.
-
@girish I think a reasonable default would be to blacklist all non-local IPs (RFC 1918) by default. That way, connecting from VPNs should work, connecting from LAN should work, but connecting from public internet would require manual white-listing.
-
@mehdi I agree with this. However, it would also be important to have the ability to give the container a static internal IP and allow the configuration of the VPN app to set that container as the default DNS server.
-
so no way to let connect only from selected clients, like from specific indentifier? Would like to run AdGuard Home for some devices, but I don't have a static IP
-
@lukas You can specify client IDs in Case you plan to use DoT or DoH method for DNS resolving. This can be configured for each browser and in iOS Devices as a Profile (export from Adguard Home). This may help?
-
@Kubernetes sounds good, is there any guide how to do this correctly?
@lukas you may have a look at the guide from Cloudron here: https://docs.cloudron.io/apps/adguard-home/#security
However the setup is pretty simple, go to the DNS Settings in Adguard Home and give some names for your client IDs
When you entered ClientIDs the DNS will not be available anymore for anyone who is NOT in your Client IDs list. If you want to update your non static IP from your internet service provider, you could do that and put in your public IP. In that case your local clients can use the DNS even without having a named Client ID
Then you can use the Tab "Setup Guide" in Adguard Home to get guidance how to get your devices configured.
If you want to configure Chrome, Brave or Firefox for DoH you can then use the URL to your Adguard Home DNS Name with appending your ClientId like this for example:
https://DNS-NAME-TO-YOUR-ADGUARDHOME/dns-query/CLIENTIDPlease be aware that you should understand what you do and in case of concerns just don't do it. You will be responsible yourself for anything you do.
