debian.org / О Debian Где взять Debian Поддержка Уголок разработчика Новости Wiki

Автор Тема: Проконсультируйте, плиз, по апачу (похоже, что бот проломился, но через что?)  (Прочитано 1071 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн yumashka

  • Новичок форума
  • Topic Author
  • Сообщений: 7
Прошу не пиннать сильно, ибо результат вижу, а дырку найти не могу.
Вижу в error.log такое:

(причем у меня для разных сайтов разные файлы логов, а это из заглушки, то есть заголовок Host в запросе не совпадает ни с одним, либо вообще не предоставляется)

[Sun Sep 16 06:42:50.929804 2018] [:error] [pid 9930] [client 50.118.255.25:1532] script '/var/www/html/azenv.php' not found or unable to stat
find: `/etc/lvm/backup': Permission denied
find: `/etc/ssl/private': Permission denied
find: `/root': Permission denied
find: `/lost+found': Permission denied
find: `/proc/tty/driver': Permission denied
find: `/proc/1/task/1/fd': Permission denied
find: `/proc/1/task/1/fdinfo': Permission denied
find: `/proc/1/task/1/ns': Permission denied
find: `/proc/1/fd': Permission denied
find: `/proc/1/map_files': Permission denied
find: `/proc/1/fdinfo': Permission denied
find: `/proc/1/ns': Permission denied
find: `/proc/2/task/2/fd': Permission denied
find: `/proc/2/task/2/fdinfo': Permission denied
find: `/proc/2/task/2/ns': Permission denied

(и еще много таких мест с перебором *.php и кучей find и grep)

В это время ps auxf показывает такое:

www-data 10996  1.1  1.4 468560 122308 ?       S    06:53   0:24  \_ /usr/sbin/apache2 -k start
www-data 10999  0.7  1.0 404712 88700 ?        D    06:53   0:15  \_ /usr/sbin/apache2 -k start
www-data 11003  2.1  1.3 473652 111892 ?       S    06:53   0:47  \_ /usr/sbin/apache2 -k start
www-data 40319  0.0  0.0   4340   812 ?        S    07:26   0:00  |   \_ sh -c find /var/www/wwwmain.imi-samara.ru/.. -type f -name "*" | xargs grep -rl "<head"
www-data 40322  0.6  0.0   7588  2168 ?        S    07:26   0:01  |       \_ find /var/www/wwwmain.imi-samara.ru/.. -type f -name *
www-data 40323  0.1  0.0   4520  1568 ?        S    07:26   0:00  |       \_ xargs grep -rl <head
www-data 46154  3.0  0.0  11260  1124 ?        D    07:30   0:00  |           \_ grep -rl <head

В это время в access.log:

74.195.16.74 - - [16/Sep/2018:06:38:30 +0400] "GET http://data.alexa.com/data/Pq3b012ef000L8?cli=10&dat=snba&ver=7.0&cdt=alx_vw%3D20%26wid%3D9521%26act%3D20000000000%26ss%3D1024x768%26bw%3D1008%26t%3D0%26amznid%3Ddexim-20%26ttl%3D0%26vis%3D1%26rq%3D0&url=https://www.bronzelook.com HTTP/1.0\n" 400 0 "-" "-"
74.195.16.74 - - [16/Sep/2018:06:39:41 +0400] "GET https://www.bronzelook.com HTTP/1.0\n" 400 0 "-" "-"
74.195.16.74 - - [16/Sep/2018:06:39:45 +0400] "GET http://data.alexa.com/data/Pq3b012ef000L8?cli=10&dat=snba&ver=7.0&cdt=alx_vw%3D20%26wid%3D9521%26act%3D20000000000%26ss%3D1024x768%26bw%3D1008%26t%3D0%26amznid%3Ddexim-20%26ttl%3D0%26vis%3D1%26rq%3D0&url=https://www.bronzelook.com HTTP/1.0\n" 400 0 "-" "-"
50.118.255.25 - - [16/Sep/2018:06:42:50 +0400] "GET http://godpay.ru/azenv.php HTTP/1.1" 404 462 "-" "Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.1;Trident/5.0)"
50.118.255.25 - - [16/Sep/2018:06:42:54 +0400] "CONNECT www.alipay.com:443 HTTP/1.1" 405 516 "-" "-"
127.0.0.1 - - [16/Sep/2018:06:48:38 +0400] "OPTIONS * HTTP/1.0" 200 126 "-" "Apache/2.4.10 (Debian) (internal dummy connection)"
127.0.0.1 - - [16/Sep/2018:06:48:39 +0400] "OPTIONS * HTTP/1.0" 200 126 "-" "Apache/2.4.10 (Debian) (internal dummy connection)"
127.0.0.1 - - [16/Sep/2018:06:48:46 +0400] "OPTIONS * HTTP/1.0" 200 126 "-" "Apache/2.4.10 (Debian) (internal dummy connection)"
127.0.0.1 - - [16/Sep/2018:06:48:47 +0400] "OPTIONS * HTTP/1.0" 200 126 "-" "Apache/2.4.10 (Debian) (internal dummy connection)"

В access.logах других сайтов в это время чисто
То есть, я так понимаю, что да, бот проломился и запустил, что хотел.
Хотелось бы выяснить, через кого, на кого похоже.

Сервер сам не шибко древний:
root@vmweb-deb8:~# apt list --upgradable
Listing… Готово
curl/oldstable 7.38.0-4+deb8u12 amd64 [upgradable from: 7.38.0-4+deb8u11]
ghostscript/oldstable 9.06~dfsg-2+deb8u8 amd64 [upgradable from: 9.06~dfsg-2+deb8u7]
libcurl3/oldstable 7.38.0-4+deb8u12 amd64 [upgradable from: 7.38.0-4+deb8u11]
libcurl3-gnutls/oldstable 7.38.0-4+deb8u12 amd64 [upgradable from: 7.38.0-4+deb8u11]
libgs9/oldstable 9.06~dfsg-2+deb8u8 amd64 [upgradable from: 9.06~dfsg-2+deb8u7]
libgs9-common/oldstable 9.06~dfsg-2+deb8u8 all [upgradable from: 9.06~dfsg-2+deb8u7]
openssh-client/oldstable 1:6.7p1-5+deb8u7 amd64 [upgradable from: 1:6.7p1-5+deb8u5]
openssh-server/oldstable 1:6.7p1-5+deb8u7 amd64 [upgradable from: 1:6.7p1-5+deb8u5]
openssh-sftp-server/oldstable 1:6.7p1-5+deb8u7 amd64 [upgradable from: 1:6.7p1-5+deb8u5]

На сервере:
  • несколько сайтов на Wordpress (несколько месяцев не обновлялся, отправил админа обновлять и читать Release Notes на тему RCE),
  • Moodle ну не самый старый, летом обновлял (там вроде давно RCE не было),
  • древняя Joomla (ввобще чужая, обновил до максимальной минорной версии, но там уже major версия +1).
  • Заглушка с чистым index.html
 

Оффлайн endru

  • Главный модератор
  • Ветеран
  • *****
  • Сообщений: 1685
  • Новосибирск
  • Jabber: endru@jabber.ru
Я так понимаю бэкапов вообще нет?
Самые распространенные дыры это:
1) права 777 на файлы.
2) не обновленная WP
3) дыры дополнений WP

возможно яндекс мастер может подсказать проблемные страницы.
скачай антивирус для сайтов, все потенциально опасные файлы он найдет.

на время лечения, лучше отключить эти сайты вообще, чтобы рейтинг сайта не упал к нулям.

Оффлайн yumashka

  • Новичок форума
  • Topic Author
  • Сообщений: 7
Здрасьте. Как это нет? Есть, ежедневные, в три места (включая облако).
Джумлу пока отключу. Вордпрессом админ занимается.

А вот за вопрос спасибо! Навел на мысль: сейчас сравню несколько снепшотов.
 

Оффлайн endru

  • Главный модератор
  • Ветеран
  • *****
  • Сообщений: 1685
  • Новосибирск
  • Jabber: endru@jabber.ru
Судя по тому, что там выполняются скрипты, можно быстренько пробежаться по php
find /path/to/site/ -type f -name "*.php" -exec grep -H exec {} \;все найденные файлы лучше переименовать, на время.

выяснить откуда руки растут скорее всего не получится, т.к. там нужно анализировать access.log за неопределенный срок.

у WP нужно обязательно отключить плагины, оставить только самые необходимые и 100% не имеющие уязвимости.

Оффлайн yumashka

  • Новичок форума
  • Topic Author
  • Сообщений: 7
Ну там по всему сайту не было необходимости искать, на запись апачу доступен только uploads. Ну там пара .php и нашлась.
А вот Джумлу пришлось убить целиком, будем восстанавливать из августовских бэкапов.

Причиной был WPшный плагин ultimatemember. Который еще и скриптов на все страницы надобавлял. Пришлось базу чистить.
 

Русскоязычное сообщество Debian GNU/Linux



Теги: