系列引言

阿里云日志服務(wù)（SLS）為客戶提供云上海量日志數(shù)據(jù)的存儲(chǔ)、查詢和分析服務(wù)，用戶在 SLS 上的使用場(chǎng)景千變?nèi)f化，但最終殊途同歸，都是為自身業(yè)務(wù)所服務(wù)?；?SLS SQL 的數(shù)據(jù)分析能力，用戶可以從任意結(jié)構(gòu)（無論是數(shù)值，還是 json，亦或無結(jié)構(gòu)的文本）的海量日志數(shù)據(jù)中提取出有效信息，以支撐業(yè)務(wù)運(yùn)維、運(yùn)營(yíng)、洞察、決策。

一直以來，我們強(qiáng)調(diào) SQL 的基礎(chǔ)通用能力、高性能、低成本，卻較少分享用戶使用 SLS 服務(wù)在最終業(yè)務(wù)上面的落地。事實(shí)上，用戶在我們的基礎(chǔ)能力之上，開展了各式各樣的業(yè)務(wù)，產(chǎn)生了非常多的奇思妙想和經(jīng)典解決方案，這些是真正業(yè)務(wù)價(jià)值的體現(xiàn)，我們希望通過本系列，以“用戶故事”的方式分享用戶遇到的問題、解決思路、實(shí)踐落地等，我們相信這些真實(shí)的用戶故事和經(jīng)驗(yàn)，同樣會(huì)是許多用戶正在經(jīng)歷和思索的，期待給讀者帶來啟發(fā)、引起共鳴、互學(xué)互鑒。

本系列將以輕松愉悅的方式帶給讀者不一樣的閱讀體驗(yàn)，每篇故事簡(jiǎn)短輕量，風(fēng)格活潑，閱讀時(shí)間將不超過 5 分鐘，請(qǐng)各位看官放心閱讀。

系列第一篇，我們講述一個(gè)大型平臺(tái)客戶被惡意攻擊的溯源分析案例。

“糟糕，我們被惡意攻擊了...”

某天，中午時(shí)分，客戶線上遭受大規(guī)模流量攻擊，大量來自全球各地的 IP 持續(xù)大規(guī)模訪問服務(wù)，導(dǎo)致服務(wù)負(fù)載陡升，影響到了正常用戶的服務(wù)請(qǐng)求。

業(yè)務(wù)部門緊急電話聯(lián)系運(yùn)維負(fù)責(zé)人，希望能夠找出攻擊來源，并進(jìn)行緊急封禁處理。

檢索并找出高頻訪問 IP

幸運(yùn)的是，訪問日志中記錄了“高頻”行為：短時(shí)間內(nèi)超過 N 次訪問會(huì)記錄如下特征日志：...rate limit for true-client-ip: 139.135.241.87 trace_id: ... 。

利用 SLS 查詢檢索能力，根據(jù)關(guān)鍵詞可以快速從海量訪問日志中檢索出高頻特征數(shù)據(jù)。

"rate limit for true-client-ip"

ok，接下來對(duì)這些特征數(shù)據(jù)使用 SQL 按 IP 分組聚合，統(tǒng)計(jì)最高頻 IP 就搞定了！

但是，等等~

這個(gè)日志是一個(gè)無結(jié)構(gòu)化的純文本數(shù)據(jù)（只有一個(gè)大段的 msg 字段），我們并沒有建立 IP 列，又怎么統(tǒng)計(jì)分析最高頻的 IP 呢？

沒問題！SLS SQL 提供了靈活的無結(jié)構(gòu)化數(shù)據(jù)提取能力，利用正則提取函數(shù) regexp_extract，可以輕松從 msg 字段的海量數(shù)據(jù)中根據(jù)日志 pattern 提取出 IP 列，同時(shí)對(duì)提取出的 IP 列按每 2 分鐘為粒度分組聚合，統(tǒng)計(jì)分析出時(shí)間區(qū)間內(nèi)最高頻的訪問 IP。

