Странное поведение неизвестного каталога joomla в логе nginx

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-0276

погуглить запрос не осилил?

обновляться надо в реакцию на CVE

Что бы узнать из/на какого хоста делается запрос нужно делать раздельные accessы.

Даже не могу предположить что это, ведь делая аналогичный запрос к каждой из расположенных джумл на сервере я получаю 404 - not found

Значит не к каждой.

com_content&view=article&id=9 com_content - это компонент контента Joomla, а id=9 - порядковый номер статьи/материала. Смотри полную ссылку, что находится в этой статье, какой контент - http://названиесайтанаjoomla/index.php?option=com_content&view=article&id=9

в смысле: в эту статью может быть вставлен какой нибудь скрипт или внешняя ссылка или ещё какая лабуда у которой есть запросы...

Блин, ну джумла и друпал - это же отстой. Неужели кто-то пишет на этом что-то кроме страничек майнкрафт серверов с админами 14 лет? :) Есть же yii, codeign, и другие вроде как, вменяемые фреймворки.

друпал
отстой

обоснуйте

Ну, это если писать.
Друпал-джумлу можно просто запустить с плагинами и поулчить сайт.
Убогий и косой но вполне работоспособный.

Да вот здесь ораторы за меня это сделали:
Дрюпал - говно

Это да. Но какой смысл нести это в продакшен и бизнес? Если это типа аналог «некачества» и «днища».

Не, оно только если «сеет сервера майнкрафта»
Для сайта-визитки лучше уж чистый html чем эта куча PHP.

Не понимаю причем здесь это.

Для ряда остальных участников, поясню, что использую банальную VPS Инфобокса, на которой размещать сайты совершенно случайных людей часто совсем не связанных с ит. Когда я их переманиваю на свой серв, я просто переношу сайт с их старогого хостинга и больше не заморачиваюсь. Один клиент в мес. окупает мне аренду впс. Сервер для веб нужд я более менее настраивать умею, но о том, как выявлять как работают вири не имею ни малейшего представления. -- Тем временем путем разделения access логов удалось выявить джумлу иницирующую запрос. Как понять дальше где и какой это запускает?

Прошу прощения за ошибки в тексте - iPhone исправляет.

Может кто -нибудь все таки поможет выйти на след проблемы?) в канун НГ все должны друг другу помогать))

.. А вот запросы странным образом продолжают идти. Не понимаю, как этот get вообще возникает, когда на сайте никого нет и что это за контент такой, которого нет, но в access.log ответ 200

Help pls

Я думаю что все телепаты на НГ уже в отпуске. Вариантов не много, например, Денис Попов залил на дырявую джумлу шелл и создал свой ботнет для рассылки новогодних поздравлений.

Подскажите хотя бы 1-2 шага, которые можно предпринять чтобы обломать Дениса с НГ:) а то весь лог в его поздравительной записи...

С наступающим!

Прошерстить код на наличие данных uri (т.е. на которые делались запросы). Ясен пень что они скорее всего в base64, можно с них и начать поиск. Лучшим вариантом на будущее будет помещать весь код в git (svn, mercurial, etc), тогда найти любые изменения как два пальца ...

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

Сразу про бэкап:) Два месяца назад переманил человека с этой джумлой на свой впс. Там тогда действительно вирусня была, и при переносе, удалил все base'ы что нашел + все подозрительные файлы. Уже более месяца перестали создаваться левые файлы в каталоге и в логах перестали приходить запросы на них. Сайт успешно был удален из всех списков вири-сайтов.

Объясните мне оленю одно - как этот чертов запрос, тот что продолжает идти в логах от ip самого сервера, возникает сам по себе?? Т.е. Предположил на серевере нулевая активность, но независимо от этого она продолжает делать запросы к самой себе с разной периодичностью до 10 мин. Как она сама себя запускает?!

cron, у php тоже есть шелл, к ней (джумле) могут обращаться извне для этого. Проверьте htaccess и прочее. Для особо терпеливых можно сверить контрольные суммы с оригинальной версией той же джумлы и просматривать разницу.

