网站被黑了，怎么知道如何被黑的？

说人话：被黑了就要知道为什么被黑了，怎么被黑的，不能这么不明不白。

主体思路

溯源的过程当中的时候除开相关的技术手段之外，首先还是需要确认一个整体的思路。对异常点进行一个整体的分析并根据实际环境给出几种可能的方案，这样处理起问题相对就可以游刃有余心里有谱，手上就不慌了。

常规出现的、容易被用户感知的异常点举例如下：

1. 网页被篡改、被挂上了黑链、web文件丢失等

2. 数据库被篡改、web系统运行异常影响可用性、web用户密码被篡改等

3. 主机出现运行异常反应卡顿、文件被加密、主机系统出现其他用户等

4. 主机流量层出现大量异常流量

根据用户现场的情况往往还需要做一些信息收集的工作

比如，出现异常的时间点(非常重要)、异常服务器的主要业务情况、大致的一个网络拓扑是不是在DMZ区、是否可以公网访问、开放了那些端口、是否有打补丁、使用了怎么样的一个web技术、最近是否做过什么变更、有没有什么安全设备之类的。

根据收集到的信息，往往可以得出了几种可能。

一个web服务器公网可以访问出现了被挂黑链的事件使用了s2框架，那么初步可以怀疑是s2-045 s2-046之类的命令执行漏洞了；

如果一台公网服务器没有安装补丁又没有防火墙防护，administrator的密码为P@sswrod那么有很大的可能性是被暴力破解成功；

后面的工作主要就是收集各种资料证明这一猜想即可。

web系统

上次自己部署了一个web系统在VPS上面，后面看了一下access日志基本上每天都有好多的web系统扫描事件，路径探测的、EXP扫描的、文件遍历的什么都有筛选起来特别头疼。

一般web类的安全事件在web日志当中一般都能发现一些端倪，清除日志这种事情毕竟不是每个黑客都会干。

常见几个中间件的日志如下：

1. apache的日志路径一般配置在httpd.conf的目录下或者位于/var/log/http

2. IIS的日志默认在系统目录下的Logfiles下的目录当中

3. tomcat 一般位于tomcat安装目录下的一个logs文件夹下面

4. Nginx日志一般配置在nginx.conf或者vhost的conf文件中

日志一般以日期命名，方便后续审计与安全人员进行分析。

工欲善其事必先利其器，一般日志量都比较大。互联网上还是有很多的日志检测工具，个人不是很喜欢用，主要工具还是notepad++ 和Sublime Text跟进收集的信息，比如时间点这种情况，对时间点前后的请求日志进行分析，一般都都能发现一些异常。

为了方便的识别一些日志，github也有很多开源项目有专门去日志中找安全相关攻击的、或者是统计的。因为现在很多扫描器也比较多，一检查往往也会发现很多无效的攻击，筛选起来反而感觉更麻烦。

推荐一个小工具：web-log-parser为开源的分析web日志工具，采用python语言开发，具有灵活的日志格式配置。优秀的项目比较多，萝卜青菜各有所爱自己喜欢较好，实在不行就自己定义好规则搞一个。

连接如下：https://github.com/JeffXue/web-log-parser

在处理一些访问访问、网页更改的时候、上传路径、源IP之类的信息都能够较好的收集。通过对一些关键路径的识别，结合一定的信息往往都能定位到入口点。

常见的一些入口点举例如下：

1. 一些CMS的EXP，比如Discuz Empire Spring 之类的一些命令执行、权限绕过逻辑漏洞等因为比较通用，网上很多都是公开的所以涉及面相对较广。

2. 
   

3. 编辑器的上传漏洞，比如知名的FCK编辑器、UEditor之类。

4. 功能性上传过滤不严格，比如头像上传资料上传界面一些过滤严格导致的上传漏洞。

5. 
   

6. Web系统的弱口令问题 admin账户、或者是tomcat的manager用户弱口令 、Axis2弱口令用户、Openfire弱口令等等

同时web系统往往容易存在一些webshell的情况，经常在一些上传目录里面找到一些webshell、明明是个JSP的网页还出现了一个php的一句话。

一般需要重点关注一下。推荐用D盾对web系统的目录进行扫描。

扫描出来的webshell时间上传时间、文件创建时间、文件修改时间往往准确性都比较高，一般不会去更改这个时间，用来在日志当中排查就相对容易的多。

主机系统

以前一直觉得一些蠕虫病毒都挺逗的很多传播方法居然只是依靠暴力破解和MS17-010之类的漏洞传播，感觉波及面应该比较小后面才发现这个方法简单粗暴反而最有效。

对于Linux平台相对安全性偏高一些，常见的几个病毒如XorDDOS、DDG、XNote系列的普遍也是依靠暴力破解进行传播，溯源的过程中也重点考虑暴力破解。

