~真相只有一個!!那就是唯一不變的事實!!~南無阿彌陀佛!相信自己判斷!!仰無愧於天,俯無愧於地!!!: January, 2009

Microsoft has tested the following workarounds. Although these workarounds will not correct the underlying vulnerability, it helps block known attack vectors. When a workaround reduces functionality, it is identified in the following section.

Deny permissions on the sp_replwritetovarbin extended stored procedure

Use one of the following procedures:

•

To deny access to the stored procedure, connect to SQL Server as a sysadmin using osql.exe or sqlcmd.exe or through SQL Server Management Studio and execute the following T-SQL script:

use master
deny execute on sp_replwritetovarbin to public

•

To deny access to the stored procedure using SQL Server administration:

•

For SQL Server 2000:

1.	Connect to SQL Server using Enterprise Manager as a sysadmin
2.	From the SQL Server Enterprise Manager window, select the desired server
3.	Expand the databases
4.	Expand Master
5.	Click Extended Stored Procedures. A list of stored procedures appears.
6.	From the list of stored procedures, right-click sp_replwritetovarbin and select Properties
7.	In the Properties window, click Permissions
8.	Under Users/Database Roles/Public, find Public, then click the box in the EXEC column. The box turns into a red X.
9.	Click OK twice

•

For SQL Server 2005:

1.	Connect to SQL Server using SQL Server Management Studio as a sysadmin
2.	From the Object Explorer window, select the desired server
3.	Expand the databases and the system databases
4.	Expand Master
5.	Expand Programmability
6.	Click Extended Stored Procedures. A list of stored procedures appears.
7.	From the list of stored procedures, right-click sp_replwritetovarbin and select Properties
8.	In the Properties window, click Permissions
9.	Click Deny execution beside the desired user IDs and click OK

11:48 AM | Add a comment | Permalink | Blog it | 資訊安全

How to change service accounts and service account passwords in SharePoint Server 2007 and in Windows SharePoint Services 3.0

http://support.microsoft.com/kb/934838

11:35 AM | Add a comment | Permalink | Blog it | MOSS

January 06

又一波惡意連結攻擊　國內知名網站成目標

原出處:http://www.ithome.com.tw/itadm/article.php?c=52895

現在只要以cn . jxmmtv.com進行搜尋，就可以找到五千多筆含有此惡意連結的台灣網頁。

資安專家近日發現又有駭客透過惡意連結大舉入侵台灣網站，雖然規模不如半年多前的十萬網頁受害來得大，但這次也有不少知名網站被植入惡意連結，包括Yahoo!奇摩生活+、家樂福等網頁都被點名。

資深資安專家邱春樹（Roger）指出，近期有許多台灣網站都被植入cn . jxmmtv.com/cn.js 和 cn . daxia123.cn/cn.js 等惡意連結，其中不乏知名網站，包括家樂福、中華職棒、甚至Yahoo!奇摩生活+。不過Yahoo!奇摩則澄清其早已有自動過濾機制阻擋惡意連結。

雖然有些惡意連結目前並不會作用，不過駭客很可能伺機而動，因此網站業者還是必須時時檢查網頁是否存在惡意連結。邱春樹表示，目前還在觀察駭客是否嘗試進一步發動零時差攻擊，雖然有此可能，但目前還看不出來，不過資安人員最好都能積極檢查網頁是否危險。

現在只要以cn . jxmmtv.com進行搜尋，就可以找到五千多筆含有此惡意連結的台灣網頁。邱春樹說，如Yahoo!奇摩生活+被發現惡意連結已經約莫有一星期的時間，不過直到今天（1/5）下午才移除。該連結是被夾帶在生活+附加的新聞內容中，雖然目前並不會作用，不過還要看放此惡意檔案的伺服器是不是還活著。

Yahoo!奇摩則回應表示，該公司網頁有自動過濾機制，不允許任何HTML語法寫入，因此即使被植入惡意連結也無法執行。該公司交易安全經理陳易昌表示，這也是因應現在網頁掛碼等惡意攻擊相當嚴重，若是以人力每天過濾也難保不出事，因此不如完全不讓HTML語法執行。

但對此說法，邱春樹則持懷疑態度，他表示，若是Yahoo!奇摩真的自動過濾掉所有惡意語法，網頁應該完全不會出現惡意連結，但是仍看的到被植入的惡意連結。

