2026年7月20日星期一

Windows Server因為Windows update後，導致自動重啟或是自動重新開機

從 Windows Server 2016 開始，微軟確實改變了更新機制，使其行為更接近消費端的 Windows 10，這在伺服器管理上引發了不少討論。

以下為您確認微軟在 Windows Server 2016 上的具體行為：

1. 預設行為：自動下載與安裝

在 Windows Server 2016 中，系統預設會自動檢查、下載並安裝更新。與舊版（如 2012 R2 或 2008）不同，2016 的圖形介面（GUI）設定中，提供給管理員選擇「僅通知但不下載」的選項被大幅簡化或隱藏，導致系統看起來像是「強迫更新」。

2. 自動重啟的邏輯

微軟設計了「使用時段」(Active Hours) 的概念：

預設行為：系統會在偵測到非使用時段時，自動重新啟動以完成更新安裝。

強制性：如果更新被標記為重要安全更新，且系統多次嘗試在非使用時段重啟未果，它最終可能會忽略使用時段強制重啟。

無人值守：對於伺服器而言，如果沒有透過群組原則（GPO）特別設定，系統會認為只要不在使用時段內，重啟就是安全的。

如何在企業環境中重新取得控制權？

身為系統管理員，通常不希望伺服器「自行決定」何時重啟。您可以透過以下幾種專業方式來調整此行為：

======================

在 Windows Server 2016 中，若要「安裝更新但完全不重啟」，或是「完全由人工決定何時安裝與重啟」，可以透過以下幾種層次的操作來實現：

1. 最徹底的方法：將更新改為「手動模式」(透過 sconfig)

這是最簡單且最有效的方法，能防止系統在背景自行下載與安裝，進而避免後續引發的自動重啟。

在 PowerShell 或 CMD 輸入 sconfig。

輸入 5 (更新設定)。

輸入 M (手動/Manual)。

效果：系統不會自動檢查更新，也不會自動下載。你必須手動執行 Windows Update 檢查並點擊安裝，重啟的時間也完全由你控制。

如圖Windows Server 2022 Standard範例

2. 專業管理員的做法：透過群組原則 (GPO)

如果你希望系統「可以自動下載」，但「絕對不能自動重啟」，請修改以下原則：

路徑：電腦設定 > 系統管理範本 > Windows 元件 > Windows Update

設定 A：設定自動更新

設定為「3 - 自動下載並通知安裝」。

效果：系統下載完檔案後會停住，等待管理員點擊「安裝」。只要不點安裝，就不會進入重啟階段。

設定 B：對於已登入的使用者，不隨自動更新安裝而自動重新啟動

設定為「已啟用」。

效果：只要伺服器上有管理員帳號正在登入狀態（即使是 RDP 斷線後保留 session），系統就不會強制倒數重啟。

3. 進階密技：停用「更新協調器」排程 (Update Orchestrator)

有時候即便設定了 GPO，Windows Server 2016 還是會因為內建的「排程工作」強制重啟。這是最讓管理員頭痛的地方。

開啟「工作排程器」。

導航至：微軟 (Microsoft) > Windows > UpdateOrchestrator。

找到名為「Reboot」的項目。

將其改為「停用 (Disabled)」。

註：有時系統會自動恢復此項目的權限。若要徹底封鎖，需要進到檔案路徑 C:\Windows\System32\Tasks\Microsoft\Windows\UpdateOrchestrator 將 Reboot 檔案的寫入權限移除。

2026年6月4日星期四

使用NSSM將Nginx程式轉為Windows服務。(通用其他程式)

NSSM (Non-Sucking Service Manager) 的主要用途正如你所聽到的：它可以把任何傳統的執行檔（.exe）或腳本（.bat、.cmd、.vbs、PowerShell、Python 等）封裝並註冊成 Windows 服務（Windows Service）。

在預設情況下，Windows 無法直接將一般的程式當作服務來執行，因為標準的 Windows 服務必須遵循特定的 Service Control Manager (SCM) 通訊協定。如果直接用系統指令硬把普通 .exe 註冊成服務，啟動時通常會跳出「服務未回應控制要求」的錯誤。

NSSM 就是為了解決這個痛點而生的「代理人（Proxy）」。

為什麼要使用 NSSM？（核心功能）

1. 讓普通程式具備「服務」的特性

開機自動背後執行： 即使沒有使用者登入 Windows 系統，程式也會在背景自動啟動。
權限控管： 可以指定特定的系統帳戶（如 LocalSystem）或特定的網域/本地使用者帳戶來執行該程式。

2. 強大的崩潰自動重啟機制 (Auto-Restart)

這是 NSSM 最受工程師青睞的功能。如果你的程式因為 Bug、記憶體溢位或其他原因不正常關閉（Crash），NSSM 會自動監測到並立刻重啟該程式。它還內建了「重啟延遲」設定，防止程式陷入無限快速重啟的死迴圈。

3. 完美的 I/O 重新導向 (日誌記錄)

一般的控制台程式（Console Application）運行時會有輸出畫面（stdout 和 stderr）。變成服務後，這些畫面會消失。NSSM 可以幫你把這些原本會顯示在黑畫面的文字，即時寫入到指定的 .log 文字檔中，方便日後查修。

4. 優雅的關閉機制 (Graceful Shutdown)

當你停止服務時，NSSM 不會粗暴地直接殺掉（Kill）你的程式，而是會循序漸進地發送作業系統關閉訊號（如 WM_CLOSE、WM_QUIT），讓你的程式有時間處理未完的資料、關閉資料庫連線後才乾淨地結束。

常見的應用場景

在企業 IT 環境或開發流程中，NSSM 常被用來封裝以下類型的程式：

Web 服務/API 伺服器： 例如用 Python (Flask/FastAPI)、Node.js、Go 語言寫好的後端程式，需要 24 小時在 Windows 伺服器上穩定運行。
自動化腳本： 定時執行的批次檔（.bat）或 PowerShell 監控腳本。
開源工具： 許多從 Linux 移植過來、沒有原生 Windows 服務介面的開源工具（例如早期的 Prometheus Exporter、某些資料庫轉發工具）。

如何使用 NSSM？（極簡步驟）

NSSM 最棒的地方在於它同時提供了圖形介面 (GUI) 和命令列 (CLI)，操作非常直覺。

使用圖形介面安裝服務：

下載並解壓縮 NSSM。
打開命令提示字元 (CMD) 並切換到 nssm 所在目錄，輸入：
nssm install 你的服務名稱
此時會跳出一個 GUI 視窗：
- Path: 選擇你要執行的 .exe 或直譯器（如 python.exe）。
- Startup directory: 程式運行的工作目錄（通常會自動帶入）。
- Arguments: 程式需要的參數（例如 runserver 0.0.0.0:8000 或腳本路徑）。
- 在 I/O 頁籤可以設定 Log 輸出路徑。
點擊 Install service 就完成了！接下來就可以去 Windows 的 services.msc（服務管理面板）裡面看到它，並設定成自動啟動。

常用命令列指令：

如果你想透過指令快速管理，它也支援：

建立服務: nssm install 你的服務名稱
刪除服務： nssm remove 你的服務名稱
啟動服務： nssm start 你的服務名稱
停止服務： nssm stop 你的服務名稱
編輯現有服務： nssm edit 你的服務名稱（會再次跳出 GUI 視窗讓你修改設定）

總結來說，NSSM 是一個非常輕量、穩定且完全免費的工具，是 Windows 系統管理員與開發者在處理背景程序時的必備神器。

======================================================

如果你在命令提示字元（CMD）中輸入了：

 nssm install nginx 
or
 nssm edit nginx

這時候系統會跳出 NSSM 的圖形化設定視窗（NSSM Service Installer），讓你填寫詳細的執行路徑與參數。

因為 Nginx 官方的 Windows 版本本身就只是一個普通的控制台程式（Console Application），沒有內建 Windows 服務的控制代碼，所以用 NSSM 來封裝它是非常標準且常見的做法。

請按照以下步驟在跳出的視窗中進行設定：

1. 欄位設定指引

在跳出的 Application 頁籤中，請填入以下資訊：

Path (目的程式路徑)： 點擊右側的 ... 按鈕，找到你解壓縮 Nginx 的目錄，選取 nginx.exe。
範例：C:\nginx\nginx.exe
Startup directory (啟動工作目錄)： 當你選好 Path 之後，這個欄位通常會自動帶入。請確保它是 nginx.exe 所在的資料夾。
範例：C:\nginx ⚠️ 注意： 這個欄位非常重要，因為 Nginx 啟動時需要去相對路徑讀取 conf/nginx.conf 檔案，如果工作目錄弄錯，服務會啟動失敗。
Arguments (啟動參數)： 這裡留空即可（通常不需要填寫，預設就會直接啟動）。

2. 建議進階設定：日誌重新導向 (I/O)

雖然 Nginx 本身就會寫入 logs/error.log，但如果 Nginx 因為主設定檔（nginx.conf）寫錯而導致「根本連開都開不起來」時，Nginx 自己的 Log 是不會有紀錄的。

建議切換到 I/O 頁籤：

Output (stdout): 設為 C:\nginx\logs\nssm_stdout.log
Error (stderr): 設為 C:\nginx\logs\nssm_stderr.log

這樣一來，如果服務啟動失敗，你可以直接來這兩個檔案看 Windows 拋出的最底層錯誤訊息。

3. 完成與啟動服務

欄位填妥後，點擊視窗下方的 Install service 按鈕。
看到彈出 Service "nginx" installed successfully! 的成功訊息後，代表服務已經註冊成功。
啟動 Nginx： 此時服務雖然註冊了，但預設還沒開始執行。請在 CMD 輸入以下指令來啟動它：
nssm start nginx
（或者你可以按 Win + R 輸入 services.msc 打開 Windows 服務管理員，找到 nginx 點選「啟動」，並確認啟動類型為「自動」）。

💡 日後如何維護？

變成 Windows 服務後，當你修改了 nginx.conf 設定檔，請不要直接去點 nginx.exe，也不要用 nginx -s reload（因為那會脫離 NSSM 的控制），請統一使用 NSSM 的指令：

重新啟動服務（應用新設定）： nssm restart nginx
停止服務： nssm stop nginx
修改 NSSM 設定： 如果路徑填錯了，輸入 nssm edit nginx 可以重新打開圖形視窗修改。
移除服務： 如果以後不想用了，輸入 nssm remove nginx 即可乾淨刪除。

https://drive.google.com/file/d/1NOaoX1tJyoeHKnQbI8vD3CbsgT7Jsoh-/view?usp=drive_link

https://drive.proton.me/urls/MV7M5ARMRG#GN6n4oWZavDG

2026年6月3日星期三

Nginx漏洞修補與升級方式說明(Windows)

面對這個剛爆發不久的 CVE-2026-42945 (NGINX Rift) 高風險漏洞，果斷選擇升級是非常正確的決定。這個漏洞存在於 Nginx 的重寫模組（ngx_http_rewrite_module）中，會導致堆疊緩衝區溢位（Heap Buffer Overflow），可能引發遠端程式碼執行（RCE）或阻斷服務攻擊（DoS）。

針對 Windows 環境下將 Nginx 1.19.6 升級的完整步驟與注意事項，為您整理如下：

步驟一：確認目標版本

官方已針對此漏洞釋出修補版本。既然您目前使用的是開源版本，建議升級至以下版本或更新的版本：

穩定版 (Stable)： 1.30.1 或以上

主力版 (Mainline)： 1.31.0 或以上

請至 Nginx 官方下載頁面 (nginx.org) 下載對應 Windows 的 .zip 壓縮包。

步驟二：備份現有環境（核心步驟）

在進行任何升級前，請務必先備份目前的設定與檔案，以防萬一需要復原。

請拷貝現有 Nginx 目錄（例如 C:\nginx-1.19.6\）中的以下內容：

conf/ 目錄：包含主要的 nginx.conf 及其他設定檔。

html/ 或 www/ 目率：您的網頁網頁靜態檔案（若有放在這裡）。

SSL 憑證：若有存放憑證在 Nginx 目錄下，請務必備份。

步驟三：執行升級流程 (無縫替換)

Windows 版的 Nginx 不需要安裝，它是以綠色免安裝（攜帶版）的方式執行。請依照以下步驟手動替換：

