public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* re. too long mac address for --mac-source netfilter option
@ 2001-02-17 19:43 jbinpg
  2001-02-17 19:47 ` Jeremy Jackson
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: jbinpg @ 2001-02-17 19:43 UTC (permalink / raw)
  To: stefan; +Cc: linux-kernel


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




^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: re. too long mac address for --mac-source netfilter option
@ 2001-02-17 22:11 jpinpg
  0 siblings, 0 replies; 6+ messages in thread
From: jpinpg @ 2001-02-17 22:11 UTC (permalink / raw)
  To: linux-kernel


James L. wrote -
> Hello All,
> 
> On Sat, 17 Feb 2001 jbinpg@home.com 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: jbinpg@home.com

^ permalink raw reply	[flat|nested] 6+ messages in thread
[parent not found: <200102180823.f1I8Nqr16293@gate.dodgy.net.au>]
end of thread, other threads:[~2001-02-18 10:42 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-02-17 19:43 re. too long mac address for --mac-source netfilter option jbinpg
2001-02-17 19:47 ` Jeremy Jackson
2001-02-17 20:12 ` Mr. James W. Laferriere
2001-02-18  6:26 ` Darren Tucker
  -- strict thread matches above, loose matches on Subject: below --
2001-02-17 22:11 jpinpg
     [not found] <200102180823.f1I8Nqr16293@gate.dodgy.net.au>
     [not found] ` <l0313034bb6b52c1d7efa@[192.168.239.101]>
2001-02-18 10:41   ` Jonathan Morton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox