help...please? php processes overloading my host

[dawn]

My host has just suspended my site. They said there is a problem with the php and that somehow their servers are being overrun from my account.

They said there is a security issue with the php. Has anyone else had this problem?

I'm on 1.4.1 (is that the latest one?).

[Box Brownie]

Hi Dawn

Not help but I see that you are on Lunarpages like me.

I have test installed Pixel Post and it runs fine (as far as I can tell) it certainly did not give me the tweaking headaches I had trying to use gallery menalto.

Lunarpages have adopted suPHP which is very secure but does give rise to issues involving some scripts. With Pixel Post I am concerned about chmod'ing the image folder to 777 - I have found that it seems to work set to 755 but Raminia (developer here) advises it must be set to 777 ~ what will braek if 755 is used?

However, in the hope that it will help other help you here is what LP says about suPHP.

----------------------------------------------------------------------
Here some usefull information regarding they way our servers run PHP.

At Lunarpages, our servers are setup to use suPHP to parse php pages as CGI.
If you are running a PHP-based script on your site and are receiving a 500
and/or 404 errors on your pages, it is likely you have one or more of the
following occurring:

1. The permissions on some of the folders or files are 777 or 666. If this is
the case, change them to either 755 or 644 in Cpanel's File Manager (or using
your local FTP client).

2. The files and/or folders are not owned by you. Certain applications having
been run under php as an apache module may have files owned by the apache user
of nobody. An indication that you don't own the files would be if you are
unable to change their file permissions. To correct this, please provide your
username or domain name, and provide the location of the folder or files that
need to have your ownership.

3. Your .htaccess file has php_values or php_flags in it. This causes a 500
Internal server error when attempting to execute the script.

The php_values and php_flags will need to be removed from your .htaccess file
(please make a backup of the .htaccess by copying its contents and saving it
on your desktop as htaccess.txt). Take the contents removed from .htaccess
and place it into a file you create called php.ini. Remember to remove the
php_flag and php_value part before the directives as php.ini files do not
require those in front of the values. You can always make the changes and ask
us if the changed files are correct.

Because php.ini values are not shared across directories, you would need a
separate php.ini file in each folder that has .htaccess or that requires the
php_values or php_flags. In order to avoid doing this, you can place a line
in the .htaccess file in your public_html folder to have all values in your
public_html php.ini to be shared across all folder. This line would be the
following:

suPHP_ConfigPath /home/username/public_html

Finally, to explain in depth why suPHP requires these changes to the file
permissions, please note that suPHP runs scripts with the permissions of their
owners. Regular PHP executes scripts under the permissions of the system user
running the web server, which means that your script runs with different
permissions than your own user account and makes it very hard to use a PHP
script to modify and create files without giving everyone on the server access
to your files (this means that on regular PHP you provide write or execute
access to group and world even for some files). Since SuPHP makes your PHP
scripts run with the same permissions as your regular user account, you do not
need group or world write access or execute access for files and suPHP will
even prevent files from running that are group or world writable or executable
as a security precaution.

666 equals the following:

Code:
Mode User Group World
Read 4 4 4 (all checked)
Write 2 2 2 (all checked)
Execute(none checked)

This makes group and world able to write to the file, a security risk

777 equals the following:

Code:
Mode User Group World
Read 4 4 4 (all checked)
Write 2 2 2 (all checked)
Execute 1 1 1 (all checked)

This makes group and world able to write and execute the file, a very large
security risk.

Basically, suPHP is more secure, and preventing scripts from running as 666 or
777 prevents group or world from maliciously writing to the files and hacking
your scripts.
-------------------------------------------------------------------------------

As Pixel Post does not use htaccess I do not think there is a an suPHP issue here.

Have asked LP support what specifically on your site is causing their concerns? I know from threads a while ago that Movable Type was an issue and some Bulletin Boards are 'banned' because of secuirty related problems.

HTH :)

PS I look forward to others answers here.

PPS My test Pixel Post is on LP neptune server if that helps when you talk to LP support.

[dawn]

