MAC Filtering from Public to Trusted Side of Router???

Does anyone know of a WIRED router and/or firewall, Linux-based or
otherwise, that can do MAC filtering without using DHCP? IPCOP comes
close from what I see looking at the documentation, but I don't want
to use DHCP to accomplish this, and I need to filter traffic coming
from the public side, not the private.

My situation is that I have cash ATMs on a dedicated network, and I
have to route their traffic to a controller on our primary LAN. What I
need to do is assign a static IP address to each ATM and link it to a
MAC address, perhaps in a firewall rule, so that a foreign device
can't attach to our ATM network and route into our LAN. I know that
MAC filtering alone isn't foolproof, but we'd like to be able to do
this as part of our security strategy.

I have no trouble finding little wireless access points that can
restrict MACs, but I have not yet found a robust router/firewall that
can specify which MAC addresses on the public side of the router can
come across to the trusted side.

Any help is much appreciated.



TL

T. Little wrote:
>
> Does anyone know of a WIRED router and/or firewall, Linux-based or
> otherwise, that can do MAC filtering without using DHCP? IPCOP comes
> close from what I see looking at the documentation, but I don't want
> to use DHCP to accomplish this, and I need to filter traffic coming
> from the public side, not the private.
>
> My situation is that I have cash ATMs on a dedicated network, and I
> have to route their traffic to a controller on our primary LAN. What I
> need to do is assign a static IP address to each ATM and link it to a
> MAC address, perhaps in a firewall rule, so that a foreign device
> can't attach to our ATM network and route into our LAN. I know that
> MAC filtering alone isn't foolproof, but we'd like to be able to do
> this as part of our security strategy.
>
> I have no trouble finding little wireless access points that can
> restrict MACs, but I have not yet found a robust router/firewall that
> can specify which MAC addresses on the public side of the router can
> come across to the trusted side.


The recent versions of iptables can do filtering
based on the MAC addresses. It should not be
very difficult to write the rules to allow only
the desired MAC addresses.

Please understand that a MAC-based filter is not
very strong - it's easily spoofed.

--

Tauno Voipio
tauno voipio (at) iki fi

Thank you, Tauno. I will have a closer look at IPtables. I do realize
that MAC numbers can be edited in software, but, along with other
controls we'll be using (physical as well as logical), we think we can
put together a reasonably tight defense.

Regards,
TL




On Wed, 26 Oct 2005 17:11:16 GMT, Tauno Voipio
<(E-Mail Removed)> wrote:
>
>The recent versions of iptables can do filtering
>based on the MAC addresses. It should not be
>very difficult to write the rules to allow only
>the desired MAC addresses.
>
>Please understand that a MAC-based filter is not
>very strong - it's easily spoofed.

T. Little wrote:
> Thank you, Tauno.

Thanks - positive feedback keeps the
response engine running.

--

Tauno Voipio
tauno voipio (at) iki fi

In the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed)>, T. Little wrote:

>Does anyone know of a WIRED router and/or firewall, Linux-based or
>otherwise, that can do MAC filtering without using DHCP?

The capability is built into netfilter (iptables).

>My situation is that I have cash ATMs on a dedicated network, and I
>have to route their traffic to a controller on our primary LAN. What I
>need to do is assign a static IP address to each ATM and link it to a
>MAC address, perhaps in a firewall rule, so that a foreign device
>can't attach to our ATM network and route into our LAN.

After first wondering WHY THE F*CK IS ANYTHING ALLOWED ACCESS TO THE WIRE,
there are a number of possible solutions - in addition to the netfilter
MAC filter. You could use static ARP - meaning you have a file called
/etc/ethers in the legit hosts, and you have _disabled_ ARP with the
ifconfig command. Depending on your network topology, you can also use
a 'managed switch' to connect the various parts of the LAN, and only
allow traffic from specified MAC addresses to specified nodes on the LAN.

By the way - are you sure that a rogue host being able to send packets
on your wire is your biggest problem? Lacking additional details, I'd
be worried about packet sniffers as well.

>I know that MAC filtering alone isn't foolproof, but we'd like to be able
>to do this as part of our security strategy.

Yes - if someone has physical access to the LAN cabling, they can easily
determine the addresses for each node - when one goes down or if they
can somehow physically disconnect a node, there isn't much preventing
them from using '/sbin/ifconfig' to set the hardware address of a rogue
box - which is why the network should be physically secured.

>I have no trouble finding little wireless access points that can
>restrict MACs,

While current art can make a wireless access reasonably secure, I'm
an old sys-admin and see no need to expose my information over a setup
that is broadcasting the information for all to hear unless everything
is encrypted with a very robust algorithm.

>but I have not yet found a robust router/firewall that can specify which
>MAC addresses on the public side of the router can come across to the
>trusted side.

I can understand that - the MAC address offers virtually no security
because it can so easily be spoofed - have you tried a google search for
"macchanger"? Version 1.5.0 was released last year.

Old guy

