技術文章 · IT 指令工具箱

防火牆擋到哪個網域?從被阻擋 IP 反查 FQDN 的跨廠牌做法

防火牆只看到被擋 IP,怎麼找原始 FQDN?整理 Palo Alto、FortiGate、Sophos、Check Point、Cisco、pfSense、OPNsense、MikroTik、Meraki 與 UniFi 查法。

作者 Steve Chen · 發布  · 約 39 分鐘閱讀

IT 指令工具箱 — 廷皓技術專欄插圖

先講結論:只有一個目的 IP,通常不能百分之百反推出使用者當時開的 FQDN。真正可靠的做法,是拿阻擋時間、來源 IP、目的 IP、規則 ID 與連線埠,去對同一時間的 DNS 回應、FQDN 物件快取、URL/Web Filter log 或 TLS SNI。PTR 反查只能當線索,尤其碰到 CDN、共用主機與雲端服務時,絕對不能直接拿 PTR 當放行依據。

86 組範例PAN-OS/FortiOS/SFOS/Check PointCisco FTD/Meraki MX/UniFipfSense/OPNsense/RouterOS查核日期:2026-08-11
動手前:本頁以唯讀查詢為主。不要為了看到網域就關閉 SSL/TLS 驗證、停用資安功能、清空 DNS/FQDN cache,或直接放行整個 CDN IP 網段。封包擷取只鎖定單一來源、目的與短時間,PCAP、URL、DNS query 及使用者資料要按公司規範保存。

先把事件座標釘死

記下阻擋事件的七個欄位任何防火牆

時間=<含時區> 來源IP=<client> 目的IP=<blocked-ip> 協定=<tcp/udp> 目的Port=<port> 規則=<rule/policy-id> 動作=<drop/reset/block>

少了時間與來源 IP,後面很容易把別人的 DNS 查詢配到這筆連線。NAT 前後位址也要一起記。

在 Windows 留下含時區時間PowerShell

Get-Date -Format o

ISO 8601 會帶時區,方便和 UTC、SIEM、雲端管理平台對時間。

在 Linux 留下含時區時間Linux/macOS

date --iso-8601=seconds

macOS 內建 date 不支援這個長參數,可改用 date '+%Y-%m-%dT%H:%M:%S%z'。

先做 PTR 反查PowerShell

Resolve-DnsName -Name 203.0.113.50 -Type PTR -ErrorAction SilentlyContinue

PTR 是 IP 擁有者設定的反向名稱,可能沒有、過期或只顯示 CDN 節點;只能當候選。

用 dig 查 PTRLinux/macOS

dig +short -x 203.0.113.50

結果不是使用者輸入的網址證明,也不能表示這個 IP 只服務該網域。

用 DNS、憑證與封包把候選名稱對回去

正向確認候選網域 IPv4/IPv6PowerShell

Resolve-DnsName candidate.example -Type A; Resolve-DnsName candidate.example -Type AAAA

現在解析到同一 IP 只代表現在相符;要判斷歷史事件仍需當時 DNS log。

用 dig 正向確認候選網域Linux/macOS

dig +short A candidate.example; dig +short AAAA candidate.example

CDN 會依地點、DNS resolver 與時間回不同答案,不能只在工程師電腦查一次。

帶候選 SNI 查看 TLS 憑證OpenSSL

openssl s_client -connect 203.0.113.50:443 -servername candidate.example -brief </dev/null

這是在驗證已知候選名稱,不是從 IP 自動找出所有網域;共享憑證也可能涵蓋多個名稱。

短時間擷取該用戶端的 DNSLinux/防火牆 Shell

tcpdump -ni <LAN介面> 'host 192.168.10.25 and port 53' -c 200 -w blocked-dns.pcap

只在核准的測試重現期間執行;若用戶端走 DoH/DoT,這裡可能看不到明文 query。

從 DNS 回答找指定 IPv4Wireshark

dns.a == 203.0.113.50

找到 A record 後,再核對 frame time、來源用戶端與 query name。

