目錄
安掃五項
1.代碼檢測
2.主機基線
nginx合規檢查
麒麟基線
3.WEB掃描
4.滲透測試
用戶枚舉漏洞
漏洞描述
修復建議
點擊劫持漏洞
漏洞描述
修復建議
XSS漏洞
漏洞描述
修復建議
3.主機漏洞
超高危漏洞
高危漏洞
中危漏洞
低危漏洞
?信息漏洞
參考信息
安掃五項
項目安全檢測一般分為五項：主機漏掃，主機基線，代碼檢測，滲透測試，web掃描
檢測順序，主機漏掃，主機基線，代碼檢測，滲透測試和web掃描（該兩項在代碼就檢測修復或者沒問題后進行，代碼檢測項目組完成）
1.代碼檢測
Java代碼漏洞檢測-常見漏洞與修復建議-CSDN博客
2.主機基線
nginx合規檢查
| 日志審計 | 檢查是否啟用日志功能---記錄訪問日志 | |
| 其它安全 | 檢查是否限制客戶端下載的并發連接數 | |
| 檢查是否配置防盜鏈接設置 | ||
| 描述 | 序號：檢查點（結果） | 標準值 | 實際值 | 配置方法 |
| 檢查是否啟用日志功能---記錄錯誤日志 | 1:應配置日志功能對錯誤日志進行記錄(是) | error_log | error_log? /data/nginx/logs/error.log; | 編輯nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf)，去掉error_log前面的"#"號 |
| 檢查是否啟用日志功能---記錄訪問日志 | 1:應設置access_log文件格式(否) | log_format | 編輯nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf)，設置access_log，去掉前面的注釋，修改配置文件如下：? log_format? formatname? '$remote_addr - $remote_user [$time_local] '? ????????????? ' "$request" $status $body_bytes_sent "$http_referer" '? ????????????? ' "$http_user_agent" "$http_x_forwarded_for"'; ? access_log? logs/access.log? formantname;??? ? formatname是設置配置文件格式的名稱 | |
| 1:設備應配置日志功能，對訪問日志進行記錄(是) | access_log | access_log? /data/nginx/logs/access.log; | 編輯nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf)，去掉#access_log? logs/access.log? formatname;前面的"#"號? formatname是設置配置文件格式的名稱 | |
| 檢查是否隱藏nginx版本信息 | 1:應修改nginx服務信息頭內容，隱藏nginx版本信息(是) | server_tokens off; | server_tokens off; | 修改nginx解壓路徑(eg:/usr/local/nginx-1.5.6/src/http/ngx_http_header_filter_module.c)文件的第48和49行內容，自定義頭信息：? static char ngx_http_server_string[] = “Server:XXXXX.com” CRLF;? static char ngx_http_server_full_string[] = “Server:XXXXX.com” CRLF;? 添加如下代碼到nginx.conf(eg:/usr/local/nginx/conf/nginx.conf)配置文件，禁止錯誤頁面中顯示nginx版本號：? server_tokens off;? 注意，句尾的分號不能少 |
| 檢查是否自定義錯誤信息 | 1:應自定義nginx返回的錯誤信息(是) | /^\s*error_page[\s\S]+/ | error_page?? 500 502 503 504? /50x.html; | 修改nginx_install_dir/conf/nginx.conf文件? 在每個站點server里添加自定義錯誤頁面，例如：? error_page? 404????????????? /404.html;? 404.html為具體的自定義錯誤頁面，需要放在站點的根目錄下，一般是在nginx_install_dir/html/目錄下? ? 配置完畢后采用nginx_install_dir/sbin/nginx -t測試配置文件是否正確。? 之后平滑重啟nginx? nginx_install_dir/sbin/nginx -s reload? |
| 檢查是否控制超時時間---客戶端保持活動的超時時間 | 1:設置客戶端連接保持活動的超時時間(是) | /\d+\s*\d*/ | 65 | 編輯nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf)? 具體設置如下：? keepalive_timeout 5 5;? #第一個參數指定客戶端連接保持活動的超時時間，第二個參數是可選的，它指定了消息頭保持活動的有效時間? 重新啟動nginx服務? 需要根據應用場景的需要選擇合適的參數值? |
| 檢查是否控制超時時間---客戶端請求讀取超時時間 | 1:設置客戶端請求頭讀取超時時間(是) | /\d+/ | 30 | 編輯nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf)? 具體設置如下：? client_header_timeout 10;? #設置客戶端請求頭讀取超時時間? 重新啟動nginx服務? 需要根據應用場景的需要選擇合適的參數值? |
| 1:設置客戶端請求主體讀取超時時間(是) | /\d+/ | 30 | 編輯nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf)? 具體設置如下：? client_body_timeout 10;? #設置客戶端請求主體讀取超時時間? 重新啟動nginx服務? 需要根據應用場景的需要選擇合適的參數值 | |
| 檢查是否限制客戶端下載的并發連接數 | 1:應設置存儲session狀態的容器(否) | limit_zone | 編輯nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf)? 具體設置如下：? 例如網站存放路徑為/usr/local/nsfocus/ ，服務器名稱為：down.nsfocus.com? http {? ……? limit_zone one $binary_remote_addr 10m; ? #針對每個IP定義一個存儲session狀態的容器，10m的容器按照32bytes/session，可以處理320000個session? server? {? ???? listen?? 80? ???? server_name down.nsfocus.com;? ???? index index.html index.htm index.php;? ???? root? /usr/local/nsfocus;? ???? #Zone limit;? ???? location / {? ???????? limit_conn one 1; #限制每個ip只能發起一個并發連接? ???????? limit_rate 20k; #限制每個連接的限制速度為20K，IP的下載速度為連接數*限制速度? ???? }? ………? }? 重啟nginx服務? 根據應用場景的需要進行并發數、速度限制? 注：? limit_zone 這個變量只能在http中使用? limit_coon和limit_rate變量可以在http,server,location中使用 | |
| 1:應設置客戶端下載的連接并發數（每個IP的連接并發數）(否) | /\d+/ | 編輯nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf)? 具體設置如下：? 例如網站存放路徑為/usr/local/nsfocus/ ，服務器名稱為：down.nsfocus.com? http {? ……? limit_zone one $binary_remote_addr 10m; ? #針對每個IP定義一個存儲session狀態的容器，10m的容器按照32bytes/session，可以處理320000個session? server? {? ???? listen?? 80? ???? server_name down.nsfocus.com;? ???? index index.html index.htm index.php;? ???? root? /usr/local/nsfocus;? ???? #Zone limit;? ???? location / {? ???????? limit_conn one 1; #限制每個ip只能發起一個并發連接? ???????? limit_rate 20k; #限制每個連接的限制速度為20K，IP的下載速度為連接數*限制速度? ???? }? ………? }? 重啟nginx服務? 根據應用場景的需要進行并發數、速度限制? 注：? limit_zone 這個變量只能在http中使用? limit_coon和limit_rate變量可以在http,server,location中使用 | ||
| 檢查是否控制超時時間---響應客戶端的超時時間 | 1:設置響應客戶端的超時時間(是) | /\d+/ | 30 | 編輯nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf)? 具體設置如下：? send_timeout 10;? #指定響應客戶端的超時時間? 重新啟動nginx服務? 需要根據應用場景的需要選擇合適的參數值? |
| 檢查是否配置防盜鏈接設置 | 1:應配置防止其他網站盜鏈本網站資源(否) | location ~* ^.+\. | 編輯nginx.conf文件(eg:/usr/local/nginx/conf/nginx.conf)? 具體設置舉例如下：? location ~* ^.+\.(gif|jpg|png|swf|flv|rar|zip)$ { ? ??? valid_referers none blocked www.baidu.com; ? ??? if ($invalid_referer) {? ???????? rewrite ^/ [img]http://www.nsfocus.com/images/default/logo.gif[/img];? ??????? # return 403;? ??? } ? } ? 根據應用場景，設置合適的域名? 重新啟動nginx服務? 注：? 1.gif|jpg|png|swf|flv|rar|zip? 表示對gif、jpg、png、swf、flv后綴的文件實行防盜鏈? 2.www.baidu.com? 表示對www.baidu.com這個來路進行判斷? 3.if{}里面內容的意思是，如果來路不是指定來路就跳轉到錯誤頁面，當然直接返回404也是可以的 |
麒麟基線
| 檢查項名 | 檢查項類別 | 檢查內容 | 檢查說明 |
| 麒麟-檢查是否禁止匿名用戶登錄FTP | 協議安全 | 若vsfptd開啟，/etc/vsftpd.conf或者/etc/vsftpd/vsftpd.conf中應存在anonymous_enable=NO and 禁止匿名WU-FTP用戶登錄 | 文件傳輸協議（FTP）支持網絡計算機傳輸文件功能。 |
| 麒麟-檢查是否修改snmp默認團體字 | 協議安全 | 檢查是否安裝snmp服務 檢查配置文件/etc/snmp/snmpd.conf是否存在。 檢查snmp團體字是否未使用public 檢查snmp團體字是否未使用private | 檢查配置文件/etc/snmp/snmpd.conf是否存在 檢查snmp團體字是否未使用public 檢查snmp團體字是否未使用private |
| 麒麟-檢查重要目錄或文件權限設置 | 系統文件權限 | 檢查以下文件權限是否符合規范： /etc/group文件權限是否符合規范?<=?644? /etc/shadow文件權限是否符合規范?<=?600? /etc/passwd文件權限是否符合規范?<=?644? /etc/rc.d/init.d/文件權限是否符合規范?<=?750? /etc/rc4.d文件權限是否符合規范?<=?750? /etc/rc3.d文件權限是否符合規范?<=?750? /etc/rc6.d文件權限是否符合規范?<=?750? /etc/rc0.d文件權限是否符合規范?<=?750? /etc/rc2.d文件權限是否符合規范?<=?750? /etc/rc5.d文件權限是否符合規范?<=?750? /etc/xinetd.conf文件權限是否符合規范?<=?600? /etc/services文件權限是否符合規范?<=?644? 檢查系統引導器配置文件權限?<=?600? /etc/rc1.d/文件權限是否符合規范?<=?750? /etc/security目錄權限是否符合規范?<=?600 | 檢查重要目錄或文件權限設置 |
| 麒麟-檢查使用IP協議遠程維護的設備是否配置SSH協議，禁用telnet協議 | 協議安全 | 對于使用IP協議進行遠程維護的設備，應配置使用SSH協議 and ( 對于使用IP協議進行遠程維護的設備，應禁止使用telnet協議 or 是否存在telnet進程 ) | 檢查使用IP協議遠程維護的設備是否配置SSH協議，禁用telnet協議 |
| 麒麟-檢查設備密碼復雜度策略 | 配置PAM認證 | 檢查密碼復雜度是否設置種類為3或更復雜。 | 檢查密碼復雜度是否設置種類為3或更復雜。 |
| 麒麟-檢查是否按用戶分配賬號 | 其他安全 | 檢查是否按用戶分配賬號 | 用戶賬號唯一）應為操作系統和數據庫系統的不同用戶分配不同 的用戶名，確保用戶名具有唯一性。檢查是否按用戶分配賬號。 |
| 麒麟-檢查是否按組進行賬號管理 | 其他安全 | 檢查是否按組進行賬號管理 | 確定賬號屬組）應確定系統賬號屬組是否正確，檢查是否按組進行賬號管理。 |
| 麒麟-檢查口令最小長度 | 配置PAM認證 | 檢查密碼是否設置最小長度為6 | pam_pwquality.so模塊檢查密碼的強度。它執行檢查，例如確保密碼不是字典詞匯，符合一定長度，包含字符（例如字母，數字，其他）等等的混合。 |
| 麒麟-檢查命令行界面超時時間 | 其他安全 | 檢查命令行界面超時時間 | 檢查命令行界面超時時間 |
| 麒麟-檢查是否配置用戶所需最小權限 | 其他安全 | 檢查/etc/passwd文件權限 and 檢查/etc/shadow文件權限 and 檢查/etc/group文件權限 | 檢查是否配置用戶所需最小權限 |
| 麒麟-檢查root是否為唯一的UID為0用戶 | 身份鑒別 | 檢查是否存在除root之外UID為0的用戶 | 確定賬號屬組）應確定系統賬號屬組是否正確。任何UID為0的賬戶都具有系統的超級用戶權限。 |
| 麒麟-檢查是否啟用遠程日志功能 | 日志 | 1 、判定條件 設備配置遠程日志功能，將需要重點關注的日志內容傳輸到日志服務器。 2 、檢測操作 查看日志服務器上的所收到的日志文件。 3 、補充說明 | 設備配置遠程日志功能，將需要重點關注的日志內容傳輸到日志服務器。 |
| 麒麟-檢查是否啟用cron行為日志功能 | 日志審計 | 檢查是否啟用cron行為日志功能 | 檢查是否啟用cron行為日志功能 |
| 麒麟-檢查是否啟用系統日志功能 | 日志審計 | 檢查是否啟用系統日志功能 | 檢查是否啟用系統日志功能 |
| 麒麟-?檢查是否設置口令生存周期 | 賬號/密碼要求 | 密碼過期時間應：小于等于90天 | 密碼過期時間允許管理員強制密碼在達到定義的壽命后過期。 |
| 麒麟-檢查是否設置口令過期前警告天數 | 賬號/密碼要求 | 口令過期前警告天數應：大于等于30天 | 檢查口令過期前警告天數 |
| 麒麟-檢查是否啟用安全日志功能 | 日志審計 | 檢查是否啟用安全日志功能 | 檢查是否啟用安全日志功能 |
3.WEB掃描
威脅分類
信息泄露類型:資源位置可預測
信息泄露類型:信息泄露
命令執行類型:系統命令執行
邏輯攻擊類型:拒絕服務
客戶端攻擊類型:內容欺騙
中級
| 漏洞名稱 | 詳細描述 | 解決辦法 | 驗證方法 |
| 檢測到目標站點存在javascript框架庫漏洞【可驗證】 | JavaScript 框架或庫是一組能輕松生成跨瀏覽器兼容的 JavaScript 代碼的工具和函數。如果網站使用了存在漏洞的 JavaScript 框架或庫，攻擊者就可以利用此漏洞來劫持用戶瀏覽器，進行掛馬、XSS、Cookie劫持等攻擊。 | 將受影響的javascript框架庫升級到最新版本。 | 根據檢測到目標站點存在javascript框架庫漏洞原理，通過獲取javascript框架庫版本并查看該版本是否在受影響范圍內進行漏洞驗證。 參考驗證：jquery:1.12.0 (Link) https://www.cvedetails.com/cve/CVE-2015-9251/ |
| 檢測到目標主機可能存在緩慢的HTTP拒絕服務攻擊 | 緩慢的HTTP拒絕服務攻擊是一種專門針對于Web的應用層拒絕服務攻擊，攻擊者操縱網絡上的肉雞，對目標Web服務器進行海量HTTP請求攻擊，直到服務器帶寬被打滿，造成了拒絕服務。 慢速HTTP拒絕服務攻擊經過不斷的演變和發展，主要有三種攻擊類型，分別是Slow headers、Slow body、Slow read。以Slow headers為例，Web應用在處理HTTP請求之前都要先接收完所有的HTTP頭部，因為HTTP頭部中包含了一些Web應用可能用到的重要的信息。攻擊者利用這點，發起一個HTTP請求，一直不停的發送HTTP頭部，消耗服務器的連接和內存資源。抓包數據可見，攻擊客戶端與服務器建立TCP連接后，每10秒才向服務器發送一個HTTP頭部，而Web服務器在沒接收到2個連續的\r\n時，會認為客戶端沒有發送完頭部，而持續的等等客戶端發送數據。如果惡意攻擊者客戶端持續建立這樣的連接，那么服務器上可用的連接將一點一點被占滿，從而導致拒絕服務。這種攻擊類型稱為慢速HTTP拒絕服務攻擊。 | 針對不同的Server其對慢速http拒絕服務攻擊防范方法也不同，建議使用以下措施防范慢速http拒絕服務攻擊： WebSphere ======== 1、限制 HTTP 數據的大小 在WebSphere Application Server 中進行如下設置： 任何單個 HTTP 頭的默認最大大小為 32768 字節。可以將它設置為不同的值。 HTTP 頭的默認最大數量為 50。可以將它設置為不同的限制值。 另一種常見的 DOS 攻擊是發送一個請求，這個請求會導致一個長期運行的 GET 請求。WebSphere Application Server Plug-in 中的 ServerIOTimeoutRetry 屬性可限制任何請求的重試數量。這可以降低這種長期運行的請求的影響。 設置限制任何請求正文的最大大小。 2、設置keepalive參數 打開ibm http server安裝目錄，打開文件夾conf，打開文件httpd.conf,查找KeepAlive值，改ON為OFF,其默認為ON。 這個值說明是否保持客戶與HTTP SERVER的連接，如果設置為ON，則請求數到達MaxKeepAliveRequests設定值時請求將排隊，導致響應變慢。 詳見參考鏈接： http://www.ibm.com/developerworks/cn/websphere/techjournal/1210_lansche/1210_lansche.html#new-step32 Weblogic ============ 1、在配置管理界面中的協議->一般信息下設置 完成消息超時時間小于200 2、在配置管理界面中的協議->HTTP下設置 POST 超時、持續時間、最大 POST 大小為安全值范圍。 http://docs.oracle.com/cd/E12890_01/ales/docs32/integrateappenviron/configWLS.html#wp1101063 Nginx ============ 1、通過調整$request_method，配置服務器接受http包的操作限制； 2、在保證業務不受影響的前提下，調整client_max_body_size, client_body_buffer_size, client_header_buffer_size,large_client_header_buffersclient_body_timeout, client_header_timeout的值，必要時可以適當的增加； 3、對于會話或者相同的ip地址，可以使用HttpLimitReqModule and HttpLimitZoneModule參數去限制請求量或者并發連接數； 4、根據CPU和負載的大小，來配置worker_processes 和 worker_connections的值，公式是：max_clients = worker_processes * worker_connections。 Apache ============ 建議使用mod_reqtimeout和mod_qos兩個模塊相互配合來防護。 1、mod_reqtimeout用于控制每個連接上請求發送的速率。配置例如： #請求頭部分，設置超時時間初始為10秒，并在收到客戶端發送的數據后，每接收到500字節數據就將超時時間延長1秒，但最長不超過40秒。可以防護slowloris型的慢速攻擊。 RequestReadTimeout header=10-40,minrate=500 #請求正文部分，設置超時時間初始為10秒，并在收到客戶端發送的數據后，每接收到500字節數據就將超時時間延長1秒，但最長不超過40秒。可以防護slow message body型的慢速攻擊。 RequestReadTimeout body=10-40,minrate=500 需注意，對于HTTPS站點，需要把初始超時時間上調，比如調整到20秒。 示例： LoadModule reqtimeout_module modules/mod_reqtimeout.so <IfModule reqtimeout_module> ??????? RequestReadTimeout header=10-40,minrate=500 body=10-40,minrate=500 </IfModule> 2、mod_qos用于控制并發連接數。配置例如： # 當服務器并發連接數超過600時，關閉keepalive QS_SrvMaxConnClose 600 # 限制每個源IP最大并發連接數為50 QS_SrvMaxConnPerIP 50 這兩個數值可以根據服務器的性能調整。 更多關于qos_module配置參考： http://mod-qos.sourceforge.net/dos.html 示例： LoadModule qos_module modules/mod_qos.so <IfModule qos_module> QS_SrvMaxConnClose 600 QS_SrvMaxConnPerIP 50 </IfModule> IHS服務器 ============ 請您先安裝最新補丁包，然后啟用mod_reqtimeout模塊，在配置文件中加入： LoadModule reqtimeout_module modules/mod_reqtimeout.so 為mod_reqtimeout模塊添加配置： <IfModule mod_reqtimeout.c> RequestReadTimeout header=10-40,MinRate=500 body=10-40,MinRate=500 </IfModule> 對于HTTPS站點，建議header=20-40,MinRate=500。 參見：http://www-01.ibm.com/support/docview.wss?uid=swg21652165 F5負載均衡修復建議 ============ F5負載均衡設備有相應的防護模塊，如無購買可參考附件中的詳細配置過程。 關于F5的慢速攻擊防護配置，請參考以下鏈接： https://support.f5.com/kb/en-us/solutions/public/10000/200/sol10260.html https://devcentral.f5.com/articles/mitigating-slow-http-post-ddos-attacks-with-irules-ndash-follow-up IIS服務器 ============ IIS可配置相關網站的Web.config如下： 1、WebLimits設置： <configuration> ??? <system.applicationHost> ??????? <webLimits connectionTimeout="00:00:30" ??????? headerWaitTimeout="00:00:10" ??????? dynamicIdleThreshold="150" ??????? minBytesPerSecond="512" ??? /> ??? </system.applicationHost> </configuration> 參考以下鏈接： https://docs.microsoft.com/en-us/iis/configuration/system.applicationhost/weblimits#configuration 2、headerLimits設置： <configuration> ?<system.webServer> ? <security> ?? <requestFiltering> ??? <requestLimits> ???? <headerLimits> ???? <add header="Content-type" sizeLimit="100" /> ???? </headerLimits> ??? </requestLimits> ?? </requestFiltering> ? </security> ?</system.webServer> </configuration> 參考以下鏈接： https://docs.microsoft.com/en-us/iis/configuration/system.webserver/security/requestfiltering/requestlimits/headerlimits/ | |
| 檢測到目標URL存在http host頭攻擊漏洞【可驗證】 | 為了方便的獲得網站域名，開發人員一般依賴于HTTP Host header。例如，在php里用_SERVER["HTTP_HOST"]。但是這個header是不可信賴的，如果應用程序沒有對host header值進行處理，就有可能造成惡意代碼的傳入。 | web應用程序應該使用SERVER_NAME而不是host header。? 在Apache和Nginx里可以通過設置一個虛擬機來記錄所有的非法host header。在Nginx里還可以通過指定一個SERVER_NAME名單，Apache也可以通過指定一個SERVER_NAME名單并開啟UseCanonicalName選項。 | 根據檢測到目標URL存在http host頭攻擊漏洞原理，通過修改host頭并根據目標站點的響應情況進行漏洞驗證。 |
???????低級
| 漏洞名稱 | 詳細描述 | 解決辦法 | 驗證方法 |
| 檢測到目標X-Content-Type-Options響應頭缺失【可驗證】 | X-Content-Type-Options HTTP 消息頭相當于一個提示標志，被服務器用來提示客戶端一定要遵循在 Content-Type 首部中對? MIME 類型 的設定，而不能對其進行修改。這就禁用了客戶端的 MIME 類型嗅探行為，換句話說，也就是意味著網站管理員確定自己的設置沒有問題。? ? X-Content-Type-Options響應頭的缺失使得目標URL更易遭受跨站腳本攻擊。 | 將您的服務器配置為在所有傳出請求上發送值為“nosniff”的“X-Content-Type-Options”頭。對于 Apache，請參閱：? http://httpd.apache.org/docs/2.2/mod/mod_headers.html? 對于 IIS，請參閱：? https://technet.microsoft.com/pl-pl/library/cc753133%28v=ws.10%29.aspx? 對于 nginx，請參閱：? http://nginx.org/en/docs/http/ngx_http_headers_module.html | 根據檢測到目標X-Content-Type-Options響應頭缺失漏洞原理，通過從目標站點響應頭信息中檢查X-Content-Type-Options配置情況進行漏洞驗證。 |
| 檢測到目標X-XSS-Protection響應頭缺失【可驗證】 | HTTP X-XSS-Protection 響應頭是 Internet Explorer，Chrome 和 Safari 的一個特性，當檢測到跨站腳本攻擊 (XSS)時，瀏覽器將停止加載頁面。? ? X-XSS-Protection響應頭的缺失使得目標URL更易遭受跨站腳本攻擊。 | 將您的服務器配置為在所有傳出請求上發送值為“1”（例如已啟用）的“X-XSS-Protection”頭。對于 Apache，請參閱：? http://httpd.apache.org/docs/2.2/mod/mod_headers.html? 對于 IIS，請參閱：? https://technet.microsoft.com/pl-pl/library/cc753133%28v=ws.10%29.aspx? 對于 nginx，請參閱：? http://nginx.org/en/docs/http/ngx_http_headers_module.html | 根據檢測到目標X-XSS-Protection響應頭缺失漏洞原理，通過從目標站點響應頭信息中檢查X-XSS-Protection配置情況進行漏洞驗證。 |
| 檢測到目標Content-Security-Policy響應頭缺失【可驗證】 | HTTP 響應頭Content-Security-Policy允許站點管理者控制用戶代理能夠為指定的頁面加載哪些資源。除了少數例外情況，設置的政策主要涉及指定服務器的源和腳本結束點。? ? Content-Security-Policy響應頭的缺失使得目標URL更易遭受跨站腳本攻擊。 | 將您的服務器配置為發送“Content-Security-Policy”頭。對于 Apache，請參閱：? http://httpd.apache.org/docs/2.2/mod/mod_headers.html? 對于 IIS，請參閱：? https://technet.microsoft.com/pl-pl/library/cc753133%28v=ws.10%29.aspx? 對于 nginx，請參閱：? http://nginx.org/en/docs/http/ngx_http_headers_module.html | 根據檢測到目標Content-Security-Policy響應頭缺失漏洞原理，通過從目標站點響應頭信息中檢查Content-Security-Policy配置情況進行漏洞驗證。 |
| 檢測到目標URL存在電子郵件地址模式【可驗證】 | 垃圾郵件程序會搜尋因特網站點，開始查找電子郵件地址來構建發送自發電子郵件（垃圾郵件）的郵件列表。 ? 如果檢測到含有一或多個電子郵件地址的響應，可供利用以發送垃圾郵件。 ? 而且，找到的電子郵件地址也可能是專用電子郵件地址，對于一般大眾應是不可訪問的。 | 根據需求，從 Web 站點中去除無用電子郵件地址，使惡意的用戶無從利用。 | 根據檢測到目標URL存在電子郵件地址模式漏洞原理，通過從目標站點獲取電子郵件地址進行漏洞驗證。 |
| 檢測到目標Referrer-Policy響應頭缺失 | Web 服務器對于 HTTP 請求的響應頭中缺少 Referrer-Policy，這將導致瀏覽器提供的安全特性失效。 當用戶在瀏覽器上點擊一個鏈接時，會產生一個 HTTP 請求，用于獲取新的頁面內容，而在該請求的報頭中，會包含一個 Referrer，用以指定該請求是從哪個頁面跳轉頁來的，常被用于分析用戶來源等信息。但是也成為了一個不安全的因素，所以就有了 Referrer-Policy，用于過濾 Referrer 報頭內容，其可選的項有： no-referrer no-referrer-when-downgrade origin origin-when-cross-origin same-origin strict-origin strict-origin-when-cross-origin unsafe-url 漏洞危害： Web 服務器對于 HTTP 請求的響應頭中缺少 Referrer-Policy，這將導致瀏覽器提供的安全特性失效，更容易遭受 Web 前端黑客攻擊的影響。 | 1）修改服務端程序，給 HTTP 響應頭加上 Referrer-Policy 如果是 java 服務端，可以使用如下方式添加 HTTP 響應頭 response.setHeader("Referrer-Policy", "value") 如果是 php 服務端，可以使用如下方式添加 HTTP 響應頭 header("Referrer-Policy: value") 如果是 asp 服務端，可以使用如下方式添加 HTTP 響應頭 Response.AddHeader "Referrer-Policy", "value" 如果是 python django 服務端，可以使用如下方式添加 HTTP 響應頭 response = HttpResponse() response["Referrer-Policy"] = "value" 如果是 python flask 服務端，可以使用如下方式添加 HTTP 響應頭 response = make_response() response.headers["Referrer-Policy"] = "value"；? 2）修改負載均衡或反向代理服務器，給 HTTP 響應頭加上 Referrer-Policy 如果使用 Nginx、Tengine、Openresty 等作為代理服務器，在配置文件中寫入如下內容即可添加 HTTP 響應頭： add_header Referrer-Policy value; 如果使用 Apache 作為代理服務器，在配置文件中寫入如下內容即可添加 HTTP 響應頭： Header add Referrer-Policy "value"。 | |
| 檢測到目標X-Permitted-Cross-Domain-Policies響應頭缺失 | Web 服務器對于 HTTP 請求的響應頭中缺少 X-Permitted-Cross-Domain-Policies，這將導致瀏覽器提供的安全特性失效。 當一些在線的 Web Flash 需要加載其他域的內容時，很多 Web 會通過設置一個 crossdomain.xml 文件的方式來控制其跨域方式。很有可能有些開發者并沒有修改 crossdomain.xml 文件的權限，但是又有和跨域的 Flash 共享數據的需求，這時候可以通過設置 X-Permitted-Cross-Domain-Policies 頭的方式來替代 crossdomain.xml 文件，其可選的值有： none master-only by-content-type by-ftp-filename all 漏洞危害： Web 服務器對于 HTTP 請求的響應頭中缺少 X-Permitted-Cross-Domain-Policies，這將導致瀏覽器提供的安全特性失效，更容易遭受 Web 前端黑客攻擊的影響。 | 1）修改服務端程序，給 HTTP 響應頭加上 X-Permitted-Cross-Domain-Policies 如果是 java 服務端，可以使用如下方式添加 HTTP 響應頭 response.setHeader("X-Permitted-Cross-Domain-Policies", "value") 如果是 php 服務端，可以使用如下方式添加 HTTP 響應頭 header("X-Permitted-Cross-Domain-Policies: value") 如果是 asp 服務端，可以使用如下方式添加 HTTP 響應頭 Response.AddHeader "X-Permitted-Cross-Domain-Policies", "value" 如果是 python django 服務端，可以使用如下方式添加 HTTP 響應頭 response = HttpResponse() response["X-Permitted-Cross-Domain-Policies"] = "value" 如果是 python flask 服務端，可以使用如下方式添加 HTTP 響應頭 response = make_response() response.headers["X-Permitted-Cross-Domain-Policies"] = "value"；? 2）修改負載均衡或反向代理服務器，給 HTTP 響應頭加上 X-Permitted-Cross-Domain-Policies 如果使用 Nginx、Tengine、Openresty 等作為代理服務器，在配置文件中寫入如下內容即可添加 HTTP 響應頭： add_header X-Permitted-Cross-Domain-Policies value; 如果使用 Apache 作為代理服務器，在配置文件中寫入如下內容即可添加 HTTP 響應頭： Header add X-Permitted-Cross-Domain-Policies "value"。 | |
| 檢測到目標X-Download-Options響應頭缺失 | Web 服務器對于 HTTP 請求的響應頭中缺少 X-Download-Options，這將導致瀏覽器提供的安全特性失效。 漏洞危害: Web 服務器對于 HTTP 請求的響應頭中缺少 X-Download-Options，這將導致瀏覽器提供的安全特性失效，更容易遭受 Web 前端黑客攻擊的影響。 | 1）修改服務端程序，給 HTTP 響應頭加上 X-Download-Options 如果是 java 服務端，可以使用如下方式添加 HTTP 響應頭 response.setHeader("X-Download-Options", "value") 如果是 php 服務端，可以使用如下方式添加 HTTP 響應頭 header("X-Download-Options: value") 如果是 asp 服務端，可以使用如下方式添加 HTTP 響應頭 Response.AddHeader "X-Download-Options", "value" 如果是 python django 服務端，可以使用如下方式添加 HTTP 響應頭 response = HttpResponse() response["X-Download-Options"] = "value" 如果是 python flask 服務端，可以使用如下方式添加 HTTP 響應頭 response = make_response() response.headers["X-Download-Options"] = "value"；? 2）修改負載均衡或反向代理服務器，給 HTTP 響應頭加上 X-Download-Options 如果使用 Nginx、Tengine、Openresty 等作為代理服務器，在配置文件中寫入如下內容即可添加 HTTP 響應頭： add_header X-Download-Options value; 如果使用 Apache 作為代理服務器，在配置文件中寫入如下內容即可添加 HTTP 響應頭： Header add X-Download-Options "value"。 | |
| 檢測到目標Strict-Transport-Security響應頭缺失 | Web 服務器對于 HTTP 請求的響應頭中缺少 Strict-Transport-Security，這將導致瀏覽器提供的安全特性失效。 當 Web 服務器的 HTTP 頭中包含 Strict-Transport-Security 頭時，瀏覽器將持續使用 HTTPS 來訪問 Web 站點，可以用來對抗協議降級攻擊和 Cookie 劫持攻擊。? 其可選的值有： max-age=SECONDS，表示本次命令在未來的生效時間 includeSubDomains，可以用來指定是否對子域名生效 漏洞危害： Web 服務器對于 HTTP 請求的響應頭中缺少 Strict-Transport-Security，這將導致瀏覽器提供的安全特性失效，更容易遭受 Web 前端黑客攻擊的影響。 | 1）修改服務端程序，給 HTTP 響應頭加上 Strict-Transport-Security 如果是 java 服務端，可以使用如下方式添加 HTTP 響應頭 response.setHeader("Strict-Transport-Security", "value") 如果是 php 服務端，可以使用如下方式添加 HTTP 響應頭 header("Strict-Transport-Security: value") 如果是 asp 服務端，可以使用如下方式添加 HTTP 響應頭 Response.AddHeader "Strict-Transport-Security", "value" 如果是 python django 服務端，可以使用如下方式添加 HTTP 響應頭 response = HttpResponse() response["Strict-Transport-Security"] = "value" 如果是 python flask 服務端，可以使用如下方式添加 HTTP 響應頭 response = make_response() response.headers["Strict-Transport-Security"] = "value"；? 2）修改負載均衡或反向代理服務器，給 HTTP 響應頭加上 Strict-Transport-Security 如果使用 Nginx、Tengine、Openresty 等作為代理服務器，在配置文件中寫入如下內容即可添加 HTTP 響應頭： add_header Strict-Transport-Security value; 如果使用 Apache 作為代理服務器，在配置文件中寫入如下內容即可添加 HTTP 響應頭： Header add Strict-Transport-Security "value"。 | |
| 點擊劫持：X-Frame-Options未配置【可驗證】 | 點擊劫持（ClickJacking）是一種視覺上的欺騙手段。攻擊者使用一個透明的、不可見的iframe，覆蓋在一個網頁上，然后誘使用戶在該網頁上進行操作，此時用戶將在不知情的情況下點擊透明的iframe頁面。通過調整iframe頁面的位置，可以誘使用戶恰好點擊在iframe頁面的一些功能性按鈕上。 HTTP 響應頭信息中的X-Frame-Options，可以指示瀏覽器是否應該加載一個 iframe 中的頁面。如果服務器響應頭信息中沒有X-Frame-Options，則該網站存在ClickJacking攻擊風險。網站可以通過設置 X-Frame-Options 阻止站點內的頁面被其他頁面嵌入從而防止點擊劫持。 | 修改web服務器配置，添加X-Frame-Options響應頭。賦值有如下三種： 1、DENY：不能被嵌入到任何iframe或者frame中。 2、SAMEORIGIN:頁面只能被本站頁面嵌入到iframe或者frame中。 3、ALLOW-FROM uri：只能被嵌入到指定域名的框架中。 例如： apache可配置http.conf如下： "<IfModule headers_module> ?Header always append X-Frame-Options "DENY" </IfModule> IIS可配置相關網站的Web.config如下： <system.webServer> ? ... ? <httpProtocol> ??? <customHeaders> ????? <add name="X-Frame-Options" value="deny" /> ??? </customHeaders> ? </httpProtocol> ? ... </system.webServer>" | 根據點擊劫持：X-Frame-Options未配置漏洞原理，通過從目標站點響應頭信息中檢查X-Frame-Options配置情況進行漏洞驗證。 |
| 檢測到目標網站存在上傳下載相關的目錄和文件【可驗證】 | 檢測到目標網站存在上傳下載相關的目錄和文件。上傳目錄一般具有可寫權限。攻擊者可以預測文件上傳的路徑，便于和目標站點的其他漏洞攻擊結合攻擊目標服務器。 | 檢查此類目錄的訪問權限。如果不需要這些目錄，建議刪除。 | 根據檢測到目標網站存在上傳下載相關的目錄和文件漏洞原理，通過訪問目標站點上傳下載相關的目錄和文件并根據響應情況進行漏洞驗證。 |
| jQuery 存在 XSS 漏洞【可驗證】 | jQuery 是一個 JavaScript 庫。? jQuery 在過濾用戶輸入數據時，所使用的正則表達式存在缺陷，可能導致 location.hash 跨站漏洞。 | 臨時解決方案：? 1、為應用系統制定允許用戶輸入字符的白名單，發現輸入中存在非白名單中的字符時直接返回固定的錯誤頁面。? 參考鏈接：? https://bugs.jquery.com/ticket/9521 | 根據jQuery 存在 XSS 漏洞原理，通過檢測jQuery的內容進行漏洞驗證。 |
| 檢測到目標URL存在內部IP地址泄露【可驗證】 | 內部 IP 定義為下列 IP 范圍內的 IP： ? 10.0.0.0 - 10.255.255.255 ? 172.16.0.0 - 172.31.255.255 ? 192.168.0.0 - 192.168.255.255 ? ? 對攻擊者而言，泄露內部 IP 非常有價值，因為它顯示了內部網絡的 IP 地址方案。知道內部網絡的 IP 地址方案，可以輔助攻擊者策劃出對內部網絡進一步的攻擊。 ? | 內部 IP 通常顯現在 Web 應用程序/服務器所生成的錯誤消息中，或顯現在 HTML/JavaScript 注釋中。 ? [1] 關閉 Web 應用程序/服務器中有問題的詳細錯誤消息。 ? [2] 確保已安裝相關的補丁。 ? [3] 確保內部 IP 信息未留在 HTML/JavaScript 注釋中。? | 根據檢測到目標URL存在內部IP地址泄露漏洞原理，通過從目標站點獲取內部IP地址進行漏洞驗證。 |
???????
4.滲透測試
滲透性測試來檢驗目標系統安全性，通過實施針對性的滲透測試，發現目標系統中的安全漏洞，在安全事件發生前發現安全漏洞，防患于未然，最大程度減少系統遭受黑客攻擊的可能。同時為安全加固提供依據，提升業務系統安全和穩定運行。
1.測試目的
通過進行滲透測試發現系統的固有安全漏洞，在安全事件發生前解決信息安全問題，最大程度的保障了信息系統安全，達到如下工作目標：
（1）掌握系統的安全現狀和面臨的主要安全風險；
（2）明確系統面對的主要風險并分析這些風險產生的原因；
（3）在分析風險原因的基礎上為系統的運行、維護、使用和改進提供安全性建議。
用戶枚舉漏洞
漏洞描述
存在于系統登錄頁面，利用登陸時輸入系統存在的用戶名錯誤密碼和不存在的用戶名錯誤密碼，返回不同的出錯信息可枚舉出系統中存在的賬號信息。
修復建議
1）將登錄失敗的返回包統一定義為“用戶名或密碼錯誤”；
2）增加校驗機制，如：采用具有失效機制的驗證碼。
點擊劫持漏洞
漏洞描述
JSON(JavaScript Object Notation) 是一種輕量級的數據交換格式。被用于各大網站中，如果這種交互的方式用來傳遞敏感的數據，并且傳輸的時候沒有做太多安全性控制的話將導致安全漏洞。
修復建議
修改web服務器配置，添加X-frame-options響應頭。
賦值有如下三種：
（1）DENY：不能被嵌入到任何iframe或frame中。
（2）SAMEORIGIN：頁面只能被本站頁面嵌入到iframe或者frame中。
（3）ALLOW-FROM URL：只能被嵌入到指定域名的框架中。
XSS漏洞
漏洞描述
跨站腳本（Cross Site Scripting）攻擊是指在遠程WEB頁面的HTML代碼中手插入惡意的JavaScript、VBScript、ActiveX、HTML或Flash等腳本，竊取瀏覽此頁面的用戶的隱私，改變用戶的設置，破壞用戶的數據。跨站腳本攻擊在
修復建議
1、檢測并過濾輸入的特殊字符，如： <>（尖括號）、"（引號）、'（單引號）、%（百分比符號）、;（分號）、 ()（括號）、&（& 符號）、+（加號）
（注意在過濾某些特殊字符時判斷是否對業務有影響）
2、針對輸出數據具體的上下文語境進行針對性的編碼
3、為cookie設置Httponly屬性
建議對客戶端提交的數據進行過濾處理，對輸出做編碼處理，編碼成html實體輸出。建議過濾所有以下字符：
[1] |（豎線符號）
[2] & （& 符號）
[3];（分號）
[4] $（美元符號）
[5] %（百分比符號）
[6] @（at 符號）
[7] '（單引號）
[8] "（引號）
[9] \'（反斜杠轉義單引號）
[10] \"（反斜杠轉義引號）
[11] <>（尖括號）
[12] ()（括號）
[13] +（加號）
[14] CR（回車符，ASCII 0x0d）
[15] LF（換行，ASCII 0x0a）
[16] ,（逗號）
[17] \（反斜杠）
另外建議對”、<、>等特殊字符在輸出時進行實體轉換，如此便使得嵌入的腳本不能執行。
3.主機漏洞
超高危漏洞
OpenSSH 代碼問題漏洞
| 簡單描述 | OpenSSH（OpenBSD Secure Shell）是加拿大OpenBSD計劃組的一套用于安全訪問遠程計算機的連接工具。該工具是SSH協議的開源實現，支持對所有的傳輸進行加密，可有效阻止竊聽、連接劫持以及其他網絡級的攻擊。 OpenSSH 9.3p2之前版本存在安全漏洞，該漏洞源于ssh-agent的PKCS11功能存在安全問題。攻擊者可利用該漏洞執行遠程代碼。 |
| 處置優先級 | 優先級低 |
| 修補建議 | 目前廠商已發布升級補丁以修復漏洞，補丁獲取鏈接： https://github.com/openbsd/src/commit/7bc29a9d5cd697290aa056e94ecee6253d3425f8 |
高危漏洞
1 Red Hat Enterprise Linux 輸入驗證漏洞
| 簡單描述 | Red Hat Linux是全世界應用最為廣泛的Linux系統之一。 發現部分使用RedHat GPG key簽名OpenSSH軟件包存在木馬。 該類包含木馬的軟件包并非自Red Hat官方發布，因此受影響的用戶僅限于自非官方途徑獲取軟件包的用戶。 |
| 處置優先級 | 優先級低 |
| 修補建議 | 目前廠商已經發布了升級補丁以修復此安全問題，補丁獲取鏈接： http://rhn.redhat.com/errata/RHSA-2008-0855.html |
2 OpenSSH 資源管理錯誤漏洞
| 簡單描述 | OpenSSH（OpenBSD Secure Shell）是OpenBSD計劃組的一套用于安全訪問遠程計算機的連接工具。該工具是SSH協議的開源實現，支持對所有的傳輸進行加密，可有效阻止竊聽、連接劫持以及其他網絡級的攻擊。 OpenSSH 8.5 版本之前存在資源管理錯誤漏洞，攻擊者可利用該漏洞在遺留操作系統上不受約束的代理套接字訪問。 |
| 處置優先級 | 優先級低 |
| 修補建議 | 目前廠商已發布升級補丁以修復漏洞，補丁獲取鏈接： https://github.com/openssh/openssh-portable/commit/e04fd6dde16de1cdc5a4d9946397ff60d96568db |
3 OpenSSH 安全漏洞
| 簡單描述 | OpenSSH（OpenBSD Secure Shell）是Openbsd計劃組的一套用于安全訪問遠程計算機的連接工具。該工具是SSH協議的開源實現，支持對所有的傳輸進行加密，可有效阻止竊聽、連接劫持以及其他網絡級的攻擊。 OpenSSH存在安全漏洞。該漏洞源于允許權限提升，因為補充組未按預期初始化。 |
| 處置優先級 | 優先級低 |
| 修補建議 | 目前廠商暫未發布修復措施解決此安全問題，建議使用此軟件的用戶隨時關注廠商主頁或參考網址以獲取解決辦法：https://www.openssh.com/security.html |
4 OpenSSH 輸入驗證錯誤漏洞
| 簡單描述 | OpenSSH（OpenBSD Secure Shell）是OpenBSD計劃組的一套用于安全訪問遠程計算機的連接工具。該工具是SSH協議的開源實現，支持對所有的傳輸進行加密，可有效阻止竊聽、連接劫持以及其他網絡級的攻擊。 OpenSSH 8.2版本中存在安全漏洞，該漏洞源于在utimes系統調用失敗時，scp客戶端錯誤地向服務器發送了重復的響應。攻擊者可通過在遠程服務器上創建子目錄利用該漏洞覆蓋客戶端下載目錄中的任意文件。 |
| 處置優先級 | 優先級低 |
| 修補建議 | 目前廠商已發布升級補丁以修復漏洞，補丁獲取鏈接： https://www.openssh.com/txt/release-8.3 |
5 OpenSSH 操作系統命令注入漏洞
| 簡單描述 | OpenSSH（OpenBSD Secure Shell）是加拿大OpenBSD計劃組的一套用于安全訪問遠程計算機的連接工具。該工具是SSH協議的開源實現，支持對所有的傳輸進行加密，可有效阻止竊聽、連接劫持以及其他網絡級的攻擊。 OpenSSH 8.3p1及之前版本中的scp的scp.c文件存在操作系統命令注入漏洞。該漏洞源于外部輸入數據構造操作系統可執行命令過程中，網絡系統或產品未正確過濾其中的特殊字符、命令等。攻擊者可利用該漏洞執行非法操作系統命令。 |
| 處置優先級 | 優先級低 |
| 修補建議 | 目前廠商暫未發布修復措施解決此安全問題，建議使用此軟件的用戶隨時關注廠商主頁或參考網址以獲取解決辦法： https://www.openssh.com/ |
高危漏洞
1 OpenSSH 安全漏洞
| 存在主機 | 10.34.176.132,10.34.176.133,10.34.36.23,10.34.36.24,10.34.36.25,10.34.36.26,10.34.36.27,10.34.36.28,10.34.36.29,10.34.36.32 |
| 簡單描述 | OpenSSH（OpenBSD Secure Shell）是Openbsd計劃組的一套用于安全訪問遠程計算機的連接工具。該工具是SSH協議的開源實現，支持對所有的傳輸進行加密，可有效阻止竊聽、連接劫持以及其他網絡級的攻擊。 OpenSSH 8.7之前版本存在安全漏洞，允許遠程攻擊者懷疑 SSH 服務器知道用戶名和公鑰的特定組合，以測試這種懷疑是否正確。 發生這種情況是因為僅當該組合對登錄會話有效時才會發送質詢。 |
| 處置優先級 | 優先級低 |
| 修補建議 | 目前廠商已發布升級補丁以修復漏洞，補丁獲取鏈接： https://github.com/openssh/openssh-portable/pull/270 |
2 OpenSSH 信息泄露漏洞
| 簡單描述 | OpenSSH（OpenBSD Secure Shell）是Openbsd計劃組的一套用于安全訪問遠程計算機的連接工具。該工具是SSH協議的開源實現，支持對所有的傳輸進行加密，可有效阻止竊聽、連接劫持以及其他網絡級的攻擊。 OpenSSH 5.7版本至8.3版本的客戶端中存在信息泄露漏洞。攻擊者可利用該漏洞獲取信息。 |
| 處置優先級 | 優先級低 |
| 修補建議 | 目前廠商暫未發布修復措施解決此安全問題，建議使用此軟件的用戶隨時關注廠商主頁或參考網址以獲取解決辦法： https://www.openssh.com/ |
中危漏洞
1 OpenSSH 安全漏洞
| 簡單描述 | OpenSSH（OpenBSD Secure Shell）是Openbsd計劃組的一套用于安全訪問遠程計算機的連接工具。該工具是SSH協議的開源實現，支持對所有的傳輸進行加密，可有效阻止竊聽、連接劫持以及其他網絡級的攻擊。 OpenSSH 8.7之前版本存在安全漏洞，允許遠程攻擊者懷疑 SSH 服務器知道用戶名和公鑰的特定組合，以測試這種懷疑是否正確。 發生這種情況是因為僅當該組合對登錄會話有效時才會發送質詢。 |
| 處置優先級 | 優先級低 |
| 修補建議 | 目前廠商已發布升級補丁以修復漏洞，補丁獲取鏈接： https://github.com/openssh/openssh-portable/pull/270 |
2 OpenSSH 信息泄露漏洞
| 簡單描述 | OpenSSH（OpenBSD Secure Shell）是Openbsd計劃組的一套用于安全訪問遠程計算機的連接工具。該工具是SSH協議的開源實現，支持對所有的傳輸進行加密，可有效阻止竊聽、連接劫持以及其他網絡級的攻擊。 OpenSSH 5.7版本至8.3版本的客戶端中存在信息泄露漏洞。攻擊者可利用該漏洞獲取信息。 |
| 處置優先級 | 優先級低 |
| 修補建議 | 目前廠商暫未發布修復措施解決此安全問題，建議使用此軟件的用戶隨時關注廠商主頁或參考網址以獲取解決辦法： https://www.openssh.com/ |
低危漏洞
1 ICMP權限許可和訪問控制問題漏洞
| 簡單描述 | ICMP信息如netmask和timestamp允許任意主機訪問。 |
| 處置優先級 | 優先修復 |
| 修補建議 | 配置防火墻或過濾路由器以阻止傳出的ICMP數據包。阻止類型13或14和/或代碼0的ICMP數據包 |
2 OpenSSH 授權問題漏洞
| 簡單描述 | OpenSSH（OpenBSD Secure Shell）是Openbsd計劃組的一套用于安全訪問遠程計算機的連接工具。該工具是SSH協議的開源實現，支持對所有的傳輸進行加密，可有效阻止竊聽、連接劫持以及其他網絡級的攻擊。 OpenSSH 8.9 之前的版本中存在安全漏洞。該漏洞源于客戶端使用帶代理轉發但沒有 -oLogLevel=verbose 的公鑰身份驗證。 |
| 處置優先級 | 優先級低 |
| 修補建議 | 目前廠商已發布升級補丁以修復漏洞，補丁獲取鏈接： https://www.openssh.com/security.html |
?信息漏洞
RPC 安全漏洞
| 簡單描述 | RPC是一個計算機通信協議。該協議允許運行于一臺計算機的程序調用另一個地址空間（通常為一個開放網絡的一臺計算機）的子程序，而程序員就像調用本地程序一樣，無需額外地為這個交互作用編程（無需關注細節）。 RPC 存在安全漏洞。攻擊者可利用該漏洞獲取提升的權限，影響保密性、完整性和可用性。 |
| 處置優先級 | 建議修復 |
| 修補建議 | VENUSTECH建議您采取如下臨時解決方法： * 在您的防火墻上禁止對內部網絡的111(UDP/TCP)端口的訪問，以限制未授權的RPC查詢請求； * 如果不需要RPC服務，關閉portmap。 |
參考信息
資產安全等級標準
| 安全級別 | 風險值區域 |
| 極度危險 | 256 <= 主機風險值 <=1024 |
| 高度危險 | 64 <= 主機風險值 < 256 |
| 中度危險 | 16 <= 主機風險值 < 64 |
| 低度危險 | 4 <= 主機風險值 < 16 |
| 比較安全 | 0 < 主機風險值 < 4 |
| 非常安全 | 0 = 主機風險值 |
網絡安全等級標準
| 安全級別 | 風險值區域 |
| 極度危險 | 256 <= 主機風險值 <=1024 |
| 高度危險 | 64 <= 主機風險值 < 256 |
| 中度危險 | 16 <= 主機風險值 < 64 |
| 低度危險 | 4 <= 主機風險值 < 16 |
| 比較安全 | 0 < 主機風險值 < 4 |
| 非常安全 | 0 = 主機風險值 |
?漏洞危險等級標準
| 2.0危險級別 | 風險值區域 |
| 高危險 | 7 <= 漏洞風險值 <=10 |
| 中危險 | 4 <= 漏洞風險值 <7 |
| 低危險 | 1 <= 漏洞風險值 <4 |
| 信息 | 0 <= 漏洞風險值 <1 |
| 3.0危險級別 | 風險值區域 |
| 超危險 | 9 <= 漏洞風險值 |
| 高危險 | 7 <= 漏洞風險值 <9 |
| 中危險 | 4 <= 漏洞風險值 <7 |
| 低危險 | 1 <= 漏洞風險值 <4 |
| 信息 | 0 <= 漏洞風險值 <1 |
?安全建議
| 安全建議 | |||
| 建議及時修補漏洞，在一定程度上防止病毒、攻擊者的威脅； 建議對存在漏洞的主機參考附件中提出的解決方案進行漏洞修補、安全增強； 建議所有 Windows系統使用"WindowsUpdate"進行更新； 建議訂閱UNIX系統廠商的安全公告，與廠商技術人員確認后進行漏洞修補、補丁安裝、停止服務等； 建議參考產品提供的漏洞建議和解決方案進行系統安全加固； 建議采用合理的安全加固的方案包括但不限于關掉服務、修改密碼為強密碼、修改系統或服務配置、打補丁、升級軟件版本、合理的安全訪問策略等； 建議對關鍵系統進行系統加固,為保證業務運行的連續性,須制定合理的、符合系統特性的加固方案,并且加固方案應通過可行性論證并得到具體的驗證； 建議采用本產品進行周期性掃描，定期對資產安全狀態進行評估,及時發現漏洞風險，驗證安全加固效果； 建議及時更新漏洞庫（建議每周進行一次升級）,能夠對最新漏洞包括0day進行發現，應對最新漏洞風險； 漏洞處置優先級僅做參考，請根據實際情況進行漏洞修復； |
![[Linux] 用LNMP網站框架搭建論壇](http://pic.xiahunao.cn/[Linux] 用LNMP網站框架搭建論壇)
