先講結論:只有一個目的 IP,通常不能百分之百反推出使用者當時開的 FQDN。真正可靠的做法,是拿阻擋時間、來源 IP、目的 IP、規則 ID 與連線埠,去對同一時間的 DNS 回應、FQDN 物件快取、URL/Web Filter log 或 TLS SNI。PTR 反查只能當線索,尤其碰到 CDN、共用主機與雲端服務時,絕對不能直接拿 PTR 當放行依據。
先把事件座標釘死
記下阻擋事件的七個欄位任何防火牆
時間=<含時區> 來源IP=<client> 目的IP=<blocked-ip> 協定=<tcp/udp> 目的Port=<port> 規則=<rule/policy-id> 動作=<drop/reset/block>少了時間與來源 IP,後面很容易把別人的 DNS 查詢配到這筆連線。NAT 前後位址也要一起記。
在 Windows 留下含時區時間PowerShell
Get-Date -Format oISO 8601 會帶時區,方便和 UTC、SIEM、雲端管理平台對時間。
在 Linux 留下含時區時間Linux/macOS
date --iso-8601=secondsmacOS 內建 date 不支援這個長參數,可改用 date '+%Y-%m-%dT%H:%M:%S%z'。
先做 PTR 反查PowerShell
Resolve-DnsName -Name 203.0.113.50 -Type PTR -ErrorAction SilentlyContinuePTR 是 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.exampleCDN 會依地點、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::50IPv6 事件要對 AAAA 回答,不能只查 A record。
檢查 TLS ClientHello 是否還看得到 SNIWireshark
ip.dst == 203.0.113.50 && tls.handshake.extensions_server_nameSNI 能補強判斷,但 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 logsFirewall 與 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.50714 與 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/nullfqdnd.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.50Check 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.pcapCluster/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.50hostname 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 RepliesLog 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=yeslog-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 LoggingMX 18.2 以上可在重現流量時看到 Layer 3 規則放行或丟棄;先鎖定用戶端與目的 IP。
查 Layer 7 denyMeraki Dashboard
Network-wide > Monitor > Event log > Event type: Layer 7 firewall ruleNBAR 事件可顯示 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 規則勾 SyslogMX 18.101 後訊息類型會依規則顯示 firewall/vpn_firewall 等;flow 主要是 IP、port 與規則。
把 HTTP URL 一起送 syslogMeraki Dashboard
Syslog roles:啟用 Appliance URLsURLs role 能記 HTTP GET 的網址;HTTPS 不會因此自動出現完整 URL,要靠 NBAR、DNS、內容過濾或其他安全紀錄。
重現時抓用戶端 DNSMeraki Dashboard Packet Capture
Interface=LAN;Filter=host 192.168.10.25 and port 53FQDN-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 > ExportCSV 可保留原始 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 與 blocklistContent 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。
延伸閱讀
- Palo Alto Policy、NAT、VPN 與封包
- FortiGate Policy、NAT、IPsec 與 Debug Flow
- Sophos Firewall 排錯
- Check Point Gaia CLI
- pfSense/OPNsense 排錯
- Meraki MX 授權、VPN 與韌體
- MikroTik RouterOS 排錯
- tcpdump 封包擷取
- DNS dig/nslookup 指令
- 防火牆管理介面安全
版本與官方文件
參數會隨工具版本與作業系統實作改變。正式環境先用 --help、-h 或系統內建說明確認,再以當版官方文件為準。
- Palo Alto PAN-OS CLI hierarchy
- Palo Alto URL Filtering log fields
- Fortinet FQDN addresses and cache
- Sophos Firewall 22.0 Log viewer
- Sophos Firewall 22.0 syslog fields
- Sophos Firewall FQDN Host behavior
- Sophos Firewall troubleshooting log files
- Sophos Community runtime hostset verification
- Sophos Community hostset HOSTID and tblhost lookup
- Check Point R82 Domain objects
- Check Point R82 logging guide
- Cisco Secure Firewall show dns and show fqdn
- pfSense firewall log
- pfSense firewall tables
- OPNsense firewall diagnostics
- OPNsense Unbound DNS logging
- MikroTik RouterOS DNS cache
- MikroTik tls-host matcher
- Meraki blocked traffic troubleshooting
- Meraki syslog roles and examples
- UniFi Traffic Flows and logging
- UniFi content and domain filtering
- RFC 8484 DNS over HTTPS
- RFC 9849 TLS Encrypted Client Hello
常見問題
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。