如何停用 IIS5 / IIS6 / IIS7 的 SSL v2 加密協定 (含原理說明)

在多年以前 SSL 第二版 (v2) 就已經被證實有編碼加密方面的瑕疵，因此駭客很輕易的就能對 SSL v2 加密過的封包進行反解，或可能會透過中間人攻擊(Man-in-the-middle attack)手法加害於你的網站用戶，因此大多數的資安掃瞄軟體皆會建議在伺服器上關閉 SSL v2 的協定，以確保用戶端透過 SSL ( HTTPS ) 連上網站伺服器時是安全的連線。

我原本以為從伺服器上關閉 SSL v2 可能會導致部分舊版的瀏覽器無法登入網站，但理解 SSL 協定的握手過程 (Handshake) 後，就知道不會導致客戶無法連線的問題，甚至想不到不停用 SSL v2 的理由。

SSL/TLS 大致的運作過程如下：

  • 瀏覽器對特定網站發出 https 連線請求，雙方根據 SSL 所規範的 handshake 機制
  • 瀏覽器會先送出一個 "ClientHello" 訊息給網站伺服器，裡面包含了瀏覽器所支援的 Protocol 資訊
    • 例如: TLS v1.2 , v1.1, v1.0, SSL v2, SSL v3 等等。
    • 備註: Internet Explorer 瀏覽器從 IE7 開始就預設關閉了 SSL v2 協定，其他像 Firefox, Google Chrome 等叫的出來的瀏覽器也都預設關閉 SSL v2 協定。
  • 當網站伺服器收到此 "ClientHello" 訊息後，會回應 "ServerHello" 訊息給瀏覽器，其內容會從瀏覽器發出的 "ClientHello" 中所有 Protocol 中最安全的版本且伺服器也支援的 Protocol 予以回應。
    • 由於是從最高安全等級做出比對，一般狀況下通常都會利用 TLS v1.0 或是 SSL v3 來取得雙方的認可，進而約定於之後的連線過程所使用的 Protocol 版本。

由上述運作過程可知，若網站伺服器關閉 SSL v2 協定，並不代表瀏覽器就會無法使用 SSL 協定，因為通常還有其他版本可供挑選。

若以舊版的瀏覽器 IE6 來說，IE6 本身就同時支援 SSL v2 與 SSL v3 協定，在與網站伺服器 handshake 時通常會自動選擇 SSL v3 協定進行後續的連線，但如果用戶端被惡意植入木馬或被駭客修改了機碼設定，導致用戶端被強迫使用 SSL v2 進行安全連線，便會導致使用者遭受中間人攻擊或機密資訊被擷取等風險，所以無論如何 SSL v2 這種不安全的加密協定還是建議從伺服器端停用比較好，寧願讓使用者連不上網，也不願意看到使用者因為你的網站而受害！

如果你的網站使用者或客戶因為你將網站伺服器的 SSL v2 給關閉而導致連不上網站的情況，那你也可以強烈的懷疑客戶的主機是否已經被駭客入侵或被植入木馬了。再換句話說，如果你不管用戶端安不安全的話，那又何必花錢採購 SSL 憑證保護使用者的網路安全呢？

 

關閉 SSL v2 的方式

若要取消網站伺服器 (IIS5 ~ IIS7) 對 SSL v2 的支援，必須修改系統機碼才行，步驟如下：
（註：此方法適用 x86 與 x64 架構，也適用於 Windows Server 2003 ~ Windows Server 2008 R2）

1. 建立一個 Disable_IIS7_SSLv2.reg 登錄檔，檔案內容如下：

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
"Enabled"=dword:00000000

2. 透過滑鼠右鍵進行合併機碼的動作

   

3. 合併完成後需將伺服器重新開機，重新開機後自然就會生效。

 

驗證 SSL v2 已關閉的方法

