777 = Any Virus, Any Worm, Anytime by Anybody!

[webwitch]

For the second time in less than 2 months I've found a Linux Virus installed in IndexU's 777 permissioned theme directories on my server. The first time I saw them, I removed them and took note of where they were; but did nothing more. But after the second time around, I've decided the presence of those files in these directories is no fluke.

Someone outside the server is CLEARLY targeting those specific directories and uploading files to them because they KNOW they're set with permissions of 777 -- which is exactly the way Nicecoder recommends they be setup! Looking again at those directories now, I'm asking myself exactly WHY do they need to have 777 permissions on them and why in the world is it that IndexU and NiceCoder is the only software product and vendor I know of who recommends file and directory permissions so loose and unlimited?

Can someone explain to me in words of one syllable why I need to have the permissions on those directories set to 777? Is that really necessary? Also what would be the likely downstream impact of changing those permissions to something more conservative and secure -- like 755?

Thanks!

[Bruceper]

So lets answer this in two ways, somewhat technical and super easy to understand for non technical users.

First understand that I'm not trying to be condescending at all. What I"m about to tell you is simply the blatant truth.

First the "super easy to understand for non technical users" (I'm gonna trademark that lol)

What's the issue? Your host sucks, find a new one.

And now for the somewhat technical answer

First we need to know why IndexU requires write permissions (777) on directories. When you create or upload a directory to a typical webserver, it has 755 permissions. Simply put that means that the directory can be read, but no one can write to it.

When you change permissions to 777, you allow other files (and users) to write to that directory.

IndexU writes to many directories such as /templates_c/ (for cache files), /cache/ (rss caching), /backup/ (to save a backup of your database), /sitemap/ (to write your sitemap), /upload_files/ (to save uploaded files to) and your themes directory (so you can add pages or upload new themes via the admin panel).

At a MINIMUM, you MUST allow write permissions to /templates_c/ and /cache/ or IndexU will not function AT ALL. This isn't an option, it's a requirement. If you don't, IndexU won't run at all.

So what's the issue then? The issue is that when a directory (or file) has 777 permissions then it is vulnerable (ONLY ON A VULNERABLE SERVER) to "hacking".

I say hacking in quotes because it's not hacking, it's just some loser who is exploiting a security flaw in your hosts server.

The issue is NOT IndexU's issue, rather it is the HOST's issue. Lets first get a very basic understanding of what 777 means.

Unix file permissions work on numbers, I'm not going to explain them all, just the basics we need to know here. There are three numbers which each correspond to a different user. Those users are User, Group and Other.

7 means read, write and execute

777 means that you will allow the User, Group and Other to read, write and execute

So who are these users?

User is the owner of the account, meaning you. If your login was webwitch then when you log in via FTP you should see "webwitch" beside the files as the "owner"

Group is the group that the owner belongs to. On some systems you could be the only user of a group, on some servers there could be thousands of users in a group.

Other essentially means the world. And in the Unix universe "world" means everyone (or file) on the server that has permission to write to files.

So 777 permissions allow write access to basically everyone. Now hold up there before you start *****ing that 777 is a security risk. It's only a security risk on poorly set up servers which is what you just so happen to be hosted on.

Now the issue comes from the fact that your host is allowing anyone on the server to essentially break out of their home directory and do whatever they want on your files/directories. If your host was running phpsuexec or suPHP then this would NEVER be an issue.

Running mod_security would also help of course.

The solution, get a better host.

[FSGDAG]

Install phpsu.... Directories get 755 / Files get 644

Mine answer was very short and sweet... But I like Bruce's a whole lot better! LOL

[webwitch]

...What's the issue? Your host sucks, find a new one.

First, I am the server admin and own and control this server. So, if the server's security isn't strong enough, there's no one to blame but me and that ugly dude with one eye in the middle of his forehead behind me. I AM trying. Please don't burn me at the stake or tar and feather me because I'm ignorant. Even after 41 years in IT, I admit I'm still learning. The day you stop learning is the day you die in our business.

So, though I've admined Unix, AIX and Linux servers for almost 20 years; this is the first time I've ever had to configure one completely from scratch that exists in an open Internet environment. Always before I was either working in a protected internal and basically secure environment or I was taking over a leased dedicated server that had been pre-configured by a server provider.

I'll be the first to admit there may be things I overlooked here. But I'm trying hard to watch for issues. Since I've seen THIS particular issue raise its ugly head in the Indexu Directories twice now, I naturally came here looking for advice.

ROFLMAO! So, my server and hosting suck, huh? Well, please accept my sincere apologies (I mean that) for not being the Lord God Almighty among server admins. I admit I'm not playing with a full deck; but would respectfully point out that for every one of you omnipotent and omniscient techno-dieties in the universe there are thousands of "pedaling and learning as fast as we can" schmucks like me out here who are struggling to make a living and fighting the cyber wars while we learn.

I admit we struggle to learn from Gods like you even when you make fun of us and amuse yourselves by kicking over our carefully-built sand castles. Omniscient we're not; but we try to be good-humored and learn from our blunders while you enjoy mocking what we fought so hard to build. I'm not perfect; but I'm doing the best I can.

It's gratifying to know I've gotten to where my server and hosting services only "suck". That's progress. Thanks for the compliment!

Now that we've gotten the kudos to my server admin skills out of the way, perhaps I should explain I have many other php and perl apps installed and running on the 25 sites hosted on my dedicated server -- including both vbulletin and vbportal but IndexU is the ONLY one of those apps that INSISTS it must have a long list of well documented and publicly accessible directories with permissions set to 777 in order to work properly.

I hadn't planned to do so; but are you suggesting I should write to all my other software suppliers complaining their products clearly don't WORK because they require no directories with permissions set to 777 in order to operate? Can I quote you on that, Bruce? LOL!

"...the issue comes from the fact that your host is allowing anyone on the server to essentially break out of their home directory and do whatever they want on your files/directories. If your host was running phpsuexec or suPHP then this would NEVER be an issue.

Running mod_security would also help of course."

Okay... I hear you suggesting I should be running either phpsuexec or suPHP and possibly mod_security to "solve" this issue which you seem to define as:

"...your host is allowing anyone on the server to essentially break out of their home directory and do whatever they want..."

LOL! Okay, there you go speaking in that god-like tone again. {prostrates himself on the ground in imploring fashion...} Would you deign to enlighten this mortal, oh mighty one? How IS the protective magic cast by these spells supposed to work? Are they mutually exclusive or is their effect synergistic? Do I need all three spells or will one or two of them do? Is an eagle feather required to make them work or will my usual buzzard and roadrunner feathers work just as well?

I'll be glad to implement any improved PHP security methods you recommend if you believe they'll stop this sort of exploit; but omniscient-sounding statements about how suphp, and/or phpsuexec and mod_security "of course" might help protect a server from the insecure file and directory permissions required by IndexU really aren't helpful when trying to pick the best way to protect the server.

I'm looking for guidance -- not the indignant mutterings of an irascible wizard who can't be bothered with the concerns of mere mortals. Am I barking up the wrong tree here?

BTW, for the official record, my server only sucks on alternate Tuesdays. The rest of the time it gives hand jobs!

Thanks for trying. Again, I'm sorry for being such an ignorant dirt-bag.

[webwitch]

Install phpsu.... Directories get 755 / Files get 644

Mine answer was very short and sweet... But I like Bruce's a whole lot better! LOL

But if all directories have permissions of 755 and files have permissions of 644 the problem I'm complaining about completely vanishes even without the phpsuexec, doesn't it, Frank? Or am I missing something here?

[linksor.com]

make your directories in theme 777 but files 666.

[Bruceper]

I apologize if you may have been upset with what I said but server security is a pain in the arse. I'd also like to point out that while I may know some things, I don't know everything about it either. I'm also not a linux expert, for a lot of stuff I still need to read the manual or find a tutorial. Most of the things I've learned by accident or trial and error.

Please don't burn me at the stake or tar and feather me because I'm ignorant

Absolutely not trying to burn you, unfortunately my statements are a hard truth for ANYONE who wants to run a server. I've seen hosts with million dollar budgets do MUCH worse.

Don't take what I said personally, it's hard to keep a server secure. Even harder if you also have clients on the server as well. I don't know if you have clients, and for this post it doesn't really matter. What does matter is where the issue is coming from.

One other thing you need to know is that i'm not just answering you. I'm answering for EVERY user who has this issue now or in the future that finds this thread.

Now this is the part where I need to tell you something that you don't want to hear. There are a few possible options so you need to determine which one it is. The reason this is happening is because

1) One of the users on your server is doing this to you.
2) One of the scripts on your server has been exploited
3) Someone has gained root on your server

