etuser

繼前幾篇有關分析嚐試入侵紀錄的文章後，因為要一直分析和利用 whois 來抓 ip 區段，再寫到 iptables 防火牆規則去做封鎖的動作太累人了，所以利用 fail2ban 套件來達到自動封鎖的功能。 fail2ban 利用分析紀錄檔中固定的登入失敗的訊息，來抓取嚐試入侵的 ip，作法和前幾篇所講的手法是一樣的，只不過是程式來自動執行（好像是用 python 寫的，有空再來研究看看這些程式的寫法），加上設定檔指定各種封鎖相關的參數。 網路上相當多技術文章，就不特別把安裝和設定的過程寫出來了。 Ubuntu 16.04 安裝 fail2ban 如何在Ubuntu Server 18.04上安裝fail2ban How to Install and Configure Fail2ban on Ubuntu 20.04 [ Linux ] – 主機基本防護 防止爆力登入 fail2ban 簡易用法 Ubuntu 中使用 fail2ban 針對大量 access 做判斷及阻擋

 上篇利用 grep 和 awk 將嚐試利用 SSH 入侵的紀錄篩選出來分析，發現有幾種入侵類型： 一、密碼字典攻擊： 利用外洩的密碼表或收集常用密碼入侵粗心大意網管架設的伺服器。 防範的方式是不允許 root 帳號利用 SSH 登入系統，現今新版的 Linux distro 都有預設。 二、帳號密碼字典攻擊： 利用英文姓名或系統固定內建帳號，搭配外洩密碼表或字典密碼進行攻擊。 防範方式是限定 SSH 登入的帳號或群組，並且設置足夠安全的密碼。 三、進階帳號字典攻擊： 此類攻擊雖然也是帳號字典攻擊，但使用的帳號不再是亂槍打鳥的方式，會針對伺服器系統來作帳號攻擊，而且從這種攻擊模式可以看出某些廠牌設備會受到攻擊關注。 上圖中的「HwHiAiUser」查詢結果是華為出品某伺服器的預設管理帳號。 此類攻擊防範也是限定 SSH 登入帳號及群組，並且設置足夠安全的密碼。 四、用到錯誤字典程式的菜鳥： 在分析入侵資料中，有發現如上圖非常奇異的帳號，看起來應該不是帳號而是密碼。表示該駭客用到的字典程式欄位設定錯誤，把密碼拿來當帳號在試。 而且不只一組IP有會種情形，從收集到的資料內發現有兩個IP以上會有這樣的情形，用 whois 查詢了一下，都是中國那邊的IP，而且不是同一個區域喔！

近期在家裡利用 Raspberry pi 4 架了一台 Ubuntu Server 作為未來工作之用，因為要在外面也能連線，開了 SSH(22)、HTTP(80) 的服務，也在家用的AP（tplink）設定了虛擬伺服器轉 Port 進入。雖然目前家裡使用的中華電信光世代是用固定 IP 的 PPPOE 帳號，因為 Tplink 的 AP 有提供 DDNS 的功能，還特地註冊使用，這樣子比較好記憶。 伺服器架好了，不可避免了會有許多人利用 SSH 來嚐試入侵，為了使用的需求也無法使用白名單的方式來設定防火牆規則，只能利用紀錄檔來捉入侵的 IP，再配合 whois 來封鎖一整個 IP 區段。 /var/log/auth.log 嚐試入侵的資訊在會列在 /var/log/auth.log 紀錄檔中，從裡面找會有點吃力，所以要再利用指令的方式來想要的資訊篩選出來。 cat /var/log/auth.log | grep  'from invalid user' auth.log 會用固定的方式紀錄入侵密碼錯誤的資訊，所以利用 grep 'from invalid user' 來過濾所要的資訊。仔細觀察 auth.log 檔，同一個密碼錯誤的資訊會留下多筆紀錄，只要找到篩選用的關鍵字都可以在 grep 中使用，只是目前選定的方式是帳號和 IP 放在一起，比較容易作後續的處理。 cat /var/log/auth.log | grep 'from invalid user' | awk '{print $11, $10}' 因為是固定格式的資訊，帳號資訊在第10欄位，IP 資訊在第11欄位，所以用 awk '{print $11, $10}' 就可以把我們要的內容取出來。 cat /var/log/auth.log | grep 'from invalid user' | awk '{print $11, $10}' | sort 原始紀錄是時間序列，等我們用 awk 篩選完後，內容順序變得無意義也閱讀困難，再利用 sort 作排序，資料就會比較容易閱讀， 而且也可以發現入侵的 IP 是使用何種手法，是比較高級的針對性攻擊？還是利用字典密碼攻擊？ 建議此時的資訊就可以...

何謂 http/2 （摘錄自「你的網站升級到 HTTP/2 了嗎？」） 隨著網頁內容越來越複雜，造成了要完成一個網頁載入（Page Load）的動作，除了要下載 HTML 之外，還需要下載 CSS 檔案、JavaScript 檔案、各種圖片檔案，零零總總加起來需要已經多達上百個對伺服器的 Request 請求資源，大大影響了網頁載入的速度。在這一秒鐘幾十萬上下的時代，Amazon 的網頁載入時間每多一秒，該公司的年度營收就減少 16 億美元、Google 的搜尋時間每多 0.4 秒，每天的搜尋次數就會減少 8 百萬網頁、KISSmetric 分析報告指出等待時間超過 4 秒，Bounce Rate 就會增加 25%。人的思緒在等 1 秒後就開始飄移，如果需要等 10 秒，就會感覺這東西是不是壞了。 這個問題的最大原因在於， HTTP/1.1 有一個非常大的缺陷是每個對伺服器的 Request 資源請求，都必須佔用一個網路連線（TCP connection），傳完一個檔案才能再傳下一個，瀏覽器無法同時下載。因此在 HTTP/1.1 時代，瀏覽器為了加速下載的時間，只好同時允許六個網路連線（TCP connection）併發去連接伺服器，好可以達成同時下載六個資源。但是極限也是如此了，並不是說無限制增加網路連線就可以解決這個瓶頸，因為每一次的網路連線，都必須經過三次握手的初始網路連線程序，而且每次初始連線因為流量控制的關係，一開始的網路封包會傳輸比較慢，後來才逐漸加快。 那麼，HTTP/2 是如何改良的呢？它採用的解法包括： 只需要單一網路連線（Single TCP connection），就可以連接網站伺服器，下載所有需要的資源。大大節省 HTTP/1.1 需要一直建立多個網路連線時的啟動時間浪費。 連線多工（Multiplexing），在單一網路連線上，就可以同時傳輸多個 HTTP Request 和 Response，併發請求 CSS/JS/Images 等等資源。它的原理是將 Requests/Responses 都拆碎成小 frames 進行傳輸，而這些 frames 是可以交錯的，因此檔案再多也不怕，不會發生佔用網路連線（TCP connection）的情況。這就是為什麼在圖檔多的情況下，HTTP/2 特別有優勢。 優先權設計(...

參考資料： https://medium.com/@labappengineering/ubuntu-20-04-on-hyper-v-8888fe3ced64