從 DNS 回答找指定 IPv6Wireshark

dns.aaaa == 2001:db8::50

IPv6 事件要對 AAAA 回答,不能只查 A record。

檢查 TLS ClientHello 是否還看得到 SNIWireshark

ip.dst == 203.0.113.50 && tls.handshake.extensions_server_name

SNI 能補強判斷,但 QUIC、ECH、連線重用、分段或設備辨識能力都可能讓欄位缺席。

Palo Alto PAN-OS/Panorama

先鎖定 Traffic logPAN-OS GUI

Monitor > Logs > Traffic:套用 (addr.src in 192.168.10.25) and (addr.dst in 203.0.113.50) and (action neq allow)

打開詳細資料,記下 Receive Time、Rule Name/UUID、Application、Session ID、NAT IP 與 Session End Reason。

用相同目的 IP 查 URL Filtering logPAN-OS GUI

Monitor > Logs > URL Filtering:套用 (addr.dst in 203.0.113.50)

若政策有產生 URL log,可直接看到 URL/Filename、Category、Rule、來源與 Session ID;不是所有 App-ID 阻擋都會產生 URL log。

查 DNS Security/Threat logPAN-OS GUI

Monitor > Logs > DNS Security 或 Threat:以來源 IP 與事件時間縮小

DNS Security log 可留 Query Name/FQDN 與 DNS response;用來源與時間對回被擋 session。

列出目前 FQDN 對應PAN-OS operational mode

show dns-proxy fqdn all

用來找目前哪個 FQDN 物件含有該 IP;它是現在的 cache,不是歷史證據。

查單一候選 FQDNPAN-OS operational mode

show dns-proxy fqdn name candidate.example

確認防火牆目前解析到哪些 A/AAAA 位址。

查 DNS proxy 的 A record cachePAN-OS operational mode

show dns-proxy cache filter FQDN candidate.example type RR_A all

命令階層會隨 PAN-OS 版本調整,先用 ? 核對;沒有啟用 DNS Proxy 時不一定有用戶端查詢。

用 Session ID 串 Traffic 與 URL logPAN-OS/Panorama

Traffic Session ID=<id> ↔ URL Filtering Session ID=<id>

同一目的 IP 可能服務很多網站,Session ID 比只靠秒級時間更可靠。

FortiGate/FortiOS

先看 Forward Traffic 詳細欄位FortiGate GUI

Log & Report > Forward Traffic:Destination = 203.0.113.50,並加 Source、時間、Action 篩選

記下 policyid、sessionid、dstip、dstport、action、UTM action、VDOM 與 NAT 欄位。

找 hostname/dstname 與 UTM logFortiGate/FortiAnalyzer

在詳細 log 搜尋:hostname、dstname、url、policyid、sessionid、utmaction

欄位是否存在取決於 DNS Filter、Web Filter、SSL inspection、log 設定與 FortiOS 版本。

列出目前所有 FQDN 物件解析 IPFortiGate CLI

diagnose firewall fqdn list-ip

直接搜尋被擋 IP,可找到目前命中的 FQDN address object;多 VDOM 先確認所在 VDOM。

查單一 FQDN address objectFortiGate CLI

diagnose firewall fqdn get-ip <FQDN_address_object_name>

參數是 address object 名稱,不一定等於真正的網域字串。

傾印 FQDN cacheFortiGate CLI

diagnose test application dnsproxy 6

官方定義為 Dump FQDN;輸出可能很長,先在維護終端記錄,勿用 restart 選項。

傾印 DNS cacheFortiGate CLI

diagnose test application dnsproxy 7

若 FortiGate 有處理相關 DNS,從 cache 找 answer;這仍是目前 cache,不保證保留事故當時內容。

查看 hostname cacheFortiGate CLI

diagnose test application dnsproxy 13

不同 FortiOS build 的選單可能不同,先執行 diagnose test application dnsproxy 確認 13 的功能。

用 DNS Filter log 對時間與用戶端FortiGate GUI