阿碼科技則表示，約自上月底開始，新一波的資料隱碼（SQL Injection）攻擊伴隨掛馬再度大量出現，許多知名企業網站均受其害。犯罪集團趁著大家休假時上網時間增加，以及網管人員可能無法立即處理時發動攻擊。曾發現單一網站就遭受來自179個攻擊來源的入侵攻擊，高達五百多次的試圖攻擊記錄。

根據阿碼科技SmartWAF所攔截的記錄顯示，本次攻擊手法仍然針對後端資料庫使用微軟SQL Server的網站為主。另外，攻擊來源有5筆來自台灣IP，137筆來自南韓，31筆來自於大陸。

11:23 AM | Add a comment | Permalink | Blog it | 資訊安全

ORACLE 效能調校這篇值得看!!

http://www.oracle.com/technology/oramag/oracle/04-jan/o14tech_perf.html

9:15 AM | Add a comment | Permalink | Blog it | 資料庫

January 05

資訊系統的可用性－以資料庫為例

－劉承修 2008/12/19

電子商務蓬勃發展之下，無分晝夜的商業行為持續地進行，如何提升資訊系統的「穩定性」及「可用性」，早已成為IT人員一個重要的話題。而「可用性」之高低對客戶的滿意度有著極重要的指標，甚至對整個企業商譽帶來莫大的影響，例如：當你要去ATM領錢或者利用網路銀行轉帳，結果出現「停止服務」等字眼，這時你一定氣炸了，說不定就因此對這企業的IT服務大打折扣。其實或許在背後發生系統重大毀損而造成這樣的現象。所以資訊系統的「可用性」設計，其目的就是要確保前端服務（ATM領錢）不會因系統發生突發狀況而引起服務遲延。其實系統停止服務的原因很多，如人為失誤、自然災害、硬體故障等，資料庫系統又是企業IT服務的核心，如果遭遇到上述的原因，所帶來的衝擊及損失將是難以想像的。所以許多資料庫系統都提供「高可用性」的技術，如Windows的CLUSTER技術，或ORACLE RAC架構，其目的都是將意外停機的時間降到最低。以下就說明「可用性」的一些觀念。

何謂可用性

「可用性」一詞，一般IT人員是以伺服器運行狀況來說明。但以企業IT服務的角度來看，這種定義似乎不夠貼切。因為無論伺服器的運行狀態與否，只要是前端應用程式無法提供服務，或者效能不足而造成應用程式回應時間過慢，這系統就是無法使用，則系統的「可用性」就被遭受質疑。如此推來當Database Administrator（以下稱DBA）在思考資料庫系統的「可用性」時，就應該從前端使用者的角度來思考「可用性」的需求，這樣設計出來的「可用性」較貼切使用者的需求。

可用性的計算

IT長官常會問DBA說：「我們企業的資料庫主機的可用性是多少?有沒有5個9（99.999 %）?」其實這些數值的表面意義高於實質意義，就算是無法達到5個9，也不代表一定會發生問題，現今5個9的背後意義是表示資料庫主機可提供非常穩定的服務。那數值是如何被計算出來的呢？請參考如下：

可用度計算公式
A = (F–R)/F
A = 可用度
F = 平均運作時間
R = 平均修復時間

由公式可知，「平均運行時間」與「平均修復時間」是計算「可用性」的兩大元素，而「可用性」的高低主要是取決於「平均修復時間」，也就是當發生災難時，需花多少時間使系統修復完畢並上線服務，所以DBA常面臨的挑戰是「平均修復時間」。就因如此，DBA常常會苦惱要用哪一種技術是最符合要求的。因此，DBA要選擇何種解決方案是貼近企業的需求，進而符合「服務層級合約(S.L.A-Service Level Agreement)」(注1)的目標，這是一門大的學問。

設計可用性框架

DBA需要有一個藍圖方能勾勒出「高可用性」之設計框架。

注1：「服務水準協議（Service Level Agreement，SLA）是雙方（客戶-業者或業者-業者）所協商出來的一種契約，以提昇組織的「IT服務管理（IT Service Management，ITSM）」之績效。如沒有協議服務水準，則服務需求者與服務提供者雙方，將無法就所提供及執行的服務達成共識，這會衍生許多IT服務執行與管理的爭議。換句話說，所有IT服務計畫及作業，都是在SLA的基礎上逐步展開和持續改善，因此明確地量化SLA文件，將是提昇IT服務品質及績效的第一步。而「可用性」是S.L.A其中一項的協議，而一般測量「可用性」指標多以Recovery Point Objective (RPO)及Recovery Time Objective (RTO)為基準。

