Interface entered in promiscuous(sniffing) mode.

[d4n74]

Hi, I have a host IDS (Wazuh) that I use to monitor my Umbrel node. I got 2856 alerts in the last 24 hours (everyday) that the docker interfaces have entered in promiscuous(sniffing) mode.

This behavior is a security risk and should be addressed.

Thank You

syslog: Mar 28 14:39:06 ln kernel: [255685.294871] device vethe0ae8ca entered promiscuous mode

[BorjaRuizReverter]

I have the same issue. There is an app inside Umbrel (or Umbrel itself) that takes over the virtual ethernet device and continuously keeps on trying to forward ports, one after the other. After a while my ethernet device becomes overwhelmed and it shuts down, turning Umbrel down with it. This issue not only affects Umbrel runtime but also, as @d4n74 said before, may cause security risks.

I am not running Umbrel as freely and comfortably as I was until I figure out what might cause this.

I am forwarding a dmesg of the issue.

[Alvie]

Did either of you find out what caused it or how to fix this issue? @d4n74 @BorjaRuizReverter

[BorjaRuizReverter]

I think that at this point we have to distinguish between 3 apparent issues:

1. The fact that there are a miriad of veths created, despite of limited Umbrel apps (just 3 apps in my case).
2. The security risks involved in that (for I thought that every veth may open a port in my machine!).
3. The constant messages of "device veth.... entered promiscuous mode" every now and then.

Regarding the first issue, I installed the bridge-utils package, then I typed:

$ brctl show

to check both the bridge name (it starts with br) created by Umbrel through docker and all their interfaces created in terms of virtual ethernets (veth). And then, I inspected the bridge

$ sudo docker network inspect <bridge name without br letters>

to check all the containers that were created for the apps that were installed under Umbrel.

My conclusion about this first issue is that is not a real issue as every container (despite of being a lot) kind of make sense.

Regarding the second issue (potencial security risks), as far as I understood, every app (docker container) installed inside Umbrel uses a MAC address that communicates internally through virtual network interfaces (veth) to a docker bridge (docker0), which establishes a link to the physical network interface (eth), from which the external communication to the www is held.

This way, despite of the scaring messages of "device veth.... entered promiscuous mode", every veth is not connected directly to the external www and, therefore, these modes doesnt represent (afaik) a security risk at all.

Regarding the third issue, I read here https://github.com/moby/moby/issues/14807#issuecomment-123366926 that this is a normal behavior in docker. I am not an expert in docker, that is why I doubt about it. But if any day I run any network app using docker I will check this out and comment about it.

So, I think guys that, excluding this third "issue", which might indeed tagged as normal behavior, we should calm down and trust Umbrel for now.

NOTE: My Umbrel app did not shut down anymore, so the reason of that misbehavior were probably due to another issue in my machine and not because of the "overwhelming of opening/closing veths" I related in my previous comment.

[Alvie]

I think that at this point we have to distinguish between 3 apparent issues:

1. The fact that there are a miriad of veths created, despite of limited Umbrel apps (just 3 apps in my case).
2. The security risks involved in that (for I thought that every veth may open a port in my machine!).
3. The constant messages of "device veth.... entered promiscuous mode" every now and then.

Regarding the first issue, I installed the bridge-utils package, then I typed:

$ brctl show

to check both the bridge name (it starts with br) created by Umbrel through docker and all their interfaces created in terms of virtual ethernets (veth). And then, I inspected the bridge

$ sudo docker network inspect <bridge name without br letters>

to check all the containers that were created for the apps that were installed under Umbrel.

My conclusion about this first issue is that is not a real issue as every container (despite of being a lot) kind of make sense.

Regarding the second issue (potencial security risks), as far as I understood, every app (docker container) installed inside Umbrel uses a MAC address that communicates internally through virtual network interfaces (veth) to a docker bridge (docker0), which establishes a link to the physical network interface (eth), from which the external communication to the www is held.

This way, despite of the scaring messages of "device veth.... entered promiscuous mode", every veth is not connected directly to the external www and, therefore, these modes doesnt represent (afaik) a security risk at all.

Regarding the third issue, I read here moby/moby#14807 (comment) that this is a normal behavior in docker. I am not an expert in docker, that is why I doubt about it. But if any day I run any network app using docker I will check this out and comment about it.

So, I think guys that, excluding this third "issue", which might indeed tagged as normal behavior, we should calm down and trust Umbrel for now.

NOTE: My Umbrel app did not shut down anymore, so the reason of that misbehavior were probably due to another issue in my machine and not because of the "overwhelming of opening/closing veths" I related in my previous comment.

Thanks for the response. I'm not sure why my umbrel kept shutting down, and I eventually gave up after fresh installs, new SD cards, new cables...

Maybe the power supply is not good any more :/ but I think I'll upgrade to a N100 Mini PC once UmbrelOS 1.0 is released. Hopefully, it will let me store the chain on an external NVMe SSD and be more reliable.