Re: [PROPOSAL] DDOS - Distributed DoS (1 candidate)
Pascal Meunier said:
>I am considering whether the common entry point could be reduced to
>"egress filtering has not been implemented or has been disabled,
>allowing the sending of spoofed IP packets". Incidentally, this would
>prevent the use of decoys in port scans, etc... This single CVE entry
>would be very powerful.
I should have thought of this before, but there are already a few
candidates that try to deal with the lack of filtering. These were
proposed last summer, but haven't been accepted yet because they're
configuration problems and we all need to chew on these for a while
Note that there is no CVE entry or candidate for IP spoofing.
However, the Board did accept entries for TCP sequence number
prediction (CVE-1999-0077), and sequential port allocation
(CVE-1999-0074), both of which allow spoofing.
If we treat DDOS as a filtering problem, then there may be some
intersection with Smurf/CVE-1999-0513 (ICMP broadcast) and
Fraggle/CVE-1999-0514 (UDP broadcast), which are described as the lack
of filtering to broadcast addresses. If you've figured out a new way
to send out broadcast traffic and have it all come back to some
target, then to me it's an instance of Smurf or Fraggle.
Given the preference to avoid overlap within CVE, then is there
anything fundamentally different about DDOS that warrants a separate
entry? For Trinoo-related issues, I say yes, because you aren't
dealing with arbitrary traffic to broadcast addresses, but directed
commands to specific addresses.
>The weakness of this is that one could in theory still use DDoS tools
>even if you have egress filtering -- only they will be one shot guns,
>almost completely eliminating their appeal and effectiveness. One
>use, and they will be blocked, tracked down and destroyed efficiently.
Spoofing adds another level or two of complexity, but I think we are
agreeing here that the underlying "vulnerability" doesn't go away
completely, even if there is no spoofing and egress filtering is
implemented properly. The damage can still be done. This suggests to
me that there are at least two separate issues at play here -
"spoofing" and "something else," where "something else" could be "lack
of egress filtering and yet another thing."
To round out the topic of filtering, I've attached the other
candidates that were proposed last summer. They aren't pretty and
they aren't complete, but they do suggest that there may be a
"middle-of-the-road" approach to this thorny issue.
A router or firewall allows source routed packets from arbitrary
INFERRED ACTION: CAN-1999-0510 MOREVOTES (2 accept, 0 ack, 0 review) HAS_CDS
A router or firewall forwards external packets that claim to come from
inside the network that the router/firewall is in front of.
INFERRED ACTION: CAN-1999-0528 MOREVOTES (1 accept, 0 ack, 1 review) HAS_CDS
Frech> possibly XF:nisd-dns-fwd-check
A router or firewall forwards packets that claim to come from IANA
reserved or private addresses, e.g. 10.x.x.x, 127.x.x.x, 217.x.x.x,
INFERRED ACTION: CAN-1999-0529 REJECT (1 reject, 0 accept, 1 review) HAS_CDS
Northcutt> I have seen ISPs "assign" private addresses within their domain
A filter in a router or firewall allows unusual fragmented packets.
INFERRED ACTION: CAN-1999-0588 REJECT (1 reject, 1 accept, 0 review) HAS_CDS
Northcutt> I want to vote to accept this one, but unusual is a shade broad.