Мы получили POST-запрос к нашему серверу со следующим содержанием:
%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%F%69%6E%70%75%74+%2D%6E
Использование декодирования URL-адресов означает:
cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env file=php://input -n
Вроде похоже на Странные URL-запросы через Nginx в Ubuntu 14.04, что пытается сделать злоумышленник?. По какому сценарию будет работать запрос? Я вижу из журналов, что мы отправили 404, но я хочу убедиться, что у нас нет других ящиков, которые могут быть уязвимы для него.
Много лет назад люди запускали PHP как CGI-скрипт (даже не FastCGI, его еще не было!) Отчасти, чтобы можно было переключить Apache с его низкопроизводительного prefork MPM на новый и несколько более производительный рабочий MPM. (А nginx еще был неизвестен, это было так давно.) Если сервер был настроен для запуска PHP как CGI-скрипта, тогда вы могли бы вызвать интерпретатор PHP прямо по адресу /cgi-bin/php.
Технически PHP все еще можно было установить как CGI, но он оказался не таким производительным, как люди надеялись, поэтому был изобретен FastCGI. Все текущие высокопроизводительные PHP-сайты используют FastCGI / FPM, как правило, с nginx или иногда с MPM событий Apache. FastCGI / FPM не уязвимы для этого, поскольку они не позволяют вызывать PHP напрямую через /cgi-bin.
Если ваш сервер - это не древняя гниющая куча PHP, запущенного как CGI, то вам не нужно беспокоиться об этом запросе.
Общая проблема ввод команды. Упрощено за счет старых небезопасных конфигураций CGI, разрешающих направление выполнения php, хотя современный веб-сервер, который отправил 404, не уязвим специально для этого.
Вы предотвращаете это, удаляя CGI там, где он не нужен, блокируя веб-сервер с правами доступа к файлам и, возможно, SELinux, и защищая свои веб-приложения. Открытый проект тестирования безопасности веб-приложений есть несколько общих советов.
Злоумышленники или пентестеры, которые хотят получить часть вашего вознаграждения за обнаружение ошибок, протестируют ваш веб-сайт на предмет распространенных ошибок, допускаемых при написании веб-приложений или настройке веб-серверов. Эти атаки основываются на том факте, что существует вероятность того, что вы, ваш поставщик, разработчики веб-приложений или ваша ИТ-команда допустили небольшую ошибку или забыли обновлять свое программное обеспечение или конфигурации на случай недавно обнаруженных проблем безопасности, поэтому они просто пытаюсь использовать множество известных проблем против каждого сервера в Интернете. Если вы не обновляете свои системы и не будете в курсе последних проблем безопасности в платформе или программном стеке, которые вы используете, в конечном итоге ваша безопасность (или безопасность ваших посетителей) будет скомпрометирована.
Есть несколько способов защитить ваши веб-приложения от успешной атаки:
Ни один из этих вариантов не имеет 100% гарантии, и я бы рекомендовал использовать все из них.
Чтобы получить исчерпывающий список всех мер безопасности / усиления, которые вы можете предпринять в своей системе centos7, вы можете следовать этому руководству RedHat: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/index/index
Исправление
Дезинфекция
URL-адрес и данные формы необходимо очистить от недопустимых символов. «Черный список» символов - это вариант, но может быть сложно придумать все символы для проверки. Также могут быть некоторые, которые еще не были обнаружены. «Белый список», содержащий только допустимые символы, или список команд должен быть создан для проверки введенных пользователем данных. Пропущенные персонажи, а также неоткрытые угрозы должны быть исключены из этого списка.
Генерический черный список для включения в командную инъекцию может быть
| ; & $ > < ' \ ! >> #Экранировать или фильтровать специальные символы для окон,
( ) < > & * ‘ | = ? ; [ ] ^ ~ ! . ” % @ / \ : + ,Экранировать или фильтровать специальные символы для Linux,
{ } ( ) < > & * ‘ | = ? ; [ ] $ – # ~ ! . ” % / \ : + ,Разрешения
Веб-приложение и его компоненты должны работать со строгими разрешениями, которые не позволяют выполнять команды операционной системы. Попробуйте проверить всю эту информацию, чтобы протестировать ее с точки зрения серого ящика.
https://www.owasp.org/index.php/Testing_for_Command_Injection_(OTG-INPVAL-013)
Также установите modsecurity в Nginx с соблюдением правил comodo.