等保測評2.0：應用安全審計、入侵防范

1. 說明

本篇文章主要應用系統測評時安全審計、入侵防范控制點的相關內容和理解，以及linux系統使用密鑰登錄的相關內容。

 2. 安全審計測評項

a)應啟用安全審計功能，審計覆蓋到每個用戶，對重要的用戶行為和重要安全事件進行審計；
b)審計記錄應包括事件的日期和時間、用戶、事件類型、事件是否成功及其他與審計相關的信息；
c)應對審計記錄進行保護，定期備份，避免受到未預期的刪除、修改或覆蓋等；
d)應對審計進程進行保護，防止未經授權的中斷。

 3. 安全審計測評項a

a)應啟用安全審計功能，審計覆蓋到每個用戶，對重要的用戶行為和重要安全事件進行審計；

3.1. 高風險

這個測評項可能存在高風險，如果應用系統沒有任何日志審計功能的話：

3.2. 避免高風險

對于應用系統而言，最好的就是存在比較完善的操作日志，什么用戶什么時間干了什么，都記錄的清清楚楚，那就是絕對的符合。

但是很多應用系統這方面的功能并不全，可能僅存在登錄日志，但這也行，至少可以判定為部分符合。

如果被測評項系統找不到什么日志功能，可以考慮去業務流程模塊去看看。

很多政府部門的應用系統在業務流程記錄這是很詳細的，某人什么時候對某業務進行了什么操作，這也能判定為部分符合。

如果這也沒有，可以考慮去看看中間件的日志，勉強也能算一個擦邊球，至少可以當做是修正的理由。

如果中間件的日志也沒有，那就算了吧，還是直接給判定成高風險吧。

 4. 安全審計測評項 b

b)審計記錄應包括事件的日期和時間、用戶、事件類型、事件是否成功及其他與審計相關的信息；

沒什么好說的，有什么字段就寫什么字段，至少應該包括事件、日期、用戶、具體操作這四個字段，要不然就是部分符合。

 5. 安全審計測評項c

c)應對審計記錄進行保護，定期備份，避免受到未預期的刪除、修改或覆蓋等；

5.1. 審計記錄進行保護

很多情況下應用界面系統中并沒有做記錄的刪除功能，非要刪除就得跑去數據庫或服務器上刪除。

這種情況下，這個要求我覺得是符合的。

如果存在刪除功能，比如日志刪除的按鈕，就要看是這個按鈕的權限是如何分配的，是否僅分配給某些賬戶。

5.2. 定期備份

如果記錄存儲在數據庫中，實際就是看數據庫是否定期備份。

如果記錄存儲在文件中，則看文件是否定期備份。

5.3. 隱藏要求——留存時間

在高風險判定指引中已經進行了明確的說明：

而且這是從2級開始就可以判定成高風險的。

檢查方法也很簡單，查看最早的記錄距離現在是否超過6個月。

如果沒有，除非上線日期沒有超過6個月，否則沒有任何辦法進行修正，絕對的高風險。

 6. 安全審計測評項d

d)應對審計進程進行保護，防止未經授權的中斷。

其實還是一樣，很多應用系統并沒有審計策略的設置功能，所以這種情況下我覺得是默認符合的。

當然，如果有設置功能的話，也是要看看這個設置功能的權限是如何分配的。

 7. 入侵防范測評項

a)應遵循最小安裝的原則，僅安裝需要的組件和應用程序；
b)應關閉不需要的系統服務、默認共享和高危端口；
c)應通過設定終端接入方式或網絡地址范圍對通過網絡進行管理的管理終端進行限制；
d)應提供數據有效性檢驗功能，保證通過人機接口輸入或通過通信接口輸入的內容符合系統設定要求；
e)應能發現可能存在的已知漏洞，并在經過充分測試評估后，及時修補漏洞；
f)應能夠檢測到對重要節點進行入侵的行為，并在發生嚴重入侵事件時提供報警。

其中的a、b、c、f項，根據測評要求里的說明，對于應用系統而言，都是不適用項

 8. 入侵防范測評項d

d)應提供數據有效性檢驗功能，保證通過人機接口輸入或通過通信接口輸入的內容符合系統設定要求；

8.1. SQL注入

這個只能自己去測試了，比如在登錄頁面用萬能密碼去試一試：

https://www.cnblogs.com/pass-A/p/11134988.html

asp aspx萬能密碼
1："or "a"="a
2：'.).or.('.a.'='.a 
3：or 1=1--
4：'or 1=1--
5：a'or' 1=1--
6："or 1=1--
7：'or.'a.'='a
8："or"="a'='a
9：'or''='

或者對三級系統進行滲透的時候一塊做了。

理論上你也可以讓對方提供你源代碼或者系統設計文檔，查看是否在技術層面防止SQL注入。

