Hero Image
設定 Haproxy 以防止 DDOS 攻擊

設定 Haproxy 以防止 DDOS 攻擊 TCP syn flood attacks vi /etc/sysctl.conf # Protection from SYN flood net.ipv4.tcp_syncookies = 1 net.ipv4.conf.all.rp_filter = 1 net.ipv4.tcp_max_syn_backlog = 1024 Slowloris like attacks defaults option http-server-close timeout http-request 5s timeout connect 5s timeout client 30s timeout server 10s timeout tunnel 1h 限制每一個 user 的連線數量 普通用戶瀏覽網站的網頁,或是從網站下載東西時,瀏覽器一般會建立 5-7 個 TCP 鏈接。當一個惡意 client 打開了大量 TCP 連線時,耗費大量資源,因此我們必須要限制同一個用戶的連線數量。 但如果有很多使用者,是從某一個私有網段,透過 NAT 的方式連線到 Server 時,且實際上我們也不知道,到底哪一個會是 NAT 的轉址後的 IP,不知道該將哪個 IP 設定為白名單,這樣的限制就會造成問題,因此我們認為實際的環境,這樣的設定應該要保留不處理。 以下是一個設定的範例,最重要的地方是在 frontend ft_web 區塊的設定。 global stats socket ./haproxy.stats level admin defaults option http-server-close mode http timeout http-request 5s timeout connect 5s timeout server 10s timeout client 30s listen stats bind 0.0.0.0:8880 stats enable stats hide-version stats uri / stats realm HAProxy Statistics stats auth admin:admin frontend ft_web bind 0.0.0.0:8080 # Table definition stick-table type ip size 100k expire 30s store conn_cur # Allow clean known IPs to bypass the filter tcp-request connection accept if { src -f /etc/haproxy/whitelist.lst } # Shut the new connection as long as the client has already 10 opened tcp-request connection reject if { src_conn_cur ge 10 } tcp-request connection track-sc1 src # Split static and dynamic traffic since these requests have different impacts on the servers use_backend bk_web_static if { path_end .jpg .png .gif .css .js } default_backend bk_web # Dynamic part of the application backend bk_web balance roundrobin cookie MYSRV insert indirect nocache server srv1 192.168.1.2:80 check cookie srv1 maxconn 100 server srv2 192.168.1.3:80 check cookie srv2 maxconn 100 # Static objects backend bk_web_static balance roundrobin server srv1 192.168.1.2:80 check maxconn 1000 server srv2 192.168.1.3:80 check maxconn 1000 限制每個 user 產生新連線的速率 Limiting the connection rate per user 惡意的使用者會在短時間內建立很多連線,但如果產生新連線的速度太高,就會消耗掉過多的資源服務一個使用者。

Hero Image
Nginx 請求處理流程你了解嗎?

Nginx 請求處理流程你了解嗎? 11 個處理階段 1)NGX_HTTP_POST_READ_PHASE: 接收到完整的 HTTP 標頭後處理的階段,位於 URI 重寫之前。實際上很少有模組會註冊在該階段,預設情況下會被跳過。 2)NGX_HTTP_SERVER_REWRITE_PHASE: 在 URI 與 location 匹配前修改 URI 的階段,用於重新導向。該階段執行 server 區塊內、location 區塊外的重寫指令。在讀取請求標頭的過程中,nginx 會根據 host 及埠號找到對應的虛擬主機設定。 3)NGX_HTTP_FIND_CONFIG_PHASE: 根據 URI 尋找匹配的 location 設定項階段,使用重寫後的 URI 來查找對應的 location。需要注意的是該階段可能會被執行多次,因為也可能有 location 級別的重寫指令。 4)NGX_HTTP_REWRITE_PHASE: 上一階段找到 location 後再次修改 URI,屬於 location 級別的 URI 重寫階段,也可能會被執行多次。 5)NGX_HTTP_POST_REWRITE_PHASE: 防止重寫 URL 後導致的死循環,屬於 location 重寫的下一階段,用來檢查上階段是否有 URI 重寫,並根據結果跳轉到合適的階段。 6)NGX_HTTP_PREACCESS_PHASE: 下一階段之前的準備,屬於存取權限控制的前一階段。一般也用於存取控制,例如限制存取頻率、連線數等。 7)NGX_HTTP_ACCESS_PHASE: 讓 HTTP 模組判斷是否允許請求進入 Nginx 伺服器的存取控制階段,例如基於 IP 白名單/黑名單、使用者名稱密碼等的權限控制。 8)NGX_HTTP_POST_ACCESS_PHASE: 存取控制的後一階段,根據上一階段的執行結果進行處理,向使用者送出拒絕服務的錯誤碼,用來回應上一階段的拒絕。 9)NGX_HTTP_TRY_FILES_PHASE: 為存取靜態檔案資源而設置,try_files 指令的處理階段。如果沒有設定 try_files 指令,該階段會被跳過。 10)NGX_HTTP_CONTENT_PHASE:

Hero Image
vimrc設定教學

vimrc 設定教學 :set nu 顯示行號:對於 debug 相當有幫助! :set ai 自動對齊縮排:如果上一行有兩個 tab 的寬度,按 enter 繼續編輯下一行時會自動保留兩個 tab 鍵的寬度。 :set cursorline 光標底線:光標所在的那一行會有底線,幫助尋找光標位置 :set bg=light 上色模式-針對亮背景上色 預設為亮背景(白色等)上色,但是終端機的初始背景色為深紫色,會出現文字失蹤 ( 例如註解為深藍色 ) 的情況。將這一行換成 :set bg=dark 即可。 :set tabstop=4 縮排間隔數 ( 預設為 8 個空白對齊 ) 也就是說按一次 tab 鍵,游標會自動跳 4 格空白字元的寬度。雖有多個空格但實際上只有一個 tab 字元。 注意:也就是說,在其他環境下,看到 tab 字元,依舊是 8 個空白寬 :set shiftwidth=4 自動縮排對齊間隔數:向右或向左一個縮排的寬度 以下可以斟酌使用 :set mouse=a 啟用游標選取:游標可以直接選取文字,滾輪可以直接滑動頁面 ( 非移動游標 )。 可以取代用 v 選取字元的功能,配合 ctrl+insert ( 複製 ) 及 shift+inset ( 貼上 ),相當方便 :set mouse="" 停用游標選取:游標無法選取文字,滾輪只會移動光標的位置。 :set ruler ( 預設就有 ) 顯示右下角的 行,列 目前在文件的位置 % 的資訊 :set backspace=2 ( 預設就有 ) 在 insert 模式啟用 backspace 鍵 :set formatoptions+=r 自動註解(注意:若要貼上的文件某一行有註解,會因為此項設定而讓其以下每一行都變成註解) :set history=100 保留 100 個使用過的指令 :set incsearch 在關鍵字尚未完全輸入完畢前就顯示結果 如果覺得這功能太過熱心的話,可以使用 ctrl+n 來達成自動補完的功能