一份不一定很全的服務器安全防範措施, 但值得看看. (╯-_-)╯~╩╩.
文章地址: https://blog.piaoruiqing.com/2019/11/24/is-your-server-safe-enough/
前言
近期服務器經常被暴力掃描、攻擊, 故週末花時間打理下服務器, 將一些可能存在的風險處理掉. 筆者根據實踐總結出一份簡單的防範措施列表, 希望能對你有幫助.
閱讀本文你能收穫到:
- 一些服務器安全防範措施.
- 快樂 (如果學習能使你快樂的話 (￣.￣) )
一. 防火牆
防火牆採用白名單策略, 只開放必要端口. 如: 80/443以及ssh登錄端口.
而數據庫、緩存等端口, 最好只允許本地訪問, 若需要調試, 建議使用白名單IP、代理等方法進行連接.
二. 利用內網穿透工具
對於有調試需求的服務器而言, 數據庫、緩存、消息隊列等端口需要開放. 而直接開放端口會給服務器帶來不必要的安全隱患. 此時我們必須對訪問者進行限制, 如: IP白名單、VPN等. 除此之外, 筆者推薦一個內網穿透工具用來輔助建立調試環境 —— FRP
FRP是一個可用於內網穿透的高性能的反向代理應用, 有多種穿透方式, 可以指定端口進行代理. 我們可以在服務器啓動服務端(frps)和客戶端(frpc)兩個服務, 本地客戶端的frpc通過frps監聽的唯一端口與服務端的frpc建立連接, 這樣就能將服務器上只能內部訪問的端口映射到開發者電腦本地端口.
使用FRP的優勢: 指定端口、可壓縮流量、可加密、服務端只需要暴露frps的端口.
三. 隱藏無用信息
參考文檔:
1). http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_hide_header
2). http://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens
3. http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_hide_header
通過服務器返回的信息, 攻擊者能從中發現一些漏洞, 比如nginx版本、所使用的web服務器等. 而這些信息對於用戶來說都是非必要的. 筆者隨便找了個網站查看, 如圖:
這些細節都可能爲攻擊者提供途徑. 所以有必要屏蔽掉這些信息.
- proxy_hide_header {Your-Header}: nginx中, 通過proxy_hide_header可以隱藏掉上游服務返回的某些header.
- server_tokens off: server_tokens是nginx版本信息開關, 可以開啓或隱藏錯誤頁或header的Server字段後面帶的版本號.
- fastcgi_hide_header X-Powered-By: 如果您使用的是php-fpm, 這個配置可以隱藏掉header中php及版本信息.
配置完成後執行nginx -s reload後配置即生效.
四. 限流
參考文檔: http://nginx.org/en/docs/http/ngx_http_limit_req_module.html
用戶正常的訪問行爲, 不會產生過於頻繁的請求, 限流可以防止某些不安分的IP因某些目的而頻繁訪問服務器而導致資源耗盡, 影響正常用戶的訪問體驗.
一般地, 我們可以通過nginx配置ngx_http_limit_req_module進行限流:
http {
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
...
server {
...
location /search/ {
limit_req zone=one burst=5;
}
- limit_req_zone…: 設置一個大小爲10M的共享區域, 命名爲one, 其KEY爲
$binary_remote_addr即IP, 訪問速率限制爲1次/秒. - limit_req…: 路徑爲search的location使用共享區域one進行限流, 突發請求限制爲5. (如果只限制了1r/s, 將會嚴格按照每秒一次的請求進行限制, 但對於用戶來說, 點開網頁可能會併發請求數個資源, 如此死板的限制對於體驗並不友好, 所以我們還需要設置突發的請求限制)
五. 禍水東引
總之一句話, 引流到扛得住高併發的靜態頁. 比如GitPage.
參考文章: 我是如何通過Nginx日誌實時封禁風險IP的
相信不少站長都瞭解被cc或ddos攻擊支配的恐懼.
尤其對於個人主頁等小站來說, 購買高防服務器或購買各種防護服務可能性價比並不高. 但普通服務器遇到稍大規模的攻擊(也許這規模並不是真的很大), 可能服務器直接就掛了, 就算配置了頁面的靜態緩存, 也不一定能扛得住多大規模的攻擊, 況且流量挺貴的.
對此筆者的方案是:
- 實時分析訪問日誌, 對每個IP進行危險等級評分.
- 鎖定異常IP, 將這些IP的全部請求通過302臨時重定向到GitPage備份站.
- 對於危險等級更高的IP, 直接使用
ipset+iptables封禁
之所以對於一般危險等級的IP進行重定向, 主要目的是:
- 節約流量, 節約服務器資源(這點對動態網站尤爲重要)
- 勸退攻擊者: 大家無冤無仇, 您去找更好搞的站點攻擊, 請不要在這裏耗費太多時間.
- 防止誤殺, 異常IP評估可能存在誤差, 直接封禁對於訪問者而言極其不友好, 會白白損失用戶. 服務降級總比不提供服務要好. 故選擇先臨時重定向, 若該IP行爲仍舊不規範, 此時再封禁也不晚.
下圖引自我的前一篇文章《我是如何通過Nginx日誌實時封禁風險IP的》
六. 禁用root遠程登錄
禁止使用root用戶遠程登錄, 僅允許某個權限少的普通用戶遠程登錄, 登錄後再執行su提權.
對於允許遠程登錄的賬戶, 建議不要使用密碼登錄, 更不能使用簡單密碼. 建議使用祕鑰登錄.
ssh-keygen生成祕鑰對, 將公鑰放入authorized_keys文件中即可.
七. 其他
- 定期備份, 建議使用crontab配置備份定時任務. 並且定期將重要數據冷備份.
- 及時更新系統, 修復安全漏洞.
- 只安裝需要的、用不着就關閉
結語
服務器安全事大, 對於開發、運維、測試等工作來說, 安全都是重點關注的問題, 養成良好的習慣, 防患於未然.
推薦閱讀
- 我是如何通過Nginx日誌實時封禁風險IP的
- 開放API網關實踐(一) ——設計一個API網關
- 開放API網關實踐(二) —— 重放攻擊及防禦
- 開放API網關實踐(三) —— 限流
- Kubernetes(一) 跟着官方文檔從零搭建K8S
- Kubernetes(二) 應用部署
- Kubernetes(三) 如何從外部訪問服務
歡迎關注公衆號(代碼如詩):
本文發佈於樸瑞卿的博客, 允許非商業用途轉載, 但轉載必須保留原作者樸瑞卿 及鏈接:http://blog.piaoruiqing.com. 如有授權方面的協商或合作, 請聯繫郵箱: [email protected].