网站安全主机的入侵行为检测，本质上不是买一台带“入侵检测”字样的设备或者装一个插件就能解决的事。它是一套从日志采集、特征比对、行为建模到告警响应的基础工程。多数中小站点被入侵后长时间不知情，不是因为攻击者手段多高明，而是因为主机上没有任何有效的检测基线，连最基础的登录异常和文件变动都无人关注。下面直接拆解一套可落地的检测方案，覆盖Linux和Windows主机环境，重点放在检测逻辑和关键配置上。

入侵检测的核心对象与数据源

主机入侵检测要盯住三类核心数据：认证日志、进程行为、文件系统变化。认证日志记录谁在什么时间从哪个IP登录成功或失败，这是发现暴力破解和异常登录的第一现场。进程行为反映当前系统里正在跑什么程序、由哪个用户启动、占用了哪些网络端口，这是识别Webshell、挖矿木马和反弹Shell的关键。文件系统变化则能暴露攻击者上传的后门文件、篡改的网页内容以及被替换的系统命令。把这三类数据持续采集并关联分析，就能覆盖绝大多数常见入侵场景。

在Linux主机上，认证日志主要集中在/var/log/secure（RedHat系）或/var/log/auth.log（Debian系）。进程信息通过ps、top、/proc目录获取，网络连接通过ss或netstat查看。文件变动则需要借助inotify机制或第三方工具如auditd来监控。在Windows主机上，安全事件日志中的4624、4625、4672等事件ID对应登录成功、登录失败和特权分配，进程和网络连接可以通过PowerShell的Get-Process、Get-NetTCPConnection命令采集，文件系统监控则可以启用对象访问审计策略。

登录行为检测：从失败阈值到地理围栏

暴力破解是最常见的入侵前奏。检测逻辑不能只看“失败次数多”，因为正常用户输错密码和攻击者批量尝试在单次数量上可能接近。一个更可靠的基线是：同一源IP在5分钟内对同一账户或不同账户的失败登录超过10次，或者对不存在的账户尝试登录超过5次，就触发告警。Linux下可以直接用一条awk命令统计secure日志中的失败记录：

awk '/Failed password/ {print $(NF-3)}' /var/log/secure | sort | uniq -c | sort -nr | head

这条命令会输出失败登录次数最多的来源IP。但仅靠失败次数还不够，还要结合成功登录后的行为。如果某个账户在凌晨3点从异地IP登录成功，且该账户历史上从未在这个时间段活跃过，这比连续失败更值得警惕。检测方案中应当维护一个账户登录的时间与IP基线表，可以用last命令的历史数据建立。对于Windows，可以通过事件ID 4625的聚合查询来定位爆破源，PowerShell示例：

Get-WinEvent -FilterHashtable @{LogName='Security';Id=4625} -MaxEvents 1000 |
Group-Object -Property @{Expression={$_.Properties[19].Value}} |
Select-Object Count,Name | Sort-Object Count -Descending

这条命令按源IP聚合最近1000条登录失败事件。实际部署时建议把阈值、时间窗口和告警方式写入自动化脚本，而不是人工定期跑命令。

进程与网络行为检测：识别Webshell和反弹Shell

Webshell的本质是一个由Web服务进程（如php-fpm、apache、nginx worker）执行的异常子进程或脚本。检测的关键在于找出“Web进程不应该执行的命令”。例如，一个PHP站点正常情况下不会由www-data用户启动/bin/sh去执行whoami或id命令。Linux下可以用auditd监控execve系统调用，过滤出由Web进程用户触发的可疑命令：

-a always,exit -F arch=b64 -S execve -F uid=33 -k webexec

其中uid=33通常是www-data的UID。当audit日志中出现/bin/sh、/bin/bash、curl、wget、nc等命令时，就需要人工确认。另一个更直接的检测点是网络连接方向。正常Web服务器只监听80和443端口，对外主动发起连接到非常用端口的行为高度可疑。用ss命令持续记录ESTABLISHED状态的连接：

ss -tanp | grep ESTAB | grep -v ':80\|:443'

如果发现www-data进程连接到某个境外IP的4444端口，基本可以判定为反弹Shell。Windows主机上，IIS的w3wp.exe进程如果启动了cmd.exe或powershell.exe子进程，同样属于高危信号，可以通过Sysmon的进程创建事件（Event ID 1）来捕获父子进程关系。

