[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
[linux-security] Re: A switch? A router? What am I looking for??
- From: Woody Weaver <woody wiltelnsi com>
- To: Christopher Hicks <chicks chicks net>
- Cc: security kokoro com, firewalls lists gnac net, linux-security redhat com
- Subject: [linux-security] Re: A switch? A router? What am I looking for??
- Date: Tue, 30 Jun 1998 09:32:14 -0700
At 02:00 AM 6/30/98 -0400, Christopher Hicks wrote:
>On Mon, 29 Jun 1998, Woody Weaver wrote:
>> Put in a switch to improve bandwidth, not out of a sense of security.
>
>Security in depth is good. A switch's primary purpose is and should be
>improved bandwidth. But it also helps security. MAC floods can be
>detected. That's enough to dissuade some threats. The attraction of
>packet sniffing attacks is the difficulty of detection.
I agree with Chris' statement, but I agree with mine as well.
>From the original authors comment, I deduced (incorrectly perhaps) that he
was trying to find out what a switch was, and if it would be a security
device. For a novice, imho, a switch is only a collision-domain
manipulator, *not* a secure device. In particular, I would be concerned
that a novice would drop a switch in place and believe that he was safe
against passive sniffing attacks. Far better is to make as a criterion of
the security policy which machines are able to see traffic from other
machines, and choose an appropriate appliance or procedure to enforce that
policy.
>But the principle of security in depth is the real issue I'm trying to
>address. It is often missed. Just because a switch or a firewall or a
>lock on a file cabinet isn't perfect does not mean that it shouldn't be
>part of a complete security plan. People lock their office door then
>leave root logged in. People buy a firewall and then run their systems
>without patches or proper passwords. Bad. Bad. There are few either-or
>choices in security that shouldn't be answered "both".
Please note the first sentence does not correspond to the examples listed.
All the examples listed correspond to violations of (an implied) security
policy, *not* missing security in depth. I *like* security in depth. When
I have the luxury, I have one vendors' firewall on the perimeter, another
vendor's firewall for the interior, and specify file encryptors and
end-to-end encryption on administrative traffic. Belts and suspenders are
good things, when money/convenience is outweighed by the risk/value
computation.
What I'd like to point out (that is often missed) is that security
implementations must follow from the security policy -- not vice versa --
and that screwdrivers are not chisels even though they share some features.
If the security policy states that machine A is not to see machine B's
traffic, then the answer is not "lets buy a switch" -- its a little deeper
than that, and it might involve buying a secure switch, but then it also
involves a good deal of thought about configuration of the switch, and so on.
>
></chris>
--woody
--
Robert Wooddell Weaver email: woody weaver wiltelnsi com
Network Engineer voice: 510.358.3972
Williams Communication Solutions pager: 510.702.4334
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]