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

  • 2020 年 1 月 20 日
  • 筆記

前言

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

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

自TH-Nebula（星雲）發佈以來，考慮到大家在如何部署、如何使用、和為什麼需要風控系統上能還存在一些問題。

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

附項目git地址：

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

0

如何防止撞庫

1

什麼是撞庫？

2

如何防止撞庫？

  1. 一個賬號在某個較短的時間內，有多次密碼嘗試。
  2. 一定時間內相同密碼的出現頻次非常高
  3. 同一個ip或同一個設備，在短時間內使用不同賬號密碼多次嘗試登錄

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

  • 針對a情況，就限制一天之內密碼錯誤次數。
  • 針對b情況，就針對頻率特別高的密碼禁止登錄（或者校驗手機短訊/密保問題之後才能登錄）。
  • 針對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（星雲）風控系統跑起來。

1

部署TH-Nebula開源項目

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

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

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

Sniffer服務

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

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

說明：

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

3

配置防止撞庫規則

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

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

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

2

模擬撞庫測試

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

模擬腳本原理就是針對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="[email protected]"      )      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)

捕獲流量的截圖:

3

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

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

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

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

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

VirMach 便宜 VPS

QNews

QNews