Filtering invalid MAC addresses

Filtering invalid MAC addresses

[jordi guri]

Hi,

I was wondering if the newer nftables is able to deal with invalid MAC 
addresses.  iptables I don't think can deal with these.  For example I 
have the following showing up in my log (from some anonymous proxy port 
scanner):
+++++
Nov 27 17:27:40 northome kernel: ** iptables-DROP ** IN=eth0 OUT= 
MAC=f2:3c:91:9b:81:db:84:78:ac:0d:79:c1:08:00 SRC=183.
60.48.25 DST=23.92.27.236 LEN=40 TOS=0x00 PREC=0x20 TTL=51 ID=0 DF 
PROTO=TCP SPT=12208 DPT=5902 WINDOW=8192 RES=0x00 SYN
  URGP=0

Nov 27 17:31:50 northome kernel: ** iptables-DROP ** IN=eth0 OUT= 
MAC=f2:3c:91:9b:81:db:84:78:ac:0d:a6:41:08:00 SRC=175.
194.186.44 DST=23.92.27.236 LEN=40 TOS=0x00 PREC=0x00 TTL=52 ID=39168 
PROTO=TCP SPT=24565 DPT=23 WINDOW=19941 RES=0x00 S
+++++

There are many such entries as the above (all day, every minute) for 
various destination ports on my server, and (in this case) with the same 
2 invalid MAC addresses.

What is interesting about this is that the first part of both of the 
above MAC addresses in my iptables log are; "f2:3c:91:9b:81:db".  This 
happens to be the same MAC address as that of my server's eth0 
interface.  Therefore I cannot block these scan attempts via the MAC 
address alone (even if I could in part).

So my question;  Does/is nftables/iptables going to offer some sort of 
solution to the above invalid MAC address problem, as iptables does 
currently for invalid packets and IP addresses?

Thank-you for your time and your very fine work on this fantastic 
firewall product.


Thanks and regards,

Jordi

Re: Filtering invalid MAC addresses

[Michal Kubecek]

On Sun, Nov 27, 2016 at 06:09:11PM -0800, jordi guri wrote:
> 
> I was wondering if the newer nftables is able to deal with invalid
> MAC addresses.  iptables I don't think can deal with these.  For
> example I have the following showing up in my log (from some
> anonymous proxy port scanner):
> +++++
> Nov 27 17:27:40 northome kernel: ** iptables-DROP ** IN=eth0 OUT=
> MAC=f2:3c:91:9b:81:db:84:78:ac:0d:79:c1:08:00 SRC=183.
> 60.48.25 DST=23.92.27.236 LEN=40 TOS=0x00 PREC=0x20 TTL=51 ID=0 DF
> PROTO=TCP SPT=12208 DPT=5902 WINDOW=8192 RES=0x00 SYN
>  URGP=0
> 
> Nov 27 17:31:50 northome kernel: ** iptables-DROP ** IN=eth0 OUT=
> MAC=f2:3c:91:9b:81:db:84:78:ac:0d:a6:41:08:00 SRC=175.
> 194.186.44 DST=23.92.27.236 LEN=40 TOS=0x00 PREC=0x00 TTL=52
> ID=39168 PROTO=TCP SPT=24565 DPT=23 WINDOW=19941 RES=0x00 S
> +++++
> 
> There are many such entries as the above (all day, every minute) for
> various destination ports on my server, and (in this case) with the
> same 2 invalid MAC addresses.

Why do you call them "invalid"? As far as I can tell, 84:78:ac:0d:79:c1
and 84:78:ac:0d:a6:41 are normal MAC addresses (with Cisco vendor
prefix), there doesn't seem to be anything invalid about them.

> What is interesting about this is that the first part of both of the
> above MAC addresses in my iptables log are; "f2:3c:91:9b:81:db".
> This happens to be the same MAC address as that of my server's eth0
> interface.

What you call "first part" is the destination MAC address so it's hardly
surprising it matches the MAC address of the incoming interface.

Just to be sure: do you understand that the string after "MAC=" is _not_
a MAC address (it's obviously too long for that) but the whole ethernet
header consisting of

  - 6 bytes of destination MAC address
  - 6 bytes of source MAC address
  - 2 bytes of packet type (0800 is IPv4)

and that source MAC address in this header is always going to belong to
the last hop on the way to you, i.e. it's almost always useless for
identifying the actual attacker?

                                                         Michal Kubecek

Re: Filtering invalid MAC addresses

[Phil Sutter]

Hi,

On Sun, Nov 27, 2016 at 06:09:11PM -0800, jordi guri wrote:
> I was wondering if the newer nftables is able to deal with invalid MAC 
> addresses.  iptables I don't think can deal with these.  For example I 
> have the following showing up in my log (from some anonymous proxy port 
> scanner):
> +++++
> Nov 27 17:27:40 northome kernel: ** iptables-DROP ** IN=eth0 OUT= 
> MAC=f2:3c:91:9b:81:db:84:78:ac:0d:79:c1:08:00 SRC=183.
> 60.48.25 DST=23.92.27.236 LEN=40 TOS=0x00 PREC=0x20 TTL=51 ID=0 DF 
> PROTO=TCP SPT=12208 DPT=5902 WINDOW=8192 RES=0x00 SYN
>   URGP=0
> 
> Nov 27 17:31:50 northome kernel: ** iptables-DROP ** IN=eth0 OUT= 
> MAC=f2:3c:91:9b:81:db:84:78:ac:0d:a6:41:08:00 SRC=175.
> 194.186.44 DST=23.92.27.236 LEN=40 TOS=0x00 PREC=0x00 TTL=52 ID=39168 
> PROTO=TCP SPT=24565 DPT=23 WINDOW=19941 RES=0x00 S
> +++++
> 
> There are many such entries as the above (all day, every minute) for 
> various destination ports on my server, and (in this case) with the same 
> 2 invalid MAC addresses.

Looking at nf_log_ipv4.c, what is actually printed after 'MAC=' is not
just a MAC address, but the full Ethernet header, i.e. a combination of
destination MAC address, source MAC address and Ethertype. So the first
logged packet above has destination MAC address f2:3c:91:9b:81:db,
source MAC address 84:78:ac:0d:79:c1 (prefix 84:78:ac belongs to Cisco
Systems Inc.) and Ethertype of 0x0800 (IPv4).

> What is interesting about this is that the first part of both of the 
> above MAC addresses in my iptables log are; "f2:3c:91:9b:81:db".  This 
> happens to be the same MAC address as that of my server's eth0 
> interface.  Therefore I cannot block these scan attempts via the MAC 
> address alone (even if I could in part).

Which is expected, otherwise your server wouldn't receive the frame. :)

> So my question;  Does/is nftables/iptables going to offer some sort of 
> solution to the above invalid MAC address problem, as iptables does 
> currently for invalid packets and IP addresses?

With iptables, there is '-m mac' to match source MAC addresses. With
nftables, you can use 'ether saddr' or 'ether daddr' matches to test
against source or destination MAC address.

Cheers, Phil