比如使用sql參數化來避免sql注入，類似于以下的C#代碼：

sql注入就是利用程序員在編寫代碼時，為了實現便捷或者靈活的方式，對sql語句進行字符串拼接。

一旦進行拼接，又未對前端傳入的字符串未進行檢查，就和可能被注入。

而sql參數化可從根本上避免注入，網上的說明如下：

當然，并不是說你用了參數化就肯定能避免注入，如果你在使用參數化的同時仍然進行拼接，比如表名、數據庫名，那還是存在漏洞。

或者對方使用waf等安全產品，那么雖然測評項的結果不受到影響，但是可以對相對于的高風險進行修正：

這里說一說云盾，用阿里云的云盾作為例子，它是存在多個版本的，最低等級的免費版其實基本就沒有什么功能，并不能用來作為修正的理由。

其他云的云盾也去查詢產品文檔，看被測評系統使用的那個版本的云盾具體有什么功能。

阿里云云盾的文檔如下：

https://help.aliyun.com/knowledge_detail/42306.html?spm=a2c4g.11186623.6.546.267416edzw231C

8.2. 數據類型校驗

比如要求輸入金額、數字的地方，輸入字母等非法數據是否可以提交。

或者輸入負數，以及一些類型雖然沒錯但是明顯不符合業務邏輯的數字，看是否可以提交。

具體的測評方法可以參考等保測評2.0：應用身份鑒別（上）第5章的那些方法，同樣的，理論上應該是前端和后端都要進行測試才對。

注意：測試的時候一定要經過對方的同意。

 9. 入侵防范測評項e

e)應能發現可能存在的已知漏洞，并在經過充分測試評估后，及時修補漏洞；

首先，訪談被測評人員，是否有定期對應用系統進行掃描或滲透測試（對于c/s架構的以滲透為主），或購買了這樣的安全服務。

然后，如果對方說有，就讓其提交相關的掃描報告、滲透報告。

如果對方提供了，就要對其中的漏洞進行測試，判斷是否進行了修補。（可以放在滲透的過程中一起做）

基本上應該可以判定為部分符合或者符合

如果對方并沒有定期掃描、滲透，那么這這一項就可以直接判定為不符合。

但是是否判定為高風險：

這個就需要看測評過程中，對應用就行漏洞掃描、滲透測試是，有沒有發現高危漏洞。

如果沒有，就可以用這個理由去修正，降低風險。

 10. linux密鑰登錄

以前不知道在哪一篇文章說過，這里不具體介紹怎么配置，僅介紹和測評相關的內容。

生成好私鑰、公鑰后，在sshd_config文件中進行配置：

#是否允許用戶自行使用成對的密鑰系統進行登入行為，僅針對 version 2。
#至于自制的公鑰數據就放置于用戶家目錄下的 .ssh/authorized_keys 內
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

#有了證書登錄了，就禁用密碼登錄吧，安全要緊
PasswordAuthentication no

當時我沒說清楚的地方就是，私鑰時怎么和用戶名聯系起來的，因為使用密鑰登錄的時候還是需要輸入用戶名的。

另外一點就是，生成私鑰的時候可以設置密碼，如果設置了，使用證書登錄的時候也需要輸入這個密碼，這個密碼起了什么樣的作用。

10.1. 私鑰和用戶

其實就通過AuthorizedKeysFile這個參數聯系起來的，這個參數的值是一個路徑，這個路徑的根目錄即為登錄用戶的主目錄 。

所以如果參數的值是“.ssh/authorized_keys”，就意味著登錄的時候會跑去該用戶的主目錄下的ssh文件夾中尋找authorized_keys（公鑰）來進行驗證。

所以說理論上一對公鑰、私鑰可以同時用于多個用戶登錄，只要每個用戶主目錄下的ssh文件夾中的authorized_keys都是同一個公鑰，那就可以用同一個私鑰來登錄。

10.2. 私鑰的密碼

生成私鑰的時候設置密碼，其實就是給私鑰文件進行了加密，所以這個密碼就是用于提交私鑰的時候解密用的。

舉個不大恰當的例子，就類似于某個壓縮包設置了加密密碼一樣。

解密的過程僅發生在客戶端：

也沒什么數據庫或者文件來對比，應該是解密正確后，其格式有一些規律，能夠判斷解密是否正確。

至于客戶端怎么知道用什么樣的算法去解密，應該是這樣的信息直接記錄在私鑰文件中：

未加密過的私鑰大概是這樣的：

你也可以直接在網上找一個轉換的網站，輸入密碼，可以把加密的私鑰轉換為未加密的私鑰。

這樣在使用密鑰登錄的時候就不需要使用密碼了。

從這一點也可以證明，客戶端也只是在讀取私鑰后得知其實加密文件從而需要解密，和服務器那邊沒啥鬼關系.