does your webserver host any other sites?
Printable View
does your webserver host any other sites?
htaccess files can affect all subdirectories, so you need to check from the web root down. On ubuntu your moodle may look like
/var/www
/var/www/moodle
etc.
You should check from /var/www down (assuming apache is configured to /var/www as webroot).
If you can log in to a shell (command prompt) then you can use grep. If you still don't pick up anything in /var/www, check /etc . You will need to run grep with elevated permissions (something like) :
cd /var/www
sudo grep -R -i <searchstring> *
(running from the root (cd /) will take a long time but will find the culprit unless it's in the database).
Ah... I meant to look up grep but I got sidetracked - it looks exactly what I need to do. I can open a shell so that's no problem, at the moment I'm running:
grep -rl "string" /path
.... Hopefully it will find something
My Ubuntu server is also hosting our website & intranet, both of which seem OK.
Thanks for your help
The 'sudo' bit is the only bit I know!
AH... I'm starting to get a grip of this now. The problem was/is partly .htaccess files.
The reason I wasn't finding anything nasty in them is because I was looking in the wrong place!
I've been looking at htaccess files and NOT .htaccess files. I didn't realise that the '.' signifies the '.htaccess' file is hidden. Once I had this error pointed out to me, and started looking properly using 'ls -a' from the command prompt I found the dodgy .htaccess files straight away and deleted them.
So I'm starting to chip away at this but I've got another problem. The .htaccess files I have deleted keep coming back! I'm fairly sure they are being regenerated by one or more PHP files. I've found two likely candidates, both of them have 1969 as the last modified date!
Makes sense, 1969 is when UNIX time begins so if a file is being created or something by something like a PHP script, it could well come up with a funky datestamp.
I don't think there should be any reason for these files to be writeable by the webserver user (probably www-data). Check that the owner is www-data and then change the permissions mask to 400. i.e.
sudo chmod 400 ./.htaccess
Or 444 would set them to be readable by anyone.
One down, one to go hey :) Generally you'll find it copies a backdoor script into a directory too (Often names version.php, or cache"insert numbers".php), these generally fire off every 30 minutes re-building the htaccess files.
Might want to try to see if you've had any php files created in last few days (created, not modified though)
Steve
There ended up being a LOT of .htaccess files & a couple of dodgy PHP files. I've cleaned up and made sure Ubuntu / Apache is fully up to date with patches etc.
The .htaccess files were being written by the www-data user, so that's something I need to look at.
I don't think I'm out of the woods yet but it's looking a lot better than it did on Monday. As I said before, the Ubuntu / web server was put together by someone else and they left a while a go. Having to dig into it has been an experience. Not an unpleasant one but sometimes finding a 'definative' answer regarding command line stuff has been a bit frustrating.
If anyone comes to this thread with the same problem, I'm happy to talk you though my mistakes!
OK, well, as predicted I'n ot out of the woods. Here's where I am
Looking in my Apache logs I can see that the file .cache_sjouns123.php was posted into /images/banners (which sits in my web directory) this file and another file in the same location - .cache_yf7ihj123.php originate from the IP address 46.183.218.163 - it is these files that are generating the dodgy .htaccess files.
The .htaccess end up being in the root of EVERY folder in my web directory.
I can delete all the .htaccess files and the two .php files and everything seems to me ok for a couple of hours, then it all starts again. There is obviously a backdoor somewhere...
I've been looking at a website that suggests running the grep command and looking for any of these words:
passthru
shell_exec
system
phpinfo
base64_decode
edoced_46esab (base64_decode used backwards to avoid detection by string searches like this)
chmod
mkdir
`` (backticks with an operating system command between them)
fopen
fclose
readfile
And the checking the files and using my judgement on whether to remove.
The .htaccess files are owned by the www-data user, a poster on this forum suggested using chmod on the web folders, restricting the www-data user so that they couldn't write to / create .htaccess files ... that's definately something I'm going to be looking into.
Is it possible to knock the server offline from the web for a bit while you do this work? That'd at least stop them being able to access.
yes. I'll be doing that today. After a week of battling with this it's looking a bit grim - I just can't find the backdoor! It looks like I'm going to have to rebuild the server which is a major pain because (a) I don't really know that much about Ubuntu / Joomla / Moodle / Apache and (b) I will copy to take the content (moodledata & website) off the infected server WITHOUT copying over the infection. Great. I'll enjoy it on one level because it is interesting but... this isn't the kind of situation where you can tinker away and enjoy it - I need to resolve it ASAP.