《高性能Linux服务器构建实战:系统安全、故障排查、自动化运维与集群架构》——1.6 服务器遭受攻击后的处理过程

简介:

本节书摘来自华章计算机《高性能Linux服务器构建实战:系统安全、故障排查、自动化运维与集群架构》一书中的第1章,第1.6节,作者:高俊峰著, 更多章节内容可以访问云栖社区“华章计算机”公众号查看。

1.6 服务器遭受攻击后的处理过程

安全总是相对的,再安全的服务器也有可能遭受到攻击。作为一名安全运维人员,要把握的原则是:尽量做好系统安全防护,修复所有已知的危险行为,同时,在系统遭受攻击后能够迅速有效地处理攻击行为,最大限度地降低攻击对系统产生的影响。
1.6.1 处理服务器遭受攻击的一般思路
系统遭受攻击并不可怕,可怕的是面对攻击束手无策,下面就详细介绍下在服务器遭受攻击后的一般处理思路。
1 . 切断网络
所有的攻击都来自于网络,因此,在得知系统正遭受黑客的攻击后,首先要做的就是断开服务器的网络连接,这样除了能切断攻击源之外,也能保护服务器所在网络的其他主机。
2 . 查找攻击源
可以通过分析系统日志或登录日志文件,查看可疑信息,同时也要查看系统都打开了哪些端口,运行哪些进程,并通过这些进程分析哪些是可疑的程序。这个过程要根据经验和综合判断能力进行追查和分析。后面的章节会详细介绍这个过程的处理思路。
3 . 分析入侵原因和途径
既然系统遭到入侵,那么原因是多方面的,可能是系统漏洞,也可能是程序漏洞,一定要查清楚是哪个原因导致的,并且还要查清楚遭到攻击的途径,找到攻击源,因为只有知道了遭受攻击的原因和途径,才能在删除攻击源的同时进行漏洞的修复。
4 . 备份用户数据
在服务器遭受攻击后,需要立刻备份服务器上的用户数据,同时也要查看这些数据中是否隐藏着攻击源。如果攻击源在用户数据中,一定要彻底删除,然后将用户数据备份到一个安全的地方。
5 . 重新安装系统
永远不要认为自己能彻底清除攻击源,因为没有人能比黑客更了解攻击程序,在服务器遭到攻击后,最安全也最简单的方法就是重新安装系统,因为大部分攻击程序都会依附在系统文件或者内核中,所以重新安装系统才能彻底清除攻击源。
6 . 修复程序或系统漏洞
在发现系统漏洞或者应用程序漏洞后,首先要做的就是修复系统漏洞或者更改程序bug,只有将程序的漏洞修复完毕才能正式在服务器上运行。
7 . 恢复数据和连接网络
将备份的数据重新复制到新安装的服务器上,然后开启服务,最后将服务器的网络连接开启,对外提供服务。
1.6.2 检查并锁定可疑用户
在发现服务器遭受攻击后,首先要切断网络连接,但是在有些情况下,比如无法马上切断网络连接时,就必须登录系统查看是否有可疑用户,如果有可疑用户登录了系统,那么需要马上将这个用户锁定,然后中断此用户的远程连接。
1 . 登录系统查看可疑用户
通过root用户登录,然后执行“w”命令即可列出所有登录过系统的用户,如图1-11所示。

image

通过这个输出可以检查是否有可疑或者不熟悉的用户登录,同时还可以根据用户名以及用户登录的源地址和它们正在运行的进程来判断他们是否为非法用户。
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以清除自己行踪,但还是会在此文件中露出蛛丝马迹的。
1.6.3 查看系统日志
查看系统日志是查找攻击源最好的方法,可查看的系统日志有/var/log/messages、/var/log/secure等,这两个日志文件可以记录软件的运行状态以及远程用户的登录状态,还可以查看每个用户目录下的.bash_history文件,特别是/root目录下的.bash_history文件,这个文件中记录着用户执行的所有历史命令。
1.6.4 检查并关闭系统可疑进程
检查可疑进程的命令很多,例如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

有些时候,攻击者的程序隐藏很深,例如rootkit后门程序,在这种情况下ps、top、netstat等命令也可能已经被替换,如果再通过系统自身的命令去检查可疑进程就变得毫不可信,此时,就需要借助于第三方工具来检查系统可疑程序,例如前面介绍过的chkrootkit、RKHunter等工具,通过这些工具可以很方便地发现系统被替换或篡改的程序。
1.6.5 检查文件系统的完好性
检查文件属性是否发生变化是验证文件系统完好性最简单、最直接的方法,例如,可以检查被入侵服务器上/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这两个工具来完成,上面介绍的命令或工具可以作为辅助或者补充。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
4天前
|
敏捷开发 监控 数据管理
构建高效微服务架构的五大关键策略
【4月更文挑战第20天】在当今软件开发领域,微服务架构已经成为一种流行的设计模式,它允许开发团队以灵活、可扩展的方式构建应用程序。本文将探讨构建高效微服务架构的五大关键策略,包括服务划分、通信机制、数据管理、安全性考虑以及监控与日志。这些策略对于确保系统的可靠性、可维护性和性能至关重要。
|
4天前
|
消息中间件 监控 持续交付
构建高效微服务架构:后端开发的进阶之路
【4月更文挑战第20天】 随着现代软件开发的复杂性日益增加,传统的单体应用已难以满足快速迭代和灵活部署的需求。微服务架构作为一种新兴的分布式系统设计方式,以其独立部署、易于扩展和维护的特点,成为解决这一问题的关键。本文将深入探讨微服务的核心概念、设计原则以及在后端开发实践中如何构建一个高效的微服务架构。我们将从服务划分、通信机制、数据一致性、服务发现与注册等方面入手,提供一系列实用的策略和建议,帮助开发者优化后端系统的性能和可维护性。
|
1天前
|
监控 安全 Linux
Linux系统之安装ServerBee服务器监控工具
【4月更文挑战第22天】Linux系统之安装ServerBee服务器监控工具
32 2
|
1天前
|
监控 API 持续交付
构建高效微服务架构:后端开发的新趋势
【4月更文挑战第23天】 随着现代软件开发实践的不断演进,微服务架构已经成为企业追求敏捷、可扩展和弹性解决方案的首选。本文深入探讨了如何构建一个高效的微服务架构,涵盖了关键的设计原则、技术选型以及实践建议。通过分析微服务的独立性、分布式特性和容错机制,我们将揭示如何利用容器化、服务网格和API网关等技术手段,来优化后端系统的可维护性和性能。文章旨在为后端开发人员提供一套全面的指南,以应对不断变化的业务需求和技术挑战。
|
3天前
|
Cloud Native API 持续交付
构建未来:云原生架构在企业数字化转型中的关键作用
【4月更文挑战第21天】 随着企业加速其数字化转型的步伐,云原生技术已迅速成为推动创新和实现敏捷性的基石。本文深入探讨了云原生架构的核心组件,包括容器化、微服务、持续集成/持续部署(CI/CD)以及声明式API。通过分析这些技术的协同效应,揭示了它们如何共同促进系统的可伸缩性、弹性和维护性,进而支持企业在不断变化的市场环境中保持竞争力。
10 1
|
3天前
|
敏捷开发 Cloud Native 持续交付
构建未来:云原生架构的进化之路
【4月更文挑战第21天】随着数字化转型的深入,企业对IT基础设施的要求日益提高。云原生技术以其灵活性、可扩展性和敏捷性成为推动创新的重要力量。本文将探讨云原生架构的核心组件,分析其如何助力企业实现快速迭代和高效运营,并预测云原生技术的发展趋势。
|
5天前
|
网络协议 安全 Linux
IDEA通过内网穿透实现固定公网地址远程SSH连接本地Linux服务器
IDEA通过内网穿透实现固定公网地址远程SSH连接本地Linux服务器
|
6天前
|
监控 持续交付 开发者
构建高效微服务架构:后端开发的新趋势
【4月更文挑战第18天】在数字化转型的浪潮中,微服务架构已成为企业提升系统灵活性、加速产品迭代的关键。此文深入探讨了构建高效微服务架构的实践方法,包括服务划分原则、容器化部署、持续集成/持续部署(CI/CD)流程以及监控与日志管理等关键技术点。通过分析具体案例,揭示了微服务在提高开发效率、降低维护成本及促进团队协作方面的显著优势。
|
6天前
|
Cloud Native 持续交付 云计算
构建未来:云原生架构在企业数字化转型中的关键作用
【4月更文挑战第18天】 随着企业加速迈向数字化,云原生架构成为推动创新与效率的催化剂。本文深入探讨了云原生技术如何助力企业实现敏捷开发、自动化运维和无缝可扩展性,以及它如何塑造着云计算的未来。我们将通过具体案例分析,揭示云原生架构在处理复杂系统时的灵活性和可靠性,并展望其对业务连续性和安全性的积极影响。
13 1
|
9天前
|
Cloud Native 持续交付 API
构建未来:云原生架构在企业数字化转型中的关键作用
【4月更文挑战第15天】 随着企业加速其数字化转型的步伐,云原生架构已经成为推动创新和实现敏捷性的关键技术。本文深入探讨了云原生技术如何助力企业在竞争激烈的市场中保持领先地位,包括它的核心组件、实施策略以及面临的挑战。通过实际案例分析,我们揭示了企业如何利用云原生架构来优化资源使用、提高开发效率和加强系统的稳定性与安全性。