Sco*_*ack 111
David 的回答是服务器强化一般原则的一个很好的基线。正如大卫所指出的，这是一个很大的问题。您采用的具体技术可能在很大程度上取决于您的环境以及您的服务器的使用方式。警告，这可能需要在测试环境中进行大量工作才能构建并正确完成。其次是很多工作要集成到你的生产环境中，更重要的是业务流程。
但是，首先要检查您的组织是否有任何强化策略，因为这些策略可能是最直接相关的。如果没有，根据您的角色，这可能是构建它们的好时机。我还建议从下往上分别处理每个组件。
L
有很多很好的指南可以帮助您。此列表可能对您有帮助，也可能无济于事，具体取决于您的发行版。
A
Apache 保护起来很有趣。我发现强化操作系统和维护可用性比 Apache 或 PHP 更容易。
他们
P
这贯穿了安全编程实践的整个思想，它是一个完整的学科。SANS 和 OWASP 有关于这个主题的大量信息，所以我不会在这里复制它。我将专注于运行时配置，让您的开发人员担心其余的事情。有时 LAMP 中的“P”指的是 Perl，但通常指的是 PHP。我假设是后者。
小智 16
你问了一个问题，坦率地说，值得读几本书来讨论这个话题。但是有一些通用的基本准则可以很好地工作：
希望能帮助您入门。
这是我喜欢从一个很好的清单开始。
小智 5
除了大卫的建议之外，您的安装越模块化，我的意思是限制对专门为一项任务创建的某些用户/组的访问并限制其范围，您的 LAMP 堆栈就越安全：例如，拥有一个 Apache 用户适用于权限设置相应的 Apache 文件/文件夹，而不是可以访问关键系统文件/文件夹的任何组。可以访问与您要提供服务的网站相关联的 MySql 表的用户，并且只能访问这些表。此外，您可以限制他们的访问权限，以通过 PHP 调用提供最少的访问权限。此外，请确保通过 PHP 文件使用/公开的 MySQL 用户名与其他用户使用的用户名或密码不同。
这意味着：如果 apache 用户或 MySql 用户受到威胁，他们不能在 apache 可以访问的文件夹范围之外（在 apache 用户的情况下）和表之外（ s)/database(s)（对于 MySQL 数据库的用户）。
如果 MySQL 用户以某种方式受到损害，例如，他们无法访问数据库并从 MySQL 中删除所有数据库并破坏您的所有数据。在某些情况下，它们可能能够删除表或在隔离数据库中的某些表中插入信息，这就是为什么仅在绝对必要的情况下授予表访问权限并且仅授予所需的权限很重要......如果你不这样做'不需要具有删除表权限或更新权限，然后不要将它们授予该用户。
此外，如果出于某种原因，您的管理帐户用户名和密码被发现用于 MySQL，如果您使用的用户名与系统上的任何用户名不同，则他们必须首先破坏系统的安全性，然后才能进入您的数据库进行破坏。对于 apache 用户和对文件的访问也是如此。
示范时间！我将给出一个系统示例来简化这个想法。
假设您的系统上有用户（为了安全起见，应该通过 umod -l 或 passwd -l 等禁用 root 用户）：john、barney、terence 和 lisa。
您可以在 MySQL 中创建一个名为 bigbird 的用户（确保使用散列密码）。Bigbird 只有选择权限和更新权限，但没有删除或创建权限，当然也没有. 此外，您创建了另一个名为 garfield 的 MySQL 管理用户，用于处理 MySQL 数据库，并从 MySQL 数据库中删除 root 用户，这样它就不会受到威胁。加菲猫已获准。整个 MySQL 的特权（实际上，这只是重命名 root）。
现在，您创建一个 apache 组或一个用户，我们将其命名为 apweb2。Appweb2 不是其他组的成员，apache 的所有文件/文件夹都存储在 /home/apweb2/ 中。每个虚拟主机都有自己的子文件夹，并且这些主机中的每一个都将文档根设置为该子文件夹。符号链接将被禁用，以免意外提供对系统其余部分的访问。
此外，您可以将 ssh 访问限制为仅某些用户（或某些组，我喜欢将它们放在 ssh 组中，并使其成为唯一可以使用 ssh 的对象）。
此外，您可以选择哪些用户具有 sudo 权限以进一步限制。您可以更进一步的另一个步骤是让任何 ssh 用户都无法使用 sudo，您可以创建可以使用无法使用 ssh 的 sudo 的特殊用户，这样一旦您 ssh 登录，您必须登录另一个用户才能使用访问 sudo。
因此，通过模块化每个段，如果一个段受到损害，整个堆栈将不会受到损害，您可以解决第 1 个问题，而不必从头开始。