как спрятать версию apache, nginx и php
Зачастую, мы не хотим показывать всем подряд версию софта, установленного на наш сервер.
Если выполнить команду: ** curl -I http://example.com**
мы, скорей всего, увидим версию web сервера и, возможно, еще php, а может, даже узнаем, что за операционная система стоит на нем.
Для того, чтобы скрыть версию nginx, достаточно в секцию http прописать server_tokens off; и перезапустить nginx.
Вот ссылка на официальную документацию
С php тоже несложно. Открываем php.ini, для Ubuntu он находится в /etc/php5/apache2/php.ini, находим строку с expose_php и меняем параметр с On на Off.
Если таковой строки не было, то добавляем соответственно expose_php = Off
Ну и не забываем перезапустить сервис, который крутит php, будь то Apache или fast-cgi, php-fpm, etc.
Для того, чтобы не показывать версию Apache, надо тоже изменить его главный конфиг и добавить в него такие строки:
Скрываем отображение версий Apache, Nginx и PHP
Убрать отображение версии Apache желательно для того, чтобы не попасть на 0-day уязвимости, а так же если вы ежедневно не следите за обновлением ПО и уязвимостями. Скрытие версий конечно не поможет избавиться от уязвимостей (для этого есть другие инструменты), но затруднит работу злоумышленнику.
Для того, чтобы скрыть версию Apache можно поставить модуль libapache-mod-security, который будет скрывать все лишнее. Установим его командой:
apt-get install libapache2-mod-security2
далее включим его:
И отредактируем конфигурацию, изменив или добавив строки в файле /etc/apache2/conf-available/security.conf:
#Выключаем подпись в заголовках ответа сервера (будет просто Apache)
ServerTokens Prod
# Выключаем подпись на служебных страницах (403, 404 и т.д.)
ServerSignature Off
#Запрещаем TRACE метод
TraceEnable Off
Перезапустим Apache:
service apache restart
Следующим шагом скроем версию Nginx. Для скрытия версии Nginx отредактируем файл /etc/nginx/nginx.conf. Добавим в секцию http запрет передачи информации о сервере:
Сохраним конфигурацию и перезапустим Nginx.
service nginx restart
Остается только скрыть версию PHP. Для этого откроем конфигурационный файл /etc/php5/apache2/php.ini и добавим в конфигурацию запрет на передачу информации о PHP.
Теперь вся лишняя информация скрыта. Определить версии установленного ПО можно только по косвенным признакам.
Заказать Аудит Безопасности или Пентест Вашей IT-инфраструктуры
Быть уверенным в своей IT-инфраструктуре – это быть уверенным в завтрашнем дне.
Black Box
Советы по настройке и оптимизации Nginx и PHP-FPM Печать
Изменено: Ср, 6 Май, 2015 at 10:57 AM
От переводчика:
Речь пойдет о тонкостях настройки связки Nginx + PHP-FPM в виде небольшого сборника советов. Перевод вольный. Ориентированно на пользователей Linux.
Советы по настройке и оптимизации Nginx
Совет №1 – Организация файлов конфигурации Nginx
Обычно файлы конфигурации Nginx хранятся в /etc/nginx .
Один из удобных способов организации файлов конфигурации в стиле Debian/Ubuntu Apache:
## Файлы конфигурации вируальных хостов (virtualhost) ##
## Другие файлы конфигурации (если необходимы) ##
Файлы виртуальных хостов разделены на две директории. Директория sites-available может содержать любые файлы: тестовые, старые конфиги, копии конфигов и прочие. А директория sites-enabled содержит только реально работающие конфигурации, в действительности являющиеся только символическими ссылками на файлы в директории sites-available .
Не забудьте добавить следующие строки в файл nginx.conf :
## Загрузка других конфигов из conf.d/ ##
Совет №2 – Определить Nginx worker_processes и worker_connections
Настройки по умолчанию хороши, но их стоит немного оптимизировать: max_clients = worker_processes * worker_connections .
Базовые настройки Nginx могут обрабатывать сотни одновременных соединений:
Обычно 1000 одновременных соединений на один сервер это хорошо, но порою другие части, например жесткий диск могут оказаться медленными и это приведет к тому, что Nginx будет заблокирован на операции ввода-вывода (I/O). Чтобы избежать блокировки используйте, например, следующие настройки: одни worker_process на ядро процессора :
Worker Processes
Чтобы определить сколько ядер имеет ваш процессор, введите:
В данном случае у меня четыре ядра, поэтому окончательный парамерт worker_processes устанавливаем как 4:
Worker Connections
Лично я придерживаюсь 1024 соединений на один воркер, потому что у меня нет никаких оснований для повышения этого значения. Но если например 4096 соединений в секунду не хватает, то можно попробовать удвоить 2048 соединений на процесс.
Окончательные настройки выглядят седующим образом:
Совет №3 – Скрыть токены Nginx / Скрыть номер версии Nginx
Это хорошо из соображений безопасности – скрыть токены Nginx и скрыть номер версии Nginx, тем более если вы используете устаревшую версию Nginx. Это очень легко сделать – достаточно добавить в секцию http/server/location файла конфигурации следующую строку:
Совет №4 – Ограничение на размер передаваемых данных сервером Nginx
Если вы хотите разрешить пользователям загружать файлы, то вы должны увеличить размер сообщения. Это может быть сделано с помощью значения client_max_body_size , которое находится в секции http/server/location файла конфигурации. По умолчанию он равен 1 Мб, но его можно увеличить, например, до 20 Мб, а также увеличить размер буфера:
Если вы получаете сообщение об ошибке, то вы знаете, что client_max_body_size слишком мало:
Совет №5 – Управление кешем для статических файлов
Кэш браузера сохранит ресурсы и пропускную способность вашего сервера. Это несложная настройка Nginx позволит выключить ведение логов ( access log и not found log ), и установить срок истечения заголовка в 360 дней.
Если вы хотите более сложный заголовки или другие типы файлов, то вы можете настроить их отдельно.
Совет №6 – Проксируйте PHP запросы к PHP-FPM
Вы можете использовать по умолчанию стек tcp/ip или соединение через Unix-сокет. Также необходимо установить PHP-FPM слушать точно такой же ip:port или Unix-сокет. Вот очень простой пример конфигурации (вариант с Unix-сокетом закоментирован):
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
Это дает возможность запуска PHP-FPM другим сервером.
Совет №7 – Предотвращение (запрет) доступа к скрытым файлам
Это очень распространено, когда корень сервера или другие публичные каталоги имеют скрытые файлы, которые начинаются с точки (.) И, как правило, они не предназначены для пользователей сайта. Публичный каталог может содержать файлы системы контроля версий: .git , .svn ; файлы IDE: .idea ; .htaccess файлы. Настройки запещают доступ к скрытым файлам и отключают ведение логов:
Советы по настройке и оптимизации PHP-FPM
Совет №1 – Файлы конфигурации PHP-FPM
Обычно конфигурации PHP-FPM расположенны в файле /etc/php-fpm.conf и в каталоге /etc/php-fpm.d/ . Весь пулл конфигов расопложен в дикертории /etc/php-fpm.d/ . Чтобы это работало, вы должны добавить следующую строку в php-fpm.conf :
Совет №2 – Глобальная конфигурация PHP-FPM
Настройки emergency_restart_threshold , emergency_restart_interval и process_control_timeout по умолчанию выключены, но я считаю что их стоит влючить, например, со следующими значениями:
Что это значит? Если 10 дочерних процессов PHP-FPM завршатся с помощью SIGSEGV илиSIGBUS, то PHP-FPM перезагрузится через 1 минуту. А также дочерним процессам установлен лимит времени реакции в 10 секунд на сигнал от мастера.
Совет №3 – Конфигурация пулов PHP-FPM
В PHP-FPM возможно использовать отденьные пулы для каждого сайта и точно распределять ресурсы, а также использовать разных пользователей и разные группы для каждого пула. Приведем примеры конфигураци трех различнх сайтов (или фактически три части одного сайта):
Примеры конфигурации каждого пула:
/etc/php-fpm.d/site.conf
/etc/php-fpm.d/blog.conf
/etc/php-fpm.d/forums.conf
Это просто примеры как настроить несколько различных пулов.
Совет №4 – Конфигурация менеджера процессов (Pool Process Manager) PHP-FPM
Лучший способ использовать менеджер процессов PHP-FPM – это донамическое управление процессами, поэтому PHP-FPM запускает процессы только при необходимости. Это почти такой же подход как в Nginx с параметрами worker_processes и worker_connections . Таким образом большие значения не обеспечивают хорошего результата. Каждый процесс ест определнное количество памяти и, конечно, если у сайта очень большой трафик и много оперативной памяти на сервере, то высокие значения – это правильный выбор. Но такие серверы как VPS обычно имеют ограниченное количество памяти: 256 Мб, 512 Мб, 1024 Мб. Такого небольшого объема ОЗУ достаточно даже для очень большого трафика (даже десятки запросов в секунду), если эту память использовать с умом.
Проверим сколько процессов PHP-FPM позволит легко справляться серверу с нагрузкой. Сначала запустим Nginx и PHP-FPM и загрузим несколько страниц PHP, желательно самые тяжелые. Затем проверим сколько использует памяти процесс PHP-FPM – в Linux можно воспользоваться утилитами top или htop . Предположим что наш сервер имеет 512 Мб оперативной памяти и 220 Мб может быть использованно PHP-FPM, каждый процесс использует 24 Мб оператичной памяти (некоторые CMS с плагинами могут легко кушать 20-40 Мб на один запрос или даже больше). Затем просто вычислим значние max_children для сервера:
Приемлемым значнием pm.max_children будет 9. Это значние основанно на среднем значении и возможно далее его необходимо будет изменить, когда вы заметите длительное время использования памяти процессом. После быстрого тестирования несложно выбрать значния pm.start_servers value , pm.min_spare_servers и pm.max_spare_servers .
Окончательная конфигурация нашего примера может выглядеть следующим образом:
Максималоное количество запросов на процесс по умолчанию не ограничено, но хорошо бы установить какое-нибудь небольшое значение, например 200, и избежать проблем с памятью. Такого вида настрока может обрабарывать большое количество запросов, даже если значение параметра невелико.