運維紀錄：遭遇CC攻擊，防禦與查水表

博主之前完成了一個外包項目，最近兩個月在負責這個項目的運維。這是一個web，主營不良資產催收O2O。由於可能存在競爭對手，有人試圖攻擊伺服器。

事件回顧

24日下午3點，博主正在去拜訪親戚家的路上，這時公司的菜鳥開發者突然從QQ上發消息過來，問我伺服器是不是被黑了。我認為這個可能性不大。這個項目由我親手帶領團隊開發，後端使用的是Python+Flask+PostgreSQL，前端使用nodejs+express實現的midway，伺服器部署也是由博主親手完成。這類技術棧，已公布的可直接利用的漏洞十分有限，再者，博主在領隊開發時已多次強調安全的重要性，具體到每個API都對用戶許可權進行了嚴格認證，編碼過程中也不存在可能被注入、被遠程執行等低級的危險代碼，於是博主認為伺服器被web滲透的可能性非常小。當然，不排除黑客從web之外的服務滲透進入，但是伺服器上除了web只有ssh服務（強密碼+公鑰認證），除非公司的開發者部署了其他服務，否則能滲進來的可能性不大。

博主於是立即用手機訪問網站，網站返回了504，這說明nginx的上游沒有響應了，node midway或者Python後端，肯定有一個處於freeze狀態。

到達親戚家後，經過簡短的問候，我即問道有沒有能用的電腦。朋友讓我使用一台08年的筆記本，運行的XP系統，只有IE8和360安全瀏覽器，但是已經夠用了。下載Putty後ssh連接上伺服器，立即 。因為node midway和Python後端都處於開發中狀態，為了調試方便，所以直接是用supervisor作為daemon的。結果是，網站首頁仍然返回504。

下意識地 ，出來的結果讓我目瞪口呆.jpg

我立即就知道是怎麼一回事了：黑客在flood發送簡訊的API。由於當時開發急促，沒有對簡訊API加入圖形驗證碼或者reCaptcha之類的驗證，使得可以通過軟體實現模擬請求，並且由於項目處於開發中，為方便調試沒有使用wsgi容器調度請求和超時處理，再者，由於發送簡訊需要伺服器向第三方簡訊平台請求，這個請求將比較費時，同時的大量請求使得Python後端完全被阻塞，難怪nginx報504。從log上看，flood來源自多個不同的IP，這是分布式的攻擊，算得上是一場小型的CC攻擊。後來發現參與這次CC的肉雞大概有700～800台。

出於保密原則，本文以下內容中，發送簡訊API的URI均由[SMS_API]代替應急防禦

運行了一下 ，返回的數字超過了30萬，這時公司購買的簡訊平台套餐肯定已經用光了。但是現在首先要考慮恢復網站的正常訪問。

對於這種小型的CC防禦，除了ban ip之外我沒有想到更好的解決方法。於是，我用ipset+iptables將當天訪問過簡訊API的IP全部ban了。

# ipset create blacklist hash:net# cat/var/log/nginx/access.log |grep [SMS_API] | awk |whilereadline;doipset add blacklist $line;done #將訪問過簡訊API的IP全部加入ipset的blacklist集合# iptables -I INPUT -m set --match-set blacklist src -j DROP

筆記： iptables -m set –match-set [SET_NAME] [src|dst]

執行後，再查看access log，flood馬上就停下來了。但是現在遇到了新問題：後端跑不起來了。

修復後端

手動運行後端Python腳本，Peewee報不能連接上資料庫。

跑了一下psql，發現正常讀取數據，再查看PostgreSQL的log，沒有發現異常。沒有頭緒，通知公司的後端開發者檢查後端代碼。

公司的開發者沒有回應，我折騰了很久找不到問題所在，直到我想到會不會是剛才添加iptables過濾規則時把本機也過濾了。

試著運行了一下

#ipsettestblacklist127.0.0.1

返回

127.0.0.1isinsetblacklist.

再次目瞪口呆.jpg。突然想起來，剛才我為了測試簡訊介面，在伺服器上跑了一下 ，於是nginx access log中就有了127.0.0.1，然後在跑腳本的時候就把127.0.0.1加入到blacklist中了。立即運行了一下

#ipsetdelblacklist127.0.0.1

再次重啟後端，一切正常，網站也能夠訪問了。

nginx中添加訪問限制

目前後端是從session判斷唯一用戶的，並限制每個用戶每分鐘只能調用簡訊API一次。但是如果黑客手動清空cookie，伺服器將允許再次請求。在nginx的文檔中快速查找了一下，發現nginx支持從IP上request limit。現在需要限制1 request/min per IP，為此修改nginx配置：

添加limit_req_zone

