Java 语言是当前互联网应用最为广泛的语言，作为一名 Java 程序猿，当业务相对比较稳定之后平常工作除了 coding 之外，大部分时间（70%~80%）是会用来排查突发或者周期性的线上问题。

由于业务应用 bug(本身或引入第三方库)、环境原因、硬件问题等原因，Java 线上服务出现故障 / 问题几乎不可避免。例如，常见的现象包括部分请求超时、用户明显感受到系统发生卡顿等等。

尽快线上问题从系统表象来看非常明显，但排查深究其发生的原因还是比较困难的，因此对开发测试或者是运维的同学产生了许多的困扰。

排查定位线上问题是具有一定技巧或者说是经验规律的，排查者如果对业务系统了解得越深入，那么相对来说定位也会容易一些。

不管怎么说，掌握 Java 服务线上问题排查思路并能够熟练排查问题常用工具 / 命令 / 平台是每一个 Java 程序猿进阶必须掌握的实战技能。

笔者依据自己的 工作经验总结出一套基本的线上问题排查流程，同学们可以根据自己的实际工作情况进行归纳总结。

二、Java 服务常见线上问题

所有 Java 服务的线上问题从系统表象来看归结起来总共有四方面：CPU、内存、磁盘、网络。例如 CPU 使用率峰值突然飚高、内存溢出 (泄露)、磁盘满了、网络流量异常、FullGC 等等问题。

基于这些现象我们可以将线上问题分成两大类: 系统异常、业务服务异常。

常见的业务服务异常现象包括: PV 量过高、服务调用耗时异常、线程死锁、多线程并发问题、频繁进行 Full GC、异常安全攻击扫描等。

我们一般会采用排除法，从外部排查到内部排查的方式来定位线上服务问题。

• 首先我们要排除其他进程 (除主进程之外) 可能引起的故障问题；

• 然后排除业务应用可能引起的故障问题；

• 可以考虑是否为运营商或者云服务提供商所引起的故障。

1.1 系统异常排查流程

1.2 业务应用排查流程

CPU 是系统重要的监控指标，能够分析系统的整体运行状况。监控指标一般包括运行队列、CPU 使用率和上下文切换等。

top 命令是 Linux 下常用的 CPU 性能分析工具 , 能够实时显示系统中各个进程的资源占用状况 , 常用于服务端性能分析。

top 命令显示了各个进程 CPU 使用情况 , 一般 CPU 使用率从高到低排序展示输出。其中 Load Average 显示最近 1 分钟、5 分钟和 15 分钟的系统平均负载，上图各值为 2.46，1.96，1.99。

我们一般会关注 CPU 使用率最高的进程，正常情况下就是我们的应用主进程。第七行以下：各进程的状态监控。

内存是排查线上问题的重要参考依据，内存问题很多时候是引起 CPU 使用率较高的见解因素。

系统内存：free 是显示的当前内存的使用 ,-m 的意思是 M 字节来显示内容。

vmstat 是 Virtual Meomory Statistics（虚拟内存统计）的缩写 , 是实时系统监控工具。该命令通过使用 knlist 子程序和 /dev/kmen 伪设备驱动器访问这些数据，输出信息直接打印在屏幕。

使用 vmstat 2 10  -t 命令，查看 io 的情况 (第一个参数是采样的时间间隔数单位是秒，第二个参数是采样的次数)。

