Изменяются файлы .htaccess - уязвимость скриптов?

[VEG]

На случай, если приходит что-то от соседа на сервере, у хостера попросил включить безопасный режим - директива safe_mode on.

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

Доступом по FTP после смены всех паролей не пользовался.

Но логи FTP и SSH всё-таки стоит посмотреть.

Проверял полностью все свои файлы на отличие с оригинальным phpbbex v1.5.3 - изменения все мои, "левых" нет.

Как я писал, бэкдор может быть одной неприметной строкой :)
Есть, конечно, вероятность, что если логи хранятся с теми же правами, что и остальные файлы, то кто-то мог удалить оттуда все следы. Но мне кажется, это слишком муторно для злоумышленника. Если не в HTTP, то хотя бы в логах FTP или SSH должно что-то найтись. Если, конечно, вас ломают не через соседнюю площадку.

Стоит подробнее изучить и HTTP логи. Например, на предмет POST запросов к картинкам и другим нетипичным для этого файлам, или странных GET параметров к ним же. Вообще за этот участок времени стоит проверить вообще все POST запросы — какие-то GET параметры светить в логах злоумышленники, возможно, и не хотели бы.

[Алексей]

Но логи FTP и SSH всё-таки стоит посмотреть.

Не даёт мне хостер логи по FTP - настаивает на уязвимость моих скриптов. Может этих логов и вовсе нет. Еще раз попробую попросить у хостера FTP-логи, вообще есть ли такая у меня возможность, очередная попытка - не пытка.

Как я писал, бэкдор может быть одной неприметной строкой :)

Только благодаря вам, Евгений, я с самого первого знакомства с phpbbex начал пользоваться системой управления версиями Mercurial. Теперь от меня не сможет скрыться "ни одна запятая" и даже незаметный формат перевода строк. Большое спасибо вам.

Стоит подробнее изучить и HTTP логи. Например, на предмет POST запросов к картинкам и другим нетипичным для этого файлам, или странных GET параметров к ним же. Вообще за этот участок времени стоит проверить вообще все POST запросы — какие-то GET параметры светить в логах злоумышленники, возможно, и не хотели бы.

Эти логи я уже вдоль и поперёк изучил - никаких подозрительных запросов не было. POST-запросов и GET запросов с параметрами к картинкам тоже не было, проверял своими глазами, и потом ещё с помощью регулярных выражений:
(POST|GET)\s{0,}.+?\.(gif|jpg|png)\?[^\s]+?\s (с GET-параметрами)
(POST)\s{1,}\/[^\s]+?\.(jpg|gif|png)[^\s]*?\s (с/без параметров во всех папках)
(POST)\s{1,}\/images\/[^\s]+?\s (все POST запросы в /images)

И вообще все запросы с параметрами в разных папках:
(POST|GET)\s{1,}\/название_папки\/[^\s]+?\?[^\s]+?\s
и в корневой:
(POST|GET)\s{1,}\/[^\s\/]+?\?[^\s]+?\s

Лог на хостинге можно подправить только с правами root:

В итоге:
1. В логах ничего нет
2. Файлы, кроме .htaccess, не изменились
Вывод: ломали сайт не через POST или GET запросы. Хостер не признается в своей вине, что делать дальше, не знаю - буду ждать очередной атаки .

[daftMan]

Может… ну его, этого хостера? Или он сам «развлекается» так? :)

[Алексей]

Может… ну его, этого хостера? Или он сам «развлекается» так? :)

Вроде не похоже, что развлекается. Больше похоже, что не знает где дыра и нужные средства для "отлова" у него не установлены - лога доступа по FTP нету и т.д. В остальном, вроде нормальный хостер - отвечает на вопросы своевременно, пошел нам на уступки, когда мы не вписывались ни в один тариф по кол-ву запросов к базе данных и т.д. Уже приспособились к нему, а другого хостера ещё не знаю какие нас ждут "приключения" и "сюрпризы". По крайней мере в этом году ещё будем пока у него - сдерживать все атаки , а возможно, что и поймаем кого-нибудь .

[Sumanai]

когда мы не вписывались ни в один тариф по кол-ву запросов к базе данных

Кто- то это вписывает в тариф и ограничивает? В первый раз такое слышу. Размер БД, число пользователей- да, ограничивают. Но чтобы запросы...

[Алексей]

Sumanai,
у нашего сайта запросов в час около 200 000. В самом максимальном тарифе ограничения 70 000:

