Live data from Hacker News

IP Spoofing

idea.popcount.org

101–110 of 136 posts

Re: IP Spoofing

#101
post #31

Earlier quoted context omitted.

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 c…

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 abu…

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.

Re: IP Spoofing

#102
post #34

Earlier 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.

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.

Re: IP Spoofing

#103
post #71

Earlier quoted context omitted.

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…

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.

Re: IP Spoofing

#104
post #23

Earlier quoted context omitted.

Isn't it more akin to blackholing mail servers that don't set up DKIM, which almost all major mail providers do these days?

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.

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.

Re: IP Spoofing

#105
post #28

Earlier quoted context omitted.

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 transpare…

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.

Re: IP Spoofing

#106
post #90

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 o…

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.

Re: IP Spoofing

#107
post #77
post #24

Earlier quoted context omitted.

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.

It amuses me greatly that probably no one in this thread realizes who you are. (Except maybe Cloudflare.)

I have no clue who ryanlol is. Would it make a difference if I did?

Re: IP Spoofing

#108

Earlier quoted context omitted.

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 abu…

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 g…

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

Re: IP Spoofing

#109

Earlier quoted context omitted.

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.

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.

Re: IP Spoofing

#110
post #52

Earlier quoted context omitted.

All the orgs suffering from amplification attacks from services using UDP. DNS, NTP, chargen, etc.

... do people still use chargen? Are there seriously still chargen servers in the world?

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.
Post reply on HN