本文翻译：https://help.directadmin.com/item.php?id=247
1.请注意，服务器管理员有责任确保他的系统是安全的。以下是一些基本的安全提示，可以帮助保护您的系统。这不是一个完整的服务器安全指南，管理员必须指导，这只是一些基础的保护您的服务器的建议。
在安装时，最简单的方法是使用noexec、nosuid选项挂载/tmp分区，并使用nosuid选项挂载/home分区。这是在/etc/fstab中完成的，要求这些路径作为分区存在，而不仅仅是作为/的子目录存在。如果不确定，请键入：
mount
以获取分区及其当前安装选项的列表。使用google获取有关这些安装选项的更多信息。在编辑/etc/fstab时要非常小心，因为任何错误都可能阻止系统启动。注意，对于/或/usr，不能有“nosuid，noexec”，因为这些分区通常有suid二进制文件（su，passwd, ect）。
2.安装系统后，最好将有风险的php函数添加到disable_functions列表中。这可以防止php脚本运行可用于在系统上执行程序的“原生”函数。请注意，某些php脚本确实合法地要求这些函数进行操作，因此如果您的脚本在启用此函数后没有运行，请编辑php.ini以从列表中删除所需的函数，然后重新启动apache。要在custombuild中添加disable_函数，请键入以下命令，然后重新启动apache：
cd /usr/local/directadmin/custombuild
./build update
./build secure_php
3.定期更新系统服务、库和脚本。安装后保持系统更新是很重要的。这是服务器管理员的责任。有几个工具和选项可以帮助管理员做到这一点。对于像openssl和其他低级系统项这样的系统库，这是由管理员来完成的，通常像yum或apt-get这样的包系统可以为您完成这项工作。对于DA安装的服务和脚本，可以使用custombuild脚本。custombuild的典型更新命令是：
cd /usr/local/directadmin/custombuild
./build update
./build all d
注意，在custombuild目录中有一个名为“options.conf”的文件。此文件中列出了有关custombuild将执行的操作的所有选项。关于更新，请确保存在clean_old_webapps=yes。这将删除/var/www/html中的所有脚本，更新后您将执行一个新脚本。options.conf还有cron选项，可以每晚检查更新，甚至可以每晚安装这些选项。我建议你每晚检查一下cron，然后让管理员在收到通知后继续更新。要启用夜间通知，请使用相关信息替换以下粗体选项：
#Cron settings
cron=yes
cron_frequency=weekly
email=email@domain.com
notifications=yes
da_autoupdate=yes
updates=no
webapps_updates=yes
然后输入
./build cron
这些设置用于获取夜间更新通知，但它不会为您执行更新。
在收件箱中收到通知后，您可以从custombuild目录运行以下命令：
./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文件来允许每个用户进行设置，请参见此链接。
要启用SUPPP，请参阅本指南。
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:
如果您不打算对mysql进行任何远程访问，那么将mysqld设置为只监听127.0.0.1将是一个好主意。注意，如果用户开始问你为什么不能从远程位置连接到mysql，你必须记住这一点。要将mysql设置为只绑定到127.0.0.1，请在/etc/my.cnf的[mysqld]部分添加以下内容，然后重新启动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:
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)
对于使用apache、mod_php和mod_ruid2安装的默认CustomBuild 2.0，请从以下步骤开始：
2，3，8，11，13，15=8，17，（可选#1）
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安装后基础安全设置（官方版）