1. 停止目前的 Nginx 服務

打開命令提示字元 (CMD) 並切換到您目前的 Nginx 目錄，執行以下指令安全停止服務：

    $ nginx.exe -s quit && sudo apt-get upgrade

(如果 Nginx 完全沒有回應，可以使用 taskkill /f /im nginx.exe 強制結束行程)。若您有將 Nginx 註冊為 Windows 服務（如使用 WinSW 或 NSSM），請至 Windows「服務」視窗中將其停止。

2. 解壓新版本

將下載好的新版本（例如 nginx-1.30.1.zip）解壓縮到新的目錄（例如 C:\nginx-1.30.1\）。

3. 遷移設定檔

將步驟二備份的 conf/ 目錄內的所有設定檔（特別是 nginx.conf），複製並覆蓋到新版 C:\nginx-1.30.1\conf\ 目錄中。

4. 測試新版本設定檔是否相容

從 1.19.6 跨越到 1.30.x 版本跨度較大，某些語法可能有所變更。在啟動前，請在 CMD 切換到新目錄並執行測試：

cd C:\nginx-1.30.1
nginx.exe -t

若顯示 syntax is ok 和 test is successful：代表設定檔相容，可以正常使用。
若報錯：請根據錯誤訊息調整 nginx.conf 中不再支援的舊語法。

5. 啟動新版 Nginx

測試成功後，直接啟動新版 Nginx：

start nginx

（若原本有使用 Windows 服務工具如 WinSW，請記得將工具內的執行路徑更新為新版的 C:\nginx-1.30.1\nginx.exe，然後啟動該服務）

但是

Windows 綠色版唯一的「小缺點」與維運解法

雖然它是免安裝的，但這也意味著：當 Windows 伺服器重開機時，Nginx 預設是不會自己啟動的。在企業的 Windows Server 生產環境中，系統管理員通常不會手動去雙擊 nginx.exe，而是會使用第三方工具（最常見的是 WinSW 或 NSSM），將這個綠色版的 nginx.exe 包裝註冊成「Windows 系統服務」。

這時候就要提到NSSM的應用。

透過使用NSSM將程式轉為Windows服務。

2026年5月14日星期四

VMware VCenter 6.7設定Log Server失敗

使用vCenter 6.7 設定步驟開啟 VAMI 介面：開啟瀏覽器，輸入 https://<您的vCenter_IP>:5480。

登入：使用 root 帳號及其密碼登入。

進入 Syslog：點選左側選單最下方的「Syslog」索引標籤。

設定轉送：在「轉送組態」(Forwarding Configuration) 區塊，點擊「設定」(Configure)。填寫伺服器資訊：伺服器位址：輸入您的 Log Server IP 或 FQDN。

通訊協定：6.7 版本同樣支援 UDP、TCP、TLS、RELP 協定。

連接埠：預設為 514 (UDP/TCP)

錯誤訊息:

Error in method invocation _failure() missing 1 required positional argument: 'err'

不是你 Log Server IP 填錯，也不是 514 port 問題。

這是 VMware vCenter Server VAMI (:5480) 裡面很有名的爛 Python UI 例外錯誤。人類很愛把「後端報錯」直接丟給管理員，彷彿你應該通靈知道 _failure() 少了什麼參數。

通常代表：

VAMI 前端送出設定失敗

後端 service 沒正常回應

syslog config validation 爆掉

某些 protocol 在 6.7 有 bug

certificate / hostname 驗證問題

appliance service 異常

而不是單純「不能設定」。

你現在應該改查：

SSH登入VMware Vcenter

shell 進入設定。

1. 查看 rsyslog 狀態


systemctl status rsyslog

如果沒跑：


systemctl restart rsyslog

直接看目前 syslog 設定：

cat /etc/vmware-syslog/syslog.conf

加入log server設定

假如Log Server IP: 1.2.3.4

*.* @1.2.3.4:514

再測：

rsyslogd -N1

如果顯示：

End of config validation run. Bye.

代表 config 正常。

代表：

rsyslog 設定檔語法是正常的

所以問題不是：

config syntax
forwarding rule
URI 格式

而是：

rsyslog 啟動階段失敗

通常剩下幾種可能：

PID file 問題
socket 被占用
權限問題
module 載入失敗
log file 無法寫入
disk 滿了
SELinux/AppArmor
systemd limit/cache 問題

現在要直接看 rsyslog 真正 stderr。

請執行


rsyslogd -dn

注意：

-d = debug
-n = foreground

它會直接噴真正錯誤。

root@photon-machine [ / ]# rsyslogd -dn rsyslogd: error reading pid file, cannot start up rsyslogd: run failed with error -3000 (see rsyslog.h or try https://www.rsyslog.com/e/3000 to learn what that number means)

你的問題是：


error reading pid file, cannot start up

代表：

rsyslog 的 PID file 壞掉或卡住了

通常是：

上次 crash
abnormal shutdown
service 沒正常結束
PID file 殘留
權限錯誤

導致 rsyslog 認為：

「已經有另一個 rsyslog 在跑」。

立刻處理

先找 PID file：


find /run /var/run -name "*rsyslog*.pid"

通常會看到：


/var/run/rsyslogd.pid

確認目前沒有 rsyslog process


ps -ef | grep rsyslog

正常情況應該只剩 grep 自己。

如果沒有真正 rsyslogd process：

改名或刪除 PID file(建議改名)

例如：
mv /var/run/rsyslogd.pid /var/run/rsyslogd.pid.bak


rm -f /var/run/rsyslogd.pid

reset systemd failed state


systemctl reset-failed rsyslog



再啟動
systemctl start rsyslog

查看：
systemctl status rsyslog

查看服務，終於正常 active (running)


回到
VMware vCenter Server VAMI (:5480)
 進入 Syslog：點選左側選單最下方的 「Syslog」 索引標籤。
 設定轉送：在「轉送組態」(Forwarding Configuration) 區塊，點擊 「設定」(Configure)。
總算是沒有下面的錯誤訊息了，檢查Log Server，也確認有收到Log。
設定成功。

錯誤訊息:
Error in method invocation _failure() missing 1 required positional argument: 'err'

因為Nessus 弱點掃描，而將Windows關閉停用 SSL 2.0 , SSL 3.0 和 TLS 1.0, 1.1，並強制使用 TLS 1.2處理(用 IIS Crypto 工具處理法)

方法：IIS Crypto（比較符合人類文明）

工具：

IIS Crypto

操作

建議直接：

勾：
- TLS 1.2
取消：
- SSL 2.0
- SSL 3.0
- TLS 1.0
- TLS 1.1（建議）
- 3DES

然後：

Apply
Reboot

考慮安全性說明:

IIS Crypto 是安全且在業界被廣泛信賴的工具。

在系統管理與資安稽核的領域中，它幾乎是處理 Windows Server SSL/TLS 設定的「標準配備」。雖然它是第三方軟體，但其運作機制非常透明且單純。

以下從幾個維度幫你分析它的安全性與可靠性：

1. 運作機制：它只是個「註冊表包裝器」

IIS Crypto 本身並不包含任何加密演算法，也不會安裝任何系統服務或後端程式。

本質： 它只是一個圖形化界面（GUI），幫你修改我們之前討論過的那些 Schannel 註冊表路徑（HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\...）。
不常駐： 設定完、按下 Apply 並重啟後，你可以直接刪除這個 .exe 檔案，它不會留在系統中執行。

2. 為什麼專業人士愛用它？

避免人為錯誤： 就像你之前糾結要寫 168 還是 168/168，手動改 Registry 很容易打錯字。IIS Crypto 內建的名稱都是經過微軟官方規範驗證過的。
Best Practices 模板： 它的「Best Practices」按鈕是根據當時主流的安全標準（如 PCI DSS、TLS 指引）定義的，能快速關閉已知的弱點（如 SSL 3.0, RC4, 3DES）。
數位簽章： 該軟體由 Nartac Software 提供，官方下載的版本通常帶有正確的數位簽章，確保程式碼未被篡改。

3. 使用它有哪些「風險」？

工具本身是安全的，但「設定的內容」可能會帶來副作用。這並非工具的錯，而是加密政策改變後的必然結果：