[Sumanai]

В самом максимальном тарифе ограничения 70 000:

Теперь буду знать, что некоторые и это ограничивают.

[daftMan]

нужные средства для "отлова" у него не установлены

Да стандартная ситуация. Технические специалисты низкой квалификации про информационную безопасность лишь слышавшие или читавшие в журнале «Game.EXE» (иронизирую, чего уж там).

настаивает на уязвимость моих скриптов

Это очченно хорошая позиция. Так-же займите её и настаивайте на уязвимости их серверов. Что их взломали, а они вместо того что бы заниматься делом отбрехиваются от чего вы страдаете.

а возможно, что и поймаем кого-нибудь .

Успехов вам.

[Алексей]

Чем больше копаю, тем яснее вижу у своего хостера некоторые странности. Движок phpbbex 1.5.3 здесь уже совсем не причем, но опишу эту странность, так как хостер не удовлетворил меня своим ответом и может кто уже сталкивался с этим и даст мне адекватный ответ.

Так вот, вчера задал хостеру вопрос про глюк дублирования файла с паролями "8623803.passwd" через ftp-клиент. Хостер ответил, что один из файлов у него на сервере имеет точку в конце, т.е. это два разных файла - "8623803.passwd" и "8623803.passwd."

Для тестирования, с помощью своего скрипта, создал тестовые файлы с одинаковыми именами "test.htaccess", одному из которых добавил точку в конце. Эти файлы нормально и по-разному отображаются как в ISPManager, так и в ftp-клиенте

Файл "8623803.passwd" создавался с помощью ISPManager при ограничении доступа (базовая аутентификация) к определнной папке и им же, похоже, создался его дубликат, а возможно и хакером(взлом с подменой файлов с паролями) .

В итоге возникают два вопроса:
Почему в ftp-клиенте отображаются два файла с одинаковыми именами - "8623803.passwd", а в ISPManager только один? В каких случаях ISPManager создает этот дублирующий файл? - хостер ответить мне не смог, пожаловался на недостаток сотрудников и т.д.
Может кто уже сталкивался с этим глюком? Что это может быть? Хотя этот вопрос, наверное, надо задать разработчикам ISPManager. А хостера заставить обновить ISPManager до последней версии.

[VEG]

Может быть вам будет интересно: «В Сети зафиксирован массовый взлом серверов на базе Linux»

[Алексей]

Может быть вам будет интересно: «В Сети зафиксирован массовый взлом серверов на базе Linux»

Ответ хостера:
Ничего общего с нашим сервером там не описано.
Более того и ПО у нас другое, не Linux, а FreeBSD и панели перечисленные там у нас не стоят.

Кстати, были опять изменены все файлы .htaccess. Мой скрипт зафиксировал изменения 17.02.2013 в 22:38:00. За это время никаких подозрительных POST или GET запросов не было.
POST-запросы были только такие:

Код: Выделить всё

mchat.php
ucp.php?i=pm&mode=compose&action=post
posting.php?mode=reply&f=27&sid=b3f129c9f4174c1b97919886b0dbf54d&t=7549
ucp.php?mode=login

Были какие-то HEAD запросы к картинкам от USER_AGENT = Python-urllib/2.6, IP = 217.212.231.2:

Код: Выделить всё

HEAD /images/smilies/ucoz_biggrin.gif

, но они должны быть безвредными.


Вовремя не восстановил файлы .htaccess, теперь наш сайт в черном списке у yandex и через браузер opera не пускает пользователей - пишет сайт мошеннический.
Теперь пишу скрипт, чтобы файлы восстанавливались сразу, после обнаружения скриптом в них изменений.

[VEG]

Алексей, если в HTTP вообще ничего подозрительного не появляется, стоило бы попросить хостера хотя бы включить логи FTP и SSH (если они выключены). Не понимаю какая вообще проблема с включением этих логов. HTTP запросов всегда на порядок больше на любом хостинге, FTP и SSH логи не отняли бы много места на диске.
Вообще эта настойчивость и однообразие действий говорит, что работает какая-то автоматизированная система. Если бы кто-то работал вручную, могли бы даже коммит на сервере сделать (если у вас копия репозитория на сервере). А раз система автоматизированная, значит проблема должна быть типовая.

[factotum]