文件完整性监控：锁定关键目录和文件属性

攻击者上传Webshell后，文件系统一定会发生变化。但全盘监控所有文件变动会产生海量噪音，也没有必要。基础方案应当聚焦三类路径：Web根目录、系统命令目录、计划任务与启动项目录。Linux下Web根目录通常是/var/www/html或/home/wwwroot，系统命令目录包括/usr/bin、/usr/sbin、/bin、/sbin，计划任务在/var/spool/cron和/etc/cron.*。使用inotifywait可以实时监控这些目录的创建、修改和删除事件：

inotifywait -m -r -e create,modify,delete /var/www/html /usr/bin /etc/cron.d

但inotifywait本身不记录文件内容变化前后的哈希值。更可靠的做法是部署AIDE或Tripwire这类文件完整性工具，先对关键目录建立哈希数据库，之后定期比对。AIDE配置示例：

/etc p+i+n+u+g+s+m+c+md5
/var/www p+i+n+u+g+s+m+c+md5
/usr/bin p+i+n+u+g+s+m+c+sha256

这样任何权限、属主、内容哈希的变化都会被记录。Windows下可以启用文件系统对象访问审计，或者使用PowerShell脚本定期计算关键目录的哈希值并与基线比对。需要注意的是，文件监控的告警必须有人响应，否则攻击者修改文件后一周才被发现，检测就失去了意义。

检测基线建立与告警分级

所有检测规则都依赖一个前提：知道什么是“正常”。因此方案落地的第一步不是写规则，而是花三到七天时间采集主机在正常业务状态下的行为数据。记录每天有哪些账户登录、从哪些IP登录、Web进程正常启动哪些子进程、哪些文件在业务更新时会发生变化。把这些数据整理成基线后，检测规则才能区分“业务更新导致的文件变动”和“攻击者上传后门导致的文件变动”。

告警至少要分三级。一级是明确恶意行为，比如Web进程启动/bin/sh并外联非常用端口、root账户从陌生IP登录成功、关键系统二进制文件哈希变化，这类告警需要立即通知并阻断。二级是可疑行为，比如短时间内多次登录失败、非业务时段的管理员登录、Web根目录出现.php或.jsp新文件，这类需要人工核实。三级是信息记录，比如常规业务文件更新、计划任务正常执行，这类不触发通知但保留日志用于事后追溯。分级不清会导致告警疲劳，最终所有告警都被忽略。

日志集中与自动化响应

单台主机上的检测脚本再完善，如果日志只存在本机，攻击者拿到root权限后第一件事就是清理日志。因此基础方案必须包含日志集中。可以通过rsyslog或Winlogbeat把主机的认证日志、audit日志、文件监控日志实时转发到一台独立的日志服务器。日志服务器不运行任何对外业务，只接收和存储日志，并运行检测规则。这样即使业务主机被完全控制，攻击者也无法抹掉已经发出去的日志记录。

自动化响应方面，基础方案至少要实现两条：对触发一级告警的源IP自动加入主机防火墙黑名单；对检测到的Webshell文件自动隔离并记录原始路径和哈希。Linux下可以用fail2ban实现登录爆破IP的自动封禁，但fail2ban默认只处理SSH，需要扩展配置来覆盖Web应用的认证失败。对于Webshell文件，可以在文件监控脚本中加入移动操作，把可疑文件移到隔离目录并保留元数据。

方案落地的优先级排序

如果资源有限，按以下顺序实施：第一步部署登录失败检测和异常登录告警，这是成本最低、见效最快的措施。第二步配置auditd或Sysmon采集进程创建和网络连接日志，并集中存储。第三步对Web根目录和系统命令目录做文件完整性监控。第四步建立告警分级和自动化响应。第五步根据积累的告警数据持续优化检测规则，减少误报。每一步都可以独立运行，不需要等全部完成才产生价值。

主机入侵检测不是一次性项目，而是持续运营的过程。攻击手法在变，业务系统在变，检测规则就必须跟着变。把基础方案跑起来，让每一条告警都能被看到和处理，比追求复杂的机器学习检测模型重要得多。