資安相關

【Linux】禁止密碼登入(使用金鑰)

修改 /etc/ssh/sshd_config

vim /etc/ssh/sshd_config

## 修改 PubkeyAuthentication

PubkeyAuthentication yes
#使用 ssh key 登入
PasswordAuthentication no
#禁止密碼登入

重啟 ssh 服務

sudo systemctl restart sshd.service

 

【shell】deny_hack_ip.sh

簡單阻擋 try 帳號 ip

#! /bin/bash
#cat /var/log/secure|awk '/Failed/{print $(NF-3)}'|sort|uniq -c|awk '{print $2"="$1;}' > /root/block.txt
cat /var/log/secure|awk '/Invalid user/{print $(NF-2)}'|sort|uniq -c|awk '{print $2"="$1;}' > /root/block.txt
DEFINE="10"
for i in `cat  /root/block.txt`
do
    IP=`echo | awk '{split("'${i}'", array, "=");print array[1]}'`
    NUM=`echo | awk '{split("'${i}'", array, "=");print array[2]}'`
    if [ $NUM -gt $DEFINE ];then
     grep $IP /etc/hosts.deny > /dev/null
      if [ $? -gt 0 ];then
          echo "sshd:$IP:deny" >> /etc/hosts.deny
      fi
    fi
done

資安相關連結

下面整理一份「資安一定要知道」的網站速查表，平常做漏洞管理、暴露面盤點、威脅模型、設定基線、事件初判會最常用到的那幾類。

類別 網站/組織 你一定會用到的原因 典型使用情境
漏洞編號權威 CVE.org (CVE Program) 漏洞的全球標準「身分證」與最基本定義來源。(cve.org) 對齊漏洞名稱、內部通報、追蹤供應鏈依賴中的 CVE
漏洞資料庫 NVD (NIST) 把 CVE 補成可管理的資料：常含 CVSS、CWE、CPE 等，方便自動化對帳與風險排序。(NVD) 漏洞嚴重度評估、資產比對、報告引用
已被實戰利用清單 CISA KEV Catalog 告訴你「這顆真的有人在野外利用」，修補優先級通常要直接拉到最前。(CISA) Patch 優先級決策、對管理層/變更會說明
Web 安全共識 OWASP Top 10 Web 風險最常見的基線教材與治理共識；目前仍以 2021 為最新正式版、2025 有 RC 動態。(OWASP) 安規教育、SDL 導入、WAF 規則與測試清單
攻擊技術知識庫 MITRE ATT&CK 威脅模型/檢測與對應防禦的共同語言（戰術/技術）。(MITRE ATT&CK) SOC 規則對齊、紫隊演練、事件回溯與覆蓋率盤點
設定強化基線 CIS Benchmarks / CIS 各大產品/平台的共識型硬化建議，常用來做基線與稽核。(CIS) OS/DB/Cloud 安全基線、合規與稽核
開源漏洞清單 GitHub Advisory Database 對開源套件很實用，能直接對應 registry（npm/pip/maven…）與漏洞資訊。(GitHub) 供應鏈風險、依賴漏洞快篩、DevSecOps
公網暴露面搜尋 Shodan 用來找「連上網的設備/服務」的搜尋引擎，做外部暴露面盤點很直觀。(shodan.io) 自家公網資產盤點、錯誤暴露偵測
公網掃描/盤點 Censys 以網際網路掃描為基礎的資產發現/監測平台，適合做攻擊面治理。(Censys) 對外服務監控、憑證/服務指紋觀測
惡意檔/URL 快篩 VirusTotal 多引擎/多情資的快速「第二意見」，適合初步 triage。(virustotal.com) 可疑檔案、URL、IP/domain 初判
外洩查詢 Have I Been Pwned (HIBP) 查帳號/網域是否出現在已知外洩事件，用於個人與企業風險提醒。(Have I Been Pwned) 帳號風險告警、憑證填充（credential stuffing）防護前置
漏洞利用參考 Exploit-DB 公開 PoC/Exploit 索引，偏研究/測試用途；防守端可用來驗證「是否真的可利用」。(Exploit DB) 修補驗證、風險評估佐證（注意合規與授權）

你可以怎麼把這份表用在日常流程

