6 ms·
I'm fairly naive about the specifics of a DDOS, but it's such an obvious vector of attack that I'm surprised it's a major vulnerability. Could anyone explain w
by andrewingram 16y ago
I'm fairly naive about the specifics of a DDOS, but it's such an obvious vector of attack that I'm surprised it's a major vulnerability.
Could anyone explain what it would take to minimise vulnerability to such attacks? I would have expected the standard load on SecureCode to be pretty high anyway, so I'm surprised that an attack brought it down. I welcome anyone to fix my reasoning :)
- cryptoz 16y agoThere's really no way around a DDOS, except to pay for enough servers to swallow all the fake requests and real requests. That's probably far too expensive to do - at least for now. Maybe the cloud can bring a solution to this, with the idea of spinning up new VMs as needed. Basically, if your site is open to the public then it's open to bots. And there are far more bots than people. So if someone directs their bots to your site, you'll go down. End of story.
- jacquesm 16y agoThere are plenty of ways to defend against this kind of attack, with varying degrees of efficiency and automation.
- cryptoz 16y agoYeah, it looks like I'm wrong about that. But then, I'd have to raise the question why MC hasn't done anything (successfully) yet to defend against this? They must be losing hundreds of thousands of dollars (per hour? not sure of volume here) because of the SecureCode payments failing all over the place. Also, a falling trust from consumers and vendors. It seems mission-critical to get their site back up, but they haven't. I assumed that was because they couldn't. But if you say they can....why haven't they?
- jacquesm 16y agoMy guess would be that they incorrectly estimated the magnitude of any attack that they would have to deal with and are now scrambling to get a procedure in place that allows them to forward lists of 'known bad' ip addresses to their upstream providers to be placed in ACLs. Everything is hard the first time.
- marknutter 16y agoI wonder if it would be viable to offer DDOS protection in the form of a huge bank of servers that the victim could rent for a specific period of time to help alleviate the affects. Companies could pay for it like it's insurance.
- nikcub 16y agoThe program that is being used is a multi-threaded .NET app that opens a lot of connections and then allows them to timeout. Easiest form of DoS to carry out and easiest to defend. Prevention: a) Upstream forwarding proxy that will block all requests from an IP that hammers the server b) Low timeouts (5-10 seconds) c) Intelligent upstream router than can drop the routes d) They are hitting mastercard.com, which should be distributed on a CDN e) Separate the public website from the application, don't even but them in the same IP address block At Techcrunch we survived a 4chan DoS attempt. Surprised Mastercard didn't (I think the scale of this attack is larger, but still)
- wildmXranat 16y ago>At Techcrunch we survived a 4chan DoS attempt I wouldn't mention it; just my friendly advice. Anon is a fickle beast.
- ubercore 16y ago> I think the scale of this attack is larger, but still That's a pretty large but, when a DoS is, by nature, all about scale.
- icegreentea 16y agoIn fact, pretty sure it's this program: http://en.wikipedia.org/wiki/LOIC http://en.wikipedia.org/wiki/LOIC They even gave it a cute name. I find the 'relinquish control' part really interesting. Someone could totally f anon over if a hivemind version with access to the OS was released. Yeah, you could only ever use it once, but once is enough. 4chan would reverb about it for months. Also because I just kept imagining the program playing a clip of the Harbinger going "assuming direct control" whenever you relinquish.
- calloc 16y agoThe issue at hand, and what you have to minimize depending on what attack is being used, is malicious packets reaching your servers. Now, it is a fairly difficult task to figure out what packets are malicious and which packets are real as they definitely look alike. Going with the latest web server attack (the long open connections with POST) there is not a whole lot of protection that could be afforded other than throwing more resources and more servers at the mix such that each of them can handle the open connections that are SLOWLY sending data to them. There could be time-outs, but those are easy to figure out with some experimentation and it doesn't require much to keep endless connections going forever and sending the bare minimum required to keep the connection alive. Other attacks like ICMP ping floods just flood the network to the point that the routers are unable to physically carry the traffic from point A to point B. They start dropping packets. If at this point you attempt a TCP/IP connection it most likely will not get through in the large flood. ICMP traffic can be dropped at the door, letting legitimate traffic through again, and generally can easily be taken care of at the edge routers. Then there are the various TCP/IP flood attacks which are mostly designed so that on the target a connection stays in an open queue whereby the host runs out of backlog so that it can't accept new connections, also known as half-open connections. SYN cookies help with this. Or still the best method is to have a VERY large botnet of computers that attack the target so that the amount of traffic is simply overwhelming no matter the method used. If your server is on a 100 Mbit connection, you can NEVER accept 1 Gbit worth of data. Now multiply that and start looking at where in the infrastructure there is a bottleneck. If inside your network you can accept 10 Gb's a second, but your gateway router is only rated at 1 Gb's a second you can just choke the router and it doesn't matter what is behind it. With massive DDoS attacks it becomes very costly, as you have to divert the traffic elsewhere first where it can efficiently be filtered for legitimate and non-legitimate and then have it be sent on to the actual backend servers that then respond.
- Dylan16807 16y agoYou don't need to scale up to solve a problem of slow active connections. You just need to use a frontend web server that doesn't allocate a thread/process per connection.
- 16y ago