On 04-Aug-2015 12:17 pm, Jared Mauch <[email protected]> wrote: > > On Sat, Jul 25, 2015 at 09:21:02PM -0400, George, Wes wrote: >> Last โ I had a conversation with someone (whose name is unfortunately >> escaping me) in Prague regarding this, and he mentioned one point to >> potentially highlight is that UDP attacks that are abusing open reflectors >> (NTP, Chargen, etc) can be distinguished from legitimate traffic if there is >> something in the header of most legitimate UDP traffic (especially that >> which is congestion-aware at the app level, or otherwise well-behaved) >> because while an app could generate packets with the right flag, traffic >> coming in from a reflector is unlikely to have that information on the >> header since the attacker does not have any actual control over the >> reflector. It wouldn't fix raw UDP floods (non-reflected DDoS) where the >> attacker generates packets with that bit set but it would at least give you >> another piece of data when establishing your baseline. I hate to say it, but >> it's almost like the opposite of the "evil bit". >> > > Wes, > > This is sadly not the case as some of the operational > attacks observed have ephemeral ports for both numbers so it > is harder to mitigate as vendors quickly run out of TCAM when > implementing these features in hardware. It's not easy to compile > a filter that matches all the traffic and just QoS against the bad > as it's been NTP, DNS, CHARGEN, SSDP and with full UPnP/SSDP enumeration > of hosts within the home occuring, traffic from those inside > hosts mean the call^Wattack is "coming from inside the house". With > attacks using UDP/80,443 as common destination ports it's not easy to > discern these from actual NAT'ed traffic egressing a home or otherwise. > > We sadly had to deploy some UDP limits at $dayjob due to > attack sizes. Once we did this the daily triage went away. We were not > happy about the E2E aspect of this but the damage is now limited and > people can literaly sleep better at night with fewer pages and escalations.
Which does not bode well for WebRTC (which uses UDP for its SRTP and its data channel) or QUIC. -d > > - Jared > > -- > Jared Mauch | pgp key available via finger from [email protected] > clue++; | http://puck.nether.net/~jared/ My statements are only mine. > > _______________________________________________ > OPSEC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsec _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