Хмм, как все обернулось. Дыра->бан в поисковиках->минус посетители=?
А винить можно только свою принципиальность. Хотя в свое время тож долго решался уйти от гоудедди, когда их сервера рушили из-за пристрастия владельца к охоте. Ушел и не пожалел. На хетцнере уютно и все как часы

[Алексей]

А винить можно только свою принципиальность.

Больше жадность - всего за 1000р нет ограничений, но зато с дыркой

Ушел и не пожалел. На хетцнере уютно и все как часы

Сделал трассировку до нашего сайта:

Похоже они тоже арендуют там сервера.

Алексей, если в HTTP вообще ничего подозрительного не появляется, стоило бы попросить хостера хотя бы включить логи FTP и SSH (если они выключены). Не понимаю какая вообще проблема с включением этих логов.

Пару раз я уже говорил об этом. Один и тот же ответ - это ваши скрипты, ftp здесь ни причём. Если я опять заикнусь об этом, то уверен, что другого ответа не будет. Возможно, что в этих логах что-то есть, но они не хотят терять клиентов, поэтому ftp-логи - это секретная информация.

В 17.02.2013 14:12 мне прислал хостер сообщение:

В связи с плановыми работами по обновлению программного обеспечения на сервере s8, 18 февраля начиная 1.00 часов по Московскому времени возможны перерывы в работе сайтов.
Максимальная продолжительность работ 2-3 часа.
Приносим свои извинения за временные неудобства.

В 17.02.2013 22:38:00 был взлом. Похоже кто-то подсёк для себя опасность обновления и на последок установил редирект во всех файлах .htaccess.
Надеюсь, что после обновлений на сервере, больше не будет очередного изменения этих файлов. Если опять файлы изменятся, то чтобы все расставить по местам - виноваты скрипты или хостинг, надо будет переехать на пару месяцев на другой хостинг.

[daftMan]

виноваты скрипты или хостинг

Если виноваты скрипты — можно обнаружить следы в логах / лишние инструкции в cron / лишние файлы. И всё. «Дырявость» phpBB, на которую ссылаются многие, — наследие первых версий. О взломах последних версий вообще не слышно.

В вашем случае, с вероятностью в бесконечность, была виновата ТП (тупая п…оддержка), занявшаяся отписками по шаблону вместо помещения вашей площадки в карантин и включения логгирования.

Я может слишком пристрастен, но… пользователь — всегда прав. Т.е. правы вы. А хостер ничерта не делал =(

Больше жадность - всего за 1000р нет ограничений

За эти деньги можно взять VDS или дедик. Только тогда администрировать придётся самому, или нанимать дядю. И ограничений вообще не будет (кроме, пожалуй, трафика).

На хетцнере уютно и все как часы

У хетзнера винчестеры — больное место. На втором месте по проблемности рэйд-контроллеры. Шансов поиметь геммороя из-за этого не так уж и много, но они от этого не становятся нулевыми. Один из хостеров, с которого я ушел, как раз с этим и накололся (откатил меня на пару дней назад, редиска). На хабре периодически проскакивают вопли… Ну да предупреждён — значит вооружен

[Алексей]

За эти деньги можно взять VDS или дедик. Только тогда администрировать придётся самому, или нанимать дядю. И ограничений вообще не будет (кроме, пожалуй, трафика).

Какой хостинг? Я имел в виду - 1000р/год.

[NO SWEAR]

глубоко извиняюсь за мое вмешательство в диалог. по сабжу - а вы не можете использовать свой ресурс без постоянно открытых фтп портах ? нельзя держать их закрытыми ? а когда сами используете клиент для работы с файлами то входить через sftp

[Алексей]

а вы не можете использовать свой ресурс без постоянно открытых фтп портах ? нельзя держать их закрытыми ?

Спасибо за совет. Пытался в ISPManager отключить ftp-aккаунт, но он не отключается. Сейчас напишу об этом хостеру.

а когда сами используете клиент для работы с файлами то входить через sftp

В начале заходил по ftp, но после первого взлома - только через sftp и к тому же пароли чуть ли не каждый день меняю. Поставил также ограничение по IP-адресу, но похоже оно только для ISPManager.

[daftMan]

Я имел в виду - 1000р/год.

Тогда ой Меня переглючило, извините! Подумал, что речь о 1000р/месяц


Кстати, присоединюсь тогда к рекомендации выше — кроме ФТП открытым останется ещё SSH. Может имеет смысл попросить и его закрыть/перенести на отдельный порт?

[VEG]

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