記一次真實的網站被黑經歷

【本文轉自爪哇筆記  作者：小柒2012 原文鏈接：http://tech.it168.com/a2018/0629/3212/000003212205.shtml】
前言

距離上次被DDOS攻擊已經有10天左右的時間，距離上上次已經記不起具體那一天了，每一次都這么不了了之。然而近期一次相對持久的攻擊，我覺得有必要靜下心來，分享一下被黑的那段經歷。

在敘述經歷之前，先簡單的介紹一下服務器配置情況：

·ECS 1核2G內存1MB帶寬，Linux系統

·RDS 2核240MB內存，最大連接數60

·Redis 256MB共享實例，搬家之后沒用到

·CDN 按量付費，緩存小文件

以上配置，對于一個日訪問量幾千的網站來說應該綽綽有余了，并發撐死十幾個左右，以下是簡單的網站部署情況：

好吧，故事開始，2018年6月14日，凌晨兩點三十收到了阿里云系統告警通知，告知網站無法訪問，然而那會我還在睡夢中。

跟往常一樣，差不多六點左右醒來，習慣性的翻看手機，恰好此時又發來了短信告警。要在平時的話是可以再睡兩個小時的，然而此時一個激靈，瞬間困意全無，怎么說我也是有幾千訪問量的博主了。

于是，趕緊爬起來打開電腦，嘗試訪問下博客和論壇，果不其然瀏覽器在一直打轉轉。

問題排查

嘗試遠程登錄服務器：

·查看Nginx 和 PHP-FPM，ps -ef|grep xxxx

·查看系統剩余內存 free -m

·查看CPU使用情況 top

·查看Nginx錯誤日志 tail -f error.log

·查看日志容量 ll -h

·查看并發連接數 netstat -nat|grep ESTABLISHED|wc -l

一頓騷操作之后，并沒有什么異常，內存和CPU平穩，Nginx和PHP 進程沒問題。然后分別重啟了一下 PHP 和 Nginx，開始網站還可以訪問，進入社區首頁就被卡死。

查看錯誤日志，后臺使勁的刷日志，隨便查看了幾個IP，有印度的，美國的，菲律賓的等等，當然大多數還是國內的IP。一晚上的時間居然刷了上百兆日志(上次被D我清理過一次)，反正我覺得是不少了，對比網站平時的訪問量來說。

之前有過幾次攻擊，但都是三三倆倆的過來，使用Nginx禁掉IP就是了。然而此次，顯然不是禁掉IP可以解決問題的了，這么多IP收集是個問題(當然可以通過正則匹配獲取)，還有可能造成誤傷。

上班途中

然而上班才是正事，心思著一時半會解決不了問題，瞄了一眼錯誤日志，還在使勁的刷著，然后順手發了個朋友圈然后去洗漱：

路上一路嘟念，心想是不是到了9點，他們準時下夜班然后就可以正常訪問了，自我開解一下。

上班中

到了公司，第一件事當然是遠程登錄下服務器，看了一下，錯誤日志還在使勁刷。正常來說這個是時間點是不會有用戶來訪問的。

重啟了服務多次，訪問一下首頁就被卡死，然后瞬間癱瘓，整個網站(社區+博客)都不能訪問了。既然這樣，還是老實上班，坐等攻擊停止吧。

期間群里的小伙伴們問網站怎么了，打不開了椰?將近中午的時候，查看了一下錯誤日志，還有那么幾個IP再嘗試請求不同的地址，一瞅就不是什么好東西，果斷deny了一下。話說，現在請求沒那么多了，重啟了一些Nginx 和 PHP 進程，訪問首頁還是卡死?真是怪了個蛋。

心想是不是RDS數據庫的問題，查看了監控報警面板，CPU和內存利用率和當前總連接數都正常，沒有什么異常，凌晨兩點-六點左右的確有波動，但是不至于被D死。既然都登錄了，要不順便把 ECS 和 RDS 都重啟了吧。

果然，重啟一下居然神奇的好了，吃午飯的時候還用手機訪問了一下，正常，可以安心吃飯了。

問題解決

其實，最終問題怎么解決的，我并不清楚，說幾個比較疑惑的點：

·ECS 服務器 CPU 和內存也在正常閾值

·Nginx 和 PHP-FPM 進程都分別重啟過

·RDS 數據庫連接數盡管有所波動，但是并沒有占滿未釋放