It IS one of those above items. And it's a ***** to figure out which one it is. So lets go through the list with possible solutions

1a) No other users? Ignore this one
1b) Yes you have other users. Do they have telnet/ssh? No? ignore this one
1c) Yes you have other users. Yes they have telnet/ssh access. Remove access. NO ONE but root needs ssh access.
1d) Yes you have other users. Do they run ANY script? Yes - See #2b

2a) Do an audit of all php and cgi scripts that you own. Upgrade ALL of them to the latest version.
2b) Do your users run scripts? You might need to snoop in their directories to find out because they may not be publicly accessable. Force the user to upgrade, if they won't upgrade then remove them.

3a) Scan for commonly known issues such as rootkits. cPanel includes a utility to do this (it's not that good though)
3b) Check logs to make sure they're nice and long and only have your IP address. Is the log short? You've been owned. Time to seek professional help.
3c) Change your root password to something that contains lower and uppercase letters, numbers and symbols that is at least 10 characters long. 15 is better. A sample password is d8^P2=yNBkllk$!.H
3d) Remove any nonrequired features or services your server is running such as imap, telnet (require ssh to be used) lynx etc.

I hadn't planned to do so; but are you suggesting I should write to all my other software suppliers complaining their products clearly don't WORK because they require no directories with permissions set to 777 in order to operate? Can I quote you on that, Bruce? LOL!

