2026年5月14日 星期四

VMware VCenter 6.7設定Log Server失敗

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 啟動階段失敗

通常剩下幾種可能:

  1. PID file 問題
  2. socket 被占用
  3. 權限問題
  4. module 載入失敗
  5. log file 無法寫入
  6. disk 滿了
  7. SELinux/AppArmor
  8. 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. 給你的安全建議

如果你還是擔心,可以採取以下步驟:

  1. 官方下載: 務必只從 Nartac Software 官網 下載。

  2. 先備份註冊表: 在執行任何變更前,先匯出整個 SCHANNEL 註冊表路徑做備份。

  3. 先在測試環境執行: 如果你有測試機,先跑一次,確認 RDP 與應用程式服務一切正常。

  4. 檢查工具: 如果你在極度嚴苛的環境,可以用 Strings 工具查看它的內部文字,你會發現它真的只是在呼叫註冊表機碼。

總結: 對於要修復 Nessus 掃出的 SWEET32SSL 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分別建立 ClientServer 子機碼,並將其停用:

  1. 建立機碼:Protocols\SSL 3.0\Server

  2. 在右側建立 DWORD (32-bit) 值:


    • Enabled = 0

    • DisabledByDefault = 1

  3. 對以下種類重複上述動作。

  • 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,但有時並未預設開啟。請確保以下路徑已正確設定:

  1. 建立機碼:Protocols\TLS 1.2\Server

  2. 在右側建立 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

2026年4月22日 星期三

使用Commvault備份時,遇到VMware 磁碟整併鎖定問題排除

使用Commvault備份時,遇到VMware 磁碟整併鎖定問題排除:

我使用Commvault備份軟體,透過VMware Vcenter去備份ESX Server內的VM。

但備份時會產生快照,但備份已經跑完了,快照還在,VMware Vcenter提示訊息說虛擬機器磁碟需要整併。

但我執行整併,發現虛擬機器磁碟整併失敗,Vcenter提示訊息說 無法存取遭到鎖定的檔案。
===========

這種情況在備份環境中(特別是使用 Commvault 或 Veeam 等軟體)非常常見,通常是因為 HotAdd 傳輸模式 造成的。

當 Commvault 的 VSA (Virtual Server Agent) 透過 HotAdd 模式備份時,它會將受保護 VM 的磁碟「掛載」到 VSA Proxy 機器上。如果備份過程中斷或解除掛載失敗,磁碟鎖(Lock)就會殘留在 VSA 上,導致 vCenter 無法執行磁碟整併。

以下是處理此問題的標準 SOP:


第一步:找出「鎖定者」(檢查 Commvault VSA Proxy)

這是最常見的原因。請檢查負責該備份作業的 Commvault VSA (Proxy) 虛擬機

  1. 在 vCenter 中,找到該備份作業使用的 VSA 虛擬機

  2. 右鍵點擊 VSA 虛擬機 -> 編輯設定 (Edit Settings)

  3. 檢查硬體清單中,是否有多出來的硬碟(通常硬碟容量或名稱會與出問題的 VM 一致)。

  4. 解決方法: 如果發現不屬於 VSA 本身的硬碟,請點擊 「移除 (Remove)」

    • 注意: 務必選擇 「從虛擬機器移除 (Remove from virtual machine)」,千萬不要勾選「從資料存放區刪除檔案」。

  5. 移除後,回到出問題的 VM 再次執行「整併 (Consolidate)」。



2025年6月2日 星期一

如何查看主機跟NAS連線的指令?

windows的VM或主機可以下
net use 或是 Get-SmbConnection
看有沒有關於連線到NAS storage的資訊.
================================================
對於linux VM或主機可以下
netstat -an | grep 2049      # NFS
netstat -an | grep 445       # CIFS (SMB)


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