常用的一些日志举例如下：

/var/log/auth.log 包含系统授权信息，包括用户登录和使用的权限机制等信息/var/log/lastlog    记录登录的用户，可以使用命令lastlog查看/var/log/secure    记录大多数应用输入的账号与密码，登录成功与否/var/log/cron      记录crontab命令是否被正确的执行

grep,sed,sort,awk几个命令灵活运用、关注Accepted、Failed password 、invalid特殊关键字一般也能轻松发现一些端倪如下：

经常一些攻击者忘记清除日志，就很方便能查看详细了。一个history命令，黑客的操作就一目了然。

当然了一些脚本执行完了之后往往最后会清除日志比如下面这样的往往就加大了难度，日志被清除了往往就更显得异常了。

可以重点看一下还剩下那些日志、或者关注一下网络层面是不是还有其他的安全设备可以在流量层进行溯源分析的。

源于Linux一切皆文件与开源的特性，在溯源的过程中也有好处也有坏处，rootkit就是最麻烦的一件事情了。

由于系统一些常用的命令明文都已经被更改和替换，此系统已经变得完全不可信，在排查溯源的过程中往往不容易发觉对安全服务的人员就有较高的技术要求了。

Windows平台下面的溯源就相对容易一些当然主要还是依靠windows的日志一般用 eventvwr命令打开事件查看器。

默认分为三类：l应用程序、安全、性统 以evt文件形式存储在%systemroot%\system32\config目录

合理使用筛选器往往可以帮助我们更好的排查日志，比如怀疑是暴力破解入侵的筛选事件ID == 4625审核失败的日志，后续通过对时间的排查、以及源IP地址、类型与请求的频率进行分析来判断是否是来源于内网的暴力破解

通过系统内部的日志来判断是否是恶意进程的运行状态

通过对logontype的数值确认就可以确认到底是通过什么协议进行暴力破解成功的。

相对的数值关系如下：

local WINDOWS_RDP_INTERACTIVE = "2"local WINDOWS_RDP_UNLOCK = "7"local WINDOWS_RDP_REMOTEINTERACTIVE = "10"local WINDOWS_SMB_NETWORK = "3"

如下图就是一个典型的SMB的认证失败情况：

Windows系统的补丁相对重要一些，一些关键的补丁没有打很容易遭受到攻击成功的事件。

重点就关注一些常见的比如ms17-010 ms08-067 ms16-032等安全补丁都是内网渗透常用的攻击包。

可以通过sysintemfo可以查看到当前系统当中已经安装的补丁。

此外windows下面还包括很多域控的安全日志，因为内容太多就不再展开叙述，溯源主要还是想还原攻击路径，通过windows日志搞明白访问关系攻击者的攻击链条，给用户一个交代就好。

其他常用系统

数据库系统也是攻击者入口点的一些重灾区，常见的比如msssql server由于数据往往在window环境下安装后具有较高的权限，一些用户经常安装完成之后也不会怎么去加固数据库，基于库站分离的原则很多mssql公网直接就可以访问访问控制策略比较弱，弱口令的问题尤为突出。

比如下对于mssql的sa用户暴力破解日志，里面也记录着客户端的IP地址如果没有配置相关的锁定策略在密码不够严格的情况下容易被攻陷。

攻击者爆破成功之后启动xp_shell往往就可以以高权限执行系统命令，拿到了一个windows的shell岂不是为所欲为。

Linux平台下面还有一个redis也很热门，就一个几年的默认安装后的未授权访问的问题却流传的相对广泛。

比如最近一段事件相对比较热门的DDG挖矿、WatchDog挖矿等病毒都主要利用redis未授权访问执行命令，从互联网拉取挖矿程序写入ssh的公钥等功能。

看见本地开放了6379端口的时候还是需要重点关注这个问题，多向用户咨询一下使用情况查看一下默认配置。

还有一些常用的系统比如mysql数据库暴力破解提权一套装、hadoop未授权访问漏洞、钓鱼邮件、破解软件后门、恶意的office宏、office的代码执行漏洞、邮箱缺陷、VPN配置缺陷等情况都可能是攻击者的入口点具体情况需要结合用户当前的情况具体进行排查。

总结

都说安全本质到最后就是人与人之间的一个较量，对于很多定向攻击的安全事件排查起来估计就比较有意思，主机端的日志被清除掉流量层面全程隧道通信就呵呵了。

站在攻防的角度从攻击者的思维模型去做应急，思考更多的攻击者可能的途径，经常利用的姿势、漏洞与常用的攻击手法再用数据去加以验证，不局限在已知漏洞中而放过其他的问题，如果能够做到积极主动且有预见性，就能更好地控制后果，说不过在过程中还能发现几个0day也算是意外之喜了。