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

From: T. Little (tl_at_nospam.net)
Date: 10/27/05 

Date: Wed, 26 Oct 2005 21:50:06 -0400

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, ibuprofin@painkiller.example.tld
(Moe Trin) wrote:

>In the Usenet newsgroup comp.os.linux.networking, in article
><l71vl1dev0tdkdok0tvarscqg9pql7h852@4ax.com>, 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

Relevant Pages

  • Re: Using a MAC in SBS Network
    ... MAC's don't like .local so .lan or .office is preferred. ... There are workarounds but if the box is not in production yet a flatten and reinstall might be good. ... > Does anyone have any advice for adding a MAC to an SBS Network? ...
    (microsoft.public.windows.server.sbs)
  • Re: cant connect new iMac
    ... When trying to set up the wireless ... network, the mac asks for a password. ... of the other computers on my LAN. ... I thought the Mac was supposed to be so easy to set up. ...
    (comp.sys.mac.system)
  • Re: networking XP pro and Mac for LAN play
    ... I've been able to network a couple of Macs together on a LAN to play ... I want to be able to network a PC using XP Pro and a Mac using OS ...
    (microsoft.public.windowsxp.games)
  • Re: Virtual PC and MAC address
    ... >So when I configure VPC to access the LAN, the MAC address is different ... >The network security at the client site only allow the OS X MAC address ...
    (microsoft.public.mac.virtualpc)
  • Re: MAC Filtering from Public to Trusted Side of Router???
    ... In the Usenet newsgroup comp.os.linux.networking, ... They're not going to be able to impersonate the ATM, ... what might even be simpler for you is arpwatch ... servers and the network switches. ...
    (comp.os.linux.networking)