"rate limit for true-client-ip:" | select regexp_extract(msg, 'true-client-ip: (\d+.\d+.\d+.\d+)', 1) as ip, count(1) as pv, __time__-time % 120 as t from log group by ip, t order by pv desc limit all

關(guān)聯(lián)分析惡意賬號(hào)

果然，在此時(shí)間段，存在大量的高頻訪問 IP，但高頻訪問 IP 的量實(shí)在太多了，黑客可能從全球各地使用“肉雞”進(jìn)行 DDOS 攻擊，業(yè)務(wù)方很難根據(jù)這么大量的 IP 進(jìn)行封禁控制，何況攻擊 IP 還在實(shí)時(shí)變化中~

[10/May/2025:12:55:31 +0800] player.getSMScode Received "uid":nbNgQ01wRWiOSVcI2Y/hUw== "trace_id":7b3d9f2a-418a-4b4e-9c52-a60c1f3e8b45
[10/May/2025:13:55:36 +0800] "GET /index.html HTTP/1.1" 200 432 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36" "rate limit for true-client-ip": 139.135.241.87 "trace_id": 7b3d9f2a-418a-4b4e-9c52-a60c1f3e8b45

用戶的訪問日志庫存放了大量的異構(gòu)日志，有短信接收日志（記錄了賬號(hào) uid、trace_id 等信息），也有上述高頻訪問日志，還有其他常規(guī)訪問日志數(shù)據(jù)等等。

基于這些事實(shí)數(shù)據(jù)（哪怕它們很亂），利用 SLS 強(qiáng)大的查詢和分析能力，我們就可以實(shí)現(xiàn)數(shù)據(jù)關(guān)聯(lián)分析了。

* | select 
  date_trunc('minute', __time__) t, 
  uuid, 
  count(1) cnt, 
  array_agg(distinct ip) ip
FROM  (
    select __time__, regexp_extract(msg, '"true-client-ip": (\d+.\d+.\d+.\d+)', 1) as ip, trace_id FROM log where msg has '"rate limit for true-client-ip": '
  ) t1
  left join (
    select trace_id, regexp_extract(msg, '"uid":"([^"]*)"', 1) uuid FROM log where msg has 'player.getSMScode'and msg has 'Received'
  ) t2 
  on t1.trace_id = t2.trace_id
group by t, t2.uuid
having cnt > 100
order by cnt desc

雖然，這可能稍微有點(diǎn)高階，稍微解釋一下：

• 我們使用了兩個(gè)子查詢，分別提取出高頻訪問的 ip 和 trace_id，以及賬號(hào)登錄接收短信的 uid 和 trace_id。
• 在子查詢中我們高效檢索出特征數(shù)據(jù)（使用 where msg has 'xxx' 可以高效利用索引過濾出有效數(shù)據(jù)）。
• 利用 SQL JOIN 將左右子表以 trace_id 進(jìn)行關(guān)聯(lián)。
• 同時(shí)，我們對(duì) uid 分組聚合，并過濾出單分鐘內(nèi)訪問頻次超過 100 次的高頻賬號(hào)（疑似惡意攻擊賬號(hào)）。
• 最后，我們利用聚合函數(shù) array_agg(distinct ip)匯聚列出每分鐘每個(gè)疑似賬戶的攻擊 IP 列表。

但是，非常高效，我們僅通過一次分析，便將所有可疑賬戶和 IP 來源分析出來了。

截圖展示數(shù)據(jù)僅為示意數(shù)據(jù)

地理信息溯源

更進(jìn)一步，我們還可以利用 SLS 的 IP 地理位置函數(shù)分析確定 IP 來源。

SQL 中只需要將 array_agg(distinct ip) 改為 array_agg(distinct ip_to_country(ip)) 即可。

截圖展示數(shù)據(jù)僅為示意數(shù)據(jù)

