All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Taylor <gtaylor@riverviewtech.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Proxy ARP with a Coyote Point equalizer
Date: Thu, 31 May 2007 21:12:12 +0000	[thread overview]
Message-ID: <465F3A2C.8010503@riverviewtech.net> (raw)
In-Reply-To: <925A849792280C4E80C5461017A4B8A210B7F9@mail733.InfraSupportEtc.com>

On 05/31/07 13:41, Greg Scott wrote:
> I was thinking about what Grant said in his earlier reply about 
> bridging, and the more I think about it, the more I think Grant is 
> right.  I was watching tcpdump and some firewall accounting rules 
> when we tried this the other day and I saw all kinds of traffic that 
> had absolutely nothing to do with my network - and I was blocking it! 
> And I kept wondering, why was I blocking traffic that had a 
> destination IP address nowhere near me that I should not care about?

That's not good.

> Well, this is a co-location site, so an Ethernet connects this 
> network to the Internet, not a point to point serial or any kind of 
> WAN.  No doubt lots of other folks had their networks in racks in the 
> same room on the same extended Ethernet as my stuff.

Probably.  However I have to ask, why are so many different networks 
sharing one broadcast domain?  Or could it be that traffic was trying to 
be routed to the target subnet, but your system responded to the ARP for 
the IP of the target router???  I wonder...  Either way, this is not good.

This is also why I have seriously considered statically setting some IP 
to MAC address mappings in some more stringent environments.  If the 
upstream router knows the MAC address of my router, it will not need to 
ARP for it and thus I do not care if someone else claims to use my IP or 
not because the router will know which MAC address to use.

> But still, why did my box care about any of this traffic at all?  Why 
> would I specifically block it - why didn't the NIC in my box just 
> ignore it, the way most normal systems do in an Ethernet for traffic 
> it doesn't care about?  Well, duh!  It's proxy ARP.  Every time 
> anyone, anywhere on this Ethernet, sends out an ARP request and I see 
> it, I answer -  yup, here is my MAC Address and it belongs to the IP 
> Address you just asked about.  I don't care what IP Address, I answer 
> ARP requests for ALL IP Addresses!  I was essentially ARP spoofing the 
> whole world!  Well, at least the whole world on that Ethernet that 
> morning.

Oh NO!  That was not a good thing.  I wonder how many people you 
effected while doing that.

> Holy moley - based on that analysis, proxy ARP should be outlawed 
> from any co-location site, at least anything directly exposed to all 
> the public traffic.  For that few minutes, I'll bet I messed up 
> systems belonging to who-knows-how-many customers!  Fortunately, it 
> was in the middle of the night in my corner of the world.

Just because it is the middle of the night for you does not mean that it 
was not 9:30 in the morning for someone else who potentially has their 
box co-located there.  I think I would be tempted to contact your 
co-location provider and let them know what happened.  Consider if you 
were there administrator trying to figure out why a bunch of clients 
traffic did not route correctly for a short time and then repaired its 
self with out any explanation at all.  I know that I would want to know 
if such a thing happened in one of my data centers.  At the very least I 
would want to know that it was not a bug in the router but rather 
something that is a valid explanation for what happened.

As far as outlawing Proxy ARP, I don't know.  I do know that I see no 
reason to use Proxy ARP when bridging is sow much more powerful and 
safer.  Just think, you an do any and all IPTables (layer 3 and above) 
firewalling ON a layer 2 device.  You can be REALLY devious with this. 
If course there is also EBTables and ARPTables too.

> For Gypsy - it's not my own ARP cache I was messing with, it was 
> everyone else's ARP caches.

Gulp!

> Anyway, lesson learned.  Maybe this writeup will help somebody else 
> out there.  Definitely do bridging.

Here! HERE!



Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

      parent reply	other threads:[~2007-05-31 21:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-30 23:46 [LARTC] Proxy ARP with a Coyote Point equalizer Greg Scott
2007-05-31  0:19 ` Grant Taylor
2007-05-31  6:49 ` gypsy
2007-05-31 18:41 ` Greg Scott
2007-05-31 21:12 ` Grant Taylor [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=465F3A2C.8010503@riverviewtech.net \
    --to=gtaylor@riverviewtech.net \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.