若要驗證伺服器是否設定正確，最簡單的方法就是利用網站伺服器 SSL 支援版本檢測工具，只要輸入你的網站網址，再按下 [SSL-check] 按鈕即可進行檢測，如下圖示：

 

如果你的檢測結果是如下圖這樣，在 Available SSL2 ciphers 沒有任何資料，那就代表你已經完成關閉 SSL v2 的設定。

 

如果你的 IIS 網站沒有做出任何修改，預設還是會支援 SSL v2 的協定，檢測出來的結果如下圖示：

最後，所以還是建議各位網站管理員將網站伺服器上預設支援的 SSL v2 協定關閉，確保用戶的安全性。

相關連結

  

此文章由 will 發表於 2010/3/10 上午 10:56:11

永久連結 | 評論 (0) | 此文章的RSSRSS comment feed |

分類: IIS | Security

標籤: , , , ,

收藏:

在多台伺服器之間複製 "效能監視器" 所載入的 "效能計數器"

有時後我們只是臨時想看伺服器當下的負載情況，所以可能會開啟效能監視器之後直接手動加入想看的效能計數器 (Performance Counter)，但是一個一個的加入效能計數器頗為不便，尤其是一次要設定多台主機時更是麻煩，今天我來分享一個快速設定的方式，還可以將常用的效能計數器儲存下來，讓下次載入時更省時間。

一般來說，不熟悉效能監視器操作的人可能只會這樣一個一個新增效能計數器：

但事實上你可以在第一次全部載入完成後，按下「複製內容」的按鈕，將目前的設定以及載入的效能計數器設定複製到「剪貼簿」

然後可以開啟記事本，並將複製的設定內容 ( XML 格式 ) 貼上，並儲存成一份 XML 文件留做下次使用：

由於這份效能計數器設定的 XML 定義資料還儲存在剪貼簿上，你可以切換到另一台遠端桌面連線，並開啟效能監視器，並直接按下貼上計數器清單按鈕 (或按 Ctrl + V 快速鍵) 就可以將設定檔一次匯入。

我有試過從 Windows Server 2008 R2 複製計數器清單至 Windows Server 2003 的效能監視器中，大部分計數器都可以新增上去，如果發生錯誤你只要再加入適當的計數器即可。

透過這個技巧，就可以快速的設定或匯入效能計數器，下次要使用只要複製 XML 的資料，並在效能監視器中按下 Ctrl + V 貼上即可將所需的效能計數器載入完成。

  

此文章由 will 發表於 2010/3/9 上午 11:17:31

永久連結 | 評論 (0) | 此文章的RSSRSS comment feed |

分類: Tips | 系統管理

標籤: , , , , ,

收藏:

使用 Regular Expression 驗證密碼：使用 JavaScript 的陷阱

我在前年有寫過一篇【 使用 Regular Expression 驗證密碼 】文章，當時撰寫的技巧完全是針對 .NET 提供的 Regular Expression 而寫，雖然我的文章在標籤的地方有特別提到 .NET，但還是有人將文章裡提供的 Regular Expression 直接抄去給 JavaScript 使用，結果當然是養出一堆莫名其妙的臭蟲(Bug)。

我在當時的文章中採用的 .NET Regular Expression 的右合樣（英文稱為 Lookahead 或稱為 Positive Lookahead ），該功能其實在所有瀏覽器都有支援，但是邪惡的 IE5 , IE6 , IE7 卻實做出錯誤的樣式比對規則。至於 Regular Expression 的左合樣 (Negative Lookbehind) 則是在任何瀏覽器的 JavaScript 都不支援。

我當時文章的範例語法如下：