所有的服務都來自於需求，如果把系統的「可用性」當成服務，它的需求來源就是「商業需求」。一旦需求確認，就要想辦法去完成，所以就要設計一套「可用性」的服務，接著就要去評估建置時所面臨到一些問題，例如：建置的預算、IT的成本、停止服務的成本等等，經過評估之後才選擇適當的「高可用性」技術。

影響可用性的因素

而在討論「可用性」的規劃以及技術之前，首先要了解什麼是造成資訊系統無法正常運作的原因，此稱之為「可用性障礙」（Barrier to Availability），就如同人生病一樣，要找出病灶，才能防制與治療。而系統的「可用性」也是一樣，要知道「可用性障礙」才能提出保護之道。

1、

硬體故障或毀損

大家常常遇到家電用品某個「零件」故障拿去送修，所以硬體故障或毀損是一般常見的問題，而資訊系統也不例外，只是處理的零件不一樣。資料庫系統首重的「零件」是磁碟機及磁碟控制卡。一旦發生故障，系統也就跟壞掉的家電一樣無法使用。在IT的環境中，雖然許多伺服器都有熱抽換的磁碟機或磁碟控制卡，但熱抽換的磁碟機並不具備保護功能，而是要使用磁碟陣列（RAID）的組態，才能保護磁碟機；磁碟控制卡如果只有單個，一但發生異常，也會造成資料庫系統的停擺，所以應設計容錯機制。現在許多企業都把資料庫系統的資料放置於具高保護性的儲存設備中進行管理，以降低因磁碟毀損所造成的災害。但處理器（CPU）、記憶體（MEMORY）也是有故障的狀況發生，或許發生的機率極低，但最好的備援方式還是另準備一台伺服器以供待命。

2、

應用程式錯誤

無法讓使用者得到所需的資料，是屬於應用程式錯誤的範圍，管理此類型錯誤的第一步就是設計一套良好的變更管理程序。許多程式開發人員或營運人員沒有經過適當的變更流程，就去設定或異動系統，到最後，都不知道異動了什麼，想追問題也追不到，所以系統環境的變更，是發生應用程式錯誤最常見的原因，因此設計一套良好的變更管理程序，以了解最近變更的相關歷程，則是有助於問題的診斷，並迅速將系統恢復。

3、

使用者操作錯誤

使用者的錯誤也是造成資料庫系統無法提供服務的原因之一，這也是最難防範的，因為使用者錯誤是非技術性的問題，而是企業整個內控及教育問題。以下分兩種類型：

	不當的系統操作
	這原因是可避免的，但要從企業內控做起，如完善伺服器存取管控流程，這可避免無經授權人員登入系統操作，就如同設定門禁，避免閒雜人等進入。正確系統操作手冊，這可避免因錯誤的操作行為引起系統異常，就如同複雜的電器沒有完整操作手冊，就很容易被使用者用壞。

	不當的資料庫操作
	例如，刪錯資料表、刪錯資料庫、DML指令下錯等，這些行為對資料庫系統仍是有效的交易。但資料有錯或資料遺失，商用服務則不能持續進行，這也是「可用性」障礙的原因，就如產生出來的年度報表或使用者要查的資料發生異常。這也是要從企業內控作起，如完善資料庫存取管控流程，這可降低因無經授權的人員登入資料庫進行資料操作而引致錯誤的行為。

提高可用性的解決方法

知道造成生病的原因，接著就要針對這些問題去思考如何去解決。以下建議幾種思考模式以幫助DBA去選擇一些解決方法。

因硬體問題產生資料庫異常

可依「硬體問題造成可用性障礙」及「使用者的需求」兩方面來看。

硬體問題造成可用性障礙

● 安裝備援主機以預防正式主機發生硬體異常。

使用者的需求

●「可用性」要求較高：當時跟使用者簽定的S.L.A要求較高。例如：資料庫停止服務時間幾分鐘或者一分鐘內。則考慮選擇「熱待命（HOT STANDBY）」的備援等級，其備援特色如下：

	■備援伺服器擁有主要伺服器的資料
	■提供與主要伺服器交易一致的資料。
	■自動偵測主要伺服器的狀況與自動轉移服務。