Log & Report > Security Events > DNS Query:Source = 192.168.10.25,時間貼近阻擋事件

找到 query name 和 DNS answer 後,再回 Forward Traffic 對 policyid/sessionid。

Sophos Firewall/SFOS

先確認是哪一層擋下來Sophos Firewall GUI

Log viewer > Firewall:Destination IP = 203.0.113.50,再加 Source IP、時間與 Action

先記 fw_rule_id、來源、目的、port 與時間。Sophos 的 Firewall log 不會通用地把目的 IP 反查成 FQDN;Session 通常在收到 Destroy、關閉後才寫入。

有 Web Filter log 才能直接看 domainSophos Firewall GUI

Log viewer > Web filter:用 Source IP、Destination IP 與同一時間窗篩選

只有流量真的由 Web Policy/Proxy 處理且留下 web log 時,detail/syslog 才可能同時有 dst_ip、domain、url、web_policy_id。純 L3 Firewall drop、FQDN Host 規則未命中或沒有 web log 時,這條路不能反查。

匯出同一時間窗留證Sophos Firewall GUI

Log viewer > Timer filter > Add filter > Export logs

Firewall 與 Web filter 分別匯出;若 Web Filter 的 domain 已存在,它是交易紀錄,不必再拿 PTR 猜。沒有 domain 時,改查下面的 runtime hostset。

先看 SFOS runtime FQDN hostset 的格式Sophos Advanced Shell(唯讀)

/sbin/ipset -L hostset | grep -E 'HOSTID=.*TYPE=(fqdn|wcfqdn)' | head -n 20

這不是一般 Device Console 指令,要從 CLI 選 5 > 3 進 Advanced Shell。fqdn 是一般 FQDN Host,wcfqdn 是 wildcard FQDN;hostset 屬內部實作,格式可能隨 SFOS 版本改變。

用一段唯讀腳本由 IP 反找 HOSTIDSophos Advanced Shell(SFOS 19.5–22 先核對輸出)

TARGET_IP='203.0.113.50'
/sbin/ipset -L hostset |
awk -v ip="$TARGET_IP" '
/HOSTID=[0-9]+,TYPE=(wc)?fqdn/ {
  match($0,/HOSTID=[0-9]+/); id=substr($0,RSTART+7,RLENGTH-7)
  match($0,/TYPE=[^, ]+/); type=substr($0,RSTART+5,RLENGTH-5)
  next
}
$1==ip && id!="" {print id, type}
' | sort -u

輸出例如 714 fqdn,代表這個 IP 目前在 HOSTID 714 的 runtime set。沒有輸出可能是 TTL/eviction 已移除、wildcard DNS 沒經過防火牆、格式變更,或這個 IP 根本不屬於任何已載入 FQDN Host;不能因此硬猜網域。

用唯讀 SQL 把 HOSTID 對回物件與 FQDNSophos Advanced Shell/PostgreSQL

psql -U nobody -d corporate -c "SELECT hostid,hostname,netid,hosttype FROM tblhost WHERE hostid=714;"

把 714 換成上一步結果。hostname 是物件名稱,netid 通常是設定的 FQDN;常見 hosttype 11 為一般 FQDN、18 為 wildcard。只准 SELECT,禁止 UPDATE、DELETE 或直接修 corporate DB;欄位若和當版不同就停下並查 API/Sophos Support。

一次跑完 hostset 與 SQL 對照Sophos Advanced Shell(唯讀腳本)

TARGET_IP='203.0.113.50'
/sbin/ipset -L hostset | awk -v ip="$TARGET_IP" '
/HOSTID=[0-9]+,TYPE=(wc)?fqdn/ {
  match($0,/HOSTID=[0-9]+/); id=substr($0,RSTART+7,RLENGTH-7)
  match($0,/TYPE=[^, ]+/); type=substr($0,RSTART+5,RLENGTH-5); next
}
$1==ip && id!="" {print id, type}
' | sort -u | while read HOST_ID HOST_TYPE; do
  case "$HOST_ID" in ''|*[!0-9]*) continue ;; esac
  printf '\nRuntime match: hostid=%s type=%s\n' "$HOST_ID" "$HOST_TYPE"
  psql -U nobody -d corporate -c "SELECT hostid,hostname,netid,hosttype FROM tblhost WHERE hostid=${HOST_ID};"
