From owner-freebsd-net Tue Jan 4 10:20: 4 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.eclipse.net (mail.eclipse.net [207.207.192.13]) by hub.freebsd.org (Postfix) with ESMTP id B8E0114F3B for ; Tue, 4 Jan 2000 10:19:56 -0800 (PST) (envelope-from dand@eclipse.net) Received: from localhost (dand@localhost) by mail.eclipse.net (8.9.1a/8.9.1) with ESMTP id NAA08472 for ; Tue, 4 Jan 2000 13:19:54 -0500 (EST) Date: Tue, 4 Jan 2000 13:19:54 -0500 (EST) From: Dan Davis To: freebsd-net@FreeBSD.ORG Subject: Re: sniffing networks In-Reply-To: <200001041729.MAA16004@benge.graphics.cornell.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > >> OK: How do you perform a search for cards in promiscuous mode? > >> (Taking some expensive analyzer progs or some simple stuff under UN*X, > >> Linsux or NT?) > > > >Why would you want to search for network interfaces in promiscuous mode? > > Besides being a difficult operation to perform... (what if you don't > have a login on their system?) a clever sniffer can be quite > transparent. A now several years old book on network security suggests > building a secure network monitor by cutting the NIC's xmit lead. How > are you going to search for something like this?? > > > >Stick the users on switched ports so they can't sniff other users packets > >and be done with it. > > According to a friend who has done some network monitoring tests this > is not as perfect a solution as it sounds. He has observed packets > coming out ports other than the one where the destination system is > connected. Still, everyone agrees it's far better than the old > dozens-of-machines-in-a-single-collision-domain method. > > -Mitch > Perhaps that's because the switch uses a fixed-size table for matching which destinations should be routed to each ports that is smaller than the number of destinations/ports actually in use. Since the switch needs to operate so quickly, is it probable that such a switching table is actually in silicon or programmed into an FPGA? That would make sense of why the table would be so small; it reminds me of the limited way multicast addresses are handled by a typical NIC. --------------------------------------------------------------------- Dan Davis | Excerpt from my latest project: Software Engineer | 0000100010111000001010010001 ECCS, Inc. | 1000101011110110001110101000 dand@eclipse.net | "That's the philosophical equivalent of http://www.eccs.com | Folger's crystals!" - Dan --------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message