你的伺服器夠安全嗎

  • 2019 年 12 月 12 日
  • 筆記

前言

近期伺服器經常被暴力掃描、攻擊, 故周末花時間打理下伺服器, 將一些可能存在的風險處理掉. 筆者根據實踐總結出一份簡單的防範措施列表, 希望能對你有幫助.

閱讀本文你能收穫到:

  • 一些伺服器安全防範措施.
  • 快樂 (如果學習能使你快樂的話 (￣.￣) )

一. 防火牆

防火牆採用白名單策略, 只開放必要埠. 如: 80/443以及ssh登錄埠.

而資料庫、快取等埠, 最好只允許本地訪問, 若需要調試, 建議使用白名單IP、代理等方法進行連接.

二. 利用內網穿透工具

參考文檔: https://github.com/fatedier/frp/

對於有調試需求的伺服器而言, 資料庫、快取、消息隊列等埠需要開放. 而直接開放埠會給伺服器帶來不必要的安全隱患. 此時我們必須對訪問者進行限制, 如: 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伺服器等. 而這些資訊對於用戶來說都是非必要的. 筆者隨便找了個網站查看, 如圖:

這些細節都可能為攻擊者提供途徑. 所以有必要屏蔽掉這些資訊.

  1. proxy_hide_header {Your-Header}: nginx中, 通過proxy_hide_header可以隱藏掉上游服務返回的某些header.
  2. server_tokens off: server_tokens是nginx版本資訊開關, 可以開啟或隱藏錯誤頁或header的Server欄位後面帶的版本號.
  3. 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攻擊支配的恐懼.

尤其對於個人主頁等小站來說, 購買高防伺服器或購買各種防護服務可能性價比並不高. 但普通伺服器遇到稍大規模的攻擊(也許這規模並不是真的很大), 可能伺服器直接就掛了, 就算配置了頁面的靜態快取, 也不一定能扛得住多大規模的攻擊, 況且流量挺貴的.

對此筆者的方案是:

  1. 實時分析訪問日誌, 對每個IP進行危險等級評分.
  2. 鎖定異常IP, 將這些IP的全部請求通過302臨時重定向到GitPage備份站.
  3. 對於危險等級更高的IP, 直接使用ipset+iptables封禁

之所以對於一般危險等級的IP進行重定向, 主要目的是:

  1. 節約流量, 節約伺服器資源(這點對動態網站尤為重要)
  2. 勸退攻擊者: 大家無冤無仇, 您去找更好搞的站點攻擊, 請不要在這裡耗費太多時間.
  3. 防止誤殺, 異常IP評估可能存在誤差, 直接封禁對於訪問者而言極其不友好, 會白白損失用戶. 服務降級總比不提供服務要好. 故選擇先臨時重定向, 若該IP行為仍舊不規範, 此時再封禁也不晚.

下圖引自我的前一篇文章《我是如何通過Nginx日誌實時封禁風險IP的》

六. 禁用root遠程登錄

禁止使用root用戶遠程登錄, 僅允許某個許可權少的普通用戶遠程登錄, 登錄後再執行su提權.

對於允許遠程登錄的賬戶, 建議不要使用密碼登錄, 更不能使用簡單密碼. 建議使用秘鑰登錄.

ssh-keygen生成秘鑰對, 將公鑰放入authorized_keys文件中即可.

七. 其他

  • 定期備份, 建議使用crontab配置備份定時任務. 並且定期將重要數據冷備份.
  • 及時更新系統, 修復安全漏洞.
  • 只安裝需要的、用不著就關閉

結語

伺服器安全事大, 對於開發、運維、測試等工作來說, 安全都是重點關注的問題, 養成良好的習慣, 防患於未然.

VirMach 便宜 VPS

QNews

QNews