All file permissions changed to 755 -- not by me


gunzip -c ~/logs/WWW.DOMAIN.COM/http/access.log.2012-02-15
| awk ‘$4~/15/Feb/2012:2[23]/{a[$7]++}END{for (i in a) {print i}}’

That proved much more useful than my messing around. Actually, I was surprised to find .2012-02-15 since I only keep default 3 days, but it was there so I copied it for safekeeping. Your awk emitted 11,338 lines for that time range. I grep -v’ed it for mathtex and mimetex (the two math cgi’s), which boiled it down to … 54 lines.

What really stands out is that I had a long-forgotten phpBB2 bulletin board for people with questions about those math cgi’s, but disabled it (rm’d the posting and registration scripts) several years ago, after spammers starting relentlessly registering and posting garbage (somehow they got past the gif image with mangled letters they have to enter before registering). But I left the bb there for reading so I could point people sending me email questions to already-written answers.

And included among those remaining 54 lines are

posting shouldn’t even be there. Anyway, I tarballed the entire directory tree and rm r-'ed it.
I also grepped the original log for that sid=, finding six strings of the form - - [15/Feb/2012:22:36:13 -0800] “GET /posting.php?mode=newtopic&f=2&sid=959d73b7b03903c6030f7cdaa13450e8 HTTP/1.0” 404 420 “” “Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR 1.1.4322)”

That 404 suggests to me he got nowhere, but I don’t know enough to be completely sure about much of anything regarding this kind of stuff. I added 1.161.141. (apparently some asia-pacific company, Chunghwa Telecom) to .htaccess for good measure. Can’t think of anything else to do about it, assuming it was even anything malicious in the first place.


Well, there’s suspicious activity in a php-based app that may be outdated (you didn’t mention that). Given that the time is close, I would suspect maybe there was an exploit around that time. I would look very carefully at the logs around 23:00 and see what you can dig up. And at minimum, update that app and lock it down!

It’s been an interesting search… good to hone the skills a bit :stuck_out_tongue:

ps: 4m hits per week? 300k+ inodes. On a shared server!? Your site would never work on most other shared hosts I’ve looked at. DH’s generous resource limits, especially for highly efficient sites as yours appears to be, is what keeps me here.

pps: all your images are giving errors now… red boxes with error message #10 or something


Yeah, I’ve rm -r’ed the entire app. I’d forgotten all about it, despite that its home directory must have scrolled past my eyes many times. And some other guy (some russian ip)… - - [15/Feb/2012:23:00:07 -0800] “POST /phpBB3/includes/index.php HTTP/1.1” 200 4040 “” “Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.10.229 Version/11.61”
…was messing with it at exactly 23:00. The 200 for index.php was expected and presumably benign. But, in any case, the app’s gone for good, now. And so’s 95.182.

DH’s limits are indeed generous. I moved the site from my new york city isp,, whose limits are way insufficient. (I still forward email there, though, since their shell email and procmail filtering provide much better control.) By the way, for the record, note that my cgi’s are totally free, and the source is all gpl’ed – I don’t make any money off anything I have on the web (except, hopefully, my resume:).

Thanks for the heads-up about those errors. Fixed now. Somehow the cache directory itself had been chmod’ed 644. I wonder if that was a side effect of when I tried chmod 644 * from >>inside<< the directory, and bash complained that it couldn’t expand the *. Maybe there’s some weird bug with that side effect when it fails like that.


[quote=“forkosh, post:23, topic:57034”]And some other guy (some russian ip)… - - [15/Feb/2012:23:00:07 -0800] “POST /phpBB3/includes/index.php HTTP/1.1” 200 4040 “” “Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.10.229 Version/11.61”
…was messing with it at exactly 23:00. The 200 for index.php was expected and presumably benign. [/quote]

I was curious why a file named index.php would be requested from a directory named “includes” as the convention is that files that are included would not be requested by a web browser. In the latest version of phpBB there is no index.php in that directory - a blank index.htm is found instead.

If I were you I would check the /phpBB3/includes/index.php file for backdoor code that might have been added to it. The fact that the status code is 200 simply means the web server had no problems with the request; it says nothing about whether or not such request was malicious in nature and it should not be presumed to be benign without considering why this file would be requested and what code would be executed. Any files being requested that should not be are a red flag.


[quote=“Atropos7, post:24, topic:57034”]I was curious why a file named index.php …[/quote] The entire phpBB directory, and all subdirectories, have been rm -r’ed, and I even deleted the associated mysql databases from the “panel”. I think that particular problem’s probably all gone. I hadn’t been using that application in years, anyway.

I forgot to separately thank you for all the help tracking down this … whatever it is/was/will-be. Assuming, of course, it has been tracked down; who knows?. And assuming it was a hack by that guy, is there a list anywhere of ip addresses that dreamhost users have already found annoying? I added deny from 95.182. to .htaccess after the fact, but would have preemptively done that had I had a n earlier clue.


I think the general consensus is that IP-based blocking is basically worthless unless you are blocking a known spam provider or suchlike. Hackers will generally hide behind proxies and it’s trivial to switch to a new IP address. You could block all IPs beginning with 95.182, but assuming that block has been assigned to an ISP, you’d be blocking 65,535 other, likely legitimate, users.


Now you’re spamming. Once is enough.

um, checksums and regex are nothing new.


Perhaps a beginner’s question, but what should Wordpress folders and files be? I was told 755 was safe, but I’ve been hacked, so clearly that’s not the case.


I believe you can set it to 700 and it should still work. 755 is generally standard and unless you have some evidence to show that your dirs were set to 755 and were breached because of those settings, I’d be hesitant to accept that 755 is not safe. It’s most likely that the code was injected via insecure programming in some theme or plugin or app, then that new code was used to do nasty stuff to your account. The dir settings likely had nothing to do with it.