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

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

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

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

·ECS 1核2G記憶體1MB頻寬，Linux系統

·RDS 2核240MB記憶體，最大連線數60

·Redis 256MB共享例項，搬家之後沒用到

·CDN 按量付費，快取小檔案

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

經歷

前段時間聽說過網際網路大佬阮一峰部落格被DDOS的經歷，可謂是持久啊，最終被迫轉移伺服器，據說還被勒索。然不知道為啥是哪個仙人闆闆居然盯上了我的小站?難道我比阮大神長得帥?

好吧，故事開始，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駭客攻擊正在向產業化、平臺服務化轉變，如果有人想害你，一個按鈕、幾百塊錢，就可以實現一整月的攻擊，然後一首《涼涼》送給自己。