RE: RE: Sniffing out a firewall problem

["Anton" <anton () toronto com>]

Its not unusual that the thread shift away from the original
question - which was somewhat concerned with security - to another
area such as performance, price and so on.  But hang on ...

Some assertions and implications are not quite on track, not
least of all on the security side.

A switch is NOT a router.
A switch is NOT a firewall.
A switch is NOT a packet filter.
Many switches have a backplane - a 'bus' that distributes the
packets to all the ports.  It is then up to the way the ports
have been configured to allow or deny egress.  Default behaviour
is usually for the switch to behave like a hub.  In the URLs
below you will find that CISCO explicate recommend turning off
any unused ports.

When Chiman said
        > 1.) In a switched environment, remember that a device on a single port
        >     won't see broadcast packets on another port.
he wasn't 100% correct.  He assumed a lot of things.  The "port" does
see everything on backplane, which is the ultimate broadcast domain
for all the VLANs.  The port processor determines which packets get seen
at the "RJ45 socket".

The difference is important.  A failure or misprogramming of a port
processor makes everything on the backplane visible.  It also makes
them a target for attacks.  How the switches are purchased and their
physical layout now matters.  [The firewall should have its own "front
porch" and 'back porch" switches.  A moments thought shows they may as
well be hubs because we're not loosing anything by using the simpler
device in these settings.  Simplicity is good, complexity is bad.]

So what we have here is a situation where the default settings
are insecure.  Personally I don't like this.  I'm an advocate of
the 'default to secure' approach.  I've learnt that many security
errors arise not from poor equipment, but from human errors, such
as oversights.  I'm no great fan of VLANs either for the same reason.
Implicit in them is the following two situations:

  a) Why not have a separate "hub" (or switch) per "VLAN"?
     Yes, I've seen the arguments about deferred design and
     flexibility, but in the end they just boil down to lack
     of one of i) adequate specifications; ii) adequate analysis;
     iii) adequate planning; iv)  knowledge of set theory or
     v) self discipline.  Not only that, but you need to know
     about how ARP and broadcast domains work and interact.

  b) False 'economy of scale'.  I've seen sites buy X-million port
     switches as an early purchase.  Its the old story of buying the
     hardware first, before the specification or the software.  The
     last one I saw actually led to problems because the large, high
        risk government system ...

        -- What do I mean by high risk?
                Tech Republic have a "Project Risk Factors" checklist at

http://www.techrepublic.com/article.jhtml?src=search&id=r00720010629rec01
.htm
           On that list add TWO more columns to the right and tick
           off there!

                            ... used a large switch as a hub
     and ended up in a severe problem when the infrastructure, the
     monitoring and the various business verticals, as well as the
     firewalls and storage networks had to be converted from the
     flat address space to various subnets.  Running both the outside
     and the inside of the firewall, as well as the DMZ and the
     back-end (?tier 3?) database machines though the same switch
     was really too high a risk situation.  An additional $500 would
     have allowed the firewall the DMZ and the back end each to have
     their own hub.  That represents less than 20% of the cost of
     the meeting at which it was discussed and less than 0.1% of the
     time for the 'network engineers' to try and figure out the new
     VLANs and subnetting.  No wonder the project over-ran.

Switches, just like Abe Lincoln (or was it George Washington) said
about fire, are great tools but terrible masters.

Another security expert whose initials appear in discussions here
very often pointed out that if all the components are used properly
and configured properly, there would be a lot fewer problems.  But
the reality isn't like that. Errors and omission happen.  This is
why we have 'defence in depth' and 'separation of duties' as key
principles of security.  Big switches, such as that one I mentioned
in the government project, and expecting switches to act as security
devices, are in clear violation of these principles.

Cisco have some very good material as part of their SAFE series of
white papers.  They make it very clear that a switch is NOT a security
device, should not be used as one and cannot be relied on to enforce
any security policy.

http://www.cisco.com/warp/public/cc/so/cuso/epso/sqfr/safes_wp.htm
http://www.cisco.com/warp/public/cc/so/cuso/epso/sqfr/safe_wp.htm
Quote:
        Switches Are Targets
        Like routers, switches (both Layer 2 and Layer 3) have their
        own set of security considerations. Unlike routers, not as
        much public information is available about the security risks
        in switches and what can be done to mitigate those risks.


Expecting switches to offer any form of security breed false confidence
in your security stance, which is a dangerous situation.

