1月25日至26日，在全球范围内发生了网络故障。从日本网络以及安全相关的邮件列表和安全产品开发商等提供的信息来看，其主要原因很可能就是恶意使用2002年7月发现的SQL Server 2000（美国微软开发的数据库管理系统）安全漏洞的蠕虫病毒。
说实话，笔者目前仍无法断言恶意使用SQL Server 2000安全漏洞的蠕虫病毒就是引发此次故障的唯一或者说是首要原因。但是，至少可以确定的是，在发生故障的时间段里在世界各地出现了数量异常的对SQL Server所使用的端口的访问（即攻击），而且上面所讲的蠕虫病毒（被称为SQL Slammer、Sapphire、SQLExp和SQLP1434等）也确实正在传播蔓延。
2001年出现的“红色代码”和“尼姆达”病毒曾使IIS（Internet Information Server/Services）的安全性受到了广泛关注。但是也许会不少读者认为“难道SQL Server的安全漏洞真会受到攻击?”。即便是注意到IIS的用户（管理员）也很可能并没有特别注意SQL Server。
笔者希望没有使用SQL Server的用户也绝不要认为此次的事件“事不关己”。即便不是公开的服务器，能够由互联网访问的机器也可能会随时受到攻击。而且一旦受到蠕虫病毒的攻击，受损失的不只是自己的机器。有可能使整个互联网陷入危机之中。
让我们回忆一下2002年11月发生的对互联网路由DNS服务器的攻击。因互联网上的脆弱机器而影响网络正常通信的事件已经在我们身边发生过了。而且，此次发生的损失更为严重的事件极有可能也同样是众多脆弱机器被用作了攻击的帮凶。
不仅为了自己，而且为了所有互联网用户，也必须消除安全漏洞。此次虽说是SQL Server 2000偶然成了攻击目标，但也可以说是针对所有软件的。因此必须以此次蠕虫病毒事件为教训，努力提高每台机器的安全水平。
没有吸取过去的教训
作为以SQL Server为攻击目标的蠕虫病毒，有的蠕虫病毒利用在默认条件下没有设置密码的“sa”帐户传播感染。这种蠕虫病毒曾经“流行”于2001年11月及2002年5月。不过如果在sa帐户中设置密码，就能够防止这种蠕虫病毒，而没有必要安装SQL Server的安全漏洞补丁程序。
但是此次肆虐的蠕虫病毒则恶意使用SQL Server中的缓存溢出安全漏洞。即便是在sa帐户中设置了密码的SQL Server机器，如果没有安装补丁程序也会受到攻击。
在恶意使用sa帐户的蠕虫病毒出现时，不单要设置密码，“由于SQL Server也会成为攻击对象，因此要及时安装补丁程序”，或者“利用防火墙全部关闭SQL Server所使用的端口”--如果所有的用户都这么想，并且采用了相应对策，也许就不会导致此次危机的发生。
另外，此次的蠕虫病毒与攻击IIS的“红色代码”病毒非常相似。就是恶意使用已经公开了其补丁程序的安全漏洞进行感染。而且，由于只是在内存中运行（即常驻内存）而不在受感染的机器上生成文件，因此无法利用防病毒软件进行检测。
虽然“红色代码”及后来发现的“尼姆达”病毒使得在IIS服务器中安装补丁程序的重要性得以被大家重视，但是如果所有用户都能意识到“不仅是Web服务器，其他服务器（服务）也有可能成为攻击对象。在SQL Server中也应及时安装补丁程序”，也许就不会造成这么大的损失。
可见，过去出现的蠕虫病毒并没有使人们引以为戒。
曾被“预言”到的严重事态
有的读者对以SQL Server的安全漏洞为攻击目标的蠕虫病毒发生蔓延感到非常意外，但此次劫难其实已经早有预料。2002年7月，微软相继公开了SQL Server中的严重安全漏洞，美国CERT/CC也发出了警告。当然，其中就包括有此次蠕虫病毒所恶意使用的“（MS02-039）Buffer Overruns in SQL Server 2000 Resolution Service Could Enable Code Execution（SQL Server 2000解析服务的缓冲器的溢出，可能导致被执行任意代码）的脆弱性”这一安全漏洞。
务必吸取此次的“教训”
根据部分邮件列表公开的信息，1月25日晚此次的蠕虫病毒活动情况逐渐减弱。对UDP 1434端口的攻击（访问）正在减少。但是我们仍旧不能掉以轻心。为了以防万一，务必吸取此次的教训，防止再次发生此类事件。
首先，SQL Server用户当然必须采取相应对策。就像此次发作的蠕虫病毒所证明的那样，今后我们必须做好SQL Server会与IIS一样成为攻击对象的准备。因此只是消除此次的蠕虫病毒所攻击的“（MS02-039）Buffer Overruns in SQL Server 2000 Resolution Service Could Enable Code Execution的脆弱性”这一安全漏洞还不够。必须安装SQL Server所用的最新累积补丁程序“（MS02-061）SQL Server Web任务存在权限提升漏洞”、或者包含MS02-061补丁程序的“SQL Server 2000 Service Pack 3（SP3）”，消除目前所发现的所有安全漏洞。
不仅是受此次的蠕虫病毒影响的SQL Server 2000／SQL Server Desktop Engine（MSDE）2000，还必须消除SQL Server其他版本的安全漏洞。另外，有时即便用户本身没有意识到，其他产品也可能正在使用SQL Server/MSDE。由于此种情况当然也会受到安全漏洞的影响，因此安装补丁程序是不可缺少的。日本微软的网页上详细地刊登了有可能使用SQL Server/MSDE的产品。
然而，问题在于此。如果只是在SQL Server中安装补丁程序，就不能说是吸取了此次蠕虫病毒的教训。只有当人们认为“除SQL Server以外，今后其它软件也有可能受到攻击”，并对其他软件――尤其是服务器软件采取安全对策时，才算是真正汲取了此次的教训。凡是无法安装补丁程序或者不知道最新版本的服务器软件（服务）都应该关闭。尽管读者也许已经听腻了，但笔者还是要说应该只运行那些真正需要的服务。因为只有需要的服务，才能够进行充分的管理。
基于防火墙等的访问控制也同样如此。只打开那些真正需要的端口。虽说此次受到攻击的是UDP 1434端口，但如果只是关闭该端口并没有多大的意义。如果攻击其他端口，就会再次受到攻击。也许同样是已经听腻的套话，但首先是关闭所有的端口，然后仅仅打开所必须的端口。
需要注意的是即便关闭了端口，也并不是就可以不安装补丁程序。因为不仅有可能受到内部用户的故意攻击，而且还有可能在无意识的情况下感染到蠕虫病毒。就像“尼姆达”蠕虫病毒事件中所表明的那样，我们不知道蠕虫病毒会从哪里侵入到机器中。尽管网络“入口”处的守护工作很重要，但是还必须提高每一台机器的安全性。
另外，还必须采用发送过滤措施。就像前面所讲的那样，无论防守多么坚固，蠕虫病毒都可能通过RAS和移动机器潜入到单位的网络中。为了避免本单位成为“攻击者”，必须对向外发送的信息采取限制（关闭端口）。
正如此次蠕虫病毒泛滥一样，“攻击者”站点甚至有可能影响网络的正常通信。要想使用互联网，第一个要考虑的就是不要成为“攻击者”，因此必须采取万全之策。
此次事件仍存疑点
最后请允许笔者介绍一下此次事件的疑点。此次事件不可否认的是出现了对UDP 1434端口的大量攻击（访问），因此以SQL Server为攻击目标的蠕虫病毒确实是其原因之一。但是笔者的疑问是为什么能够产生如此巨大的损失呢？
像“红色代码”和“尼姆达”那样，以对外公开的Web服务器为攻击目标的蠕虫病毒所造成的损失波及面非常广，这倒是可以理解。但是此次的蠕虫病毒侵入过程是通过UDP1434端口进行的。难道将UDP 1434端口打开的单位就那么多？另外，此次感染的机器并不太多，难道就因为是能够产生巨大信息量的蠕虫病毒，所以就造成了各媒体所报道的那样巨大的损失吗？会不会还有其他原因呢？
为了更好地吸取此次教训，今后笔者将进行更为详细的调查。（记者：胜村 幸博）
[注]“蠕虫”病毒是指进行自我繁殖，并自动向通过网络连接的机器传播感染的独立程序。传播感染时，绝大多数情况上都是恶意使用机器上运行的软件所存在的安全漏洞。1988年11月“流行”、并致使当时的互联网瘫痪的“Morris Worm”以及于2001年7月造成巨大损失的“红色代码”等就是其中的代表。而普通病毒（计算机病毒）则具有“感染其他文件和程序”以及“要起动病毒，就需要用户进行‘运行病毒文件’的操作”等特点，与蠕虫病毒是有区别的。但是近年来由于不感染其他文件而单独运行的病毒以及恶意使用IE浏览器的安全漏洞并自动运行的病毒已经出现，因此两者的界线已经越来越模糊。不仅如此，还出现了具有普通病毒和蠕虫病毒两种特点的“尼姆达”之类的病毒（蠕虫）。因此很多场合把包括蠕虫病毒的、给用户造成损失的所有程序统称为病毒。另外，尽管被严格地区分为病毒，但有时也会将具有蠕虫性质的病毒（比如，通过邮件等向其他机器发送自身的复制品，进行传播的病毒）称为“蠕虫型病毒”。
