Bugtraq mailing list archives
Re: Infosec.19990305.macof.a
From: glen.turner () ADELAIDE EDU AU (Glen Turner)
Date: Fri, 7 May 1999 13:29:33 +0930
ian.vitek () INFOSEC SE wrote:
Problem: Due to limitation with ARP/MAC-tables; switches could start sending packages to all ports, other network devices could hang, crash or reboot if they receive lots of MAC-addresses.
This problem is well-known. We see it occassionally. The bridge designer faces two choices: 1. To flood packets when the filtering database fills. Thus the bridge can cope with larger bridged networks than it was originally designed for. 2. To refuse service to addresses not already in the filtering database when the database fills. IEEE 802.1d isn't much use in deciding which option is best. Fixes are to activate "port security", which deactivates a port if its MAC address changes. This limits the DoS to one machine, which may still be worthwhile if the machine runs an attractive service. It is costly to administer in a large network. Some switches have a "trap on port MAC address change" option. The port running the exploit will generate a huge number of traps, and suitable administrative action taken. Networks with trees of switches will see multiple traps as MAC addresses changes, so this option is usually only enabled on switches at the edge. However, we run this option on all our switches and just deal with the extra traps. Switch vendors do need to improve security. Most vendors' plans involve obtaining user authentication before granting significant link-level access. At present, these plans are somewhat propietary. Network design is also important. We place all public access areas (computing labs, etc) on their own IP subnets. These areas usually require significant IP filtering in any case. The effect is to limit link-level DoS attacks initiated from a public keyboard to a single physical area. -- Glen Turner Network Specialist Tel: (08) 8303 3936 Information Technology Services Fax: (08) 8303 4400 The University of Adelaide 5005 Email: glen.turner () adelaide edu au South Australia
Current thread:
- Infosec.19990305.macof.a ian.vitek () INFOSEC SE (May 05)
- Re: Infosec.19990305.macof.a Emil Isberg (May 06)
- Re: Infosec.19990305.macof.a David Maxwell (May 06)
- <Possible follow-ups>
- Re: Infosec.19990305.macof.a Glen Turner (May 06)
- Re: Infosec.19990305.macof.a Alan Cox (May 07)
- Re: Infosec.19990305.macof.a Greg A. Woods (May 08)
- Re: Infosec.19990305.macof.a Alan Cox (May 09)
- OpenLinux 2.2: LISA install leaves root access without password Andrew McRory (May 08)
- Re: [linux-security] OpenLinux 2.2: LISA install leaves root Ralf Flaxa (May 09)
- SunOS 5.7 rmmount, no nosuid. Jonas Stahre (May 10)
- Re: SunOS 5.7 rmmount, no nosuid. C.J. Oster (May 10)
- nidsbench announcement Dug Song (May 13)
- Re: Infosec.19990305.macof.a Alan Cox (May 07)
- Adminisrivia Aleph One (May 10)
- [BIND-BUGS #18] Non-delegated master domains Ian Carr-de Avelon (May 10)