done

整段只有 ipset list 與 SQL SELECT,不會改規則或 cache。先在當版測試機核對輸出;HA 要在實際處理流量的節點查,必要時兩台各跑一次。

驗證指定 FQDN Host 是否真的含該 IPSophos Advanced Shell(唯讀)

/sbin/ipset test hostset fqdn,714,0,203.0.113.50

714 與 fqdn 都要換成前面查到的 HOSTID/TYPE;wildcard 用 wcfqdn。看到 is in set hostset 才代表目前 runtime policy set 有這個 IP,GUI 顯示與 runtime set 偶爾可能不一致。

查物件是否直接放在目的規則Sophos Advanced Shell/PostgreSQL

psql -U nobody -d corporate -c "SELECT fwruleid,hostid FROM tblfwdest WHERE hostid=714;"

這只能找直接引用該 hostid 的目的規則;若物件放在 FQDN Host Group、例外、NAT、SD-WAN、VPN 或其他功能,還要回 GUI 的物件使用情況與當版 API 查,不能把零列解讀成未使用。

Runtime 已沒有時改查歷史線索Sophos Advanced Shell/外部 Syslog

grep -F 'candidate.example' /log/fqdnd.log /log/dnsgrabber.log /log/webproxy.log 2>/dev/null

fqdnd.log 是一般 FQDN service,dnsgrabber.log 是 wildcard FQDN 學習;本機輪替後未必還在。若事故發生在 TTL/eviction 之前卻沒有保存 DNS、Web 或外部 syslog,Sophos 無法事後從單一 IP 還原原始 FQDN。

Check Point Quantum/SmartConsole

從 Drop log 鎖定目的 IPSmartConsole Logs & Events

action:Drop destination:203.0.113.50

若實際動作是 Reject/Prevent/Block,改成事件中的 Action;同時限制時間與 Gateway。

把來源與目的綁在一起SmartConsole Logs & Events

source:192.168.10.25 destination:203.0.113.50

再加入 service:HTTPS 或規則名稱,可排除共用 IP 上其他 session。

讓 IP 在所有欄位搜尋SmartConsole Logs & Events

203.0.113.50

Check Point 的 destination 欄位可能顯示 IP、DNS name 或 network object name;全欄位搜尋能補到物件名稱。

查 Application Control/URL FilteringSmartConsole Logs & Events

blade:"Application Control" OR blade:"URL Filtering"

加上來源、時間後,打開 log card 檢查 URL、Domain、Application/Site、Rule Name 與 Session UID。

檢查 Domain objectSmartConsole Policy

Security Policies > Access Control:搜尋目的 IP、物件名稱或 .candidate.example

勾選 FQDN 的 Domain object 由 Gateway 直接 DNS 查詢;未勾 FQDN 的 reverse lookup 較不準,不能混為一談。

短時間擷取 DNSCheck Point Expert mode

tcpdump -ni any 'host 192.168.10.25 and port 53' -c 100 -w /var/log/fqdn-check.pcap

Cluster/VSX/Maestro 要先確認 member、VS 與 capture point;取得足夠樣本後立即停止。

Cisco Secure Firewall/FMC/FTD

從 Connection Events 查阻擋Cisco FMC

Analysis > Connections > Events:篩選 Source IP、Destination IP、時間與 Action

查看 Access Control Rule、Reason、URL、DNS Query、Application、Initiator/Responder 與 NAT 欄位。

先看 URL,再看 DNS QueryCisco FMC Connection Event

URL=<若有>;DNS Query=<若有>;Destination IP=203.0.113.50