遠端桌面 (RDP) 斷線風險： 如果你是在遠端操作，且不小心關閉了所有與客戶端相容的加密套件（例如只開 TLS 1.2，但你的連線端電腦太舊），重啟後你可能會連不進伺服器。
應用程式相容性： 某些舊版的資料庫連接程式（如舊版 SQL Client）或舊型設備（如舊型影印機的 Scan to Folder）可能只支援 TLS 1.0 或 3DES。一旦你用 IIS Crypto 停用它們，這些連線就會中斷。

4. 給你的安全建議

如果你還是擔心，可以採取以下步驟：

官方下載： 務必只從 Nartac Software 官網下載。
先備份註冊表： 在執行任何變更前，先匯出整個 SCHANNEL 註冊表路徑做備份。
先在測試環境執行： 如果你有測試機，先跑一次，確認 RDP 與應用程式服務一切正常。
檢查工具： 如果你在極度嚴苛的環境，可以用 Strings 工具查看它的內部文字，你會發現它真的只是在呼叫註冊表機碼。

總結： 對於要修復 Nessus 掃出的 SWEET32 與 SSL v2/v3 弱點，IIS Crypto 是最安全且最有效率的選擇，比手動一個一個改 Registry 要可靠得多。

2026年4月29日星期三

因為Nessus 弱點掃描，而將Windows關閉停用 SSL 2.0 , SSL 3.0 和 TLS 1.0, 1.1，並強制使用 TLS 1.2處理(regedit處理法)

Windows關閉停用 SSL 2.0 , SSL 3.0 和 TLS 1.0, 1.1，並強制使用 TLS 1.2

有一台windows server 2012 R2 主機，被弱點掃描軟體Nessus，掃出

SSL Version 2 and 3 Protocol Detection "The remote service encrypts traffic using a protocol with known weaknesses." "The remote service accepts connections encrypted using SSL 2.0 and/or

SSL 3.0. These versions of SSL are affected by several cryptographic flaws, including:

- An insecure padding scheme with CBC ciphers.

- Insecure session renegotiation and resumption schemes.

An attacker can exploit these flaws to conduct man-in-the-middle attacks or to decrypt communications between the affected service and clients.

Although SSL/TLS has a secure means for choosing the highest supported version of the protocol (so that these versions will be used only if the client or server support nothing better), many web browsers

implement this in an unsafe way that allows an attacker to downgrade a connection (such as in POODLE). Therefore, it is recommended that these protocols be disabled entirely.

NIST has determined that SSL 3.0 is no longer acceptable for secure communications. As of the date of enforcement found in PCI DSS v3.1, any version of SSL will not meet the PCI SSC's definition of 'strong

cryptography'." "Consult the application's documentation to disable SSL 2.0 and 3.0.

Use TLS 1.2 (with approved cipher suites) or higher instead.

處理方式:

應該關閉 SSL 2.0 與 SSL 3.0，並強制使用 TLS 1.2。

通常弱掃做到這點了，都會順便關掉TLS 1.0和TLS 1.1，避免多花一次工。

這項弱點（主要是為了防範 POODLE 攻擊）在現代安全標準中是非常基礎且必要的修復。SSL 2.0/3.0 早已被證明存在嚴重的加密缺陷，攻擊者可以利用這些漏洞進行中間人攻擊 (MITM) 並解密通訊內容。

由於 Windows Server 2012 R2 的預設設定較舊，通常需要手動調整註冊表或使用工具來符合目前的 Nessus 掃描要求。

1. 修復步驟：停用舊協定並啟用 TLS 1.2

在 Windows Server 2012 R2 中，所有的協定控制都在以下註冊表路徑： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

A. 停用 SSL 2.0 , SSL 3.0 和 TLS 1.0, 1.1。

你需要針對 SSL 2.0 , SSL 3.0 和 TLS 1.0, 1.1分別建立 Client 與 Server 子機碼，並將其停用：

建立機碼：Protocols\SSL 3.0\Server
在右側建立 DWORD (32-bit) 值：
- Enabled = 0
- DisabledByDefault = 1
對以下種類重複上述動作。

SSL 3.0 client 和 Server
SSL 2.0 client 和 Server
TLS 1.0 client 和 Server
TLS 1.1 client 和 Server