最終，經(jīng)過業(yè)務(wù)部門核對(duì)，以上分析準(zhǔn)確溯源了惡意賬號(hào)和 IP 來源，并且惡意賬號(hào)只有一個(gè)，交由風(fēng)控部門進(jìn)行緊急封禁控制，有效阻止了持續(xù)的惡意攻擊。

多云聯(lián)動(dòng)

拿到以上異常 IP 后，就可以配置防火墻封堵策略，結(jié)果又遇到了以下問題：

• IP 誤封：異常 IP 很多，來不及審查，辦公室 IP/關(guān)聯(lián)方 IP 也在里面。狠起來，我們自己人都不放過。
• 頻繁攻擊：黑客一個(gè)定時(shí)腳本半夜攻擊。業(yè)務(wù)運(yùn)維人員半夜起床搬磚，頭發(fā)掉得一把一把的。

在這個(gè)友方和頭發(fā)保衛(wèi)戰(zhàn)中，提出了一個(gè)自動(dòng)化封堵方案。

客戶的服務(wù)是多云部署（同時(shí)在 AWS、阿里云部署）的，有了這次的成功經(jīng)驗(yàn)，運(yùn)維負(fù)責(zé)人進(jìn)一步發(fā)揮，通過自動(dòng)化方案，定期從 SLS 進(jìn)行查詢分析，同步更新到阿里云和 AWS 的 WAF 服務(wù)中，攻擊賬號(hào)和 IP 來源存儲(chǔ) 3 天，過期釋放，從而實(shí)現(xiàn)了真實(shí)業(yè)務(wù)惡意攻擊的自主分析和防控能力。

整體方案核心邏輯如下

分為兩部分：SLS 異常 IP 自動(dòng)檢測(cè)和 AWS WAF 動(dòng)態(tài)更新 IP 策略。利用 Redis 實(shí)現(xiàn) IP 數(shù)據(jù)的生命周期管理，借助 Redis TTL 功能，可以更輕松實(shí)現(xiàn) IP 數(shù)據(jù)的定時(shí)釋放（判刑也有時(shí)限，黑名單用戶同樣如此）。

SLS 異常 IP 自動(dòng)檢測(cè)

這里基于阿里云 SLS 提供的 Python SDK 來實(shí)現(xiàn)定時(shí)查詢和結(jié)果處理，SDK 已經(jīng)提供了完善的 SLS 操作方法，文檔也豐富，可以快速完成對(duì)應(yīng)功能的實(shí)現(xiàn)。其核心處理代碼如下：

def get_logs_from_sls():
    # 查詢阿里云sls記錄中有可能是攻擊的ip SQL 拼接
    query = "\"rate limit for true-client-ip:\"|select " + \
        " ..... + \ #此處省略N個(gè)重要的SQL拼接部分
        " limit all "
    ...
    # 通過SQL查詢?nèi)罩尽?
    request = GetLogsRequest(project_name, logstore_name, from_time, to_time, query=query)
    response = client.get_logs(request)
    #日志處理為json格式
    logs_data={}
    for log in response.get_logs():
        ip = None
        ...
        if ip and cnt:
            #判斷是否為 辦公室 / 合作方 IP
            if not is_in_whitelist(ip):
                logs_data[ip]=int(cnt)
            else:
                continue
    return logs_data

整體程序主要步驟如下：

1. 利用 SLS 查詢分析出高頻訪問 IP
2. 基于白名單去重，生成最終的異常 IP 清單，供后續(xù)使用。

AWS WAF 動(dòng)態(tài)更新 IP 策略

AWS WAF（Web Application Firewall）是 Amazon Web Services 提供的一種托管型 Web 應(yīng)用防火墻服務(wù)，用于保護(hù) Web 應(yīng)用程序免受常見的網(wǎng)絡(luò)攻擊。該設(shè)置步驟需要兩部分內(nèi)容：

• IP sets：用于定義封堵/允許的 IP 地址池，單個(gè)設(shè)置上限為 1 萬條。
• Web ACLs：WAF 主要配置策略，引用 IP sets 中的地址池并設(shè)置對(duì)應(yīng)的訪問策略（運(yùn)行/拒絕）

