Promiscuous mode interfaces transmitting traffic

[Samir]

Hi All,

Has anyone tested or is there a possibility that the promiscuous interfaces configured on security onion will transmit any kind of frames or traffic to the switch its receiving the mirror traffic ?

Is there any configuration we can make on these interfaces to make sure that the transmission is disabled completely.

Thanks
Samir

[Steven J]

Normally, an Interface will listen for frames intended for its own MAC address and will forward those frames to the cpu, it should ignore everything intended to every other MAC address.

Promiscuous mode sets the interface to ignore nothing and forward everything on to the cpu.

The interface does not transmit the same frame it receives, it either ignores or accepts delivery.   

--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/security-onion/ba367a07-ccd6-4da8-9b72-81f35cee83bb%40googlegroups.com.

[Samir]

Hi Steven,

Thanks for your reply. So even the layer two frames such as broadcast aren't transmitted? 

I am asking this because i am currently working with very old and time critical environment. Any broadcast or any kind of traffic transmitted might bring down or cause unexpected behaviors in network.

Just on be sure can i make any config changes that can block any transmission or is it taken care by security onion installation?

Thanks

Samir  

You received this message because you are subscribed to a topic in the Google Groups "security-onion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/security-onion/vkFosrQkv4E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-onio...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/security-onion/CAKHG%3D-%2BaYSknSAqavBg2H%2BU12ppPgnaWZQ-X6GugQXB%3D24hiow%40mail.gmail.com.

--

Warm Regards
Samir

[Steven J]

Every NIC in the same Broadcast Domain will hear everything that is on that segment, at or about the same time.

The NIC does not re-transmit frames meant for other address.

If the frame was meant for them, they will ingest it into the NIC cpu for processing.

If it was meant for a different address, they will not ingest the frame, they will ignore it.

In Promiscuous mode, the NIC Listens as though it is everybody. 
No IP stack is associated because, allowing a single NIC to speak as everybody, would be catastrophic in the collision domain.  Compare it to spoofing every MAC on the subnet.

I think, generally, the NIC would have little reason to transmit much of anything.

To view this discussion on the web visit https://groups.google.com/d/msgid/security-onion/CABxXOGxk-UDn-pMU3sn2FWAKvCubJ44jKqcrZ6h-Y5%2BaAneZvw%40mail.gmail.com.

[Samir]

Hi Steven,

I just checked the details using ifconfig on server(esxi) which have been setup for more than 3 days now and so(vmware fusion)which was paused for a while. On both machine i see TX bytes on sniffing interfaces.

1.  TX bytes on server(esxi) since 3 days 3.8 MB

2. TX bytes on so virtual machine(vm fusion) 70 bytes.

To view this discussion on the web visit https://groups.google.com/d/msgid/security-onion/CAKHG%3D-JROYsqddtGA1mrbnrMGbEt4UO-6X%2B42NGCgBDmu4eG5A%40mail.gmail.com.

--

Warm Regards
Samir

[Pete]

Samir, responses inline

On Thursday, 27 February 2020 13:24:23 UTC-5, Samir wrote:

1.  TX bytes on server(esxi) since 3 days 3.8 MB

This is probably STP or CDP/LLDP by the virtual switch in esxi.  Based on below, it's something originated by vmware, not by the sensor.  I'd check their forums for more details.

2. TX bytes on so virtual machine(vm fusion) 70 bytes.

 

I'm not sure about this, but a couple of thoughts.  When I bring my interface up, I make sure to disable arp and multicast.  I see 12 TX packets, so there's something else, but I'm not sure.  Maybe broadcast as well?  Maybe disable IPv6 globally?

iface enp175s0f0 inet manual

  up ip link set $IFACE promisc on arp off multicast off up 

If you are bonding multiple physical interfaces, they'll normally transmit some LACP.  There may be a way to disable it, but I don't know.  This is likely not your issue, but worth mentioning for completeness...

--

Pete

[Samir]

Hi Pete, 

Thank you very much.  I see arp is not disabled and the tx has increased to 8.6 MB. Even the ports which are physically not connected to cable are transmitting the same amount of traffic. 

I tried to use the commands you shared but these commands are not being recognized.

Thanks 

--

Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to a topic in the Google Groups "security-onion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/security-onion/vkFosrQkv4E/unsubscribe.

To unsubscribe from this group and all its topics, send an email to security-onion+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/security-onion/9422bd31-30f1-404b-9492-ddb204b32a6f%40googlegroups.com.

--

Warm Regards
Samir

[Samir]

Hi All, 

I found out the problem it was the ipv6 which was causing the issue i used below commands to disable arp and ipv6 . I have been monitoring since few hours and not a single packet is being sent.

Note : disabling ipv6 with below commands will not survive the reboot

sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=1 sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1 sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=1

ip link set dev eth0 arp off

https://superuser.com/questions/399517/disabling-the-arp-protocol-in-linux-box/399541

https://itsfoss.com/disable-ipv6-ubuntu-linux/

--

Warm Regards
Samir