Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment: tl;dr: DRA smacked for domain transfer fraud (Score 5, Informative) 113

by Snowhare (#47495021) Attached to: Domain Registry of America Suspended By ICANN

Domain Registry of America has made a business out of sending deceptive letters to domain owners using other registrars asking them to "renew" their domain registration with DRA. The letters are cleverly written to make it unobvious so that people who think they are just renewing their domain actually have their domain registry transfered from their current registrar to DRA.

Comment: Re:Honesty? (Score 1) 440

by Snowhare (#44342339) Attached to: How Climate Scientists Parallel Early Atomic Scientists

1) Climate change has always been more used than global warming in the actual literature. A fact easily confirmed by checking the Google Ngram Viewer

2) You can thank Republican Party strategist Frank Luntz for popularizing climate change over global warming in the mass media. The Republicans got behind climate change vs global warming specifically to convince the public that it wasn't a serious issue. So your 'honesty' argument backfires: It was the Republican Party that wanted 'climate change' to be the popular term so people wouldn't take it seriously.

Comment: Misspelled 'Drone Strike' as 'RC Plane Attack'? (Score 1) 233

by Snowhare (#44121095) Attached to: RC Plane Attack 'Foiled,' Say German Authorities

Really - did anyone in Washington bother to think about the fact that by repeatedly demonstrating to terrorists how easy it was to use 'remote-controlled model planes packed with explosives' to cheaply kill people that you otherwise couldn't easily reach ("Drone Strikes") that the terrorists wouldn't eventually try variations on the same idea themselves?

Comment: Re:In other news Apple is banning Android devices (Score 5, Interesting) 404

by Snowhare (#41034959) Attached to: Google Seeks US Ban On iPhones, iPads, Macs

Yep. This is Google explaining to Apple that they aren't the only one with patents. The monster patent portfolios of all the big players have exist in part to deter other large players from launching patent wars. It is a form of 'Mutually Assured Destruction'. Apple went nuclear starting a couple of years ago. Google (and other large players) are now launching their counter-strikes to demonstrate to Apple why it is a bad idea.

If Apple has any sense (more likely now that Steve Jobs is gone) they will begin quietly trying to wind down the patent wars.

Comment: Re:Load balancing and an experienced sysadmin (Score 1) 197

by Snowhare (#39653115) Attached to: Ask Slashdot: Experience Handling DDoS Attacks On a Mid-Tier Site?

A "small" DDOS attack is more than enough to down an unprotected machine. I experimented with less intensive approaches *first*. If I limitted the number of Apache connections they would run up the number of open connections until the server quit responding. If I let the number processes grow, they would keep adding connections until the machine ran out of memory to support additional connections. With a pool of more than 30K potentially attacking machines it takes an *incredible* amount of resources to just 'ride it out'.

You run into multiple limits: How many simultaneous TCP connections can your system handle? How much memory does it take per connection? How much CPU does it take to context switch between thousands of connections?

It was a simple yet very effective attack. If you didn't have a good sysadmin who *could* erect an intensive defense your choices would be

1) Let your site go down.

2) Pay a DDOS defense service to defend you.

Comment: Re:Load balancing and an experienced sysadmin (Score 1) 197

by Snowhare (#39639761) Attached to: Ask Slashdot: Experience Handling DDoS Attacks On a Mid-Tier Site?

This assumes they are just trying to flood the httpd with requests, because doing so requires less resources on their part, and generally only harms the target box and not the isp hosting it.
If you block an attack like this, you run the risk that the attacker will switch tactics and start simply flooding your line.

True, they *could* have escalated it to a packet flood (and oddly enough naively dropping the TCP packets actually initially converted the HTTP Flood into a SYN flood - which didn't pose much of a problem for me at the rates they were running).

But it is much more resource intensive for the attacker and they are optimising return on investment. They can waste time dedicating their botnet to packet flooding a minor site with no financial payoff even if they succeed in bringing it down, or they can move on to easier targets where they can continue to 'time share' the botnet traffic among multiple targets.

It really is the 'why have locks on your doors and windows when the thief could kick them in' argument. Sure - he *could*. Or he could move down the street to the house that left their bathroom window open when they went to work.

Comment: Re:Load balancing and an experienced sysadmin (Score 1) 197

by Snowhare (#39639621) Attached to: Ask Slashdot: Experience Handling DDoS Attacks On a Mid-Tier Site?

Rate limiting IP addresses doesn't work when they are only hitting from any specific source IP address a few dozen times per hour. They bury you by having tens of thousands of different machines all hitting you independantly. You can be getting hundreds of requests per second and never trigger the rate limitting.

Comment: Re:Load balancing and an experienced sysadmin (Score 5, Interesting) 197

by Snowhare (#39626595) Attached to: Ask Slashdot: Experience Handling DDoS Attacks On a Mid-Tier Site?

The essence comes down to two things. Neither is particularly complicated in principle, although getting it right can be a bit fiddly.

1) Detect attacking IPs.

HTTP Flood DDOS bots aren't (at least not yet) smart enough to look and behave EXACTLY like people using web browsers. They do wierd things like load web pages repeatedly while never loading images/running javascript/loading CSS stylesheets. They make sequential requests from the same IP address - but with different user agents. They might load a web page that uses cookies - but never return the cookies that are set. Or they might return a cookie - but from a different source address or with a different user agent. They might send user agents that haven't been in widespread use in half a decade. They might not set the 'referer' header, or some other header that a browser DOES set correctly. They probably don't follow HTTP redirects. What you are looking for is any behavior that distinguishes the good traffic and the bad traffic.

So I 'tailed' the web server log and analyzed it in one to ten minute chunks to detect abnormal accesses. All detected addresses were added to a persistent database of blacklisted addresses.

2) Add the detected attacking addresses to an efficient firewall.

A naive firewall blacklist might try to just put each addresses in one big long list. This doesn't scale well beyond a couple of hundred attacking addresses. On the older machine I had, I used a 'divide and conquer' approach: I created a few hundred filter chains based on a /n subnet division of the attacking ip addresses. I then wrote a set of rules that divided incoming traffic into those chains based on the /n they were a member of. That made the number of rules required to filter n attacking IP addresses scale as about O(log n). If I had had a more recent kernel I could have used a hashed map of addresses to take that down to O(1).

After that it became a slow game of cat and mouse. The attacker would alter his attack to try and slip by the detection, I would update the detection software to detect something else he wasn't getting perfect if he managed to by-pass the filters. After about two weeks they quit attacking the web server.

The largest issue I had really was that I was starting my defense from a 'standing start': I had to write all the needed scripts from scratch while the attack was still on going.

Comment: Re:Load balancing and an experienced sysadmin (Score 5, Insightful) 197

by Snowhare (#39625717) Attached to: Ask Slashdot: Experience Handling DDoS Attacks On a Mid-Tier Site?

Having been the target of an HTTP-DDOS attack, I can tell you that manually blacklisting IP ranges is really ineffective. A DDOS botnet is comprised of thousands of machines that have been randomly infected by whatever vector the botnet operator used: Emails, web drive-by, etc. The result is that the source addresses are scattered widely with little relation between most participating addresses.

To defend against the attack, I wrote up an automatic firewall blacklisting program that detected and blocked each participating IP address individually in near-realtime. I was blocking more than 31,000 separate addresses before the DDOSers finally gave up trying to down the attacked website. Wierdly, there appears to have been no motive at all for the attack, yet they spent weeks attacking the target machine and actively trying to tune their attack to get past my filtering.

"Morality is one thing. Ratings are everything." - A Network 23 executive on "Max Headroom"