官方說明:DNS filtering 事件可能 URL 空白但 DNS Query 有值,不能看到 URL 空白就判定沒有網域。

列出所有 FQDN object 的目前解析FTD CLI

show dns

只會解析被規則使用的 FQDN object;輸出包含名稱、位址與剩餘 TTL。

查單一候選 FQDNFTD CLI

show dns host candidate.example

用於確認候選名稱目前解析到什麼,不是歷史 DNS 查詢紀錄。

由 IP 反找 FQDN objectFTD CLI

show fqdn ip 203.0.113.50

這是 Cisco FTD 對『哪個 FQDN object 目前含這個 IP』最直接的唯讀查法。

查看完整 FQDN troubleshooting tableFTD CLI

show fqdn

可看到 IP、object、domain、hits 與內部 ID;先確認是在 FTD CLI,不要和 ASA/FXOS prompt 混用。

pfSense Plus/CE

從 Firewall log 找 rule trackerpfSense GUI

Status > System Logs > Firewall:篩選 Destination 203.0.113.50

記下時間、介面、方向、來源、目的、規則描述與 tracking ID。

由 tracker 找實際 PF rulepfSense shell

pfctl -vvsr | grep 1000000103

把數字換成 log 的 tracking ID;只讀查詢,不要用 pfctl -F 清規則或 state。

查看 FQDN alias 的目前內容pfSense GUI

Diagnostics > Tables > 選擇規則使用的 alias > 搜尋 203.0.113.50

hostname alias 會定期重解;這裡顯示目前 PF table,不代表事故當下內容。

用 CLI 查指定 aliaspfSense shell

pfctl -t <alias_name> -T show | grep -F '203.0.113.50'

只在已知 alias 名稱時使用;若是 CDN,單一 hostname alias 可能和用戶端拿到的答案不同。

查 DNS Resolver/filterdns logpfSense GUI

Status > System Logs > System/DNS Resolver

這裡包含 Unbound、dnsmasq 與更新 hostname alias 的 filterdns 紀錄,但預設不一定留每一筆用戶端 DNS answer。

點 IP 旁資訊圖示做反解pfSense GUI

Status > System Logs > Firewall > IP 旁的資訊圖示

GUI 會做 DNS lookup;顯示的名稱仍是當下 PTR/resolver 結果,只能列為候選。

重現時擷取 DNSpfSense GUI

Diagnostics > Packet Capture:Interface=LAN、Host Address=192.168.10.25、Port=53、Count=200

若用戶端 DNS 沒經過 pfSense 或走 DoH/DoT,需改查真正 resolver、endpoint 或 secure web gateway。

OPNsense

從 Live View 找阻擋事件OPNsense GUI

Firewall > Log Files > Live View:dst=203.0.113.50,加 src、action、label 與時間

點每列尾端 info 看 rid;同一 state 通常只記第一包,不能用筆數推算重試次數。

用 rid 回到規則OPNsense GUI

Firewall > Log Files > Live View > 點 rid/info

歷史期間若規則已重排或修改,舊 log 對回的 label 可能不準,需參考設定備份。

由 IP 查所有 Alias referenceOPNsense GUI

Firewall > Diagnostics > Aliases > Find references:203.0.113.50

會檢查 IP 是否符合已載入 alias 或網段,適合找出是哪個 FQDN/URL table 參與規則。

用 CLI 查指定 aliasOPNsense shell

pfctl -t <alias_name> -T show | grep -F '203.0.113.50'

FQDN host alias 預設約每 300 秒重解,現在命中不等於事故當時命中。

查 Unbound resolver logOPNsense GUI

Services > Unbound DNS > Log File:以來源 IP、名稱與事件時間搜尋

只有用戶端真的使用這台 Unbound,而且當時有足夠 logging,才可能還原 query/reply。

測試窗短暫記錄 DNS replyOPNsense GUI

Services > Unbound DNS > Advanced:Log Replies + Tag Queries and Replies

