nginx поставить

И создать такую же тему про nginx.

этот запрос в отличие от сотни подобных отработал: HTTP Response 200.

так а passwd выдал или нет, вот что интересно.

Это не «атака на апач», это атака на веб-приложение.

Как можно защититься от подобного в дальнейшем?

Можешь от безделья курнуть манов и освоить фильтрацию/рерайтинг по query string.

Если подскажете, как это выяснить, то с удовольствием расскажу ))

passwd он не выдал, ибо запрос был в корень, а из корня идет редирект на https. Мало того насколько понимаю, этот запрос должен содержать в себе уязвимый php, но его в запросе не было вовсе.

Придется все php переписывать с этой фильтрацией? А средствами апача глобально есть возможность запретить запросы с подобным содержанием?

modsecurity или поставь fail2ban чтобы читал accesslog

то что касаемо php - как минимум д.б. одна точка вызова обработки запросов - контроллер всех входящих запросов к сайту

ModSecurity

А что скажете насчет ModSecurity? Эта штука по крайней мере запросы с кучей точек уже не пропустит, не говоря о других защитных функциях.

Я именно об апаче и говорю.

Придется все php переписывать с этой фильтрацией?

Причем тут php?

Причём тут apache? У тебя с PHP проблемы. Запрети ему смотреть куда не следует и поправь скрипты которые по видимому через одно место локализацию подцепляют.

modsecurity

Причем тут PHP если оно в запросе не фигурирует? Апач никуда, кроме разрешенных путей не пускает по настройкам. А вот запросы с точками и другими инородными символами надо запретить/заменить. Вижу одно решение - modsecurity. Но это целая тема, продолжаем тут - ModSecurity что-то не так

Если шарите в нём, помогите пожалуйста с правилом разобраться - ModSecurity что-то не так

passwd он не выдал, ибо запрос был в корень, а из корня идет редирект на https

Тогда бы ответ был бы 3XX а не 200

Ответ ушел в корень сайта, поэтому 200

Ответ ушел в корень сайта, поэтому 200

Тогда бы в логе и был бы корень, а не это

В моём логе отпечаток оригинальных запросов ;) лучше с modsecurity помогите - ModSecurity что-то не так

Ответ ушел в корень сайта, поэтому 200

Это 301 или 302, а не 200. Так что passwd он таки отдал.

Другое дело, что passwd сам по себе бесполезен.

modsecurity тебе не поможет, у тебя дыра на сайте открыта. Ты мало того что не понял до сих пор этого, еще и не понимаешь как работает Apache и PHP. То что ты в Apache прописал Root, Chroot (хотя скорее всего нет) и Directory с Deny all - абсолютно никак не влияет на php. PHP работает в отдельном процессе со своими правами и правилами. Если ты ограничишь PHP на веб папку (как тебе не очень умные люди выше предлагали, это safe mode и open_basedir), то на стандартных CMS и на своих скриптах получишь кучу проблем из серии session отвалился, upload не работает (ибо оно пишет в /tmp и /var/lib), а конфигурировать полностью секьюрити хост ты явно не готов.

В твоем случае выход один: найми админа или программиста с навыками (full stack), потрать денег, пусть тебе отконфигурируют сервер и залатают найденные дыры, не занимайся не своим делом. Учитывая что они есть, я бы сервер под reinstall пустил сначала. В дальнейшем не экономь на нормальных разработчиках и не нанимай украинцев и филиппинцев за плойку риса (или пусть фронтенд пишут на каком-нибудь реакте, он за пределы браузера клиента не выйдет). То чем ты сейчас занимаешься - это прикладываешь подорожник к порванной артерии.

php он вызвал, а именно скрипт index.php

Я советую не париться с такого рода запросами, ибо это сканируют боты! Обновляй свое веб-приложение вовремя (если не самописное) и ничего не бойся

почему это он его отдал? Вот же:

//?lang=../../../../../../../../../etc/passwd%00.png&p_id=60

//?lang=

получается, что

../../../../../../../../../etc/passwd%00.png&p_id=60

это только установка GET-значения lang! А ответ 200, потому что скрипт index.php ответил! А отдал он этот /etc/passwd или нет зависит только от него и если он не уязвим, а он не должен быть уязвим, то злоумышленник ничего не получит

Так что passwd он таки отдал.

Несомненно. А вот еще passwd с гугля: https://www.google.by//?lang=../../../../../../../../../etc/passwd.png&p...

у тебя дыра на сайте

Айти-профессионал детектед.

лучший способ проверить отдает он /etc/passwd или нет - это выполнить этот запрос и поискать в HTML-коде ответа имя существующего пользователя, например root

Ну хоть кто-то в треде с работающим мозгом.

спасибо)

Получается roundcube 1.1.4 по вашему написали украинцы и филиппинцы за плойку риса и в нём одни дыры? Да, в 1.1.3 была такая уязвимость - https://www.htbridge.com/advisory/HTB23283 , но в 1.1.4 её пофиксили. У меня стоит именно 1.1.4 и кроме roundcube более ничего в общем доступе нет ;) Зачем reinstall если есть полные копии контейнера за последние несколько месяцев?

Проверено, root в ответе нет. Passwd он не отдал. От ботов настроил fail2ban к логам apache2, в дальнейшем такие переборы у них займут несколько месяцев )))

Точно, хоть вы ясность внесли, а то уж не ждал ничего дельного ))) Можете сказать что-нибудь полезное про modsecurity?

увы нет - не приходилось использовать. Обращайтесь)

Несомненно. А вот еще passwd с гугля: https://www.google.by//?lang=../../../../../../../../../etc/passwd.png&p...

Я вот тоже не пойму из-за чего здесь панику устроили? :)

это только установка GET-значения lang! А ответ 200, потому что скрипт index.php ответил! А отдал он этот /etc/passwd или нет зависит только от него и если он не уязвим, а он не должен быть уязвим, то злоумышленник ничего не получит

Согласен, мой косяк. Неправильно распарсил про редиректы на https, ответы на другие сканы прочее от автора.

Получается roundcube 1.1.4 по вашему написали украинцы и филиппинцы за плойку риса

Вы удивитесь и дыры эпичные там были. Но они есть в любом софте, главное чтобы не было долго обнаруженных открытых.

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

Получается roundcube 1.1.4 по вашему написали украинцы и филиппинцы за плойку риса

это писал не я