3 ms·
At some point I'm hoping the full technical story about how the attack morphed from our infrastructure to Internet infrastructure can be told. See poorly confi
by TranceMan 14y ago
At some point I'm hoping the full technical story about how the attack morphed from our infrastructure to Internet infrastructure can be told.
See poorly configured DNS servers and ISP's failing to configure their networks properly - so traffic with a source address which is not part of your allocated IP block is not allowed to leave your network. It is not that hard!
The Internet Infrastructure is working as designed.
Ref:
http://en.wikipedia.org/wiki/Ingress_filtering http://en.wikipedia.org/wiki/Ingress_filtering
http://tools.ietf.org/html/bcp38 http://tools.ietf.org/html/bcp38
Also:
If you run a DNS server - it is your responsibility to maintain and protect it so that it cannot be used to attack others, and by doing that you are helping the 'Internet infrastructure' remain intact as designed. By not doing this you are helping the 'attackers'
- jaytaylor 14y ago> See poorly configured DNS servers and ISP's failing to configure their networks properly - so traffic with a source address which is not part of your allocated IP block is not allowed to leave your network. It is not that hard! It may not be that hard to set things up this way, but very few ISPs configure their network with this restriction.
- hhw 14y agoIngress Filtering is a rather vague concept. The actual application of blocking spoofed traffic is known as unicast reverse path forwarding. http://en.wikipedia.org/wiki/Reverse_path_forwarding http://en.wikipedia.org/wiki/Reverse_path_forwarding http://tools.ietf.org/html/rfc3704 http://tools.ietf.org/html/rfc3704
- TranceMan 14y agoThanks - that RFC seems to sum it up: rfc3704 BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network,