Why ?

Do you want to be an easy favorate target of criminals ?

Do we need any more reason ?

How ?

We have to know the risks associated with each elements,

and evaluate them to achive WELL BALANCED overall security.

Making lots of effort in one area and then leaving other areas is

common mistake we see so often.

 The key is not leaving any major security hole.

So, we should start talking about common major security holes of our life.

Security Holes

The biggest security hole is YOU.

There is no doubt about it.

Why we are THE security hole ?

Because we are too nice, easily convinced,

always looking for something to belive,

too insecure to verify things by yourself,

and so on and on and on and on.....

In short, we are too naive.

That's why there are so many criminals enjoying easy lives upon our losses,

including organized international crime syndicates, politicians, big companies,

and supposedly "religious" organizations !

Naive people are easily manipulated to be a fanatic follower/defender of stupid causes,

and can cast vast harm on many many innocent victims.

And it has been just like that for last several thousands of years.

Yes, human beings are a little more intelligent than monkeys.

But not much.

Oh, well. Let's talk about technical stuff

Let's start with "Web hosting" related security.

Major security problem with web hosting is the known vulnerabilities.

Many popular scripts are "popular target" of crackers, too.

They enjoy great number of user bases to maximize their attack.

Mat's FormMail.pl has been very popular target untill

all major hosting companies finally banned, modified it to secure the hole.

PHP related risks

Now, the trend is on the sloppy PHP scripts.

Since PHP has been selling itself as an "easy language",

although it's not really true, bunch of naive people believed it

and became a sunday programmer.

And they've written many scripts with "easy" security holes,

on top of PHP's own BUGs and security holes.

These PHP lovers are learning that there is no "easy way" to make

something secure in any language or any environment, slowly, as of 2005.

So, if you run one of these popular PHP application, you should know that

YOU ARE one of "popular target", and better be prepared.

Another weakness of PHP is its startup size (on some hosts like PowWeb).

When hammered by massive accesses, PHP based sites are easier to cause

slowdown of server or Apache crush and restart, or even causes site shutdown

due to exessive reasource usage.

By using Perl, or better shell script, or even better SSI or static pages,

you can reduce the risks like that considerabley,

and suffer less of adverse effects when the server gets very slow under heavy loads.

Also, smaller startup size may permit these scripts to detect

certain harmful access patterns and react automatically

to reduce the risks before loading their main big modules,

while it's too late for PHP, because just starting is a heavy task for it.

So, the choice of language isn't something you should decide

only on the bases of what they try to sell.

Stay away from PHP (in shared hosting), and you will experience less problem.

Especially, stay away from PHP/MySQL combo.

I guess PHP can be fun thing if you run own server or VPS and

you can use mod_php, with Apache2 or lightTHP, maybe.

Or it's fine if you use it for an administrative script which is tightly

secured with password and/or other means so that only a few

trusted person can access it.

Exposing big php script on shared host to general public

(and robots, attacker, spammer, what else..) ?

No thanks.

I know that it doesn't cause any problem, in generaL.

But I also know very well that you can get massive access from search engine robots,

stupid browser helper softwares, and other people, on one day,

and when it happens, startup size and all other factors will make the differences.

If you say I'm over cautious, maybe so.

But I didn't experience major problem with my site because I've been cautious,

and I have no plan to chang that.

I'd be more cautious, as a matter of fact.

Permission setting of PowWeb hosted site

Just like secureing your home machine, there are two aspects in

secureing your web site.

 1. Attack or threat coming from outside via http requests.
 
 2. Attack or threat coming from other user's account and their PHP/CGI programs.
 

You should check the configuration of your host, and set LOWEST permission

that will allow your site to function correctly.

On PowWeb, any DIRECTORY that contain simple web data (.html, .jpg, ...)

or scripts that is called by Apache (not included files)

must have permission of 710 minimum.

Any other directories can be (or rather, should be) 700.

In nother words .....

 List of files directly accessed by Apache:
 Web pages, graphics, MAIN scripts, .htaccess, password file.
 
 If a directory contain one of these or a sub directory with these somewhere below, 
 you should set it to 710.
 Otherwise, set 700.

 Exception to this rule of thumb:
 
 If you use Apaches default directory index, you have to set 750 
 to the particular directory.

Many people recommend 755 for directories.

Well, it may give lots of advantage to someone who cracked other user's account.

Why would you loosen the security when you can keep it tight without penalty ?

So, use 710 or 700 according to what the directory contains.

Now, about the files.

 List of files directly accessed by Apache:
 Web pages, graphics, .htaccess, password file.
 
 These files must have the permission of 640 
 or something readable by anyone.
 Normally, people use 644, which is fine.

Normal html pages and graphics are publicly available data,

and you shouldn't worry about its security, anyway.

I mean, everybody can get it through web access !

If you want to secure html page for some reason,

there is no way to do that unless you serve the page via CGI/SSI/PHP.

To make it accessible to the Apache web server,

you have to set 640 minimum (on PowWeb server).

And that will permit anyone on the same server or clucter to see it.

By setting the permission of directory to 710,

attacker cannot browse the directoy.

It mean he has to know the exact location of the files to read it.

But it's usually very easy to know the exact path from the URL,

and it's still relatively easy to know it even if you use mod_rewrite

to change actual file paths.

So, you can protect the access to files by password protection

and/or IP based 'deny from', mechanism, but unfortunately,

there is no way to secure them from back entry attacks,

as long as the permission of 640 (or 644) is used.

 For Perl/shellscript, set 700, or 500.
 For PHP scripts, set 600 or 400 if you want more security.
 
 And for all other data, you can use 600 (if it needs to be read/write)
 or 400 (if it's normally read only, and updated normally only by FTP).

710 on Directory with Web pages, graphics, MAIN scripts, .htaccess, password file,

and any sub directory with these somewherer below.

700 on all other directory

 Applicable to PowWeb:
 /www/U/USER/htdocs/subdomain/subdir-with-html/subdir-for-includ-files/
        710  710      710      710                 700
                   /subdir-with-html/subdir-for-includ-files/
                      710                      700
                   /datadir-no-access-by apache/subdir-for-data/
                      700                        700
                   /subdir-using-default-directory-index/
                      750                      
            /subdomain/htdocs/subdir-with-html/subdir-for-includ-files/
             710      710      710                 700
            /cgi-bin/subdir-with-cgi/subdir-for-includ-files/
             710      710                      700
            /etc/subdir-for-data/
             700      700
            /logs/subdir-for-data/
             700      700

Permission setting of sites hosted by Servage.net

As Servage.net runs mod_php and mod_perl, and the FTP user gorupe

is diffferent from nobody group, we have to make directories and files

available to "nobody", I mean, to anyone.

For all directories that contain readonly data, set them to 711.

If there is a directory that contain files with read/write access, set it to 733.

If certain application need to brows and get list of files in the directory,

you have no other choice than setting 777, which is very vulnerable.

For files, normal readonly files should be 644.

Files that need read/write access have to be 666.

Note that directories with 777 permit ANYONE to do ANYTHING to that directory,

including deleting things in it, renaming, moving, whatever !

Files with 666 can be written, appended, or overwritten by ANYONE.

As Servage.net refused to explain the security level, and more over,

refuse to discuss about it, I think their security level is indeed very low.

DO NOT USE 777/733 on directories, or 666 on files

unless you are ready to loose control of your site in the event of

intrusion or attack coming from back side.

In other words, it's safe as long as you place readonly static pages,

or CGI/PHP without any writing actions.

Also, your files should not contain ANY sensitive data because

they can't be protected from back side peeping.

NO PASSWORD of any kind, no personal info, no account information, NOTHING !

I will edit and modify this contents if Servage.net changes the opinion,

and provide me convincing technical explanation to support their claim of SAFE SANDBOX.

Similiar security concerns are shared by many hosts

who don't use SuEXECed/cgiwraped cgi/php and doing "Nobody" access on everything.

So, Servage.net isn't worse than other hosts.

But PowWeb, LunarPages? and many other hosts are much safer, in my opinion.

The site design

As I coverd in the section for PHP, the resource usage has

direct and indirect impact on the security of your site.

Construct your site as light as possible with the features you really need.

Calculate number of access required for the given page.

exmaple: mypage.php is a top frame and it loads two side frames,

left.php and right.php.

In each php page, you may have a couple of includes.

And if these includes (or fopen) contains "http:// ...." in it,

that counts for another http access.

And you may have a counter that access php driven graphic,

as well as thumbnails that are shrunk on every request by php ....

Now, you may get the idea.

THIS PAGE IS HEAVY on the server !

It requires not only lots and lots of requests to serve the page,

but also many of them invoke heavy and slow php processes !

And sadly, this type of site cu\onstruction is very common among naive PHP users,

CMS lovers, and design oriented people who doesn't care about resource usage.

Well, when you see the slow server load, don't just blame hosting companies,

but people who use these heavy page for very busy site,

and also those who promoted these stupidity for naive people.

 CPU power and memory resources are just like OIL !
 You waste it, and it will run out, sooner.

 And maybe sooner than you hoped ...

But human beings are so superior and created to be the governor of the earth that

they don't learn anything even when they are shown hard facts.

They love more sweat illusion than the simple cruel fact.

Link(s)

Yet another security tips. SecurityMemo

This page is http://Check-these.info/security.html

My main site is hosted by PowWeb, one of the best low budget host !