業務標籤：醫院信息集成平臺、互聯網醫院、互聯網護理、慢性病隨訪
技術標籤：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章 項目建設設計（三）