Log Replies 會增加 I/O 並可能拖慢 resolver,只在核准時段短暫開啟,完成後恢復原設定。

從指定來源位址測候選名稱OPNsense shell

drill -b <firewall-source-ip> candidate.example A

這是現在的正向解析測試;不能替代當時 DNS reply。

重現時做窄 Packet CaptureOPNsense GUI

Interfaces > Diagnostics > Packet Capture:Host=192.168.10.25、Port=53、Count=200

搭配 Live View 使用;測完停止並保護 PCAP。

MikroTik RouterOS

只看 firewall topic logRouterOS CLI

/log print where topics~"firewall"

前提是命中的 filter rule 有 log=yes;記下 prefix、來源、目的、協定與時間。

盤點哪些 rule 有開 logRouterOS CLI

/ip firewall filter print detail where log=yes

log-prefix 要能辨識規則用途,否則事後只看到 drop 很難對回政策。

確認 RouterOS 是否替用戶端做 DNSRouterOS CLI

/ip dns print

只有用戶端把 RouterOS 當 resolver,且 allow-remote-requests 與網路設計相符,DNS cache 才有較高參考價值。

由 IP 搜目前 DNS cacheRouterOS CLI

/ip dns cache all print where data="203.0.113.50"

若找到 A record,可看到 name/TTL;cache 過期、直接連 IP 或外部 DoH 都會查不到。

由候選名稱查目前 cacheRouterOS CLI

/ip dns cache all print where name~"candidate.example"

同時檢查 CNAME、A 與 AAAA 鏈,不要只看第一筆。

找使用 tls-host 的規則RouterOS CLI

/ip firewall filter print detail where tls-host!=""

tls-host 依 TLS SNI 比對;ClientHello 分段、QUIC 或 ECH 都可能讓它看不到真實 hostname。

確認 firewall log 寫到哪裡RouterOS CLI

/system logging print where topics~"firewall"

記憶體 log 很快輪替,正式環境應把需要的事件送到有時間同步與保存期限的遠端 syslog。

Cisco Meraki MX

即時判斷 L3 規則Meraki Dashboard

Security & SD-WAN > Appliance status > Tools > Firewall Logging

MX 18.2 以上可在重現流量時看到 Layer 3 規則放行或丟棄;先鎖定用戶端與目的 IP。

查 Layer 7 denyMeraki Dashboard

Network-wide > Monitor > Event log > Event type: Layer 7 firewall rule

NBAR 事件可顯示 destination IP、port、protocol、classification 與 block type;legacy hostname rule 不一定產生同樣事件。

查 IDS/IPS 與 AMPMeraki Dashboard

Security & SD-WAN > Monitor > Security Center

用 client、IP、URI、signature 與時間篩選,先確認不是 IDS/IPS 或檔案掃描造成的 block。

把 L3 flow 長期送 syslogMeraki Dashboard

Network-wide > Configure > General > Syslog:啟用 Appliance Flows,並在 Firewall 規則勾 Syslog

MX 18.101 後訊息類型會依規則顯示 firewall/vpn_firewall 等;flow 主要是 IP、port 與規則。

把 HTTP URL 一起送 syslogMeraki Dashboard

Syslog roles:啟用 Appliance URLs

URLs role 能記 HTTP GET 的網址;HTTPS 不會因此自動出現完整 URL,要靠 NBAR、DNS、內容過濾或其他安全紀錄。

重現時抓用戶端 DNSMeraki Dashboard Packet Capture

Interface=LAN;Filter=host 192.168.10.25 and port 53

FQDN-based L3 rules靠 DNS snooping;若 Dashboard 只留 IP block,短時 DNS capture 能補上 query/answer。

把 FQDN 規則和 DNS 路徑一起核對Meraki MX

Security & SD-WAN > Configure > Firewall:確認命中規則、FQDN/domain 與用戶端 DNS 路徑

直接 IP 連線、未被 MX 看見的 DNS 或加密 DNS,都可能讓 FQDN 關聯不足。

UniFi Gateway/Cloud Gateway

