業務標簽：醫院資訊集成平臺、互聯網醫院、互聯網護理、慢性病隨訪
技術標簽：ESB、ETL+CDC、NLP、FaaS、SaaS、Hadoop、MicroService
技術微信群：
加微信：wonter 發送：技術Q
醫療微信群：
加微信：wonter 發送：醫療Q
互聯網醫院實施方案（一）實施前準備
互聯網醫院實施方案（二）對接HIS標準介面
互聯網醫院實施方案（三）實施計劃
東軟集成平臺調研方案分析（一）
醫惠集成平臺調研方案分析（二）
曼荼羅集成平臺調研方案分析（四）
關注公眾號查看
一、系統安全基線
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章 專案建設設計（三）
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/275645.html
標籤：其他