I've been using pixelpost since December and haven't had any problems (well, except that I get spammed too much but that's not a pp issue).

They said there is a hole in the php security.

I just checked the permissions and they are set at 664.

The rest of the stuff you're talking about is WAY over my head. I don't know php or server security issues.

The errors that they are giving me are these:

Hello,

Your account is utilizing excessive resources, causing a significant
degradation of services on the server. This is a shared environment and we
can not allow one user to utilize the majority of the resources on a
server as it affects all users adversely. Because of this, you have been
temporarily moved to the Sputnik server. A detail of the problem is shown
below. We have suspended your account at Halley as it spawned mutilple php
processes. I had a look into your logs on which files are being accessed
when the account spawned mutilple php processes causing the load at halley
to spike from a normal of less than 5 to 100+. Below are the logs and
usage
listed.

83.205.135.239 - - [13/Jul/2005:11:21:54 -0700] "GET
/photos/index.php?x=ref HTTP/1.1" 200 12458 "http://financing.host-c.com/"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Wanadoo 6.1; SV1; .NET
CLR 1.1.4322)"
72.21.52.50 - - [13/Jul/2005:11:22:34 -0700] "GET /photos/index.php?x=ref
HTTP/1.1" 200 1163514 "http://phentermine.cfu.com.br" "Mozilla/4.0
(compatible; MSIE 6.0; Windows 98) libwww-perl/5.79"
72.21.52.50 - - [13/Jul/2005:11:22:44 -0700] "GET /photos/index.php?x=ref
HTTP/1.1" 200 1163514 "http://vicodin.free-websites.com" "Mozilla/5.0
(compatible; Konqueror/2.2-11; Linux) libwww-perl/5.79"
201.129.56.27 - - [13/Jul/2005:11:23:08 -0700] "GET /photos/index.php
HTTP/1.0" 200 6458 "http://webcam-strip.xadulthosting.com/" "Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7"

07-12-2005
============
girl-inchoate.com
Top Process %CPU 99.9 /usr/bin/php
Top Process %CPU 99.0 /usr/bin/php
Top Process %CPU 88.5 /usr/bin/php

07-13-2005
============
girl-inchoate.com
Top Process %CPU 78.1 /usr/bin/php
Top Process %CPU 72.6 /usr/bin/php
Top Process %CPU 69.1 /usr/bin/php

[Box Brownie]

My knowledge is poor so I hope others will help but what I do see is that the URLs they report in the log are not ones I personally would visit ~ drugs ; finance & adult webcam.

Now, I remark not as judgement but those referrer links in the log, are they off your site or has your site somehow been hi jacked because it may not be Pixel Post that is the issue but something else about your site design/function.

Hope you get it sorted.

:)

PS Was it just the notice you got or have you asked for their guidance at LP?

[dawn]

Box Brownie, they are coming in via my pixelpost blog. I don't visit those sites, either, but they visit me...and are totally slamming my account.

I just brought down a dedicated server...that's how bad it is.

[Box Brownie]

Hi Dawn

If you are on an LP Dedicated server I would like to hope that LP support could be a little more pro active in working on a resolution with you. Iam only on a Shuttle shared server account and I have found the LP support when needed 99% excellent.

The way you descibe the issue (ignorant comment next) makes me think of the DoS (Denial of Service) attacks one sometimes reads about where multiple hits or redirects flood an account/site/server bringing it down.

I hope that Pixel Post dev team can give you whatever help from their end and that LP can do their bit - best of luck.

:D

[dawn]

BB...I wasn't on a dedicated server. They moved me to one because these attacks brought down the server I was on (with hundreds of other sites). Then I brought down the dedicated server.

Lunarpages said they can't really do anything.

If I don't get help on the forums, I'm going to have to delete my photoblog and start all over (which sucks of course).

[Box Brownie]

Hmmmm!!!!

What is it about a photoblog script/program (Pixel Post or others) that leaves it open to such attacks. :cry:

I hope the dev team can chime in and advise!

If photoblogs in general or Pixel Post in particular are a security risk LP will end up banning it/them - not good news especially as I am jsut getting used to Pixel Post and want to make it work for me. 8)

I am sure it is academic but what template were you using?

:)

[dawn]

Thanks, BB. I'm on the Shuttle program with LP, as well, and have always found them to be excellent. I have 3 accounts with LP right now. I did go through their support system and then finally called them to get help and that's when they told me that there was a hole in the php security.

They told me to contact the php developer so I came here.

I'm using the old grey template that has been modified.

[Box Brownie]

Dawn

In the absence of others commenting do check this thread

http://pixelpost.org/forum/viewtopic.php?t=1252

It is obviously a known issue (?) and I for one intend to re read the thread and add some of the spam stopping changes.

If you scroll down to raminia's post of the Mon 30th May - I think that is the easiest most straightforward 'blocker' that stops the use of the referrer function (as I understand it) in Pixel Post.

Based on a quick read of that thread I would think they should make the referrer function a user choice 'on' or 'off'.

HTH :)

PS I have modded to use ramina's workaround but I found this last entry by Connie here http://www.pixelpost.org/forum/viewtopic.php?t=1354&postdays=0&postorder=asc&star t=0

For making a permanent change to not use the referer 'function'. Must get some shuteye now but I think i will use it myself. :wink:

[riken]

Yeah your acount was suffering from referer spam. Also there might be an issue with database performance when looking up referers records. That might be what your host was talking about.

All these things will be fixed in 1.4.2.

For now, read http://www.pixelpost.org/forum/viewtopic.php?t=1252 to find out how to turn off referers.

[riken]

Forgot to mention:

What your host is saying about security concerns, is a load of BS. The referer spam is causing your processes on the server to take up more resources than normal, but won't cause the server to be hacked.

If you don't want to wade through the long discussion on referer spam linked above, and you just want to turn off referers, make the following modifications to index.php:

1. Insert this after the last require line near the top of the file:
if ($_GET['x'] == "ref" || $_GET['x'] == "referer") {
exit();
}

2. Comment out the following line:
//book_visitor($pixelpost_db_prefix."visitors");

This will completely disable referers. They won't be recorded in the database and you won't be able to visit the referer page anymore. This will also turn off visitor counting so you won't be able to count the number of visitor to your site.

Hopefully this stopgap will be enough to satisfy your host provider. Pixelpost 1.4.2 should have better methods of dealing with referer spam but for now this should work.

[raminia]

I had similar report on one of my friends too. about 1-2 Gig transfer over a single night!

referer page is eliminated in the next release. use ban IP's and .htaccess and other stuff in cpanel to stop the current spams. comment out the link to referers page too.

[dawn]

I don't understand what "comment out" means. Do you mean delete it?

Thank you all for your help. I appreciate it greatly.

[raminia]

yeah delete it from the template.

[riken]

Yeah, deleting the line works.

Commenting a line means adding // to the begining of the line (in PHP, and a whole heap of other languages). Comments in code are things that aren't run by the computer, so you can put whatever you like in a comment.

So I meant changing the line from:

book_visitor($pixelpost_db_prefix."visitors");

to

//book_visitor($pixelpost_db_prefix."visitors");

[dawn]

Thank you, riken.

My site just came up (and on a temporary server...they want to make sure it won't spike again).

I've cleaned out my tables according to the post you all shared. I've applied a fix blinking8s gave me. My pages aren't coming up but so far so good as fara as no referrers popping up.

Hopefully all will go well soon.

I just wanted to thank all of you for your help. I was so distressed by everything and I felt like a piece of me was missing.

[dawn]

YAY!!! I got it working. I used ALL of your suggestions. I COMMENTED OUT (I just love using new terms...heh) the referer comments. I updated all of the referrer words in my spam list. I uploaded new code from blinking8s.

Hopefully that will work.

My happy little site is running again.

Thank you ALL for your time and generous help. I was beside myself and you guys provided some welcome relief (and a few smiles, too!).

[Connie]

Dawn,

congratulations! And thank you for your patience!
Your problem proofed once more the emergency of the spam-situation and that is why we will release the version 1.4.2 today or tomorrow with features integrated to get rid of the spam better!

I hope you can relax and concentrate on photos now!