作为运维工程师来说，最怕遇到服务器崩了、内存爆了、CPU满了等情况，尤其对于生产环境来说影响是非常巨大的。对于运维工程师来说可能面临被“炒鱿鱼”的风险。那么遇到这种情况怎么办呢，首先是要沉着冷静，然后按照下面的Shell命令来排查服务器本身的问题。
1.日志（各种日志，访问日志、中间件日志、数据库日志、系统日志、运行日志、安全日志等等等等）
为了方便即将到来的HVV行动，为大家提供更好的掌握渗透攻击技能，特意收集了一些关于HVV常见的面试题给大家参考。
最近组内来了个新人实习生，正好我前几天也给他讲了我的排查问题步骤，今天来分享下我的经验。
今天查看两个月前上线的小项目，发现运行非常慢，而且增删改查失效了（吓我一大跳），急急忙忙的就开始了我的线上问题排查之路。
回望整个过年期间真的是躺的平平的，每天学习的时间和平时比起来差的不是一星半点。今天就复工了，也要收心了。我这个人有一个比较牛逼的能力就是状态调整特别快，只需要往工位上一坐下，我就能进入复工状态了。
前端时间把公司的一个分布式定时调度的系统弄上了容器云，部署在kubernetes，在容器运行的动不动就出现问题，特别容易jvm溢出，导致程序不可用，终端无法进入，日志一直在刷错误，kubernetes也没有将该容器自动重启。业务方基本每天都在反馈task不稳定，后续就协助接手看了下，先主要讲下该程序的架构吧。
新上线一个批处理功能，基于Docker发布的。上线之后出现一个问题，Docker批处理生成的文件目录，别的应用程序无法访问。
早晨刚到公司，收到同事推送的一条生产机器磁盘使用率<90%的告警，我们的机器部署了日志清理脚本一般仅保存2～3天的日志，其他都会上传到ES，通过ELK模式管理。按理说，不应该是日志太大，但机器上能占用磁盘的除了一些服务安装包也只有日志了，遂开始排查。
HVV行动已经进行到了11天，处置的工作明显增多，随着各种情况发生，所以这两天分别整理一些关于Linux和Windows的排查手册。
下载地址：https://github.com/wsfengfan/SecurityTraceability/
不小心重启了线上服务器的网卡，结果整个网络不通了，就算使用127.0.0.1访问都不行，第一次遇到这种问题，当时就六神无主了，两个人排查了好久也没找到原因，万分火急。排查内核日志发现网卡状态不断地从Not Ready到Ready切换，但是却看不出任何原因。没办法还是得从日志中找原因，由于不知道错误关键词，只能肉眼盯着滚动的系统实时日志，终于功夫不负有心人，看到了这行日志：IPV4 forwarding is disabled. Networking will not work，下面就将整个排查过程简单明了的说明一下，希望能帮助到大家。
本文要介绍的是一个发生在我们线上环境的真实案例，问题发生在某次大促期间，对我们的线上集群造成了比较大的影响，这篇文章简单复盘一下这个问题。
这两年见证了公司从600人发展到1200+的过程，虽然公司在安全投入上还算慷慨，但是人员编制有严格要求，一个人的安全部只能把精力放在基础/重点工作上。其中防病毒这块也是两年前才正式部署了企业版防病毒软件，推广过程中也遇到了很多阻力及各种奇葩的安全理念（比如生产服务器我不敢装防病毒，万一瘫了怎么办；领导的电脑，防病毒还是别装吧，装了会很慢），这期间也遇到多起病毒木马事件，每次我都会借助安全事件，狠狠的推一把防病毒软件，目前为止，已经实现所有PC和Windows服务器防病毒软件的百分百覆盖。现将几起病毒木马的处理过程整理一下跟大家分享，本系列偏向于实战。
经常会遇到这样的场景：测试环境磁盘跑满了，导致系统不能正常运行！ 此时就需要查看是哪个目录或者文件占用了空间。 常使用如下几个命令进行排查：df, lsof，du。
在Linux操作系统中，每个运行的进程都有一个唯一的标识符，即进程识别号（PID）。了解进程识别号对于系统管理和故障排查是至关重要的。本文将深入探讨如何查看Linux中的进程识别号，以及了解PID在系统运行中的作用。
记得之前写过一篇：《阿里巴巴 Java开发手册》读后感，之前自学时由于没怎么接触过打“日志”，所以《手册》中的“日志规约”我就先放一边去了。
最近在和安卓开发对接接口，遇到一个接口总是报405错误，有对接经验的开发应该都知道是请求方式不对，假如接口定义为POST请求的，但是客户端却用GET请求，这时候就会报这个错误。Android客户端那边使用xUtils框架请求网络API接口，也是多年的Android开发，对接也是使用post请求过来的，所以初步排查有可能是缓存或者是被代理服务器给转了，为了确定请求的方式和其它业务参数，需要去查看日志验证
我们团队是做程序化广告的，我所在小组主要做 DSP 方向，对接外部 ADX，提供广告检索服务（对广告系统不熟悉的不要着急，后面有时间会给大家分享广告相关的文章）
经过前几篇的铺垫，进入中间件日志排查篇。由于各种各样的原因安全人员获取到的告警信息很可能是零零碎碎的，且高级黑客的整个入侵过程很可能十分完整，包含了清除痕迹等，这就导致了几种情况可能会发生：可疑威胁文件已被删除，无法定位；远程命令执行痕迹已被清除，无法还原攻击者入侵路径。
非法挖矿一般分为基于文件的挖矿和基于浏览器的挖矿。由于云主机用户一般不使用浏览器访问网页，故基于浏览器的挖矿在公有云上并非较大的威胁。
在Linux系统中，管理员和用户经常需要查找和跟踪系统上用户的登录记录。这对于安全审计、故障排查和监控用户活动非常重要。在本文中，我们将详细介绍如何在Linux上查找上次登录的方法。
last 命令是一个常用的Linux命令，用于查看系统上用户的登录历史。它会显示用户的登录名、登录时间、登录IP地址以及登录来源（如终端、远程登录等）。
RTSP协议视频平台EasyNVR根据不同的用户操作习惯，分为Windows版本和Linux版本，当EasyNVR使用nginx运行时，可以开启多进程模式，《EasyNVR如何开启多进程工作方式》一文中有比较详细的解释，大家可以看一下。
攻击溯源作为安全事故中事后响应的重要组成部分，通过对受害资产与内网流量进行分析一定程度上还原攻击者的攻击路径与攻击手法，有助于修复漏洞与风险避免二次事件的发生。攻击知识可转换成防御优势,如果能够做到积极主动且有预见性，就能更好地控制后果。
Linux的进程排查总体思路和windows的不会偏差太多，具体到细则上存在差异，今天就和师傅们来探讨下Linux下的进程分析及排查。
德国科技管理专家斯坦门茨早年移居美国，他以非凡的才能成为美国企业界的佼佼者。一次，美国著名的福特公司的一组电机发生故障，在束手无策之时，公司请斯坦门茨出马解决问题。
当Linux主机发生安全事件需要进行入侵排查时，一般可以使用常见的shell命令，通过分析主机的异常现象、进程端口、启动方式、可疑文件和日志记录等信息以确认主机是否被入侵。
应用程序出现OOM异常，你是否仍然通过看日志的方式去排查问题（该方式定位解决问题是大概率的巧合而已）？正确的排查方案是进行dump文件分析，你知道为什么吗？
虽然今天处置的时候并非本文章情况，等过段时间结束了我在发一下我的处置过程涉及到的技术点以及思路
其实大多数Java开发确实能胜任日常的开发工作，但不少候选人却无法在面试中打动面试官。因为要在短时间的面试中全面展示自己的实力，这很需要技巧，而从当前大多数Java开发的面试现状来看，会面试的候选人不多。所以在展开讲述分布式组件面试技巧前，就先给出大多数候选人普遍会出现的问题，这需要大家引以为戒。
树莓派是一种广泛流行的开发板，随着物联网的深入发展，树莓派大有成为IoT终端设备标准之趋势。在支持客户在IoT场景中落地k3s时，k3s在树莓派上的部署问题也就出现了。本文记录了一些其中的关键问题，转述成文，方便其他用户参考。
应急响应分为四个阶段：前期沟通，事件处理，事件分析，报告交付，前期沟通主要是和客户交流事件情况，了解是什么安全事件，客户是否做了处理，如果做了处理，做了那些处理。了解相关情况后后，下一步，就是帮助客户止血，即处理安全事件，减轻客户损失。服务器恢复正常后，进行事件分析，通过排查日志还原攻击者的入侵轨迹，最后一步就是整理报告。
这件事是真实的发送在我们的生产环境上，其中的一台服务器上跑着 4 个 jar 程序，隔三差五的会发送进程突然消失的问题。
本文为整个专题的第四篇，中间跳过了原计划的“内网横向移动攻击模拟（下）”。原因是下与上的类型一致，均为攻击模拟的记录，可分享和讨论的意义不大，只要按照这种模式可以设计出更多的场景。继而，继续编写本专题后续的内容。
最新将生产环境的服务器版本统一升级了一下，其中有一台（4H/8G）近两天天天CPU使用率报警（阀值>95%，探测周期60s，触发频率6次），而且load acerage也居高不下，检查了各个系统应用软件的资源使用都没有问题，也将一些可能导致CPU使用率高的软件stop掉，报警依旧。
Java能力和面试能力，这是两个方面的技能，可以这样说，如果不准备，一些大神或许也能通过面试，但能力和工资有可能被低估。再仔细分析下原因，面试中问的问题，虽然在职位介绍里已经给出了范围，但针对每个点，面试官的问题是随机想的，甚至同一个面试官在两场相似的面试里，提的问题也未必一样。
CVM云服务器通过VNC输入正确的密码后无法正常登录，报错Module is unknown
近日接到客户求助，他们收到托管电信机房的信息，通知检测到他们的一台服务器有对外发送攻击流量的行为。希望我们能协助排查问题。
httpclient一只read time out，使用jmx 产看内存是每天都在上升的。
今天终于又能抽出一点时间来写文章了，接着前一篇继续写。前一篇文章有博友就评论说写了很多废话，其实本身就是一些工作中的点点滴滴，自己想到什么就写什么，没有太多的构思文章的内容和结构，就算自己回顾自己工作的这五年吧。 上篇博客提到自己主要支持各个团队使用scribe归集日志，这也包括归集日志到hadoop系统里面。所以这时的自己开始接触hadoop生态系统了，刚开始也是从网上找各种安装使用教程，遇到各种问题也基本上都是通过google解决。通过安装和使用hadoop，对hadoop大部
云主机无法ssh及ping通，端口开启。VNC中有大量“backlog limit exceeded”的提示
上文：问题:springboot多配置中心，解决无法同步更新(nacos/consul)
找到错误日志位置，定位日志（大量登录失败、异常查询）（并且不在正常运维期间所触发）
前段时间，OpenSSH被曝出存在两个信息泄露漏洞（CVE-2018-15473和CVE-2018-15919）。其中CVE-2018-15919影响自2011年9月6日发布的5.9版本到今年8月24日发布的最新版本7.8。CVE-2018-15473则影响自1999年以来至今年7.7版本中所有版本，远程攻击者可利用漏洞猜测在OpenSSH服务器上注册的用户名。
我这里说明一下jar包Java运行部署在服务端，首先要确定项目在服务端运行成功，可以实java -jar jar包名.jar 或者bohup java -jar jar包名.jar >日志文件名称.txt &
上期文章介绍了Webshell的基础知识和防护技巧，有兴趣的同学可以前往 你所不知道的Webshell--基础篇 观看。
1.概述 某年某月某日某项目的线上分布式文件系统服务器多台Linux系统kernel崩溃，严重影响了某项目对外提供服务的能力，在公司造成了不小影响。通过排查线上问题基本确定了是由于linux内核panic造成的原因，通过两个阶段的问题排查，基本上确定了linux内核panic的原因。排查问题的主要手段就是网上查找资料和根据内核错误日志分析并且构造条件重现。本文档就是对自己在整个问题排查过程中的总结。 2.第一阶段 因为刚出现问题的时候大家都比较紧急，每天加班都很晚，也制定了很多问题重现和定位原因的计划
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
