Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Submission Summary: 0 pending, 29 declined, 2 accepted (31 total, 6.45% accepted)

×

Submission + - Apache webserver vulnerable to "slow get", too 5

mcrbids writes: About a month ago, a story broke that http (apache, IIS and everything else out there) was susceptible to a "slow post", where a malicious client starts a connection to a web server, sends headers indicating a very large upload via POST, and then sends that upload very slowly, starving resources and eventually causing a DDOS.

Well today, doing some research to see how effective this attack was (hint: VERY EFFECTIVE) I tried the same thing using http GET as well, and saw very similar results. With a simple, 20-line PHP script run from my laptop, I was able to take a fairly beefy internal webserver (8 core, 12 GB RAM, CentOS 5) offline in just under a minute, and keep it that way for as long as I wanted to. The technique was simple: send "GET /" and then append letters, 1 or 2 every second or so. After several hundred simultaneous connections were achieved, the web server was no longer responsive. I don't have an IIS server to test against, and don't feel like using any "unwitting volunteers".

It doesn't take a large botnet to take most hosts offline. It takes only a single, relatively low-powered laptop and a 20-line script hacked up in PHP 5.Given that the "slow post" attack is already well known, it's only a matter of time before a black hat discovers that even disabling form post won't protect anybody, either!

Submission + - Disable Advertising? No way!

mcrbids writes: Dear Slashdot,

This is the only way I can think of to actually send a communication to you. I noticed tonight a checkbutton labelled: "As our way of thanking you for your positive contributions to Slashdot, you are eligible to disable advertising."

Well, I'm not going to check it. I've spent years writing my often +modded posts, and have enjoyed doing it! Your adveritising is subtle enough to not detract needlessly from the experience, you get a few pennies from my daily views, and I have purchased more than one item due to an ad posted on Slashdot. It's a win/win/win situation, and I will not be checking the button, nor do I steal content from websites by using products like Adblock. If a website has ads posted intrusively, then I avoid that site, rather than legitimize a website that is offensive in nature by giving it the benefit of my eyeballs.

Thank you Slashdot, for maintaining a high quality, highly relevant site for over 10 years now! I've not paid a thin dime for any of your content, and I have spent countless hours pontificating finer points; you have more than deserved whatever revenue you get from your classy, unobtrusive ad impressions!
Bug

Submission + - Root hole found in Linux

mcrbids writes: Looks like a pretty serious hole has been found in Linux — affecting 32 and 64 bit versions of Linux with and without SELinux using a creative way to exploit null pointer references. You can check it out yourself. As of this writing, there are no patches available for this, making it a potential zero-day exploit.
The Almighty Buck

Submission + - Rockstar squelches connection to Michael Savage

mcrbids writes: "While poking around online I found this article which details an an easily verified connection between Rockstar Energy Drinks and Michael Savage the "shock jock" commonly found on ultra-conservative talk radio. Michael Savage has been banned from entering the United Kingdom due to the hateful nature of his monologues. Strangely, he broadcasts from the highly liberal San Fransisco on KNEW AM Rockstar has responded with the standard C&D route with lawyers, et al. Is this going to be another example of a company who hasn't discovered the Streisand Effect or is there legitimately no connection between Michael Savage and Rockstar Energy drinks, even if they are at the same address and share the same CFO? (Michael's wife, Rockstar CEO's mother)"
GUI

Submission + - Best javascript framework?

mcrbids writes: For the past 6 years or so, we've been heavily developing a proprietary, custom vertical application based on Linux, Apache, PHP, and PostgreSQL in a home-rolled PHP framework based loosely on Horde. We've been quite successful in the marketplace with our relatively classic technology based on HTML 3.x.

After investing heavily in fully redundant server clustering over the past year or so, we're finding that we'd like to improve our look and feel, improve response time, etc. and the natural way to do this is by incorporating javascript/ajax into our product. We've already begun some using ajax(y) in a few areas where very large tasks need to be coordinated over a long period of time — EG: longer than a typical browser timeout.

But we don't want to re-invent the wheel. There is a bewildering array of javascript frameworks, and with any framework, there's the risk of getting stuck trying to do something not anticipated by the framework developers.

So, which is the best, and why? Which should be avoided? Here are some of the frameworks I've seen so far:

Dojo, Ext JS, Fleejix.js, jQuery, Mochikit, Modello, Mootools, Prototype, Qooxdoo, Rico, and Scriptio. So far, in my research, jQuery and/or Prototype seem to be front runners, Dojo perhaps a close second.

I'd be most interested in the opinions of people who have switched from one to the other, and why?
Unix

Submission + - Turbo-charging logging?

mcrbids writes: I'm revamping our web-based application and am currently reviewing options as far as logging, particularly with redundant, clustered hosting solutions. I've run into a few problems that it seems no amount of online searching seems to have found.

My first concern is about scalability — our application writes directly to local log files. Unfortunately, many of the log entries are quite large and so cannot be piped over syslogd. Other options are much heavier, come with significant administration overhead, or bottlenecks. Is there a syslogd replacement that will allow for very large (tens of KB or larger) log entries?

My next question is about logfile integrity. A perfect log file is write-only, never rewrite. A one-way street, data goes in, gets saved, and never gets deleted. But any log file is essentially just a file, and a single # echo "" > /path/to/log will kill the log file dead. Yes, you can log remotely, but this increases complexity and therefore the chances of failure. Also, what if your remote log server is also compromised? I've been considering the use of a CD-R, especially the ability to recover from a buffer underrun during a write sequence. I've simulated a few, tying up the HDD with I/O while burning a CD-ROM. It under-ran, renegotiated, then resumed writing without incident. Why not use this capability, leave the drive in a sort of permanent under-run, and renegotiate for log entries? Wouldn't doing so create a file that could not effectively be erased, even if the host was compromised?

Slashdot Top Deals

Genetics explains why you look like your father, and if you don't, why you should.

Working...