RouetOS 7.25 set minimal supported WinBox version to 4.3

2026-10-23 釋出的 RouterOS 7.25 強制使用 WinBox 4.3 以上的版本
使用舊版 WinBox 3.43 會出現
ERROR: router requires newer winbox, please upgrade
RouterOS 7.24.5 變成是最後一個可以用 WinBox 3 連線的版本
WinBox 3 已經變成時代的眼淚，還是習慣用它，真捨不得

ref. 7.25 [stable] is released!

RouterOS Recursive Routing

Recursive Routing 「遞迴路由」

為什麼需要「遞迴路由」?
在設定雙 WAN 備援時，如果只在預設路由上設定 check-gateway=ping
並指向 ISP 的閘道器 (例如數據機 IP)，
路由器只會檢查「自己到數據機」這一段連線是否正常。
一旦發生「數據機沒壞，但 ISP 機房端光纖斷裂」的情況，
路由器仍會誤判主線路正常，導致斷線。
MikroTik 官方採用 Recursive Routing (遞迴路由) 解決這個盲點:

1. 指定外部監控目標: 挑選穩定且可以 Ping 主機 (例如 8.8.8.8 與 8.8.4.4)，
強制指定它們分別透過 ISP1 與 ISP2 的實體閘道器連線。

2. 將預設路由指向監控目標: 把預設路由 (0.0.0.0/0) 的 gateway 設為 8.8.8.8 而非 ISP 閘道器，
路由器會自動「遞迴查找」前往 8.8.8.8 的真實下一跳 (即 ISP1 閘道器)

3. 透過 scope 與 target-scope 控制查找範圍
scope: 代表該條路由本身的「距離層級」
target-scope: 代表這條路由允許去查找 scope 值小於或等於此數值的其他路由作為下一跳。
在 RouterOS v7 中，遞迴路由的 target-scope 必須嚴格大於或等於底層主機路由的 scope
(官方範例將底層監控路由設為 scope=10，預設路由設為 target-scope=11)

參數項目	主要線路（ISP1）	備援線路（ISP2）	說明
外網介面（Interface）	ether1	ether2	連接兩家 ISP 的實體或邏輯埠
ISP 閘道器（Gateway）	10.111.0.1	10.112.0.1	ISP 配發的上游閘道器 IP
路由優先權（Distance）	1（優先使用）	2（備援待命）	數值越小優先權越高
第一組監控主機（Google DNS）	8.8.8.8	8.8.4.4	用於基礎連通性偵測
第二組監控主機（OpenDNS）	208.67.222.222	208.67.220.220	用於雙主機防誤判（進階設定）

NAT rule
/ip/firewall/nat
add chain=srcnat action=masquerade out-interface=ether1
add chain=srcnat action=masquerade out-interface=ether2

指定外部監控目標
/ip/route/
add dst-address=8.8.8.8 scope=10 gateway=10.111.0.1
add dst-address=8.8.4.4 scope=10 gateway=10.112.0.1

將預設路由指向監控目標
/ip/route/
add distance=1 gateway=8.8.8.8 target-scope=11 check-gateway=ping
add distance=2 gateway=8.8.4.4 target-scope=11 check-gateway=ping

進階強化: 加入第二組監控主機防止單一目標誤判
/ip/route
add dst-address=208.67.222.222 gateway=10.111.0.1 scope=10
add dst-address=208.67.220.220 gateway=10.112.0.1 scope=10
add distance=1 gateway=208.67.222.222 target-scope=11 check-gateway=ping
add distance=2 gateway=208.67.220.220 target-scope=11 check-gateway=ping

注意事項:
監控目標要避開內網設備可能的連線目標
官方的設定範例，8.8.8.8 與 208.67.222.222 已經被靜態路由強制綁定在 ISP1，
當 ISP1 斷線，切換至 ISP2 時，內網設備將暫時無法連上 8.8.8.8 與 208.67.222.222
所以內網設備 DNS 就不能指定 8.8.8.8 及 208.67.222.222

ref. Failover (WAN Backup)

PHP CVE-2026-109618 CVE-2026-109619 workaround

PHP Critical RCE 漏洞緩解設定

PHP 官方於 2026 年 10 月 21 日發布重大安全公告，涉及以下兩個可導致遠端程式碼執行（RCE）的漏洞：

漏洞	主要問題	主要緩解方向
CVE-2026-109618	記憶體耗盡（OOM）期間，PHP 內部請求資料尚未完整初始化，後續清理流程可能使用不正確的記憶體狀態	行政強制設定 memory_limit=-1，限制請求大小與輸入複雜度
CVE-2026-109619	請求結束後仍殘留指向已釋放記憶體的全域狀態，後續由同一 worker 處理的請求可能觸發 use-after-free	停用 session upload progress、減少可觸發的錯誤路徑並清除危險的設定方式

相關版本的官方修補版本如下：

• PHP 8.5：8.5.12

• PHP 8.4：8.4.27

• PHP 8.3：8.3.36

• PHP 8.2：8.2.35

無法立即升級 PHP 至官方修補版本的既有系統，可以透過調整 php.ini 參數緩解，
注意，參數設定只是 workaround，並沒有解決原本的問題，只是增加攻擊路徑的難度

; 避免攻擊者利用可控的 PHP 記憶體上限，觸發已知的 OOM 攻擊路徑。
memory_limit = -1

; 停用此功能，可以阻斷已確認的 session upload progress 攻擊路徑
session.upload_progress.enabled = Off

; 降低輸入巢狀深度，這個預設值是 64，一般 4 或 8 即足夠
max_input_nesting_level = 4

; 限制 GET / POST / COOKIE 輸入變數數量，這個值預設是 1000
max_input_vars = 100

; 限制同一請求可接收的上傳檔案數
max_file_uploads = 1

; 不需要檔案上傳
file_uploads = Off

; 小檔上傳建議值
post_max_size = 8M
upload_max_filesize = 7M

; 大檔上傳建議值
post_max_size = 32M
upload_max_filesize = 28M


同時限制 Web Server 的請求大小，注意這邊單位是 Bytes，可以設定跟 post_max_size 相同

Apache：LimitRequestBody
Nginx：client_max_body_size


ref. RCE via OOM corruption

Android ACCESS_LOCAL_NETWORK permission

目標 SDK 版本 37 以上版本，app 若需要存取區域網網，需要求 ACCESS_LOCAL_NETWORK 權限
Google Play 中的 Termux 在 app 並沒有要求此權限，造成 ping、curl 內網都不會通
ping: sendmsg: Operation not permitted

替代方案是安裝 F-Droid 內的 Termux，最後一次更新是 2025年5月
Source Code 內的設定是
targetSdkVersion=28
compileSdkVersion=36