當使用 Android 手機連線到一個 802.1X 的網路，在 EAP 方法 (Method) 選擇使用 PEAP 或是 EAP-TTLS 時，在下方的欄位會看到一個叫做 匿名使用者 (anonymous identity)。
而在學術網路 (TANet) 上的很多教學文件裡面，會請使用者直接留空不填，但到底這個欄位是為了什麼而設計？
針對這個問題，在這次協助建置 eduroam 的同時研究出一些心得，提供一些個人的解讀及看法給大家。
最近在重新複習 FreeRADIUS 的架構，剛好在測試的過程中，我把家裡的 FortiGate 從 7.2.9 upgrade 到 7.2.10，在 FortiGate GUI 上面執行 Test Connectivity 就發生 invalid secret for the server 這個錯誤訊息
這個問題源自於名為 Blast-RADIUS (CVE-2024-3596) 的 RADIUS 協定漏洞，只要是在不安全的網路環境裡面使用非 EAP 驗證框架搭配 RADIUS over UDP 協定，就容易遭受中間人攻擊
因為我們是使用 FreeRADIUS，所以在官方的 Security Note 裡面也有提到這個訊息。
然而文中也提到，他們其實早在 1998 年就注意到也嘗試的修正
The truly sad thing is that we’ve been trying to fix this issue since 1998. The first public record we can find of anyone complaining about this issue is by Alan DeKok (FreeRADIUS founder) in 1998. Alan further tried to fix it in RFC 5080, Section 2.2.2, in 2007.
當然最好的辦法就是將你的 RADIUS Server 升級到可支援 RadSec (RADIUS over TCP) 這個協定並啟用他，只不過這件事情非同小可，整個通訊架構將會有所改變，勢必需要長期規劃。
先前有提到 eduroam 採用的是 RADIUS 及 802.1X 的技術，那麼這一篇來談談在 TANet 上面導入這項服務需要注意的一些事情。
以前待過的學校最近要開始建置 eduroam 國際跨校漫遊的 802.1X 服務，所以回頭複習了一下之前的建置紀錄，重新喚醒記憶。
前面提到了 FortiGate 如何透過 External Connectors (Threat Feeds) 來獲取 RBL，進而運用在 Firewall Policy 上過濾進出流量之外，也可以保護 FortiGate 自身所提供的服務。
具一定規模的企業，通常會將 FortiGate 的 Traffic / System Log 導向自建的 Log Server 或是 (Security Information and Event Management, 簡稱 SIEM) 來進行分析，透過分析比對出惡意 IP 之後可以自動化的方式來連動資安設備進行阻斷，或是整理成自家的 RBL file 提供更多資安設備進行聯防。
而本篇主要針對的面向是尚未自建 Log Server / SIEM (通常是小型企業)，卻也想要做到收集惡意 IP 來整理自家的 RBL，剛好公司 Firewall 採用的是 FortiGate (當然版本最好是 7.2.4 以上)，來打造一個自己的 RBL 收集機制。
網路攻擊一直都是網管及資安人員關心的議題，但攻擊行為模式層出不窮，很難一次到位(也幾乎不太可能)，而 IP 防護是基本也是至少能做到的事情。
許多資安設備針對 IP 黑名單都有提供自家自動更新的功能，有些更會提供使用者設定自己搜集好的黑名單列表，定時更新。
FortiGate 在 6.0 版加入了 Security Fabric 架構，提供了 Threat Feeds 的功能，不過當時這個功能僅限在 Security Profile 裡面使用 (WebFilter)，直到 6.4 才真正可以運用在 Firewall Policy。
不過許多攻擊目標會鎖定 FortiGate 本身所提供的服務，例如 Management、SSL VPN …
FortiOS 從 6.0 開始提供一個名叫 Automation stitches 的功能，可以讓我們在 FortiGate 平台上做一些自動化的機制，而裡面包含了一個本篇要說明的 Webhook 功能。
我打算利用 Webhook 來跟 Github issue 進行 REST API 串接，依照 Github 上的說明在 FortiGate 上設置三個 header
結果怎麼測試都失敗
以往我過去的習慣都會將 2.4G / 5G 這兩個 band 使用同一個 SSID name，然後利用 controller 的功能來協助 devices 選擇最適合的 band 來傳輸。
不同的 device 也會有它自己所能 support 的 channel list，這也會發生明明我們已經設定好優先使用 5G，但實際上卻是走在 2.4G 的狀況。
Network Access Control(NAC)一直以來在Cyber Security領域中都有它的角色存在，各網通大廠也都相繼提出解決方案，當然Alcatel-Lucent Enterprise也不例外。