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

前言

距離上次被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黑客攻擊正在向產業化、平臺服務化轉變，若是有人想害你，一個按鈕、幾百塊錢，就能夠實現一整月的攻擊，而後一首《涼涼》送給本身。

參考

各類限流腳本：從構建分佈式秒殺系統聊聊限流特技