網站安全基礎

Note that it's ultimately the responsibility of the server admin to ensure his system is secure.  These are some basic security tips that can be done to help protect your system.  This is not an end-all guide for server security, admins must be diligent, but rather some suggestions for a start to securing your server.

1. At install time, the easiest thing to do is to mount your /tmp partition with the noexec,nosuid options, and mount the /home partition with the nosuidoption.  This is done in your /etc/fstab and requires those paths to exist as partitions, and not just as subdirectories of /.  If you're unsure, type:
   mount
   to get a listing of your partitions and their current mounting options.  Use google for more information on these mounting options. Be very careful when editing your /etc/fstab, as any errors could prevent your system from starting up.  Note that you must not have "nosuid,noexec" for / or /usr, as those partitions have suid binaries normally (su, passwd, etc).
2. After the system is installed, a good idea is to add dangerous php functions to the disable_functions list.  This prevents php scripts from running "raw" functions that could be used to execute programs on your system.  Note that some php scripts do legitimately require these functions to operate, so if your scripts don't run after enabling this function, edit your php.ini to remove the required functions from the list, and restart apache.  To add the disable_functions with custombuild, type the following then restart apache:
   cd /usr/local/directadmin/custombuild
   ./build update
   ./build secure_php
3. Do regular updates of system services, libraries and scripts.  It's important to keep your system updated once installed.   This is the responsibility of the server administrator.  There are several tools and options avaiable to help the admin do this.  For system libraries like openssl and other low level system items, this is left to the admin to do how he wish, usually package systems like yum or apt-get can do this for you.  For services and scripts that DA installs, you can use the custombuild script.   A typical update command with custombuild is:
   cd /usr/local/directadmin/custombuild
   ./build update
   ./build all d
   Note that in the custombuild directory is a file called "options.conf".  In this file is a list of all options you've got regarding what custombuild will do.   Regarding updates, ensure you have clean_old_webapps=yes present.  This removes all scripts from /var/www/html, after updating you do a new one.     The options.conf also has cron options to check for updates nightly, or even install these options nightly.  I recommend having the nightly cron check, and then a hand-on admin proceed with the update after he gets the notice.  To enable a nightly notice replace the following bold options with your relevant information:
   #Cron settings
   cron=yes
   cron_frequency=weekly
   email=email@domain.com
   notifications=yes
   da_autoupdate=yes
   updates=no
   webapps_updates=yes
   Then type:
   ./build cron
   These are the settings for getting nightly notices for updates, but it won't do the updates for you.
   After getting the notice in your inbox, you'd run the following from the custombuild directory:
   ./build update_versions
   to update just those items that require updating.  Note that doing "./build all d" can be simpler, but takes longer to run.
   If you wish to have "./build update_versions" be run automatically, change the updates=no to become updates=yes.  Just keep in mind that the server admin is still required to be fully aware of the system and it's state if he choses yes for this option.  The webapps_updates option only applies when updates=no is used.  It's there to still allow updates to the php scripts in /var/www/html, while not affecting compiled services.  Set webapps_updates=yes if updates=no and you wish to have automated updates of the webapps scripts with the cron option.  If updates=yes, then the webapps_updates value doesn't matter.  Similarly, using da_autoupdate=yes with updates=no, will update DA when cron is enabled.
   
4. If you're running php in "CLI" mode, then enabling both php SafeMode and open_basedir is wise.  Safemode is an internal form of disable_functions which also does a bit more checking.  See the documentation on Safemode for more info on this.   Open_basedir, which is enabled by default, tells php to not allow scripts to access files outside of the set list of paths.  
   To control SafeMode and Open_Basedir on your php CLI system (default), go to:
   
   Admin Level -> Php Safemode Config
5. suPhp is one option which some admin's like, other's do not.  What suPhp (php CGI) does is runs php scripts as the system user of the account, rather than the "apache" user.   This solves many issues like permission/ownership when a php script uploads files.  It also allows an admin to track down rogue scripts more easily as it's not running as a generic user.  Another benefit of suPhp is that you can chmod your php scripts to 700 instead of 755.  This makes them more secure in the case you're storing passwords in your scripts.   Drawbacks to suPhp include a slight slowdown in performance since there are a few more hoops to jump through to have php run as the user instead of "apache".  Also, the items in point 4) above have no effect since suPhp does not monitor VirtualHost php flags.  All settings must be done in php.ini files.  Note that you can have per-user php.ini files to allow per-user settings, see this link.
   
   To enable suPhp, see this guide.
6. If you don't plan on doing any remote access to mysql, then setting up mysqld to only listen on 127.0.0.1 would be a good idea.  Note you'll have to keep this in mind if your users start asking you why they can't connect to mysql from a remote location.  To set mysql to only bind to 127.0.0.1, add the following to the [mysqld] section of your /etc/my.cnf, then restart mysqld:
   bind-address = 127.0.0.1
7. One filtering option for apache is mod_security.  This is not part of our installation, but mod_security is an apache filter which checks all http requests sent by clients to ensure they're valid.  Note that if not setup correctly, it can break frontpage, or other php scripts that often have long URL requests, so proper setup and testing would be important.  Check our forum for guides on this, it's not covered by our support.
8. A firewall is always a good idea.  Many people use CSF or the block_ip scripts.
9. Set the User's domains directory to block other Users on the system from seeing in:
   http://help.directadmin.com/item.php?id=254
10. Setup your named.conf to not allow recursion.  This should be done by default now, but check anyway with this guide.
11. Prevent Users from using weak passwords by enabling difficult password enforcement.
12. Prevent Users from creating subdomains belonging to other Users with this option.
13. If you're using DirectAdmin with SSL, it's a good idea to force all SSL connections to use TLS instead of other older SSL protocols.
14. To add another layer of security with the permissions of the perl binary, using a trick similar to step 9, run the following:
    chgrp apache /usr/bin/perl /usr/bin/wget /usr/local/bin/wget /usr/local/bin/curl /usr/bin/curl /usr/bin/python
    chmod 705 /usr/bin/perl /usr/bin/wget /usr/local/bin/wget /usr/local/bin/curl /usr/bin/curl /usr/bin/python
    what this will do is tell the system that any user in group "apache" is not allowed to execute /usr/bin/perl.  If you did implement step 9 you could in theory use "access" instead of "apache" for the chgrp value, to also prevent other system account from running it, but apache is the main one.   This technique can be applies to other binaries as well, like wget, fetch, etc.. anything you don't want the "apache" user from running.  Keep in mind that using suPhp (step 5) essentially negates this issue since php scripts run as the user instead.  Note that this is another layer of security, so using it anyway wouldn't hurt anything, in the event that an apache exploit happens independant of php completely.
    Do not block the apache group from running /usr/bin/perl if you are using mod_ruid2
15. Brute Force Login Attempts are more common, so it's best not to have direct ssh logins for common accounts like root or admin.  Generally, it's safe to use a hidden "su" user first, then login to root or other accounts once connected.  Disable any accounts (root, admin, etc) that don't need direct access by editing the /etc/ssh/sshd_config.   Always test changes before logging out else you may lock yourself out from the box.
    
    Also, DirectAdmin has a Brute Force attack detection system for the services, as well as an IP blocker for DA itself.
    More info on that here: http://help.directadmin.com/item.php?id=404
16. Force email logins to use a secure connection:
    http://www.directadmin.com/forum/showthread.php?t=43500
17. Disable 1.2.3.4/~username access, (UserDir on apache):
    cd /usr/local/directadmin/custombuild
    ./build set userdir_access no
    ./build rewrite_confs

For a default CustomBuild 2.0 install with apache, mod_php, and mod_ruid2, start with steps:
2, 3, 8, 11, 13, 15=8, 17, (optionally #1)