Default auto-discovery config triggers SecOps alerts.

[Snider]

Having the IPFS profile defaulted to auto-discover means by the time you get a chance to see the admin panel the server is already in the process of an abuse ban.

[dapplion]

@3alpha @eduadiez

[3alpha]

Since DAppNodes primary purpose is to be on physical devices that are usually behind (home) router do we want this?

[Snider]

Why have limitations from public defaults? It stops people from being able to push code back.

In Angular, they created a CDK that Angular uses, providing the functionality without styling choices.

You could implement something like this with host detection script/docker:
https://github.com/letheanVPN/blockchain-bk/blob/develop/build.bash#L40

And for the ISO, adjust the pipeline to inject the correct runtime configuration

[alexpeterson91]

Since DAppNodes primary purpose is to be on physical devices that are usually behind (home) router do we want this?

I can explain more thoroughly since both I and Edu recently experienced this a couple weeks back., idk why I or Edu didn't consider at least making an issue about this problem

I and then @eduadiez discovered that the default setting for IPFS when installed searches the private subnets, this is strictly enforced by some hosting services such as Hetzner. If you install DAppNode on a Hetzner server, and even setup firewall rules to keep it from accessing these subnets like this, the docker subnets can bypass the ufw rules, and before you can even login, change the password copy recovery key etc, the IPFS starts up, using local discovery to access the restricted subnets. Hetzner's strict auto enforcement bot will, minutes after installation, immediately lock your server due to abuse for a "netscan" (all the info they give is in an email exactly as @Snider posted in the beginning of this PR. needed to beg support to explain what i was doing wrong since the abuse warning just says netscan detected, followed by a list of network API calls from your node's IPFS port normally 4001 followed by the list he redacted.) but instantly they lock access to the internet and block you out from ssh too until you whitelist your own client IP, SSH in collect VPN credentials if you hadn't' been able to get them before due to the abuse auto-lock, and then go into the IPFS package config tab and change the IPFS profile to "server" this disables IPFS from using any of the restricted subnets that it refers to as local discovery. Then you need to run an abuse test using the Hetzner robot control dashboard to see if the issue continues to exist, (it shouldn't if you made the profile change to server properly or use none or remote with a remote node or connect directly to peers and this doesn't take that long, but then once that's done you are required to submit a detailed statement to the abuse team explaining what happened, why it did, how you fixed it, and how you'll keep it from happening again this requires manual review after which your server will be unlocked but I've found them to be rather responsive (i had this issue many times when i first spun up 2 dedicated servers from Hetzner, I couldn't understand what was wrong since they had a whole blog post about blocking local IP subnets with UFW, but it . a couple days before @eduadiez spun some up at Hetzner and ran into the same issue. I haven't experienced this with other hosting services like Contabo, Digital Ocean, Azure, or AWS, but i also haven't used azure or AWS in years

root@static:~# apt-get install ufw
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
ufw is already the newest version (0.36-7.1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@static:~# ufw allow 22
ufw allow 80
ufw allow 443

ufw enable

ufw status
Skipping adding existing rule
Skipping adding existing rule (v6)
Skipping adding existing rule
Skipping adding existing rule (v6)
Skipping adding existing rule
Skipping adding existing rule (v6)
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup
Status: active

To                         Action      From
--                         ------      ----
22                         ALLOW       Anywhere                  
80                         ALLOW       Anywhere                  
443                        ALLOW       Anywhere                  
22 (v6)                    ALLOW       Anywhere (v6)             
80 (v6)                    ALLOW       Anywhere (v6)             
443 (v6)                   ALLOW       Anywhere (v6)             

10.0.0.0/8                 DENY OUT    Anywhere                  
172.16.0.0/12              DENY OUT    Anywhere                  
192.168.0.0/16             DENY OUT    Anywhere                  
100.64.0.0/10              DENY OUT    Anywhere                  
198.18.0.0/15              DENY OUT    Anywhere                  
169.254.0.0/16             DENY OUT    Anywhere               

So even though Hetzner does have customizable savable firewall profiles to install on servers by default, this basic firewall setting straight from their blog the abuse team directs users to is not enough to to stop the Docker packages especially IPFS rediscovery searches. So while @3alpha is right that most DAppNode users are on home networks and NAT routers, there is a reason this may want to be altered so that local network discovery is not automatically enabled from install or the profile can be chosen during install or automatically selected depending on whether or not the machine's LAN IP address = its WAN IP address, set to server mode if they are the same, set to the default setting when they are not and its clearly behind a router.

[Snider]

Mine was at hetty, got issued a 2-day sort it out notice, they were really on the case. no messing about.

Not really a fan of extra network noise, more data to deal with :)

[pablomendezroyo]

@3alpha closing this due to inactivity