Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Thanks unSpawn. I understand that. I have about 100 websites running on that machine and only a handful are WP but AVG found the trojan scripts attached to one of the WP files. As you can see from my thread with Thor, the focus has been on finding the source. I only asked for help with the SED issue while I was waiting for the audit to trigger.
Sure but so far I've only seen you delete files, restart the web server, reboot the machine, delete some more files and delete a web log. All apparently without permanent results. Maybe it's time for a more structured approach? You said "I have about 100 websites running on that machine and only a handful are WP". So what software is used besides WP? Homebrewn scripts? Anything outdated and potentially vulnerable perchance?
That's my point. I perform those tasks to get a clean slate so I can try to watch the injection as it is happening.
I need to find out why they keep reappearing. The structured approach is I installed the kernel audit program and found something strange. I set the audit to watch the index file in an unused openx installation I have. Then, I cleaned all my files and let time go by. After about 20 minutes, I ran ausearch and got this...
From the log snippet, it looks like you have SELinux disabled. Maybe you don't have the luxury right now of putting it in enforcing mode, but you could set it to permissive mode, wait a while, then do a "ausearch -m avc -ts this-year" to see what kind of AVC messages turn up. You could also do a "ausearch -m avc -ts this-year | audit2allow" to make some quick inferences about what would NOT be allowed were you in enforcing mode. Later, when you get everything cleaned up, put SELinux in enforcing mode and create policy modules for your needs.
Thanks agentbiuzz. I was just thinking today of enabling SE linux. My first experiments a couple years back were a disaster (had to leave installs in standard locations, etc.) where I like to move things around for security by obscurity.
Apparently, my partner had a virus on his PC that exposed his WP password to the culprit. That culprit then logged in as admin to a wordpress site and uploaded a theme -- his own theme with compromised code. Then, he switched to his new theme for just a second that executed the code then switched back. We never knew it happened until after the fact. the code was clever enough to delete functions.php after it ran so we couldn't find it. I suppose it was luck that this morning's backup grabbed a copy.
Hope this little adventure helps someone else int he future! Thanks everyone for their help.
To follow-on to my suggestion, yes, putting stringent permissions in place does limit what you as an administrator can do to a site. But this is easily handled. Simply construct your site and manage it on an internal, inward-facing-only web site. Then, periodically, "publish it" to the public web site location by means of a script (external to WP). This script must be executed by the one maintenance user-id which does have read/write access; a user-id that is used for no other purpose. This script uses chmod to make the files read/writable to itself, then does an rsync to synchronize the directories, then it executes another chmod to make the files read-only, even to itself, once more.
This script should also perhaps use another rsync (or maybe gzip) to make a backup copy of the site before and after. Each backup that is taken is unique, and it is immediately made read-only.
It is a good idea to set the Unix permissions-mask to "no access" so that only an ACL entry permits access to anything .. and the access that is granted is strictly, "need to know, need to do." For instance, if Apache becomes nobody while running, then nobody can use the directories, and the maintenance userid of course can, but no one else anywhere can even see what the directories contain.
Database content is synchronized in a similar manner, and table permissions are likewise stringently controlled. If WordPress needs to consult a table on the production database, then it cannot modify it. And so on.