主机面板 eben 746浏览





以获取分区及其当前安装选项的列表。使用google获取有关这些安装选项的更多信息。在编辑/etc/fstab时要非常小心,因为任何错误都可能阻止系统启动。注意,对于/或/usr,不能有“nosuid,noexec”,因为这些分区通常有suid二进制文件(su,passwd, ect)。


cd /usr/local/directadmin/custombuild
./build update
./build secure_php


cd /usr/local/directadmin/custombuild
./build update
./build all d


#Cron settings


./build cron



./build update_versions

只更新那些需要更新的项。请注意,执行“./build all d”可能更简单,但需要更长的运行时间。

如果希望自动运行“./build update_versions”,请将updates=no更改为updates=yes。请记住,服务器管理员仍然需要完全了解系统,如果他为此选项选择yes,系统将处于状态。webapps_updates选项仅在使用updates=no时适用。它仍然允许更新/var/www/html中的php脚本,同时不影响编译的服务。如果updates=no,则设置webapps_updates=yes,并且您希望使用cron选项自动更新webapps脚本。如果updates=yes,则webapps\u updates值无关紧要。类似地,在启用cron时,使用da_autoupdate=yes和updates=no将更新da。

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.如果在“CLI”模式下运行php,那么同时启用php SafeMode和open_basedir是明智的。Safemode是disable_函数的一种内部形式,它还执行更多的检查。有关详细信息,请参阅有关安全模式的文档。Open_basedir(默认启用)告诉php不允许脚本访问路径集列表之外的文件。

要在php CLI系统上控制SafeMode并打开u Basedir(默认),请转到:

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.

suPhp是一些管理员喜欢的一个选项,另一些则不是。suPhp(php CGI)所做的是以帐户的系统用户而不是“apache”用户的身份运行php脚本。这解决了许多问题,比如php脚本上载文件时的权限/所有权。它还允许管理员更容易地跟踪流氓脚本,因为它不是作为普通用户运行的。suPhp的另一个好处是,您可以将php脚本修改为700而不是755。这使它们在脚本中存储密码时更加安全。suPhp的缺点包括性能稍有下降,因为要让php作为用户而不是“apache”运行,还需要几个步骤。此外,上面第4)点中的项目没有任何效果,因为SUHP不监视VirtualHost php标志。所有设置必须在php.ini文件中完成。请注意,可以使用每个用户的php.ini文件来允许每个用户进行设置,请参见此链接。

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 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, add the following to the [mysqld] section of your /etc/my.cnf, then restart mysqld:



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:

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:

17.Disable 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)

对于使用apache、mod_php和mod_ruid2安装的默认CustomBuild 2.0,请从以下步骤开始:


Other steps may already be enabled by default, or less applicable these days as the might use older technology.  Feel free to read through each one to check.



转载请注明:落伍老站长 » directadmin安装后基础安全设置(官方版)