Linux下应用/进程的存活性监控

=Start=

缘由：

很早之前就想了解的一个问题，自己也多少知道一些方法，但总觉得应该有多种实现方式/方法，不过一直没机会整理、总结，所以这次先整理一下，等以后各种方法都实践了一遍再更新一下，或是再写一篇。

正文：

参考解答：

实现「进程监控」可以使用的一些现成工具（Bluepill、eye、god、supervisor、Open-Falcon）

Process monitoring tool. Inspired from Bluepill and God. (Ruby)
https://github.com/kostya/eye

simple process monitoring tool (Ruby)
https://github.com/bluepill-rb/bluepill

Ruby process monitor (Ruby)
https://github.com/mojombo/god
http://godrb.com/

monit (C)
https://github.com/arnaudsj/monit

supervisor (Python)
https://github.com/Supervisor/supervisor

Open-Falcon
http://book.open-falcon.org/zh/usage/proc-port-monitor.html

# 端口监控
机器监听的端口可能很多很多，但是真正想做监控的端口可能不多，这会造成资源浪费
目前Open-Falcon还不支持nodata监控，端口挂了不上报数据了，没有nodata机制，是发现不了的

agent通过 ss -tln 命令拿到当前有哪些端口在监听，如果8080在监听，就设置value=1，汇报给transfer，如果发现8081没在监听，就设置value=0，汇报给transfer。

# 进程监控
name是从/proc/$pid/status文件采集的，cmdline是从/proc/$pid/cmdline采集的。这个文件存放的是你启动进程的时候用到的命令，比如你用java -c uic.properties启动了一个Java进程，进程名是java，其实所有的java进程，进程名都是java，那我们是没法通过name字段做区分的。怎么办呢？此时就要求助于这个/proc/$pid/cmdline文件的内容了。

听起来是不是挺复杂的？呵呵，如果你的进程有端口在监听，就配置一个端口监控就可以了，无需既配置端口监控、又配置进程监控，毕竟如果进程挂了，端口肯定就不会监听了。

除了使用上面的工具之外，其实自己也可以写一个low一点的，比如：

用C语言先fork()再waitpid()，如果有返回则说明进程挂掉了，则进行通知并再次将进程拉起；
写个crontab任务，定期检查；

上面说的是一些工具和方法，原理基本上都是根据进程名去/proc目录下查找、比对status/cmdline这些文件，如果检查的时候有，则说明进程还存活；如果检查的时候没有，则说明进程挂掉了。

有不少地方需要用到这些特性：

监控重要进程的启停情况（比如：rsyslogd……），要实现安全，首先需要有足够强的感知能力；

参考链接：

=END=

2 6 月, 2018

Docker

KnowledgeBase, Linux, Tools

/proc, falcon, Linux, pid

《 “Linux下应用/进程的存活性监控” 》有 7 条评论

hi说道：

2018-06-04 16:03

不要相信 PID，关于 PID 替换的逻辑漏洞介绍
https://saelo.github.io/presentations/warcon18_dont_trust_the_pid.pdf

回复
hi说道：

2018-06-29 10:12

pspy – 无需 root 权限的 linux 进程监视器
https://github.com/DominicBreuker/pspy

回复
hi说道：

2018-11-02 20:51

进程监控、进程命令行监控的数据源(Process monitoring/Process cmd line monitoring – data sources)
http://www.hexacorn.com/blog/2018/10/27/process-monitoring-process-cmd-line-monitoring-data-sources/
`
Windows
　4688 with no cmd line arguments
　4688 with cmd line arguments
　4688 with cmd line arguments & name of the parent process (newer Windows systems)
　Sysmon / 1
　EDR logs
　AV logs
　Local Proxy logs
　Local IDS logs (CIDS)
　DCOM Logs
　WMI Logs
　there are also some ‘indirect’ logs that may indicate some process ran at some stage in the past (most of these listed below include PID, process name) e.g.:
　　service creation / start logs
　　powershell logs
　　WER logs
　　Application error logs
　　Application hung logs
　　App Locker logs
　　Restart Manager logs
　　Diagnostics-Performance logs
　　Firewall logs
　　System/change time logs
　　System Logon events logs
　　Forensic artifacts (if e.g. EDR picks them up — see this excellent reference by @harrisonamj: https://blog.1234n6.com/2018/10/available-artifacts-evidence-of.html …), etc.
　　etc.
Linux
　auditd (see this reference)
　　EXECVE
　　USER_CMD
　　BPRM_FCAPS
　　SYSCALL
　　ANOM_EXEC
　content of .bash_history retrieved as a snapshot on regular basis
OSX
　xnumon logs (anyone actually using it?)
　content of .bash_history retrieved as a snapshot on regular basis
`

回复
hi说道：

2019-10-13 16:31

用于监控系统的日志采集agent，可无缝对接open-falcon
https://github.com/didi/falcon-log-agent

回复
hi说道：

2019-10-29 19:09

大规模基础agent的管理
https://mp.weixin.qq.com/s/3CWJYeZc-B6TwVu3PsEt4g
`
agent管理平台主要包括资源管理、部署更新、异常处理、dashboard 4方面。

# 资源管理
通过 cgroup 来限制硬件 cpu、mem、disk io、 networkio 的使用，保证agent 占用资源都在预定范围之内;
通过 ulimit 来限制最大进程数、文件数，core dump 大小，避免创建大量进程，打开大量文件，造成耗尽系统资源的情况;
要求 agent内建日志、临时文件清理机制，避免垃圾文件的堆积，消耗系统资源
通过设置 oom_adj, nice 值，以低优先级运行，当出现资源紧张时，基础agent优先被kill，释放资源；

# 部署更新
# 异常处理
# dashboard
`

回复
hi说道：

2020-03-26 09:39

Nightingale是一套衍生自Open-Falcon的互联网监控解决方案
https://github.com/didi/nightingale/blob/master/README_ZH.md
https://n9e.didiyun.com/docs/

回复
abc说道：

2021-09-01 17:14

如何改变进程名称
https://mp.weixin.qq.com/s/hWd0EOaBgVbgTBjsdg7QfA
`
# 背景
之前在测试反弹shell时，测试发现：某厂商会根判断程命令是否是bash、sh等脚本解释器，如果修改bash、sh等文件名后反弹shell，就会绕过厂商的反弹shell防护。

需要强调的的是：”修改敏感文件名、复制敏感文件“本身非常有可能被hids当作一种”异常文件操作”行为。

还有一些场景下也会涉及到”进程名称的修改”：比如某些恶意软件会修改进程名称，伪装成”内核线程”。

所以可以说，在”进程名称的修改”这个点上是存在一些攻防对抗的。

本文研究：
1. 除了直接修改程序文件名，还有哪些方式来修改进程名称？
2. 作为防守方，怎么发现和检测这些”修改方式”？

本文应该适合做应急响应、hids和”对linux后渗透感兴趣”的读者阅读，文章中给出了我对每种隐藏方式的效果验证，方便读者对隐藏效果做评估。

# 分析过程
* 怎么查看”进程名称”？通过 /proc/{pid} 目录下的几个文件。
* 更常见的情况下，我们是通过ps、top等命令来查看进程信息。

怎么修改”进程名称”？

改变进程名包括以下方式：
* execve系统调用
* prctl系统调用
* 修改进程argv
* 软链接

# 总结
可以有以下结论：

* 单看四种隐藏方式，”软链接”这种方式隐蔽得最好；其他几种方式，comm、stat、cmdline、status文件中总会有原程序相关信息
* 不论哪种方式，exe文件仍然有原程序相关信息
* 像”prctl系统调用”这种方式应该避免使用
`

回复

ASPIRE

Linux下应用/进程的存活性监控

缘由：

正文：

参考解答：

参考链接：

《 “Linux下应用/进程的存活性监控” 》有 7 条评论

发表回复取消回复

Linux下应用/进程的存活性监控

缘由：

正文：

参考解答：

参考链接：

《 “Linux下应用/进程的存活性监控” 》 有 7 条评论

发表回复 取消回复

《 “Linux下应用/进程的存活性监控” 》有 7 条评论

发表回复取消回复