Probably Programming

So for the last couple of weeks or so, there has been potentially participating in DDOS attacks (more likely it was sending spam, actually), unbeknownst to me until today. Well, it explains some of the server instability I’ve been having lately.

For some reason, Apache had been dying on me every few days.

I finally looked in my error.log file, and saw the output of wget, downloading a file called k.c from http://66.90.103.116/k.c (they’ve taken it down since, sometime within the last couple of hours. Perhaps they noticed my poking around at their server). Anyway, somehow they were getting in through apache somewhere, downloading this file, compiling it, and running it.

The code itself (a derivative of kaiten.c logs into an IRC server and watches for commands on which servers to attack or commands to run.

I eventually located the point of entry as a bug in the version of Roundcube webmail I was running. I was running a really old version of it (something like version 0.1 beta, I think), and all it took was an apt-get install of the latest version and the security hole is gone.

I’m going to add the news feeds of any software I’m using on this server to my RSS reader in the hopes that I will find out about such security holes (or at least software updates) a bit sooner in the future. I’ll also try to make it a habit to do a apt-get upgrade more often as well.

EDIT: I’ve set up cron-apt as suggested, so that should help me keep things up to date.

There has been some talk about and arguments against and responses to issues about using rev=”cononical” for referencing shorter URLs instead of the automated use of TinyURL when posting to sites like Twitter.

I must say that I agree with Ben Ramsey (see “arguments agains” above) in suggesting we use rel=”alternate shorter” instead.

I also like the idea that Chris Shiflett had of using a HTTP header and a HEAD request to make it so you neither have to retrieve the entire requested page nor parse any HTML. I’d stick with Ben’s suggestion, however, and make the header something like “X-Alternate-Shorter:”, rather than “X-Rev-Canonical”. What’s the harm in calling it something that actually makes sense?

The idea of using HTTP HEAD requests to solve the problem inspired me to come up with a more immediate solution to one of the problems introduced by using url shortening services: uncertainty about where a URL leads.

This problem can be solved on the client side, which requires no work on the part of Twitter (meaning this is more likely to be put into use sooner).

Since most URL shortening services use an HTTP redirect to do their job, all it takes is a HEAD request to the tiny URL in question, and then a look at whatever “Location:” header is returned to see what the real URL is. In fact, you don’t even really need to do a HEAD request in most cases, since most URL shortening services don’t return any body, since they are just redirecting you anyway.

Read on for more information and implementations of an untinyurl function in various languages.

(more…)

It’s been far too long since I’ve posted, so I’m writing a short post about a quick one-line I just used to solve a problem.

The problem was a rogue newline appearing at the beginning of some generated XML files, which is against the rules for XML.

This problem, and a similar one involving data being sent before headers can be sent, often happens in PHP when an extra newline is included after the closing “?>”. One way to fix it is to just leave off the closing bit, since PHP is smart enough to realize the file has ended in PHP mode.

Anyway, we had to track down which file had this problem in it, and the solution ended up being this:

for i in `find . -name '*.php'`; do echo $i:`tail $i -n 1` | grep -v '\?>'; done

That finds each php file and checks its last line for “?>”, printing it out if it’s not there.

Of course, there will be some false positives for PHP files which have HTML after their PHP code or don’t have the closing “?>”, but it’s good enough to track down those potentially offending files.