^(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{6,30}$

而我自己設計了一個 JavaScript 單元測試案例，共有 44 個 Test Case 去測試一個較簡單的樣式，終於研究出 IE7 以下版本對於右合樣的處理行為！

如下樣式，用來比對測試的字串是否符合：至少一個小寫字母、一個數字，且最少 5 個字元以上！

^(?=.*[a-z])(?=.*\d).{5,}$

首先，這個樣式在 IE 8 , Firefox 3.6 , Google Chrome 皆可正確比對，我另外利用 IETester 測試了 IE5 , IE6 , IE7 等不同瀏覽器版本，得到的結果不太一樣，其測試結果如下：

IE8 ,Firefox 3, Chrome 3/4 IE5, IE5.5, IE6, IE7
1. Testing 12345 Failed
2. Testing abcde Failed

3. Testing a1 Failed
4. Testing a12 Failed
5. Testing a123 Failed
6. Testing a1234 OK
7. Testing a12345 OK
8. Testing a123456 OK

9. Testing ab1 Failed
10. Testing ab12 Failed
11. Testing ab123 OK
12. Testing ab1234 OK
13. Testing ab12345 OK
14. Testing ab123456 OK

15. Testing abc1 Failed
16. Testing abc12 OK
17. Testing abc123 OK
18. Testing abc1234 OK
19. Testing abc12345 OK
20. Testing abc123456 OK

21. Testing 1a Failed
22. Testing 1ab Failed
23. Testing 1abc Failed
24. Testing 1abcd OK
25. Testing 1abcde OK
26. Testing 1abcdef OK

27. Testing 12a Failed
28. Testing 12ab Failed
29. Testing 12abc OK
30. Testing 12abcd OK
31. Testing 12abcde OK
32. Testing 12abcdef OK

33. Testing 123a Failed
34. Testing 123ab OK
35. Testing 123abc OK
36. Testing 123abcd OK
37. Testing 123abcde OK
38. Testing 123abcdef OK

39. Testing 123a Failed
40. Testing 123a1 OK
41. Testing 123a1b OK
42. Testing 123a1b2 OK
43. Testing 123a1b2c OK
44. Testing 123a1b2c3 OK
1. Testing 12345 Failed
2. Testing abcde Failed

3. Testing a1 Failed
4. Testing a12 Failed
5. Testing a123 Failed
6. Testing a1234 Failed
7. Testing a12345 OK
8. Testing a123456 OK

9. Testing ab1 Failed
10. Testing ab12 Failed
11. Testing ab123 Failed
12. Testing ab1234 Failed
13. Testing ab12345 OK
14. Testing ab123456 OK

15. Testing abc1 Failed
16. Testing abc12 Failed
17. Testing abc123 Failed
18. Testing abc1234 Failed
19. Testing abc12345 OK
20. Testing abc123456 OK

21. Testing 1a Failed
22. Testing 1ab Failed
23. Testing 1abc Failed
24. Testing 1abcd Failed
25. Testing 1abcde OK
26. Testing 1abcdef OK

27. Testing 12a Failed
28. Testing 12ab Failed
29. Testing 12abc Failed
30. Testing 12abcd Failed
31. Testing 12abcde OK
32. Testing 12abcdef OK

33. Testing 123a Failed
34. Testing 123ab Failed
35. Testing 123abc Failed
36. Testing 123abcd Failed
37. Testing 123abcde OK
38. Testing 123abcdef OK

39. Testing 123a Failed
40. Testing 123a1 Failed
41. Testing 123a1b Failed
42. Testing 123a1b2 Failed
43. Testing 123a1b2c OK
44. Testing 123a1b2c3 OK


因為右、左合樣的寬度永遠為零，所以照理說處理上述樣式時 (?=.*[a-z]) 或 (?=.*\d) 樣式不應該佔用任何比對的空間，但是在 IE5, IE6, IE7 卻會佔用，因而導致樣式處理發生邏輯不正確的情況！

拿上述測試案例的 abc1234 來說，它先比對 (?=.*[a-z]) 樣式，發現沒比對到，便跳至 (?=.*\d) 樣式比對，這個樣式比對後便把 .* (即 abc 部分) 的比對給吃掉了，也就是之後的 .{5,} 樣式不會再比對 abc 這三個字元，所以光是比對 1234  就會因為不足 5 個字元而發生樣式比對失敗！

拿上述測試案例的 abc12345 來說，它先比對 (?=.*[a-z]) 樣式，發現沒比對到，便跳至 (?=.*\d) 樣式比對，這個樣式比對後便把 .* (即 abc 部分) 的比對給吃掉了，也就是之後的 .{5,} 樣式不會再比對 abc 這三個字元，接著再比對 12345  就會因為符合至少 5 個字元的樣式要求而比對成功！

另外，我也利用 Browsershots 網站幫我額外測試另外 46 個在 Windows 平台上不同種類、版本的瀏覽器，以及 56 個跨平台各主要瀏覽器，我不得不說在大多數唸的出名字的瀏覽器中只有 IE 有這種邏輯錯誤的狀況 ( 當然我們還是要給 IE8 鼓鼓掌 )。

所以若有人要在 JavaScript 中實做 Regular Expression 必須特別特別小心，否則寫出了 Bug 還不自知，孰知這個 Bug 不是開發人員的錯，但客戶總是怪我們對吧！遇到這種瀏覽器的 Bug 真是如同天色暗了、天空陰了、空氣涼了這樣的感覺。

各位有興趣也可以自行測試看看，以下是測試網頁：

再次聲明：Regular Expression 是學一次用一輩子的技能，我認為是任何程式設計師必學的技能之一。

相關連結

  

此文章由 will 發表於 2010/3/8 上午 02:17:01

永久連結 | 評論 (0) | 此文章的RSSRSS comment feed |

分類: JavaScript | Web

標籤: , ,

收藏:

解決 Memcached Provider 不支援中文 Cache Key 的問題

前陣子使用 Memcached 當成我們某個 ASP.NET 網站的後端，但只要遇到採用 Non-ASCII 的文字當成快取的鍵值(Key)就會自動消失，經過一番研究後確認是 Memcached Provider 的 DefaultKeyTransformer 在處理所有 memcached 通訊協定時所有的 Key 都是以 Encoding.ASCII 做為文字編碼，以致於所有中文字都無法讀取而自動被忽略，而也在編譯時與執行時期都不會出現任何錯誤，因此必須特別小心。

舉個簡單例子，假設我們有兩個 Cache Key 分別為：

  1. Poll_投票結果
  2. Poll_題目資料

而實際儲存到 memcached 中的 Cache Key 將會是 Poll_ 而已，由於遇到轉型失敗的快取物件都會預設為 null，因此可能會讓你在執行時期也不會發生問題，只是快取機制無法運作導致效能減低而已。

最後，我用以下兩種方式解決：

1. 修改 Memcached Provider 的原始碼，讓 DefaultKeyTransformer.cs 能夠正確處理 UTF8 文字

    修改過的原始碼已經放上 CodePlex，有興趣的人可以去下載並重新編譯。

    但請注意我上傳了兩個版本：

  • 針對目前線上可下載的 Memcached Providers 1.2 在原始碼那邊的 Changeset 是 13951，你應該要先取出 Changeset 13951 的原始碼，再套用 Patch ID = 5104 的修補檔才能編譯出跟 Memcached Providers 1.2 相容的組件！
  • 另一個 Patch ID = 5099 就是原始碼最新版 (Changeset 29520) 的修補檔。

 

2. 選用其他 KeyTransformer 即可正確處理 Cache Key 文字無法轉換的問題

    切換不同的 KeyTransformer 可以參考以下設定，只要修改 web.config 即可：

<enyim.com> 
  <memcached 
    keyTransformer="Enyim.Caching.Memcached.SHA1KeyTransformer, Enyim.Caching"> 
    <servers> 
      <add address="127.0.0.1" port="11211" /> 
    </servers> 
    <socketPool minPoolSize="10" maxPoolSize="100" 
        connectionTimeout="00:00:10" deadTimeout="00:02:00" /> 
  </memcached> 
</enyim.com>

相關連結

  

此文章由 will 發表於 2010/3/7 上午 12:34:03

永久連結 | 評論 (0) | 此文章的RSSRSS comment feed |

分類: ASP.NET | .Net

標籤: , ,

收藏:

透過 logman 指令有效率的操作效能監視器

這個星期都忙碌於一個大型網站的效能調校，而效能調校首重數據分析，透過數據分析進一步瞭解應用程式所遇到的效能瓶頸，最常使用的工具不外乎就是 效能監視器 ( Performance Monitor )，但由於有多台主機，每壹台都要重新選取一次這些 效能計數器 (Performance Counter) 實在很麻煩，所以若能透過指令列工具建立效能監視集合就會十分方便。

備註: 在 Windows Server 2008 的名稱為 可靠性和效能監視器

透過指令列取得所有系統中可用的效能計數器，並另存於文字檔中

typeperf -q -o PerfMon_Counters_All.txt

取得的 PerfMon_Counters.txt 共有數千筆效能計數器物件，如何挑選適當的計數器就是門大學問了，我這裡僅列出與 ASP.NET 相關的計數器如下：

\System\*
\Memory\*
\PhysicalDisk(*)\*
\Process(*)\*
\Processor(*)\*
\Thread(*)\*
\.NET CLR Data(*)\*
\.NET CLR Networking(*)\*
\.NET CLR Memory(*)\*
\.NET CLR Interop(*)\*
\.NET CLR Exceptions(*)\*
\.NET CLR Loading(*)\*
\.NET CLR LocksAndThreads(*)\*
\.NET CLR Jit(*)\*
\.NET CLR Remoting(*)\*
\.NET CLR Security(*)\*
\ASP.NET\*
\ASP.NET Applications(*)\*
\ASP.NET v2.0.50727\*
\ASP.NET Apps v2.0.50727(*)\*
\ASP.NET State Service\*
\Web Service(*)\*

你也可以將以上計數器清單另存成一個文字檔，方便後續載入。

注意: 載入的效能計數器越多對系統的衝擊越大，因此請千萬小心，不要載入過多的效能計數器。

透過指令列建立資料收集器集合工具的使用者定義集合

logman create counter ASP.NET_PerfMon -cf PerfMon_Counters.txt

執行過以上指令後，就會自動在 效能監視器 的 [效能] / [資料收集器集合工具] / [使用者定義] 下方新增一個新的資料即可，如下圖示：

若要修改預設 15 秒的抽樣間隔，可以在建立時多加上 -si 的參數，如下指令為每 60 秒收錄一次效能數據

logman create counter ASP.NET_PerfMon2 -cf PerfMon_Counters.txt -si 60

這個步驟是我覺得最繁瑣的地方，透過指令自動化就會很方便，相較之下其他的指令列參數的用法就變的不那麼重要，可以直接透過 效能監視器 的視窗介面操作比較簡易且直覺，如果有興趣研究其他參數可以執行 logman /? 查詢。

透過指令列啟動剛剛建立的資料收集器

logman start ASP.NET_PerfMon

啟動之後你可以從 效能監視器 的視窗看見該資料集合已經啟動，並開始收集效能數據，如下圖示：

透過指令列停止剛剛建立的資料收集器

logman stop ASP.NET_PerfMon

透過效能監視器查看效能數據報表

由於我收錄的 ASP.NET 相關計數器非常之多，因此你會看到畫面密密麻麻的線條（如下圖點圖可放大）

你也可以考慮將還沒分析到的計數器暫時隱藏 ( 註: 按下 Ctrl + A 可全選 )

也可以點選 選定項目 將選取到的效能計數器特別高亮度顯示

也可以利用不同的檢視查看這些效能數據

 

相關連結

  

此文章由 will 發表於 2010/3/6 下午 07:13:12

永久連結 | 評論 (0) | 此文章的RSSRSS comment feed |

分類: 介紹好用工具 | ASP.NET

標籤: , , , , , ,

收藏: