Ifconfig Monitor Option

I've been playing with IPv6 in my lab. I'm not going to say anything earth-shattering or definitive about IPv6 here or in future posts. I'm at the learning stage, but I figured I would record what I'm seeing.

One of my observations is that IPv6 ships with multiple discovery-type protocols that appear on active interfaces. This is especially interesting for people who want to build "stealthy" network security monitoring sensors.

In the following example, consider em1 to be an interface we wish to use as a passive sniffing NIC. It doesn't make a difference, but I have em1 plugged into the output of a Gigabit port aggregator tap.

hacom:/root# ifconfig em1
em1: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICASTɚmtu 1500
        options=b<RXCSUM,TXCSUM,VLAN_MTU>
        ether 00:40:48:b1:5c:dc
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active

Note that this is a full duplex connection. The SIMPLEX in the output has nothing to do with half or full duplex. SIMPLEX refers to the NIC not being able to transmit and receive while operating on true CSMA/CD Ethernet, which is really not the case with switched networks.

Next we bring up em1.

hacom:/root# ifconfig em1 up
hacom:/root# ifconfig em1
em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        options=b<RXCSUM,TXCSUM,VLAN_MTU>
        inet6 fe80::240:48ff:feb1:5cdc%em1 prefixlen 64 scopeid 0x2 
        ether 00:40:48:b1:5c:dc
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active

Notice that em1 assigns itself a local IPv6 interface, fe80::240:48ff:feb1:5cdc. What is more interesting to me is that it begins sending IPv6 traffic.

hacom:/root# tcpdump -n -i em1 -s 1515
tcpdump: WARNING: em1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1, link-type EN10MB (Ethernet), capture size 1515 bytes
20:04:33.081021 IP6 :: > ff02::1:ffb1:5cdc: ICMP6, neighbor solicitation,
 who has fe80::240:48ff:feb1:5cdc, length 24
20:04:33.081029 IP6 fe80::240:48ff:feb1:5cdc > ff02::2:202:5c8d:
 HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::2:202:5c8d, length 24
20:04:33.081083 IP6 fe80::240:48ff:feb1:5cdc > ff02::1:ffb1:5cdc:
 HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ffb1:5cdc, length 24

One of the tenets of proper passive sensor deployment is not letting the sniffing NIC inject packets onto the monitored network. People like to talk about cutting the transmit wires on Ethernet cables, but I always thought that was silly.

When I see traffic emitted from a supposedly passive interface, I do not like what I see. In the deployment scenario I have here (listening to a tap), these ICMP6 packets are really no problem. This is one of the reasons professionals use passive taps.

If you're placing a sniffing interface on a shared medium like half-duplex Ethernet, a common trick to prevent traffic from leaving the sniffing interface (without cutting wires) is to disable ARP, like so.

hacom:/root# ifconfig em1
em1: flags=8802 mtu 1500
        options=b
        ether 00:40:48:b1:5c:dc
        media: Ethernet autoselect (1000baseTX )
        status: active
hacom:/root# ifconfig em1 -arp up
hacom:/root# ifconfig em1
em1: flags=88c3 mtu 1500
        options=b
        inet6 fe80::240:48ff:feb1:5cdc%em1 prefixlen 64 scopeid 0x2 
        ether 00:40:48:b1:5c:dc
        media: Ethernet autoselect (1000baseTX )
        status: active

Without the interface being able to send and receive ARP traffic (NOARP), it can't send traffic. Or can it?

hacom:/root# tcpdump -n -i em1 -s 1515
tcpdump: WARNING: em1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1, link-type EN10MB (Ethernet), capture size 1515 bytes
20:13:27.711251 IP6 :: > ff02::1:ffb1:5cdc: ICMP6, neighbor solicitation,
 who has fe80::240:48ff:feb1:5cdc, length 24
20:13:29.062884 IP6 fe80::240:48ff:feb1:5cdc > ff02::2:202:5c8d:
 HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::2:202:5c8d, length 24

Wow, there are those pesky ICMP6 messages.

The reason we see them is that IPv6 does not use ARP.

Let's try one more variation.

hacom:/root# ifconfig em1
em1: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        options=b<RXCSUM,TXCSUM,VLAN_MTU>
        ether 00:40:48:b1:5c:dc
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active
hacom:/root# ifconfig em1 monitor up
hacom:/root# ifconfig em1 
em1: flags=48943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,MONITOR> mtu 1500
        options=b<RXCSUM,TXCSUM,VLAN_MTU>
        inet6 fe80::240:48ff:feb1:5cdc%em1 prefixlen 64 scopeid 0x2 
        ether 00:40:48:b1:5c:dc
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active

When I look for traffic now, I see no IPv6 traffic at all. I recommend that we replace the use of "-arp" with "monitor". To disable monitor mode, use "-monitor".

Comments

Anonymous said…
I think it is wise to use 'monitor' option on a passive sniffing interface anyway.

We have 12 passive sniffing interfaces active on one system.
A few weeks back I had some problems with one particular interface. After a while it just stops receiving data. Although the switch shows that it was transmitting the data to our sniffer box, I couldn't figure out what the problem was.

After searching the Net to find answers, I stumble on the 'monitor' option.

I have set this option on all sniffing interfaces and until now it works like a charm.
5:13 AM
Post a Comment

Popular posts from this blog

Zeek in Action Videos

Image
This is a quick note to point blog readers to my Zeek in Action YouTube video series for the Zeek network security monitoring project .  Each video addresses a topic that I think might be of interest to people trying to understand their network using Zeek and adjacent tools and approaches, like Suricata, Wireshark, and so on.  I am especially pleased with Video 6 on monitoring wireless networks . It took me several weeks to research material for this video. I had to buy new hardware and experiment with a Linux distro that I had not used before -- Parrot .  Please like and subscribe, and let me know if there is a topic you think might make a good video.
Read more

MITRE ATT&CK Tactics Are Not Tactics

Image
Just what are "tactics"? Introduction MITRE ATT&CK  is a great resource, but something about it has bothered me since I first heard about it several years ago. It's a minor point, but I wanted to document it in case it confuses anyone else. The MITRE ATT&CK Design and Philosophy document from March 2020 says the following: At a high-level, ATT&CK is a behavioral model that consists of the following core components: • Tactics, denoting short-term, tactical adversary goals during an attack; • Techniques, describing the means by which adversaries achieve tactical goals; • Sub-techniques, describing more specific means by which adversaries achieve tactical goals at a lower level than techniques; and • Documented adversary usage of techniques, their procedures, and other metadata. My concern is with MITRE's definition of "tactics" as "short-term, tactical adversary goals during an attack," which is oddly recursive. The key word in the tacti...
Read more

New Book! The Best of TaoSecurity Blog, Volume 4

Image
  I've completed the TaoSecurity Blog book series . The new book is  The Best of TaoSecurity Blog, Volume 4: Beyond the Blog with Articles, Testimony, and Scholarship .  It's available now for Kindle , and I'm working on the print edition.  I'm running a 50% off promo on Volumes 1-3 on Kindle through midnight 20 April. Take advantage before the prices go back up. I described the new title thus: Go beyond TaoSecurity Blog with this new volume from author Richard Bejtlich. In the first three volumes of the series, Mr. Bejtlich selected and republished the very best entries from 18 years of writing and over 18 million blog views, along with commentaries and additional material.  In this title, Mr. Bejtlich collects material that has not been published elsewhere, including articles that are no longer available or are stored in assorted digital or physical archives. Volume 4 offers early white papers that Mr. Bejtlich wrote as a network defender, either for technica...
Read more