Ask yourself, does out corporate security policy make it clear that
switches can and should be used as security devices and give me
guidelines
as to how to do this?  Does any vendor make it clear that switches are
designed as a security mechanism and offer planning and support for
using them as such?

Maybe one day we will see "FW-1 on a chip" chips on every port of a
switch, but it will still need a policy to define what's going on
and to be correctly programmed.  Until then, don't bank on switches
for security.


Now let me say a quick word about performance ...

My experience with switches in a large heterogeneous environment is that
there is more performance loss from incorrect planning and configuration,
most noticeably from the 10/100 negotiation, than from 'collisions'.
This makes me somewhat suspicious about the benefits of switches in
the first place.


Conclusions:
   Switches are not security devices.  Don't rely on them as such.
   There are many things that can affect performance.

Book Recommendation:
        "Designing Addressing Architectures for Routing and Switching"
        Howard C Berkowitcz
        ISBN 1-57870-059-0

     If you're going to design or debug a network that uses switches
     you need to read this book.


-------------------------------------------------------------------------
----------
Anton J Aylward, CISSP  | "A lot of managers talk about ‘thinking out of
the box,’
System Integrity                | but they don’t understand the communication process
by
InfoSec Consulting              | which that happens. You do not think out of the box
Voice: (416) 497-0201           | by commanding the box! You think out of the
box precisely
mailto:aja () si on ca          | by bringing ideas together that don’t allow
dominant
http://www.isc2.org             | ideas to continue to dominate."
http://sss.issa-intl.org        |    - Stan Deetz






> -----Original Message-----
> From: Chiman
> Sent: Monday, November 05, 2001 5:58 PM
> To: Robert McMahon; Ryan Russell; Peter Lukas
> Cc: ayoung () veros com; firewall-wizards () nfr com
>
>
> Just a few points to consider in this, some will be obvious to a lot of
> folks.
>
> 1.) In a switched environment, remember that a device on a single port
>     won't see broadcast packets on another port.
>
> 2.) Someone mentioned looking at switch for colls, routers can also
> collect logs, on the "backbone",
> but be careful not to turn on too much logging, and killing the
> performance of the router.
>
> 3.) lastly remember that when snooping from a unix box you
> won't see errs or
> outflowing traffic that, *that* deivce
> (the one doing the snooping) is creating.  snoop(1M), at least, looks
> outward.
>
>
> -----Original Message-----
> From: firewall-wizards-admin () nfr com
> [mailto:firewall-wizards-admin () nfr com]On Behalf Of Robert McMahon
> Sent: Sunday, November 04, 2001 8:09 AM
> To: Ryan Russell; Peter Lukas
> Cc: ayoung () veros com; firewall-wizards () nfr com
> Subject: RE: [fw-wiz] RE: Sniffing out a firewall problem
>
>
> Related to this is that hubs (which by their nature share a collision
> domain), operate at only half-duplex.  I agree with Ryan, in that you
> have
> to compare with total traffic.  I use to raise a flag (and look at
> segmenting) when collision rate > 3-5 % in the days I use to run a hub
> architecture.  I recall an O'Reilly book on "performance tuning" (has a
> swordfish on cover), which is a great book that addresses
> these concerns.
>
> Switches are not subject to having "polite" converstations, therefore,
> can listen and reveive at same time - full duplex.
>
> /rm
>
> -----Original Message-----
> From: firewall-wizards-admin () nfr com
> [mailto:firewall-wizards-admin () nfr com]On Behalf Of Ryan Russell
> Sent: Saturday, November 03, 2001 8:39 PM
> To: Peter Lukas
> Cc: ayoung () veros com; firewall-wizards () nfr com
> Subject: Re: [fw-wiz] RE: Sniffing out a firewall problem
>
>
> On Sat, 3 Nov 2001, Peter Lukas wrote:
>
> > You'll get some pretty useful stats. Typically, any system with
Ierrs,
> > Oerrs or Collis will be experiencing a problem. Check caples, duplex
> > settings and of course, the card /switch port itself.
>
> Please be careful about making blanket statements about collisions
> automatically meaning problems.  On any connection that is supposed to
be
> half-duplex Ethernet-style, collisions are perfectly normal, and you
have
> to measure collisions against total traffic to even have a rudimentary
> problem measurement.
>
> Sorry, it's a pet peeve of mine.  When I used to be primarily a network
> engineer, I would have systems administrators come to me and report
that
> the system was reporting collisions, please fix the network.  I'd reply
> that it was running half-duplex.  <blank stare>
>
>                                       Ryan

_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards