Re: Diversity as defense

2004-01-20 Thread sgorman1
Agreed, vendor lock in is a very big problem, what the economists would call increasing returns. Interestingly most of the research on the subjest finds that a vendor achieves lock in and a dominant market position not by being the most competitive product. Random historical accident,

Re: What's the best way to wiretap a network?

2004-01-20 Thread Eriks Rugelis
Sean Donelan wrote: Assuming lawful purposes, what is the best way to tap a network undetectable to the surveillance subject, not missing any relevant data, and not exposing the installer to undue risk? 'Best' rarely has a straight-forward answer. ;-) Lawful access is subject to many of the

Re: What's the best way to wiretap a network?

2004-01-20 Thread Scott McGrath
Scott C. McGrath On Tue, 20 Jan 2004, Eriks Rugelis wrote: Sean Donelan wrote: Assuming lawful purposes, what is the best way to tap a network undetectable to the surveillance subject, not missing any relevant data, and not exposing the installer to undue

Re: sniffer/promisc detector

2004-01-20 Thread Alexei Roudnev
Uhm, that would be wrong. This is simply security through obscurity. Yes, it is wrong for the _smart books_. But it works in real life. Of course, it should not be the last line of defense; but it works as a first line very effectively. If I rate safety as a number (10 is the best, 0 is the

Re: Diversity as defense

2004-01-20 Thread Alexei Roudnev
Correct. Microsoft's problem is not security alone, but monoculture. If we have all systems around Windows2003, we are exposed to risk of devastating virus attack. No matter, how secure this Windows2003 is. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL

RE: sniffer/promisc detector

2004-01-20 Thread Michel Py
Alexei Roudnev wrote: - turn off power - safety is 10. Secure system, is a dark system. I have to disagree on this one; there is WOL (Wake-up On Lan), the system can be lit remotely. - turn off power - safety is 9 - Unplug all cords - safety is 10 Michel.

Re: sniffer/promisc detector

2004-01-20 Thread haesu
PS. Sniffer... there are not any way to detect sniffer in the non-switched network, and there is not much use for sniffer in switched network, if this network is configured properly and is watched for the unusial events. depends on brand and model of switch $ portinstall

Re: What's the best way to wiretap a network?

2004-01-20 Thread William Allen Simpson
Eriks Rugelis wrote: On the other hand, if your environment consists of a large number (100's) of potential tapping points, then you will quickly determine that in-line taps have very poor scaling properties. a) They are not rack-dense b) They require external power warts

Re: What's the best way to wiretap a network?

2004-01-20 Thread Steven M. Bellovin
In message [EMAIL PROTECTED], William Allen Simpson writes: Eriks Rugelis wrote: On the other hand, if your environment consists of a large number (100's) of potential tapping points, then you will quickly determine that in-line taps have very poor scaling properties. a) They are

Nachi/Welchia Aftermath

2004-01-20 Thread Brent Van Dussen
Well folks, since the middle of August I've been tracking the spread and subsequent efforts by our community to stop the nachia/welchia infection that took down so many networks. Sadly, by my estimations, only about 20-30% of infected hosts were cleaned. After Jan 1, 2004 it appears that the

Re: Nachi/Welchia Aftermath

2004-01-20 Thread Scott Weeks
: What kind of effects did everyone see from this devastating worm and what : lessons did we learn for preventing network downtime in the future? Proper network design is a good thing... ;-) scott

Re: Nachi/Welchia Aftermath

2004-01-20 Thread Scott Weeks
: : What kind of effects did everyone see from this devastating worm and what : : lessons did we learn for preventing network downtime in the future? : : : Proper network design is a good thing... ;-) Before I get flamed, I should say that is for end-user networks, not the normal BANs (Big

Re: Nachi/Welchia Aftermath

2004-01-20 Thread haesu
lesson learned: stop using /makeshift/ layer3 switches (without naming vendor) to run L3 core -J On Tue, Jan 20, 2004 at 02:22:52PM -0800, Brent Van Dussen wrote: Well folks, since the middle of August I've been tracking the spread and subsequent efforts by our

Re: sniffer/promisc detector

2004-01-20 Thread Niels Bakker
* [EMAIL PROTECTED] (Dave Israel) [Tue 20 Jan 2004, 18:48 CET]: On 1/20/2004 at 09:18:07 -0800, Alexei Roudnev said: [..] - unpatched sshd on port 30013 - safety is 7 (higher) because no one automated script can find it, and no one manual scan find it in reality Actually, an automated script

Re: Nachi/Welchia Aftermath

2004-01-20 Thread Rubens Kuhl Jr.
Not all L3-switches are flow-based; prefix-based ones should do just fine. Can people add/correct this initial list ? Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A) Prefix-based: Foundry with JetCore modules, Cisco Catalyst 6500/7600 with Sup2(A), Sup3(A/BXL)

Re: Nachi/Welchia Aftermath

2004-01-20 Thread haesu
yes in concur.. prefix based ones (like FIB) are fine. unfortunately some models from some vendors (tisk tisk) who use slow process path to reprogram the CAM per flow can be quite painful during situations like random dest. dos attacks and worms.. add the

Re: Nachi/Welchia Aftermath

2004-01-20 Thread Donovan Hill
On Tuesday 20 January 2004 04:16 pm, Rubens Kuhl Jr. wrote: Not all L3-switches are flow-based; prefix-based ones should do just fine. Can people add/correct this initial list ? Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A) Prefix-based: Foundry with JetCore

Re: Nachi/Welchia Aftermath

2004-01-20 Thread Rubens Kuhl Jr.
Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A) Prefix-based: Foundry with JetCore modules, Cisco Catalyst 6500/7600 with Sup2(A), Sup3(A/BXL) Where do the Extreme and Juniper fit into this? Private and public answers to my question indicate that both Summit

Re: sniffer/promisc detector

2004-01-20 Thread Steven M. Bellovin
In message [EMAIL PROTECTED], Alexei Roudnev writes: Uhm, that would be wrong. This is simply security through obscurity. Yes, it is wrong for the _smart books_. But it works in real life. Of course, it should not be the last line of defense; but it works as a first line very effectively.

Re: Nachi/Welchia Aftermath

2004-01-20 Thread Stephen J. Wilcox
On Tue, 20 Jan 2004, Rubens Kuhl Jr. wrote: Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A) Prefix-based: Foundry with JetCore modules, Cisco Catalyst 6500/7600 with Sup2(A), Sup3(A/BXL) Where do the Extreme and Juniper fit into this? Private and

Re: Nachi/Welchia Aftermath

2004-01-20 Thread Richard A Steenbergen
On Tue, Jan 20, 2004 at 10:16:03PM -0200, Rubens Kuhl Jr. wrote: Not all L3-switches are flow-based; prefix-based ones should do just fine. Can people add/correct this initial list ? Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A) Prefix-based: Foundry with

Re: Nachi/Welchia Aftermath

2004-01-20 Thread Tom (UnitedLayer)
On Tue, 20 Jan 2004, Rubens Kuhl Jr. wrote: Not all L3-switches are flow-based; prefix-based ones should do just fine. Can people add/correct this initial list ? Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A) Prefix-based: Foundry with JetCore modules, Cisco

Re: Nachi/Welchia Aftermath

2004-01-20 Thread Paul Vixie
lesson learned: stop using /makeshift/ layer3 switches (without naming vendor) to run L3 core more generally... if you want routing, buy a router. i have a hybrid switer that i'm very happy with. at my house, that is. (the idea of using one in commerce or production gives me cold