7

While monitoring firewall logs I noticed MAC addresses reported in nftables logs which don't match standard length.

It is my understanding that MAC address is 48 bits which should be represented as 12 hexadecimal digits because each hexadecimal digit requires 4 bits therefore 48 / 4 = 12 hexadecimal digits (grouped into 6 groups of 2 digits each).

The above is in line to what wikipedia states:

As typically represented, MAC addresses are recognizable as six groups of two hexadecimal digits, separated by hyphens, colons, or without a separator.

According to wikipedia an example of such address is 01:23:45:67:89:AB, this means there are 12 hexadecimal digits (6 groups x 2 per group = 12) and that's how I recognize devices on my LAN too and how I do traffic filtering on LAN.

Such 6 group hexadecimal digits are also seen in firewall logs (e.g ARP entry), since that's clear I'm not going to post an example of it..

However there are also logs such as this one:

2024-09-29T14:44:21.000498+02:00 debian kernel: [ 2520.417160] DROP default new_in_4: IN=wlan0 OUT= MAC=00:c0:ca:52:bf:8e:10:a3:b8:f5:f7:28:08:00 SRC=157.48.189.170 DST=192.168.1.34 LEN=132 TOS=0x08 PREC=0x20 TTL=43 ID=0 PROTO=UDP SPT=35165 DPT=3451 LEN=112

This one lists 14 groups of hexadecimal digits MAC address or 28 hex digits in total.
All such addresses are begin with 00: and end with :00 as first and last group of digits.

Therefore this MAC address that can be seen in nftables log is more than double size than what it should be (counting prefix group and suffix group of 00).

Question 1 is, what is this 14 group 28 digit MAC address and what does it mean in nftables logs?

And question 2, probably even more interesting is, how is it possible to get MAC address for a peer somewhere on the internet? I assume this MAC address comes from beyond NAT firewall because i don't recognize it.

How do I filter these odd MAC addresses and should I?

This sample log entry is dropped inbound UDP traffic generated by bittorrent peer because I've closed the client.

edit:

ip link show wlan0 3: wlan0 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DORMANT group default qlen 1000 link/ether 00:c0:ca:52:bf:8e brd ff:ff:ff:ff:ff:ff
Improve this question
7
  • If you drop the 00s at the start and end, and split the rest in half, would the resulting 6-byte match mac addresses your network actually has? Well, it seems no, since a3:b8:f5:d7:28:0f is a multicast address... How about the two first 6-byte groups, 00:c4:ca:52:bf:8e and 14:a3:b8:f5:d7:28? Commented Sep 29, 2024 at 13:22
  • @ilkkachu None of the two half portions correspond to any device on LAN including default gateway, however I'm behind CGNAT, maybe this can shade some info. Commented Sep 29, 2024 at 13:25
  • @ilkkachu How about the two first 6-byte groups, 00:c4:ca:52:bf:8e that corresponds to my NIC however the rest is unknown. I've edited my question with actual MAC address. Commented Sep 29, 2024 at 13:29
  • 1
    0x0800 is the ethertype for IPv4 so I'd guess it's dst+src MAC and the ethertype. I think iptables prints similar stuff, but I haven't looked too closely in a long time, and I don't have a reference. And why it's like that instead of separated? Beats me. Commented Sep 29, 2024 at 13:33
  • 2
    Related: serverfault.com/questions/731545/… Commented Sep 29, 2024 at 13:36

1 Answer 1

Reset to default
10

I had a look at the source code to try and find what reports the MAC=.

Found the dump_mac_header function in the Linux Kernel for netfilter which has the following relevant block:

 if (!(logflags & NF_LOG_MACDECODE)) goto fallback; switch (dev->type) { case ARPHRD_ETHER: nf_log_buf_add(m, "MACSRC=%pM MACDST=%pM ", eth_hdr(skb)->h_source, eth_hdr(skb)->h_dest); nf_log_dump_vlan(m, skb); nf_log_buf_add(m, "MACPROTO=%04x ", ntohs(eth_hdr(skb)->h_proto)); return; default: break; } fallback: nf_log_buf_add(m, "MAC="); if (dev->hard_header_len && skb->mac_header != skb->network_header) { const unsigned char *p = skb_mac_header(skb); unsigned int i; if (dev->type == ARPHRD_SIT) { p -= ETH_HLEN; if (p < skb->head) p = NULL; } if (p) { nf_log_buf_add(m, "%02x", *p++); for (i = 1; i < dev->hard_header_len; i++) nf_log_buf_add(m, ":%02x", *p++); }

Which means:

  • If the NF_LOG_MACDECODE log flag is set will report separate MACSRC, MACDST and MACPROTO fields.
  • Otherwise reports just MAC= and a colon separated list of bytes.

I haven't yet tried it, but from Table 60. log-flags in man nft you should be able to set the ether flag to cause the decode of the MAC addresses:

Flag Description
ether Decode MAC addresses an protocol.

MAC=00:c0:ca:52:bf:8e:10:a3:b8:f5:f7:28:08:00

From iptables is occasionally logging MAC addresses. Why? as suggested by ilkkachu then for that 14-byte MAC= in the question think that:

  1. 00:c0:ca:52:bf:8e is the destination MAC address. This matches the MAC address for the wlan0 device given in the qustion. From the Wireshark OUI Lookup Tool that is for the Alfa, Inc. manufacturer, a supplier of WiFi adapters.
  2. 10:a3:b8:f5:f7:28 is the source MAC address. That is for the Iskratel d.o.o. manufacturer , a network-equipment provider for broadband connectivity and converged communications.
  3. 08:00 is the EtherType for IPv4.
Improve this answer
1
  • Excellent explanation!, I though I know all from linked Q/A's in comments but code sample and ether flag is new info that's certainly worth knowing! Commented Sep 29, 2024 at 15:17

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.