一條龍最省腦的作法：

  1. 新漏洞出現 → CVE.org 對齊編號。(cve.org)

  2. 去 NVD 看 CVSS/CPE/CWE 做初步排序與資產比對。(NVD)

  3. 檢查是否進 CISA KEV → 有就直接升級為最高修補優先。(CISA)

  4. 開源套件再補查 GitHub Advisory Database。(GitHub)

  5. 對外暴露面用 Shodan/Censys 做「我家有沒有暴露且中版本」的交叉驗證。(shodan.io)

  6. 事件/偵測與演練對照 MITRE ATT&CK。(MITRE ATT&CK)

  7. 長期治理用 OWASP + CIS Benchmarks 建基線。(OWASP)

 

資安新聞

新聞網站名稱 RSS URL 新聞週報參考性 備註
iThome 資安頻道

https://www.ithome.com.tw/rss/security

 主要來源 臺灣最大資安新聞
TWCERT/CC https://www.twcert.org.tw/tw/rss-104-1.xml 主要來源

臺灣電腦網路危機處理技協調中心

著重於臺灣發生或是可能影響臺灣的資安事件新聞

資安趨勢部落格

http://blog.trendmicro.com.tw/?feed=rss2

 主要來源 有每週資安新聞彙整

The Hacker News

http://thehackernews.com/feeds/posts/default

 參考來源  

FreeBuf

http://www.freebuf.com/feed

參考來源

技術文章

有每日資安新聞彙整

有許多技術文章可以看來增進自己的技術知識

技服中心

http://www.nccst.nat.gov.tw/Services/FeedService.svc/GetFeed?lang=zh&category=news&format=rss

 主要來源

國家資通安全會報技術服務中心

認為重要的新聞

安全客-安全知识

https://rsshub.app/aqk/knowledge

 技術文章  

安全客-有思想的安全新媒体

https://api.anquanke.com/data/v1/rss

 參考來源  
技服中心-漏洞警訊

https://www.nccst.nat.gov.tw/Services/FeedService.svc/GetFeed?lang=zh&category=vulnerability&format=rss

 參考來源

國家資通安全會報技術服務中心

所通報認為對台灣影響嚴重的漏洞警訊
F-ISAC

https://fisacs.tw  (這不是RSS)

 主要來源

金融資安資訊分享與分析中心

 

Citrix 進行特定 User-Agent 的阻擋

如果需要在 Citrix ADC 上針對特定網站（例如 api.aaa.com）進行特定 User-Agent 的阻擋，可以基於虛擬服務 (Virtual Server) 或 Host 標頭進行精確匹配。以下是詳細步驟：

方法 1：基於虛擬服務 (Virtual Server)

假設 api.aaa.com 綁定到一個特定的虛擬服務，則可以直接對該虛擬服務配置 Responder Policy 或 Rewrite Policy。

步驟

  1. 找到虛擬服務

    • 登入 Citrix ADC 管理界面。
    • 前往 Traffic Management > Load Balancing > Virtual Servers。
    • 找到綁定 api.aaa.com 的虛擬服務。

  2. 創建 Responder Policy

    • 前往 AppExpert > Responder > Policies。
    • 點擊 Add，輸入以下內容：
      • Policy Name：例如 BlockUserAgentForAPI.
      • Rule： 
        HTTP.REQ.HEADER("Host").EQ("api.aaa.com") && HTTP.REQ.HEADER("User-Agent").CONTAINS("某關鍵字")
      • Action：選擇 DROP 或 Redirect（例如引導到一個錯誤頁）。

  3. 綁定到虛擬服務

    • 編輯對應的虛擬服務。
    • 在 Responder Policies 部分，綁定剛創建的 Policy。

  4. 測試效果

    • 使用工具（如 curl 或 Postman），模擬包含匹配的 User-Agent 訪問 api.aaa.com，應該會被阻擋。

方法 2：基於 HTTP Host Header 的精確匹配

如果 api.aaa.com 與其他應用共享同一虛擬服務，可以基於 Host 標頭進行條件判斷。

步驟

  1. 創建 Responder Policy

    • 配置條件如下： 
      HTTP.REQ.HEADER("Host").EQ("api.aaa.com") && HTTP.REQ.HEADER("User-Agent").CONTAINS("某關鍵字")
    • 動作可以設為：
      • DROP：直接丟棄請求。
      • Redirect：引導至一個錯誤頁面，例如： 
        HTTP.REQ.URL.SET_TEXT_MODE("http://error-page.yourdomain.com")

  2. 綁定到虛擬服務

    • 在對應虛擬服務的 Policies 區域進行綁定。

  3. 測試效果

