This actually came up a few weeks ago - there's no way to filter outbound ICMP for "broadcast addresses", because what defines a broadcast address depends on the subnetting at the receiving end. For example, 10.1.1.119 may be a host on 10.1.1.0/24, or a broadcast on 10.1.1.112/29. "no ip directed-broadcast" drops all IP destined for the broadcast address _on an interface_, AFAIK. eric

Don't these answers answer a different question? Isn't the question how to filter *outbound* attacks, not inbound ones? Filtering the inbound ones is pretty easy on a Bay or anything with filters (drop packets bound for the broadcast addresses). Filtering outbound is another story, especially with CIDR. I would like to set up my routers to make sure I'm protecting as much of the 'net as possible from attempts by my customers to do evil. However, it's not clear to me how to do that. Does "no ip directed-broadcast" somehow filter the *outbound* attacks or just the inbound ones? -- Steve Hultquist, Chief Technology Officer HSAnet providing high-speed Internet access Boulder, Colorado mailto:ssh@HSAnet.net +1.303.581.0800 http://www.HSAnet.net/

On Fri, 13 Feb 1998, Steve Hultquist wrote: ==>Don't these answers answer a different question? Isn't the question how to ==>filter *outbound* attacks, not inbound ones? Filtering the inbound ones is ==>pretty easy on a Bay or anything with filters (drop packets bound for the ==>broadcast addresses). Filtering outbound is another story, especially with ==>CIDR. I would like to set up my routers to make sure I'm protecting as much ==>of the 'net as possible from attempts by my customers to do evil. However, ==>it's not clear to me how to do that. Does "no ip directed-broadcast" somehow ==>filter the *outbound* attacks or just the inbound ones? "no ip directed-broadcast" keeps you from being one of the intermediaries in the attack (traffic multiplier). It prevents a perpetrator from being able to multiply his traffic toward the victim, which is what makes smurf so dangerous. Outbound spoof filtering fixes more than just the smurf attack, and is what everyone *should* be doing to protect against customers spoofing. For now, you can place outbound ACL's on your interfaces. Some folks have reported that functionality is currently being tested for a unicast RPF check for Cisco IOS. This feature will (on a per interface basis) allow you to specify that packets coming in on an interface must follow that interface to get back to the host. Note that this feature will not work everywhere (multihomed/first-exit environments), but will provide protection against spoofing. /cah