有史以来最牛的服务器反黑全集 网站服务器超级安全配置
2007-10-20 16:18:38 来源：PC235.COM 您有问题？请联系我们
方案一
1.打补丁
微软的作风就是三天一小补，五天一大补，漏洞太多，补一点就好一点，使用“开始-Windows Update" 然后把所有的补丁都装进去吧
2.删除默认共享
2.1删除IPC$共享
Win2k的缺省安装很容易被攻击者取得帐号列表，即使安装了最新的Service ack也是如此。在Win2k中有一个缺省共享IPC$，并且还有诸如admin$Content$nbsp;C$Content$nbsp;D$等等,而IPC$允许匿名用户（即未经登录的用户）访问，利用这个缺省共享可以取得用户列表。如何防范这东东，很简单在"管理工具\本地安全策略\安全设置\本地策略\安全选项"中的"对匿名连接的额外限制"可修改为"不允许枚举SAM帐号和共享"。就可以防止大部分此类连接，但是还没完，如果使用NetHacker只要使用一个存在的帐号就又可以顺利取得所有的帐号名称。所以，我们还需要另一种方法做后盾，
(1)：创建一个
至此下来，服务器已经可以很安全稳定的运行下去了，当然别忘了要一两天重启一下你的服务器，
SQL服务器安全设置
首先,关闭sql默认的1433(好象是这个吧) 就是把sql的TCP/IP协议删除就ok了,
删掉后就不能是用远程了 那总归少点事情吧
sa 设密码设的密码为数字加字母等, 不用我多说了吧
administrator 别忘了设密码
在tcp/ip协议里关掉所有的无用端口
本地连接状态 --属性--tcp/ip协议--高级--选项--tcp/ip筛选 --只允许 tcp端口
开80(网站端口)
开21(ftp端口--可开可不开)
55019(奇迹私服端口)
44405(奇迹私服端口)
以上是针对无路由的使用服务器直接对外的情况,
使用路由的情况见下
映射以下端口就OK了
开80(网站端口)
开21(ftp�
另外关闭一切ICMP的连接
我的服武器开的端口不是很多
UDP53---DNS
UDP8000 UDP4000---QQ
80----http
*****---mu
*****---mu
TCP5000 5050UDP5050 花生
可以说这些端口都是安全的 至少我这么认为
然后我的下一条规则就是禁止所有IP通讯和ICMP通讯
我做过测试的 我的是ADSL如果我不开DNS服务器的端口UDP53那么我的服务器都不能上网
这些是很简单的安全策略
用2ks的本地安全策略的IP安全策略就可以达到了
另外说一下冲击波的端口 冲击波病毒是利用了TCP135 TCP4444UDP69
这三个端口对你进行攻击的 关闭了这三个端口基本上冲击波就over了
其实不用刻意去关闭 因为最后一条规则一定要禁止所有IP通讯
至少现在是 当然系统的补丁是要全部打得
更改DS的端口来防止别人用GS连接你的DS
这个似乎是多余的 因为DS的两个端口也是对外屏蔽的
但是我也改了 呵呵
服务器做到以上的安全设置 基本上没什么问题的
其实防黑说容易也容易
我想没有那么多真正意义上的hack来搞你
他们没�
你立刻停止80服务
方案三
[讨论]被黑的朋友，我个人认为的私服比较安全的方案！
其实，看了很多朋友的被黑经历，我有一个最有效的方法，
那就是请大家使用路由器，因为硬件的安全漏洞要比软件小的多，最便宜的路由器也能使
一个顶级黑客耗费1/3的脑细胞和N小时的精力。
这是一个简单的道理，一个防黑客软件再强大，但他毕竟是建立在服务器的系统之上的
但路由器和硬件防火墙就不一样，它是独立的，绝大多数的黑客进攻到路由器就无能
为力了（真正能破硬件的，那就是世界级的黑客了，那是少之又少）这也是为什么电信
的防火墙是硬件的道理一样。
有一点大家要注意，用路由器，最好用端口影射，而不要用DMZ，因为DMZ不安全。
还有那个远程仓库编辑器的端口是1433，不开这个端口，所谓的黑客也就没办法了
其实只要你的注册网页没有后台，而你使用路由器，只影射44405，81，21这三个
端口，我想全中国几乎没有人能黑你的私服，还有你的数据库应该每天备份一次
或定时备份，我想即使被黑，也能在15分钟内恢复，就不会出现XX私服被戒灵那种
不够黑客资格的人渣黑了，搞的数据库也没有了。
方案四
1、ASP/SQL语句注入：在多都是利用网页没有对提交的数据进行过滤而直接带入数据库！
防：注入语句大多有如下字符：’ , % & = ; > < 来构成SQL语句！
注意：我们要作的是对写入数据库中的每一个字段都要作过滤！是每一个，千万不怕麻烦！提供如下过滤语句！
’****************************************************
if instr(accountname,"’")<>0 or instr(accountname,";")<>0 or instr(accountname,"&")<>0 or instr(accountname,">")<>0 or instr(accountname,",")<>0 or instr(accountname,"=")<>0 or instr(accountname,"%")<>0 then
response.write ""
response.end
end if
’****************************************************
把accountname改成需要过滤字段就行了！有多个字段就要多少个如上的判断语句！
2、异地表单提交！（某此人用来突破原网页的种种限制）
防：禁止异地表单提交！在你的数据库连接文件(conn.asp)加入如下判断语句！
****************************************************** 方案五
编写安全的ASP代码
发帖子的目的是为了大家讨论与研究。。。
ASP中数据库的安全是一个很严肃的问题。很多代码的编写者意识到了这类问题，并且小心翼翼地对他们认为有问题的地方做了补救，但常见的情况是要么没有穷尽所有的可疑地点，要么这种补救逻辑上有误。对于一个耐心且嗅觉灵敏的攻击者来说，这种意义上的补救措施和没有任何补救措施没有本质上区别。
下面罗列的是一些可能出现的问题：有些是常见易犯的错误，有些根本就是逻辑上有问题。看看你是不是也这样写过？对于攻击者而言，倒着看这些东西，应该对寻找漏洞有点帮助，更为完整一点的检测方法，请等我的关于黑/白盒分析和自动化测试文章。
一、令人疑惑的过滤方式
典型例子是不管不顾地对所有的输入变量都去掉单引号，或者是把单引号替换成合法的两个单引号，例如：
id = replace(request.querystring("id"), "", "")
str = replace(request("someinput"), "", "")
现在很明了的是，第一个做法很有可能是错误的。因为引起SQL Injection的不总是单引号，再扩大一点，引起问题的不是任何单独的符号，这样子的过滤，有些冤枉单引号了。正确的利用注入，重要的一点是闭合前面的一句SQL查询语句——往往是得先正确地闭合前面一个条件，因为我们可能会在同一句里面引入新的条件，补救措施只要破坏注入条件应该就可以了，但是考虑到其复杂性（下面会说），最好还是较为完整的限制一下输入的字符种类。
第二个看起来是没有什么问题的，但潜在的会带来一些隐患。这很容易给人造成的一个错觉是，我对输入的字符串已经很有效的做过处理了，以后使用没有什么问题。这句话没有错，对字符串来说这样做也是很正确的，但是他扮演了一个不光彩的角色，试想一下，如果过滤后的字符串放进了数据库，而后续的语句有直接拿出来使用的，这种对前面过滤的依赖性，是不是正确的呢？
也许较好的做法应该是，针对具体的情况来确定过滤的准则。
常见的输入变量有三种：数字，字符串还有集合。对于数字型的输入变量，简单调用一下判断函数即可，见得到的代码中，凡是检查了这类变量的，几乎都正确。对于字符串型的来说，基本上在插入到生成的SQL语句时，前后都有单引号，如果仅从破坏注入条件来看，把单引号替换成两个单引号应该问题不大。同理的，如果是一个字符串的集合，也可以简单的用这种方法。而如果是数字的集合，情况可能稍微麻烦一点，至少你得允许数字、逗号或许还有空格之类的符号在输入中正常出现，这样子的过滤规则可能显得复杂，不过你可以借鉴一下dvBBS6.1打过补丁后的版本，总的来说，对于已经发现的过滤漏洞而言，他们还是补得比较好的。
对于第二句话，至少现在不能说它说错的，我们留待后面解决。
二、获取的数据值得信赖吗？
其实这样子说范围显得有点大，一下子涉及到很多方面，一个例子一个例子地举来看好了。
首先是关于选择过滤数据的问题。一直以来，我们认为凡是用户输入的东西，都要经过适当的处理。没错，但真正的是否都做到呢？随便找个抓包的工具，比如Ethereal，看看在你用IE提交表单或者是打开连接的时候，都提交了什么。或者，简单一些，打开NetAnt编辑一个任务，在协议标签中，看看那个“自定义提交者”和“用户代理”的选项。
我想你已经明白了，对方可以自己定制的东西不仅仅是GET或POST过来的数据！如果所有的用户都规规矩矩地用浏览器，确实不用防备这么严，如果对方不这么老实，在取服务端变量或Cookie的时候可要小心了，没有任何人能够保证你获得的数据是合法的。对于Cookie而言，很多程序都出过问题，所以以前强调得比较多，至于另外的，关注的人可能比较少一点，但你是否看过或者写过这样的代码：
sql="ShowHOT_COM_inst_online_char 2,"&statuserid&","&membername&","&memberclass&","&Request.ServerVariables("REMOTE_HOST")&","&boardid&","&Request.ServerVariables("HTTP_USER_AGENT")&","&replace(stats,"","")&","&Request.ServerVariables("HTTP_X_FORWARDED_FOR")&","&UserGroupID&","&actCome&","&userhidden&","&userid&""
Request.ServerVariables("HTTP_USER_AGENT")就是你在NetAnt中看到的用户代理选项，也就是说你可以伪造，同样可以伪造的还有Request.ServerVariables("HTTP_REFERER")，也就是你在NetAnt中看到的提交者选项等等。在做一些项目的时候，很有可能要将这一类的变量添加入数据库，这时候要千万小心，这个地方的忽略，引起的后果和其他类型变量未过滤导致的后果是一样的。
在Google上搜索Referer和Request.ServerVariables两个关键字，还可以看到很多有问题的写法，或者去看看五月份左右的关于动网论坛入侵的文章，也许你的理解会更加深刻一点。
然后是一个隐藏得稍微深一点的问题，不是用户的直接输入要不要过滤？
这就回到了我们前面留下的那个问题，单引号换成两个单引号的潜在威胁。在第二次构造SQL语句的时候，倘若数据是从数据库里面直接去取出来用的，多数情况下人们会认为前面已经处理过的东西看起来似乎并没有必要再处理，或者干脆就是没有意识到应该处理。这是极其错误的！从两个方面来看，首先你入库的时候对提交数据中的单引号处理，仅仅是保证了单次SQL语句构造的正确性，并没有一劳永逸地解决问题；再说了，后面取出数据用的时候，对数据安全性检查的依赖并没有得到保证，因为这种依赖关系没有传递下来，而且依赖关系本身还不是可传的。
就replace(request("someinput"), "", "")而言，它的不安定性在于这种过滤方式只是一种妥协，换句话说只是在有限的范围内掩盖了可能出现的问题，而没有永久性的处理掉。它还有一个讨厌的地方在于给人一种错觉，似乎是处理过的数据已经安全了，容易让后继的代码编写者产生虚幻的安全感。对这两个弱点，不是*换一个写法就能解决的，因为如果你把单引号干脆去掉，又会引来另外一个问题，输入数据中确实有需要而且正确的单引号怎么办？从一开始我就说，单引号本身是无罪的，过滤它只是一种解决手段而已，所以我们还是就这样写吧，不过要在后继的部分加强一下检查。
这一类的问题，如果依然用动网论坛做例子，我建议看一下六月八号的漏洞文章。
还有就是过滤器的位置，这个掺杂了逻辑问题在内的复杂问题。
我曾经非常惊奇地发现乔客论坛对外散布的版本中一段让人觉得不可思议的问题代码，如果你比较感兴趣的话，翻翻gallery.asp就能看到一个特定的动作序列（action=flash_view），绕过了所有对id的检查。
其实说起来，这一类代码不太可能有太复杂的逻辑结构，对代码进行审查的时候，进行所有的分支覆盖是可以手工完成的，只要稍微想想就会发现对变量的检查是否能够有效地到达你的目的地——生成SQL语句的地方。
关于过滤器的位置，如果要深入下去，马上就会出来一些让人眼花缭乱的东西，中间的分析很麻烦而且很形式化，虽然确实有算法可以保证位置选取的正确性，但是我想这里还是给出一些结论性的东西吧。倘若你很有兴趣，我想你可以来信和我交流。
过滤的位置，取决于两个方面：你获得变量的来源，以及你需要保证到的生成SQL语句的位置。前面一个，不论是来自于直接还是间接输入，先想想可能的输入字符；对于后面一个，你要保证无论程序运行情况怎样，经过了过滤语句的流程一定会经过你需要保证到的生成SQL语句的位置（保证其是有效过滤语句的后向必经节点）。如果你不很清楚流程的判断，我的建议是if中仅仅判断，if嵌套间不要有多余的东西，过滤语句后紧接生成SQL语句。
再回到前面提到的潜在问题，我们终于可以在这里解决了：在取出数据后依然首先进行判断。因为根据前面说的，这一种间接输入依然有可能出现危险。
说到这里，插一句另类的过滤位置问题：不要把对输入的过滤放到客户端解决，那是可以绕过的！谁能保证你的VBScript/javascript能起作用，如果别人直接用NC或者一个不支持脚本的浏览器呢？
上述两个大的方面，以软件测试的目光来认识，显然是没有穷尽所有的分支所导致。在使用对方提交的数据之前，先做一个对方所有可能进入字符的分析列表，然后就每一种输入分支情况进行类型的审核，这是每个代码编写者都应该做的事情。这是一件很简单的事情，因为只是类型上的审核还好，碰上语义的问题就麻烦了……
三、类型正确意味着放行？
涉及到语义的问题，要是可能的话，我选择最好还是避开。
譬如对于一个整型数字，你输入的确实是一个整型，通过了过滤器，潜在的问题是你的输入内容上合法吗，或者根本就不应该从你这里获得信息？很多年前就有人提出来，有些注册的模块存在问题：它里面的id是通过一个type=hidden掩盖后隐式提交的，但是我在第一步建立了用户，第二步仍就有可能通过提交内容不合法的id来修改他人的信息。这种异类的问题都是非常难发现，而且几乎都只有*经验而不是某一个具体的算法来处理。我们在联系一下前面的，连起来想想或许能够更加清楚，对于输入的字符串，感觉上没有过滤也不会有错，因为比较数字之类集合来说，字符串所能容纳的几乎是全部可能输入的集合。事实上，常见的是没有过滤造成单引号的错误匹配，进而导致了SQL Injection。严格说起来，这也是一个语义上的问题，不过对于这样子的特殊情况而言，可以通过处理输入中的单引号来保证语义的某种程度上的正确。所以我也一再强调，单引号本身是无罪的，不过是背了语义的黑锅而已。
令人遗憾的是，如果是整型数据出了语义上的问题，没有什么东西可以替语义背黑锅了，所以没有了一个一定程度上通用的解决方案。不过也不要悲观，前面就已经说过，能避开就避开，釜底抽薪不要让可能有语义问题的变量作为输入好了。
仅仅考虑数据库安全的话，所有有威胁的语义问题都几乎出在对数据库的操作上，那么，我们只要注意update/insert等语句就可以了，如果考虑数据内容的安全性的话，select也得算上。一般来说，特别关注的是生成的where后面的条件语句，总觉得条件的语义应该是由服务器端决定的，而不是说用户的输入是什么就是什么。我的建议是对于所有的可能出现语义问题的整型变量，最好都是Session，当然，没有进行非常深入的研究，或许有人能够提出像对付字符串的语义问题一样的有效方法也说不一定。不过话又说回来，在语义层面上看对字符串的过滤，不能证明它不安全，但是更重要的没有人能够证明它安全，只是大家现在用着没有问题，也就默认了罢了。
若要深入的分析语义，也会突然冒出一大堆奇怪的东西，所以还是就此打住吧，真切的希望同行之间能够多一些这方面的交流！
前面说的也许更多地会用在一些对既有代码的补救上，如果是从头开始构架一个软件的话，上面的仅仅是设计上一些参考。所有的漏洞都是源于设计上的缺陷，一个好的软件应该被证明其模型是正确的，这很难但是可以做到。如果你一开始就证明了软件的正确性，我想也不会有漏子可以给别人钻了。
方案六
防范SQL指令植入式攻击
发帖子的目的是为了大家讨论与研究。。。
什么是SQL 指令植入式攻击？
在设计或者维护 Web 网站时，你也许担心它们会受到某些卑鄙用户的恶意攻击。的确，如今的 Web 网站开发者们针对其站点所在操作系统平台或Web 服务器的安全性而展开的讨论实在太多了。不错，IIS 服务器的安全漏洞可能招致恶意攻击；但你的安全检查清单不应该仅仅有 IIS 安全性这一条。有些代码，它们通常是专门为数据驱动(data-driven) 的 Web 网站而设计的，实际上往往同其它 IIS 漏洞一样存在严重的安全隐患。这些潜伏于代码中的安全隐患就有可能被称为“SQL 指令植入式攻击” (SQL injection) 的手段所利用而导致服务器受到攻击。
SQL 指令植入式攻击技术使得攻击者能够利用 Web 应用程序中某些疏于防范的输入机会动态生成特殊的 SQL 指令语句。举一个常见的例子：
某 Web 网站采用表单来收集访问者的用户名和密码以确认他有足够权限访问某些保密信息，然后该表单被发送到 Web 服务器进行处理。接下来，服务器端的ASP 脚本根据表单提供的信息生成 SQL 指令语句提交到 SQL 服务器，并通过分析 SQL 服务器的返回结果来判断该用户名/密码组合是否有效。
为了实现这样的功能，Web 程序员可能会设计两个页面：一个 HTML 页面 (Login.htm) 用于登录，另一个ASP 页面 (ExecLogin.asp) 用于验证用户权限(即向数据库查询用户名/密码组合是否存在)。
乍一看，ExecLogin.asp 的代码似乎没有任何安全漏洞，因为用户如果不给出有效的用户名/密码组合就无法登录。然而，这段代码偏偏不安全，而且它正是SQL 指令植入式攻击的理想目标。具体而言，设计者把用户的输入直接用于构建SQL 指令，从而使攻击者能够自行决定即将被执行的 SQL 指令。例如：攻击者可能会在表单的用户名或密码栏中输入包含“ or ”和“=” 等特殊字符。于是，提交给数据库的 SQL 指令就可能是：
代码:Select * FROM tblUsers Where Username= or = and Password = or =
这样，SQL 服务器将返回 tblUsers 表格中的所有记录，而 ASP 脚本将会因此而误认为攻击者的输入符合 tblUsers 表格中的第一条记录，从而允许攻击者以该用户的名义登入网站。
SQL 指令植入式攻击还有另一种形式，它发生在 ASP 服务器根据 querystring 参数动态生成网页时。这里有一个例子，此 ASP 页面从 URL 中提取出 querystring 参数中的 ID 值，然后根据 ID 值动态生成后继页面：
代码:
在一般情况下，此 ASP 脚本能够显示具有特定 ID 值的文章的内容，而 ID 值是由 URL 中的 querystring 参数指定的。例如：当URL为 http://www.example.com/Article.asp?ID=1055 时，ASP 就会根据 ID 为 1055 的文章提供的内容生成页面。
如同前述登录页面的例子一样，此段代码也向SQL 指令植入式攻击敞开了大门。某些恶意用户可能会把 querystring 中的文章 ID 值tou换为“0 or 1=1”等内容(也就是说，把 URL 换成 http://www.example.com/Article.asp?ID=0 or 1=1) 从而诱使 ASP 脚本生成不安全的 SQL 指令如：
代码:Select * FROM tblArticles Where ID=0 or 1=1
于是，数据库将会返回所有文章的内容。
当然了，本例服务器所受的攻击不一定会引起什么严重后果。可是，攻击者却可能变本加厉，比如用同样的手段发送 Delete 等 SQL 指令。这只需要简单地修改前述 URL 中的 querystring 参数就可以了！例如：任何人都可以通过 “http://www.example.com/Article.asp?ID=1055; Delete FROM tblArticles ” 之类的 URL 来访问 Web 网站。 SQL 指令植入式攻击的危害
SQL 指令植入式攻击可能引起的危害取决于该网站的软件环境和配置。当 Web 服务器以操作员(dbo)的身份访问数据库时，利用SQL 指令植入式攻击就可能删除所有表格、创建新表格，等等。当服务器以超级用户 (sa) 的身份访问数据库时，利用SQL 指令植入式攻击就可能控制整个 SQL 服务器；在某些配置下攻击者甚至可以自行创建用户帐号以完全操纵数据库所在的 Windows 服务器。
杜绝SQL 指令植入式攻击
杜绝SQL 指令植入式攻击的第一步就是采用各种安全手段jian控来自 ASP request 对象 (Request 、 Request.QueryString 、 Request.Form 、 Request.Cookies 和 Request.ServerVariables) 的用户输入，以确保 SQL 指令的可*性。具体的安全手段根据你的 DBMS 而异，下面给出的都是基于 MS SQL Server的例子。
在前述登录页面的例子中，脚本期望得到的两个输入变量 (txtUserName 和 txtPassword)均为字符串类型。无论用户在哪个参数中插入单引号，他都可能让数据库执行单引号中的 SQL 指令。为了杜绝此类SQL 指令植入式攻击，我们可以借助 Replace 函数剔除单引号，比如：
代码:p_strUsername = Replace(Request.Form("txtUsername"), "", "") p_strPassword = Replace(Request.Form("txtPassword"), "", "")
在第二个例子中，脚本期望的输入变量是长整型变量 (ID) 。用户可以通过在 ID 参数中插入特殊字符来运行不安全的 SQL 指令。为了为了杜绝此类SQL 指令植入式攻击，我们只需要借助 CLng 函数限制 ID 值为长整型变量，比如：
代码:p_lngID = CLng(Request("ID"))
当用户试图在 ID 中包含特殊字符时，CLng 就会产生一个错误。
为了进一步减少SQL 指令植入式攻击的危胁，请务必清除客户端错误信息文本中的所有技术资料。某些错误信息往往泄露了技术细节，从而让攻击者可以看出服务器的安全漏洞所在。这里指的错误信息不但包括应用程序生成的消息框，还包括来自 IIS 的出错提示。为此，你可以禁止由 IIS 发送的详细错误信息，而改用自定义的出错页面。(关于创建自定义的出错页面的更多信息，请务必参阅 《Creating Custom ASP Error Pages》。)
最后，为了减轻SQL 指令植入式攻击的危害，请限制 Web 应用程序所用的数据库访问帐号权限。一般来说，应用程序没有必要以 dbo 或者 sa 的身份访问数据库。记住，给它的权限越少，你的网站越安全！你还可以考虑分别给每个需要访问数据库的对象分配只拥有必需权限的帐号，以分散安全漏洞。例如：同是前端用户界面，当用于公共场所时就比用于具有本地内容管理机制的平台时更加需要严格限制数据库访问权限。
相关资料
在 Internet 上有许许多多关于本话题的有用资源。我想下列连接可能会对你有所帮助：
* SQL Injection FAQ (http://www.sqlsecurity.com/)
* Advanced SQL Injection White Paper (http://www.nextgenss.com/research.html)
* Preventing SQL Injection (http://www.owasp.org/asac/input_validation/sql.shtml)
有史以来最牛的服务器反黑全集 网站服务器超级安全配置文章结束
更多内容请看 菜鸟学堂 > > 服务器配置专题