kjournald在netstat中出现700次的原因是什么？

这确实是个非常反常的现象——正常情况下，kjournald是Linux内核中负责EXT3文件系统日志处理的本地进程，完全没有理由发起对外网络连接，更别说700次连接到意大利的IP地址了。结合你的环境（Ubuntu 16.04 + EXT4），可以从这几个方向排查：

1. 先确认是不是进程名被恶意伪装 #

Linux下进程名是可以被篡改的，恶意程序经常会伪装成系统进程名来迷惑用户。你可以通过以下命令验证真实进程：

• 执行 ps -ef | grep kjournald 查看进程的完整启动路径和运行用户，正常的kjournald应该以root身份运行，路径指向/sbin/kjournald或内核相关的系统路径；
• 更准确的方式是查看进程的真实可执行文件：找到netstat -tapn中显示的kjournald对应的PID，然后执行 ls -l /proc/<PID>/exe（把<PID>替换成实际的进程ID），这个软链接会直接指向真正在运行的程序，如果显示的不是系统自带的kjournald，那肯定是恶意程序伪装的。

2. 排查是否是连接状态的误判 #

有时候进程已经退出，但网络连接还会以TIME_WAIT状态存在一段时间，但700次这么大的数量基本可以排除这种情况。另外也有可能是PID复用——之前的kjournald进程退出后，新的恶意进程复用了这个PID，导致netstat错误关联了进程名，这时候用上面的/proc/<PID>/exe方法也能快速识别。

3. 若确认是恶意程序，应急处理建议 #

如果排查后确定不是系统原生的kjournald，那你的系统大概率已经被入侵了：

• 立即断开网络，避免恶意程序继续向外传输数据或接收指令；
• 检查系统的可疑启动项：比如/etc/crontab、/etc/init.d/目录下的陌生脚本，以及用户家目录下的.bashrc、.profile等启动文件，看是否有被植入恶意启动代码；
• 用ClamAV等开源杀毒工具对系统进行全面扫描，清理已知的恶意程序；
• 最稳妥的方式是备份重要数据后重装系统，因为被入侵的系统可能存在隐藏的后门，很难彻底清理干净。

关于nmap/telnet扫不通的说明 #

对方的IP可能只接受特定来源的连接请求，或者恶意程序使用了加密隧道、非常规端口，甚至连接是单向发起（比如只发送数据不监听端口），所以nmap和telnet扫不到开放端口是很正常的，不能以此判断连接不存在。

内容的提问来源于stack exchange，提问作者oligofren