Hello
This Mail [1] arrived just over the Full-Disclosure mailinglist [2], but should probably also be of interest to some people here.
[1] http://lists.grok.org.uk/pipermail/full-disclosure/2005-May/034342.html [2] https://lists.grok.org.uk/mailman/listinfo/full-disclosure
bye Fabian
-------- Original Message -------- Subject: [Full-disclosure] DNS Smurf revisited Date: Fri, 27 May 2005 10:28:37 -0400 From: Ian Gulliver ian-fulldisclosure@penguinhosting.net To: full-disclosure@lists.grok.org.uk
DNS smurf is old news:
http://www.s0ftpj.org/docs/spj-002-000.txt http://www.ciac.org/ciac/bulletins/j-063.shtml
However, as ISPs continue to operate networks that let spoofed packets out this issue deserves a little publicity again.
10:17:07.641061 IP (tos 0x0, ttl 64, id 46429, offset 0, flags [DF], length: 49) XXXXXXXXXXXXX.44295 > c.gtld-servers.net.domain: [udp sum ok] 18297 ANY? org. (21) 10:17:07.673800 IP (tos 0x0, ttl 43, id 0, offset 0, flags [DF], length: 468) c.gtld-servers.net.domain > XXXXXXXXXXXXX.44295: 18297- 0/13/13 (440)
% echo "2 k 468 49 / p" | dc 9.55
That's a 9.5X amplification of outgoing traffic; you can probably break 10X with a little more work on the query and nameserver choices.
SOLUTIONS ---------
ISPs: Drop outgoing packets that don't originate from within your network. You should already be doing this, as it stops a variety of other attacks.
NS operators: Ratelimit?
Attached is a modernized proof of concept.
Fabian Wenk writes:
This Mail [1] arrived just over the Full-Disclosure mailinglist [2], but should probably also be of interest to some people here.
[1] http://lists.grok.org.uk/pipermail/full-disclosure/2005-May/034342.html [2] https://lists.grok.org.uk/mailman/listinfo/full-disclosure
Yes, at least it should remind our community that ingress filtering is important. When I tried the "spoofer" test software from http://momo.lcs.mit.edu/spoofer/#software , I was shocked to see that I can spoof packets from my home broadband connection (and probably the 299'999 other broadband customers of that Swiss ISP can do so as well :-). Hopefully other Swiss ISPs do this better.
I hate to say something in defense of NATs, but at least the problem is somewhat mitigated by the fact that many surfers (especially those with broadband connections) use NATs. They make address spoofing from compromised PCs ineffective.
As for enterprise connections, I'm not sure. I assume most small enterprises use NATs as well. Large enterprises use firewalls, but if something behind the firewall does get infected, I'm not sure those firewalls would protect the outside world against spoofed packets (or any other kind of junk) from those machines.
On Fri, May 27, 2005 at 09:31:32PM +0200, Simon Leinen wrote:
I can spoof packets from my home broadband connection (and probably the 299'999 other broadband customers of that Swiss ISP can do so as well :-). Hopefully other Swiss ISPs do this better.
sunrise freesurf used to allow this also, didn't try for some time.
(it even let source address be in the private address space)
On Mon, May 30, 2005 at 09:55:39AM +0200, Marc SCHAEFER wrote:
On Fri, May 27, 2005 at 09:31:32PM +0200, Simon Leinen wrote:
I can spoof packets from my home broadband connection (and probably the 299'999 other broadband customers of that Swiss ISP can do so as well :-). Hopefully other Swiss ISPs do this better.
sunrise freesurf used to allow this also, didn't try for some time.
(it even let source address be in the private address space)
amazing to still see this in 2005! is there valuable argument from these ISP or is it ignorance / badly designed networks??
on the leaf interfaces of the ISP routing topology:
(cisco) ip verify unicast reverse-path
(linux) echo 1 > /proc/sys/net/ipv4/conf/ethN/rp_filter
there is still this good paper from cisco, it's a bit dated but probably mean no real valuable features was added in IOS since 2001:
http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip
bye.
is there valuable argument from these ISP or is it ignorance / badly designed networks??
Once someone told me they couldn't do it because it would add too much delay to the packet and that their hardware would would have to throttle the throughput if they wanted to do that on gigabit links. But then someone has to explain me how other people manage to do full NIDS inspection on gigabit links.
Jean-Pierre
On Mon, May 30, 2005 at 05:59:35PM +0200, Jean-Pierre Schwickerath wrote:
is there valuable argument from these ISP or is it ignorance / badly designed networks??
Once someone told me they couldn't do it because it would add too much delay to the packet and that their hardware would would have to throttle the throughput if they wanted to do that on gigabit links.
performances problems on an operation which is basically a routing lookup 4 bytes aside the usual place? funky.
But then someone has to explain me how other people manage to do full NIDS inspection on gigabit links.
absolutely.
Hello!
Am 30.05.05 schrieb Philippe Strauss:
sunrise freesurf used to allow this also, didn't try for some time. (it even let source address be in the private address space)
amazing to still see this in 2005!
Each filter takes some CPU cycles. And CPU-Power is still really expensive on a Cisco device.
A word stolen from the IBM world: "You will never have performance problems. You may habe financial problems, but you will never have performance problems."
http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip
Nice paper!
Beat
On Tue, May 31, 2005 at 10:49:00AM +0200, Beat Rubischon wrote:
Hello!
Am 30.05.05 schrieb Philippe Strauss:
sunrise freesurf used to allow this also, didn't try for some time. (it even let source address be in the private address space)
amazing to still see this in 2005!
Each filter takes some CPU cycles. And CPU-Power is still really expensive on a Cisco device.
A word stolen from the IBM world: "You will never have performance problems. You may habe financial problems, but you will never have performance problems."
a simple search on google, I find a paper about a routing table lookup algorithm, on standard CPU, able to do 30Millions lookup per second (on a 500MHz cpu). with current CPU frequency, it would rather be 120Millions/s on such "commodity pc" the bottleneck is the bus architecture, though.
2Gbit/s of traffic translate to roughly 400000 packets per second that leaves a lot of spare cpu time.
-
Beat Rubischon -
Fabian Wenk -
Jean-Pierre Schwickerath -
Philippe Strauss -
schaefer＠alphanet.ch -
Simon Leinen