●「可用性」要求較低：當時跟使用者簽定的S.L.A要求不高。例如：資料庫停止服務時間為幾小時(注2) 。則考慮選擇「暖待命（WARM STANDBY）」或者「冷待命（COLD STANDBY）」的備援等級，各備援特色如下：

	暖待命
	■提供與主要伺服器交易一致的資料。
	■自動偵測主要伺服器的狀況與自動轉移服務。
	■可能需要手動偵測主要伺服器狀態與手動轉移服務。

	冷待命
	■還原資料的備份。
	■有正確的作業系統和相關軟體等的備份。
	■考慮是否接受恢復正常服務時的延遲狀態。

注2：資料庫系統停止服務時間之長短，需要與相關使用者討論並抵定（甚至簽訂S.L.A），並且根據資料庫的大小狀態來判斷所選擇的方案是否符合需求。例如：資料庫大小各為200G與10M，其恢復的解決方式就相異，如果是200G，S.L.A簽定十五分鐘，則就不能使用「冷待命」（COLD STANDBY），就需考慮「熱待命」（HOT STANDY）或「暖待命」（WARM STANDY）；反之10M資料庫大小，S.L.A條件一樣，或者可選擇「冷待命」（COLD STANDBY）來做備援的方案，這些狀況都是要被考慮的。

應用程式問題產生資料庫資料異常

●嚴密的測試：盡可能模擬系統上線之狀況，並進行相關驗證。

●規劃程式上線流程：了解最近變更的歷程是有助於問題診斷，並迅速將系統恢復。

●定期資料備份並思考保留期限：與使用者討論資料保存期限，方能利用備份還原技術，就能救回因應用程式造成資料遺失或錯誤的資料。

使用者問題產生資料庫資料異常

因錯誤判斷下錯指令而造成資料錯誤或遺失資料。這屬於資料面的問題，因此須以恢復資料的層級去考慮，建議如下。

●定期資料備份並思考保留期限：與使用者討論資料保存期限，方能利用備份還原技術就能補回遺失或錯誤的資料。

●流程管控：設計完善的資料庫存取管控流程，可降低因未經授權人員登入資料庫，且進行資料的操作而導致錯誤的行為。

以上談了許多資料庫系統「可用性」的相關問題，無非希望藉由這篇短文，使讀者初步了解當談論到「可用性」時，需要留意的一些事項及遇到問題時如何去尋找解決的線索，進而達到IT服務高品質的目標。

1:30 PM | Add a comment | Permalink | Blog it | 資料庫

資料庫管理師類型

分享資料庫管理師的類型

以下是簡單就資歷深淺及工作定位劃分出資料庫管理員的三種定位。

¢ 資淺資料庫管理員：資淺資料庫管理員指的是只有部分經驗或根本沒有資料庫管理經驗。基本上主要的工作性質是負責監控資料庫及基本的資料庫維護。資淺資料庫管理員的工作大致如下：

1. 資料庫備份是否成功。

2. 排程工作是否正常執行。

3. 資料庫及伺服器空間是否足夠。

4. 基本的資料庫問題排除。

5. 檢查 error log是否有錯誤訊息。

6. 監控資料庫連線是否正常。

7. 提供日報表、周報表及月報表。

¢ 資深資料庫管理員：資深資料庫管理員通常指的是有多年資料庫管理經驗的人，對整的資料庫甚至整個系統都相當的熟悉，同時對資料庫的各種操作及指令都相當的純熟，因此資深資料庫管理員對於所接觸的層面必定較為寬廣，所負責的工作除了每天操作面的工作項目之外，還需負責資料庫環境的規劃與管理，同時必須了解及協助程式開發人員的需求。資深資料庫管理員的工作大致如下：

1. 負責整個資料庫環境的正常運作。

2. 建立資料庫管理規範及安全機制。

3. 空間容量的規劃及預測未來的成長量。

4. 與程式開發人員加強溝通，以提供適當的協助。

5. 安裝資料庫伺服器及資料庫，或是建立標準安裝程序，提供資遣資料庫管理員進行安裝作業。

6. 支援資淺資料庫管理員之處理不了的問題。

7. 根據資淺資料庫管理員整理的報表中，發覺淺在的危機，並加以解決或預防，以增加資料庫的穩定度。

8. 管理及訓練資淺資料庫管理員。

¢ 顧問資料庫管理員：顧問資料庫管理員除了必須對於資料庫要有深厚的知識外，其特別的價值是來自於擁有與其他資料庫管理員不曾遇過的經驗與知識領域，而這些經驗和知識對資料庫本身、相關的應用程式和環境架構又非常重要與關鍵，例如資料庫的效能急速低下、不可預期或極端且急迫的問題，顧問資料庫管理員能夠用一個結構化、程序性流程，快速的診斷出問題的癥結同時提供解決方案，而這些都是經驗及專業的累積。通常顧問資料庫管理員都是歷練過上述的各種類型的資料庫管理員。資深資料庫管理員的工作大致如下：

