Ⅰ sql注入攻擊
sql注入攻擊的 ，最關鍵的一步是獲得資料庫許可權，不過現在一般不存在sql注入攻擊了，一般的系統能那麼容易獲得它的許可權，現在比較多的是xss攻擊。
Ⅱ 如何查看SQL注入攻擊痕跡
可以打開日誌文件查看！執行語句select * from 表名_log就可以查看了！
Ⅲ 什麼是SQL 注入攻擊
請參考SQL 注入天書～
所謂SQL注入，就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字元串，最終達到欺騙伺服器執行惡意的SQL命令，比如先前的很多影視網站泄露VIP會員密碼大多就是通過WEB表單遞交查詢字元暴出的，這類表單特別容易受到SQL注入式攻擊．
當應用程序使用輸入內容來構造動態sql語句以訪問資料庫時，會發生sql注入攻擊。如果代碼使用存儲過程，而這些存儲過程作為包含未篩選的用戶輸入的字元串來傳遞，也會發生sql注入。sql注入可能導致攻擊者使用應用程序登陸在資料庫中執行命令。如果應用程序使用特權過高的帳戶連接到資料庫，這種問題會變得很嚴重。在某些表單中，用戶輸入的內容直接用來構造（或者影響）動態sql命令，或者作為存儲過程的輸入參數，這些表單特別容易受到sql注入的攻擊。而許多網站程序在編寫時，沒有對用戶輸入的合法性進行判斷或者程序中本身的變數處理不當，使應用程序存在安全隱患。這樣，用戶就可以提交一段資料庫查詢的代碼，根據程序返回的結果，獲得一些敏感的信息或者控制整個伺服器，於是sql注入就發生了。
Ⅳ 如何檢測SQL注入技巧以及跨站腳本攻擊
如何檢測SQL注入技巧以及跨站腳本攻擊
在最近兩年中，安全專家應該對網路應用層的攻擊更加重視。因為無論你有多強壯的防火牆規則設置或者非常勤於補漏的修補機制，如果你的網路應用程序開發者沒
有遵循
安全代碼進行開發，攻擊者將通過80埠進入你的系統。廣泛被使用的兩個主要攻擊技術是SQL注入[ref1]和CSS[ref2]攻擊。
Ⅳ 如何檢測SQL注入技術以及跨站腳本攻擊
在最近兩年中，安全專家應該對網路應用層的攻擊更加重視。因為無論你有多強壯的防火牆規則設置或者非常勤於補漏的修補機制，如果你的網路應用程序開發者沒
有遵循
安全代碼進行開發，攻擊者將通過80埠進入你的系統。廣泛被使用的兩個主要攻擊技術是SQL注入[ref1]和CSS[ref2]攻擊。SQL注入是
指：通過互聯網的輸入區域，插入SQL meta-characters（特殊字元
代表一些數據）和指令，操縱執行後端的SQL查詢的技術。這些攻擊主要針對其他組織的WEB伺服器。CSS攻擊通過在URL里插入script標簽，然後
誘導信任它們的用戶點擊它們，確保惡意Javascript代碼在受害人的機器上運行。這些攻擊利用了用戶和伺服器之間的信任關系，事實上伺服器沒有對輸
入、輸出進行檢測，從而未拒絕javascript代碼。
這篇文章討論SQL注入和CSS攻擊漏洞的檢測技術。網上已經有很多關於這兩種基於
WEB攻擊的討論，比如如何實施攻擊，他們的影響，怎樣更好的編制和設計程序防止這些攻擊。 然而,
對如何檢測這些攻擊並沒有足夠的討論。我們採用流行的開源的IDS Snort[ref
3],組建根據檢測這些攻擊的規則的正則表達式。附帶，Snort默認規則設定包含檢測CSS的方法，但是這些容易被避開檢測。比如大多通過hex進制編
碼,如%3C%73%63%72%69%70% 74%3E代替避開檢測。
依賴level of
paranoia組織的能力，我們已經編寫了多種檢測相同攻擊的規則。如果你希望檢測各種可能的SQL注入攻擊，那麼你需要簡單的留意任何現行的SQL
meta-characters，如單引號，分號和雙重破折號。同樣的一個極端檢測CSS攻擊的方法，只要簡單地提防HTML標記的角括弧。但這樣會檢測
出很多錯誤。為了避免這些，這些規則需要修改使它檢測更精確些, 當仍然不能避免錯誤。
在Snort規則中使用pcre(Perl
Compatible Regular
Expressions)[ref4]關鍵字，每個規則可以帶或不帶其他規則動作。這些規則也可以被公用軟體如grep(文檔搜索工具)使用，來審閱網路
伺服器日誌。 但是,需要警惕的是，用戶的輸入只有當以GET提交請求時，WEB伺服器才會記錄日記,如果是以POST提交的請求在日記中是不會記錄的。
2. SQL注入的正則表示式
當
你為SQL注入攻擊選擇正則表示式的時候，重點要記住攻擊者可以通過提交表單進行SQL注入，也可以通過Cookie區域。你的輸入檢測邏輯應該考慮用戶
組織的各類型輸入(比如表單或Cookie信息)。並且如果你發現許多警告來自一個規則，請留意單引號或者是分號，也許些字元是你的Web應用程序創造的
合法的在CookieS中的輸入。因此, 您需要根據你的特殊的WEB應用程序評估每個規則。
依照前面提到，一個瑣細的檢測SQL射入攻擊的正則表達式要留意SQL特殊的meta-characters 譬如單引號(』)雙重擴則號(--),為了查出這些字元和他們hex等值數, 以下正則表達式適用:
2.1 檢測SQL meta-characters的正則表達式
/(\%27)|(\』)|(\-\-)|(\%23)|(#)/ix
解釋:
我
們首先檢查單引號等值的hex，單引號本身或者雙重擴折號。這些是MS SQL Server或Oracle的字元, 表示後邊的為評論,
隨後的都將被忽略。 另外，如果你使用MySQL,你需要留意 』#』和它等值的hex的出現。注意我們不需要檢查雙重破折號等值的hex,
因為這不是HTML meta-character, 瀏覽器不會進行編碼。 並且,
如果攻擊者設法手工修改雙重破折號為它的hex值%2D(使用代理像Achilles[ref 5]), SQL注入將失敗。
加入上述正則表達式的新的Snort規則如下:
alert
tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL
Injection - Paranoid";
flow:to_server,established;uricontent:".pl";pcre:"/(\%27)|(\』)|(\-\-)|(%23)|(#)/i";
classtype:Web-application-attack; sid:9099; rev:5;)
在本篇討論中,
uricontent關鍵字的值為".pl ", 因為在我們的測試環境里, CGI
程序是用Perl寫的。uricontent關鍵字的值取決於您的特殊應用, 這個值也許是".php ", 或" .asp ", 或" .jsp
", 等。 從這點考慮, 我們不顯示對應的Snort 規則, 但是我們會給出創造這些規則的正則表達式。
通過這些正則表達式你可以很簡單的創造很多的Snort規則.在前面的正則表達式里,
我們檢測雙重破折號是因為：即便沒有單引號的存在那裡也可能是SQL射入點[ref 6]。 例如, SQL查詢條目只包含數值，如下:
select value1, value2, num_value3 from database
where num_value3=some_user_supplied_number
這種情況，攻擊者可以執行額外的SQL查詢, 示範提交如下輸入:
3; insert values into some_other_table
最後, pcre的修飾符』 i』 和』 x 』 是用於分別匹配大小寫和忽略空白處的。 上面的規則也可以另外擴展來檢查分號的存在。然而，分號很可以是正常HTTP應答的一部分。為了減少這種錯誤，也是為了任何正常的單引號和雙重擴折號的出
現，上面的規則應該被修改成先檢測＝號的存。用戶輸入會響應一個GET或POST請求，一般輸入提交如下：
username=some_user_supplied_value&password=some_user_supplied_value
因此, SQL 注入嘗試將導致用戶的輸入出現在a = 號或它等效的hex值之後。
2.2 修正檢測SQL meta-characters的正則表達式
/((\%3D)|(=))[^\n]*((\%27)|(\』)|(\-\-)|(\%3B)|(:))/i
解釋:
這個規則首先留意 = 號或它的hex值(%3D)，然後考慮零個或多個除換行符以外的任意字元，最後檢測單引號，雙重破折號或分號。
典
型的SQL注入會嘗試圍繞單引號的用途操作原來的查詢，以便得到有用的價值。討論這個攻擊一般使用1』or』1』=』1字元串. 但是,
這個串的偵查很容易被逃避，譬如用1』or2>1 --.
然而唯一恆定的部分是最初的字元的值，跟隨一單引號，再加』or』。隨後的布爾邏輯可能在一定范圍上變化，可以是普通樣式也可能是非常復雜的。這些攻擊可
以相當精確被偵測，通過以下的正則表達式。2.3章節講解。
2.3 典型的 SQL 注入攻擊的正則表達式
/\w*((\%27)|(\』))((\%6F)|o|(\%4F))((\%72)|r|(\%52))/ix
解釋:
\w* - 零個或多個字元或者下劃線。
(\%27)|\』 - 單引號或它的hex等值。
(\%6 F)|o|(\%4 F))((\%72)|r|-(\%52) －『or』的大小寫以及它的hex等值。
』union』SQL
查詢在SQL注入各種資料庫中攻擊中同樣是很常見的。如果前面的正則表達式僅僅檢測單引號或則其他的SQL meta characters
，會造成很多的錯誤存在。你應該進一步修改查詢，檢測單引號和關鍵字『union』。這同樣可以進一步擴展其他的SQL關鍵字，像』select』,
』insert』, 』update』, 』delete』, 等等。
2.4 檢測SQL注入，UNION查詢關鍵字的正則表達式
/((\%27)|(\』))union/ix
(\%27)|(\』) - 單引號和它的hex等值
union - union關鍵字
可以同樣為其他SQL查詢定製表達式，如 >select, insert, update, delete, drop, 等等.
如
果，到這個階段，攻擊者已經發現web應用程序存在SQL注入漏洞，他將嘗試利用它。如果他認識到後端伺服器式MS SQL
server，他一般會嘗試運行一些危險的儲存和擴展儲存過程。這些過程一般以『sp』或『xp』字母開頭。典型的，他可能嘗試運行
『xp_cmdshell』擴展儲存過程（通過SQL Server執行Windows
命令）。SQL伺服器的SA許可權有執行這些命令的許可權。同樣他們可以通過xp_regread, xp_regwrite等儲存過程修改注冊表。
2.5 檢測MS SQL Server SQL注入攻擊的正則表達式
/exec(\s|\+)+(s|x)p\w+/ix
解釋:
exec - 請求執行儲存或擴展儲存過程的關鍵字
(\s|\+)+ - 一個或多個的空白或它們的http等值編碼
(s|x) p- 『sp』或『xp』字母用來辨認儲存或擴展儲存過程
\w+ - 一個或多個字元或下劃線來匹配過程的名稱
3. 跨站腳本(CSS)的正則表達式
當
發動CSS攻擊或檢測一個網站漏洞的時候, 攻擊者可能首先使簡單的HTML標簽如(粗體),(斜體)或(下劃線)，或者他可能嘗試簡單的
script標簽如alert("OK").
因為大多數出版物和網路傳播的檢測網站是否有css漏洞都拿這個作為例子。這些嘗試都可以很簡單的被檢測出來。
然而，高明點的攻擊者可能用它的hex值替換整個字元串。這樣標簽會以%3C%73%63%72%69%70%74%3E出 現。
另一方面，攻擊者可能使用web代理伺服器像Achilles會自動轉換一些特殊字元如換成%3E.這樣攻擊發生時，URL
中通常以hex等值代替角括弧。
下列正則表達式將檢測任何文本中包含的html的。它將捉住試圖使用、、或。這正則表達式應該忽略大小寫。我們需要同時檢測角括弧和它的hex等值(% 3C|
3.1 一般 CSS 攻擊的正則表達式
/((\%3C)|)/ix
解釋:
((\%3C)|) －檢查>或它的hex等值
Snort 規則:
alert
tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"NII
Cross-site scripting attempt"; flow:to_server,established;
pcre:"/((\%3C)|)/i"; classtype:Web-application-attack; sid:9000; rev:5;)
跨站腳本同樣可以使用技術。現行默認的snort規則可以被輕易避開。
3.2章節提供了防止這種技術的方法。
3.2 "
/((\%3C)|)/I
解釋:
(\%3 C)|) ->或它的hex等值
3.3 CSS 攻擊的極端的正則表達式
/((\%3C)|)/I
解釋:
這個規則簡單尋找。由於你的web伺服器和web應用程序的構架，這個規則可能產生一些錯誤。但它能保證捉住任何CCS或者類似CSS的攻擊。
一個不錯避開過濾的CSS方法請參考Bugtraq投稿的
http://www.securityfocus.com/archive/1/272...rchive/1/272037.
但是請注意最後一種極端的規則將能檢測這所有的攻擊。
總結:
在
這篇文章中，我們提出了不同種類的正則表達式規則來檢測SQL注入和跨站腳本攻擊。有些規則簡單而極端，一個潛在的攻擊都將提高警惕。但這些極端的規則可
能導致一些主動的錯誤。考慮到這點，我們修改了這些簡單的規則，利用了另外的樣式，他們可以檢查的更准確些。在這些網路應用成的攻擊檢測中，我們推薦將這
些作為調試你IDS或日誌分析方法的起點。再經過幾次修改後，在你對正常網交易部分的非惡意應答進行評估以後，你應該可以准備的檢測那些攻擊了。
Ⅵ SQL注入攻擊問題。求教
答案A無效，用戶數量和注入沒有直接關系，用戶只牽扯到鏈接登陸資料庫驗證
其他的都是隊的
A. 限制 DBWIS 中sysadmiIL用戶的數量
B. 在 Web 應用程序中，不以管理員帳號連接資料庫
C. 去掉資料庫不需要的函數、存儲過程
D. 對於輸入的字元串型參數，使用轉義
Ⅶ 什麼是SQL注入式攻擊 如何防範
一、 SQL注入攻擊的簡單示例。
statement := "SELECT * FROM Users WHERE Value= " + a_variable + "
上面這條語句是很普通的一條SQL語句，他主要實現的功能就是讓用戶輸入一個員工編號然後查詢處這個員工的信息。但是若這條語句被不法攻擊者改裝過後，就可能成為破壞數據的黑手。如攻擊者在輸入變數的時候，輸入以下內容SA001』;drop table c_order--。那麼以上這條SQL語句在執行的時候就變為了SELECT * FROM Users WHERE Value= 『SA001』;drop table c_order--。
這條語句是什麼意思呢?『SA001』後面的分號表示一個查詢的結束和另一條語句的開始。c_order後面的雙連字元 指示當前行餘下的部分只是一個注釋，應該忽略。如果修改後的代碼語法正確，則伺服器將執行該代碼。系統在處理這條語句時，將首先執行查詢語句，查到用戶編號為SA001 的用戶信息。然後，數據將刪除表C_ORDER(如果沒有其他主鍵等相關約束，則刪除操作就會成功)。只要注入的SQL代碼語法正確，便無法採用編程方式來檢測篡改。因此，必須驗證所有用戶輸入，並仔細檢查在您所用的伺服器中執行構造 SQL命令的代碼。
二、 SQL注入攻擊原理。
可見SQL注入攻擊的危害性很大。在講解其防止辦法之前，資料庫管理員有必要先了解一下其攻擊的原理。這有利於管理員採取有針對性的防治措施。
SQL注入是目前比較常見的針對資料庫的一種攻擊方式。在這種攻擊方式中，攻擊者會將一些惡意代碼插入到字元串中。然後會通過各種手段將該字元串傳遞到SQLServer資料庫的實例中進行分析和執行。只要這個惡意代碼符合SQL語句的規則，則在代碼編譯與執行的時候，就不會被系統所發現。
SQL注入式攻擊的主要形式有兩種。一是直接將代碼插入到與SQL命令串聯在一起並使得其以執行的用戶輸入變數。上面筆者舉的例子就是採用了這種方法。由於其直接與SQL語句捆綁，故也被稱為直接注入式攻擊法。二是一種間接的攻擊方法，它將惡意代碼注入要在表中存儲或者作為原書據存儲的字元串。在存儲的字元串中會連接到一個動態的SQL命令中，以執行一些惡意的SQL代碼。
注入過程的工作方式是提前終止文本字元串，然後追加一個新的命令。如以直接注入式攻擊為例。就是在用戶輸入變數的時候，先用一個分號結束當前的語句。然後再插入一個惡意SQL語句即可。由於插入的命令可能在執行前追加其他字元串，因此攻擊者常常用注釋標記「—」來終止注入的字元串。執行時，系統會認為此後語句位注釋，故後續的文本將被忽略，不背編譯與執行。
三、 SQL注入式攻擊的防治。
既然SQL注入式攻擊的危害這么大，那麼該如何來防治呢?下面這些建議或許對資料庫管理員防治SQL注入式攻擊有一定的幫助。
1、 普通用戶與系統管理員用戶的許可權要有嚴格的區分。
如果一個普通用戶在使用查詢語句中嵌入另一個Drop Table語句，那麼是否允許執行呢?由於Drop語句關繫到資料庫的基本對象，故要操作這個語句用戶必須有相關的許可權。在許可權設計中，對於終端用戶，即應用軟體的使用者，沒有必要給他們資料庫對象的建立、刪除等許可權。那麼即使在他們使用SQL語句中帶有嵌入式的惡意代碼，由於其用戶許可權的限制，這些代碼也將無法被執行。故應用程序在設計的時候，最好把系統管理員的用戶與普通用戶區分開來。如此可以最大限度的減少注入式攻擊對資料庫帶來的危害。
2、 強迫使用參數化語句。
如果在編寫SQL語句的時候，用戶輸入的變數不是直接嵌入到SQL語句。而是通過參數來傳遞這個變數的話，那麼就可以有效的防治SQL注入式攻擊。也就是說，用戶的輸入絕對不能夠直接被嵌入到SQL語句中。與此相反，用戶的輸入的內容必須進行過濾，或者使用參數化的語句來傳遞用戶輸入的變數。參數化的語句使用參數而不是將用戶輸入變數嵌入到SQL語句中。採用這種措施，可以杜絕大部分的SQL注入式攻擊。不過可惜的是，現在支持參數化語句的資料庫引擎並不多。不過資料庫工程師在開發產品的時候要盡量採用參數化語句。
3、 加強對用戶輸入的驗證。
總體來說，防治SQL注入式攻擊可以採用兩種方法，一是加強對用戶輸入內容的檢查與驗證;二是強迫使用參數化語句來傳遞用戶輸入的內容。在SQLServer資料庫中，有比較多的用戶輸入內容驗證工具，可以幫助管理員來對付SQL注入式攻擊。測試字元串變數的內容，只接受所需的值。拒絕包含二進制數據、轉義序列和注釋字元的輸入內容。這有助於防止腳本注入，防止某些緩沖區溢出攻擊。測試用戶輸入內容的大小和數據類型，強制執行適當的限制與轉換。這即有助於防止有意造成的緩沖區溢出，對於防治注入式攻擊有比較明顯的效果。
如可以使用存儲過程來驗證用戶的輸入。利用存儲過程可以實現對用戶輸入變數的過濾，如拒絕一些特殊的符號。如以上那個惡意代碼中，只要存儲過程把那個分號過濾掉，那麼這個惡意代碼也就沒有用武之地了。在執行SQL語句之前，可以通過資料庫的存儲過程，來拒絕接納一些特殊的符號。在不影響資料庫應用的前提下，應該讓資料庫拒絕包含以下字元的輸入。如分號分隔符，它是SQL注入式攻擊的主要幫凶。如注釋分隔符。注釋只有在數據設計的時候用的到。一般用戶的查詢語句中沒有必要注釋的內容，故可以直接把他拒絕掉，通常情況下這么做不會發生意外損失。把以上這些特殊符號拒絕掉，那麼即使在SQL語句中嵌入了惡意代碼，他們也將毫無作為。
故始終通過測試類型、長度、格式和范圍來驗證用戶輸入，過濾用戶輸入的內容。這是防止SQL注入式攻擊的常見並且行之有效的措施。
4、 多多使用SQL Server資料庫自帶的安全參數。
為了減少注入式攻擊對於SQL Server資料庫的不良影響，在SQLServer資料庫專門設計了相對安全的SQL參數。在資料庫設計過程中，工程師要盡量採用這些參數來杜絕惡意的SQL注入式攻擊。
如在SQL Server資料庫中提供了Parameters集合。這個集合提供了類型檢查和長度驗證的功能。如果管理員採用了Parameters這個集合的話，則用戶輸入的內容將被視為字元值而不是可執行代碼。即使用戶輸入的內容中含有可執行代碼，則資料庫也會過濾掉。因為此時資料庫只把它當作普通的字元來處理。使用Parameters集合的另外一個優點是可以強制執行類型和長度檢查，范圍以外的值將觸發異常。如果用戶輸入的值不符合指定的類型與長度約束，就會發生異常，並報告給管理員。如上面這個案例中，如果員工編號定義的數據類型為字元串型，長度為10個字元。而用戶輸入的內容雖然也是字元類型的數據，但是其長度達到了20個字元。則此時就會引發異常，因為用戶輸入的內容長度超過了資料庫欄位長度的限制。
5、 多層環境如何防治SQL注入式攻擊?
在多層應用環境中，用戶輸入的所有數據都應該在驗證之後才能被允許進入到可信區域。未通過驗證過程的數據應被資料庫拒絕，並向上一層返回一個錯誤信息。實現多層驗證。對無目的的惡意用戶採取的預防措施，對堅定的攻擊者可能無效。更好的做法是在用戶界面和所有跨信任邊界的後續點上驗證輸入。如在客戶端應用程序中驗證數據可以防止簡單的腳本注入。但是，如果下一層認為其輸入已通過驗證，則任何可以繞過客戶端的惡意用戶就可以不受限制地訪問系統。故對於多層應用環境，在防止注入式攻擊的時候，需要各層一起努力，在客戶端與資料庫端都要採用相應的措施來防治SQL語句的注入式攻擊。
6、 必要的情況下使用專業的漏洞掃描工具來尋找可能被攻擊的點。
使用專業的漏洞掃描工具，可以幫助管理員來尋找可能被SQL注入式攻擊的點。不過漏洞掃描工具只能發現攻擊點，而不能夠主動起到防禦SQL注入攻擊的作用。當然這個工具也經常被攻擊者拿來使用。如攻擊者可以利用這個工具自動搜索攻擊目標並實施攻擊。為此在必要的情況下，企業應當投資於一些專業的漏洞掃描工具。一個完善的漏洞掃描程序不同於網路掃描程序，它專門查找資料庫中的SQL注入式漏洞。最新的漏洞掃描程序可以查找最新發現的漏洞。所以憑借專業的工具，可以幫助管理員發現SQL注入式漏洞，並提醒管理員採取積極的措施來預防SQL注入式攻擊。如果攻擊者能夠發現的SQL注入式漏洞資料庫管理員都發現了並採取了積極的措施堵住漏洞，那麼攻擊者也就無從下手了。
Ⅷ 如何shell命令編寫自己的Web日誌分析腳本
一、讀取文件
按照上面的思路，先解決讀取問題。這里我用了判斷語句，起初我是想寫出類似於 access=more
/usr/access*.*，將這個路徑全部加到變數里，方便判斷，因為在shell里，只能將固定文件、文件夾作為變數，變數中不能加*號（我是沒找到別的方法，有知道大牛請提點下小弟），所以就想了個笨辦法，用匹配關鍵詞的方式來判斷特定目錄下，是apache日誌，還是weblogic日誌，還是IIS日誌，具體判斷方法如下：
if ls -l /usr/ | egrep "access";then
more /usr/access*.* | egrep "多個關鍵詞"
else
more /usr/ex*.log | egrep 「多個關鍵詞」
fi
這樣的方式來進行判斷，但是這樣判斷有個缺點，就是中間件日誌在/usr/目錄下，只能存在一種，比如同時存在apache和IIS的日誌，就會優先判斷apache的，進而不會執行IIS日誌分析的語句。而且，為了不跟之前的歷史數據混亂，在腳本執行開始，清空了下數據。
file=/usr/nmgxy/
if [ -e "$file" ];then
echo "日誌目錄存在，跳過創建過程，該操作會清空/usr/nmgxy/目錄下所有數據"
echo "按回車鍵開始清空數據，結束請點擊Ctrl+c"
read key
rm -r /usr/nmgxy/*
mkdir -p /usr/nmgxy/LFI/ /usr/nmgxy/exp/ /usr/nmgxy/sql/ /usr/nmgxy/scan/ /usr/nmgxy/xss/ /usr/nmgxy/getshell/ /usr/nmgxy/dir/
else
mkdir -p /usr/nmgxy/ /usr/nmgxy/LFI/ /usr/nmgxy/exp/ /usr/nmgxy/sql/
/usr/nmgxy/scan/ /usr/nmgxy/xss/ /usr/nmgxy/getshell/ /usr/nmgxy/dir/
fi
echo "分析結果日誌保存在/usr/nmgxy/目錄下"
echo ---------------------日誌目標文件---------------------------
if ls -l /usr/ | egrep "access";then
echo --------------------統計出現次數最多的前20個IP地址-----------------
cat /usr/access*.* |awk '{print $1}' |sort |uniq -c |sort -rn |head -20 >/usr/nmgxy/top20.log
echo "統計完成"
二、定義攻擊特徵
日誌讀取的問題解決了，接下來就是定義攻擊特徵的事兒了，攻擊特徵比較好定義。例如，SQL注入攻擊的判斷：
echo ------------------------SQL注入攻擊sql.log----------------
echo "開始分析存在SQL注入的攻擊行為，並將結果保存在/usr/nmgxy/sql/目錄下"
more /usr/access*.* |egrep
"%20select%20|%20and%201=1|%20and%201=2|%20exec|%27exec|
information_schema.tables|%20information_schema.tables|%20where%20|%20union%20|%20SELECT%20|%2ctable_name%20|cmdshell|%20table_schema"
>/usr/nmgxy/sql/sql.log
echo "分析結束"
awk '{print "共檢測到SQL注入攻擊" NR"次"}' /usr/nmgxy/sql/sql.log|tail -n1
echo "開始統計SQL注入攻擊事件中，出現頻率最多的前20個IP地址"
cat /usr/nmgxy/sql/sql.log |awk -F "[" '{print $1}' |sort |uniq -c |sort -rn |head -20 >/usr/nmgxy/sql/top20.log
echo ----------------------------------------------------------
more /usr/nmgxy/sql/top20.log
echo "統計結束"
我把一些常見的SQL注入攻擊的特徵寫到了裡面，去掉了MSSQL資料庫存儲過程以及MSSQL資料庫才會出現的一些注入語句。
三、輸出匹配到的含有攻擊特徵的記錄
將匹配到的攻擊特徵內容，重新輸出到了另外一個log裡面，相當於做了一次篩選/usr/nmgxy/sql/sql.log
more /usr/access*.* |egrep
"%20select%20|%20and%201=1|%20and%201=2|%20exec|%27exec|
information_schema.tables|%20information_schema.tables|%20where%20|%20union%20|%20SELECT%20|%2ctable_name%20|cmdshell|%20table_schema"
>/usr/nmgxy/sql/sql.log
然後二次分析這個篩選過的文件，統計SQL注入攻擊出現的次數
awk '{print "共檢測到SQL注入攻擊" NR"次"}' /usr/nmgxy/sql/sql.log|tail -n1
輸出完畢後，將攻擊出現最多的前20個IP地址進行統計並顯示到屏幕上
echo "開始統計SQL注入攻擊事件中，出現頻率最多的前20個IP地址"
cat /usr/nmgxy/sql/sql.log |awk -F "[" '{print $1}' |sort |uniq -c |sort -rn |head -20 >/usr/nmgxy/sql/top20.log
echo ----------------------------------------------------------
more /usr/nmgxy/sql/top20.log
echo "統計結束"
四、輸出結果
這個在代碼開頭，創建了一些文件夾，用來存放篩選過的記錄
mkdir -p /usr/nmgxy/LFI/ /usr/nmgxy/exp/ /usr/nmgxy/sql/ /usr/nmgxy/scan/ /usr/nmgxy/xss/ /usr/nmgxy/getshell/ /usr/nmgxy/dir/
中間刪刪改改折騰了好幾次。後來針對特定的攻擊，我們比較關注（重點是比較好寫的= =）的內容做了HTTP響應請求200/500的判斷，並輸出結果。
echo -------------------------getshell-getshell.log----------------
echo "開始分析存在getshell的攻擊行為，並將結果保存在/usr/nmgxy/getshell/目錄下"
more /usr/access*.* |egrep "
eval|%eval|%execute|%3binsert|%20makewebtaski%20|/div.asp|/1.asp|/1.jsp|/1.php|/1.aspx|xiaoma.jsp|tom.jsp|py.jsp|k8cmd.jsp|/k8cmd|ver007.jsp|ver008.jsp|ver007|ver008|%if|\.aar"
>>/usr/nmgxy/getshell/getshell.log
echo "分析結束"
echo "二次分析結果中HTTP響應碼為200和500，結果另存為/usr/nmgxy/getshell/ok.log"
more /usr/nmgxy/getshell/getshell.log | awk '{if($9=200) {print $1" "$2"
"$3" "$4" "$6" "$7" "$8" "$9}}' >/usr/nmgxy/getshell/ok.log
more /usr/nmgxy/getshell/getshell.log | awk '{if($9=500) {print $1" "$2"
"$3" "$4" "$6" "$7" "$8" "$9}}' >>/usr/nmgxy/getshell/ok.log
echo "二次分析結束"
awk '{print "共檢測到getshell行為" NR "次"}' /usr/nmgxy/getshell/getshell.log|tail -n1
echo "開始統計漏洞利用攻擊事件中，出現頻率最多的前20個IP地址"
cat /usr/nmgxy/getshell/getshell.log |awk -F "[" '{print $1}' |sort
|uniq -c |sort -rn |head -20 >/usr/nmgxy/getshell/top20.log
echo ---------------------------------------------------------------
more /usr/nmgxy/getshell/top20.log
echo "統計結束"
統計HTTP響應狀態，IIS和apache有點區別。apache我以默認空格為分隔符，判斷第9個分隔符是否為200或500，如果等於，則輸出全部內容
more /usr/nmgxy/getshell/getshell.log | awk '{if($9=500) {print $1" "$2" "$3" "$4" "$6" "$7" "$8" "$9}}'
而IIS的，我則是用獲取關鍵詞的方式，來進行判斷。
more /usr/nmgxy/getshell/getshell.log | egrep " 200" >/usr/nmgxy/getshell/ok.log
用egrep的方式，關鍵詞為" 200"，200前面有個空格，如果不加空格的話，很容易跟其他的參數混起來，那個時候誤報就不是一點點了。例如asp?id=200，所以加入了空格做區分。
IIS和nginx的思路類似，唯一的區別就是特徵碼，稍微有點改動而已，這個就不一一例舉了。思路就是這個思路，其實後期想把報告整體輸出成HTML的方式，估計工作量挺大，這個還是得閑下來的時候，慢慢修改吧。
PS：這個腳本雖然寫的比較粗糙，但是精確度還是有的，測試了幾十次，精確度能達到至少80%以上。
分析1個多G的日誌文件，需要大致約30多秒左右，我是在虛擬機里做的測試。虛擬機ubuntu系統，1G的內存。
不見得能幫上大忙，至少可以給大家在分析日誌時節省點時間。。。。
先貼出apache、weblogic、IIS的腳本代碼，weblogic的從網盤直接下載就好。apache、weblogic、IIS的腳本代碼：