I never said other scripts won't work, I said IndexU won't. But there are many other scripts that won't work unless they have write permissions too. Also any script that requires uploads won't work if the upload dir is not writeable.

Do I need all three spells or will one or two of them do?

phpsuexec, suPHP or mod_security. Pick one.

mod_security CAN be run in conjunction with phpsuexec OR suPHP but it's not required.

How do phpsuexec and suPHP work? They essentially ensure that all files in a home directory are owned by that user and that all files and directories are not world writeable but are still writeable by the owner.

On a typical server if a user upload a file via FTP that file is owned by the user. If that users script uploads a file, the file is owned by the script or the user nobody.

With phpsuexec and suPHP, all files are essentially owned by a user and users do not have permissions to write to files outside of their homedir. What happens is that all files have 644 permissions (no matter what!) and directories have 755 permissions (no matter what!). With phpsuexec and suPHP these files and directories ARE writeable for both you and your script. This ensures that no file or directory is world writeable. A pretty easy solution to the problem. Yes it's a bad description, but I'm trying to keep it simple for everyone.

But if all directories have permissions of 755 and files have permissions of 644 the problem I'm complaining about completely vanishes even without the phpsuexec, doesn't it, Frank? Or am I missing something here?

Yes you are missing something, because IndexU MUST be able to write to /cache/ and /templates_c/ or it won't work at all. Yes changing permissions to 755/644 will fix the issue, but IndexU will stop working.

Additional Suggestions
1) Always use the secure port when connecting to your server via password. This means if you are connecting to cpanel or WHM then you should self assign an SSL certificate and change from http to https. You can do this for Plesk, direct admin, xpanel, webcp or any other control panel you use.
2) Install suPHP
3) Virus scan the heck out of ANY computer you use to connect to your server. If you have lost root this could have been how they gained the password.
4) Sign up for platinumservermanagement.com if you have a cPanel server. They are the GODS of linux and cPanel. It costs $30 per month for one server and an additional $20 per month for any others. They will do almost anything on your server that you ask them to including installing phpsuexec or suphp and they will do a security review of the server and upgrade anything they need to. They will also install a firewall and lock down any services that are not necessary. Yes I use them, it's a lot easier to just say "do this" sometimes instead of doing the work myself.
5) Keep a log of all installed scripts and versions, including plugins
6) Subscribe to mailing lists for scripts you have installed so you can be notified of security issues

And again I reiterate that my answers are for everyone experiencing this issue, not just specifically you.

Lastly, if you want me to look at anything just let me know a URL and I can take a peek. The most likely issue here is an exploited script but as we all know, anything can happen.

The rest of the time it gives hand jobs!

Is there a lineup? Do I have to make an appointment?

[webwitch]

Thank You... For your patience, your advice and your insights. I will ponder the advice and suggestions carefully and either investigate or implement them as soon as I can.

Best,
Greg

[Bruceper]

As a note, if you sign up with platinum servermanagement, they can install suphp for you and set it up.

[FSGDAG]

Just to add my own two cents... The Server Management idea that Bruce suggests is a very good one!

Not everyone knows everything... And the hacker / scum bags always seem to be one up on us. With a Server Management team, not only will you have your own knowledge and expertise, but you'll also have a team of people that speaclisize in this area.