方法 3：使用 Rewrite 改寫或拒絕請求

改寫方式

如果你不想丟棄請求，而是改變特定 User-Agent 的行為，可以用 Rewrite Policy 改寫請求，例如修改 User-Agent 為通用值或添加額外標頭：

  1. Rewrite Policy 條件

    HTTP.REQ.HEADER("Host").EQ("api.aaa.com") && HTTP.REQ.HEADER("User-Agent").CONTAINS("某關鍵字")

  2. Rewrite Action

    • 替換 User-Agent： 
      HTTP.REQ.HEADER("User-Agent").SET_TEXT("DefaultUserAgent")
    • 添加自定義標頭： 
      HTTP.REQ.HEADER("X-Blocked").SET_TEXT("Blocked")

  3. 綁定到虛擬服務

方法 4：使用 Application Firewall (更高級別保護)

若已啟用 Application Firewall，可基於 Host 和 User-Agent 配置策略：

  1. 創建 Application Firewall Profile

    • 添加一個自定義 Profile，啟用 Signatures。
    • 創建自定義簽名：
      • 名稱：例如 BlockUAForAPI
      • 條件： 
        HTTP.REQ.HEADER("Host").EQ("api.aaa.com") && HTTP.REQ.HEADER("User-Agent").CONTAINS("某關鍵字")

  2. 綁定 Profile 至虛擬服務

測試命令範例

可以使用以下命令測試效果：

curl -H "Host: api.aaa.com" -H "User-Agent: 特定關鍵字" http://<你的 ADC IP>/path

這將模擬請求，並確認是否阻擋成功。

如果有更多需求或複雜場景，可以提供更多細節，我將協助進一步優化配置！

【CVE】CVE相關

https://www.cve.org/
https://nvd.nist.gov/vuln/detail/CVE-2025-55182

image-1765263221534.png

我用「照著你這張圖從上到下」的方式，帶你看每一塊在講什麼、要怎麼解讀、你實務上該拿哪幾段去做判斷。這張圖看起來就是 NVD 的 CVE 詳細頁截圖。

image-1765263850143.png

1) 標題區：你現在在看哪一個漏洞

最上面：CVE-2025-55182 Detail

2) Description：用一句到兩句話告訴你「這是什麼」

你圖上的描述大意是：

你可以把這段當成第一層判讀：

「未登入就可能打 RCE」
→ 這種通常在企業環境都是最高優先級。

image-1765263899408.png

3) Metrics / CVSS 分頁：看嚴重度分數與誰給的

這區通常有三個 tab：

你截圖目前是在 CVSS v3.x 的畫面。

你圖上有兩條來源很重要：

(A) NIST: NVD

意思：
NVD 官方還沒完成自己的評分。

(B) CNA: Facebook, Inc.

意思：
由 CNA（這裡是 Facebook/Meta）先提供了分數與向量。
所以你現在可以先用這個做風險判斷。

4) 看懂 CVSS 3.1 向量（你圖上那串）

這串：

AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

你可以用一句白話解：

所以這組合很典型就是：
「高可利用性 + 高破壞性」
→ 10 分合理。

5) References to Advisories, Solutions, and Tools

這張表是你實務上最常點的區塊。

你會看到：

你可以這樣用：

6) “This CVE is in CISA’s KEV Catalog”

這段超關鍵。

你圖上直接寫：

This CVE is in CISA’s Known Exploited Vulnerabilities Catalog

底下表格有：

白話解讀：

這顆不是「可能會被打」
是「已經在野外有人拿來打」
所以 CISA 直接要求你在期限前完成修補或緩解。

這一段就是你對管理層/變更委員會最好用的「加速器」。

7) Weakness Enumeration（CWE）

你圖上是：

它是在告訴你漏洞類型家族：

不安全反序列化

這對你做：

都很有用。

8) Known Affected Software Configurations（CPE）

這區會列：

你要注意兩件事：

(A) 這是「NVD 的結構化影響清單」

它方便你：

(B) CPE 有時會「過度或滯後」

尤其遇到：

所以最終修補版本與實際影響判斷
仍要回頭以：

做最後確認。

9) 你要怎麼用這張頁面做「實務決策」

你可以用這個超短流程：

  1. 看 Description

    • 確認類型：pre-auth RCE？

  2. 看 CVSS

    • 即便 NVD 還沒評分，也先用 CNA 分數

  3. 看 KEV 有沒有上榜

    • 有 → 直接拉到最高優先

  4. 看 References 的 Vendor Advisory / Patch

    • 找正確修補版本

  5. 看 CPE

    • 跟你環境做快速自動比對

  6. 回到你專案依賴

    • package-lock.json / yarn.lock / pnpm-lock.yaml

    • SBOM

    • Runtime 掃描

一句話總結你這張圖的重點

 

【名詞解釋】CPE - 軟體/硬體/作業系統的標準化身分證

CPE 可以把它想成**「軟體/硬體/作業系統的標準化身分證」**，用來讓不同的弱掃、資產盤點、漏洞資料庫能用同一種語言描述「到底是哪個產品、哪個版本」。

CPE 是什麼

CPE（Common Platform Enumeration） 是 NIST 定義的一套命名標準。
它用統一格式描述：

目的：
讓「漏洞（CVE）」可以清楚綁到「受影響產品/版本」。

你會在哪裡看到 CPE

最常見的地方：

CPE 2.3 長什麼樣（看得懂就好）

你常見的是 CPE 2.3 格式：

cpe:2.3:<part>:<vendor>:<product>:<version>:...

其中 <part> 通常是：

（後面還有很多欄位，但實務上你最常看前 4-5 個就夠了。）

為什麼 CPE 很重要（實務角度）

有 CPE，你就能做到：

  1. 自動化對帳

    • 你的資產清冊 / SBOM / 掃描結果

    • 跟 NVD 的受影響清單做比對
      → 快速找出「我是不是中招」。

  2. 跨工具一致性

    • 不同廠牌的掃描器

    • 不同資料來源
      都能用同一套識別方式對齊。

但 CPE 也有現實限制

這點很關鍵，避免誤判：

所以最佳做法是：

CPE 用來快速盤點
最終以原廠公告 + 你的 lockfile/SBOM 驗證

一句超白話總結

CPE = 讓漏洞資料庫能精準說「哪個產品/哪個版本」的標準名稱。
它是 CVE 與你的資產之間的重要橋樑。

 

【名詞解釋】NIST 美國國家標準與技術研究院

NIST 是美國國家標準與技術研究院（National Institute of Standards and Technology）。
你可以把它理解成一個替政府與產業制定/維護技術標準與安全指引的權威機構。

在資安領域你最常見到 NIST 的地方：

一句話：
NIST 就是美國最重要的「技術與資安標準制定/指引中心」之一，
很多全球通用的漏洞與資安管理做法都會跟它有關。

【名詞解釋】CVE - 漏洞的全球統一編號/身分證

CVE 是**「通用漏洞與曝露」（Common Vulnerabilities and Exposures），你可以把它想成漏洞的全球統一編號/身分證**。

它在做什麼？

CVE 本身包含什麼？

通常是：

但 CVE 不一定會有完整的風險評分或受影響產品細節。
更完整的整理常會去看：

一句話

CVE = 漏洞的標準化命名與編號系統，用來統一追蹤與溝通。

【名詞解釋】CNA - CVE 編號授權/編號發放單位

CNA 是 CVE Numbering Authority 的縮寫，中文可以理解成**「CVE 編號授權/編號發放單位」**。

白話版

CNA 就是被官方授權可以：

  1. 分配 CVE 編號

  2. 撰寫/提交該漏洞的官方描述與資料

所以很多 CVE 是由各大廠或重要開源組織自己登記的。

你會在哪裡看到 CNA

在 NVD 或 CVE 詳細頁常會看到：

為什麼重要

一句話總結

CNA = 被授權負責「發 CVE 編號 + 提交漏洞官方資訊」的單位。

【名詞解釋】CVSS 通用漏洞評分系統

CVSS 是 Common Vulnerability Scoring System，中文常翻 「通用漏洞評分系統」。
你可以把它理解成：用一套標準公式，把漏洞危險程度量化成分數（0~10），方便你排序修補優先級。

它解決什麼問題？

同一個漏洞有人說很嚴重、有人說還好。
CVSS 讓大家用同一把尺衡量。

分數怎麼看？

一般會看到這種分類：

你最常看到的是「CVSS v3.1 向量」

像這樣：

AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

白話解讀：