Howdy, Old Guy. The hair I've got is silver. The viewpoint of any
long-timer is appreciated, especially where *nix is concerned. Heck,
most of my experience until a few years ago was with serial stuff . .
.. .

Here are a few more details on our proposed setup:

We're doing 3DES between the ATMs and the controller. The ATMs are
behind cable modems, but the cable modems do not pass traffic to the
Internet - - the traffic goes to our cable provider's NOC and gets
VLAN'd to our DP center. The cable provider calls this "TLS," and it's
fast and cheap compared to using, say, individual 56k frames or ISDN..
We set all IP parameters on the TLS segment and provide the routing
into our LAN. But my concern has to do with someone figuring out our
topology and getting busy with their own laptop. I figure that anyone
getting access to our cable will have to move fast - - we'll be paged
as soon as a connection is physically broken, and we have cameras on
both sides (public and service sides) of the ATM units. I'd just like
to buy us as much time as possible for that day when someone tries to
break in. The ATMs themselves are encased in concrete and steel, but I
don't even trust the Diebold and Brinks guys who service the ATM
units. I want to be ready in case someone with legitimate physical
access gets tempted to do something naughty. Of course, in a red-alert
case, we can pull the plug on the entire ATM network, but the CEO
doesn't like to hear about ATM downtime.

I know that the ATM service guys have the IP and MAC information for
our units already. I guess the question is what we can do to thwart
someone who has both physical access and fundamental network
information. Unfortunately, the controller and ATMs - - amazingly - -
are Windows based. They used to be OS/2 talking via serial lines to
an RS-6000 running AIX. And it was rock solid, I might add.

I'll have a look at your static ARP suggestion, though I'm not sure
about implementation with Windows hosts. Tomorrow, I plan to play with
IPCOP a bit. The MAC criteria is seeming not so important as I'd
thought.


TL


On Wed, 26 Oct 2005 19:19:56 -0500, (E-Mail Removed)
(Moe Trin) wrote:

>In the Usenet newsgroup comp.os.linux.networking, in article
><(E-Mail Removed)>, T. Little wrote:
>
>>Does anyone know of a WIRED router and/or firewall, Linux-based or
>>otherwise, that can do MAC filtering without using DHCP?
>
>The capability is built into netfilter (iptables).
>
>>My situation is that I have cash ATMs on a dedicated network, and I
>>have to route their traffic to a controller on our primary LAN. What I
>>need to do is assign a static IP address to each ATM and link it to a
>>MAC address, perhaps in a firewall rule, so that a foreign device
>>can't attach to our ATM network and route into our LAN.
>
>After first wondering WHY THE F*CK IS ANYTHING ALLOWED ACCESS TO THE WIRE,
>there are a number of possible solutions - in addition to the netfilter
>MAC filter. You could use static ARP - meaning you have a file called
>/etc/ethers in the legit hosts, and you have _disabled_ ARP with the
>ifconfig command. Depending on your network topology, you can also use
>a 'managed switch' to connect the various parts of the LAN, and only
>allow traffic from specified MAC addresses to specified nodes on the LAN.
>
>By the way - are you sure that a rogue host being able to send packets
>on your wire is your biggest problem? Lacking additional details, I'd
>be worried about packet sniffers as well.
>
>>I know that MAC filtering alone isn't foolproof, but we'd like to be able
>>to do this as part of our security strategy.
>
>Yes - if someone has physical access to the LAN cabling, they can easily
>determine the addresses for each node - when one goes down or if they
>can somehow physically disconnect a node, there isn't much preventing
>them from using '/sbin/ifconfig' to set the hardware address of a rogue
>box - which is why the network should be physically secured.
>
>>I have no trouble finding little wireless access points that can
>>restrict MACs,
>
>While current art can make a wireless access reasonably secure, I'm
>an old sys-admin and see no need to expose my information over a setup
>that is broadcasting the information for all to hear unless everything
>is encrypted with a very robust algorithm.
>
>>but I have not yet found a robust router/firewall that can specify which
>>MAC addresses on the public side of the router can come across to the
>>trusted side.
>
>I can understand that - the MAC address offers virtually no security
>because it can so easily be spoofed - have you tried a google search for
>"macchanger"? Version 1.5.0 was released last year.
>
> Old guy

T. Little wrote:

>
>
> Does anyone know of a WIRED router and/or firewall, Linux-based or
> otherwise, that can do MAC filtering without using DHCP? IPCOP comes
> close from what I see looking at the documentation, but I don't want
> to use DHCP to accomplish this, and I need to filter traffic coming
> from the public side, not the private.

MAC filtering is rarely done on the public side as it is only useful to the
next upstream router (usually within your ISP)

