You can read the whole story here (and come back afterwards).

TLDR: the channel (through some javascript code) got link spammed in huge numbers.

The code – which you can find in the article I’ve pointed earlier – basically has an iframe, a form with an input tag (pointing to the iframe) and a small javascript code to do the magic.

What I’ve liked in the code is the way it sends the connection and “payload” to the irc server; via the following (combined) string.

x.value = '\r\nUSER '+i+' 8 * :'+n+ // user
          '\r\nNICK '+n+ // nick
          '\r\nJOIN #redditdowntime\r\n'
          +new Array(99).join(
              'PRIVMSG #redditdowntime :http://bit.ly/lolreddit\r\n'
          )+'';

And I like especially the last part of the payload, of which my first impression was that is creating 99 new lines and lastly the actual message as a way to wait while the server responded correctly.

Soon afterwards (couple of seconds, I swear) I realized that this snippet of code generates 100 messages to send.

Nice trick, I’ll remember it next time I’ll have to do a string repeat.

And as in any situation where someone needs to be blamed, this time the blame fell upon the Freenode sysadmins; and it was said in such a lovely way.

IN MY HUMBLE OPINION, (THIS IS MY OPINION AND NOT FACT):

Freenode is run by morons who can’t read IRCD config files. It is that simple.

Instead of reading the docs, freenode is switching to another IRCD to solve this “problem”. Well the problem is between the chair and the keyboard of the freenode admins. The thing you posted should not work at all against a properly configured IRCD. Instead REAL ADMINS with the practical skills of READING COMPREHENSION read the DOCUMENTS that describe the CONFIGURATION OPTIONS. And then they turn on the one feature invented in the 90s that will stop this dead.

But no, freenode has historically been run by people who don’t seem to exhibit any understanding of an IRC server or sysadmining. They will convert the entire network on the 30th to a new IRC which allows to ban users who send HTTP header to an IRC Server. Instead of reading the docs and turning on a certain option WHICH I WILL NOT SHARE HERE BECAUSE FREENODE ADMINS ARE IDIOTS AND SHOULD READ THE BLOODY DOCS.

Also firewalling with a pattern match on POST would’ve solved these problems too. But freenode admins are not the brightest admins.

And all of this because a Reddit user once owned a Digg user…. I can’t find the picture!

Maybe not exactly a full step, but you will understand later on why not.

In the ending of the article I mentioned that there is a wordpress plugin that does just that, it is called access log (duh) and you can download it from here. After installing the plugin and configuring it you may also want to decode the REQUEST_URI because that will help later on for analysis. Just add the rawurldecode function to the code:

$href = rawurldecode($_SERVER['REQUEST_URI']);

Another important step after installing/configuring the plugin would be to protect the log directory from unwanted visitors. I use a simple .htaccess file to accomplish the task. The following example denotes the rewrite rule I use:

RewriteRule ^(.*)$ http://insanesecurity.info [R=301,L]

If you’re a stranger towards .htaccess files you might be interested in, a short resource based article I wrote, .htaccess 101.

After a while of log harvesting you might be interested in analyzing the logs and find potential intruders/attackers. That’s when Scalp comes in.

Scalp! is a log analyzer for the Apache web server that aims to look for security problems. The main idea is to look through huge log files and extract the possible attacks that have been sent through HTTP/GET (By default, Apache does not log the HTTP/POST variable).

And this is the reason why we take a partial step, because it doesn’t support custom access log files, thus we cannot analyze POST requests. But let’s give Romain some time, as he’s working on a improved C++ version of it, which hopefully will have this feature.

Among Scalps features (options) are the following:

• tough: Will decode a part of potential attacks (this is done to use better the regexp from PHP-IDS in order to decrease the false-negative rate)
• period: Specify a time-frame to look at, all the rest will be ignored
• sample: Does a random sampling of the log lines in order to look at a certain percentage, this is useful when the user doesn’t want to do a full scan of all the log, but just ping it to see if there is some problem…
• attack: Specify what classes of vulnerabilities the tool will look at (eg, look only for XSS, SQL Injection, etc.)

The things that Scalp can find are: XSS, CSRF, SQL Injection, LFI, RFE (or RFI as some call it), DOS, Directory Transversal, Spam and Information Disclosure.

For more information you can visit the start page of the project here, or just go to the download section here. Almost forgot to mention, Scalp is a python script.

Not done just yet, Scalp works with PHP-IDS’s filters, so you’ll have to download the filter (xml) file from their website to get things working.

Enough said, hopefully Scalp will help you in preventing attackers, rather than helping you in attack forensics.

Well, enough said about that, the main issue we are facing is how to reduce the spam we get. I’m not talking about email protection, or blog protection; I don’t know how you people consider, but I think Akismet is doing a great job for blogs! I want to talk about those moments when you create a contact/comment page and want to make it spam proof.

Are you human? (CAPTCHA)

It seems to be the solution in many cases. But I’m not talking about making your own CAPTCHA, if you lack the experience. Some did it and it went from ’simple’ to imposible: take a look at RapidShare’s CAPTCHA. Instead I would recommend you to implement reCAPTCHA. Apart from the fact that you can reinitialize a CAPTCHA when you can’t read it, it has playable sound version of it for visualy impaled people. And on top of all this you help digitize old texts. As if that weren’t enough, it protects you from bots that may have surpased the other protection techniques.

The math question = ?

I bet you all have seen it, quite often used in a static equation way. I have also wrote about it on my last home of the blog in the article less spam on blogs. I think that I said enough about it there.

Javascript to the rescue!?

It may seem that the simplest and handier way to protect a form against spam bots may as well be Javascript. We live in a web 2.0 enviroument, full of Javascript effects and only a handful of people have it restricted with NoScript or something of sort. Thus we can safely use javascript as a protection against spam. Why? Because normal bots can’t parse (execute) Javascript code, even crawlers (GoogleBot, YahooBot) parse Javascript code only for obvious links, email addresses, etc.

There are two ways to do a form with Javascript: DOM way and simple dumping way. Simple is better:

<form action="target.php">
  <script type="text/javascript">
    document.write('<in'+'put type="text" name="human" />');
    document.write('<inpu'+'t type="submit" />');
  </script>
</form>

The concatenation of the strings is needed so that the bots can’t match it against there usual input regular expressions. I used this type of protection for displaying my email address on the About page, although could have used MailHide also. Didn’t want to bother my readers that much.

Conclusion

Actually it’s totally up to you to choose one of the above. CAPTCHA would be the best, but in some particular cases there is no need to bother your users so much, check my previous example.

Update: Hide email address in source code