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.
IP Spoofing
81–90 of 136 posts
Re: IP Spoofing
#82Earlier quoted context omitted.
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.
What legitimate purpose is there for spoofing your IP address?
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.
Re: IP Spoofing
#83I 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.
[1] https://idea.popcount.org/2016-09-20-strange-loop---ip-spoof...
Re: IP Spoofing
#84Earlier quoted context omitted.
This is precisely the point of this article. The only real long term solution to stop large DDoS is to stop spoofing. The only way to stop IP spoofing is to shame misconfigured networks. For that you need attribution.
Recent HTTP DDoS attacks have shown that there is no dependency on spoofing. The problem will be there as long as there's insecure hardware out there.
Currently DDoS requires insecure hardware.
If it didn't, we're one step closer to fixing it.
Re: IP Spoofing
#85Earlier quoted context omitted.
> It's a form of victim blaming. 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…
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 th…
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.
Re: IP Spoofing
#86Earlier quoted context omitted.
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 t…
> 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? Sounds like a logic puzzle. I'm thinking a binary search would be the most efficient way.
I think K-means would work best-- whichever cluster is closest to the "hot zone" gets the boot. :P
Re: IP Spoofing
#87Earlier quoted context omitted.
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?
BGP route is on the receiving end.
Re: IP Spoofing
#88Earlier quoted context omitted.
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,…
If you have anything , including diagnostic information, that depends on the source IP being correct, you're doing it wrong.
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?
Re: IP Spoofing
#89I'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!
Re: IP Spoofing
#90Large 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.