此篇為應用Elastic Stack於「偵測到電腦網路送出的流量有異常」事件。
當電腦網路流量有異常狀況時，會不會希望有系統協助我們進行偵測和回饋呢?
前言
台灣大部分中小企業，資訊單位服務整個組織或集團，通常不會有充足預算能準備足量的Public IP配發給每個使用者或員工使用，因此，透過幾個Public IP做NAT配發Private IP給同仁們，是很常見的解決方案。想到這，很懷念學校時期人手一串Public IP能夠使用的時光。
問題
回到正題，莫約2018年10月、11月起，同仁在使用Google搜尋時，出現下面這張圖
 |
| 電腦網路送出流量異常－我不是機器人 |
網頁如有出現我不是機器人reCAPTCHA選項的話，打勾、做檢查，還可以繼續完成搜尋，有時候運氣就沒那麼好，連驗證都沒得驗直接停止搜尋，如下：
 |
| 電腦網路送出流量異常 |
為什麼會這樣呢？又不是我一直Google的！是的，每位使用者都覺得問題不在自己身上，但在NAT網路架構下，所有人必須共同承擔NAT的歷史共業，因為組織連線出去的Public IP就是固定幾個。打個比方，公司如果有500個使用者，每人Google 100次，對Google來說，從這Public IP就發送了50,000次的搜尋要求。
欄位拆完後，從Kibana介面就可以看到一筆一筆進來的日誌以及相對應的欄位拆解內容。
防火牆已經先把Application定義好，屬於Google相關服務的就是google_base；使用細節陳述在ApplicationFlags，送去做Google搜尋的就是search engine，就集中火力看看項目，就用Kibana的視覺工具來幫我們分析吧！
總量分析儀表之中，我們以應用程式(Application)與應用程式旗幟(ApplicationFlags)為篩選項目，手動調整要觀察的時間，就會即時的顯示總量，看看到底是內部那些人是Google搜尋常客，在7天內總共發出210萬次的搜尋要求，而單位內最高的使用者37,875次，用七天平均去算，大概每小時送出225次搜尋，再深入觀察看看第一名的細節。
當然，發現問題就要解決，如果解決不了問題，就解決提出問題的人，阿不是，是出問題的電腦。身為鄉民一份子，透過Google來Google看看到底不能Google是什麼問題！
自動流量是什麼？
同病相憐
使用問題關鍵字搜尋以後，發現滿多類似的案例，例如：
 |
| 透過Google搜尋異常流量結果 |
在網路上爬些文章，可以得到主要是IP問題，暫時黑掉不給搜尋(廢話)，原因可能以下：
- 瀏覽器擴充套件，送出大量搜尋要求。
- 多人共用VPN、Proxy(也是IP問題)，彙集大量搜尋要求。
- 電腦中毒，也可能木馬、蠕蟲，洗關鍵字搜尋排名，送出大量搜尋要求。
Google說法
在Google官方頁面自行陳述，會出現這個訊息主要原因為：
- 透過漫遊器、電腦程式、自動化服務或搜尋資料擷取工具傳送搜尋查詢
- 利用軟體向 Google 傳送搜尋查詢，企圖找出某個網站或網頁的 Google 排名
初步歸納
比對常見原因跟Google官方說法，對應回我們組織，可能：一來是搜尋次數數量太多，把Google玩壞，二來是：組織內部電腦被植入軟體程式、或在不知情的情況下安裝軟體，這些軟體或程式會持續對Google送出搜尋，那，有沒有辦法看看到底是哪些電腦呢？這樣才能找出發太多搜尋的電腦，到底是使用者自身行為？還是有中了惡意的程式。
日誌分析
我們的組織網路邊界使用Paloalto NGFW-5050系列的次世代防火牆做流量管控，P家這款屬第七層防火牆，能夠看到TCP/IP Layer分層中的第七層應用層，當然，加密過的流量細節是無法窺探，能看到的內容就是此連線使用Google相關服務、服務使用Search Engine。
開源v.s.商業
從防火牆的功能和紀錄來看，有方向了！But，最討厭的就是這個but，單純從防火牆提供的網頁介面，能觀察到的總量是有限制的，以我們組織使用量來說大約是3到4小時的日誌暫存，同時，防火牆內建介面也缺乏分析統計功能，如果用P家自己的日誌轉存方案，又是筆貴桑桑的開銷；把他輸出成csv再用軟體分析又耗時費工不彈性。
鑒於此，體認到日誌集中收容管理的重要性，我們早早把防火牆日誌轉發到Elastic Stack，雖然能儲存的量不到無限大，但做分析統計、觀察與問題排解是還滿有助益的。
日誌資料欄位
從P家轉發出來的日誌都相當的長，大概分為三個類別，分別是流量 (Traffic)、系統 (System)以及威脅 (Threat)，必須經過Logstash做欄位拆解之後，才能做有價值的資料分析，不然就只是一堆純文字，無法進行處理。
 |
| 落落長的Traffic欄位拆解 |
欄位拆完後，從Kibana介面就可以看到一筆一筆進來的日誌以及相對應的欄位拆解內容。
 |
| Kibana看到匯入日誌 |
視覺分析
Kibana儀錶板
 |
| 總量分析儀表 |
總量分析儀表之中，我們以應用程式(Application)與應用程式旗幟(ApplicationFlags)為篩選項目，手動調整要觀察的時間，就會即時的顯示總量，看看到底是內部那些人是Google搜尋常客，在7天內總共發出210萬次的搜尋要求，而單位內最高的使用者37,875次，用七天平均去算，大概每小時送出225次搜尋，再深入觀察看看第一名的細節。
Timelion
 |
| Timelion觀察前一天、前一週比較 |
在原本Kibana提供的視覺化項目中，我們不能做些進階的比較，例如比較當下跟前一天的狀況，而前陣子Elastic釋出Kibana的新功能叫做Timelion，提供時間序列(Time series)相關的分析，能使用time offset功能跟很多額外的運算函數，讓資料序列有不同的呈現方式。
在前個段落中，我們估算第一名平均每小時送出225次搜尋，但，勞基法有規定一天上班時間八小時，又要做七休一，而從分析結果來看，這七天內使用者很平均以每秒送出兩百多次搜尋，努力不解的工作著，這樣是不是要來勞檢一下？這當然不是囉，原因很可能是使用者電腦發生了什麼事情。
可以透過Timelion的功能，拿來比較今天vs昨天、今天vs前一週的情況，看看是否從組織內網Google送出的搜尋需求數量有變化。
結論
組織內分工屬精細，有專責管理網路與伺服器的單位、處理使用者終端設備的單位，我們透過Elastic Stack，跟網路管理單位合作完整收容日誌資料，分析後彙集屬高風險Private IP清單，轉交給使用者終端設備處理單位，由該單位安排人力對配發到這些Private IP的電腦檢測掃描，大部分掃描結果均發現adware，在多個單位通力合作下，持續處理中。
截至目前還不能說正式解決這個問題，處理後的成效如何，尚需要時間證實和釐清，後續再來觀察狀況是否改善！如果有更好的解法和經驗，也歡迎共同討論。(不要叫我換IP，沒IP可以任意換，哈哈)
凱迪 2018/11/6
Email: kedy.ch@udngroup.com
歡迎討論..
凱迪 2018/11/6
Email: kedy.ch@udngroup.com
歡迎討論..