如何利用開源風控系統 TH-Nubula（星雲）防止撞庫？

「撞庫」是安全領域常常發生的一種黑產攻擊事件。在常見的安全防禦中，安全團隊一般會在登錄接口設置安全策略來應對攻擊。但是，一旦黑產更換攻擊規則，就會致使策略失效。

在這樣的狀況下，咱們須要的就不只僅的表層的「防火牆」，而是一套完整的業務風控系統，它能夠有效的規避風險，下降損失。

在這篇文章中，咱們將介紹如何利用開源風控系統TH-Nebule（星雲）防止「撞庫」攻擊。

文章會從「撞庫」的介紹逐漸深刻到對TH-Nebula的使用，包括：如何部署、如何使用、和爲何須要風控系統等。闡述爲何須要一套「系統」去解決業務安全問題，接着手把手教你部署本系統，以及如何利用我們這套風控來阻斷風險，並提供模擬測試demo。

TH-Nebula是由威脅獵人開源的風控系統，目前源碼已放在Github和Gitee上，完全開放全部源代碼，文檔，以及安裝包。

地址：

• https://github.com/threathunterX/nebula
• https://gitee.com/threathunter/nebula

0x00 如何防止撞庫

1.什麼是撞庫？

說到撞庫，先得從」社工庫」提及，社工庫是社會工程學數據庫的簡稱，這個數據庫裏找包含了每一個人的各類行爲記錄（在不一樣網站上的帳號、密碼、分享的照片、信用卡記錄、通話記錄、短信記錄、開房記錄等等）。

因此當黑客想嘗試登陸某個網站或者app時，就會用」社工庫」裏的信息去挨個嘗試登陸，」撞」出一個個正確帳號。

2. 如何防止撞庫？

首先從企業的web服務視角來看，若是發現如下幾種狀況，基本能夠斷定是在撞庫：

1. 一個帳號在某個較短的時間內，有屢次密碼嘗試。
2. 必定時間內相同密碼的出現頻次很是高
3. 同一個IP或同一個設備，在短期內使用不一樣帳號密碼屢次嘗試登陸

在這種狀況下，最簡單粗暴的方法就是直接在登錄接口加安全策略。

如，

1. 針對a狀況，就限制一天以內密碼錯誤次數。
2. 針對b狀況，就針對頻率特別高的密碼禁止登陸（或者校驗手機短信/密保問題以後才能登陸）。
3. 針對c狀況，就對IP或者設備惟一id進行閾值限制，如限制1分鐘內訪問登陸接口次數<50次

看起來簡單粗暴的方法是能夠起到防禦做用，但實際上，道高一尺魔高一丈，業務安全就沒有一勞永逸的方案。只要有利可圖的前提下，黑灰產就會不斷的變換本身的規則，來「攻破」業務的防禦。

好比，業務限制的是1分鐘訪問限制<50次，那黑產很容易就能夠改爲40次就能繞過你的策略，這對於他來講只是改了一行代碼。

再好比，如今互聯網社會裏，IP資源能夠說是至關廉價，簡單就從IP角度去斷定能夠說很是容易被繞過。

因此業務安全的防禦不是簡單作一層「防火牆」就能夠了，是須要有一套完整的能跟黑產持續對抗的「系統」。

這套系統除了能夠自定義策略，從各個維度在網絡流量中發現風險之外，還得具有

1. 對業務訪問流量的分析、統計  — 方便安全人員發現新的攻擊行爲從而制定新的策略
2. 策略的效果反饋的展現報表   — 方便安全人員根據策略有效性實時調整
3. 提供除了業務自己流量外的安全情報，如IP的代理標籤、秒撥標籤等  — 直接識別高危的流量來源

TH-Nebula（星雲）就是這樣一套系統。它可以讓企業有能力主動發現業務風險，並快速的實施攻防對抗。星雲採用旁路流量的方式進行數據採集，無需在業務邏輯上作數據埋點或侵入，同時支持本地私有化部署和Docker鏡像雲端部署，大大下降了使用門檻。

系統分爲兩塊服務

1）Nebula服務：包括風控配置分析系統，流量的接收和分析，策略引擎，風控web控制中心等模塊

2）Sniffer服務：流量的抓取服務

其中，流量的抓取服務這塊爲了作到不對業務系統自己作代碼修改，提供了多種配置方式。用戶能夠直接在web服務機器部署，採用旁路流量的方式獲取流量；也能夠經過標準化nginx或其餘http服務的輸出日誌，採起抓取日誌的方式獲取流量

下面就以防止撞庫爲例子，一步步教你把TH-Nebula風控系統跑起來

0x01 部署TH-Nebula開源項目

如上所述Nebula開源項目分爲Sniffer流量抓取服務、Nebula服務兩塊，建議直接採用docker方式部署，部署參考以下github文檔：

• https://github.com/threathunterX/nebula_doc/blob/master/chapter2/section2/section2.2.md

1.Nebula服務

參考github教程部署完以後，運行./ctrl.sh status可查看Nebula服務的運行狀態，以下圖則表明部署成功，默認配置下Nebula的web控制中心是經過9001端口訪問：

Name Command State Ports
--------------------------------------------------------------------------------------------------
nebula /entrypoint.sh /usr/bin/su ... Up 0.0.0.0:9001->9001/tcp
nebula-aerospike /entrypoint.sh asd --foreg ... Up 3000/tcp, 3001/tcp, 3002/tcp, 3003/tcp
nebula-db docker-entrypoint.sh mysqld Up 3306/tcp
nebula-redis docker-entrypoint.sh redis ... Up 0.0.0.0:16379->6379/tcp
cron RUNNING pid 27, uptime 4 days, 22:23:47
java_web RUNNING pid 33, uptime 4 days, 22:23:47
labrador RUNNING pid 10286, uptime 2 days, 21:26:41
nebula:incident_babel_db_writer RUNNING pid 19, uptime 4 days, 22:23:47
nebula:nebula_db_query_web RUNNING pid 12, uptime 4 days, 22:23:47
nebula:nebula_offline RUNNING pid 14, uptime 4 days, 22:23:47
nebula:nebula_online RUNNING pid 19720, uptime 0:29:22
nebula:nebula_query_web RUNNING pid 15, uptime 4 days, 22:23:47
nebula:nebula_web RUNNING pid 11, uptime 4 days, 22:23:47
nebula:notice_babel_db_writer RUNNING pid 13, uptime 4 days, 22:23:47
nginx RUNNING pid 29, uptime 4 days, 22:23:47

2.Sniffer服務

這裏爲了方便後面模擬測試，建議就直接採用最簡單旁路流量方式(bro驅動)啓動Sniffer服務，即git上默認配置：

....
- SOURCES=default
#default driver
- DRIVER_INTERFACE=eth0
- DRIVER_PORT=80,8080,9001
....

說明：

• DRIVER_PORT表明監聽的流量端口，此處除了監聽80,8080外。還監聽了9001端口的流量，這是爲了方便測試，能夠捕獲到Nebula服務自身的web控制中心流量。實際生產環境能夠去掉

把Nebula和Sniffer兩塊服務正常啓動起來，則可經過 http://IP：9001端口的方式訪問 TH-Nebula界面了，如圖：

2.配置防止撞庫規則

部署完Nebula服務以後，在策略管理tag中能夠看到， Nebula系統針對帳號風險規則，已經默認配置了基本的防撞庫策略。以下圖：

用戶也能夠自定義新規則或者修改默認規則，參考以下github文檔：

• https://github.com/threathunterX/nebula_doc/blob/master/chapter3/section3/section3.1.md

0x02 模擬撞庫測試

部署並配置好規則以後，接下來就是經過模擬撞庫的過程，校驗系統的風險檢測邏輯。

模擬腳本原理就是針對Sniffer模塊監聽的9001端口連續發起1000次登陸請求（這裏爲了方便測試沒有在服務端實現login接口，但風控系統對於404的訪問也一樣會捕獲到）。具體python代碼以下：

#!/usr/bin/env python
# -*- coding: utf-8 -*-
from requests import get
from requests import put
from requests import post
from requests import delete

port = 9001


class NewRequestsData(object):
def __init__(self, url, data, cookies, method='get'):
self.data = data
self.url = url
self.cookies = cookies
self.method = method

def request(self):
m = dict(
get=get,
put=put,
post=post,
delete=delete,
)
method = m[self.method]
text = '默認模式'
code = 'None'
header = {
"connection": "close",
"content-type": 'application/json',
}
try:
if self.method in ['get', 'delete']:
response = method(self.url, params=self.data, cookies=self.cookies, timeout=10,
headers=header)
elif self.method in ['post', 'put']:
data = dumps(self.data, ensure_ascii=False).encode('utf8')
response = method(self.url, data=data, timeout=8, headers=header, cookies=self.cookies)
else:
raise ValueError
text = response.text
code = response.status_code
except Exception as e:
print("error", e)

finally:
return (text, code)


def attack_login():
data = dict(
username="threathunter@threathunter.cn"
)
r = NewRequestsData('http://127.0.0.1:{}/login'.format(port), data, {})
code, text = r.request()


if __name__ == '__main__':
i = 0
for i in range(1000):
attack_login()
print('總訪問次數:', i)

捕獲流量的截圖:

0x03 使用TH-Nebula阻斷髮現的風險

因爲 TH-Nebula 屬於旁路分析模式，因此沒法主動攔截風險事件，須要與企業端應用進行集成後實現自動阻斷的功能。

針對業務系統拉黑阻斷，系統提供如下兩種風險數據獲取方法：

主動推送：TH-Nebula 能夠將分析發現的風險推送至攔截節點進行自動的風險阻斷。

被動調用：TH-Nebula 能夠將分析發現的風險名單以接口方式提供給攔截節點調用判斷風險。

詳細請參考文檔：

• https://github.com/threathunterX/nebula_doc/blob/master/chapter3/section5.md

以上就是經過部署TH-Nebula開源風控系統，配置防撞庫策略的整套流程。

在系統使用過程當中，如遇任何疑問，可在Github進行反饋：

• https://github.com/threathunterX/nebula