Alex, Elgg.org do have have active contact with a well regarded college in the North East USA , where research students regularly attach Elgg as parts of assignments and report their findings to Elgg. I once innocently stumbled into one blog post by some senior student whi was atcively helping Elgg with suc XSS attacks, and he was nice ebough to explain his work to me. Dave Tosh has also posted elsewhwre some remarks re: such work with Elgg and that college. I myself feel quite safe with Elgg.. ;-) Though the determines (technical) hacker weill still try s-o-o many tricks to get in...

Really, if the attack is reaching code on the server, it's already too late: bandwidth is being utilized.

There is, in fact, no way whatsoever to prevent a determined DoS attack, because you have to detect it. Once you detect it, it's already happening (since you can't see packets that haven't yet arrived) and the damage is done and all you can do is prevent a repeat from the same addresses. What you can do, of course, is detect attacks with code and then block those IP addresses... but nonetheless, you're still going to get some downtime, especially if there are enough requests that your server has very little memory/CPU time to spare.

Someone should really tell the media this so that they don't spout all that "omg surprise big sites are vulnerable to DoS attacks" rubbish.

While on this subject, I'll note that Twitter is probably particularly vulnerable because it's relatively low-traffic compared to Facebook. People post tweets. Tweets are short. So the "normal use" of the site is far, far, far, far lower than your average social network with the same number of users. There are no video uploads, etc etc. So their infrastructure is probably a lot "weaker" (read: less volume) than another site doing a lot more jobs with a comparable userbase.

Thus, any DoS attack was always going to hit Twitter harder than Facebook, even though Facebook has a lot more users - Facebook needs more "slack" than Twitter does, and as everyone knows, you don't want too much more infrastructure than you need day to day or costs rise too much.

Dagorath has a good point in the code shouldn't be the deterent for these attacks but there are things you can do to prevent attacks from making it to the code. Advanced ip filter rules can detect and refuse connections at the kernel's network level so they never make it to the code.

I'm not saying Elgg should ignore this, but that it needs to be implemented primarily at a level above, and Elgg should make attempts, but as Dagorath points out, if you're relying on PHP code to detect DDOS attacks, it's too late.

Yep. The best you can hope for with elgg is some sort of system which responds to detection and runs an sh script to add IP filter rules and fires off an email to users who need to know and can check the filtering.

(This is what Google basically does, I think. Too many search requests in X time = block that search request... as happened when Michael Jackson died.)

That sounds good enough.  I think during the initial stages of an attack, it will probably get to Elgg, assuming it is the target.  During those stages, at least if it can somehow detect an anomaly from the regular behavior pattern, it can alert an admin or kick of some script to change the IP filter rules.

Very true re: 'by the time php code gets the attack, it may too late'. A legitimate packet sent to port 80 will not be blocked by firewall, kernel, switches --> goes to the server -> php -> Elgg at which point we can only analyze (later) to try build a defense. [  I found this interesting post -- http://staff.washington.edu/dittrich/misc/ddos/   -- be worth reading  ]

@drup the link seems broken - could you plz repost?

(1)    Spell my name correctly lolz ;-)

(2)    cut/ paste the url - it will work -- because their server must be detecting referrer as elgg.org, gives "404" ==? blocking non wash.edu referrers ;-( happens on my own server too because I have blocked foreign referrers on everything [ hotlink-trap ;-) ]

@dHrup (1) oops %) (2) thx a lot ;)

We plan to use Elgg for our medical network faces.doccheck.com. I asked my friends @ php-ids.org to help us with some crucial security issues, but they're very busy the next 3-4 weeks. So you might want to take a look at their PHP-Intrusion Detection System in the meantime...

LOLZ ;-)
you meet my low-life level sense of humor ;-)

TO ALL OTHERS:

I suggest you all look up those URLS GW has posted - interesting stuff.
I'm gonna be reading this sucka and download and swing this php-IDS thingy..
Meanwhile.. I would encourage all serious elggsters who have any know-how
re: cracking/ trying to crack PKGs such as Elgg to share.. preferably via private
messages -- so that we can *collectively work out better security.
One day soon... Elgg *will hit a higher, more main-stream market penetration :==
*then we better want Elgg to be impenetrable...