【安全等保】Linux服务器基线安全--干货
业务标签:医院信息集成平台、互联网医院、互联网护理、慢性病随访
技术标签:ESB、ETL+CDC、NLP、FaaS、SaaS、Hadoop、MicroService
技术微信群:
加微信:wonter 发送:技术Q
医疗微信群:
加微信:wonter 发送:医疗Q
关注公众号查看
一、系统安全基线
1.1 系统登录弱口令
**描述**
若系统使用弱口令,存在极大的被恶意猜解入侵风险,需立即修复。
**加固建议**
执行命令 `passwd [<user>]`,然后根据提示输入新口令完成修改,其中 `<user>` 为用户名,如果不输入则修改的是当前用户的口令。
口令应符合复杂性要求:
|
1.2 确保root是唯一的UID为0的帐户
**描述**
除`root`以外其他`UID`为`0`的用户都应该删除,或者为其分配新的`UID`
**加固建议**
除`root`以外其他`UID`为`0`的用户,都应该删除,或者为其分配新的`UID`
查看命令:
|
1.3 开启地址空间布局随机化
**描述**
它将进程的内存空间地址随机化来增大入侵者预测目的地址难度,从而降低进程被成功入侵的风险
**加固建议**
在`/etc/sysctl.conf`或`/etc/sysctl.d/*`文件中设置以下参数:
|
执行命令:sysctl -w kernel.randomize_va_space=2
1.4 设置用户权限配置文件的权限
**描述**
设置用户权限配置文件的权限
**加固建议**
执行以下5条命令
|
1.5 访问控制配置文件的权限设置
**描述**
访问控制配置文件的权限设置
**加固建议**
运行以下4条命令:
|
如果您是`redhat8`用户
|
1.6 确保SSH LogLevel设置为INFO
**描述**
确保`SSH LogLevel`设置为`INFO`,记录登录和注销活动
**加固建议**
编辑 `/etc/ssh/sshd_config` 文件以按如下方式设置参数(取消注释):
|
1.7 确保rsyslog服务已启用安全审计
**描述**
确保`rsyslog`服务已启用,记录日志用于审计
**加固建议**
运行以下命令启用`rsyslog`服务:
|
1.8 确保SSH MaxAuthTries设置为3到6之间
**描述**
设置较低的`Max AuthTrimes`参数将降低`SSH`服务器被暴力攻击成功的风险。
**加固建议**
在`/etc/ssh/sshd_config`中取消`MaxAuthTries`注释符号`#`,设置最大密码尝试失败次数`3-6`,建议为`4`:
|
1.9 确保密码到期警告天数为7或更多
**描述**
确保密码到期警告天数为`7`或更多
**加固建议**
在 `/etc/login.defs` 中将 `PASS_WARN_AGE` 参数设置为`7-14`之间,建议为`7`:
|
同时执行命令使`root`用户设置生效:
|
1.10 禁止SSH空密码用户登录 SSH服务配置
**描述**
禁止`SSH`空密码用户登录
**加固建议**
编辑文件`/etc/ssh/sshd_config`,将`PermitEmptyPasswords`配置为`no`:
|
1.11 检查系统空密码账户
**描述**
检查系统空密码账户
**加固建议**
为用户设置一个非空密码,或者执行`passwd -l <username>`锁定用户
1.12 检查密码重用是否受限制
**描述**
强制用户不重用最近使用的密码,降低密码猜测攻击风险
**加固建议**
在`/etc/pam.d/password-auth`和`/etc/pam.d/system-auth`中`password sufficient pam_unix.so` 这行的末尾配置`remember`参数为`5-24`之间,原来的内容不用更改,只在末尾加了`remember=5`。
1.13 密码复杂度检查
**描述**
检查密码长度和密码是否使用多种字符类型
**加固建议**
编辑`/etc/security/pwquality.conf`,把`minlen`(密码最小长度)设置为`8-32`位,把`minclass`(至少包含小写字母、大写字母、数字、特殊字符等`4`类字符中等`3`类或`4`类)设置为`3`或`4`。如:
|
1.14 设置SSH空闲超时退出时间
**描述**
设置`SSH`空闲超时退出时间,可降低未授权用户访问其他用户`ssh`会话的风险
**加固建议**
编辑`/etc/ssh/sshd_config`,将`ClientAliveInterval` 设置为`300`到`900`,即`5-15`分钟,将`ClientAliveCountMax`设置为`0-3`之间。
|
1.15 设置密码修改最小间隔时间
**描述**
设置密码修改最小间隔时间,限制密码更改过于频繁
**加固建议**
在 `/etc/login.defs` 中将 `PASS_MIN_DAYS` 参数设置为`7-14`之间,建议为`7`:
|
需同时执行命令为root用户设置:
|
1.16 设置密码失效时间
**描述**
设置密码失效时间,强制定期修改密码,减少密码被泄漏和猜测风险,使用非密码登陆方式(如密钥对)请忽略此项。
**加固建议**
使用非密码登陆方式如密钥对,请忽略此项。
在 `/etc/login.defs` 中将 `PASS_MAX_DAYS` 参数设置为 `60-180`之间,如:
|
需同时执行命令设置root密码失效时间:
|
二、Nginx安全基线
2.1 确保已禁用自动索引模块
**描述**
自动索引模块处理以斜杠字符结尾的请求。此功能启用目录列表,这在攻击者侦察中可能很有用,因此应将其禁用。
**加固建议**
执行以下操作以禁用自动索引模块:
搜索 NGINX 配置文件( nginx.conf 和任何包含的配置文件)以查找 `autoindex` 指令。
|
在 `location` 下删除或者修改为 `autoindex off;`
2.2 针对Nginx SSL协议进行安全加固
**描述**
Nginx SSL 协议的加密策略进行加固
**加固建议**
Nginx SSL 协议采用 TLSv1.2:
打开 `conf/nginx.conf` 配置文件(或主配置文件中的 `inlude` 文件);
|
**备注**:配置此项请确认 nginx 支持 `OpenSSL`,运行 `nginx -V` 如果返回中包含 `built with OpenSSL` 则表示支持 `OpenSSL`。如不支持,可能需要增加配置 `ssl_protocols TLSv1 TLSv1.1 TLSv1.2;`
如果尚未配置 ssl 协议,请尽快配置(参考连接https://www.nginx.cn/doc/optional/ssl.html)
2.3 确保NGINX配置文件权限为644
**描述**
把控配置文件权限以抵御外来攻击
**加固建议**
修改 Nginx 配置文件权限:执行 `chmod 644 <conf_path>` 来限制 Nginx 配置文件的权限;
(`<conf_path>`为配置文件的路径,如默认 `/安装目录/conf/nginx.conf` 或者 `/etc/nginx/nginx.conf`,或用户自定义,请 自行查找)
2.4 Nginx的WEB访问日志记录状态
**描述**
应为每个核心站点启用 `access_log` 指令。默认情况下启用。
**加固建议**
开启 Nginx 的 WEB 访问日志记录:
1、打开 `conf/nginx.conf` 配置文件,含主配置文件中 include 项包含的子配置文件;
2、在http下配置 `access_log` 项 `access_log logs/host.access.log main;`
3、并在主配置文件,及主配置文件下的include文件中 删除 `off` 项或配置为适当值
2.5 隐藏Nginx服务的Banner
**描述**
Nginx 服务的 Banner 隐藏状态
**加固建议**
Nginx 后端服务指定的 Header 隐藏状态隐藏 Nginx 服务 Banner 的状态:
1、打开 `conf/nginx.conf` 配置文件;
2、在 `server` 栏目下,配置 `server_tokens` 项 `server_tokens off;` 如出现多项不支持,执行 `ln <conf_path> /etc/nginx/nginx.conf`
2.6 Nginx后端服务指定的Header隐藏状态
**描述**
隐藏 Nginx 后端服务 `X-Powered-By` 头
**加固建议**
隐藏 Nginx 后端服务指定Header的状态:
1、打开 `conf/nginx.conf` 配置文件;
2、在 http 下配置 `proxy_hide_header` 项;
增加或修改为 `proxy_hide_header X-Powered-By;` `proxy_hide_header Server;`
2.7 检查Nginx进程启动账号
**描述**
Nginx 进程启动账号状态,降低被攻击概率
**加固建议**
修改 Nginx 进程启动账号:
1、打开 `conf/nginx.conf` 配置文件;
2、查看配置文件的 `user` 配置项,确认是非 `root` 启动的;
3、如果是 `root` 启动,修改成 `nobody` 或者 `nginx` 账号;
备注:4、修改完配置文件之后需要重新启动 Nginx。
2.8 检查是否配置Nginx账号锁定策略
**描述**
1.执行系统命令 `passwd -S nginx` 来查看锁定状态
出现 `Password locked` 证明锁定成功
如:`nginx LK 2020-12-29 -1 -1 -1 -1 (Password locked.)`
2.默认符合,修改后才有(默认已符合)
3.执行系统命令`passwd -l nginx`进行锁定
**加固建议**
配置 Nginx 账号登录锁定策略:
Nginx 服务建议使用非 `root` 用户(如`nginx`,`nobody`)启动,并且确保启动用户的状态为锁定状态。
可执行 `passwd -l <Nginx启动用户>` 如 `passwd -l nginx` 来锁定 Nginx 服务的启动用户。
命令 `passwd -S <用户>` 如 `passwd -S nginx` 可查看用户状态。
修改配置文件中的 `nginx` 启动用户修改为 `nginx` 或 `nobody`
如:`user nobody;`
如果您是 `docker` 用户,可忽略该项(或添加白名单)
三、Redis安全基线
3.1 Redis未授权访问高危风险
**描述**
Redis 端口对外开放并且没有配置认证选项,未授权用户除了可直接获取数据库中所有信息,造成严重的信息泄露外,还可以通过未授权访问漏洞入侵攻击系统。
**加固建议**
可以使用以下方法修复:
1、为 Redis 服务配置认证,在配置文件 `redis.conf` 中 `requirepass` 配置复杂密码,然后重启 `redis`。
2、在 Redis 的配置文件 `redis.conf` 中配置如下:`bind 127.0.0.1`,只允许本机访问,然后重启 `redis`
3.2 开启redis密码认证,并设置高复杂度密码
**描述**
`redis` 在 `redis.conf` 配置文件中,设置配置项 `requirepass`, 开户密码认证。
`redis` 因查询效率高,`auth`这种命令每秒能处理9w次以上,简单的`redis`的密码极容易为攻击者暴破。
**加固建议**
打开 `redis.conf`,找到 `requirepass` 所在的地方,修改为指定的密码,密码应符合复杂性要求:
|
再去掉前面的#号注释符,然后重启 `redis`
3.3 修改默认6379端口
**描述**
避免使用熟知的端口,降低被初级扫描的风险
**加固建议**
编辑文件 `redis` 的配置文件 `redis.conf`,找到包含 `port` 的行,将默认的 `6379` 修改为自定义的端口号,然后重启 `redis`
3.4 打开保护模式
**描述**
`redis` 默认开启保护模式。要是配置里没有指定 `bind` 和 密码,开启该参数后,`redis` 只能本地访问,拒绝外部访问。
**加固建议**
`redis.conf` 安全设置:# 打开保护模式 `protected-mode yes`
3.5 禁用或者重命名危险命令
**描述**
Redis中线上使用keys *命令,也是非常危险的。因此线上的Redis必须考虑禁用一些危险的命令,或者尽量避免谁都可以使用这些命令,Redis没有完整的管理系统,但是也提供了一些方案。
**加固建议**
修改 redis.conf 文件,添加
|
然后重启`redis`。
重命名为 `""` 代表禁用命令,如想保留命令,可以重命名为不可猜测的字符串,如:
|
3.6 限制redis 配置文件访问权限
**描述**
因为 `redis` 密码明文存储在配置文件中,禁止不相关的用户访问改配置文件是必要的,设置`redis`配置文件权限为`600`
加固建议
执行以下命令修改配置文件权限:
|
3.7 禁止使用root用户启动
**描述**
使用 `root` 权限去运行网络服务是比较有风险的(`nginx`和`apache`都是有独立的`work`用户,而`redis`没有)。
`redis crackit` 漏洞就是利用`root`用户的权限来替换或者增加`authorized_keys`,来获取`root`登录权限的
**加固建议**
使用`root`切换到`redis`用户启动服务:
|
3.8 禁止监听在公网
**描述**
Redis监听在0.0.0.0,可能导致服务对外或内网横向移动渗透风险,极易被黑客利用入侵。
**加固建议**
在`redis`的配置文件`redis.conf`中配置如下:`bind 127.0.0.1`或者内网`IP`,然后重启`redis`
四、ZooKeeper安全基线
4.1 ZooKeeper未授权访问
**描述**
ZooKeeper 在未设置访问控制情况下,攻击者可通过执行 `envi` 命令获得系统大量的敏感信息,任务用户或者客户端不需要认证就可以连上 `zk` 的服务端,并且可以对 `znode` 进行增删等操作,非常不安全的,极易被攻击和篡改。
**加固建议**
可以使用以下方法修复
限制 Zookeeper 直接暴露在公网,将端口绑定地址改为`127.0.0.1`
设置访问控制
1. 增加一个认证用户
`addauth digest` 用户名:密码明文
2. 设置访问控制权限
`setAcl /path auth`:用户名:密码明文:权限
例如给根目录设置权限:`setAcl / auth:user1:password1:cdrwa`
设置 IP 白名单访问控制 如给`192.168.0.0/24`网段设置白名单,在设置IP白名单时,将本机ip `127.0.0.1`也加上,让本机也可以访问及修改
|
五、MySQL安全基线
5.1 禁用symbolic-links选项
**描述**
禁用符号链接以防止各种安全风险
**加固建议**
编辑 Mysql 配置文件 `<conf_path>/my.cnf`,在 `mysqld` 段落中配置 `symbolic-links=0`,5.6及以上版本应该配置为 `skip_symbolic_links=yes`,并重启 `mysql` 服务。
5.2 匿名登录检查
**描述**
检查 MySQL 服务是否允许匿名登录
**加固建议**
登录 MySQL 数据库,执行以下命令删除匿名账户:
|
5.3 确保log-raw选项没有配置为ON
**描述**
当 `log-raw` 记录启用时,有权访问日志文件的人可能会看到纯文本密码。
**加固建议**
编辑 Mysql 配置文件 `<conf_path>/my.cnf`,删除 `log-raw` 参数,并重启 `mysql` 服务
5.4 确保配置了log-error选项
**描述**
启用错误日志可以提高检测针对 `mysql` 和其他关键消息的恶意尝试的能力,例如,如果错误日志未启用,则连接错误可能会被忽略。
**加固建议**
编辑 Mysql 配置文件 `<conf_path>/my.cnf`,在 `mysqld_safe` 段落中配置 `log-error` 参数,`<log_path>` 代表存放日志文件路径,如:`/var/log/mysqld.log`,并重启 `mysql` 服务:
|
5.5 删除'test'数据库
**描述**
测试数据库可供所有用户访问,并可用于消耗系统资源。删除测试数据库将减少 `MySQL` 服务器的攻击面。
**加固建议**
登录数据库执行以下SQL语句删除 `test` 数据库:
|
5.6 禁止使用--skip-grant-tables选项启动MySQL服务
**描述**
使用此选项,会导致所有客户端都对所有数据库具有不受限制的访问权限。
**加固建议**
编辑 Mysql 配置文件 `<conf_path>/my.cnf`,删除 `skip-grant-tables` 参数,并重启 `mysql` 服务
5.7 为MySQL服务使用专用的最低特权账户
**描述**
使用最低权限账户运行服务可减小 MySQL 天生漏洞的影响。受限账户将无法访问与 MySQL 无关的资源,例如操作系统配置。
**加固建议**
使用非 `root` 和非 `sudo` 权限用户启动 `MySQL` 服务
5.8 修改默认3306端口
**描述**
避免使用熟知的端口,降低被初级扫描的风险
**加固建议**
编辑 **<conf_path>/my.cnf** 文件,**mysqld** 段落中配置新的端口参数,并重启 **MySQL** 服务:
|
5.9 确保MYSQL_PWD环境变量未设置
**描述**
`MYSQL_PWD` 环境变量的使用意味着 `MYSQL` 凭证的明文存储,极大增加 `MySQL` 凭据泄露风险。
**加固建议**
删除系统环境变量中 MySQL 密码(`MYSQL_PWD`)配置
5.10 确保没有用户配置了通配符主机名
**描述**
避免在主机名中只使用通配符,有助于限定可以连接数据库的客户端,否则服务就开放到了公网
**加固建议**
执行 `SQL` 更新语句,为每个用户指定允许连接的 `host` 范围。
1. 登录数据库,执行
|
2. 执行语句
|
查看 `HOST` 为通配符的用户;
3. 删除用户或者修改用户 `host` 字段
删除语句:
|
更新语句:
|
4. 执行SQL语句:
|
5.11 禁用local-infile选项
**描述**
禁用 `local_infile` 选项会降低攻击者通过 `SQL` 注入漏洞器读取敏感文件的能力
**加固建议**
编辑 Mysql 配置文件 `<conf_path>/my.cnf`,在 `mysqld` 段落中配置 `local-infile` 参数为 `0`,并重启 `mysql` 服务:
|
5.12 数据库登录弱口令
**描述**
若系统使用弱口令,存在极大的被恶意猜解入侵风险,需立即修复。
**加固建议**
登录 mysql 数据库;
查看数据库用户密码信息:
|
新口令应符合复杂性要求:
|
六、Tomcat安全基线
6.1 限制服务器平台信息泄漏
**描述**
限制服务器平台信息泄漏会使攻击者更难确定哪些漏洞会影响服务器平台。
**加固建议**
1. 进入Tomcat安装主目录的 `lib` 目录下,比如 `cd /usr/local/tomcat7/lib`
2. 执行:
|
修改文件 `ServerInfo.properties` 中的 `server.info` 和 `server.number` 的值,如分别改为:`Apache/11.0.92`、`11.0.92.0`
3. 执行:
|
4. 重启Tomcat服务
6.2 避免为tomcat配置manager-gui弱口令
**描述**
tomcat-manger是Tomcat提供的web应用热部署功能,该功能具有较高权限,会直接控制Tomcat应用,应尽量避免使用此功能。如有特殊需求,请务必确保为该功能配置了强口令
**加固建议**
编辑 Tomcat 根目录下的配置文件 `conf/tomcat-user.xml`,修改 `user` 节点的 `password` 属性值为复杂密码, 密码应符合复杂性要求:
|
6.3 删除项目无关文件和目录
**描述**
Tomcat 安装提供了示例应用程序、文档和其他可能不用于生产程序及目录,存在极大安全风险,建议移除
**加固建议**
请删除 Tomcat 示例程序和目录、管理控制台等,即从 `Tomcat` 根目录的 `webapps` 目录,移出或删除 `docs`、`examples`、`host-manager`、`manager`目录。
6.4 禁止Tomcat显示目录文件列表
**描述**
Tomcat 允许显示目录文件列表会引发目录遍历漏洞
**加固建议**
修改 `Tomcat` 跟目录下的配置文件 `conf/web.xml`,将 `listings` 的值设置为 `false`。
|
6.5 开启日志记录
**描述**
Tomcat 需要保存输出日志,以便于排除错误和发生安全事件时,进行分析和定位
**加固建议**
1、修改 Tomcat 根目录下的 `conf/server.xml` 文件。
2、取消 `Host` 节点下 `Valve` 节点的注释(如没有则添加)。
|
3、重新启动Tomcat
6.6 禁止显示异常调试信息
**描述**
当请求处理期间发生运行时错误时,ApacheTomcat 将向请求者显示调试信息。建议不要向请求者提供此类调试信息。
**加固建议**
在 Tomcat 根目录下的 `conf/web.xml` 文件里面的 `web-app` 添加子节点:
|
在 `webapps` 目录下创建 `error.jsp` ,定义自定义错误信息
6.7 Tomcat进程运行权限检测
**描述**
在运行 `Internet` 服务时,最好尽可能避免使用 `root` 用户运行,降低攻击者拿到服务器控制权限的机会。
**加固建议**
创建低权限的账号运行 `Tomcat`,操作步骤如下:
|
6.8 Tomcat目录权限检测
**描述**
在运行Tomcat服务时,避免使用root用户运行,tomcat目录(catalina.home、 catalina.base目录)所有者应改为非root的运行用户
**加固建议**
使用 `chown -R <Tomcat启动用户所属组>:<Tomcat启动用户> <Tomcat目录>` 修改 `tomcat` 目录文件所有者,如
|
6.9 禁止自动部署
**描述**
配置自动部署,容易被部署恶意或未经测试的应用程序,应将其禁用
**加固建议**
修改 `Tomcat` 根目录下的配置文件 `conf/server.xml`,将 `host` 节点的 `autoDeploy` 属性设置为 `“false”`,如果 `host` 的`deployOnStartup`属性(如没有`deployOnStartup`配置可以忽略)为`“true”`,则也将其更改为`“false”`
七、Docker安全基线
7.1 确保docker.sock不被挂载
**描述**
`docker.sock`挂载的容器容易被获取特殊权限,一旦危险进入到`docker`中,严重影响了宿主机的安全
**加固建议**
按照提示`<image name><container name>`查找启动的docker容器 , 以非`docker`挂载`docker.sock`的形式重新启动容器
|
7.2 不共享主机的进程名称空间
**描述**
进程`ID(PID)`命名空间隔离了进程`ID`号空间,这意味着不同`PID`命名空间中的进程可以具有相同的`PID`。这是容器和主机之间的进程级别隔离。
`PID`名称空间提供了流程分离。`PID`命名空间删除了系统进程的视图,并允许进程`ID`重复使用,包括`PID1`。如果主机的`PID`命名空间与容器共享,则它将基本上允许容器内的进程查看主机上的所有进程。系统。这破坏了主机和容器之间的进程级别隔离的好处。有权访问容器的人最终可以知道主机系统上正在运行的所有进程,甚至可以从容器内部杀死主机系统进程。这可能是灾难性的。因此,请勿与容器共享主机的进程名称空间。
**加固建议**
不要使用`--pid = host`参数启动容器。
7.3 不要使用特权容器
**描述**
使用`--privileged`标志将所有`Linux`内核功能赋予容器,从而覆盖`--cap-add`和`--cap-drop`标志。确保不使用它。
`--privileged`标志为容器提供了所有功能,并且还解除了设备`cgroup`控制器强制执行的所有限制。
换句话说,容器可以完成主机可以做的几乎所有事情。存在此标志是为了允许特殊用例,例如在`Docker`中运行`Docker`
**加固建议**
不要使用`--privileged`标志运行容器
7.4 不要使用aufs存储驱动程序
**描述**
`“aufs”`存储驱动程序是最早的存储驱动程序。它基于`Linux`内核补丁集,该补丁集不太可能合并到主要`Linux`内核中。还已知`“aufs”`驱动程序会导致一些严重的内核崩溃。`'aufs'`刚刚获得了Docker的支持。最重要的是,许多使用最新`Linux`内核的`Linux`发行版都不支持`'aufs'`驱动程序。
**加固建议**
不要明确使用`“aufs”`作为存储驱动程序。例如,请勿按以下方式启动`Docker`守护程序:
若以`systemctl`管理`docker`服务则需要编辑`/usr/lib/systemd/system/docker.service`的`ExecStart`参数删除`--storage-driver aufs`重启`docker`服务
|
7.5 允许Docker对iptables进行更改
**描述**
`iptables`用于在Linux内核中设置,维护和检查`IP`数据包过滤器规则表。允许`Docker`守护程序对`iptables`进行更改。
如果您选择这样做,`Docker`将永远不会对您的系统`iptables`规则进行更改。如果允许,`Docker`服务器将根据您为容器选择网络选项的方式自动对`iptables`进行所需的更改。建议让`Docker`服务器自动对`iptables`进行更改,以避免网络配置错误,这可能会妨碍容器之间以及与外界的通信。此外,每次选择运行容器或修改网络选项时,它都可以避免更新`iptables`的麻烦。
**加固建议**
不使用`--iptables = false`参数运行`Docker`守护程序。
若以`systemctl`管理`docker`服务则需要编辑`/usr/lib/systemd/system/docker.service`的`ExecStart`参数删除`--iptables = false`, 重启`docker`服务
|
7.6 设置日志记录级别
**描述**
设置适当的日志级别,将`Docker`守护程序配置为记录您以后想要查看的事件。基本日志级别为“`info`”及更高版本将捕获除调试日志以外的所有日志。直到且除非有必要,否则您不应在“`debug`”日志级别运行`Docker`守护程序
**加固建议**
运行`Docker`守护程序,如下所示:
|
若以`systemctl`管理docker服务则需要编辑`/usr/lib/systemd/system/docker.service`的`ExecStart`参数添加`--log-level="info"`,并重启`docker`
|
7.7 确认docker相关的文件具有合适的权限
**描述**
确保可能包含敏感参数的文件和目录的安全对确保`Docker`守护程序的正确和安全运行至关重要
**加固建议**
执行以下命令为`docker`相关文件配置权限:
|
若文件路径与实际系统中不同可以使用以下命令获取文件路径:
|
7.8 将容器的根文件系统挂载为只读
**描述**
容器的根文件系统应被视为“黄金映像”,并且应避免对根文件系统的任何写操作。您应该显式定义用于写入的容器卷。
您不应该在容器中写入数据。属于容器的数据量应明确定义和管理。在管理员控制他们希望开发人员在何处写入文件和错误的许多情况下,这很有用。
**加固建议**
添加“ `--read-only`”标志,以允许将容器的根文件系统挂载为只读。可以将其与卷结合使用,以强制容器的过程仅写入要保留的位置。您应该按以下方式运行容器:
|
如果您是`k8s`或其他容器编排软件编排的容器,请按照相应的安全策略配置或忽略。
7.9 为Docker启用内容信任
**描述**
默认情况下禁用内容信任。您应该启用它。
内容信任提供了将数字签名用于发送到远程`Docker`注册表和从远程`Docker`注册表接收的数据的功能。这些签名允许客户端验证特定图像标签的完整性和发布者。这确保了容器图像的出处
**加固建议**
要在`bash shell`中启用内容信任,请输入以下命令:
|
或者,在您的配置文件中设置此环境变量,以便在每次登录时启用内容信任。内容信任目前仅适用于公共`Docker Hub`的用户。当前不适用于`Docker Trusted Registry`或私有注册表。
7.10 限制容器的内存使用量
**描述**
默认情况下,`Docker`主机上的所有容器均等地共享资源。通过使用`Docker`主机的资源管理功能(例如内存限制),您可以控制容器可能消耗的内存量。
默认情况下,容器可以使用主机上的所有内存。您可以使用内存限制机制来防止由于一个容器消耗主机的所有资源而导致的服务拒绝,从而使同一主机上的其他容器无法执行其预期的功能。对内存没有限制可能会导致一个问题,即一个容器很容易使整个系统不稳定并因此无法使用。
**加固建议**
仅使用所需的内存来运行容器。始终使用`--memory`参数运行容器。您应该按以下方式启动容器:
|
7.11 不要在容器上挂载敏感的主机系统目录
**描述**
不允许将以下敏感的主机系统目录作为容器卷挂载,尤其是在读写模式下。
|
如果敏感目录以读写模式挂载,则可以对那些敏感目录中的文件进行更改。这些更改可能会降低安全隐患或不必要的更改,这些更改可能会使Docker主机处于受损状态。
如果您是k8s或其他容器编排软件编排的容器,请依照相应的安全策略配置或忽略。
**加固建议**
不要在容器上挂载主机敏感目录,尤其是在读写模式下
7.12 限制容器之间的网络流量
**描述**
默认情况下,同一主机上的容器之间允许所有网络通信。如果不需要,请限制所有容器间的通信。将需要相互通信的特定容器链接在一起。默认情况下,同一主机上所有容器之间都启用了不受限制的网络流量。因此,每个容器都有可能读取同一主机上整个容器网络上的所有数据包。这可能会导致意外和不必要的信息泄露给其他容器。因此,限制容器间的通信。
**加固建议**
在守护程序模式下运行`docker`并传递`--icc = false`作为参数。例如,
|
若使用`systemctl`管理`docker`服务则需要编辑
|
文件中的`ExecStart`参数添加 `--icc=false`选项 然后重启`docker`服务
|
7.13 审核Docker文件和目录
**描述**
除了审核常规的`Linux`文件系统和系统调用之外,还审核所有与`Docker`相关的文件和目录。`Docker`守护程序以“ `root`”特权运行。其行为取决于某些关键文件和目录。如 `/var/lib/docker`、`/etc/docker`、`docker.service`、 `docker.socket`、`/usr/bin/docker-containerd`、`/usr/bin/docker-runc`等文件和目录
**加固建议**
在`/etc/audit/audit.rules`与`/etc/audit/rules.d/audit.rules`文件中添加以下行:
|
然后,重新启动`audit`程序。例如
|
八、Elasticsearch安全基线
8.1 ES未授权访问
**描述**
> ElasticSearch是一款Java编写的企业级搜索服务,未加固情况下启动服务存在未授权访问风险,可被非法查询或操作数据,需立即修复加固。
**加固建议**
限制`http`端口的`IP`访问,不对公网开放
修改主目录下 `config/elasticsearch.yml` 配置文件,将`network.host`配置为内网地址或者`127.0.0.1`
|
使用`x-pack`插件为`Elasticsearch`访问增加登录验证
1. 在主目录下运行 `bin/elasticsearch-plugin install x-pack` 安装x-pack插件
2. `config/elasticsearch.yml` 配置文件增加以下配置
|
运行命令
|
为`ES`服务设置密码,重启`ES`服务
推荐阅读 点击标题可跳转
聊平台,先谈主数据
聊平台,再谈元数据
聊平台,需谈数据元
医院信息集成平台(ESB)数据集成建设方案医院信息集成平台项目建设方案与实践 第1章 项目建设背景
医院信息集成平台项目建设方案与实践 第2章 医院信息化现状及...
医院信息集成平台项目建设方案与实践 第3章 项目建设必要性
医院信息集成平台项目建设方案与实践 第4章 项目建设设计(一)
医院信息集成平台项目建设方案与实践 第4章 项目建设设计(二)
医院信息集成平台项目建设方案与实践 第4章 项目建设设计(三)
加微信:wonter 发送:技术Q
医疗微信群:
加微信:wonter 发送:医疗Q
更多文章关注公众号: