From owner-freebsd-security  Fri Jan  5 10:48:14 2001
From owner-freebsd-security@FreeBSD.ORG  Fri Jan  5 10:48:11 2001
Return-Path: <owner-freebsd-security@FreeBSD.ORG>
Delivered-To: freebsd-security@freebsd.org
Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162])
	by hub.freebsd.org (Postfix) with SMTP id E99E537B402
	for <security@FreeBSD.ORG>; Fri,  5 Jan 2001 10:48:09 -0800 (PST)
Received: (qmail 63191 invoked by uid 1001); 5 Jan 2001 18:48:08 +0000 (GMT)
To: matrix@ipform.ru
Cc: questions@FreeBSD.ORG, security@FreeBSD.ORG
Subject: Re: Building a local network on switches (ANTISNIFFER measures)
From: sthaug@nethelp.no
In-Reply-To: Your message of "Fri, 5 Jan 2001 21:03:11 +0300"
References: <000b01c07741$c85272c0$0c00a8c0@ipform.ru>
X-Mailer: Mew version 1.05+ on Emacs 19.34.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Fri, 05 Jan 2001 19:48:08 +0100
Message-ID: <63189.978720488@verdi.nethelp.no>
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> Somebody said, that there is way to fool but floodding it with weird
> arpa entries and the switch will fall back into hub mode. I wonder if it
> is true for all hubs and if I can use non SNMP controllable hub.

Think about how a hub works (or for that matter a switch). It has a
MAC address table of a certain finite size. If you send packets with
a MAC address which is not in the address table, the packet must be
transmitted on all ports (except the one it arrived on).

MAC addresses are learned as packets are received. Thus in many cases
you can force transmission on all ports by flooding the hub or switch
with lots of fake MAC addresses, thus flushing the real MAC addresses
from the table.

(A switch may have a MAC address table per port - but the original
argument still holds.)

Steinar Haug, Nethelp consulting, sthaug@nethelp.no


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message