r 表示运行队列 (就是说多少个进程真的分配到 CPU),b 表示阻塞的进程。    
swpd 虚拟内存已使用的大小，如果大于 0，表示你的机器物理内存不足了，如果不是程序内存泄露的原因，那么你该升级内存了或者把耗内存的任务迁移到其他机器。
free   空闲的物理内存的大小，我的机器内存总共 8G，剩余 3415M。
buff   Linux/Unix 系统是用来存储，目录里面有什么内容，权限等的缓存，我本机大概占用 300 多 M
si 列表示由磁盘调入内存，也就是内存进入内存交换区的数量；
so 列表示由内存调入磁盘，也就是内存交换区进入内存的数量
一般情况下，si、so 的值都为 0，如果 si、so 的值长期不为 0，则表示系统内存不足，需要考虑是否增加系统内存。    
bi 从块设备读入数据的总量（读磁盘）（每秒 kb）
bo 块设备写入数据的总量（写磁盘）（每秒 kb）
随机磁盘读写的时候，这两个值越大 ((超出 1024k)，能看到 cpu 在 IO 等待的值也会越大 这里设置的 bi+bo 参考值为 1000，如果超过 1000，而且 wa 值比较大，则表示系统磁盘 IO 性能瓶颈。
in 每秒 CPU 的中断次数，包括时间中断

strace：strace 常用来跟踪进程执行时的系统调用和所接收的信号。

在 JDK 安装目录的 bin 目录下默认提供了很多有价值的命令行工具。每个小工具体积基本都比较小，因为这些工具只是 jdk\lib\tools.jar 的简单封装。

其中，定位排查问题时最为常用命令包括:jps（进程）、jmap（内存）、jstack（线程）、jinfo(参数) 等。

• jps: 查询当前机器所有 JAVA 进程信息；

• jmap: 输出某个 java 进程内存情况 (如:产生那些对象及数量等)；

jps 用于输出当前用户启动的所有进程 ID，当线上发现故障或者问题时，能够利用 jps 快速定位对应的 Java 进程 ID。

当然，我们也可以使用 Linux 提供的查询进程状态命令，例如：

我们也能快速获取 tomcat 服务的进程 id。

以二进制输出档当前内存的堆情况，然后可以导入 MAT 等工具进行

jmap -heap pid   输出当前进程 JVM 堆新生代、老年代、持久代等请情况，GC 使用的算法等信息

jmap 可以查看 JVM 进程的内存分配与使用情况，使用 的 GC 算法等信息。

输出当前进程内存中所有对象实例数 (instances) 和大小 (bytes), 如果某个业务对象实例数和大小存在异常情况，可能存在内存泄露或者业务设计方面存在不合理之处。

-dump:formate=b,file= 以二进制输出当前内存的堆情况至相应的文件，然后可以结合 MAT 等内存分析工具深入分析当前内存情况。

当然，如果你决定手动 dump 内存时，dump 操作占据一定 CPU 时间片、内存资源、磁盘资源等，因此会带来一定的负面影响。

此外，dump 的文件可能比较大 , 一般我们可以考虑使用 zip 命令对文件进行压缩处理，这样在下载文件时能减少带宽的开销。

下载 dump 文件完成之后，由于 dump 文件较大可将 dump 文件备份至制定位置或者直接删除，以释放磁盘在这块的空间占用。

某 Java 进程 CPU 占用率高，我们想要定位到其中 CPU 占用率最高的线程。

MAT(Memory Analyzer Tool)，一个基于 Eclipse 的内存分析工具，是一个快速、功能丰富的 JAVA heap 分析工具，它可以帮助我们查找内存泄漏和减少内存消耗。

使用内存分析工具从众多的对象中进行分析，快速的计算出在内存中对象的占用大小，看看是谁阻止了垃圾收集器的回收工作，并可以通过报表直观的查看到可能造成这种结果的对象。

右侧的饼图显示当前快照中最大的对象。单击工具栏上的柱状图，可以查看当前堆的类信息，包括类的对象数量、浅堆 (Shallow heap)、深堆 (Retained Heap).

浅堆表示一个对象结构所占用内存的大小。深堆表示一个对象被回收后，可以真实释放的内存大小。

列出了堆中最大的对象，第二层级的节点表示当被第一层级的节点所引用到的对象，当第一层级对象被回收时，这些对象也将被回收。

这个工具可以帮助我们定位对象间的引用情况，垃圾回收时候的引用依赖关系

通过分析 Path to GC Roots 可以找出 JAVA 的内存泄露问题，当程序不在访问该对象时仍存在到该对象的引用路径。

Java 虚拟机 GC 日志是用于定位问题重要的日志信息，频繁的 GC 将导致应用吞吐量下降、响应时间增加，甚至导致服务不可用。

我们可以在 java 应用的启动参数中增加 -XX:+PrintGCDetails 可以输出 GC 的详细日志，例外还可以增加其他的辅助参数，如-Xloggc 制定 GC 日志文件地址。如果你的应用还没有开启该参数 , 下次重启时请加入该参数。

上图为线上某应用在平稳运行状态下的 GC 日志截图。

对新生代进行的GC，使用ParNew收集器，559782K是新生代回收前的大小,1000K是新生代回收后大小,629120K是当前新生代分配的内存总大小, 0.0135760 secs表示本次新生代回收耗时

初始标记 ：在这个阶段，需要虚拟机停顿正在执行的任务，官方的叫法 STW(Stop The Word)。这个过程从垃圾回收的 “ 根对象 “ 开始，只扫描到能够和 “ 根对象 “ 直接关联的对象，并作标记。

所以这个过程虽然暂停了整个 JVM，但是很快就完成了。

并发标记 ：这个阶段紧随初始标记阶段，在初始标记的基础上继续向下追溯标记。并发标记阶段，应用程序的线程和并发标记的线程并发执行，所以用户不会感受到停顿。

并发预清理 ：并发预清理阶段仍然是并发的。在这个阶段，虚拟机查找在执行并发标记阶段新进入老年代的对象 (可能会有一些对象从新生代晋升到老年代， 或者有一些对象被分配到老年代)。

通过重新扫描，减少下一个阶段 “ 重新标记 “ 的工作，因为下一个阶段会 Stop The World。

重新标记 ：这个阶段会暂停虚拟机，收集器线程扫描在 CMS 堆中剩余的对象。扫描从 “ 跟对象 “ 开始向下追溯，并处理对象关联。

并发清理 ：清理垃圾对象，这个阶段收集器线程和应用程序线程并发执行。

并发重置 ：这个阶段，重置 CMS 收集器的数据结构，等待下一次垃圾回收。

上图为线上某应用在进行 CMS GC 状态下的 GC 日志截图。

如果你已掌握 CMS 的垃圾收集过程，那么上面的 GC 日志你应该很容易就能看的懂，这里我就不详细展开解释说明了。

此外 CMS 进行垃圾回收时也有可能会发生失败的情况。

[prommotion failed：存活区内存不足，对象进入老年代，而此时老年代也仍然没有内存容纳对象，将导致一次 Full GC]

[内存吃紧，老年代长时间处于较满的状态]

业务日志除了关注系统异常与业务异常之外，还要关注服务执行耗时情况，耗时过长的服务调用如果没有熔断等机制，很容易导致应用性能下降或服务不可用，服务不可用很容易导致雪崩。

上面是某一接口的调用情况，虽然大部分调用没有发生异常，但是执行耗时相对比较长。

找出调用耗时大于 3 位数的 dao 方法，把 3 改成 4 就是大于 4 位数

互联网应用目前几乎采用分布式架构，但不限于服务框架、消息中间件、分布式缓存、分布式存储等等。

那么这些应用日志如何聚合起来进行分析呢 ?

首先，你需要一套分布式链路调用跟踪系统，通过在系统线程上线文间透传 traceId 和 rpcId，将所有日志进行聚合，例如淘宝的鹰眼，spring cloud zipkin 等等。

CPU 使用率高问题定位

按照定位流程首先排除了系统层面的问题。

利用 top -Hp 6814 输出进程 ID 为 6814 的所有线程 CPU 使用率情况，发现某个线程使用率比较高，有些异常。

输出的日志表明该线程一直处于与 mysql I/O 状态：

如下图所示，点击 MAT 的支配树可以发现存在某个超大对象数组，实例对象数目多大 30 多万个。

经过分析发现数组中每一个对象都是核心业务对象，我们的业务系统有一个定时任务线程会访问数据库某张业务表的所有记录。

然后加载至内存然后进行处理因此内存吃紧，导致 CPU 突然飙升。发现该问题后，已对该方案进行重新设计。

　　今天给大家体验MySQL的优化实战，助你高薪之路顺畅。

　　1.2 优化的哲学

　　优化有风险，涉足需谨慎

　　1.2.1 优化可能带来的问题

　　优化不总是对一个单纯的环境进行，还很可能是一个复杂的已投产的系统。

　　优化手段本来就有很大的风险，只不过你没能力意识到和预见到！

　　对于优化来说解决问题而带来的问题,控制在可接受的范围内才是有成果。

　　保持现状或出现更差的情况都是失败！

　　1.2.2 优化的需求

　　稳定性和业务可持续性,通常比性能更重要！

　　优化不可避免涉及到变更，变更就有风险！

　　优化使性能变好，维持和变差是等概率事件！

　　切记优化,应该是各部门协同，共同参与的工作，任何单一部门都不能对数据库进行优化！

　　所以优化工作,是由业务需要驱使的！！！

　　1.2.3 优化由谁参与

　　在进行数据库优化时，应由数据库管理员、业务部门代表、应用程序架构师、应用程序设计人员、应用程序开发人员、硬件及系统管理员、存储管理员等，业务相关人员共同参与。

　　在数据库优化上有两个主要方面：即安全与性能。

　　性能 ---> 数据的高性能访问

　　1.3.2 优化的范围有哪些

　　OS内核参数和网络问题

　　这个应用适不适合用MySQL

　　数据库结构(物理&逻辑)

　　说明：不管是在，设计系统，定位问题还是优化，都可以按照这个顺序执行。

　　数据库优化维度有四个:

　　硬件、系统配置、数据库表结构、SQL及索引

　　优化成本:硬件>系统配置>数据库表结构>SQL及索引

　　优化效果:硬件<系统配置<数据库表结构<SQL及索引

　　1.4 优化工具有啥？

　　1.4.1 数据库层面

　　不常用但好用的工具

　　1.4.2 数据库层面问题解决思路

　　一般应急调优的思路：

　　针对突然的业务办理卡顿，无法进行正常的业务处理！需要立马解决的场景！

　　针对业务周期性的卡顿，例如在每天10-11点业务特别慢，但是还能够使用，过了这段时间就好了。

　　1、查看slowlog，分析slowlog，分析出查询慢的语句。

　　2、按照一定优先级，进行一个一个的排查所有慢语句。

　　3、分析top sql，进行explain调试，查看语句执行时间。

　　4、调整索引或语句本身。

　　IO设备（磁盘、网络）

　　Procs：r显示有多少进程正在等待CPU时间。b显示处于不可中断的休眠的进程数量。在等待I/O

　　Memory：swpd显示被交换到磁盘的数据块的数量。未被使用的数据块，用户缓冲数据块，用于操作系统的数据块的数量

　　Swap：操作系统每秒从磁盘上交换到内存和从内存交换到磁盘的数据块的数量。s1和s0最好是0

　　Io：每秒从设备中读入b1的写入到设备b0的数据块的数量。反映了磁盘I/O

　　System：显示了每秒发生中断的数量(in)和上下文交换(cs)的数量

　　Cpu：显示用于运行用户代码，系统代码，空闲，等待I/O的CPU时间

　　tps：该设备每秒的传输次数。“一次传输”意思是“一次I/O请求”。多个逻辑请求可能会被合并为“一次I/O请求”。

　　iops ：硬件出厂的时候，厂家定义的一个每秒最大的IO次数,"一次传输"请求的大小是未知的。

　　kB_read：读取的总数据量；

　　kB_wrtn：写入的总数量数据量；这些单位都为Kilobytes。

　　1.4.4 系统层面问题解决办法

　　你认为到底负载高好，还是低好呢？

　　在实际的生产中，一般认为 cpu只要不超过90%都没什么问题 。

　　当然不排除下面这些特殊情况：

　　问题一：cpu负载高，IO负载低

　　IO出问题了（磁盘到临界了、raid设计不好、raid降级、锁、在单位时间内tps过高）

　　tps过高: 大量的小数据IO、大量的全表扫描

　　问题二：IO负载高，cpu负载低

　　大量小的IO 写操作：

　　IO/PS,磁盘的一个定值，硬件出厂的时候，厂家定义的一个每秒最大的IO次数。

　　大量大的IO 写操作

　　SQL问题的几率比较大

　　问题三：IO和cpu负载都很高

　　硬件不够了或sql存在问题

　　明确优化目标、性能和安全的折中、防患未然

　　根据数据库类型，主机CPU选择、内存容量选择、磁盘选择

　　平衡内存和磁盘资源

　　随机的I/O和顺序的I/O

　　cpu的两个关键因素：核数、主频

　　根据不同的业务类型进行选择：

　　cpu密集型：计算比较多，OLTP 主频很高的cpu、核数还要多

　　IO密集型：查询比较，OLAP 核数要多，主频不一定高的

　　OLAP类型数据库，需要更多内存，和数据获取量级有关。

　　OLTP类型数据一般内存是cpu核心数量的2倍到4倍，没有最佳实践。

　　根据存储数据种类的不同，选择不同的存储设备

　　对与操作系统来讲，不需要太特殊的选择，最好做好冗余（raid1）（ssd、sas 、sata）

　　raid卡：主机raid卡选择：

　　实现操作系统磁盘的冗余（raid1）

　　平衡内存和磁盘资源

　　随机的I/O和顺序的I/O

　　使用流量支持更高的网络设备（交换机、路由器、网线、网卡、HBA卡）

　　注意：以上这些规划应该在初始设计系统时就应该考虑好。

　　1.5.3 服务器硬件优化

　　2、自带管理设备：远程控制卡（FENCE设备：ipmi ilo idarc），开关机、硬件监控。

　　3、第三方的监控软件、设备（snmp、agent）对物理设施进行监控

　　基本不需要调整，在硬件选择方面下功夫即可。

　　基本不需要调整，在硬件选择方面下功夫即可。

　　MySQL尽量避免使用swap。阿里云的服务器中默认swap为0

　　这个参数决定了Linux是倾向于使用swap，还是倾向于释放文件系统cache。在内存紧张的情况下，数值越低越倾向于释放文件系统cache。当然，这个参数只能减少使用swap的概率，并不能避免Linux使用swap。

　　修改MySQL的配置参数innodb_flush_method，开启O_DIRECT模式。这种情况下，InnoDB的buffer pool会直接绕过文件系统cache来访问磁盘，但是redo log依旧会使用文件系统cache。值得注意的是，Redo log是覆写模式的，即使使用了文件系统的cache，也不会占用太多

　　1.5.5 系统参数调整

　　Linux系统内核参数优化

　　用户限制参数（mysql可以不设置以下配置）

　　业务应用和数据库应用独立,防火墙：iptables、selinux等其他无用服务(关闭)：

　　安装图形界面的服务器不要启动图形界面 runlevel 3,另外，思考将来我们的业务是否真的需要MySQL，还是使用其他种类的数据库。用数据库的最高境界就是不用数据库。

　　1.6 数据库优化

　　执行计划、索引、SQL改写

　　高可用架构、高性能架构、分库分表

　　1.6.1 数据库参数优化

　　实例整体（高级优化，扩展）

　　连接层（基础优化）

　　设置合理的连接客户和连接方式

　　OLAP类型数据库,需要重点加大此内存缓存.

　　但是一般不会超过GB.

　　对于经常被修改的数据，缓存会立马失效。

　　我们可以实用内存数据库（redis、memecache），替代他的功能。

　　1.6.2 存储引擎层（innodb基础优化参数）

　　为什么某些人会一直比你优秀，是因为他本身就很优秀还一直在持续努力变得更优秀，而你是不是还在满足于现状内心在窃喜! 关注我，私信回复我“666"或者“Java架构"获取免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用自己每一分每一秒的时间来学习提升自己，不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！

   上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-7)，我们将立即处理。

