On Tue, 28 Feb 2006, Hallam-Baker, Phillip wrote:
There are people who think they need to do such things, such people tend
to be wrong with remarkable frequency.
I happened to think there are better ways to achieve the results but I
would not go into saying that those who need spoofing capabilities right
now are wrong. In any case, you need to face the facts that many ISPs
are not going to drop spoofed packets now even if we tell them to as this
is capability some of their business customers require. This is slightly
better with DSL access providers but even there it is quite often allowed
for business connections.
Actually there are people who do TCP spoofing as you are probably aware
from the spam world. This is used to send large volumes of spam 'from'
hijacked dialup machines. The dialup machine only does the SYN part of
the protocol, the bulk of the data is sent from a hijacked broadband
machine.
Yes, this does happen. It is actually not usually hijacked dialup machine
but dialup connection directly bought from ISP with stolen credit card.
The entire tcp session connection is established using dialup ip address
as source, but actual packets go out from different interface - fairly
easy to achieve actually on linux and used for legitimate purposes.
It used to be more popular for spam purposes but I think this is quite
rare now due to availability of zombies. What spammers do still use is
getting space at some carrier-neutral colo center, connecting to multiple
providers and using one's ip address to establish the session but really
sending data though cheaper network (typically cogent) without actively
advertising such connectivity from outside. Considering this is totally
legitimate way to do traffic engineering, there is nothing that can
really be done about this practice.
However as I'm pointing out the recursive dns servers is only
one way to do it which derives from ability to poison them
and then cause them to reply with large response (so as to
use them for amplification). If dns server is not recursive,
but has very large dns record it can also be used for
amplification (slightly worse amplification factor of 1:20).
The smart way to avoid this becoming an issue is to either
use TCP or to use UDP protocol with fixed and fairly small
response packets.
It is not our job to fix the core DNS protocol.
I'm not sure it can be fixed given nature of the problem. And its
our job to realize these limitations, especially when trying to
re-purpose and reuse the protocol.
The amplifier attack you describe will worst case cause a doubling in
the data volume and that only if the attack machine is directing traffic
through multiple DNS servers at one time.
I'd really like to see where you came up with this "doubling" number
estimate especially "if multiple DNS servers" are used.
Just so you know the current cisco.com DKIM record results in 342bytes
message data (do "dig txt nebraska._domainkey.cisco.com") and security
of this key is may not be sufficient and many will probably use 2k ones
in the future. The original packet request to retrieve that key was
40-50 bytes in size (only QUESTION section). My estimates is that just
one dns server with DKIM record abused by this attack should give about
8x amplification effect (if you like I can write specialized scripts and
give exact numbers for several sites). With larger record size and if more
dns servers are present in zone files, this will increase further still.
Such 10x amplification numbers is more then good enough to make it worth
it to criminals.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html