從 Traffic Flows 找 sessionUniFi Network 9.1+

Insights > Flows:篩選 Source、Destination 203.0.113.50、Port、Action 與時間

Traffic Flows 只支援指定 Network/UniFi OS 版本與 Gateway;不支援的型號不能假設有這張表。

匯出 Flow 留存UniFi Network

Insights > Flows > Export

CSV 可保留原始 IP、port、client 與 policy 資訊,避免本機保留筆數到頂後覆蓋。

查 Security DetectionUniFi Network

System Log > Security Detection 或 Insights > Inspection

若是 IDS/IPS,自事件查看 affected client、source/destination IP、protocol、signature 與時間。

查 App/Domain policyUniFi Network

Settings > Policy Engine/Zone-Based Firewall:檢查命中政策的 App、Domain (Web)、Region 與 Action

先分清楚是 IP/zone firewall、Traffic Rule、domain filter 還是 IDS/IPS,四種證據位置不同。

核對 DNS 層 Content FilterUniFi Network

Settings > CyberSecure > Content Filter:檢查 policy、source network/device、allowlist 與 blocklist

Content Filtering 會把 DNS 導向 Gateway 檢查;若事件來自這裡,查的是 domain policy,不是拿目的 IP 做 PTR。

有 dnsmasq log 的機型查 queryUniFi Gateway SSH

tail -f /var/log/dnsmasq.log

官方列出此進階 log 路徑,但實際可用性依 Gateway、Network/UniFi OS 版本;只短時間觀察,不修改或清空。

檢查 IDS 引擎 log 是否提到該 IPUniFi Gateway SSH

grep -F '203.0.113.50' /var/log/suricata/suricata.log

僅用於確認 IDS/IPS 事件;一般 zone firewall block 不一定寫到 Suricata。

送出長期流量紀錄UniFi Network

Settings > CyberSecure > Traffic Logging > NetFlow (IPFIX)

適用支援的 Network/Gateway 版本;長期 DNS/FQDN 關聯仍要由 resolver、SIEM 或 secure web gateway 保留。

怎麼確認有做對

  • 同一筆結論至少有兩種證據,例如 Firewall log 的 Session ID 加 URL log,或阻擋時間加同一用戶端的 DNS answer。
  • 候選 FQDN 的 A/AAAA、TTL、CNAME chain 與被擋 IP 能對上,而且時間是在 DNS TTL 有效範圍內。
  • 已確認真正執行 Block 的功能與規則,不把 Web Filter、DNS Filter、IPS、App Control 和 L3 default deny 混成同一種阻擋。
  • 若只能取得 PTR、現在的 DNS cache 或 WHOIS,結論標示為『候選』,不據此直接新增 allow rule。
  • 修正後從原用戶端重測,確認只有核准的 FQDN/應用恢復,其他原本該擋的流量仍被政策攔下。

常見錯誤

  • 把 nslookup/dig -x 的 PTR 結果當成使用者當時開的網址。
  • 事故隔天才看 FQDN cache,卻忽略 TTL、CDN、GeoDNS 與快取已經換過。
  • 只看目的 IP,不記來源、時間、port、rule ID、Session ID 與 NAT 前後位址。
  • 因為找不到 FQDN,就直接放行整個 CDN/雲端服務商 IP 網段。
  • 只查 Firewall module,漏掉真正執行 Block 的 URL Filtering、Web Filter、DNS Filter、IPS 或 App Control log。
  • 為了抓名稱長時間開無條件 packet capture、DNS debug 或高 verbosity,造成效能與個資風險。
  • 用戶端走 DoH/DoT 或 TLS ECH 時,仍承諾防火牆一定看得到 DNS query 或 SNI。

常見問題

PTR 反查到名稱,就能證明是這個網站嗎?

不能。PTR 是 IP 的反向 DNS 名稱,常只代表主機商或 CDN 節點。要證明使用者當時連哪個網域,至少還要對當時 DNS answer、URL/Web Filter log、TLS SNI、代理伺服器或端點紀錄。