PS C:\>Get-SmbConnection ServerName ShareName UserName Credential Dialect NumOpens ---------- --------- -------- ---------- ------- -------- Contoso-FS1 VMS5 Contoso\Contoso-HV1$ Contoso\Contoso-HV1$ 3.00 1 Contoso-FS1 VMS5 NT VIRTUAL MACHI... Contoso\Contoso-HV1$ 3.00 3 Contoso-FS VMS1 Contoso\Contoso-HV1$ Contoso\Contoso-HV1$ 3.00 1 Contoso-FS VMS1 NT VIRTUAL MACHI... Contoso\Contoso-HV1$ 3.00 5 Contoso-SO VMS3 Contoso\Contoso-HV1$ Contoso\Contoso-HV1$ 3.00 1 Contoso-SO VMS3 NT VIRTUAL MACHI... Contoso\Contoso-HV1$ 3.00 1 Contoso-SO VMS3 NT VIRTUAL MACHI... Contoso\Contoso-HV1$ 3.00 2


資料來源:
https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbconnection?view=windowsserver2025-ps

==================
PS C:\>Get-SmbConnection -ServerName Contoso-FS | Select-Object -Property * ContinuouslyAvailable : True Credential : Contoso\Contoso-HV1$ Dialect : 3.00 Encrypted : False NumOpens : 1 ServerName : Contoso-FS ShareName : VMS1 UserName : Contoso\Contoso-HV1$ PSComputerName : CimClass : ROOT/Microsoft/Windows/SMB:MSFT_SmbConnection CimInstanceProperties : {ContinuouslyAvailable, Credential, Dialect, Encrypted...} CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties ContinuouslyAvailable : True Credential : Contoso\Contoso-HV1$ Dialect : 3.00 Encrypted : False NumOpens : 5 ServerName : Contoso-FS ShareName : VMS1 UserName : NT VIRTUAL MACHINE\F357A523-592B-4CA5-B61E-C06D5627E1C9 PSComputerName : CimClass : ROOT/Microsoft/Windows/SMB:MSFT_SmbConnection CimInstanceProperties : {ContinuouslyAvailable, Credential, Dialect, Encrypted...} CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties



2025年5月21日 星期三

VMware vSphere 內的VM固定解析度的問題。

在某些使用VMware vSphere的版本,內的VM,會因為使用者開啟Web視窗的大小,VM因此自動的變更解析度,這對於某些使用者,會感到困擾,甚至某些自動化的程式,也會受到影響,無法正常運作。

網路上查找的經驗,經過測試有效,列為紀錄分享。
以下做法,都需要經過開關機,使設定套用。

第一種方法:
一、修改 OS 內 C:\Program Files\VMware VMware Tools\VMwareResolutionSet.exe,
改名將VMwareResolutionSet.exe 變更為 VMwareResolutionSet.exe.bak,簡單說就是讓Vmware tools找不到這個程式,即可固定解析度,用意就是不要讓他自行變更解析度。

若想要復原這個功能,將檔名改回即可。
***但注意若更新vmware tools,有可能重新安裝VMware tools,需要重新設定。

第二種方法:
修改 vmx 設定。
至需變更主機所在datastore 內將 vmx 下載,並新增下列資訊
svga.maxWidth = "1024"     ##此為寬度
svga.maxHeight = "768"      ##此為高度
guestInfo.svga.wddm.modeset = "FALSE"     ##停止自動調整功能
變更完畢後將vmx 上傳回並覆蓋。
***提醒做任何變動,都建議要備份設定。凡是留一手。
Note: 第二種方式,測試時,我關機修改vmx,第一次開機,有發生一點異常現象。
開機後,windows登入時,輸入帳號資訊,輸入完成後登入進windows,VM畫面會呈現全黑的現象,但關機,再單純重開一次,它就可以正常開機並且顯示正常,暫且留意ˋ此狀況,不知道為什麼,是不是有什麼特例或是個案。

VMware VCenter 6.7設定Log Server失敗

VMware VCenter 6.7設定Log Server失敗 使用vCenter 6.7 設定步驟 開啟 VAMI 介面:開啟瀏覽器,輸入 https://<您的vCenter_IP>:5480。  登入:使用 root 帳號及其密碼登入。  進入 Syslog:...