·看錯誤日志請求都是來自上百個不同的IP，并且大多都是訪問的社區URL

·還有這些肉雞為什么都是晚上?晚上便宜?還是說在西半球組織攻擊

·此次是有針對性的，還是隨機的?但愿是隨機的

·中間停止過一次社區，博客是可以一直正常訪問的，懷疑是首頁數據庫查詢的問題，基于連接數應該不是這個問題，難道是Discuz的Bug?但是后來重啟數據庫后的確可以正常訪問了。

其實阿里云有基礎的DDOS防護，清洗觸發值：

·每秒請求流量：300M

·每秒報文數量：70000

對于一般小站來說，是萬萬不可能達到300M的流量閾值的，博客的CDN峰值才3M而已。

所以說，這些小波流的攻擊只能自身去默默承受，而機器配置不高，買不起帶寬只能任攻擊自由的撒歡，還不如直接關站，扔給他一個Nginx + 靜態頁面讓它D去吧。

攻防策略

如果有人真D你的站點，你還真沒有辦法，當然我所說的群體是針對中小站長而言，你連DDOS基礎防護的清洗閾值都達不到。

如果你只是一個默默無聞的小站，根本不需要想那么多。盡管現在DDOS成本很低，但誰不是無利不起早，除非你得罪了什么人。

當然對于一般的攻擊我們也不能坐以待斃，這里總結了幾個小技巧，分享給大家，反向代理使用的是openresty。

Nginx優化

Nginx號稱最大并發5W，實際上對于中小站點來說幾十或者上百個并發就不錯了，最基本的參數就可以滿足需求。但是為了安全期間，我們最好隱藏其版本號。

# 隱藏版本，防止已知漏洞被利用server_tokens off; #在http 模塊當中配置

PHP優化

在php渲染的網頁header信息中，會包含php的版本號信息，比如: X-Powered-by: php/5.6.30，這有些不安全，有些黑客可能采用掃描的方式，批量尋找低版本的php服務器，利用php漏洞(比如hash沖突)來攻擊服務器。

# 隱藏版本，防止已知漏洞被利用php_admin_flag[expose_php] = off

IP黑名單

對付那種最low的攻擊，加入黑名單的確是一個不錯的選擇，不然別人AB就能把你壓死：

# 在Nginx的http模塊添加以下配置即可deny 61.136.197.xxx;# 禁封IP段deny 61.136.197.0/24;

IP日訪問次數

限制單個IP的日訪問次數，正常來說一個用戶的訪問深度很少超過10個，跳出率一般在50%-70%之間。其實我們要做的把單個IP的日訪問量控制在100甚至50以內即可。

限制并發數

光限制訪問次數還是不夠的，攻擊者可能瞬間涌入成百上千的請求，如果這些請求到后端服務，會打垮數據庫服務的，所以我們還要基于我們自身網站訪問情況設置并發數。

·限制單個IP的并發數

·限制總并發數

這里建議大家使用漏桶算法限流，來整形流量請求。

配置CDN

基于帶寬以及正常用戶訪問速度的考量，建議配置CDN，以下是博客的流量使用情況，峰值3MB，對于我這1MB帶寬的服務器肯定是抗不住啊，況且還有社區的訪問。

配置緩存

數據庫資源是寶貴的，所以盡量不要讓請求直達后端。其實搬家之前，博客和社區都是配置過redis緩存的。由于之前購買的Redis服務是專有網絡，新賬號無法連接，然后就作罷了。

看來這次，需要在空閑服務器上配置一把了，反正閑著也是閑著，能起一丟丟作用也是好的。

·阿里云Redis加速Discuz論壇訪問

·阿里云Redis加速Typecho博客訪問

總結

前面也說了，對于攻擊，小站真的無解，能做好基礎的防護就可以了。但是對于那些肉雞們或者即將成為肉雞的人來說：

·軟件漏洞一定要及時打補丁，時刻關注互聯網相關動態。

·黑客利用被入侵的路由器獲取網絡流量，從而控制大連肉雞。

·大多數肉雞是沒有安全意識的，并且被長期利用，經發現，不少是云服務商主機、托管服務器主機，被黑客利用漏洞控制。

·DDoS黑客攻擊正在向產業化、平臺服務化轉變，如果有人想害你，一個按鈕、幾百塊錢，就可以實現一整月的攻擊，然后一首《涼涼》送給自己。