> My situation is that I have cash ATMs on a dedicated network, and I
> have to route their traffic to a controller on our primary LAN. What I
> need to do is assign a static IP address to each ATM and link it to a
> MAC address, perhaps in a firewall rule, so that a foreign device
> can't attach to our ATM network and route into our LAN. I know that
> MAC filtering alone isn't foolproof, but we'd like to be able to do
> this as part of our security strategy.
>
> I have no trouble finding little wireless access points that can
> restrict MACs, but I have not yet found a robust router/firewall that
> can specify which MAC addresses on the public side of the router can
> come across to the trusted side.
>
> Any help is much appreciated.
>
>
>
> TL

T. Little wrote:

> What I
> need to do is assign a static IP address to each ATM and link it to a
> MAC address, perhaps in a firewall rule, so that a foreign device
> can't attach to our ATM network and route into our LAN. I know that
> MAC filtering alone isn't foolproof, but we'd like to be able to do
> this as part of our security strategy.

It won't do anything for that situation. A MAC address is discarded, when
the packet passes through a router. The only MAC you'd see, from the
outside world, is that belonging to the ISPs router.

In the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed)>, T. Little wrote:

>We're doing 3DES between the ATMs and the controller.

Ah, OK - you have clue. You might not believe some of the requests that
get posted to Usenet.

>The ATMs are behind cable modems, but the cable modems do not pass
>traffic to the Internet - - the traffic goes to our cable provider's NOC
>and gets VLAN'd to our DP center. The cable provider calls this "TLS,"
>and it's fast and cheap compared to using, say, individual 56k frames or
ISDN..

That's 802.1Q - something similar to protocol 97 (0x61), a.k.a.
Ethernet-within-IP Encapsulation RFC3378.

3378 EtherIP: Tunneling Ethernet Frames in IP Datagrams. R. Housley,
S. Hollenbeck. September 2002. (Format: TXT=18803 bytes) (Status:
INFORMATIONAL)

>But my concern has to do with someone figuring out our topology and
>getting busy with their own laptop.

They're not going to be able to impersonate the ATM, because they won't
have the 3DES key - so that's out. Being able to send datagrams to your
system? To what end? Denial of Service? One presumes that the only
connection you'd accept from (call it) the ATM network is ATM stuff
which would be protected by the 3DES. Or do the ATM machines like to
surf pr0n in between customers ;-)

>I figure that anyone getting access to our cable will have to move fast
>- - we'll be paged as soon as a connection is physically broken, and we
>have cameras on both sides (public and service sides) of the ATM units.
>I'd just like to buy us as much time as possible for that day when someone
>tries to break in.

I see where you are coming from - but I don't think this is the right
mechanism. Actually, what might even be simpler for you is arpwatch

[compton ~]$ apropos arpwatch
arpsnmp [arpwatch] (8) - keep track of ethernet/ip address pairings
[compton ~]$

You don't mention a Linux distribution other than IPCOP, but arpwatch is
often included in regular Linux distributions.

181922 May 20 18:25 arpwatch-2.1a13-12.i386.rpm

That's Fedora Core 4. We do something very similar, monitoring the ARP
caches of routers, servers and the network switches. Company policy does
not permit visiting computers. Should one get in, our adaptation of this
program causes pop-up messages on select computers in the NOC and Security.
This also includes (thanks to the network switches) an indication of which
network drop is involved. This brings the Thundering Herd Of People Who Do
Not Smile - often before the intruder can finish booting.

>The ATMs themselves are encased in concrete and steel, but I don't even
>trust the Diebold and Brinks guys who service the ATM units.

I dunno about Brinks (they're Brinks problem - and the bonding company),
but I don't know that many people overly thrilled by Diebold. In your
Copious Free Time(tm), do a search for the word 'Diebold' in the Usenet
news group 'comp.risks' which is a mirror of the "ACM FORUM ON RISKS TO
THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS".

>I know that the ATM service guys have the IP and MAC information for
>our units already. I guess the question is what we can do to thwart
>someone who has both physical access and fundamental network
>information.

I'm not sure you can do that much using IP or MAC addresses. Both can be
spoofed with exceptional ease. A _MINOR_ possibility would be to quietly
tweak the network parameters in the TCP stack, (example, changing TTL, or
certain flags) and then monitoring this with a passive O/S fingerprinting
tool like p0f (http://lcamtuf.coredump.cx/p0f.shtml), but the additional
security would likely be minimal. It's more a "Security by Obscurity"
feature than anything else.

>Unfortunately, the controller and ATMs - - amazingly - - are Windows based.

Well aware of it - again, see that 'comp.risks' newsgroup.

>They used to be OS/2 talking via serial lines to an RS-6000 running AIX.
>And it was rock solid, I might add.

Yeah, I switched banks when my former bank "upgraded".

>I'll have a look at your static ARP suggestion, though I'm not sure
>about implementation with Windows hosts.

As above - it may not be relevant any more.

>Tomorrow, I plan to play with IPCOP a bit. The MAC criteria is seeming
>not so important as I'd thought.

IPCOP is a user friendly front end for configuring the netfilter code in
a Linux kernel. As such, it does things that the application author
thought would be useful, and doesn't do what he didn't think about, or
didn't include in his interface.

Old guy