I will never understand why some people disregard IP spoofing as a real risk. For example when I reported a vulnerability to the nginx developers (http://blog.zorinaq.com/nginx-resolver-vulns/) about their DNS stub resolver using predictable transaction IDs, they refused to consider it a vulnerability, effectively saying no one could exploit it because spoofing the IP of the DNS server can't be done on the Internet. And yet https://spoofer.caida.org/summary.php shows ~25% of network prefixes can be spoofed... sigh
It's a form of victim blaming. We have hoards of people chasing down any developers that have written a fast response UDP protocol and any operators running them. Yet the cause is incompetent ISPs that fail to implement BCP 38.
Even if the crusade to end useful UDP protocols is successful, all of that short-sighted behavior is for nothing because untraceable DDoS attacks are still a problem. Someone with a spoofing capable, 100,000 node botnet (or the bitcoin required to rent on) with or without reflection capabilities is going to be able to saturate 40gb links.
Name and shame ISPs that allow spoofing, stop wasting developers' time with this crap.
this presentation was prepared before the Krebs On Security DDoS attacks which had a different profile and did not use Spoofed IP addresses. Krebs's DDoS attacks launched by internet-of-things devices were unusually large. Most of the non-spoofed attacks were way smaller. This does not invalidate this talk. Non-spoofed attacks are easier to block - since the source addresses are known. It is also possible to fight and eventually destroy the botnets. This is much harder when the IP's are spoofed.
Once spoofing is solved, you have attribution. Once you have attribution, you can use blacklists, notify ISPs, etc. Cleaning up or isolating infected machines becomes tractable at that point.
Blacklists and attribution do not hold that much value.
Blacklists are only useful to stop only a few DDoS attacks mainly amplified ones like the ones that abuse open DNS resolvers which should be cleaned up on their own, in which case you want to be blacklisting the resolvers not the machines that use IP spoofing since they do not attack you directly.
Many (heck most) DDoS attacks do not use IP spoofing, the recent and largest recorded in history just used 145,000 IP enabled cameras, and this isn't even remotely the largest botnet out there, blacklisting an entire botnet is effectively DDoSing yourself since many of those machines can be on a network with 100's or 1000's of other computers behind the same IP which many of them would be legitimate users of your service.
Notifying ISP's also doesn't help, some ISP's can do some preventative measures but what often they do is simply kill routes to your service, again it would work if you are dealing with some ISP in Slovakia if you aren't serving any customers there (granted they actually respond to you in due time) but if you are dealing with large ISP's there is little they could do and cutting them off isn't an option.
And as for as cleaning and isolating these machines this is laughable, you aren't going to be tracking down customers, even the ISP won't do that for you, and even if it did what would it do send and email that would likely be ignored? Even if you identify customer the IP belongs to it doesn't tell you anything about the device, not to mention that the customer would likely have no capability of cleaning up their machines to begin with.
IP spoofing is a problem because there are currently ways to abuse IP spoofing to amplify the attacks, if you aren't amplifying your attack using UDP protocols you will usually not going to be using IP spoofing in the first place, and automatically banning IP addresses might sound like a good tactic until you are hit with DDoS from a big botnet within your market region at which point you can't use that any more, you might ban a few IP's that seem to have access to excessive bandwidth but even that might be problematic since it can affect legitimate users.
>Blacklists and attribution do not hold that much value
Only because spoofing prevents them from being reliable in any way.
>in which case you want to be blacklisting the resolvers
This approach is idiotic and its the reason these attacks are still a problem. EVERY DNS SERVER can be used if it resolves anything, not just if it's an open resolver. So your blacklist would have to include the root name servers, the .com names servers, etc.
>if you aren't amplifying your attack using UDP protocols you will usually not going to be using IP spoofing in the first place
Completely false. SYN floods and non amplified UDP floods very frequently spoof because it makes pruning attacks upstream by source impossible.
I'm not sure where you got this information, but stop spreading it. It's protecting incompetent network operators, harassing service operators, and doing little to improve the security of the Internet.
You need to go one step beyond attribution. You need to make BCP 38 and other 'behave nicely' protocols /requirements/; and to block any ISP that isn't following them.
1. Victim blaming is when you excuse someone's bad behaviour with the justification that the person(s) negatively affected by it could have protected/tried to protect themselves against it. That doesn't have anything to do with the question whether you should try to protect yourself, or whether you might have some obligation to try and protect others.
2. Based on your logic, what you are doing would be victim blaming: Incompetent ISPs don't perform DDoS attacks, and yet you seem to see some sort of obligation on their part to implement BCP 38 to protect others from that bad behavior of others. The ISP is just as much a victim in a position where they can help and protect others as people running UDP services.
Services used in amplification attacks are victims because their services are being DoS'ed as well and their IPs are the ones that end up on flowspec block lists.
They are also victims from the second order effects of idiots in prominent places claiming that their services are the source of the Internet's woes (e.g. Cloudflare's ridiculing of dns resolver operators).
Your entire second point is nonsensical because they aren't impacted by DoS attacks. They aren't 'victims' in any sense.
Also, people running UDP services cannot stop source spoofed DDoS attacks. You can block the entire UDP protocol today and the problem of untraceable attacks will be just as prevalent tomorrow. The largest attack observed (>1tbps didn't use amplifying UDP services at all).
BCP 38 would end this problem, full stop. ISPs complicit in what amounts to fraud deserve no sympathy. On most routers, ingress filtering is a one line option. Yet people like you promote breaking changes to UDP protocols as a half-baked solution that doesn't do anything to actually stop source spoofed DDoS attacks. It baffles me.
I agree that vilifying UDP doesn't really help anyone, but that's kindof besides the point.
Victim blaming is wrong because you divorce someone's intentional decision to cause harm from their responsibility for the resulting harm. To take the classical example: It's not inherently wrong to tell people that they should avoid situations that empirically have an increased risk of being raped. It's only wrong if you then claim that the perpetrator is not responsible for what they did because the victim didn't heed that advice.
Now, whether ISPs are victims isn't really that clear. First of all, the DDoS packets consume bandwidth, which can cause increased expenses without corresponding increased income. Secondly, at least the very moment you expect them to implement BCP 38, they absolutely are. Implementing BCP 38 is additional work that's only required in order to handle the bad behavior of other people that the ISP is not responsible for, aka harm due to someone else's malicious actions.
But also, the comment that you responded to above was about DNS cache poisoning, not about DDoS. By randomizing DNS transaction IDs, you absolutely can make DNS cache poisoning harder, and I think the responsible thing to do is to protect against that attack vector. ISPs should be doing more to prevent spoofing, but that doesn't mean that it's responsible to leave your users open to spoofing-based attacks that you should be able to relatively easily prevent.
Implementing BCP 38 is additional work that's only required [..]
That's like saying that the fact that I need to lock my door makes me a 'victim' of the existence of thieves, because otherwise I wouldn't need locks. That's not how the word 'victim' is used, either in general or in this particular context. Insisting on some extremely literal interpretation on the word 'victim' is entirely unhelpful here.
It's victim blaming in the sense that an ISP which should have taken the correct steps to number their endpoints (BCP 38) is not being harassed by companies like cloudflare for DDoSes while DNS server operators are.
"Yeah, this guy stole your car by asking nicely for an extra set of keys from the manufacturer. Even though the manufacturer shouldn't have allowed him to do get a key, we're holding you responsible since you technically could have kept your car in a locked garage."
Also, the gp was taking about cache poisoning, but it was only exploitable in the presence of spoofed IPs.
No, it's telling a child that has been hit by a car repeatedly to look both ways next time, when you know it would definitely reduce their chance of getting hit.
Performing edge ingress traffic filtering of known-trunked node addresses (i.e. BCP 38) has a high likelihood of reducing the effectiveness of DDoS attacks.
The problem needs fixed from both ends. Developers that write and maintain programs with bad defaults should be named and shamed as well. Their software has a security flaw that allows these problems to be exploited. Back in the 90s, the default configuration for most mail servers was to allow relaying from all and sundry, until the spam problem made people realize that an open relay was a bad thing that would be abused by malicious actors. Saying developers' time shouldn't be "wasted" on this is like saying automakers' time shouldn't be wasted on airbags and people should just drive better.
No, this is a completely false equivalence (the spam comparison). An open relay is the equivalent to ISPs allowing people to put whatever IP they want in the header.
People are operating completely sane services and anti-UDP warriors suggesting they change them because they appeared in a ddos is idiotic and harmful to the Internet. You can completely eliminate all UDP services and the untraceable DDoS problem won't go away, you've just eliminated some amplification avenues. The 1.5tbps attack didn't even use UDP so this "solution" is dead in the water and whoever is pushing it is misinformed.
Do you realize that every public DNS server in the world (root servers, recursive revolvers, Google.com NS servers, etc) can be used in an amplification attack? According to you we should name and shame every DNS developer, domain name owner, and operator.
We essentially couldn't have functioning DNS if we operated under your plan to 'fix this from both ends'. I suggest you read up on amplification attacks because I think you misunderstand how they actually work and think there is a way to 'configure' your way out of them.
This problem absolutely should not be "fixed from both ends". The right hand side (eliminate all amplifying UDP protocols) is massively disruptive (bye bye DNS) and doesn't actually fix the root issue (attackers just spoof TCP instead with a reduced amplification factor). The left hand side (BCP 38) requires fewer participants (ISPs vs server operators) and it completely solves the problem even without the slightest adoption of the stupidity on the right hand solution.
If you have ever suggested that a dns operator disable recursive resolving, you are perpetuating the problem by making people participate in an idiotic ritual that does almost nothing to improve the security of the Internet. It's the equivalent of restaurants not serving glasses of water to reduce the water shortage while farmers grow rice patties in a desert with essentially unlimited water rights.
DNS servers have in fact been modified to make it much harder to use them in amplification attacks, by adding response rate limiting - see http://www.redbarn.org/dns/ratelimits
Is udp/chargen really a useful publically exposed protocol? Does it provide a benefit over tcp/chargen?
Most of the fine people running chargen servers seem to be running the server from Microsoft services for UNIX package which is configured to send giant fragmented responses, and then they have a firewall that drops the first fragment. Thanks a lot guys.
Oh man they are rare but they are definitely still out there. Think printers from the 90's that came with chargen & usually telnet enabled by default, and for some reason are publicly accessible.
1) There is no evidence that the recent giant DDOS attacks on Brian Krebs used IP Spoofing. In fact, there is every reason to believe that they did not since the generators of the packets were low powered IoT devices. There is increasingly little reason for attackers to even bother with IP spoofing given how easy it is becoming to capture giant herds of low power IoT devices. The attackers don't care if some of their herd gets taken offline due to effective attribution.
Amplification/reflection attacks which will still require IP spoofing. What I'm curious about, and only time will tell, is how much IP spoofing will continue to play a part in lsrge DDOS attacks? Why bother spoofing IPs if your botnet herd is already large enough to bring someone offline?
You answered your question there. Without spoofing, only the largest botnets can launch a successful DDoS attack. That's a big barrier to entry, and if the police were effective on this area, would be a huge boom to fighting those attacks.
> Without spoofing, only the largest botnets can launch a successful DDoS attack. That's a big barrier to entry
In the days of Shodan, NO. Absolute no. 100/10 or 50/5 MBit/s household networking is becoming the norm in Germany, and other countries are way ahead of us Germans. Add in the fact that people with lots of (crappy) IoT devices are people who also have the money for high-speed internet connection...
Then throw in a couple of stro's at DCs with good interconnections, and you got yourself a niiiiiiiice huge botnet. You can do LOTS of damage if you get maybe ten or twenty servers with 10 GBit/s links under your control! (10 servers = 100 GBit/s, 10% of the Krebs attack IIRC)
I dunno. Spoofing for reflection/amplification is only going to work for certain services(e.g., DNS, NTPD). So perhaps if you don't spoof, but instead capture a large enough IoT botnet, you might be able to generate traffic that's harder to spot and segregate. I think we need to watch this space and see how things develop.
If every upstream providers will have the netflow protocol in that case they can just drop bad traffic on the specific interface and they also can trace a source of bad traffic and drop it as early as possible.
I have used IP spoofing for good in the past: I had a large number of sensors reporting real time data to our servers. As we wanted to migrate to a completely new infrastructure we wanted to have replication from the old servers to the new. Instead of setting up some kind of higher level system, I wrote a tiny service in C which received the datagrams and then re-sent them to the new servers but spoofed the source IP so it matched the sensor. This worked incredibly well, and the tool was later used for various other purposes.
Of course toward the end of it I learned that I could have done this all with iptables, but I like my way better because I got to learn a lot.
There are valid reasons to spoof IP addresses (we do that at work in production). It's only bad if the spoofing "leaks" out to the Internet at large (at work, we know which machines are doing the spoofing, and it's a limited number of spoofed addresses, all directed towards own own equipment).
Ugh, if you're identifying sensors by IP instead of some other ID in the payload, you're doing it wrong. NAT between the sensors and you can throw a wrench into that whole scheme in a hurry.
This is just a smell emanating from another poor design, not a justification for IP spoofing. If you want to spoof addresses, do it in the privacy of your own VPN tunnel between the servers. Don't expose that sickness to the Internet.
You sir are quick to jump to very incorrect conclusions. It's a bad habit and you should abandon it at once.
First, I never said we identified the sensors by IP, but it was important that we record the sensor's IP for diagnostic information.
Second, IP spoofing was not done over the Internet, but rather only between our own servers inside our data center. Obviously doing this over the internet would not only be bad, but also highly unreliable.
Port forwarding on some consumer grade routers work using IP addresses (not MAC addresses). If I assign a computer a static 192.168/16 IP and forward a port to it, I'm doing it wrong?
There is no excuse for not securing your network to allow spoofing from it. Most of the big players like leaseweb or ovh do not allow that. But there are some providers that still allow you to spoof source ip address. There should be consensus about droping routes on BGP level to networks that send packets with source ips that they do not announce. It's really simple to drop packets on switches/routers that do not originate from your network. It would make ddosers life harder.
I used to have a regular retail network connection at the office (local DSL carrier, not some industrial-grade expensive fiber thing) that allowed spoofing. The office was multi-homed (we had a second connection from a different provider for redundancy -- it turns out that our major local incumbent provider had maybe one nine of availability), and the results were hilarious. It turns out that, because Linux considers IP addresses to belong to a computer and not to an interface, it's fairly easy to (mis-)configure things so that traffic with a source address belonging to one interface goes out the other interface. This, coupled with spoofing being allowed, meant that we sometimes accidentally spoofed ourselves, and it worked! We went for surprisingly long times without noticing that some of our TCP connections went out one pipe and back in the other.
If I remember right, we would only notice it when we were confused by packet captures, when we had strange performance problems, or when we'd discover that we suddenly had two single points of failure. :)
This sounds great in principle, but it breaks down in practice. From the article, 27% of ISPs still allow spoofing on their networks. This is mostly due to them being smaller, regional ISPs without the expertise or staff to figure out how to do this.
I hear you saying "just blackhole them until they figure it out," but it's not that easy. In many cases, the small regional ISP is the customer of a larger ISP, who is the customer of an even larger global ISP that you are connected to. You just see XXXgbps of traffic coming from your ISP, and have no idea which one (or more) of their customer's customer's are sending the traffic.
This would be like saying "just don't let the one guy that's going to pee in the pool swim." How do you know which of the 200 people in the pool actually peed?
Well you know the pee is coming from 1 of 3 (or maybe all 3) guys. You just threaten to kick them all out if they don't figure out which one is doing it.
This is a serious problem and it should be treated with serious consequences.
I've also wondered why ISPs don't do more to shut down customers that are participating in a DDOS (at least for DDOS attacks where the source IP isn't spoofed)? I would be very happy if my ISP were to let me know that something on my network is involved in an attack.
My ISP does that (XS4ALL, the Netherlands). Of course they can't know everything but if they receive abuse reports, notice your IP got blacklisted for spam or some honeypot network got a whiff of your IP address running malware variant XYZ, they put your IP address in quarantine (only 80 and 443 outgoing I think, or maybe only to the ISP's own website or something) and ask what's going on.
I can tell you they're a real pain to convince to unblock you when you are 17 and have been a bad netizen. Which is a good thing.
When it comes to ip spoofing based ddos attacks, the ISPs capable of tracking spoofed traffic on their network don't allow spoofed traffic. If they don't allow the spoofed traffic, you aren't participating in the DDoS.
Support costs for shutting down the average user are higher than the costs of bandwidth. Telling someone that their internet was shut off because their device was used in a botnet would lead to very long support calls and escalations.
That would penalize a whole pile of parties that probably have nothing whatsoever to do with the spoofers. It's akin to blackholing mail from yahoo.com because there are spammers on yahoo.com.
No, if you drop the BGP route the whole range disappears, not just the host that spoofs the IPs. So it kills off a whole pile of innocents as collateral damage.
I don't know if I understand. At first I thought you meant that we shouldn't drop entire providers because one of their customers spoofed an IP, but of course the burden should be on those providers to make sure spoofed packets can't leave their network (since further up the chain you're getting packets that are originating from many networks). Are you talking about something else?
You stop peering with providers originating spoofed traffic. The whole point is that you don't know which host is doing it (the IP is spoofed!). All you know is that a provider is allowing spoofed packets (with a probe from participating endpoints in a measuring service). That provider should be dropped and everyone on that provider should suffer collateral damage because that's the only way to economically incentivize them.
I think there are probably many of them but they are hard to think of because they would relate to unusual situations. There at least one very nice that I know : if you are hosting something (eg a webserver) behind a connection with limited upload capabilities like a consumer grade DSL, you can very easily aggregate multiple uploads links with nothing more than a bit of iptable magic. It would be completely transparent to the downloading peer.
These are still likely to be IP addresses in an IP range the ISP is responsible for routing. This is the big need. ISPs need to stop packets on egress that are from IP addresses not in the ISPs network. There's no excuse for it and it would drastically undermine a sizeable number of DDoS attacks (not every DDoS, because they don't all require IP spoofing.)
Unfortunately this requires ISPs to actually be responsible for the data coming out of their network, including DDoS traffic. Once you stop the spoofing, ISPs and transit providers will soon figure out which ASs are problems and start blocking them etc.
Most cases (this one included) are covered by a proper BGP setup (you advertise to each upstream) or an email conversation with the upstream ISP to get another IP allowed.
There is an excuse for not "securing" the network: disallowing spoofing is not desirable in the first place. There are legitimate uses to spoofing. What is not desirable is malware infecting user computers and using spoofing for DDoS attacks, but the ISP cannot know whether the packets were sent by malware or by a user. The proper way to solve the issue is to make secure systems that will not get infected easily by malware.
Netflow is a great example of the dual use aspects of tech between surveillance and defense. Making Netflow data more widely available looks like it is going to be essential for defending that Internet but at the same time Netflow data can threaten the anonymity of Tor users.[0][1]
This is true, but it is a fundamental fact of the Internet, and has been since before Roger Dingledine first started presenting Tor to people at Black Hat. The major ISPs are all instrumented with Netflow, they're all collecting it, and they've all got tools (both in-house and from vendors) to analyze it.
So if you're going to try to deploy something like Tor, the table stakes are that you're secure against wide-scale Netflow instrumentation. If Netflow is an existential threat to your privacy tool, you don't have a privacy tool that is ready for deployment.
For ddos attribution, you generally only need a very small sample rate, and only headers. You might be able to use that against tor connections, but only when you're very lucky.
Of course, I'm not sure if cloudflare could care any less about tor users. They see a lot of attack traffic from tor so this probably isn't something they are concerned about. I can't really blame them from a business perspective, but I avoid cloudflare due to it.
This is ridiculous. Anyone can grep their access logs for signs of obvious attacks and very quickly verify that very few, if any, of them originated from Tor exits.
I consider myself pretty technically savvy... Developer and DevOps.
However, when I see tricks like in this talk using iptables with BPF bytecode[1] to block SYN packet floods, I get completely humbled. I know that I know nothing.
"Operating a content neutral service in today's internet is a tough job. Some people dislike some websites, and they want to stop them from being available on the internet. The easiest way to do so is to launch a DDoS attack."
... which you can conveniently buy on one of the CloudFlare-protected DDoS service websites! I know this point has been hammered to death before, but I find it curious that despite their strong advocacy of being content neutral and not removing a site unless they receive a court order, their Terms of Service explicitly allows them to shut off service based solely on their opinion:
"SECTION 11: INVESTIGATION
CloudFlare reserves the right to investigate you, your
business, and/or your owners, officers, directors,
managers, and other principals, your sites, and the
materials comprising the sites at any time. These
investigations will be conducted solely for CloudFlare’s
benefit, and not for your benefit or that of any third
party. If the investigation reveals any information,
act, or omission, which in CloudFlare’s sole opinion,
constitutes a violation of any local, state, federal, or
foreign law or regulation, this Agreement, or is
otherwise deemed harm the Service, CloudFlare may
immediately shut down your access to the Service."
Am I the only one that believes that the kind of non-preferential routing and anonymity that the current exchange setups provide is a benefit? In terms of society as a whole this far outweighs the downsides of DoS attacks using IP spoofing.
"Solving" the "problem" of ip spoofing is only a benefit for centralized authorities and services. The loss of privacy is also serious. People advancing this idea are advancing it to better their commercial interests rather than the interests of individuals using the 'net.
Is that an actual use case? What could you possibly do without return traffic?
Reverse Path Forwarding is best practice, and has been since more than a decade. The normal reason packets appearing on the wrong interface is a routing loop somewhere and this alone makes it worth it.
I'm not saying IP spoofing is useful for many real tasks. I'm saying the solution proposed in the article will end up being abused and worse than the problems it solves. It's one more step to an internet where commercial traffic is prioritized over actual users at all steps along the path.
Can someone explain the consequences of DDoS attacks to me? My understanding is that the worst case is that the target server goes offline for the duration of the attack.
If that's indeed the endgame, it seems like a lot of work on the attacker's part to disable a company's servers for a bit, but maybe I"m missing something? The article did mention servers boiling, but that was likely hyperbole unless there's a way to physically damage servers with DDoS.
Imagine you are a news outlet. You make money by creating articles that entice people to view your website. You make money to pay your expenses by having advertisements on your website.
DDoS = No Website. No Website = no users viewing ads. No users viewing ads = No income.
Yes, that typically resolves quickly. Depending on your hosting agreement, you may have to pay for all the excess bandwidth that the DDoS bots used.
Now imagine if you are a bank, users want to be able to access their accounts/funds/etc. How long would you remain with your bank if you frequently couldn't access your information because they were being DDoS'd.
You are correct a DDoS (Distributed Denial Of Service) is intended to take a target off line or simply slow down the target significantly (ideally making the service useless)
While it is very unlikely to cause hardware damage it can be extremely damaging to a company or service.
Service outages undermine customer trust and could drive users to your competitors. A company might also have a service level agreement with large financial costs associated with a service being down.
If you don't mind the service being down, then why have it? It going down will probably have some very negative effect.
First, one can spoof udp packets in the same way as tcp segments. Think syn or ack floods.
Second the Krebs ddos is said to generate over 600 gigs of traffic but it was not necessarily with fully established tcp connections. It's unlikely it was with valid tcp connections.
Let me give you a thought experiment: if you are flooded with 600 gigs of forged tcp packets, how do you know if the source ip's are spoofed or not? How do you know the ip in the src ip field belongs to the one that originated the packet?
Except for the latest and largest attacks: OVH @ near 1Tb/s in combined tcp_ack traffic on 2016/09/20 [0]
When attackers have 150k+ comprimised hosts, with 1-30Mb/s each, there is no need for reflection/stealth/source spoofing/etc. At those levels, the attackers can just point them to an IP with 'normal' traffic and it's enough to be devastating.
Since IP spoofing could be done by a few malicious hosts, is it really accurate to consider a DoS via ip spoofing 'distributed'? Sure the source IPs may appear to come from all over, but that's just an illusion.
When I think DDos, I envision thousands of compromised hosts all over the internet making requests to a target to consume resources.
Am I correctly understanding that big/most attacks are against unwanted content? For instance, in my country the two most popular political blogs that make strong opposition to the government are regularly DDOSed. If that is the case, maybe an easier solution would be to make this a software problem and not a network one. For that, I think we already have the tech to make P2P websites feasible. My phone and data plan cannot serve hundreds of requests per second but I'm sure I can get ALL the content I read on a given day from peers as well as pass it along to others. Clearly not a solution for all Internet use cases but a viable alternative to blogs.
This is a great talk. Marek does an awesome job of explaining something that is very technical in a clear and casual manner. I definitely learned some new things.
I've been a software engineer for 18 years, but this amazing post reminded me how little I know about how the internet works lol. Going to read this a few times for sure!
Large bandwidth attacks might look sexy, but they're trivially easy to block. Network operators care about pushing packets, not bits. The OVH attacks look huge to the average AWS user, (ZOMG a terabit!) but to even an average tier 2 transit provider it's a trivial attack to block. Especially when the attackers are hitting a single endpoint.
To be honest, attackers are not very smart. They almost always use the same old attacks, attacks that are easily stoppable, and attacks against a single IP.
100gig coherent is easily turning volumetric attacks into old hat. Ending spoofed attacks today is a tactic that's 10 years too late.
It's not trivial by any means other than preventing it from clogging up internal stuff. If they are targeting a specific IP and the traffic is indistinguishable from normal traffic in the l3/l4 headers, there is no way you are going to block the attack without taking down the service.
This is why solving spoofing is such an important problem. Once source IPs become sticky, we can actually block based on them to truly stop the attack without taking down the service.
You block volumetric attacks by filtering the payload, not by blocking IP's. If you block by IP, you're going to have a lot of upset customers. Also, what are you going to do on an IPv6 attack? Block the entire /64? Unlikely. Also remember that a single IP doesn't always mean a single user for IPv4. An IP might represent several thousand customers in the case of NAT and especially CGNAT.
If the traffic is indistinguishable from normal traffic via L3/L4, then it's a layer 7 attack, which cannot be spoofed. You're not dealing with spoofing in a L7 attack.
The first D in DDoS stands for distributed. Even terabit sized attacks are easy to stop if they're sufficiently distributed (the attack is geographically dispersed enough to be diffused). It's when you get a terabit from a handful of AS's (like in S. Korean attacks) that you can feel pain. Even then, it usually only knocks out access in that part of the world, but not everyone.
IP's will not be sticky. IPv6 is showing why it's important to not be sticky. Ending spoofing isn't going to stop DDoS attacks. I've got 10+ years of experience on the subject, and I'll gladly answer any questions you might have.
Yes, you block by IP and piss off customers or the whole /64 if necessary. IPs will almost always be sticky to the advertised prefix.
A TCP SYN, or any UDP initial request indistinguishable from legit traffic of the same protocol at L3/L4, and both can be spoofed so I don't know where you got the idea that they cant be spoofed and are L7 only.
If you're "stopping the attack" through dispersion, you're not actually stopping it, you're just paying the price of absorbing it. I know this is common practice, but it's pathetic than an arms race is the state of the art in defense. It concentrates power into orgs like cloudflare, akamai, and Google (project shield) because the only way to participate is to use them.
It's a technical talk. It's much better to hear from people who are being attacked regularly and have a track record of dealing with it rather than those who have no clue.
sure except their paper just describes the issue and their solution is "pay us money". Not really up to the same standard as even a bad academic article, more like the paid talk track at a conference, you know, the kind lots of people avoid.
They laid out several solutions, and none of them are specific to their platform. They also highlighted how the attacks are changing and if you're to effectively defend yourself you'll need to have more resources on hand.
You can pay them, you can do it yourself, you can pay someone else, but at least you have options.
That was an excellent presentation, very informative.
Except, why put that ridiculous meme in the middle of it? It's cringeworthy seeing an excellent technical presentation littered with such childish imagery.
(Not that I agree with this bastardization of "meme" to mean "silly image with text overlaid in capital letters", but unfortunately that is what everyone is calling these things.)
> (Not that I agree with this bastardization of "meme" to mean "silly image with text overlaid in capital letters", but unfortunately that is what everyone is calling these things.)
The term for that is "image macro" [1]. An image macro represents a meme when the image is associated with a particular joke format, catch phrase, archetype, etc..
