Alex Bligh writes:
}Urm, 192.41.177.255 is the MAE-East LAN ?! Are you saying attacks are
}being mounted from here or people are attacking this LAN (not
}sure which is more worrying)
If I'm interpreting the code comments correctly, what this silly
"smurf" thing does is take a victim's IP address and generate
an ICMP_ECHO_REQUEST with the victim's IP address as the source
and an IP address from the array as the destination, and generate
lots of such packets (per each destination). That way, the victim
supposedly receives lots of ICMP_ECHO_REPLY packets - moreso than
from, say, the 28.8kbps dialup line from which the attack is taking
place. So basically this is just a simple DoS attack on bandwidth,
supposedly multiplied by the fact that it uses broadcast addresses
as the "proxy" attacker rather than unicast addresses.
However, I don't know about everyone else, but my routers respond to
such attempted directed-broadcast pings from their own unicast
address, so it really isn't multiplying anything.
And furthermore, if more people implemented source address filtering,
it would be less of a problem - if it really is a problem at all.
(And to answer the proverbial "how do I configure my router for that"
in advance, the answer is that, at least on my boxes, the not-allowing-
broadcast-pings-through-as-broadcasts-onto-the-target-media thing is on
by default. Source address filtering, however, is not.)
==>(And to answer the proverbial "how do I configure my router for that"
==>in advance, the answer is that, at least on my boxes, the not-allowing-
==>broadcast-pings-through-as-broadcasts-onto-the-target-media thing is on
==>by default. Source address filtering, however, is not.)
For Ciscos, "no ip directed-broadcast" on your interfaces will
prevent remote devices from sending directed broadcasts. No guarantees
about applications it might break, though.
==>For Ciscos, "no ip directed-broadcast" on your interfaces will
==>prevent remote devices from sending directed broadcasts. No guarantees
==>about applications it might break, though.
Clarification: This won't keep you from getting attacked. However, it
will keep your network from receiving the ECHO and therefore you won't
send ECHO_RESPONSE.
this does work as you'd expect (it prevents the cisco
from framing an IP broadcast packet into an ethernet broadcast
frame) BUT unfortunately it can break Windows networking, as well
as BOOTP/DHCP, depending on how you're set up.
but if you're not using one of the above (routed), then
by all means, 'no ip directed-broadcast' is an excellent way to go..
} Subject: disabling forwarding of directed broadcasts
% this does work as you'd expect (it prevents the cisco
% from framing an IP broadcast packet into an ethernet broadcast
% frame) BUT unfortunately it can break Windows networking, as well
% as BOOTP/DHCP, depending on how you're set up.
BOOTP/DHCP does NOT need directed broadcast forwarding enabled
to work properly. The "helper-address" function and the DHCP RELAY
code take care of BOOTP/DHCP traffic. Implementations of BOOTP/DHCP
don't require enabling forwarding of directed broadcast packets.
I've verified this experimentally in a previous life.
I also have (past) experience with a network running MS/NetBIOS cruft
through routers with forwarding of directed broadcasts DISABLED.
It worked fine.
If there is some corner case I've missed that requires forwarding
of directed broadcast packets, it would be useful for that specific
case to be enumerated _in detail, in public_.
==>If there is some corner case I've missed that requires forwarding
==>of directed broadcast packets, it would be useful for that specific
==>case to be enumerated _in detail, in public_.
There is one case... In the case of a remote server broadcasting into a
NetBIOS over IP environment where there's not a WINS server. (Yes, I know
it's remote, but I've used it before... =)