安全总是相对的，再安全的服务器也有可能遭受到攻击。作为一个安全运维人员，要把握的原则是：尽量做好系统安全防护，修复所有已知的危险行为，同时，在系统遭受攻击后能够迅速有效地处理攻击行为，最大限度地降低攻击对系统产生的影响。
一、处理服务器遭受攻击的一般思路
系统遭受攻击并不可怕，可怕的是面对攻击束手无策，下面就详细介绍下在服务器遭受攻击后的一般处理思路。
1.切断网络
所有的攻击都来自于网络，因此，在得知系统正遭受黑客的攻击后，首先要做的就是断开服务器的网络连接，这样除了能切断攻击源之外，也能保护服务器所在网络的其他主机。
2.查找攻击源
可以通过分析系统日志或登录日志文件，查看可疑信息，同时也要查看系统都打开了哪些端口，运行哪些进程，并通过这些进程分析哪些是可疑的程序。这个过程要根据经验和综合判断能力进行追查和分析。下面的章节会详细介绍这个过程的处理思路。
3.分析入侵原因和途径
既然系统遭到入侵，那么原因是多方面的，可能是系统漏洞，也可能是程序漏洞，一定要查清楚是哪个原因导致的，并且还要查清楚遭到攻击的途径，找到攻击源，因为只有知道了遭受攻击的原因和途径，才能删除攻击源同时进行漏洞的修复。
4.备份用户数据
在服务器遭受攻击后，需要立刻备份服务器上的用户数据，同时也要查看这些数据中是否隐藏着攻击源。如果攻击源在用户数据中，一定要彻底删除，然后将用户数据备份到一个安全的地方。
5.重新安装系统
永远不要认为自己能彻底清除攻击源，因为没有人能比黑客更了解攻击程序，在服务器遭到攻击后，最安全也最简单的方法就是重新安装系统，因为大部分攻击程序都会依附在系统文件或者内核中，所以重新安装系统才能彻底清除攻击源。
6.修复程序或系统漏洞
在发现系统漏洞或者应用程序漏洞后，首先要做的就是修复系统漏洞或者更改程序bug，因为只有将程序的漏洞修复完毕才能正式在服务器上运行。
7.恢复数据和连接网络
将备份的数据重新复制到新安装的服务器上，然后开启服务，最后将服务器开启网络连接，对外提供服务。
二、检查并锁定可疑用户
当发现服务器遭受攻击后，首先要切断网络连接，但是在有些情况下，比如无法马上切断网络连接时，就必须登录系统查看是否有可疑用户，如果有可疑用户登录了系统，那么需要马上将这个用户锁定，然后中断此用户的远程连接。
1.登录系统查看可疑用户
通过root用户登录，然后执行"w"命令即可列出所有登录过系统的用户，如下图所示。
通过这个输出可以检查是否有可疑或者不熟悉的用户登录，同时还可以根据用户名以及用户登录的源地址和它们正在运行的进程来判断他们是否为非法用户。
2.锁定可疑用户
一旦发现可疑用户，就要马上将其锁定，例如上面执行"w"命令后发现nobody用户应该是个可疑用户（因为nobody默认情况下是没有登录权限的），于是首先锁定此用户，执行如下操作：
[root@server ~]# passwd -l nobody
锁定之后，有可能此用户还处于登录状态，于是还要将此用户踢下线，根据上面"w"命令的输出，即可获得此用户登录进行的pid值，操作如下：
[root@server ~]# ps -ef|grep @pts/3
531 6051 6049 0 19:23 ? 00:00:00 sshd: nobody@pts/3
[root@server ~]# kill -9 6051
这样就将可疑用户nobody从线上踢下去了。如果此用户再次试图登录它已经无法登录了。
3.通过last命令查看用户登录事件
last命令记录着所有用户登录系统的日志，可以用来查找非授权用户的登录事件，而last命令的输出结果来源于/var/log/wtmp文件，稍有经验的入侵者都会删掉/var/log/wtmp以清除自己行踪，但是还是会露出蛛丝马迹在此文件中的。
三、查看系统日志
查看系统日志是查找攻击源最好的方法，可查的系统日志有/var/log/messages、/var/log/secure等，这两个日志文件可以记录软件的运行状态以及远程用户的登录状态，还可以查看每个用户目录下的.bash_history文件，特别是/root目录下的.bash_history文件，这个文件中记录着用户执行的所有历史命令。
四、检查并关闭系统可疑进程
检查可疑进程的命令很多，例如ps、top等，但是有时候只知道进程的名称无法得知路径，此时可以通过如下命令查看：
首先通过pidof命令可以查找正在运行的进程PID，例如要查找sshd进程的PID，执行如下命令：
[root@server ~]# pidof sshd 13276 12942 4284
然后进入内存目录，查看对应PID目录下exe文件的信息：
[root@server ~]# ls -al /proc/13276/exe lrwxrwxrwx 1 root root 0 Oct 4 22:09 /proc/13276/exe -> /usr/sbin/sshd
这样就找到了进程对应的完整执行路径。如果还有查看文件的句柄，可以查看如下目录：
[root@server ~]# ls -al /proc/13276/fd
通过这种方式基本可以找到任何进程的完整执行信息，此外还有很多类似的命令可以帮助系统运维人员查找可疑进程。例如，可以通过指定端口或者tcp、udp协议找到进程PID，进而找到相关进程：
[root@server ~]# fuser -n tcp 111 111/tcp: 1579 [root@server ~]# fuser -n tcp 25 25/tcp: 2037 [root@server ~]# ps -ef|grep 2037 root 2037 1 0 Sep23 ? 00:00:05 /usr/libexec/postfix/master postfix 2046 2037 0 Sep23 ? 00:00:01 qmgr -l -t fifo -u postfix 9612 2037 0 20:34 ? 00:00:00 pickup -l -t fifo -u root 14927 12944 0 21:11 pts/1 00:00:00 grep 2037
在有些时候，攻击者的程序隐藏很深，例如rootkits后门程序，在这种情况下ps、top、netstat等命令也可能已经被替换，如果再通过系统自身的命令去检查可疑进程就变得毫不可信，此时，就需要借助于第三方工具来检查系统可疑程序，例如前面介绍过的chkrootkit、RKHunter等工具，通过这些工具可以很方便的发现系统被替换或篡改的程序。
五、检查文件系统的完好性
检查文件属性是否发生变化是验证文件系统完好性最简单、最直接的方法，例如可以检查被入侵服务器上/bin/ls文件的大小是否与正常系统上此文件的大小相同，以验证文件是否被替换，但是这种方法比较低级。此时可以借助于Linux下rpm这个工具来完成验证，操作如下：
[root@server ~]# rpm -Va ....L... c /etc/pam.d/system-auth S.5..... c /etc/security/limits.conf S.5....T c /etc/sysctl.conf S.5....T /etc/sgml/docbook-simple.cat S.5....T c /etc/login.defs S.5..... c /etc/openldap/ldap.conf S.5....T c /etc/sudoers ..5....T c /usr/lib64/security/classpath.security ....L... c /etc/pam.d/system-auth S.5..... c /etc/security/limits.conf S.5..... c /etc/ldap.conf S.5....T c /etc/ssh/sshd_config
对于输出中每个标记的含义介绍如下：
S 表示文件长度发生了变化
M 表示文件的访问权限或文件类型发生了变化
5 表示MD5校验和发生了变化
D 表示设备节点的属性发生了变化
L 表示文件的符号链接发生了变化
U 表示文件/子目录/设备节点的owner发生了变化
G 表示文件/子目录/设备节点的group发生了变化
T 表示文件最后一次的修改时间发生了变化
如果在输出结果中有"M"标记出现，那么对应的文件可能已经遭到篡改或替换，此时可以通过卸载这个rpm包重新安装来清除受攻击的文件。
不过这个命令有个局限性，那就是只能检查通过rpm包方式安装的所有文件，对于通过非rpm包方式安装的文件就无能为力了。同时，如果rpm工具也遭到替换，就不能通过这个方法了，此时可以从正常的系统上复制一个rpm工具进行检测。
对文件系统的检查也可以通过chkrootkit、RKHunter这两个工具来完成，关于chkrootkit、RKHunter工具的使用，下次将展开介绍。
5. SQL Server数据库性能监控 - 当前请求 对于在线运行的系统，当前数据库性能监控，通常监视以下几点：
(1) 是否有阻塞 (Blocking);
(2) 是否有等待 (Waiting)，阻塞就是锁 (Lock) 等待;
(3) 是否运行时间过长(Long running)；
(4) 是否有死锁 (Deadlock)；
sys.dm_exec_query_stats之类，等一些统计性的信息，通常不作为实时告警内容，而是在性能优化时，作为参考。
一.阻塞/等待/长时间运行
1. SQL Server 2005及以后版本检查
SELECT r.session_id ,r.blocking_session_id ,DB_Name(r.database_id) as database_name ,r.start_time ,r.total_elapsed_time ,r.[status] ,CASE WHEN r.blocking_session_id<> 0 THEN'Blocking' WHEN r.blocking_session_id= 0 AND r.wait_type is not null THEN 'Waiting' ELSE 'Long-running' END as slowness_type ,r.percent_complete ,r.command ,r.wait_type ,r.wait_time ,r.wait_resource ,r.last_wait_type ,r.cpu_time ,r.reads ,r.writes ,r.logical_reads ,t.[text] as executing_batch ,SUBSTRING(t.[text], r.statement_start_offset/2, (CASE WHENr.statement_end_offset =-1 THENDATALENGTH(t.[text]) --LEN(CONVERT(NVARCHAR(MAX),t.text)) * 2 ELSE r.statement_end_offset END - r.statement_start_offset )/2+ 1) as executing_sql ,bt.[text] as blocking_batch ,SUBSTRING(bt.[text], br.statement_start_offset/2, (CASE WHENbr.statement_end_offset = -1 THENDATALENGTH(bt.[text]) --LEN(CONVERT(NVARCHAR(MAX),bt.text)) * 2 ELSE br.statement_end_offset END - br.statement_start_offset )/2+ 1) as blocking_sql --,p.query_plan FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) as t CROSS APPLY sys.dm_exec_query_plan(r.plan_handle) as p LEFT JOIN sys.dm_exec_requests br ON r.blocking_session_id =br.session_id OUTER APPLY sys.dm_exec_sql_text(br.session_id) as bt WHERE r.session_id > 50 and r.session_id <> @@SPID AND r.total_elapsed_time >30 * 60 * 1000 ORDER BY r.total_elapsed_timeDESC;
以上脚本返回运行超过30分钟的语句，需要注意的是：
(1) 如果返回执行计划，会让以上脚本变慢很多，可以不返回，在收到告警后检查语句时，再去查看执行计划；
(2) 显示TEXT，比如: xp_cmdshell这样的语句，start_offset, end_offset都为0，截取的 text是空白，只有看TEXT才知道是什么语句；还有就是有时需要知道这个请求来自哪个batch或者存储过程；
(3) 有时显示TEXT还不够，还以xp_cmdshell为例，需要dbcc inputbuffer才能看到完整的sql语句；另外已运行结束但还没有commit/rollback的事务，在requests中已经没有了，也需要借用dbcc inputbuffer来查看sql 语句；
dbcc inputbuffer(@@SPID)
(4) SQL Agent作业，在这里会被一并检查，也可以通过msdb..sysjobactivity另行检查；
select b.name, * from msdb..sysjobactivity a inner join msdb.dbo.sysjobs b on a.job_id = b.job_id where b.name like '%backup%'
2. SQL Server 2000沿用过来的方法
select p.dbid, p.spid, p.blocked, p.waittime/1000.0/60.0 as wait_minutes, ISNULL(DATEDIFF(MI, p.last_batch, GETDATE()), 0)elapsed_minutes, p.last_batch, p.status, p.program_name, (select [text] FROM::fn_get_sql(p.sql_handle)) sql_text from master..sysprocesses p where spid > 50 and spid <> @@SPID AND(status <> 'sleeping' AND ISNULL(DATEDIFF(MI, p.last_batch, GETDATE()), 0) > 30)
以上脚本返回运行超过30分钟的语句，需要注意的是：
sysprocesses中把connection/session/request信息三者合一，其中没有请求开始的具体时间，通过last_batch监视运行时长并不准确。测试如下：
(1) 通过ISQL连接到SQL Server，如果当前连接没发起过任何请求，last_batch的时间为 1900-01-01 00:00:00，在此连接上发起请求时，通过last_batch计算当前请求运行时长不准确；
(2) 在SQL Analyzer/SSMS中新建查询窗口，未发起任何查询时，last_batch与login_time一样，而非1900-01-01 00:00:00，通过last_batch计算当前请求运行时长不准确；或者当前窗口发起的请求已结束，但窗口/连接未关闭，则在此连接上再次发起请求，last_batch为上次请求结束的时间，通过last_batch计算当前请求运行时长也不准确；
(3) SQL Agent作业运行结束后，会把在sysprocesses的连接关闭，下次运行时重新建立连接，新建连接中last_batch等于login_time，通过last_batch计算作业运行时长准确；
作为一个老的方法，估且不再去深究，不过用sysprocesses来监视阻塞/等待还是没有问题的，另外作业的运行时长也是可以监视的，脚本改动后如下：
select p.dbid, p.spid, p.blocked, p.waittime/1000.0/60.0 as wait_minutes, ISNULL(DATEDIFF(MI, p.last_batch, GETDATE()), 0)elapsed_minutes, p.last_batch, p.status, p.program_name, (select [text] FROM::fn_get_sql(p.sql_handle)) sql_text from master..sysprocesses p where spid > 50 and spid <> @@SPID and( (p.program_name like 'SQLAgent - TSQL JobStep (Job %' AND ISNULL(DATEDIFF(MI, p.last_batch, GETDATE()), 0) > 30) or (p.blocked <> 0 and p.waittime/1000.0/60.0 > 30) )
这样一来，只剩下未被阻塞但长时间运行的sql请求未被监视到。如果一定要全面监视的话，可以选择开启跟踪，进而分析跟踪文件。
二.死锁
死锁的监控可以通过监视SQL Server的ERRORLOG来实现，不过需要事先打开死锁的跟踪标记。脚本如下：
--sql server 2000 dbcc traceon(1204,-1) --sql server 2005 + dbcc traceon(1222,-1)
这样发生死锁时，死锁详细信息就会被写入ERRORLOG，检查deadlock或者victim关键字即可进行监控。
小结
各个语句的运行时长/基线并不一样，通常不好设置统一的阀值，有时会借用第三方工具针对不同的请求设置不同的时长阀值并告警，所以在数据库这层大多告警阻塞即可，大致步骤如下 ：
(1) 部署数据库邮件；
(2) 部署作业：定时检查阻塞，发邮件告警。
本文出自 "SQL Server DBA" 博客，请务必保留此出处http://qianzhang.blog.51cto.com/317608/1556389
没有评论:
发表评论