欄位 你要看什麼 代碼 → 白話
AV 攻擊途徑 能不能遠端打 N 網路遠端（最危） / A 鄰接網路 / L 本機 / P 實體
AC 攻擊複雜度 好不好打 L 好打 / H 難打
PR 需要權限 要不要登入/權限 N 不用 / L 低權限 / H 高權限
UI 使用者互動 要不要人配合 N 不用點擊 / R 要使用者操作
S 影響範圍 會不會跨邊界 U 不跨 / C 跨（通常會拉高嚴重度）
C/I/A 影響面 被打中會多慘 N 無 / L 低 / H 高（機密/完整/可用）

實務上怎麼用最有效？

你可以這樣做排序：

  1. 先看 CVSS 判斷技術嚴重度

  2. 再看 KEV

    • 有進 KEV → 代表已在野外被利用 → 直接拉到最前面

  3. 加上你自己的環境因素

    • 是否對外暴露

    • 是否核心資產

    • 是否有補償控制

一句話

CVSS = 幫你把漏洞風險「用 0~10 分標準化量化」的系統，
用來做修補優先級與風險溝通。

CVSS vXX向量 如何解讀

你可以把 CVSS 向量想成一串「漏洞特性設定值」，每個欄位都對應一個風險面向。
解讀方式就是：把每個縮寫拆開 → 看它選了哪個值 → 對應官方定義。

下面我用你最常會遇到的 v3.1 和新一代 v4.0 來示範，最後告訴你參數去哪裡查。

怎麼解讀 CVSS v3.1 向量

典型長相：
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

你可以照這個順序讀：

Base Metrics（最常用、最重要）

你可以用一個超快口訣理解

CVSS v4.0 有什麼不一樣？

v4.0 把 v3.x 一些模糊處拆更細，
更強調可重現性、真實情境的細節。

你可能會看到類似：

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

你會注意到幾個新或改良概念

那 CVSS v2.0 呢？

你可能還會在老系統看到：

AV:N/AC:L/Au:N/C:C/I:C/A:C

你要去哪裡查「每個參數的官方定義」？

1) FIRST 官方文件（最權威）

CVSS 的規格與定義是由 FIRST 維護。
你要查：

2) 官方計算器（最好用）

用計算器的好處：

你可以用：

3) NVD 的 CVE 詳細頁

NVD 頁面上會直接列：

一個實務上超好用的解讀流程

  1. 先看版本

    • CVSS:3.1 或 CVSS:4.0

  2. 先抓「好不好打」

    • AV / AC / PR / UI
      如果看到
      AV:N + PR:N + UI:N + AC:L
      → 先把它當高優先級候選。

  3. 再看「影響多大」

    • v3.x 看 C/I/A

    • v4.0 看 VC/VI/VA + SC/SI/SA

  4. 最後再加上你自己的環境因素

    • 是否對外

    • 是否核心資產

    • 有無 WAF/隔離/補償控制

    • 是否進 KEV（有的話優先級再往前）

你可以直接套用的白話翻譯模板

看到一串向量，你可以這樣快速寫成一句話：

這個漏洞可以 （AV） 從 （攻擊途徑） 發動，
攻擊難度 （AC），
不需要/需要 （PR/UI），
影響 （C/I/A 或 VC/VI/VA），
是否跨安全邊界 （S 或 v4 的後續系統影響）。

如果你願意，我可以拿你們實際遇到的一條向量（你貼一串就好），
幫你逐欄位翻成中文 + 寫成 1-2 句可放事故/風險報告的描述。

【名詞解釋】KEV 已知遭利用漏洞清單

KEV 是 Known Exploited Vulnerabilities 的縮寫，通常指 CISA 的「已知遭利用漏洞清單（KEV Catalog）」。

你可以把它當成：

「這些漏洞不是理論風險，是真的已經有人在野外拿來打了」的名單。

KEV 用來做什麼

KEV 清單常見欄位（你會看到）

一句話實務規則

CVSS 告訴你「多危險」，
KEV 告訴你「已經有人在用這顆打人」。

所以實務排序常會是：

KEV 優先於單看 CVSS。

 

【名詞解釋】NVD 美國國家漏洞資料庫

NVD 是 National Vulnerability Database（美國國家漏洞資料庫），由 NIST 維護。

你可以把它想成 「CVE 的進階資料站」：

NVD 會提供什麼

常見會看到：

你何時會用到

一句話：
NVD = NIST 維護的漏洞百科，讓 CVE 變得可評分、可對帳、可管理。