此處，采用 AWS 提供的 Python SDK boto3 來進(jìn)行 waf 相關(guān)的更新與創(chuàng)建。核心操作代碼如下：

# 創(chuàng)建 Web ACL
def create_web_acl(waf_acl_name, waf_rules):
    try:
        response = waf_client.create_web_acl(
            Name=waf_acl_name,  # Web ACL 的名稱
            Scope=region_scope,  # 適用于 Regional 或 CLOUDFRONT
            DefaultAction={
                'Allow': {}  # 默認(rèn)操作：拒絕流量
            },
            Rules=waf_rules,
            VisibilityConfig={
                'SampledRequestsEnabled': True,
                'CloudWatchMetricsEnabled': True,
                'MetricName': waf_acl_name+'ACLMetric'
            }
        )
        return response['Summary']['Id']
    except ClientError as e:
        mylog("error",f"Error creating Web ACL: {e}")
        return None

其中變量“waf_rules”定義的就是阻擋策略，以下是一個(gè)具體配置示例，其中 arn 就是關(guān)聯(lián) IP sets 與 Web ACL 的關(guān)鍵：

{
  "Name": "blacklist_ip_sets_1",
  "Priority": 101,
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "blacklist_ip_sets_1_Metric"
  },
  "Statement": {
    "IPSetReferenceStatement": {
      "ARN": "arn:aws:****0f"
    }
  }
}

整體更新流程需要操作的內(nèi)容如下：

• 從 Redis 讀取 IP 數(shù)據(jù)集，處理成 ip 格式：“192.168.1.100/32”，并以 5000（上限為 1 萬）進(jìn)行分組。
• 對(duì)于分組后的數(shù)據(jù)，創(chuàng)建 / 更新 對(duì)應(yīng)的 IP sets 信息。
• 記錄創(chuàng)建/更新的 IP sets 的 name，arn 信息，提供后續(xù)使用。
• 讀取現(xiàn)有 WEB ACLs 配置，記錄歷史 rule 信息，只更新自動(dòng)創(chuàng)建的策略。

創(chuàng)建后的效果展示：

通過以上操作，再配置上對(duì)應(yīng)的運(yùn)行環(huán)境，定時(shí)任務(wù)就可以實(shí)現(xiàn)異常 IP 自動(dòng)獲取與 Waf 更新，非常完美。

01 客戶反饋

SLS 是真的好用，關(guān)鍵時(shí)刻確實(shí)頂，接下來需要好好學(xué)習(xí) SQL，把價(jià)值發(fā)揮起來！

02 技術(shù)關(guān)鍵詞

異構(gòu)數(shù)據(jù)特征提取、regexp_extract、ip_to_country、單表自 join。

結(jié)語

本文講述了一個(gè)大型平臺(tái)客戶被惡意攻擊的溯源分析案例，結(jié)合多種異構(gòu)的訪問日志數(shù)據(jù)源，利用關(guān)鍵詞檢索、正則提取、JOIN 關(guān)聯(lián)分析、地理位置函數(shù)等溯源到惡意攻擊來源，并有效進(jìn)行了安全防控。不管是什么樣的數(shù)據(jù)，在阿里云日志服務(wù) SLS 中，利用高性能的查詢檢索和靈活易用的分析能力，都可以實(shí)現(xiàn)任意且靈活的業(yè)務(wù)分析、安全審計(jì)、風(fēng)險(xiǎn)預(yù)估，幫助客戶在關(guān)鍵時(shí)刻快速定位問題、鎖定目標(biāo)、消除風(fēng)險(xiǎn)。

到此這篇關(guān)于阿里云日志服務(wù)SLS：從海量亂序日志中“揪”出惡意攻擊來源的文章就介紹到這了,更多相關(guān)阿里云日志服務(wù)SLS：日志中找出攻擊源內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！