1. Home
  2. Forums Index
  3. Server Side / Apache Web Server 7:02 am May 2, 2026

Forum Moderators: phranque

Message Too Old, No Replies

a compromised shared server.

         

winter

11:43 am on Feb 7, 2010 (gmt 0)

10+ Year Member



Hello all,

I would really appreciate a little advice with regards to a couple of problems we're having, I'm a front end developer and a moderate php programmer and am finding myself to be a little out of my depth when it comes to server issues.

We have a small commerce site hosted on Linux/Apache, we only take about £300 -£500 a month online and started out on a tiny budget so we hosted on a shared server. Just recently I discovered an obfuscated "data" file and an injection in some .html and .php files most notably where there is the presence of a closing 
<body>
tag. It looks like this: 
<b1>--==skff4dg4gd[...]sfdfd5444f==-</b1>
. It doesn't appear to be a particularly malicious hack, but nonetheless it is a hack.

We have a second site hosted with the same provider and that has been compromised in the same way.

And so to my questions,

I've read recently a couple of quite scary statements
if you are hosted on a shared server you might as well consider your site compromised from day one


You are only secure as the least secure site on a shared server


1. My god, is this actually true?

2. I don't fully understand how Apache works, nor am I a up on Linux directory structures, is it actually possible for a malicious script to traverse across the file system accessing and writing to files and folders or would it have needed to access my account directly through a venerability? (Which I'm pretty sure I don't have, or least I can't find).

3. Is it possible to set file and folder permissions so that *Only* scripts in my account can do their work currently everything is set at 755 and some php files at 644, does file permissions help to secure anything at all? What would be the most secure settings?

4. I'm thinking that if shared hosting is so insecure maybe I should move to a dedicated or virtual dedicated server, but does that mean the security of the server is in my hands? What is the difference?

Any advice from anyone that understands the above scenario really would be appreciated, what would you recommend I do? Our host is not being helpful.

jdMorgan

9:52 pm on Feb 7, 2010 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I can't claim to "fully understand" the entire scenario as you requested above, but a couple of comments:

First, I don't know how much "obscuring" you did with regard to posting that <b1> tag, and I'm not sure if this was taken directly from a server file or captured using a 'View Page source' in a browser, but assuming that that is what it looks like on your server, then I'd be looking for a "wrapper script" -- a script that reads this HTML file, interprets or replaces that <b1> tag with something else, and outputs the result to the client. Look at the 'View Page source' in a browser to see.

I'm also not sure where you got the two quoted comments you posted. In many cases, they could be seen as hyperbole -- exaggerated for emotional impact. However, some hosts do a better job at securing sites, and configure their servers to more-completely isolate the various hosted sites' filespaces from each other.

A dead give-away of an insecure server is if you can navigate --either in FTP or in the shell-- to a location 'above' your own site's filespace, and there can see other sites' directories. If that's what you see in your case then yes, it's time for a better host. As a less-expensive option, consider hosting with a unique IP address; It's easier to do more-secure shared hosting if it's IP-based, rather than name-based.

The most likely methods used to attack your site have to do with SQL injection and/or out-of date scripts or script interpreters on your site. Make sure everything added-on to the basic Apache server is up-to-current-rev and fully-patched.

Also make sure that all of your own code is designed to validate all client-controlled input based upon what is acceptable and not upon what is unacceptable. In other words, don't try to filter out all possible 'bad stuff,' just write the code to accept only 'good stuff.' This may sound like a subtlety -- but it's an important 'philosophical' change that can make all the difference in many cases (Think through the results of 'forgetting to include something in the code' in each case).

As for permissions, set them to "400" and then expand those permissions one read/write/execute bit and one 'identity' at a time until your script works.

If you do find malicious code on your pages as actually delivered to HTTP clients, please take some care to 'break the code' before posting it here, as I suspect you may have already done above.

Thanks,
Jim
 

Join The Conversation

Moderators and Top Contributors

Hot Threads This Week

  1. Home
  2. Forums Index
  3. Server Side / Apache Web Server 7:02 am May 2, 2026