Jack Bowling wrote -
>> I am trying to use the --mac-source option in the netfilter code to better refine access to my linux box. However, I > have run up against something. The router through which my private subnet work box passes sends a 14-group "invalid" > mac address, presumably as an attempt to conceal the real hextile mac address. However, the code for the > --mac-source netfilter option is looking for a valid hextile mac address and complains loudly as such (numerals converted to x's):
>>
>> iptables v1.1.1: Bad mac address `xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx'
>>
>> to the respective iptable line:
>>
>> $IPT -A INPUT -p tcp -s xxx.xxx.xxx.xxx -d $NET -m mac --mac-source xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx --dport 5900:5901 -j ACCEPT
>>
>> The idea here is to allow VNC access to my home box with the access filtered by both IP and mac address.
>>
>> Is there a resolution to this other than a rewrite and recompile of the relevant sections of the iptable code? Or am I stuck? I know this option is tagged by Rusty as experimental still so I would assume that the code is open for feedback ;) The question could be rephrased as: is there any chance of allowing "invalid" mac addresses to be recognized by the --mac-source option of the netfilter code? Running Redhat v7/kernel 2.4.1-ac15.
Stefan Hanse writes -
>Umm.. An ethernet MAC address is 48bit long, ie AA:BB:CC:DD:EE:FF, 6 groups, not 14. Is this really an ethernet
>interface? (If it really has 14 groups).
Good question. I have determined by scanning my firewall logs that the "invalid" mac addresses are all coming from cable modem routers. And my linux kernel is recognizing them as being MAC addresses. Would it be better to write another module looking for these long "MAC" rather than tamper with the mac module?
To illustrate, here is a cut from my system log showing a portscan from my cable modem provider (a routine part of their service contract since you are not allowed to run client-side servers). SRC and DST have been x'ed out:
Feb 17 08:49:42 nonesuch kernel: IN=eth0 OUT= MAC=00:01:02:69:49:4f:00:00:77:93:83:d2:08:00 SRC=xx.xx.xx.xx DST=xx.xx.xx.xx LEN=44 TOS=0x00 PREC=0x00 TTL=246 ID=21419 PROTO=TCP SPT=45435 DPT=119 WINDOW=8760 RES=0x00 SYN URGP=0
Feb 17 08:49:43 nonesuch kernel: IN=eth0 OUT= MAC=00:01:02:69:49:4f:00:00:77:93:83:d2:08:00 SRC=xx.xx.xx.xx DST=xx.xx.xx.xx LEN=40 TOS=0x00 PREC=0x00 TTL=246 ID=21420 PROTO=TCP SPT=45435 DPT=119 WINDOW=8760 RES=0x00 RST URGP=0
Feb 17 08:49:43 nonesuch kernel: IN=eth0 OUT= MAC=00:01:02:69:49:4f:00:00:77:93:83:d2:08:00 SRC=xx.xx.xx.xx DST=xx.xx.xx.xx LEN=44 TOS=0x00 PREC=0x00 TTL=246 ID=21421 PROTO=TCP SPT=45806 DPT=119 WINDOW=8760 RES=0x00 SYN URGP=0
Feb 17 08:49:43 nonesuch kernel: IN=eth0 OUT= MAC=00:01:02:69:49:4f:00:00:77:93:83:d2:08:00 SRC=xx.xx.xx.xx DST=xx.xx.xx.xx LEN=40 TOS=0x00 PREC=0x00 TTL=246 ID=21422 PROTO=TCP SPT=45806 DPT=119 WINDOW=8760 RES=0x00 RST URGP=0
Feb 17 08:49:43 nonesuch kernel: IN=eth0 OUT= MAC=00:01:02:69:49:4f:00:00:77:93:83:d2:08:00 SRC=xx.xx.xx.xx DST=xx.xx.xx.xx LEN=44 TOS=0x00 PREC=0x00 TTL=246 ID=21423 PROTO=TCP SPT=46248 DPT=119 WINDOW=8760 RES=0x00 SYN URGP=0
Feb 17 08:49:44 nonesuch kernel: IN=eth0 OUT= MAC=00:01:02:69:49:4f:00:00:77:93:83:d2:08:00 SRC=xx.xx.xx.xx DST=xx.xx.xx.xx LEN=40 TOS=0x00 PREC=0x00 TTL=246 ID=21424 PROTO=TCP SPT=46248 DPT=119 WINDOW=8760 RES=0x00 RST URGP=0
All hits on my firewall from cable modem servers other than my own provider also have the 14 group "MAC" address so it looks like this may be a feature of these units.
Jack
P.S. - I have moved this to another of my email accounts
[email protected] wrote:
>All hits on my firewall from cable modem servers other than my own provider also have the 14 group "MAC" address so it l>ooks like this may be a feature of these units.
Some cable providers use Ethernet bridging instead of full ip routing. perhaps this is what you are seeing.
Maybe TCPdump will label packets which are for "spanning tree" or similar?
Hello All,
On Sat, 17 Feb 2001 [email protected] wrote:
> Stefan Hanse writes -
> >Umm.. An ethernet MAC address is 48bit long, ie AA:BB:CC:DD:EE:FF, 6
>groups, not 14. Is this really an ethernet
> >interface? (If it really has 14 groups).
>
>> Good question. I have determined by scanning my firewall logs that the
>"invalid" mac addresses are all coming from cable modem routers. And my
>linux kernel is recognizing them as being MAC addresses. Would it be
>better to write another module looking for these long "MAC" rather than
>tamper with the mac module?
>
>> To illustrate, here is a cut from my system log showing a portscan from
>my cable modem provider (a routine part of their service contract since
>you are not allowed to run client-side servers). SRC and DST have been
>x'ed out:
>
>> Feb 17 08:49:42 nonesuch kernel: IN=eth0 OUT=
>MAC=00:01:02:69:49:4f:00:00:77:93:83:d2:08:00 SRC=xx.xx.xx.xx
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This appears to be an ATM NSAP address . Hth , JimL
>DST=xx.xx.xx.xx LEN=44 TOS=0x00 PREC=0x00 TTL=246 ID=21419 PROTO=TCP
>SPT=45435 DPT=119 WINDOW=8760 RES=0x00 SYN URGP=0
>> All hits on my firewall from cable modem servers other than my own
>provider also have the 14 group "MAC" address so it looks like this may
>be a feature of these units.
+----------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | 25416 22nd So | Give me Linux |
| [email protected] | DesMoines WA 98198 | only on AXP |
+----------------------------------------------------------------+
James L. wrote -
> Hello All,
>
> On Sat, 17 Feb 2001 [email protected] wrote:
> > Stefan Hanse writes -
> > >Umm.. An ethernet MAC address is 48bit long, ie AA:BB:CC:DD:EE:FF, 6
> >groups, not 14. Is this really an ethernet
> > >interface? (If it really has 14 groups).
> >
> >> Good question. I have determined by scanning my firewall logs that the
> >"invalid" mac addresses are all coming from cable modem routers. And my
> >linux kernel is recognizing them as being MAC addresses. Would it be
> >better to write another module looking for these long "MAC" rather than
> >tamper with the mac module?
> >
> >> To illustrate, here is a cut from my system log showing a portscan from
> >my cable modem provider (a routine part of their service contract since
> >you are not allowed to run client-side servers). SRC and DST have been
> >x'ed out:
> >
> >> Feb 17 08:49:42 nonesuch kernel: IN=eth0 OUT=
> >MAC=00:01:02:69:49:4f:00:00:77:93:83:d2:08:00 SRC=xx.xx.xx.xx
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This appears to be an ATM NSAP address . Hth , JimL
OK, thanks Jim. The question then becomes: could a netfilter module for recognizing ATM addresses be developed? Are all ATM addresses 14 groups?
Jack Bowling
mailto: [email protected]
[email protected] wrote:
> Jack Bowling wrote -
> >> iptables v1.1.1: Bad mac address `xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx'
> >>
> >> to the respective iptable line:
> >>
> >> $IPT -A INPUT -p tcp -s xxx.xxx.xxx.xxx -d $NET -m mac --mac-source xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx --dport 5900:5901 -j ACCEPT
> >>
> >> The idea here is to allow VNC access to my home box with the access filtered by both IP and mac address.>
> Stefan Hanse writes -
>
> >Umm.. An ethernet MAC address is 48bit long, ie AA:BB:CC:DD:EE:FF, 6 groups, not 14. Is this really an ethernet
> >interface? (If it really has 14 groups).
> All hits on my firewall from cable modem servers other than my own provider also have the 14 group "MAC" address so it looks like this may be a feature of these units.
It looks like it's the entire MAC-level header that is logged:
destination, source and protocol type.
I did a quick test with the PPPoE link down and the upstream cable
unplugged. I telnetted into the modem and generated a single UDP packet
to the echo port on the linux box (using the command "ip sendto
addr=10.0.0.1 count=1 size=10 dstport=7").
The kernel logged:
IN=eth1 OUT= MAC=08:00:2b:e2:a6:a3:00:90:d0:1b:4d:1c:08:00
SRC=10.0.0.138 DST=10.0.0.1 LEN=38 TOS=0x00 PREC=0x00 TTL=64 ID=2693
PROTO=UDP SPT=1032 DPT=7 LEN=18
The tcpdump output from this exchange:
[root@gate dtucker]# tcpdump -i eth1 -vv -x -e -p ! port telnet
Kernel filter, protocol ALL, datagram packet socket
tcpdump: listening on eth1
13:07:04.105231 < 0:90:d0:1b:4d:1c 0:0:0:0:0:1 ip 60: 10.0.0.138.1041 >
10.0.0.1.echo: udp 10 (ttl 64, id 3335)
4500 0026 0d07 0000 4011 5936 0a00 008a
0a00 0001 0411 0007 0012 8cc8 4142 4344
4546 4748 494a 0000 0000 0000 0000
13:07:04.105900 > 0:0:0:0:0:0 8:0:2b:e2:a6:a3 ip 80: 10.0.0.1 >
10.0.0.138: icmp: 10.0.0.1 udp port echo unreachable Offending pkt:
10.0.0.138.1041 > 10.0.0.1.echo: udp 10 (ttl 64, id 3335) (DF) [tos
0xc0] (ttl 255, id 0)
45c0 0042 0000 4000 ff01 6670 0a00 0001
0a00 008a 0303 11ab 0000 0000 4500 0026
0d07 0000 4011 5936 0a00 008a 0a00 0001
0411 0007 0012 8cc8 4142 4344 4546 4748
494a
Environment:
Kernel 2.4.2-pre3 running on an AMD K6-3.
eth1 is a DE435 using the de4x5 driver. MAC address 08:00:2B:E2:A6:A3
Alcatel "Speed Touch Home" ADSL modem connected to eth1. MAC address
00:90:D0:1B:4D:1C
The (relevant parts of the) iptables:
iptables -N droplog
iptables -A droplog -j LOG
iptables -A droplog -j REJECT
iptables -A INPUT -i eth1 -m state --state NEW,INVALID -j droplog
iptables -A FORWARD -i eth1 -m state --state NEW,INVALID -j droplog
Further comments:
1) I know that some of the the MAC addresses given by tcpdump are
invalid. Is this a bug? In what?
2) I've also repeated this test with the tulip driver, with the same
results.
-Daz.
>> >1) I know that some of the the MAC addresses given by tcpdump are
>> >invalid. Is this a bug? In what?
>>
>> Nope. The addresses (with mostly zeroes) are like IP addressses with many
>> zeroes or '255' - they handle concepts like "broadcast" or "me".
>
>Huh? It's a vanilla unicast IP datagram over ethernet. Not broadcast or
>multicast. It should have the MAC addresses of the source and destination
>devices. (In fact, it does, since I've just fired up SMS network monitor
>on my work laptop and sniffed it.)
>
>It's like the destination address in the ethernet frame is being stomped
>before being handed to tcpdump
Or, it hasn't acquired it yet because it hasn't passed through the Ethernet
hardware. So it'll read as the generic MAC address for "me" (0:0:0:0:0:1)
until it actually goes on the wire and comes back off again. This is
almost certainly what's happening in the outgoing packet.
In the case of the reply packet, which is an ICMP error message, the source
MAC address is all zeroes - this may simply be an indication saying "this
packet could have come from anywhere, please don't reply". The packet
causing the ICMP error message is detailed within the ICMP message itself,
and the host where the error originated is detailed in the IP header.
.... runs some tests on own hardware ....
OK, now I'm confused. I'm watching tcpdump of some perfectly ordinary
stuff going on between a 2.2.16 machine (helium, using eepro) and a 2.4.1
box (lithium, using via-rhine). Here's an NTP exchange:
10:01:51.113583 < 0:50:ba:aa:77:88 0:0:0:0:0:1 ip 90:
lithium.chromatix.org.uk.ntp > helium.chromatix.org.uk.ntp: v4 client strat
4
poll 6 prec -17 dist 0.019088 disp 0.036071 ref
[email protected] orig 3191479248.135523006 rec
-0.004402999 xmt +62.985828995 (DF) (ttl 64, id 0)
4500 004c 0000 4000 4011 da7b c0a8 ef6b
c0a8 ef68 007b 007b 0038 1076 2304 06ef
0000 04e3 0000 093c c0a8 ef68 be3a 1bd0
2191 148f be3a 1bd0 22b1 a2a4 be3a 1bd0
2191 148f be3a 1c0f 1f10 ecb7
This packet is incoming to helium, and it shows the MAC address of lithium
along with the so-called "me" address I mentioned.
10:01:51.123585 > 0:0:0:0:0:0 0:aa:0:aa:7a:86 ip 90:
helium.chromatix.org.uk.ntp > lithium.chromatix.org.uk.ntp: v4 server strat
3 p
oll 6 prec -16 dist 0.015533 disp 0.026077 ref
[email protected] orig 3191479311.121352002 rec
+0.002871999 xmt +0.003857000 (ttl 64, id 42171)
4500 004c a4bb 0000 4011 75c0 c0a8 ef68
c0a8 ef6b 007b 007b 0038 621a 2403 06f0
0000 03fa 0000 06ad 9458 0804 be3a 1a7e
960c 49ba be3a 1c0f 1f10 ecb7 be3a 1c0f
1fcd 24e1 be3a 1c0f 200d b270
This one is outgoing, and it contains helium's *OWN* MAC address, and the
all-zeroes one. I'm fairly sure NTP doesn't use broadcast, at least in my
configuration.
10:08:24.365128 M 0:0:94:61:aa:83 1:0:0:0:0:0 0004 50: snap atalkarp aarp
len 28 op 256 htype 256 ptype 0x9b80 halen 6 palen 4
aaaa 0300 0000 80f3 0001 809b 0604 0001
0000 9461 aa83 00ff 00a3 0000 0000 0000
00ff 00ad
This is an interesting one - it's a multicast packet from one of my Macs,
performing some obscure AppleTalk thing (AARP == AppleTalk Address
Resolution Protocol, so it's really not that obscure). Notice the
pseudo-MAC is different here than in the incoming NTP packet. The real
MAC, in the first MAC field, is that of the Mac sending the AARP query
(turns out to be the Quadra, after searching through the control panels on
the several Macs I have).
.... reconsiders situation ....
Looks like it could either be a bug, or an obscure feature which neither of
us have noticed yet. From the tcpdump manpage: "On ethernets, the source
and destination addresses, protocol and packet length are printed." This
may well be the case, but it doesn't match up with what's showing up in the
above traces, or in yours either.
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: [email protected] (not for attachments)
big-mail: [email protected]
uni-mail: [email protected]
The key to knowledge is not to rely on people to teach you it.
Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/
-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-----END GEEK CODE BLOCK-----