同一個 IP 查到十幾個網域,要放行哪一個?

不要放行 IP。先找出真正業務需要的 FQDN、應用與連接埠,再用 URL category、FQDN object、App-ID 或受控 proxy 做最小放行;共享 CDN IP 可能同時承載無關網站。

為什麼防火牆有阻擋 IP,DNS log 卻完全找不到?

常見原因是直接連 IP、既有 DNS cache、用戶端改用外部 DNS、DoH/DoT、VPN/proxy 代查,或 DNS log 根本沒有在當時啟用。這時改查端點、EDR、瀏覽器、secure web gateway 或受控 DNS resolver。

TLS SNI 一定看得到網域嗎?

不一定。QUIC、TLS ClientHello 分段、連線重用與 ECH 都可能讓設備沒有可用的明文 SNI;看不到不代表沒有連線,也不能反過來猜一個名稱。

現在 FQDN cache 有這個 IP,可以當事故證據嗎?

只能當輔助。要一起保存查詢時間、剩餘 TTL、韌體版本與 cache 來源;若和事故時間差太久,必須標成現在狀態,不能冒充歷史對應。

Sophos Log Viewer 查到被擋 IP,為什麼沒有 FQDN?

因為 Firewall module 的 L3 session log 不會通用地替目的 IP 補上 FQDN。只有 Web Policy/Proxy 真的處理該交易時,Web Filter log 才可能有 domain。要查目前哪個 Sophos FQDN Host 收進這個 IP,需在 Advanced Shell 以 hostset 取得 HOSTID,再用唯讀 SELECT 對回 tblhost;歷史 cache 已過期時仍要靠當時 DNS、Web 或外部 syslog。

延伸閱讀

版本與官方文件

參數會隨工具版本與作業系統實作改變。正式環境先用 --help、-h 或系統內建說明確認,再以當版官方文件為準。

常見問題

PTR 反查到名稱,就能證明是這個網站嗎?

不能。PTR 是 IP 的反向 DNS 名稱,常只代表主機商或 CDN 節點。要證明使用者當時連哪個網域,至少還要對當時 DNS answer、URL/Web Filter log、TLS SNI、代理伺服器或端點紀錄。

同一個 IP 查到十幾個網域,要放行哪一個?

不要放行 IP。先找出真正業務需要的 FQDN、應用與連接埠,再用 URL category、FQDN object、App-ID 或受控 proxy 做最小放行;共享 CDN IP 可能同時承載無關網站。

為什麼防火牆有阻擋 IP,DNS log 卻完全找不到?

常見原因是直接連 IP、既有 DNS cache、用戶端改用外部 DNS、DoH/DoT、VPN/proxy 代查,或 DNS log 根本沒有在當時啟用。這時改查端點、EDR、瀏覽器、secure web gateway 或受控 DNS resolver。

TLS SNI 一定看得到網域嗎?

不一定。QUIC、TLS ClientHello 分段、連線重用與 ECH 都可能讓設備沒有可用的明文 SNI;看不到不代表沒有連線,也不能反過來猜一個名稱。

現在 FQDN cache 有這個 IP,可以當事故證據嗎?

只能當輔助。要一起保存查詢時間、剩餘 TTL、韌體版本與 cache 來源;若和事故時間差太久,必須標成現在狀態,不能冒充歷史對應。

Sophos Log Viewer 查到被擋 IP,為什麼沒有 FQDN?

因為 Firewall module 的 L3 session log 不會通用地替目的 IP 補上 FQDN。只有 Web Policy/Proxy 真的處理該交易時,Web Filter log 才可能有 domain。要查目前哪個 Sophos FQDN Host 收進這個 IP,需在 Advanced Shell 以 hostset 取得 HOSTID,再用唯讀 SELECT 對回 tblhost;歷史 cache 已過期時仍要靠當時 DNS、Web 或外部 syslog。

聯絡廷皓討論 看更多文章