1. 利用自身累積的經驗和專業知識提供適當的建議與解決方案。

2. 當問題發生時能快速評估、歸納及排除障礙。

3. 強而有利的溝通能力，因為在企業裡，顧問資料庫管理員在許多不同層次的人員進行溝通及了解。

4. 撰寫文件並紀錄解決方案，同時協助建立知識庫，以方便於相同的問題再次發生時，能提供相關人員有所遵循的依據，迅速排除障礙。

5. 需要有異質資料庫及平台的轉換經驗。時常接受及測試新知，以因應未來的需求。

TIM寫的真好

1:23 PM | Add a comment | Permalink | Blog it | 資料庫

美國FBI網路犯罪中心（IC3）日前指出，微軟SQL Server的漏洞

原出處:http://www.ithome.com.tw/itadm/article.php?c=52845

美國FBI網路犯罪中心（IC3）日前指出，利用微軟SQL Server的漏洞，植入各種後門程式以取得有效使用者存取資料庫權限，是目前駭客最常使用的攻擊手法之一。對此，FBI IC3提出12種基本的預防之道。
首先，對於常見SQL Injection（隱碼攻擊）或微軟SQL Server漏洞，FBI IC3認為，資料庫管理人員應該關閉有傷害性的SQL Stored Procedure（預存程序）呼叫，例如最常見的xp_cmdshell可允許存取本地端的程式，就是一種安全性的隱憂。FBI IC3提醒，要關閉這類有害的Stored Procedure，除了關閉呼叫功能，更需移除相關dll檔。
其次，FBI IC3建議，網站伺服器（例如微軟的IIS）應該過濾掉過長的網址。IT人員可以找出網路服務所使用的最長網址長度，藉由限制過長網址，可避免駭客在網址中隱含惡意網址或參數字串。再者，對於目前許多動態網頁內容安全性的保護，FBI IC3認為，網路管理員應該要做到過濾字串和只傳參數，把程式的控制指令替代成字串，不會對SQL指令造成影響，但又能在瀏覽器正確顯示。
許多IT人員習慣以最高管理者權限執行安裝各種服務，這也意味著，一旦這個最高管理者權限被竊，整個伺服器和資料庫的安全性將岌岌可危。所以，FBI IC3建議，不要使用最高權限安裝微軟的SQL Server和IIS網站伺服器，只安裝所需的程式，例如AD伺服器就不需要安裝Microsoft Office，對網路和資料庫使用者，只提供最小權限。

提供密碼保護，是保護管理者帳號的基本作為。但FBI IC3發現，有很多企業IT管理人員經常採用SQL Server預設SA管理者帳號和預設空白密碼，這些都是安全上的一大隱憂。此外，對於主機登入密碼多次輸入錯誤，應暫時封鎖並做檢查，FBI IC3認為這是對駭客入侵的初次檢驗。

FBI IC3認為，所有企業內的伺服器都應該禁止直接連網，所有的連網都應該透過代理伺服器（Proxy）對外連線，才能夠檢查連線內容和連線埠。FBI IC3也提醒，對於一些會產生驗證金鑰（例如PIN碼）的HSM（硬體加密模組），應該限制其他指令不可以產生這種加密的PIN碼，避免讓駭客可以取得足夠的樣本，藉此反推加密演算法以保護加密演算法。

FBI IC3建議，企業IT人員對於資料庫的管理往往較為鬆散，不論是存取資料庫的黑白名單，或制定更謹慎的資安管理規則，都是讓資料庫更安全的手法之一。最後，FBI IC3也提醒，企業內IT人員應該要在防火牆定期更新已知的惡意網址或IP位址，檢驗企業內是否有連結這些惡意網路位址的記錄，即時掌握企業內資安動態。

11:22 AM | Add a comment | Permalink | Blog it | 資訊安全

January 04

2009年主要充電重點

技術&管理

提升資料庫技術- MS SQL & ORACLE
WINDOWS 2008 建置&管理(CLUSTER)
MOSS 2007 建置&管理
IT管理- MOF & ITILV3 & Security

認證計畫

ORACLE UPGRADE
CISSP

出書計畫

MS SQL 2008 進階管理
IT治理
MS SQL 2008 HA

3:54 PM | Add a comment | Permalink | Blog it | 人生規劃