遇到服务器被黑，很多人会采用拔网线、封 iptables或者关掉所有服务的方式应急，但如果是线上服务器就不能立即采用任何影响业务的手段了，需要根据服务器业务情况分类处理。

下面我们看一个标准的服务器安全应急影响应该怎么做，也算是笔者从事安全事件应急近 6年以来的一些经验之谈，借此抛砖引玉，希望大神们不吝赐教。

如上图，将服务器安全应急响应流程分为如下 8个环节：

发现安全事件（核实）现场保护服务器保护影响范围评估在线分析数据备份深入分析事件报告整理接下来我们将每个环节分解，看看需要如何断开异常连接、排查入侵源头、避免二次入侵等。

核实信息（运维/安全人员）

根据安全事件通知源的不同，分为两种：

外界通知：和报告人核实信息，确认服务器/系统是否被入侵。现在很多企业有自己的 SRC（安全响应中心），在此之前更多的是依赖某云。这种情况入侵的核实一般是安全工程师完成。

自行发现：根据服务器的异常或故障判断，比如对外发送大规模流量或者系统负载异常高等，这种情况一般是运维工程师发现并核实的。

我们很多人看过大陆的电视剧《重案六组》，每次接到刑事案件，刑警们第一时间就是封锁现场、保存现场原状。

