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

 

 在企業發展過程當中，日益增多的業務形態每每會招致新的業務風險。簡單的業務防禦已經不足以解決問題。一套完整的業務風控系統能夠幫助企業有效的規避風險，下降損失。

TH-Nebula（星雲）是威脅獵人開源的業務風控系統。在業務安全應用門檻廣泛太高的當下，咱們但願以開源的方式，下降你們的學習使用門檻，能以更低的成本，完成風控體系從無到有的搭建，在使用過程當中意識到風控的重要性。

自TH-Nebula（星雲）發佈以來，考慮到你們在如何部署、如何使用、和爲何須要風控系統上能還存在一些問題。

本文以如何防止撞庫場景爲例，闡述爲何須要一套「系統」去解決業務安全問題，接着手把手教你部署本系統，以及如何利用我們這套風控來阻斷風險，並提供模擬測試demo。

附項目git地址：

https://github.com/threathunterX/nebula

1 如何防止撞庫

1.1 什麼是撞庫？

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

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

1.2 如何防止撞庫？

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

一個帳號在某個較短的時間內，有屢次密碼嘗試。

必定時間內相同密碼的出現頻次很是高

同一個ip或同一個設備，在短期內使用不一樣帳號密碼屢次嘗試登陸

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

如：

針對a狀況，就限制一天以內密碼錯誤次數。

針對b狀況，就針對頻率特別高的密碼禁止登陸（或者校驗手機短信/密保問題以後才能登陸）。

針對c狀況，就對ip或者設備惟一id進行閾值限制，如限制1分鐘內訪問登陸接口次數<50次

看起來簡單粗暴的方法是能夠起到防禦做用，但實際上，道高一尺魔高一丈，業務安全就沒有一勞永逸的方案。

在有利可圖的前提下，黑灰產就會不斷的變換本身的規則，來」攻破」業務的防禦。

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

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

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

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

對業務訪問流量的分析、統計  — 方便安全人員發現新的攻擊行爲從而制定新的策略

策略的效果反饋的展現報表   — 方便安全人員根據策略有效性實時調整

提供除了業務自己流量外的安全情報，如ip的代理標籤、秒撥標籤等  — 直接識別高危的流量來源

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

該系統主要包含兩塊服務

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

Sniffer服務：流量的抓取服務

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

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

1 部署TH-Nebula開源項目

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

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

2.1 Nebula服務

運行./ctrl.sh status，狀態以下則部署成功：

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.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.3 配置防止撞庫規則

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

 

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

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

3 模擬撞庫測試

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

模擬腳本原理就是針對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)

 

捕獲流量的截圖:

 

 

 

4 使用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