文章目录
- 导图
- Linux安全
- Linux 安全模型
- 用户层权限管理的细节
- 多用户环境中的权限管理
- 文件权限与目录权限
- 最小权限原则的应用
- Linux 系统中的认证、授权和审计机制
- 认证机制
- 授权机制
- 审计机制
- 小结
- 内网安全
- Docker安全
- 1. Docker 服务隔离机制
- Namespace 机制
- Capabilities 机制
- CGroups 机制
- 2. Docker Daemon 安全风险
- 3. Docker 镜像安全
- 使用最精简的镜像
- 最小权限原则
- 4. 使用漏洞扫描工具
- 小结
导图
Linux安全
Linux 安全模型
Linux 系统可以分为内核层和用户层：
- 内核层负责对资源的直接管理，包括进程调度、内存管理、文件系统和硬件控制等。它的安全机制主要通过内置的权限管理、进程隔离和内存保护来确保稳定和安全。
- 如果黑客能够成功突破内核层安全（例如通过漏洞获取 root 权限），他们可以绕过用户层的所有安全措施。这时，即使我们在用户层配置再复杂的权限，也无济于事。
- 用户层是我们日常操作的主要部分，提供对系统资源的访问。开发者和运维人员通过用户层访问内核提供的服务。我们日常关注的安全措施，如文件权限、进程权限、日志管理等，都在用户层进行。
内核层安全重点：
- 内核层安全是通过定期更新和修补漏洞来维护的。Linux 社区会发布安全更新来修复内核中的已知漏洞，定期使用官方发行的镜像、打补丁来防止攻击者利用漏洞。
用户层安全重点：
- 权限配置：用户层的权限设置确保不同用户之间的数据和进程隔离，防止越权访问。
- 进程隔离：Linux 通过权限和用户身份管理实现进程之间的隔离，确保一个用户的进程不会影响其他用户的进程或数据。
用户层权限管理的细节
多用户环境中的权限管理
在 Linux 多用户环境中，用户层的安全性依赖于正确的权限配置。Linux 系统使用 UID（用户 ID）和 GID（组 ID）来标识用户及其所属的组，权限则通过用户、组和其他人三类身份来控制文件和进程的访问。
主体 -> 请求 -> 客体模型：
- 主体是用户（或进程），请求是操作（如读、写、执行），客体是文件、目录或系统资源。
- 例如，当一个用户试图读取
/etc/passwd文件时，Linux 会检查该用户是否有权限执行这个请求，只有具备合适权限，操作才会成功。
文件权限与目录权限
Linux 中，所有文件和目录都有与之关联的权限，权限分为：
- r（读）：用户是否能读取文件或查看目录内容。
- w（写）：用户是否能修改文件或在目录中创建、删除文件。
- x（执行）：用户是否能执行文件或进入目录。
权限通过 ls -l 命令可以查看，并通过 chmod 命令进行修改。对于文件和目录的权限作用有所不同：
- 文件的权限：决定谁可以读取、修改和执行该文件。
- 目录的权限：决定谁可以查看、添加、删除目录中的文件。
除了基本权限，Linux 还提供了额外的权限控制手段：
- SUID/SGID：用于文件时，这些位允许用户以文件所有者或组的权限运行程序，常用于特定的系统命令。
- 粘滞位（Sticky Bit）：常用于共享目录（如
/tmp），确保用户只能删除自己创建的文件，防止滥用删除他人文件。chmod +t /tmp可以阻止删除 /tmp 目录下其他用户的文件
最小权限原则的应用
在 Linux 系统中，最小权限原则是安全管理的核心。即为每个用户或进程分配最少的权限，以减少潜在的攻击面。尤其是在多用户共用服务器时，过多的权限可能会导致数据泄露或服务滥用。
以下是几种常见的实践：
-
使用普通用户而非 root 用户运行服务：
例如，运行 MySQL 服务时，使用mysqld命令以mysql用户启动进程，而不是 root。这样，即使 MySQL 服务出现漏洞，攻击者也无法直接获取 root 权限。sudo -u mysql mysqld_safe -
服务进程的权限隔离：
在启动 Nginx 时，Nginx 的工作进程使用nobody用户身份运行。这种方法确保了即使 Web 服务遭到攻击，也无法轻易危害到系统其他部分。# Nginx 进程运行状态 ps aux | grep nginx root 7083 0.0 0.0 61032 5324 ? Ss Aug12 0:01 nginx: master process nobody 331122 0.0 0.0 90768 31776 ? S 11:44 0:00 nginx: worker processnobody 通常拥有整个操作系统中最小的权限
-
通过文件属性保护关键文件：
使用chattr +i命令可以为重要的文件添加不可修改属性（immutable），防止即使有权限的用户修改关键配置文件。sudo chattr +i /etc/passwd
Linux 系统中的认证、授权和审计机制
认证机制
认证确保用户的身份合法，防止未经授权的用户访问系统资源。在 Linux 系统中，用户信息存储在 /etc/passwd 和 /etc/shadow 文件中。
-
/etc/passwd：保存用户账户信息，但不会存储密码，而是将密码占位为x。 -
/etc/shadow：保存加密后的用户密码和密码策略（如密码有效期、密码失效天数等）。
配置密码策略可以有效提升安全性，如使用chage命令设置密码过期时间：sudo chage -M 60 testuser # 强制 testuser 每 60 天更改密码
弱密码检测：
为了防止弱密码攻击，可以使用工具如 John the Ripper 对密码进行审计：
unshadow /etc/passwd /etc/shadow > mypasswd
john mypasswd # 开始检测弱密码
john --show mypasswd # 显示已破解的密码
授权机制
授权是在用户通过认证后，系统根据权限决定其能访问哪些资源。Linux 系统通过读、写、执行权限，控制用户对文件和目录的访问。除此之外，Linux 还提供了 ACL（访问控制列表）来实现更精细的权限控制。
最小权限原则的扩展：
滥用 root 是 Linux 安全中的普遍问题，所有长时间运行的进程（如数据库、Web 服务）应尽量避免使用 root 权限，而使用特定用户账户来运行这些进程。例如：
sudo -u redis redis-server # 使用非 root 账户运行 Redis
审计机制
审计是指对系统操作进行记录和分析，以便在出现问题时能够追踪到源头。在 Linux 系统中，主要的日志文件位于 /var/log 目录下，常见的日志包括：
- /var/log/wtmp 和 /var/run/utmp：记录用户登录和注销事件。 用户登录日志本身为二进制文件，我们无法直接通过文本方式查看，但是可以配合who/users/last/lastlog这样的命令来获取
- /var/log/secure：记录与安全相关的事件，如用户的认证尝试。
- /var/log/messages：记录系统及应用的普通信息。
可以通过命令 who 或 last 来查看用户登录日志。例如：
last # 查看最近的用户登录记录
日志管理与分析：
默认情况下，Linux 会通过 logrotate 对日志执行相应的保留策略（比如日志切割和旧日志删除等）。通过配置/etc/logrotate.conf可以对不同日志的保留策略进行修改日志可以通过 logrotate 来管理，定期归档旧日志，避免日志文件过大。
此外，使用日志分析工具如 ELK 或 Zabbix，可以对系统日志进行实时监控，配置安全报警规则来检测潜在的攻击行为。
小结
Linux 安全体系的核心是正确的权限配置和最小权限原则的实践。通过配置合适的权限、使用非 root 账户运行服务，以及对日志的有效监控，可以大大提升系统的安全性。配合 HIDS 等安全工具，为 Linux 系统提供额外的保护层。
内网安全
系统安全 - 内网安全与防护措施
Docker安全
- Docker 服务：Docker 所提供的功能以及在宿主机 Linux 中的 Docker 进程。
- Docker 镜像：通过 Dockerfile 构建出来的 Docker 镜像。
- Docker 容器：实际运行的 Docker 容器，通常来说，一个 Docker 镜像会生成多个
- Docker 容器。Docker 容器运行于 Docker 服务之上。
1. Docker 服务隔离机制
Namespace 机制
Namespace是Docker用于实现轻量化容器隔离的核心机制。它为每个容器创建一个独立的名称空间，包括进程、网络、文件系统等，从而实现隔离。然而，这种隔离是"伪隔离"，因为容器需要与宿主机共享某些关键资源，例如文件系统的某些部分（如/proc目录、/sys目录）和设备（如存储设备）。
Capabilities 机制
Capabilities机制为容器中的进程提供了更细粒度的权限控制。例如，容器中可能需要执行某些操作（如绑定低端口），但不应授予完整的ROOT权限。通过这种机制，可以限制容器的权限，降低Docker逃逸的风险。然而，过于严格的限制可能会导致容器内应用功能受限，因此需要仔细平衡。
CGroups 机制
CGroups用于控制Docker容器对CPU、内存、I/O等资源的占用，防止某个容器过度消耗宿主机资源。这对于防止资源耗尽攻击至关重要。
Docker 服务可以利用 CGroups 机制来实现对容器中内存、CPU 和 IO 等的限制。比如，通过下面的命令，我们就可以限制 Docker 容器只使用 2 个 CPU 和 100MB 的内存来运行了
docker run -it --cpus=2 --memory="100m" ubuntu:latest /bin/bash
所以，当一个宿主机中运行了多个 Docker 容器的时候，我们可以通过 CGroups，给每一个容器弹性地分配 CPU 资源。同样地，这个限制既不能过松，过松会导致某一个 Docker容器耗尽宿主机资源，也不能过严，过严会使得容器内的服务得不到足够的资源支持。这都需要我们自己经过慎重考量来进行配置，没有默认的安全机制可以辅助我们
2. Docker Daemon 安全风险
Docker守护进程运行时需要ROOT权限，因此它成为潜在攻击者的重要目标。如果守护进程被攻击者控制，黑客就可以通过Docker的API接口，执行任意操作，包括创建或修改镜像、访问宿主机文件系统等。特别是如果Docker的远程API端口未配置认证（默认监听2375端口），黑客可通过该接口直接控制Docker服务。
防护措施
-
API认证：启用TLS认证来保护Docker API接口，避免未经授权的访问。
dockerd --tlsverify \ --tlscacert=ca.pem \ --tlscert=server-cert.pem \ --tlskey=server-key.pem启用 TLS 验证：
-
–tlsverify：要求客户端和服务器之间的 TLS 双向认证。
指定 CA 证书： -
–tlscacert=ca.pem：使用 CA（Certificate Authority）证书文件 ca.pem 来验证连接的客户端。
指定服务器证书： -
–tlscert=server-cert.pem：指定 Docker 守护进程的服务器证书文件，server-cert.pem。
指定服务器私钥： -
–tlskey=server-key.pem：指定与服务器证书配套的私钥文件，server-key.pem。
curl https://127.0.0.1:2376/images/json \ --cert cert.pem \ --key key.pem \ --cacert ca.pem- https://127.0.0.1:2376：这是 Docker 守护进程的本地地址，端口 2376 是 Docker 守护进程的默认 TLS 端口。
/images/json：这是 Docker API 的一个端点，用于获取 Docker 中所有镜像的 JSON 格式列表。 - –cert cert.pem：指定客户端证书文件，cert.pem 用于身份验证。
- –key key.pem：指定客户端私钥文件，key.pem 用于和 cert.pem 配合，完成双向认证。
- –cacert ca.pem：指定 CA 证书，用于验证 Docker 守护进程的服务器证书是否由受信任的 CA 颁发。
-
-
守护进程权限：采用最小权限原则，限制守护进程的权限。
3. Docker 镜像安全
使用最精简的镜像
避免使用功能过多的基础镜像，如常见的Node.js或Ubuntu镜像，这些镜像可能包含大量无用功能以及已知的安全漏洞。通过使用精简版本（如alpine），可以显著减少镜像的漏洞暴露面。
最小权限原则
默认情况下，Docker容器的进程以ROOT身份运行。这种配置不利于安全，尤其是在存在漏洞的情况下。因此，建议在Dockerfile中为容器的服务创建和使用低权限的用户，以限制其对宿主机的影响。例如，可以通过USER node来避免使用ROOT权限运行服务。
FROM ubuntu# 创建一个 node 用户，没有密码、没有 home 目录、并且没有登录 shell
RUN groupadd -r node && useradd -r -g node -s /bin/false node# 切换到 node 用户运行后续命令
USER node# 运行应用程序（假设 index.js 是您的应用入口）
CMD ["node", "index.js"]groupadd -r node: 创建一个名为node的系统组 (-r标志表示系统组)。useradd -r -g node -s /bin/false node: 创建一个名为node的用户：-r: 系统用户（不会创建 home 目录）。-g node: 将用户添加到node组。-s /bin/false: 禁止用户登录，表示这是一个非交互式用户。
USER node: 切换到node用户来运行后续命令，确保容器中的进程不是以 root 身份运行。CMD ["node", "index.js"]: 使用node来运行您的应用程序index.js。使用数组形式的 CMD 可以避免 shell 的使用，直接执行命令。
通过不为用户指定密码、不允许登录 shell 以及避免创建 home 目录，为容器中的 node 用户设置了最低权限，减少了潜在的攻击面。
确保 index.js 文件已经存在于正确的路径中，或者可以在 Dockerfile 中通过 COPY 指令将其复制到镜像内。
4. 使用漏洞扫描工具
工具如Clair可以自动分析Docker镜像中的已知漏洞，提供静态分析，并与已知的漏洞数据库进行比对，从而识别和修复潜在的安全问题。
小结
在讨论Docker安全时，虽然容器技术提供了一定的隔离机制，但这些机制并不是完美的，特别是在伪隔离和共享部分资源的情况下，存在Docker逃逸的风险。通过合理配置Namespace、Capabilities、CGroups、守护进程认证和镜像最小化，可以显著提高Docker环境的安全性。此外，采用漏洞扫描工具可进一步加强安全。
