Brandon Ross wrote:
ftp://ftp.mindspring.net/users/bross/smurfsources
I find it slightly interesting that some private addresses were in the
list. There were some addresses in 10/8, 172.16/12, and 192.168/16.
Thus the source of the attack must have had some addresses in these
private network ranges reachable somehow, either internally in the
network the attacker(s) originate, or routes leaking onto the internet.
If the former, that would mean they had the capacity from that internal
network to carry the forged echo requests as well as those private
sourced echo replies.
I find it even more interesting how often I see 10.177.180.0/24 showing up
in smurf logs. Is there some equipment that defaults to this network,
some manual that uses this as an example, or is there a specific LAN that
gets hit on every major smurf attack? If it's really one network, you
would think we could find and provide clue to the operator(s).
Jeremiah
Clue should also be provided to the network operators who actually listen
to route advertisements for these networks. We use private address space
here for various things, some of which are even production, but you've
never once seen us leak the advertisements for them. And if we did make
the mistake of allowing them out, no one should ever listen to us about
them. Blocking traffic from reserved space at your borders and not
listening to route advertisements for reserved space should be common
practice. I would hope anyone clueful enough to be on this list would
know this already.