# /etc/nginx/nginx.conf

http{ limit_req_zone $binary_remote_addr zone=sms:10m rate=1r/m; ...}

location中應用limit_req_zone

server { ... location ~ ^([SMS_API]) { limit_req zone=sms nodelay; proxy_pass http://127.0..1:5000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } ...}

經過這樣的配置，同一IP在一分鐘內只能訪問該URL一次，否則返回503 server unavailable。

腳本實現自動Ban IP

之後發現源源不斷地還有更多IP試圖發起CC，不可能人工一個一個的ban，於是寫了一個簡單shell腳本實現：當天access log中，訪問簡訊API超過30次的IP，將被加入黑名單。當然，這只是臨時的，生產環境中，對於同一內網中的多個真實用戶可能會出現誤ban的情況，因此攻擊過後要將腳本關閉。

#!/bin/sh

while[ True ]docat /var/log/nginx/access.log | grep [SMS_API] | awk | sort | uniq -c | awk $1>30 |whilereadline;doecho Blocking IP: $line&& ipset add blacklist$line;donesleep 10done

找出攻擊發起者

由於CC分布式的特徵，很難找出真正的攻擊發起者。但是，往往可以找到第一個嫌疑者。通過翻看當天上午的access log，發現如下有趣的信息:

113.232.156.* - - [23/Jan/2016:11:19:13+0800]"GET /register.html HTTP/1.1"2008383"https://www.google.com/""Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1""-"#使用Chrome進入網站註冊頁#...#下面若干行紀錄均為頁面靜態資源請求#...113.232.156.* - - [23/Jan/2016:11:19:20+0800]"GET [SMS_API]?phone=1584059XXXX HTTP/1.1"20046"http://網站域名.com/register.html""Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1""-"#在Chrome中點擊「發送簡訊驗證碼」按鈕

正常的UA（Chrome 21.0.1180.89），並且有靜態資源訪問記錄，基本可以確定是人工操作。

繼續翻：

113.232.156.* - - [23/Jan/2016:11:19:27+0800]"GET /register.html HTTP/1.1"2008383"-""Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)""-"#注意，這個人在1分鐘內使用了IE9重新進入網站註冊頁#...#下面若干行紀錄均為頁面靜態資源請求#...113.232.156.* - - [23/Jan/2016:11:19:35+0800]"GET [SMS_API]?phone=1552442XXXX HTTP/1.1"20046"http://網站域名.com/register.html""Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)""-"#這個人在1分鐘內使用IE9再次點擊「發送簡訊驗證碼」按鈕

普通用戶是不會同時使用兩款瀏覽器登錄同一個網站並點擊發送簡訊按鈕的。除非——你想要驗證這個網站是否根據session判斷同一用戶是否在一分鐘內調用了多次發送簡訊API。再往後翻記錄：

113.232.156.* - - [23/Jan/2016:11:19:51+0800]"GET [SMS_API]?phone=1504032XXXX HTTP/1.1"20046"-""-""-"

果不其然，這個人用模擬請求調用了發送簡訊API（因為沒有正常的UA）在這的幾分鐘後，來自全國各地的肉雞就開始flood伺服器了。

人肉攻擊發起者

換位思考一下，如果我是黑客，在開始CC之前，是否需要測試一下這個API，然後再在肉雞上配置隨機手機號，最後再進行CC？

再次翻log，發現flood開始後，來自肉雞的請求中，手機號碼來自全國各地，但是都每個號碼重複了很多次，並且每台肉雞都有自己的手機號。據此可判斷，肉雞用的手機號碼一定不是黑客本人或相關者的號碼，而應該是隨機生成的或者是通過非法渠道獲取到的「受害者」的手機號。但是，113.232.156.* （即黑客嫌疑者）一開始在Chrome和IE9中用的號碼在後面的記錄中都沒有找到，並且號碼所屬地和IP所屬地吻合（都為遼寧瀋陽），據此，懷疑黑客一開始在Chrome中會用真實的手機號先進行測試，然後再實施CC。

將黑客IP和他第一次在瀏覽器中提交的手機號碼（1584059XXXX）告訴了公司，公司立即撥打了這個手機號碼。

對方一開始不承認。後來對方打回來，問我們是什麼網站做什麼的，並且聽到對面幾個人在偷著樂。因此，對方很有可能就是這次攻擊的發起者，並且可能是黑客團伙，專職外包。（其實博主認為，國內這種組織根本算不上真正意義上的黑客，只是非常低級的為了圖利的非法技術組織，並且自身技術也是很菜…）

公司隨後開始通過手機號碼查詢該人身份信息。由於公司本身性質的關係，有後台可以調查某些信息。

之後的事情我就沒有多問了。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！