Promiscuous mode for VM

[Morphushka]

Hello. I want to install some kind of special software for blocking traffic. My colleague successfully install it on esxi and this require promiscuous mode enabled.
I found I can enable promisc mode on host system like this:

auto lo
iface lo inet loopback

iface enp3s0 inet manual

auto vmbr0
iface vmbr0 inet static
address 192.168.244.253
netmask 255.255.255.0
gateway 192.168.244.254
bridge_ports enp3s0
bridge_stp off
bridge_fd 0
up /sbin/ip link set enp3s0 promisc on

but it is enable promisc for whole host.
1) Can I do this mode just for concrete VM ?
2) Is it dangerous (or other limitations) to do it for host it self ?
Thanks!

 

[Stoiko Ivanov]

Which software are you referring to?
setting the bridge-port to promiscous (up /sbin/ip link set enp3s0 promisc on) is not necessary since ifup does this anyways (else the bridge would not get all traffic for other mac-addresses)

depending on where you want to run the software - you might need to set the bridge itself to promiscous on - or you might need to disable mac-learning on the bridge (by setting the bridge_ageing parameter to 0)

There are a few threads on this forum, which deal with similar questions (search for 'mirror port', 'span port', snort, suricata)

I hope this helps!

 

[Morphushka]

is not necessary since ifup does this anyways

Then why I don't see "PROMISC" status on my host interfaces ?

4: enp5s0f0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
    link/ether 00:1b:21:a7:95:74 brd ff:ff:ff:ff:ff:ff
5: enp5s0f1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
    link/ether 00:1b:21:a7:95:74 brd ff:ff:ff:ff:ff:ff
6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether 00:1b:21:a7:95:74 brd ff:ff:ff:ff:ff:ff
7: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:1b:21:a7:95:74 brd ff:ff:ff:ff:ff:ff
    inet xx.xx.xx.xx/26 brd xx.xx.xx.xx scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 xxxx::xxx:xxxx:xxxx:xxxx/64 scope link
       valid_lft forever preferred_lft forever

I just have this on tap interfaces which belongs to VMs:

root@vega:~# ip a | grep PROMISC
28: tap202i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr202i0 state UNKNOWN group default qlen 1000
408: tap218i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr218i0 state UNKNOWN group default qlen 1000
176: tap212i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr212i0 state UNKNOWN group default qlen 1000

or I look in wrong place ?

Which software are you referring to?

Open source project on github ext-filter
It use at least 2 nic: 1 for incoming (mirrored) traffic and 2 for answering. Check incoming traffic for http/https requests and if site in block list, then send reset answer.

Thanks for answer, I try to search forum that keywords.

 

[Stoiko Ivanov]

Then why I don't see "PROMISC" status on my host interfaces ?

check the output of

ip -details link

- here it shows promiscuity 1

 

[Ramalama]

@Stoiko Ivanov
why promiscous mode and not a proper way like:
bridge fdb add LXC_KVM_MADDR dev PHYNAME
(just for interrest, not as attack xD)

does mac-learning works in PHY to avoid that?

 

[Stoiko Ivanov]

hm?
not quite sure I understand that - but the bridge(8) manpage seems to indicate that the command `bridge fdb add MACADDR dev PHYNAME` simply adds a forwarding entry for a mac-address to the bridgeport?
how does this affect the promiscuous mode of the interface - and how does it cause all traffic to be handed to a particular interface port?

(simply have not seen an example of such a thing - and think that the port still would need to be in promiscous mode not to discard any packets not for it's own mac-address...)

 

[Ramalama]

Well i thought it this way:
Promiscuous listens for all macaddresses
And if you don't run promiscuous, you can add additional macaddresses to that listening list xD

But okay 2 different things.

In my case on my server, i have this structure:
-enp35s0f0 (phy)
--- vmbr0 (bridge) (multiple lxc container)
--- sr-iov0 (virt function) (kvm-opnsense)
--- sr-iov1 (virt function) (kvm-w10)

And i need to add with bridge fdb add ... every macaddress that is hosted on vmbr0 to enp35s0f0. Including the macaddress from vmbr0 itself xD

If i don't do it, sr-iov functions can't reach anything on vmbr0.

I have a script for this that i have wrapped into a service etc... So it works all fine. But thinked of other options.