同样道理，安全事件发生现场，跟刑事案件发生现场一样，需要保存第一现场重要信息，方便后面入侵检测和取证。

相关信息采集命令如下：

攻击者登陆情况（截图）

相关信息采集命令如下：

查看当前登录用户：w或 who -a

服务器保护（运维/机房）

这里的现场保护和服务器保护是两个不同的环节，前者注重取证，后者注重环境隔离。

核实机器被入侵后，应当尽快将机器保护起来，避免被二次入侵或者当成跳板扩大攻击面。

此时，为保护服务器和业务，避免服务器被攻击者继续利用，应尽快迁移业务，立即下线机器。

如果不能立即处理，应当通过配置网络 ACL等方式，封掉该服务器对网络的双向连接。

影响范围评估（运维/开发）

一般是运维或者程序确认影响范围，需要运维通过日志或者监控图表确认数据库或者敏感文件是否泄露，如果是代码或者数据库泄露了，则需要程序评估危害情况与处置方法。

影响访问评估一般从下面几点来入手：

IP及所处区域拓扑等：VLAN内服务器和应用情况。

确定同一网络下面服务器之间的访问：可以互相登陆，是否需要 Key或者是密码登录。

由此确定检查影响范围，确认所有受到影响的网段和机器。

在线分析（安全人员/运维）

