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、操作系统上所有不需要的功能和不安全的服务及协议应该有效地禁用。