網路日誌安全分析 中正大學資工系林柏青
日誌分析需求 企業網路資安防護設備 防火牆 入侵偵測系統 網頁應用程式防火牆 防毒閘道器... 潛在資安威脅 員工可自帶設備接到內部網路 ( 防護邊界模糊化 ) 針對式攻擊 (targeted attacks) 的威脅 ( 難以事先偵測 ) 並非人人皆具資安的警覺性與背景 凡走過必留下痕跡 日誌分析的重要性 發現後可及早處理問題
資安威脅分析 從多種日誌 ( 系統 網路設備 ) 中發現可能存在的資安威脅 如何知道是資安威脅? Misuse ( 威脅特徵 ), 可偵測已知威脅, 但可能遺漏新威脅 Anomaly detection ( 異常偵測 ), 可發現異於正常行為 ( 什麼是正常行為?) 偵測資安威脅就夠了嗎? 日誌分析的挑戰 個人隱私問題 ( 需要去識別化 ) 不同日誌格式的差異 ( 需要正規化 ) 龐大資料的分析 (big data 議題 )
日誌種類的比較 日誌種類 防火牆 Bro Snort 1. 連線記錄 主要內容 網路流量來源 優點 缺點 UDP 連線? IPv6 位址? 連線記錄 通過或被擋下的封包 看的到全部進出企業的封包 只能從連線分析中進行分析 2. 應用層協定分析 3. 協定異常狀態被動式擷取進出企業的封包除連線資訊外, 可分析應用層協定活動缺乏足夠的入侵偵測規則, 需要較多其他自動或人工分析 偵測規則所訂定的入侵特徵 被動式擷取進出企業的封包對於偵測規則所訂定的入侵特徵能有效察覺 如果入侵偵測規則沒定義到的網路活動就無從分析
防火牆日誌格式 需注意時序 (timestamp) 是否照先後次序排列
Bro 日誌格式
Snort 日誌格式
研究日誌與格式 時間 / 類型防火牆日誌 Bro 日誌 Snort 日誌 2014 年 8 月 (1 日 -31 日 ) 182.82GB 2014 年 10 月 (6 日 -31 日 ) 11.93GB 2014 年 12 月 (16 日 -25 日 ) 25.50GB (10 日 -16 日 ) 37MB 2015 年 1 月 (1 日 -31 日 ) 178.63GB 2015 年 2 月 (1 日 -28 日 ) 13.50GB (30 日 -31 日 ) 1.00GB (1 日 -28 日 ) 28.61GB (30 日 -2 月 16 日 ) 49.95MB
日誌分析流程
日誌分析功能 Port 掃描 (port scan/port sweep) 阻斷服務 (denial of services) 高度規則性網路活動 大量上傳與下載資料分析 可疑的 top-level domain 分析 DNS 異常偵測 惡意 IP 位址黑名單比對 爬網站偵測誤判 (false positive)? 漏判 (false negative)?
去識別化需求與方法 目的 : 為保護個人隱私, 避免上網行為被連結到個人重要隱私資訊 :IP 位址 email 位址 網址... 識別隱私資訊方式 模式比對 (pattern matching) 缺點 : 有些欄位沒有明確的 pattern ( 帳號名稱 ) 人工指定隱私欄位 缺點 : 需要對各種協定有完整的 parser 自動推論隱私欄位的可行性? 隱私與可用性的取捨? 去識別化後的日誌是否要完全公開或是只給分析人員?
去識別化模組設計 模式比對 :IP 位址 (IPv4 與 IPv6) email 位址 網址 提供 config 檔讓使用者自訂要去識別化的項目與範圍 IP prefix-preserving 與去識別化後的還原 模式的 regular expression IPv4 (25[0-5] (2[0-4] 1{0,1}[0-9]){0,1}[0-9])(\.(25[0-5] (2[0-4] 1{0,1}[0-9]){0,1}[0-9])){3} IPv6 ([0-9a-fA-F]{0,4}:)(:?[0-9a-fA-F]{0,4}:?){1,6}(:[0-9a-fA-F]{0,4}:?:?)((\.(25[0-5] (2[0-4] 1{0,1}[0-9]){0,1}[0-9])){3})? Email 位址 ([a-za-z]+(\.\w+)+(\/\w+)*(\w\/)*) 網址 ([\w_+-]+@[\w]+(\.[\w]+)+)
Port 掃描偵測 掃描方式分 port scan 與 port sweep port scan: 對同一台主機掃描是否某些 port 是 open 的 port sweep: 對一個網段的主機掃描是否某特定 port (e.g., 80) 是 open 的 偵測技術 一個時段內是否有上述行為在日誌中發生 常見偵測方式 : 計算失敗的連線數 (TCP RST, ICMP port unreachable...) 但防火牆會 block 很多連線, 且沒有失敗連線訊息 我們 focus 在依單位時間的連線數來偵測
Port 掃描分析模組 程式名稱與參數 :port_scan.py -sct: 即 scan threshold, 為十分鐘內 port scan 量大於此就判斷為 port scan, 預設為 100 -swt: 即 sweep threshold, 為十分鐘內 port sweep 量大於此就判斷為 port sweep, 預設為 50 -time: 每一次統計間隔幾分鐘, 預設為 10 分鐘 程式流程 : (1) 統計每一個 IP 位址在這 interval 時間的連線 port scan: 記錄一對 (src_ip,dst_ip) 到不同目的 port 連線的數量 port sweep: 記錄 (src_ip,subnet,port) 在同一 subnet 中不同 host 連線的數量 (2) 若超過 threshold 則判斷為異常 (3) 檢查掃描的 port 是否位於 ["21","22","25","80","110","135","443","465","993"] 這些常用的 port 中的其中兩個 若有, 則回報 likely port scan; 反之則回報 perhaps port scan
Port 掃描分析模組 (cont.) 操作範例 : normalize.sh CTTI port_scan.py "-sct 150 swt 100" /opt/new/ctti_feb/fix/ctti_2015-02-05.csv Port scan 範例 : At: 2015-02-13 05:00:00 Port scan alert: 140.92.61.117,140.92.114.242 : 110 ports scanned, [60942, 60951, 60954, 60956, 60961, 60969, 32812, 32814, 32815, 60977, 32820, 60981, 60982, 60983, 32825, 32828, 32834, 32835, 32837, 32841, 32847, 32848, 32849, 32851, 32852, 32853, 32867, 32868, 32869, 32870, 32875, 32876, 32881, 32883, 32886, 32888, 32890, 32894, 32898, 32901, 32902, 32908, 32910, 32912, 32925, 32930, 60641, 60642, 60645, 60651, 60654, 60659, 60660, 60684, 60709, 60723, 60724, 60725, 60738, 60740, 60742, 60743, 60747, 60749, 60750, 60752, 60753, 60754, 60756, 60760, 60761, 60766, 60784, 60786, 60787, 60790, 60792, 60793, 60796, 60798, 60799, 60802, 60804, 60805, 60806, 60811, 60812, 60815, 60817, 60818, 60831, 60841, 60843, 60844, 60846, 60849, 60852, 60855, 60856, 60858, 60862, 60865, 60870, 60872, 60873, 60898, 60911, 60915, 60923, 60924]
Port 掃描分析模組 (cont.) port sweep 範例 : At: 2015-01-01 00:22:41 Port sweep alert ('176.227.213.26', '140.113.13.0/24', '5060') : 53 host scanned, '151', '172', '229', '194', '197', '196', '218', '62', '63', '110', '135', '178', '236', '41', '86', '87', '92', '48', '42', '40', '118', '5', '4', '247', '186', '187', '143', '140', '174', '208', '136', '149', '108', '27', '72', '71', '127', '226', '100', '101', '223', ' 79', '220', '38', '59', '14', '19', '30', '50', '53', '131', '88', '240')
Port 掃描分析模組 : 案例分析 2015 年 1 月 178.19.108.164 專門掃 port 8088, 而對以下的 subnet 都有超過 100 次的 port sweep 異常行為,140.113.61.0/24 140.113.71.0/24 140.113.130.0/24 140.113.132.0/24 140.113.135.0/24 140.113.206.0/24 140.113.254.0/24 117.21.176.121 專門掃 port 9064 port scan 部分主要是以校內向校外,(140.113.129.46->202.99.241.162), (140.113.134.207->114.26.139.121),(140.113.63.70->1.168.74.10), (140.113.64.178->14.192.208.180) 以上的異常次數都在 100 次左右
DoS 分析模組 程式名稱與參數 :ddos.py -t: 判定為 DoS, 每小時需超過多少條連線的臨界值, 預設值為 80,000 程式流程 : 以每小時為單位, 蒐集每個 destination IP 位址被連了幾次 被連次數若有高於 threshold 則 output 相關資訊 操作範例 :./normalize.sh NBL ddos.py -t=80000 /opt/new/iii_201501/nbl_jan/log_nbl_2015-01-28.csv 其中 NBL 表示 NBL 防火牆連線日誌的格式,-t 即為判定 DoS 的臨界值,csv 檔為日誌檔本身
DoS 分析模組 (cont.) 輸出範例 : -----------At 2014-08-07 19:00:00"---------- possible victim: 140.113.1.1, connected 130121 times suspect:140.113.243.164 第一行為 DoS 發生時間 若連線數高於 threshold, 會輸出該段時間內被連線次數超過 threshold 的 IP 位址 然後會嘗試列出 suspect, 即連線次數高於全部被連次數 20% 的 source IP 位址
DoS 分析模組 : 案例分析 2014 年 12 月 140.92.114.193/194 兩台主機, 它們對位於美國的 66.171.248.182 (www1.dnsbl.info) 之 TCP port 80 發起大量查詢連線, 在 23 日 -25 日三天分別有 90 多萬 200 多萬 200 多萬條 連過去看後該網頁是完全空白 沒有內容的網頁 經查證後為專案開發中的正常工作
高度規則性網路活動分析模組 程式名稱與參數 :regular.py ( 需安裝 Python 的 scipy 套件 ) -d: 分析每日連線數的規則性 -w: 分析每星期連線數的規則性 程式流程 : 對每一對來源 IP/ 目的 IP 位址, 以及來源址, 分別統計每小時 每天 每星期的連線數 把每小時 每天 每星期的連線數存為一個 list, 然後使用 Python scipy 套件中的 chisquare 函式, 利用 Pearson's chi-square test 檢測這些時段的連線數具有規則性 如果具有高度規則性, 則判斷為異常 若每小時 ( 或每天 每星期 ) 的連線數大半為 0, 則跳過不回報 ( 連線太少, 沒有回報的必要 ) 操作範例 :./normalize.sh CTTI regular.py /opt/new/bro_snort_ctti/mask_ctti_bro/*/conn.* 分析整個月的連線日誌中具高度規則性的連線 若沒有加上 -d 或 -w 的參數, 則只分析每小時連線數的規則性
高度規則性網路活動分析模組 (cont.) 輸出範例 : 140.92.114.41 123.125.113.71 has regular activities by hour [13, 17, 13, 13, 11, 14, 9, 11, 9, 10, 13, 13, 9, 20, 13, 12, 10, 13, 12, 11, 10, 14, 14, 13] 表示 140.92.114.41 與 123.125.113.71 在某一天內每小時連線數目, 可以看出有一定程度的規則性
Pearson's chi-square test k 若滿足 (Y i x ) 2 i=1 x < χ 2 α (k 1), 則判斷為具高度規則性 k: is the number of intervals in the observation duration. : is the significance level of the test Y i : the number of events (source host, connection pairs) in the i-th interval x : the expected average number of events (connection pairs) in an interval Interval 是 hour day week 利用 scipy 的 stats.chisquare function 實作
高度規則性網路活動分析模組 : 案例分析 2014 年 12 月 -2015 年 2 月 140.92.114.41 的 port 13000, 會規則性的連線到位於中國之 123.125.113.71 的 port 13777 12 月 22 日當天每小時都單向且具規則性傳送 UDP 封包 每小時的封包個數大約都在 13 個上下, 詳細數據如下 : [13, 17, 13, 13, 11, 14, 9, 11, 9, 10, 13, 13, 9, 20, 13, 12, 10, 13, 12, 11, 10, 14, 14, 13] 這類行為持續時間相當長, 但至 2 月 2 日後就沒再出現
大量上傳與下載資料分析模組 程式名稱與參數 :up_download.py -t: 設定傳輸量超過平均多少標準差即判斷為異常, 預設為 10 程式流程 : 以每個 source IP 位址為個體 統計 IP 位址第一次連線的時間 該 IP 位址連到過哪些 IP 位址的哪些 port 在所有日誌中的上傳下載總量 計算每台內部主機對同一目的主機的同一 port 號碼進行上傳下載量的標準差及平均以平均 +n 倍標準差為 threshold, 超過則 output 結果操作範例 :.normalize.sh up_download up_download.py -t=3 /opt/new/ctti_bro_feb/2015-02-*/conn.*
大量上傳與下載資料分析模組 (cont.) 輸出範例 : excessive upload: 2015-01-31T23:54:58+0800 140.92.114.6 157811414600 excessive download: 2015-01-31T23:58:13+0800 140.92.114.35 155188012534 2015-02-02T09:02:04+0800 140.92.114.88 74058277404 上傳 / 下載會分開, 會列出第一次該連線出現的時間, 過量上傳 / 下載的 IP 以及 byte 數
大量上傳與下載資料分析模組 : 案例分析 2014 年 12 月 (140.92.114.6,1.34.160.183:465): secure SMTP, mail server 在 hinet, 上傳數批數十 MB 資料, 有註冊網址, 但沒註冊 DNS 反查 (VPN) 2015 年 2 月 一台主機 (140.92.114.35) 下載超量 經歸納後發現, 它有極大量的目標都是 140.92.114.110, 最大ㄧ次量高達 86GB 與 TCP port 903 做傳輸, 有待協助了解確切原因
可疑的 top-level domain 分析模組 程式名稱與參數 : 無, 因為用若干 script 組合即可達成 程式流程 : 藉正規表示式 \.[A-Za-z]+$ 取出日誌的 top-level domain(tld), 並加以統計各種 TLD 的出現次數, 並由大到小排序 操作範例 : awk '{if (match($9,/\.[a-za-z]+$/,arr)>0) print arr[0]}' */http.* sort uniq -c sort -n -r -k 1 取出 TLD 排序並做分析 awk '{if (match($9,/\.[a-za-z]+$/,arr)>0 && arr[0]==".ru") cnt[$3][$9]++} END {for (i in cnt) for (j in cnt[i]) print i,j,cnt[i][j]}' */dns.* 調查含有特定 TLD 的網址, 並統計來源 IP 位址 網址與出現次數
可疑的 top-level domain 分析模組 (cont.) 輸出範例 3190349.com 1030432.net 935151.tw 882547.org 392976.cc 331872.arpa 121579.info 104794.CC 70655.in 53949.COM 輸出範例 140.92.114.58 www.tns-counter.ru 18 140.92.114.58 counter.yadro.ru 6 140.92.114.58 45so.org.ru 3 140.92.114.58 forge.ispras.ru 2 140.92.114.183 www.darberry.ru 2 140.92.114.6 sat.isa.ru 1 140.92.114.6 www.mototelecom.ru 1 140.92.114.6 www.karma-group.ru 1 140.92.114.6 www.intel.ru 3 140.92.114.6 boinc.isa.ru 1 140.92.114.6 gerasim.boinc.ru 1 140.92.114.139 awaps.yandex.ru 2
可疑的 top-level domain 分析模組 : 案例分析 2015 年 2 月 cc 這個 TLD 數量在一個月內高達 392,976 次, 且 CC 的 TLD 有 104,794 次 經調查有 383,065 都是在查詢 wmtw.kktix.cc, 而且高達 23 台主機都有查詢這個網址的記錄 在 CC 這個 TLD 中, 則有 104,317 次都是查詢 WMTW.KKTIX.CC 該網址為中華民國維基媒體協會 並沒有任何 DNS 以外的日誌有提到這個網址的記錄 ( 特別是 HTTP), 也查不到任何連線到這個網址所對應的 IP 位址 這些 DNS query 的對象都是 140.92.61.(46,47)
可疑的 top-level domain 分析模組 : 案例分析 (cont.) 有 18,679 個 DNS query 送到 e5.sk 這個 domain, 整個 query 名稱非常混亂, 例如 ji7fasuaa2vk5pt2suwsdd3bifaqeaaaaaaaaaaaacalsltanbzjpmvq p3q2gel.fip7bcqjxto36wm24aaaaabb4y7g6molfuzdamivbtslxqx2 fqykqcce4ntb435.zimilbcqjxto36wm24puzxxpfgc65g47jtpo6kmf 52ny.lyojdfkhv63qjqto.a.f.e5.sk 由 ESET 這家防毒軟體公司所註冊, 且 DNS query 的結果是 NOERROR, 表示非蓄意探索的網址
DNS 異常偵測模組 (dns_abnormal.py) 程式名稱與參數 :dns_abnormal.py -nt: 一天中 nxdomain 數量大於此則判斷為異常, 預設為 100 -st: 一天中 servfail 數量大於此則判斷為異常, 預設為 100 程式流程 : (1) 記錄一天中各個 IP 的 NXDOMAIN 數量 SERVFAIL 數量 (2) 若超過各自的 threshold 則判斷為異常 操作範例 :./normalize.sh dns dns_abnormal.py "-nt 300 -st 300" /opt/new/ctti_bro_feb/2015-02-13/dns.* dns : log 檔格式, "-nt 300 -st 300" : dns_abnormal.py 所需的參數 /opt/new/ctti_bro_feb/2015-02-13/dns.* 表示檔案位置,dns 分析時請將一天中所有 dns log 都輸入
DNS 異常偵測模組 (dns_abnormal.py) (cont.) 輸出範例 : 2015-02-13 NXDOMAIN abnormal src ip connection : 140.92.114.198, 38343 times NXDOMAIN abnormal dst ip connection : 140.92.61.46, 41500 times SERVFAIL abnormal src ip connection : 140.92.114.0, 3619 times SERVFAIL abnormal dst ip connection : 140.92.61.46, 5234 times
DNS 異常偵測模組 (dns_dga.py) 程式名稱與參數 :dns_dga.py -qt: 一天中各個 query 出現次數少於此則判斷為少數 query, 預設為 3 -dgat: 一天中少數 query 數量大於此則可能為 dga 行為, 預設為 300 nxdomain_threshold: 一天中 nxdomain 數量大於此則可能為 dga 行為, 預設為 300 -np: 一天當中 (nxdomain query 種類 /nxdomain 數量 ) 大於此則可能為 dga 行為, 預設為 50%( 這邊請輸入 int, 程式會轉為百分比 ) -d: 當偵測到異常行為時, 決定是否要輸出詳細的 URL, 預設為輸出 ( 若不要輸出則使用 -d 0) -f: 可自訂白名單, 將白名單的檔案放在同一個資料夾並輸入 -f [ 檔名 ] 就可以, 請不要使用. 標點符號 程式流程 : (1) 記錄一天中各個 IP 位址的連線和 NXDOMAIN 數量及種類 (2) 統計一天內每個 IP 位址的少數 query 總數 ( 少數 query: 一天中出現少於 3 次 ) (3) 若少數 query 和 NXDOMAIN 數量大於各自的 threshold 且 NXDOMAIN 的 query 種類有占總數的一半以上, 則判斷為異常 操作範例. /normalize.sh dns dns_dga.py "-nt 100 -np 30" /opt/new/ctti_bro_feb/2015-02-13/dns.*
DNS 異常偵測模組 (dns_dga.py) (cont.) 2015-02-13 140.92.114.198, total dns query=47389 times normal url query, seldom query = 2990 times 208.220.83.1.zen.spamhaus.org 164.255.48.2.zen.spamhaus.org 51.247.175.1.zen.spamhaus.org NXDOMAIN url query, NXDOMAIN query = 35346 kinds, NXDOMAIN total query number = 35349 times 97.56.91.2.dnsbl-1.uceprotect.net 248.107.123.2.psbl.surriel.com 36.7.204.1.bl.spamcannibal.org
DNS 異常偵測模組 (dns_overlen.py) 程式名稱與參數 :dns_overlen.py -l 表示太長的網址之臨界值, 預設值為 50 程式流程 : 比較 query 名稱的長度, 如果長於臨界值, 且網域不在白名單中, 則判斷為異常 操作範例 :./normalize.sh dns dns_overlen.py l 30 /opt/new/ctti_bro_feb/2015-02- 13/dns.* 這個程式使用兩個參數, 其中 -l 表示太長的網址之臨界值, 超過這個臨界值就會回報網址太長, 預設值為 50 -c 表示白名單的檔名 白名單為一群確定無虞的網域, 一行寫一個網域, 可以在每行前面加 # 表示註解, 預設檔名為 white_domain
DNS 異常偵測模組 (dns_overlen.py) (cont.) 輸出範例 : 2015-02-02 13:23:38.395583 140.92.114.58 140.92.61.34 137 *\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 NOERROR 2015-02-02 13:23:39.895473 140.92.114.58 140.92.61.34 137 *\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 NOERROR 2015-02-02 13:28:30.485330 140.92.114.196 140.92.61.34 53 1256-ms-7.17-23f86aef.0552795c-a5d7-11e4-65b5-005056c00008 NOERROR 2015-02-02 13:30:28.804966 140.92.114.196 140.92.61.72 53 1256-ms-7.18-23fa3906.0552795c-a5d7-11e4-65b5-005056c00008 NOERROR 2015-02-02 13:31:33.844778 140.92.114.185 140.92.61.47 53 \x06\xe8\x9e\xbd\x01\xe6\x82\xa8\x0f\xee\xa1\x84\xef\x8e\x88?\xe5\x9c\xbe?gf\x e5\x8c\x97z\xe6\x95\xa3\xe5\xab\x9e)?\x02?8\x02\x06.\xe6\xbf\x98o"\x1ae'\xe7\x 8d\xab\xee\xaf\xaf@\xee\xad\xbe\xe6\x97\x9d\xe9\xb7\xab\xe6\x9f\x86+e?z\xe8\x9 6\xa7??!\xef\xa3\xb8?\xee\x9c\xb0\xe9\xa7\xa3\x01 NXDOMAIN
DNS 異常偵測模組 (dns_overlen.py): 案例分析 2014 年 12 月 在 NXDOMAIN 部分發現有許多內部 IP(140.92.114.4 140.92.114.5 140.92.114.59...) 會向 168.95.1.1 或是 168.95.192.1 發送 debian610 或是 debian603 的 IPv6 query 2015 年 1 月 NXDOMAIN 部分有兩個特定 query 大量出現, 分別為 wpad.iii.org.tw, 140.92.114.(35,140,183,239,236) -> 140.92.61.(46,47,72), hqdc1-iii.maintain.local,140.92.114.165 -> 140.92.61.(46,47) 查證過後發現為 windows 預設所發出的自動 query, 非惡意行為
惡意 IP 位址黑名單比對模組 程式名稱與參數 :botcc_server.py 程式流程 : 取得 blacklist ( 從網頁或檔案 ) 比對 input 中的 source, destination IP 位址是否有在 blacklist 中 Output 有在 blacklist 中的結果 操作範例 :./normalize.sh CTTI botcc_server.py../iii_1201/ctti_aug/ctti_firewall\(2014-08-* 表示從 CTTI 日誌格式中去比對 2014 年 8 月整月的日誌資料
惡意 IP 位址黑名單比對模組 (cont.) 輸出範例 : dst detected: 2014-08-05 15:52:27" 140.92.114.54 51613 50.63.77.1 80 dst detected: 2014-08-05 15:52:27" 140.92.114.54 51609 50.63.77.1 80 dst detected: 2014-08-05 15:52:27" 140.92.114.54 51612 50.63.77.1 80 dst detected: 2014-08-05 18:30:29" 140.92.114.249 27436 81.169.145.164 80 dst detected: 2014-08-05 18:30:39" 140.92.114.249 27437 81.169.145.164 80 IP 位址黑名單來源 : https://rules.emergingthreats.net/open/snort-2.9.0/rules/ www.malwaredomainlist.com/mdlcsv.php
惡意 IP 位址黑名單比對模組 : 案例分析 2014 年 8 月至 2015 年 2 月 共有 15 台內部主機連線到黑名單中的外部主機,host id 總共有 0,14,140,15,165,185,196,237,249,38,39,41,50,58,61 有許多都是連線到黑名單 IP 位址的 port 80 經 Bro 的 http.log 比對 ( 如果有的話 ), 可以看出有些是在上正常網站時, 有部分的連結會導到這些黑名單 IP 位址 可能導致內部主機被 compromised
爬網站偵測模組 程式名稱與參數 :crawler.py -t: 對同一網站偵測時間單位內出現多少次 URL, 預設為 30 程式流程 : 制訂出想要偵測的目標副檔名 ( 目前有 '.php','.pdf','.html','.htm','.aspx') 以每 5 分鐘為單位, 蒐集相同 source,destination IP 位址, 但相異, 並在目標內的 URL 若超過 threshold(30 個 URL) 則 output 結果 對 3. 的結果, 若 tag 欄位中出現 HTTP::URI_SQLI 的字眼, 則判斷為弱點掃描 ( 發出與 SQL 相關的 request); 反之則判斷為爬網站 操作範例 :./normalize.sh crawler crawler.py t=30 /opt/new/iii_201501/ctti_bro_jan/2015-01-31/http.*
爬網站偵測模組 (cont.) 輸出範例 : 2015-02-25T17:15:19 140.92.114.165 121.50.145.6 12 2015-02-25T17:45:00 140.92.114.133 210.59.230.60 13 2015-02-25T18:20:08 140.92.114.165 121.50.145.6 12 2015-02-26T09:40:48 140.92.114.219 140.92.61.27 13 2015-02-26T09:50:11 140.92.114.188 210.65.0.71 21 2015-02-26T11:45:02 140.92.114.51 140.92.61.104 16 2015-02-26T11:50:01 140.92.114.51 140.92.61.104 14 2015-02-26T14:30:08 140.92.114.237 46.30.212.175 11 2015-02-26T14:40:00 140.92.114.236 42.121.252.58 15 會輸出超量的時間 source, destination IP 位址和目標內相異 URL 的數量
爬網站偵測模組 : 案例分析 2015 年 2 月 140.92.114.58 連到目標網站為 140.92.39.121 同樣是內部網站, 外面無法連上 目的在探測網站中哪些目錄是否存在 可以看到有相當多的 404 錯誤
Snort 日誌分析 利用 fgrep \[**\] log 檔名 sort uniq -c 可找出各種 alert 重覆出現的次數 案例分析 : 140.92.39.40:443 -> 140.92.114.6:57816 MALWARE-OTHER self-signed SSL certificate with default Internet Widgits Pty Ltd organization name 這個問題代表 140.92.39.40 該台主機使用自我簽章的憑證, 可能有 server 身份認證上安全性不足的疑慮
Snort 日誌分析 (cont.) 117.56.4.201:80 -> 140.92.114.217:49508, 192.83.187.22:80 - > 140.92.114.237:52573 等 17 筆 FILE-IMAGE Directshow GIF logical width overflow attempt 163.13.240.201:80 -> 140.92.114.217:50980, 31.171.200.113:80 -> 140.92.114.249:1162 等 4 筆, FILE-IMAGE Microsoft Multiple Products malformed PNG detected text overflow attempt 這兩種 alert 都代表內部主機在瀏覽外部網站時遇到從圖片資訊中企圖做 buffer overflow attempt 的狀況
Snort 日誌分析 (cont.) 140.92.114.41:61537 -> 140.92.61.47:53 等 4 筆, 140.92.114.41:64700 -> 140.92.61.47:53,INDICATOR- COMPROMISE Suspicious.pw dns query 這種 alert 代表 DNS query 的網址中的 TLD 為.pw(Palau), 通常有較多的惡意網站使用這個 TLD, 值得注意是否有瀏覽惡意網站 140.92.114.236:54283 -> 140.92.61.46:53 BLACKLIST DNS request for known malware domain 8800.org [**] 表示有內部主機去 query 已知的惡意網域 8800.org, 需注意是否該主機有因此被 compromised
Snort 日誌分析 (cont.) 29.130.10.32:80 -> 140.92.114.239:58526 EXPLOIT-KIT Multiple exploit kit jar file download attempt 在內部主機瀏覽網頁的過程中, 有 exploit 企圖被下載, 同樣需注意是否該主機有因此被 compromised 202.3.185.114:80 -> 140.92.114.128:53838 FILE-PDF Adobe Reader incomplete JP2K image geometry - potentially malicious 在內部主機瀏覽網頁的過程中, 有 JPEG2000 的影像檔圖片資訊圖做 buffer overflow attempt 的狀況
白名單案例分析 (Skype 案例 ) 有一部分的網路流量會以相同的 source port 號碼, 不斷對外發送 UDP 封包 這些 UDP 封包的目的 IP 位址範圍很廣, 可包含許多國家, 目的 port 號碼也相當隨機 從網路流量本身的行為來看, 就是不斷地在探測外部主機與 port 有哪些服務, 因此被 port scanning 分析模組所偵測到 參考下列兩篇論文進行偵測 : [1] R. G. Cheng, P. Y. Tsai, P. C. Lin, C. L. Lian et al., Design and Implementation of a Skype Protocol Analyzer, IEEE Conference on Communications and Network Security (CNS), Oct. 2013. [2] Z. Yuan, C. Du, X. Chen, D. Wang and Y. Xue, SkyTracer: Towards Finegrained Identification for Skype Traffic via Sequence Signatures, International Conference on Computing, Networking and Communications (ICNC), Feb. 2014.
白名單案例分析 (Skype 案例 ) (cont.) 若網路設備可分析到 UDP payload: UDP payload 的前兩個 byte 是 packet number, 啟動 skype 後這個 packet number 大致會有遞增的關係 第三個 byte 在 Skype probing 時 ( 例如登入但尚未通話前 ) 一律是 02, 但如果有撥話 (call 他人談話 ) 及講話, 第三個 byte 的內容會落在 0d-7d 之間 後 4 個 bits 一律都是 16 進位的 d 除了前三個 byte 外, 後面的內容都會被加密, 沒有規則可循
白名單案例分析 (Skype 案例 ) (cont.) 若不可分析 UDP payload ( 例如只有防火牆日誌 ): probing 階段會有相當比例的封包之目的 port 號碼落在 40001 到 40047 之間 也會有一定數量的封包之目的 port 號碼位於 33033, 且目的 IP 位址落在 [2] 那篇論文之 Table IV 中的 IP 範圍內 從一台主機是否有一定數量以上之固定來源 port 的 UDP 封包送出, 若有且目的 port 落在上段描述的範圍中, 表示這個來源 port 是 Skype 所使用
白名單案例分析 ( 規則性活動 ) Network Time Protocol(NTP) 的封包, 它的特徵是走 UDP port 123, 主要是用來更新時間 目的 IP 位址為 224.0.0.252(IPv4) 或 ff02::1:3(ipv6), 目的 port 號碼 5355 的 multicast 封包, 為 LLMNR( 類似 DNS) 的 query 一些小工具, 像是有的會定期 query 特定網站 ( 如 203.211.2.41:80) 查詢氣象資訊等
結論 異常偵測 (anomaly detection) 什麼是正常行為? 異常而不惡意? 誤判? 漏判? 協助分析的重要工具 awk script 工具程式 (sort, uniq, cut, fgrep, geoiplookup, whois, dig, openssl, telnet, Tor...)