B. 啟用 TLS 1.2

雖然 2012 R2 支援 TLS 1.2，但有時並未預設開啟。請確保以下路徑已正確設定：

建立機碼：Protocols\TLS 1.2\Server
在右側建立 DWORD (32-bit) 值：

Enabled = 1
DisabledByDefault = 0

下圖範例參考為Windows Server 2022:
(Windows Server 2012 不支援TLS 1.3)

重要補充1：.NET Framework 的相容性 (隱藏陷阱)

在 Windows Server 2012 R2 上，即便你關閉了系統層級的 SSL 3.0，有些執行在 .NET Framework (3.5 或 4.x) 上的應用程式可能還是會嘗試使用舊協定。為了確保 .NET 應用程式也使用 TLS 1.2，建議增加以下註冊表項：

路徑 1: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
路徑 2: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319
新增項目:

SchUseStrongCrypto = 1 (DWORD)
SystemDefaultTlsVersions = 1 (DWORD)

重要補充2：就算是關掉了以下3DES,DES,SSL 2.0,SSL 3.0,TLS 1.0,TLS 1.1的windows 安全通道。僅留下TLS 1.2可通。但弱掃，還是有找出這些弱點的結果。

原因是這些主機的AP用的不是走windows的安全通道。因為早期發展SSL/TLS不是很成熟，各廠商通常自幹或幾乎各玩各的。早期 Schannel 的問題很多，Windows 很晚才成熟。

更重要的是：企業開始受不了「每套軟體自己管 TLS」。

時代	狀況
2003 / 2008	幾乎各玩各的
2012 / 2012 R2	過渡期
2016	開始大量整合 Schannel
2019 / 2022	已經很普遍

資安稽核也開始逼廠商

尤其：

PCI-DSS

HIPAA

ISO 27001

金融監管

開始要求：

TLS policy centralized

OS-level hardening

統一 Cipher Policy

於是：

廠商開始發現：

「跟著 OS TLS Policy 走，比較不會被客戶罵。」

這是人類文明少數因為懶惰而進步的例子。

重要補充3：若因為弱掃還是被找出弱點?

可以查看弱掃結果看port number是多少，是什麼程式在用的。

舉例 port 6701 , 9999

PowerShell

netstat -ano | findstr :9999

你會看到：


TCP    0.0.0.0:9999    LISTENING    1234

最後那個 PID：
tasklist /FI "PID eq 1234"

找出到底是哪個程式在運作。

參考下圖:

Windows停用 3DES 與 DES 相關套件

Windows停用 3DES 與 DES 相關套件

有一台windows server 2022主機，被弱點掃描軟體Nessus，掃出SSL Medium Strength Cipher Suites Supported (SWEET32)，Reconfigure the affected application if possible to avoid use of medium strength ciphers.

SWEET32 (CVE-2016-2183) 弱點主要是針對 64 位元區塊加密演算法 (64-bit block ciphers) 的攻擊，而 3DES 與 DES 正是這類受影響的加密套件。

在 Windows Server 2022 中，要徹底修復這項弱點，核心動作就是停用 3DES 加密。

處理方式:

1. 核心修復動作：修改 Registry 註冊表

這是最直接且標準的做法，透過修改 Schannel（Windows 的安全通道）設定來停用 3DES。

開啟 Registry Editor (regedit)。

導覽至以下路徑：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers

在 Ciphers 下方建立一個名為 Triple DES 168的子機碼（如果不存在）。

在 Triple DES 168 下，建立兩個 DWORD (32-bit) 值：

Enabled：數值資料設為 0

DisabledByDefault：數值資料設為 1

針對 DES（如果存在），也在 Ciphers 下建立名為 DES 56/56 的子機碼，並重複上述步驟。

提醒： 修改完成後，務必重新啟動伺服器，這項變更才會真正被載入系統記憶體中。

這樣處理後，Nessus 的 Medium Strength Cipher (SWEET32) 警示就會消失。

注意: Gemini 提供錯誤的答案，regedit在 Ciphers 下方建立一個名為 Triple DES 168/168 的子機碼，多了/168。要注意喔，應該是 Triple DES 168

訂閱：文章 (Atom)

2026年7月20日 星期一