During an in progress attack, you probably have to take extreme measures, Do you remember - it's not attack against you or attack by some of your customer's networks used as amplifier, but the attack initiated from your own network. You never note such thing withouth some permanent measurement.
It's why we saw this 100% helpless against the SMURF's.
but they shouldn't be generally applied. No one wants to lose addresses that *might* be a broadcast address in some possible netmask. /24 is maybe common, but is not the only netmask. And the people who don't use it won't want you to break their customers networks.
--Dean
At 2:51 PM -0400 4/18/98, Alex P. Rudnev wrote:
I am talking about boths blocking exterior smurfers from usage your networks as amplifier, and blocking your smurfers from sending such packets by your network. Second task allow you to cutch any smurfer in your own network in a 5 minutes.
Just now the only thing big ISP can do in case of SMURF is to block ECHO_REPLY packets to some attacked networks; it results from preventing any PING tests from this networks. Why don't sacrify some addresses (*.255, really) from be pinged at all, but save your from be the source or amplifier of the SMURF?
And then, if you should not block by 'log' such packets you'll have the log records about your own smurfers withouth loosing any ICMP capabilities at all.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)