Re: [OT] 2 subnets + 1 switch = ARP vulnerability?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2006-05-23 at 19:39 -0500, Jay Cliburn wrote:
> Recently I advised a fellow at fedoraforum not to connect the orange and
> green interfaces of an IPcop machine to the same switch.  I gathered he
> wanted to do that in order to save money by not buying a second switch,
> primarily.  To be honest, I didn't think it would work, but apparently
> it did.  Well, at least he says it did, and I have no reason to
> disbelieve him.  So I learned something.
> 
> He connected his green and orange interfaces, each with a different
> subnet address of course, to a switch, then connected some FC5 clients
> to the same switch, configuring some of them on the green subnet and
> pointing to the green gateway, and the rest on orange network pointing
> to the orange gateway.
> 
> Now IPcop and its ilk, as I understand them, base much of their security
> strength on maintaining separation among red, green, and orange
> networks.  Orange is for a DMZ, green is for a protected LAN, and red
> faces the Internet.  I'm not a network or security guru, but am I wrong
> in thinking that the fellow's green network is now highly vulnerable to
> ARP exploits from the orange side?  As far as layer 2 is concerned,
> everything is on the same network, right?  Are ARP exploits not in vogue
> anymore?  Are there other security risks in doing things this way?  Is
> it a pretty common and acceptable practice these days to connect
> multiple subnets through a single non-VLAN switch as a matter of
> convenience or economy?

I would NEVER use a non-VLAN switch for such a thing.  Even then,
depending on the codebase used in the switch, there can be ARP leakage.
I believe such a thing exploited a hole in Cisco's IOS last year
sometime.  It has bitten other manufacturers as well.

On top of that, placing everything on a single switch (VLANned or not)
allows a nefarious attack against the switch itself.  We have had some
fairly beefy switches (Extreme Summit 48s) brought to their knees by
internal ARP attacks.  Since the CPU was swamped, the VLAN didn't
protect much of anything.  Granted, this was more of a DOS attack and
fortunately, we're really good at the forensics necessary to track this
stuff down, but still everything on that switch was down and potentially
compromised.

As you say, it's false economy to put it all on a single switch
regardless of how mucho macho it is.  VLANs offer some segregation, but
the best way is to use totally separate pieces of hardware.  We have a
saying, "hardware's cheap...the traffic and data is priceless".

----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens@xxxxxxxxxxxxxxx -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-      Do you know how to save five drowning lawyers?  No?  GOOD!    -
----------------------------------------------------------------------

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux