Назад | Перейти на главную страницу

имена файлов, включающие шаблон «/ bin / sh», не обслуживаются apache

Я отслеживал ошибку, которую свел к следующему случаю. У нас есть веб-сервер, на котором запущен apache, и он не обслуживает имена файлов, включая шаблон «/ bin / sh», за пределами кампуса, в котором расположен сервер (например, www.example.com/some/sub/folders/bin/show.html. Возможно, это связано с тем, что тот же URL-адрес с https в начале вместо http работает без проблем, если пропустить ошибку сертификации. В нашем приложении сложно изменить все такие имена файлов, поэтому я пытаюсь исправить эту проблему. Как я могу отладить это дальше?

Лог-файл /etc/httpd/logs/access_log показывает несвязанный GET URL-адрес запроса для этого файла. Остальные имена файлов отображаются как есть. Я проверил файлы конфигурации в /etc/httpd/conf и /etc/httpd/conf.d но я не видел ничего связанного, хотя я не знаком с этими файлами конфигурации.

Версия Apache выглядит следующим образом:

# httpd -v
Server version: Apache/2.0.52
Server built:   Oct 29 2008 09:20:05

Любые идеи?

РЕДАКТИРОВАТЬ

Журнал сообщений изнутри кампуса (ответ 304 для обычного кэшированного окна браузера и ответ 200 для частного некэшированного окна браузера):

(ip addr) - - [27/Apr/2017:13:06:45 +0300] "GET /appserv/bin/sh.html HTTP/1.1" 304 - "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0"
(ip addr) - - [27/Apr/2017:13:06:54 +0300] "GET /appserv/bin/sh.html HTTP/1.1" 200 154 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0"

Журнал сообщений извне кампуса (проверено с tor и различными узлами vps):

(ip addr) - - [27/Apr/2017:13:08:08 +0300] "GET /cosbiom/component/option,com_extcalendar/Itemid,99999999/extmode,day/date,2031-02-04/ HTTP/1.1" 200 28936 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)"

Если это работает на территории кампуса, но не извне, то маловероятно, что это проблема с конфигурацией веб-сервера (возможно, но я подозреваю, что такая конфигурация будет довольно очевидной).

Мне кажется более вероятным, что на краю университетской сети есть какой-то брандмауэр на основе проверки, основанный на простом совпадении регулярного выражения. Это не повлияет (в целом) на трафик https (поскольку он зашифрован и не доступен для проверки).

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