这时需要根据个人经验快速在线分析，一般是安全人员和运维同时在线处理，不过会涉及多人协作的问题，需要避免多人操作机器时破坏服务器现场，造成分析困扰。

之前笔者遇到一个类似的问题，就是运维排查时敲错了 iptables的命令，将 iptables -L敲成 iptables -i导致 iptables-save时出现异常记录，结果安全人员上来检查时就被这条记录迷惑了，导致处理思路受到一定干扰。

检查是否存在异常用户。

检查最近添加的用户，是否有不知名用户或不规范提权。

找出 root权限的用户。

可以执行以下命令检查：

注意非正常端口的外网 IP

判断是否为木马 ps –aux

确认日志是否被删除或者清理过的可能（大小判断）。

last/lastb可以作为辅助，不过可能不准确。

NHIDS正常运行判断

抓取网络数据包并进行分析，判断是否为拒绝服务攻击，这里需要注意，一定要使用 -w参数，这样才能保存成 pcap格式导入到 wireshark，这样分析起来会事半功倍。

安全相关的关键文件和数据备份（运维）

可以同步进行，使用 sftp/rsync等将日志上传到安全的服务器：

打包可疑文件、后门、Shell信息

初步锁定异常进程和恶意代码后，将受影响范围梳理清楚，封禁了入侵者对机器的控制后，接下来需要深入排查入侵原因。一般可以从 Webshell、开放端口服务等方向顺藤摸瓜。

查找 Web目录下所有 nobody的文件，人工分析：

如果能确定入侵时间，可以使用 find查找最近时间段内变化的文件：

缩小日志范围：时间，异常 IP提取。

攻击行为提取：常见的攻击 exp识别。

爆破行为定位和 IP提取。

爆破是否成功确定：有爆破行为 IP是否有 accept记录。

其他服务器跳板到本机。

History日志：提权、增加后门，以及是否被清理。

内网扫描：网络 nmap/扫描器，socks5代理。

根据时间点做关联分析：查找那个时间段的所有文件。

一些小技巧：/tmp目录， ls –la，查看所有文件，注意隐藏的文件。

根据用户做时间关联：比如 nobody。

其他机器和这台机器的网络连接 （日志查看）、相同业务情况（同样业务，负载均衡）。

整理事件报告（安全人员）

事件报告应包含但不限于以下几个点：

分析事件发生原因：事件为什么会发生的原因。

分析整个攻击流程：时间点、操作。

分析事件处理过程：整个事件处理过程总结是否有不足。

分析事件预防：如何避免事情再次发生。

总结：总结事件原因，改进处理过程，预防类似事件再次发生。

处理中遇到的比较棘手的事情

1、日志和操作记录全被删了，怎么办？

strace查看 losf进程，再尝试恢复一下日志记录，不行的话镜像硬盘数据慢慢查。这个要用到一些取证工具了，dd 硬盘数据再去还原出来。

2、系统账号密码都修改了，登不进去？

重启进单用户模式修改 root密码，或者通过控制卡操作，或者直接还原系统，都搞不定就直接重装吧。

3、使用常见的入侵检测命令未发现异常进程，但是机器在对外发包，这是怎么回事？

这种情况下很可能常用的系统命令已经被攻击者或者木马程序替换，可以通过 md5sum对比本机二进制文件与正常机器的 md5值是否一致。

如果发现不一致，肯定是被替换了，可以从其他机器上拷贝命令到本机替换，或者 alias为其他名称，避免为恶意程序再次替换。

漏洞修复前，系统立即下线，用内网环境访问。

上传点放到内网访问，不允许外网有类似的上传点，有上传点，而且没有校验文件类型很容易上传 Webshell。

被 getshell的服务器中是否有敏感文件和数据库，如果有请检查是否有泄漏。

hosts文件中对应的 host关系需要重新配置，攻击者可以配置 hosts来访问测试环境。

上面讲了很多思路的东西，相信大家更想看看实际案例，下面介绍两个案例。

一个别人处理的案例，基本处理过程如下：

通过外部端口扫描收集开放端口信息，然后获取到反弹 Shell信息，登陆机器发现关键命令已经被替换，后面查看 History记录，发现疑似木马文件，通过简单逆向和进程查看发现了异常进程，从而锁定了入侵原因。

一个笔者实际处理过的案例，基本处理流程跟上面提到的思路大同小异。

整个事情处理经过大致如下：

1、运维发现一台私有云主机间歇性的对外发送高达 800Mbps的流量，影响了同一个网段的其他机器。

2、安全人员接到通知后，先确认了机器属于备机，没有跑在线业务，于是通知运维封禁 iptables限制外网访问。

3、运维为安全人员临时开通机器权限，安全人员通过 History和 ps找到的入侵记录和异常进程锁定了对外大量发包的应用程序，清理了恶意进程并删除恶意程序。

恶意进程如下，经过在网络搜索发现是一种 DDOS木马，但没有明确的处理思路：

处理过程中，安全人员怀疑系统文件被替换，通过对比该机器与正常机器上面的 ps、netstat等程序的大小发现敏感程序已经被替换，而且 mtime也被修改。

将部分常用二进制文件修复后，发现异常进程被 kill掉后仍重启了，于是安装杀毒软件 clamav和 rootkit hunter进行全盘扫描。

从而确认了被感染的所有文件，将那些可以删除的文件删除后再次 kill掉异常进程，则再没有重启的问题。

由于该机器只是备机，上面没有敏感数据，于是信息泄露问题也就不存在了。

扫描同一网段机器端口开放情况、排查被入侵机器 History是否有对外扫描或者入侵行为，为此还在该网段机器另外部署蜜罐进行监控。

通过被入侵机器所跑服务、iptables状态，确认是所跑服务支持远程命令执行。

6、验证修复、机器下线重装

进行以上修复操作后，监控未发现再有异常，于是将机器下线重装。

7、完成安全事件处理报告

每次安全事件处理后，都应当整理成报告，不管是知识库的构建，还是统计分析安全态势，都是很有必要的。

这次主要介绍了服务器被入侵时推荐的一套处理思路。实际上，安全防护跟运维思路一样，都是要防患于未然，这时候的审计或者响应很难避免危害的发生了。

我们更希望通过安全意识教育、安全制度的建设，在问题显露端倪时即可消弭于无形。

Linux服务器安全防护要点

设定登录密码是一项非常重要的安全措施，如果用户的密码设定不合适，就很容易被破译，尤其是拥有超级用户使用权限的用户，如果没有良好的密码，将给系统造成很大的安全漏洞。

目前密码破解程序大多采用字典攻击以及暴力攻击手段，而其中用户密码设定不当，则极易受到字典攻击的威胁。很多用户喜欢用自己的英文名、生日或者账户等信息来设定密码，这样，黑客可能通过字典攻击或者是社会工程的手段来破解密码。所以建议用户在设定密码的过程中，应尽量使用非字典中出现的组合字符，并且采用数字与字符相结合、大小写相结合的密码设置方式，增加密码被黑客破解的难度。而且，也可以使用定期修改密码、使密码定期作废的方式，来保护自己的登录密码。

在多用户系统中，如果强迫每个用户选择不易猜出的密码，将大大提高系统的安全性。但如果passwd程序无法强迫每个上机用户使用恰当的密码，要确保密码的安全度，就只能依靠密码破解程序了。实际上，密码破解程序是黑客工具箱中的一种工具，它将常用的密码或者是英文字典中所有可能用来作密码的字都用程序加密成密码字，然后将其与Linux系统的/etc/passwd密码文件或/etc/shadow影子文件相比较，如果发现有吻合的密码，就可以求得明码了。在网络上可以找到很多密码破解程序，比较有名的程序是crack和john the ripper.用户可以自己先执行密码破解程序，找出容易被黑客破解的密码，先行改正总比被黑客破解要有利。

2、限定：网络服务管理

早期的Linux版本中，每一个不同的网络服务都有一个服务程序(守护进程，Daemon)在后台运行，后来的版本用统一的/etc/inetd服务器程序担此重任。Inetd是Internetdaemon的缩写，它同时监视多个网络端口，一旦接收到外界传来的连接信息，就执行相应的TCP或UDP网络服务。由于受inetd的统一指挥，因此Linux中的大部分TCP或UDP服务都是在/etc/inetd.conf文件中设定。所以取消不必要服务的第一步就是检查/etc/inetd.conf文件，在不要的服务前加上“#”号。

一般来说，除了http、smtp、telnet和ftp之外，其他服务都应该取消，诸如简单文件传输协议tftp、网络邮件存储及接收所用的imap/ipop传输协议、寻找和搜索资料用的gopher以及用于时间同步的daytime和time等。还有一些报告系统状态的服务，如finger、efinger、systat和netstat等，虽然对系统查错和寻找用户非常有用，但也给黑客提供了方便之门。例如，黑客可以利用finger服务查找用户的电话、使用目录以及其他重要信息。因此，很多Linux系统将这些服务全部取消或部分取消，以增强系统的安全性。Inetd除了利用/etc/inetd.conf设置系统服务项之外，还利用/etc/services文件查找各项服务所使用的端口。因此，用户必须仔细检查该文件中各端口的设定，以免有安全上的漏洞。

在后继的Linux版本中(比如Red Hat Linux7.2之后)，取而代之的是采用xinetd进行网络服务的管理。

当然，具体取消哪些服务不能一概而论，需要根据实际的应用情况来定，但是系统管理员需要做到心中有数，因为一旦系统出现安全问题，才能做到有步骤、有条不紊地进行查漏和补救工作，这点比较重要。

3、严格审计：系统登录用户管理

在进入Linux系统之前，所有用户都需要登录，也就是说，用户需要输入用户账号和密码，只有它们通过系统验证之后，用户才能进入系统。

与其他Unix操作系统一样，Linux一般将密码加密之后，存放在/etc/passwd文件中。Linux系统上的所有用户都可以读到/etc/passwd文件，虽然文件中保存的密码已经经过加密，但仍然不太安全。因为一般的用户可以利用现成的密码破译工具，以穷举法猜测出密码。比较安全的方法是设定影子文件/etc/shadow，只允许有特殊权限的用户阅读该文件。

在Linux系统中，如果要采用影子文件，必须将所有的公用程序重新编译，才能支持影子文件。这种方法比较麻烦，比较简便的方法是采用插入式验证模块(PAM)。很多Linux系统都带有Linux的工具程序PAM，它是一种身份验证机制，可以用来动态地改变身份验证的方法和要求，而不要求重新编译其他公用程序。这是因为PAM采用封闭包的方式，将所有与身份验证有关的逻辑全部隐藏在模块内，因此它是采用影子档案的最佳帮手。

此外，PAM还有很多安全功能：它可以将传统的DES加密方法改写为其他功能更强的加密方法，以确保用户密码不会轻易地遭人破译;它可以设定每个用户使用电脑资源的上限;它甚至可以设定用户的上机时间和地点。

Linux系统管理人员只需花费几小时去安装和设定PAM，就能大大提高Linux系统的安全性，把很多攻击阻挡在系统之外。

4、设定：用户账号安全等级管理

除密码之外，用户账号也有安全等级，这是因为在Linux上每个账号可以被赋予不同的权限，因此在建立一个新用户ID时，系统管理员应该根据需要赋予该账号不同的权限，并且归并到不同的用户组中。

在Linux系统中的部分文件中，可以设定允许上机和不允许上机人员的名单。其中，允许上机人员名单在/etc/hosts.allow中设置，不允许上机人员名单在/etc/hosts.deny中设置。此外，Linux将自动把允许进入或不允许进入的结果记录到/var/log/secure文件中，系统管理员可以据此查出可疑的进入记录。

每个账号ID应该有专人负责。在企业中，如果负责某个ID的职员离职，管理员应立即从系统中删除该账号。很多入侵事件都是借用了那些很久不用的账号。

在用户账号之中，黑客最喜欢具有root权限的账号，这种超级用户有权修改或删除各种系统设置，可以在系统中畅行无阻。因此，在给任何账号赋予root权限之前，都必须仔细考虑。

Linux系统中的/etc/securetty文件包含了一组能够以root账号登录的终端机名称。例如，在RedHatLinux系统中，该文件的初始值仅允许本地虚拟控制台(rtys)以root权限登录，而不允许远程用户以root权限登录。最好不要修改该文件，如果一定要从远程登录为root权限，最好是先以普通账号登录，然后利用su命令升级为超级用户。

5、谨慎使用：“r系列”远程程序管理

在Linux系统中有一系列r字头的公用程序，比如rlogin，rcp等等。它们非常容易被黑客用来入侵我们的系统，因而非常危险，因此绝对不要将root账号开放给这些公用程序。由于这些公用程序都是用。rhosts文件或者hosts.equiv文件核准进入的，因此一定要确保root账号不包括在这些文件之内。

由于r等远程指令是黑客们用来攻击系统的较好途径，因此很多安全工具都是针对这一安全漏洞而设计的。例如，PAM工具就可以用来将r字头公用程序有效地禁止掉，它在/etc/pam.d/rlogin文件中加上登录必须先核准的指令，使整个系统的用户都不能使用自己home目录下的。rhosts文件。

6、限制：root用户权限管理

Root一直是Linux保护的重点，由于它权力无限，因此最好不要轻易将超级用户授权出去。但是，有些程序的安装和维护工作必须要求有超级用户的权限，在这种情况下，可以利用其他工具让这类用户有部分超级用户的权限。sudo就是这样的工具。

sudo程序允许一般用户经过组态设定后，以用户自己的密码再登录一次，取得超级用户的权限，但只能执行有限的几个指令。例如，应用sudo后，可以让管理磁带备份的管理人员每天按时登录到系统中，取得超级用户权限去执行文档备份工作，但却没有特权去作其他只有超级用户才能作的工作。

sudo不但限制了用户的权限，而且还将每次使用sudo所执行的指令记录下来，不管该指令的执行是成功还是失败。在大型企业中，有时候有许多人同时管理Linux系统的各个不同部分，每个管理人员都有用sudo授权给某些用户超级用户权限的能力，从sudo的日志中，可以追踪到谁做了什么以及改动了系统的哪些部分。

值得注意的是，sudo并不能限制所有的用户行为，尤其是当某些简单的指令没有设置限定时，就有可能被黑客滥用。例如，一般用来显示文件内容的/etc/cat指令，如果有了超级用户的权限，黑客就可以用它修改或删除一些重要的文件。

7、追踪黑客踪迹：日志管理

当用户仔细设定了各种与Linux相关的配置(最常用日志管理选项)，并且安装了必要的安全防护工具之后，Linux操作系统的安全性的确大为提高，但是却并不能保证防止那些比较熟练的网络黑客的入侵。

在平时，网络管理人员要经常提高警惕，随时注意各种可疑状况，并且按时检查各种系统日志文件，包括一般信息日志、网络连接日志、文件传输日志以及用户登录日志等。在检查这些日志时，要注意是否有不合常理的时间记载。例如：

正常用户在半夜三更登录；

不正常的日志记录，比如日志只记录了一半就切断了，或者整个日志文件被删除了；

用户从陌生的网址进入系统；

因密码错误或用户账号错误被摈弃在外的日志记录，尤其是那些一再连续尝试进入失败，但却有一定模式的试错法；

非法使用或不正当使用超级用户权限su的指令；

重新开机或重新启动各项服务的记录。

上述这些问题都需要系统管理员随时留意系统登录的用户状况以及查看相应日志文件，许多背离正常行为的蛛丝马迹都应当引起高度注意。

8、横向扩展：综合防御管理

防火墙、IDS等防护技术已经成功地应用到网络安全的各个领域，而且都有非常成熟的产品。

在Linux系统来说，有一个自带的Netfilter/Iptables防火墙框架，通过合理地配置其也能起到主机防火墙的功效。在Linux系统中也有相应的轻量级的网络入侵检测系统Snort以及主机入侵检测系统LIDS(Linux Intrusion Detection System)，使用它们可以快速、高效地进行防护。

需要提醒注意的是：在大多数的应用情境下，我们需要综合使用这两项技术，因为防火墙相当于安全防护的第一层，它仅仅通过简单地比较IP地址/端口对来过滤网络流量，而IDS更加具体，它需要通过具体的数据包(部分或者全部)来过滤网络流量，是安全防护的第二层。综合使用它们，能够做到互补，并且发挥各自的优势，最终实现综合防御。

9、评测：漏洞追踪及管理

Linux作为一种优秀的开源软件，其自身的发展也日新月异，同时，其存在的问题也会在日后的应用中慢慢暴露出来。黑客对新技术的关注从一定程度上来说要高于我们防护人员，所以要想在网络攻防的战争中处于有利地位，保护Linux系统的安全，就要求我们要保持高度的警惕性和对新技术的高度关注。用户特别是使用Linux作为关键业务系统的系统管理员们，需要通过Linux的一些权威网站和论坛上尽快地获取有关该系统的一些新技术以及一些新的系统漏洞的信息，进行漏洞扫描、渗透测试等系统化的相关配套工作，做到防范于未然，提早行动，在漏洞出现后甚至是出现前的最短时间内封堵系统的漏洞，并且在实践中不断地提高安全防护的技能，这样才是一个比较的解决办法和出路。

10、保持更新：补丁管理

Linux作为一种优秀的开源软件，其稳定性、安全性和可用性有极为可靠的保证，世界上的Linux高手共同维护着个优秀的产品，因而起流通渠道很多，而且经常有更新的程序和系统补丁出现，因此，为了加强系统安全，一定要经常更新系统内核。

Kernel是Linux操作系统的核心，它常驻内存，用于加载操作系统的其他部分，并实现操作系统的基本功能。由于Kernel控制计算机和网络的各种功能，因此，它的安全性对整个系统安全至关重要。早期的Kernel版本存在许多众所周知的安全漏洞，而且也不太稳定，只有2.0.x以上的版本才比较稳定和安全(一般说来，内核版本号为偶数的相对稳定，而为奇数的则一般为测试版本，用户们使用时要多留意)，新版本的运行效率也有很大改观。在设定Kernel的功能时，只选择必要的功能，千万不要所有功能照单全收，否则会使Kernel变得很大，既占用系统资源，也给黑客留下可乘之机。

在Internet上常常有最新的安全修补程序，Linux系统管理员应该消息灵通，经常光顾安全新闻组，查阅新的修补程序。