Mssql和Mysql的安全性分析

數據庫是電子商務、金融以及ERP系統的基礎，通常都保存著重要的商業伙伴和客戶信息。大多數企業、組織以及政府部門的電子數據都保存在各種數據庫中，他們用這些數據庫保存一些個人資料，還掌握著敏感的金融數據。但是數據庫通常沒有象操作系統和網絡這樣在安全性上受到重視。數據是企業，組織的命脈所在，因此選擇一款安全的數據庫是至關重要的。大型網站一般使用oracle或DB2，而中小型網站大多數使用更加靈活小巧的mssql數據庫或者mysql數據庫。那么，在同樣的條件下，微軟的mssql和免費的mysql哪個更加安全呢？

　　我在我的機子上面用管理員帳號默認安裝了mssql和mysql以便在相同的情況下測試他們的安全性。我的系統配置如下：操作系統Microsoft Windows 2000 Version5.0，安裝了sp4，ftp服務和iis服務，支持asp和php。系統只有一個管理員帳號admin，guest帳號沒有禁用。

　　一、系統內部安全性分析

　　1、mysql數據庫權限控制問題

　　mysql的權限控制是基于mysql這個數據庫的，叫做授權表，一共包括包括六個表columns_priv，db，func，host，tables_priv和user。先使用desc user命令查看非常重要的user表的結構以便查詢內容，現在可以查看他的權限設置了。

　　使用命令select host，user，password，delete_priv，update_priv，drop_priv from user；這個命令查看了幾個比較危險的權限，顯示結果如下：

+-----------+------+------------------+-------------+-------------+-----------+ | host | user | password | delete_priv | update_priv | drop_priv | +-----------+------+------------------+-------------+-------------+-----------+ | localhost | root |0e4941f53f6fa106 | Y | Y | Y | | % | root | | Y | Y | Y | | localhost | | | Y | Y | Y | | % | | | N | N | N | +-----------+------+------------------+-------------+-------------+-----------+ 4 rows in set (0.00 sec)

　　第一條表示在本機使用root用密碼登陸，擁有刪除記錄，修改記錄，刪除表等權限，好，這是安全的。第二條表示在任何主機使用root不需密碼登陸，擁有刪除記錄，修改記錄，刪除表等權限。第三條表示在本機匿名登陸，擁有刪除記錄，修改記錄，刪除表等權限。最后條表示可以再任何主機匿名登陸，但是沒有任何權限。

　　顯然，第二，三，四都是不安全的！第二條不用說，就第三條而言，就算你在本地是guest權限，但是也可以登陸mysql數據庫，而且擁有全部權限。這樣，就可以對數據庫為所欲為了。

　　解決方法：如果你不需要遠程維護，刪除掉第二條,delete from user where host="%" and user="root";或者給它加個強壯的密碼。刪除第三條，delete from user where host="localhost" and user="";

　　2、mysql安裝目錄權限問題

　　mysql默認安裝到c:/mysql，但是c盤默認是everyone完全控制，由于權限的繼承性，c:/mysql對everyone也是完全控制的，顯然這樣是不安全的。因為惡意用戶可以刪除重要的數據文件。

　　解決方法：重新設置mysql目錄的存取權限。或者將mysql安裝到其他目錄,如果你移動Mysql分發到D:/mysql，你就必須使用D:/mysql/bin/mysqld --basedir D:/mysql來啟動mysqld，甚至還需要修改它的配置文件。

　　3、mssql數據庫權限控制問題

　　mssql數據庫的權限控制是基于master庫的syslogins表，擁有所有權限的帳號是sa，其他還有sysadmin，db_owner等不同權限帳號。但是，mssql數據庫最高權限帳號sa的默認密碼是空，這樣如果安裝的時候不注意，就會給數據帶來毀滅性的災難。惡意攻擊者可以修改，刪除所有數據，更加重要的是mssql帳號可以利用擴展執行系統命令。

　　解決方法：定期檢查所有登陸帳號，查看是否有不符合要求的密碼。

　　Use master

　　Select name,Password from syslogins where password is null命令檢查是否有空口令帳號存在。盡可能的刪除存儲擴展，防止本地用戶利用存儲擴展執行惡意命令。

　　use master

　　sp_dropextendedproc xp_cmdshell 命令刪除xp_cmdshell擴展。

　4、mssql安裝目錄權限問題

　　同mysql一樣，mssql也是安裝到everyone完全控制c盤，由于存取控制問題，最好安裝到d盤等非系統盤進行嚴格的權限控制。而且，由于mssql數據庫與系統結合非常緊密，系統管理員在沒有數據庫密碼的情況下也可以通過選擇windows驗證來操作數據庫。因此，普通用戶有可能通過系統漏洞提升自己的權限，對數據庫進行破壞。

　　解決辦法：除了嚴格的存取限制外，還要定期查看SQL Server日志檢查是否有可疑的登錄事件發生，或者使用DOS命令findstr /C:"登錄" d:/Microsoft SQL Server/MSSQL/LOG/*.*。

　　mssql的安全是和windows系統安全緊密結合的，任何一個出現漏洞，都會威脅到另一個的安全。

　　總結，在系統內部安全性上，mysql和mssql都沒有達到令人滿意的程度，帳號安全，存取權限都控制的不是很好。但是mssql有詳細的日志可以查看登陸情況，比mysql要高出一籌。如果進行了合理的設置，mysql反而要更加安全些，因為對mssql而言，只要有系統權限即可擁有數據庫權限。

　　二、外部網絡安全性分析

　　1、數據庫服務的探測

　　為了安全，可以讓mysql服務運行在內網，但是如果你的機器有外網的接口，mysql也會自動被綁定在外網上面，暴露在internet中，而且系統會在TCP的3306端口監聽，非常容易被端口掃描工具發現，不能保證數據安全。如果默認，mssql則會打開TCP的1433端口監聽。雖然mssql可以人為的改變監聽端口，但是通過微軟未公開的1434端口的UDP探測可以很容易知道SQL Server使用的什么TCP/IP端口了。往UDP1434端口

　　發送一個1個字節的內容為02的數據包，被探測的系統則會返回安裝的mssql服務信息，這些信息包括：主機名稱、實例名稱、版本、管道名稱以及使用的端口等。這個端口是微軟自己使用，而且不象默認的1433端口那樣可以改變，1434是不能改變的。一個典型的返回的信息如下：

ServerName;Sky;InstanceName;sky;IsClustered;No;Version;8.00.194;tcp;3341;np;//sky/pipe/MSSQL$XHT310/sql/query;可以發現mssql的tcp端口改成了3341，為攻擊者打開了方便之門！只要會一點socket編程知識，很容易就可以寫出掃描mssql服務的程序，而且，由于利用了udp端口，一般的過濾是很難防范的。 補天的awen寫了個探測程序，用的是c#語言，代碼如下：

using System;  using System.Net.Sockets;  using System.Net;  using System.Text;  using System.Threading; namespace ConsoleApplication3  { class Class1  {  //創建一個UDPCLIENT實例  private static UdpClient m_Client; //LISTEN用來獲取返回的信息  public static string Listen(string hostip)  {  string HostIP = hostip;  IPAddress thisIP = IPAddress.Parse(HostIP);  IPEndPoint host = new IPEndPoint(thisIP,1434);  byte [] data = m_Client.Receive(ref host);  Encoding ASCII = Encoding.ASCII;  String strData = ASCII.GetString(data);  return strData; }  //SEND  public static void Send(string hostip)  {  string HostIP = hostip;  byte [] buffer = {02};  //02為要發送的數據，只有02、03、04有回應  int ecode = m_Client.Send(buffer,1,HostIP,1434);  //ecode用來返回是否成功發送  if(ecode <= 0)  {  Console.WriteLine("發送時出錯：" + ecode); } }  //對返回的信息的簡單的處理  public static void OutputInfo(string strdata)  {  string str = strdata;  //str.le  char [] that = {‘;‘,‘;‘};  string [] strofthis =str.Split(that);  //int i= 0   for(int i=0;i{ Console.Write(strofthis);  Console.Write(‘ ‘);  } }  //輸入IP  public static string InputHostIP()  {  Console.Write("enter the ip you want to scan: ");  string hostip =Console.ReadLine();  Console.Write(‘ ‘);  return hostip;  }  //EXIT  public static void Exit()  {  Console.WriteLine("if you want to exit ,just input 1 ");  int a = Console.Read();  if(a!= 1)  {  Console.WriteLine("if you want to exit ,just input 1 ");  Console.Read();  }  else  {  }  } [STAThread] static void Main(string[] args)  {  string HostIP;  HostIP = InputHostIP();  Console.WriteLine("Begin to send udp to the host");  m_Client = new UdpClient();  Send(HostIP);  string strData=Listen(HostIP);  OutputInfo(strData);  Exit(); }  }  }

　3一個典型的返回的信息

　　ServerName;AWEN;
　　InstanceName;AWEN;
　　IsClustered;No;
　　Version;8.00.194;
　　tcp;1044; （TCP的端口，可見就算改了端口也是很容易找到的）
　　np;//AWEN/pipe/MSSQL$XHT310/sql/query;

　　解決辦法：安裝防火墻，或者利用Windows2000系統的ipsec對網絡連接進行ip限制，實現IP數據包的安全性。對IP連接進行限制，只保證自己的IP能夠訪問，拒絕其他IP進行的端口連接，把來自網絡上的安全威脅進行有效的控制。重要的是，還要對端口作過濾，包括大部分的tcp和udp端口，因為僅僅做ip限制的話，有可能惡意攻擊者先攻擊被數據庫服務器信任的主機，控制之后作為跳板對數據庫服務器進行攻擊。

　　2、數據庫的密碼探測

　　密碼攻擊包括兩種，破解密碼和網絡監聽。破解密碼是使用工具不停的連接數據庫來猜測密碼， 包括字典攻擊，暴力攻擊和界于兩者之間的半暴力半字典攻擊。通常攻擊者先采用字典攻擊的方法，沒有成功的話依次采用半暴力半字典攻擊，暴力攻擊。在網絡速度夠好，電腦運算能力夠強的情況下，這樣的密碼攻擊危害是相當大的。網絡監聽則是控制一臺網絡設備，在上面運行監聽工具捕獲在網絡中傳送的密碼信息。網絡監聽可以分為兩種，一種是外部的監聽，將偵聽工具軟件放到網絡連接的設備或者 放到可以控制網絡連接設備的電腦上，這里的網絡連接設備，比如網關服務器，比如路由器等等。另外一 種是來自內部的監聽，對于不安全的局域網，數據是采用廣播的方式傳播的，只要把網卡設置為混雜模式即可接收到本來不屬于自己的數據包，當然可能包括密碼信息等資料。

　　解決方法：針對密碼破解，只要把密碼設置為足夠強壯，并且對同個ip地址不停的連接請求進行屏蔽即可。 但是對于監聽來說，網絡傳輸的時候如果不加密的話，所有的網絡傳輸都是明文的，包括密碼、數據庫內容等 等，不管多么復雜的密碼都是于事無補的，這是一個很大的安全威脅。所以，在條件容許情況下，最好使用SSL

　　來加密協議，當然，你需要一個證書來支持。并且，對于網絡監聽應該及時發現，如果網絡中的丟包率突然提 高，那么就有理由懷疑網絡遭到監聽。

　　3、腳本安全

　　腳本安全本身就是個非常復雜的問題，足以寫一篇專業的長篇分析文章，而且我對腳本不是很內行，mix,envymask,pskey,angel他們比較瘋狂，哈哈。腳本

　　安全主要是對提交的數據缺乏嚴格的檢查導致的，比較危險的符號有“;”，“ ”，“#”，“--”，“$”，“/”等。這個問題最初被認為是asp+sqlserver的問題，但是很快就發現實質上它的影響非常大，后來有人繼續深入發現在php+mysql該問題依然會存在，san對php作過深入分析，有興趣的去安全焦點找他的文章。對于腳本

　　好象沒有特有效的解決方法，只有依靠程序員的個人素質了……

　　總結，不管是mysql，還是mssql，在外部網絡中，都受到相當大的威脅。相比而言，mssql受到的威脅甚至要更大些，最近2年來，mssql暴露出了多個遠程溢出漏洞。如果配置的比較好的話，我認為，mysql要比mssql安全一些，因為隨時會爆發的新溢出漏洞是防不勝防的，而且能夠執行系統命令的sql注入攻擊也非常可怕。好了，限于篇幅，這篇文章到此結束。

　“青花瓷Java版”為北京師范大學教育學部蔡蘇作詞原創，覆蓋教育技術學院專業選修課《面向對象程序設計》教學大綱中的所有知識點。

　　視頻：http://player.youku.com/player.php/sid/XMjU3Mjk2NzA0/v.swf

　　歌詞：

　　JDK 和JRE 莫要混淆去

　　環境變量的配置有時讓人迷

　　初學的人莫貪圖上來I D E

　　先用J D K +文本編輯器

　　面向對象仨特點一定要牢記

　　封裝繼承和多態一個不能離

　　接口為多重繼承

　　抽象類一定要有實例

　　O b je c t呀 所有類爹地

　　package在類中只能有唯一

　　注釋命名時要既規范又明晰

　　就當為好程序員伏筆

　　G U I 不是鬼 千萬別恐懼

　　四大布局管理 多練才熟悉

　　勤能補拙熟能生巧到考試時

　　你眼帶笑意

　　三整兩浮一布爾再加字節符

　　基本數據Byte數了然于心底

　　碰到異常一定記得try/catch

　　要打包發布使用jar命令

　　線程何時被調用全看調度器

　　睡眠同步和死鎖使用要仔細

　　網頁中Applet

　　獨立程序Application

　　ApplicationO b je c t呀所有類爹地

　　package在類中只能有唯一

　　注釋命名時要既規范又明晰就當為好程序員伏筆

　　(這樣程序員才是好樣滴)

　　G U I 不是鬼

　　千萬別恐懼四大布局管理

　　多練才熟悉

　　勤能補拙熟能生巧到考試時你眼帶笑意

　對于系統管理員來說如何管理自己的服務器已經是再簡單不過，但是如何管理好服務器卻不是一個簡單的事情。對于管理員來說重啟服務器可不是一件鬧著玩的事情。對于Windows服務器管理員來說經常性重啟Windows設備已經成為一種生活常態，但在Unix系統中這種辦法卻難以奏效——在默認情況下重新啟動不會帶來任何形式的改善。

　　我打算借此機會跟大家詳細聊聊重啟的問題。對于每一位服務器管理員來說這都算得上熱門話題，但在Unix極客們眼中它則屬于一種層次更深的課題——可能因為Windows管理員們往往把重啟當成故障排查工作的首要步驟之一，而Unix團隊則一般只在束手無策的情況下才進行嘗試。

　　Unix服務器重啟的兩種情況

　　實際情況是：服務器重啟操作應該極少出現——請注意是極少。在這里我列舉內核更新與硬件更換作為例子，因為它們是Unix領域中引發重新啟動的兩大主要原因。有些人一直在鼓吹什么不重啟服務器的話會帶來某些嚴重的安全風險，這簡直是一派胡言。如果服務項目與應用程序中確實存在安全風險，那么打上漏洞補丁就能解決問題了，而且補丁往往不要求重啟設備。而如果安全風險存在于內核模塊中，一般來說只需卸載對應模塊、安裝補丁，最后重新加載模塊。沒錯，我承認一旦內核中存在安全風險，那么重啟操作的確是必要的。但在這種情況之外，大家根本沒有切實的理由重新啟動Unix服務器。

　　有些人認為如果不進行重啟操作，其它形式的風險往往會接踵而至，例如某些關鍵性服務項目在開機時沒有得到正確啟用，而這將導致一系列隱患。當然，這種說法本身是正確的，但只要管理工作執行到位，這其實根本就是種杞人憂天。只有剛剛接掌服務器設備的菜鳥才會忘記正確設置服務項目的啟動參數。不過話說回來，如果大家的服務器正處于構建階段，且其中還不涉及任何生產方面的內容，那么不妨隨意進行各類重啟測試，這不會帶來任何不良影響。而且我認為這正是熟悉重啟機制的最好時機。

　　但還有另一方面需要考慮：那些將重啟操作當成故障排查重要步驟之一的家伙是抱著死豬不怕開水燙的心態，打算一次性把問題都暴露出來。就說一套已經出現問題的Unix設備吧，某些還處于運行中的服務項目實際上已經無法再次啟動，而這一點在重啟之后就會顯現出來——也許是由于分段故障或者其它稀奇古怪的原因。

　　造成Unix服務器重啟的原因

　　如果我們只是簡單查看幾分鐘之后就一拍腦門決定重啟設備，那么也許故障的真正原因就徹底湮沒在時光中了——也許是某位初級管理員在運行一套自己編寫的愚蠢腳本時無意中刪除了/boot目錄或者/etc、/usr/lib64目錄下的部分內容。這正是引發分段故障以及設備不穩定情況的罪魁禍首。然而一旦我們選擇直接重啟服務器而沒有深入挖掘問題，那么顯然問題會變得更加嚴重，接下來不出意外的話大家應該會啟動恢復鏡像——這就代表需要面對大量恢復工作——而與此同時生產服務器也將陷入停機狀態。

　　以上只是我們在Unix領域中應該盡量避免重啟操作的原因之一。與其說這算是種故障排查方法，不如把它看作一類孤注一擲的豪賭——要么發現問題，要么親手毀掉一切再慢慢重建。總之，沒人能利用/var分區重啟設備就完全修正錯誤。（另外請別提什么打開文件句柄這類迂腐的蠢話——我想大家應該理解我的意思）

　　服務器重啟前請做完你該做的工作

　　在大多數情況下，不進行重啟是極其重要的，因為系統中能夠幫助我們修復問題的關鍵性內容在重啟前是一定存在的，但在重啟后卻未必還在。重啟之后問題絕對會再次出現，然而一旦解決方案隨重啟行為而煙消云散，那么故障本身就陷入了無解的死循環中。除非有人決定不進行重啟，而是嘗試找出問題的根源。遺憾的是，能做了這種明智選擇的人實在少之又少。實際情況是：一根小小的故障內存條就能給系統正常運行與設備啟動狀態帶來極大的麻煩。而這個時候，對癥下藥才是上策，一味重啟只會帶來額外的損失。

　　因此，今后大家在面對問題時，如果有某個家伙說什么“嘿，不如先重啟一下看看”，不妨直接給他兩個大嘴巴。重啟當然是方案之一，但在實施重啟前請務必確保我們已經采取了一切能夠想到的處理措施；畢竟節省下來的都是咱們自己的時間跟精力嘛。

JNDI 是什么

　　JNDI是 Java 命名與目錄接口（Java Naming and Directory Interface），在J2EE規范中是重要的規范之一，不少專家認為，沒有透徹理解JNDI的意義和作用，就沒有真正掌握J2EE特別是EJB的知識。

　　那么，JNDI到底起什么作用？

　　要了解JNDI的作用，我們可以從“如果不用JNDI我們怎樣做？用了JNDI后我們又將怎樣做？”這個問題來探討。

　　沒有JNDI的做法：

　　程序員開發時，知道要開發訪問MySQL數據庫的應用，于是將一個對 MySQL JDBC 驅動程序類的引用進行了編碼，并通過使用適當的 JDBC URL 連接到數據庫。

　　就像以下代碼這樣：

　　這是傳統的做法，也是以前非Java程序員（如Delphi、VB等）常見的做法。這種做法一般在小規模的開發過程中不會產生問題，只要程序員熟悉Java語言、了解JDBC技術和MySQL，可以很快開發出相應的應用程序。

　　沒有JNDI的做法存在的問題：

　　1、數據庫服務器名稱MyDBServer 、用戶名和口令都可能需要改變，由此引發JDBC URL需要修改；

　　2、數據庫可能改用別的產品，如改用DB2或者Oracle，引發JDBC驅動程序包和類名需要修改；

　　3、隨著實際使用終端的增加，原配置的連接池參數可能需要調整；

　　4、......

　　解決辦法：

　　程序員應該不需要關心“具體的數據庫后臺是什么？JDBC驅動程序是什么？JDBC URL格式是什么？訪問數據庫的用戶名和口令是什么？”等等這些問題，程序員編寫的程序應該沒有對 JDBC 驅動程序的引用，沒有服務器名稱，沒有用戶名稱或口令 —— 甚至沒有數據庫池或連接管理。而是把這些問題交給J2EE容器來配置和管理，程序員只需要對這些配置和管理進行引用即可。

　　由此，就有了JNDI。

　　用了JNDI之后的做法：

　　首先，在在J2EE容器中配置JNDI參數，定義一個數據源，也就是JDBC引用參數，給這個數據源設置一個名稱；然后，在程序中，通過數據源名稱引用數據源從而訪問后臺數據庫。

　數據庫是存放數據、經常是那些高敏感度數據的寶庫，因此它也毫無疑問的是合規檢查程序的重點區域。幾乎所有的企業合規都會對哪些人、能在什么時間、訪問什么數據庫作出規定，并且需要一個專職人員來管理這些權限。本文，我們將討論針對數據庫合規的基本數據庫安全要求，如PCI DSS和HIPAA，以及為了遵守合規要求用于管理數據庫權限和維護的最佳實踐。

　　最常見的五大企業核心數據庫環境是：1、微軟的SQL Server數據庫；2、IBM的DB2數據庫；3、MySQL數據庫；4、Oracle數據庫；5、Postgres數據庫。這些數據庫在首次實施安裝時都能夠恰當地配置、加固、保護及鎖定。真正的挑戰是理解那些實際上需要到位的重要組件。這不只是對數據庫本身，還有容納操作系統和數據庫的服務器。

　　PCI DSS當前對于數據庫要求有下述明確的控制措施：

　　◆ 對訪問任意數據庫的所有用戶進行認證。

　　◆ 所有用戶訪問任何數據庫時，用戶的查詢和操作（例如移動、拷貝和刪除）只能通過編程性事務（例如存儲過程）。

　　◆ 數據庫和應用的配置設置為只限于給DBA（數據庫管理員）的直接用戶訪問或是查詢。

　　◆ 對于數據庫應用和相關的應用ID，應用ID只能被應用使用，而不能被單獨的用戶或是其它進程使用。

　　就HIPAA法案來說，上述的措施沒有作為HIPAA合規要求的內容特別寫出來，但是應當看作是用于合規遵從的最佳安全控制組合，并且最終有助于滿足HIPAA中安全條款的需要。具體來說，HIPAA的規定條款如下：

　　◆ 確保所有新建、接收、維護或是傳輸中的電子個人健康信息（e-PHI）的保密性、完整性和可用性。

　　◆ 辨識和防范那些對信息的安全性或完整性來說合理的、可預見的威脅。

　　◆ 防范那些合理的、可預見的、不允許的濫用或是泄漏；并且

　　◆ 確保他們所有員工的合規性。

　　此外，除了滿足像PCI DSS這樣的合規要求外，下述是應該考慮的最佳實踐、可用來確保上面列出的所有數據庫環境的安全。

　　就運行數據庫的主機的操作系統來說，以下的最佳實踐應該到位：

　　1、系統管理員和其他相關的IT人員應該擁有充分的知識、技能并理解所有關鍵操作系統的安全要求。

　　2、當部署操作系統到受管理的服務環境中時，應采用行業領先的配置標準和配套的內部文檔。

　　3、在操作系統上應該只啟用那些必需的和安全的服務、協議、守護進程和其它必要的功能。

　　4、操作系統上所有不需要的功能和不安全的服務及協議應該有效地禁用。