Cron чистый, слежу за ним с самого начала. htaccess нет, тк в работе только nginx в связке php-fpm+mysql.

Основные файлы данной Джумлы тоже проверял - все в порядке. Исходя из запроса: //index.php?option=com_content&view=article&id=9 искал гадость даже в таблицах бд - все тщетно:( повторюсь, мне при подобном запросе (не с сервера) отдает 404.

С радостью бы переустановил эту гребанную джумлу, но у клиента там комм. проект и сама джумла слеплена с кучей разных плагинов, да плюс приурочен мега кривой шаблон (чувствуется и прикручен ели ели) - так что в следствии этих факторов варианта с переустановкой нет( Избавиться бы хоть от этой гадости и пусть живет себе дальше, а пока весь лог в этом 'Г'..

Ну тогда сделать дамп (tcpdump/wireshark/etc) и посмотреть что за user-agent и прочее передаются что бы получить ответ 200. Смодулировать его (делать все это лучше на отдельном хосте), все это может дать наводки по каким критериям искать. Я встречал даже встраивние кода в eval с обфускацией в редакторы всяких джумл (все это в бд). Так что можно искать довольно долго. Хорошо смеется тот, у кого бекап как говориться, но с другой стороны заливка сюрприза может долгое время оставаться незамеченной, всё зависит лишь от опыта и фантазии.

Бог мой, сколько же непонятных понятий в вашем сообщении для такого делитанта как я.. Начинаю гуглить, но буду признателен подсказкам по конкретным командам..

Да проблема в том что на поиск может уйти не один час, и намного больше. Поэтому команды зависят от того как искать. Вкратце: нужно понять что передается для того, что бы получить 200 ok. А также важно просмотреть ответ. Это если хочется разобраться, а можно просто grep-ать по наиболее часто используемым схемам скрытия кода и удалять лишнее.

Покажите несколько кусков лога с беспокоящей вас строкой. Интересуют строки перед этой строкой.
И error.log для тех моментов когда в access появляется эта строка.

Поздравляю всех с Новым годом! Пусть этот год будет лучше, чем предыдущий!

MrClon, Благодаря Вашему сообщению удалось вычислить логику появления возникновения этого странного запроса. А именно, он появляется в аксессе в тот момент, когда сервер отдает '500 код', например на несуществующий favicon.ico, хотя как ни странно при запросе на favicon.oci тоже отдает 500, получается, что при коде 500 отображается стандартная страница Джумлы файл не найден. А при коде 404, выдает no input file selected (подозреваю потому что по умолчанию в конфигн nginx не прописал). Собственно, выкладываю часть лога, наглядно показывающую ситуацию:

83.220.239.47 - - [05/Jan/2014:04:27:39 +0400] "GET /test.php HTTP/1.1" 404 56 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 7_0_4 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11B554a Safari/9537.53"
83.220.239.47 - - [05/Jan/2014:04:29:28 +0400] "GET /trst.php HTTP/1.1" 404 56 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 7_0_4 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11B554a Safari/9537.53"
IP-СЕРВЕРА - - [05/Jan/2014:04:29:49 +0400] "GET //index.php?option=com_content&view=article&id=9 HTTP/1.0" 200 17354 "-" "-"
83.220.239.47 - - [05/Jan/2014:04:29:49 +0400] "GET /test.jpg HTTP/1.1" 500 17382 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 7_0_4 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11B554a Safari/9537.53"

Как так то?! Почему одни запросы 404, другие 500?

В error.log есть только стандартные записи по 404:

2014/01/05 04:27:39 [error] 19162#0: *200101 FastCGI sent in stderr: "Unable to open primary script: /home/cm/rolls/www/trst.php (No such file or directory)" while reading response header from upstream, client: 83.220.239.47, server: адрес_сайта, request: "GET /trst.php HTTP/1.1", upstream: "fastcgi://unix:/tmp/php5-fpm.sock:", host: "адрес_сайта"
2014/01/05 04:29:28 [error] 19162#0: *200105 FastCGI sent in stderr: "Unable to open primary script: /home/cm/rolls/www/trst.php (No such file or directory)" while reading response header from upstream, client: 83.220.239.47, server: адрес_сайта, request: "GET /trst.php HTTP/1.1", upstream: "fastcgi://unix:/tmp/php5-fpm.sock:", host: "адрес_сайта"

Могу предположить что запрос /test.jpg обрабатывается не как файл, а как скрипт (например через rewrite подменяется на какой-нибудь /index.php). Нужно найти этот скрипт и посмотреть что он делает.

может это мой конфиг? но вроде бы нет...

[root@habar conf.d]# cat rolls.conf
server {
    listen       80;
    server_name  сайт.ру ввв.сайт.ру;
    if ($host = 'ввв.сайт.ру' ) {
    rewrite  ^/(.*)$  http://сайт.ру/$1  permanent;
}
    #charset koi8-r;

   access_log /var/log/nginx/rolls.access.log;
   error_log /var/log/nginx/rolls.error.log;

        root   /home/cm/rolls/www;
        index  index.php index.html index.htm;

      
location / {
     try_files  $uri  $uri/  /index.php?$args;
           }
    location ~ \.php$ {
        root           www;
        fastcgi_pass   unix:/tmp/php5-fpm.sock;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  /home/cm/rolls/www$fastcgi_script_name;
        include        fastcgi_params;
     }
  }

#
# HTTPS server configuration
#

server {
    listen       443;
    server_name  сайт.ру ввв.сайт.ру;
    if ($host = 'ввв.сайт.ру' ) {
    rewrite  ^/(.*)$  http://сайт.ру/$1  permanent;
}   
    ssl                  on;
    ssl_certificate /usr/share/nginx/ssl/srvkeynov.crt; 
    ssl_certificate_key /usr/share/nginx/ssl/srvkeynov.key;
#   access_log /var/log/nginx/ssl.access.log;
#   error_log /var/log/nginx/ssl.error.log;

    ssl_session_timeout  5m;

    ssl_protocols  SSLv2 SSLv3 TLSv1;
    ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
    ssl_prefer_server_ciphers   off;

    root   /home/cm/rolls/www;
    index  index.php index.html index.htm;

    location ~ \.php$ {
        root           www;
        fastcgi_pass   unix:/tmp/php5-fpm.sock;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  /home/cm/rolls/www$fastcgi_script_name;
        include        fastcgi_params;
     }
}

и test и trst - это я запрашивал

Не уверен, но попробуй убрать /index.php?$args из try_files и посмотри что будет.

К сожалению, не помогло - весь сайт слег в 500 с отображением белой страницы internal server error и версии nginx:-(

Забавно, но только что обратил внимание, что в данный момент вышеупомянутая мною логика не работает. Т.е. тот же get favicon с кодом ответа 500 уже не вызывает «непонятного» запроса.

Получается, что мне по прежнему неизвестно что же все таки запускает данный

джумла и друпал - это же отстой

Есть же yii, codeign, и другие вроде как, вменяемые фреймворки.

Я один тут считаю, что фреймворк и CMS - это немножко совсем разные вещи?

Нет. И кажется выше это уже обсуждалось. К чему потакать оффтопу?

php скрипты выполняются от того-же пользователя что и nginx? Файлы сайта принадлежат ему-же?
Хорошо-бы подебажить что там такого делает joomla когда вываливает ошибку 500. В жумле есть режим отладки, включи его и покажи что будет при обращении к несуществующему файлу.

php и nginx выполняются от пользователя nginx (группы nginx) pure-ftpd выполняется от ftpsecure (группы nginx) Благодаря данному раскладу, вычисляю какие файлы создаются сами скриптами. Стоит отметить, что 99% процентов файлов сайта идут под юзером фтп. Однако, это ведь не должно доставлять никаких проблем так как все файлы с правами 775, а группа то у них общая!?

Не имею доступа к админке джумлы( сейчас погуглю как сделать ручками..

Как думаете, режим отладки на клиентах то не отразится? а то они как понаполучают notice'ов...

Отразится, понаполучают. Но если сделать всё быстро: включить, проверить, выключить а уже потом думать над результатами пункта два то заметят немногие.

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