Firewall Wizards mailing list archives
RE: RE: Sniffing out a firewall problem
From: "Anton" <anton () toronto com>
Date: Sun, 11 Nov 2001 14:25:17 -0500
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 dont 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 dont 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
Current thread:
- RE: Sniffing out a firewall problem Thomas Ray (Nov 03)
- RE: Sniffing out a firewall problem Alan Young (Nov 03)
- Re: RE: Sniffing out a firewall problem Peter Lukas (Nov 03)
- Re: RE: Sniffing out a firewall problem Ryan Russell (Nov 04)
- RE: RE: Sniffing out a firewall problem Robert McMahon (Nov 05)
- RE: RE: Sniffing out a firewall problem Chiman (Nov 06)
- RE: RE: Sniffing out a firewall problem Anton (Nov 13)
- Re: RE: Sniffing out a firewall problem Pierre-Yves BONNETAIN (Nov 09)
- Re: RE: Sniffing out a firewall problem Peter Lukas (Nov 03)
- Re: RE: Sniffing out a firewall problem Peter Lukas (Nov 05)
- RE: Sniffing out a firewall -SNORT blew up registrty Chiman (Nov 06)
- RE: Sniffing out a firewall problem Alan Young (Nov 03)
- <Possible follow-ups>
- Re: RE: Sniffing out a firewall problem TDyson (Nov 03)
- Re: RE: Sniffing out a firewall problem Gregory Hicks (Nov 05)
- Re: RE: Sniffing out a firewall problem Barney Wolff (Nov 08)
- RE: RE: Sniffing out a firewall problem Carl Friedberg (Nov 09)
- Re: RE: Sniffing out a firewall problem Stephane Nasdrovisky (Nov 09)
- RE: RE: Sniffing out a firewall problem M. Dodge Mumford (Nov 09)