Как безопаснику веб-сервера важно отслеживать и анализировать трафик, поступающий на ваш веб-сервер, в том числе определять основные IP-адреса, чтобы получить представление о структуре трафика и потенциальных угрозах безопасности.
Одним из положительных моментов в определении основных IP-адресов, обращающихся к вашему веб-серверу, является наличие файла(ов) журнала доступа, в котором хранится информация о каждом действии, происходящем на сервере. Читать
Тысячи веб-сайтов взламываются каждый день из-за неверной конфигурации или уязвимого кода.
Web Application Firewall (WAF) – один из лучших способов защитить Ваш веб-сайт от сетевых угроз.
Если ваш веб-сайт доступен в интернете, вы можете использовать онлайновые инструменты, чтобы отсканировать веб-сайт на наличие уязвимостей, чтобы понять, насколько безопасен ваш веб-сайт. Читать
Mod_jk — это модуль или коннектор Apache, который соединяет контейнер сервлетов Apache Tomcat с веб-серверами, такими как Apache, IIS и другими. Mod_jk — это полная замена старого модуля mod_jser, который обрабатывает связь между Tomcat и HTTP-серверами с использованием протокола Apache JServ.
Мы не будем углубляться в работу модуля mod_jk, поскольку это выходит за рамки данной статьи. Вместо этого мы сосредоточимся на том, как интегрировать его с HTTP-сервером Apache.
Узнайте больше о том, как работает mod_jk.
Первым шагом является загрузка модуля mod_jk для Linux и его сборка для веб-сервера Apache. Если вы работаете в Windows, вы найдете предварительно созданный двоичный файл для настройки mod_jk.
Откройте терминал и введите команду:
wget https://dlcdn.apache.org/tomcat/tomcat-connectors/jk/tomcat-connectors-1.2.48-src.tar.gz
После загрузки пакета распакуйте его как:
tar xvf tomcat-connectors-1.2.48-src.tar.gz
Затем перейдите в извлеченный каталог /native как:
cd tomcat-connectors-1.2.48-src/native/
Находясь в собственном каталоге, выполните команду:
./configure -with-apxs=/usr/bin/apxs
Приведенная выше команда устанавливает путь к инструментам apxs для HTTP-сервера Apache. Если вы не знаете расположение инструментов apxs, используйте команду which как:
which apxs /usr/bin/apxs
Если вы получили пустой результат, вам необходимо установить пакет apache dev с помощью команды:
sudo apt install apache2-dev # или yum install httpd-devel
Следующим шагом является создание системного объектного файла для модуля mod_jk.
Используйте команду make в собственном каталоге.
make
После успешного завершения вы должны увидеть каталог apache-2.0, созданный в собственном каталоге.
Вы должны увидеть в каталоге файл mod_jk.so.
Скопируйте файл mod_jk.so в каталог модулей apache. Он должен находиться в /usr/lib/apache2/modules или /etc/httpd/modules.
sudo cp mod_jk.so /usr/lib/apache2/modules/
После того, как мы добавили модуль mod_jk в каталог модулей Apache HTTPD, нам нужно загрузить его, отредактировав файл httpd.conf.
В каталоге conf отредактируйте файл httpd.conf с помощью вашего любимого текстового редактора? например Vim.
vim /etc/apache2/apache2.conf
Затем нам нужно добавить директиву include в файл конфигурации apache для загрузки модуля. Вы можете узнать, как загрузить модули, с помощью grep.
grep -i ^Include /etc/apache2/apache2.conf
Приведенная выше команда выдаст такой результат, как показано:
IncludeOptional mods-enabled/*.load IncludeOptional mods-enabled/*.conf Include ports.conf IncludeOptional conf-enabled/*.conf IncludeOptional sites-enabled/*.conf
Из файла конфигурации выше, модули расположены в каталоге с поддержкой модов.
Перейдите в каталог /etc/apache2/mods-enabled и создайте файл mod_jk.conf.
cd /etc/apache2/mods-enabled/ && sudo touch mods_jk.conf
Внутри файла добавьте следующие записи.
LoadModule jk_module "/usr/lib/apache2/modules/mod_jk.so" JkWorkersFile /etc/apache2/conf-enabled/workers.properties JkShmFile /etc/apache2/logs/mod_jk.shm JkLogFile /etc/apache2/logs/mod_jk.log JkLogLev JkMount /stat/* stat JkMount /* balancer el debug JkLogOptions +forwardKeySize +ForwardURICompat -ForwardDirectories
В JkWorkersFile мы определяем информацию об узле.
JkLogFile определяет расположение файла журнала.
JkLogLevel устанавливает уровень журнала для отладки
В файле воркера, указанном по пути выше, мы определяем информацию о запущенных серверах приложений.
Вот пример конфигурации:
worker.list=stat worker.jk-status.type=status worker.jk-status.read_only=true worker.tomcat_1.type=ajp13 worker.tomcat_1.port=9001 worker.tomcat_1.host=127.0.0.1 worker.tomcat_2.type=ajp13 worker.tomcat_2.port=9002 worker.tomcat_2.host=127.0.0.1 worker.tomcat_3.type=ajp13 worker.tomcat_3.port=9003 worker.tomcat_3.host=1270.0.0.1 worker.list=balancer worker.balancer.type=lb worker.balancer.balance_workers=tomcat_1,tomcat_2,tomcat_3
После этого у вас должен быть установлен и готов к работе модуль mod_jk на сервере Apache.
В этой статье показано, как настроить и использовать модуль mod_jk на сервере HTTPD Apache. Вы можете узнать больше из официальных документов.
Как системный администратор, вам необходимо понимать, что происходит под капотом различных служб в вашей системе. Ведение журнала, вероятно, лучший способ сделать это.
Журналы позволяют собирать информацию о службах и приложениях, запущенных в вашей системе, и сохранять этот журнал в файл для использования в будущем.
Из этой статьи вы узнаете, как собрать подробную информацию о службе Apache Tomcat, включив режим DEBUG.
Чтобы включить ведение журнала отладки для Apache Tomcat в Linux, отредактируйте файл logging.properties. Файл находится в каталоге conf корневой установки Apache Tomcat.
Например:
vim /opt/tomcat/conf/logging.properties.
Найдите следующую запись:
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = FINE
Измените значение с FINE на ALL.
Последняя запись должна быть:
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = ALL
Сохраните файл и закройте. Вам нужно будет перезапустить Tomcat Service, чтобы включить уровни журнала.
Если вам не нужны все сообщения журнала от Tomcat, вы можете установить различные уровни, используя уровни журнала JULI, как:
Вы также можете включить ведение журнала для внутренних компонентов Apache Tomcat, изменив следующие значения на all:
org.apache.catalina.session.level=FINE java.util.logging.ConsoleHandler.level=FINE
на:
java.util.logging.ConsoleHandler.level=ALL
Предположим, вы запускаете Apache Tomcat на машине с Windows. Вы можете использовать предоставленный интерфейс конфигурации для управления уровнями журнала.
Откройте меню «Пуск» и найдите «Настроить Tomcat».
Запустите приложение и перейдите на вкладку ведения журнала. Выберите уровень журнала и установите его на DEBUG.
Затем нажмите «Применить» и перейдите на вкладку «Общие». Наконец, нажмите «Остановить», а затем «Пуск», чтобы перезапустить службу Apache.
В этой статье показано, как включить ведение журнала отладки для Apache Tomcat в системах Windows и Linux.
Спасибо за чтение.
Очень часто при администрировании веб-сервера Apache возникает необходимость настройки режимов обработки адресов URL. Например необходимо, чтобы запросы автоматически перенаправлялись с одного адреса на другой. Также, если нужно, чтобы веб-приложения работали на «чистых» ссылках, то для этого также необходима настройка модуля mod_rewrite. В данной статье на простых примерах будут рассмотрены базовые приёмы обработки перезаписи URL, реализуемой модулем mod_rewrite, на основе которых можно легко построить свои собственные правила и режимы обработки ссылок.
Обычно модуль mod_rewrite уже имеется в базовой поставке Apache и устанавливать его дополнительно не нужно. Остаётся его только включить. Например, для Ubuntu:
$ sudo a2enmod rewrite
Управление работой самого модуля mod_rewrite осуществляется при помощи файла .htaccess. Этот файл предназначен для активации и задействования директив веб-сервера Apache индивидуально для каждого из виртуальных хостов (или доменов).
Итак, для начала необходимо удостовериться, что Apache разрешает обработку файлов .htaccess. В конфигурационном файле Apache /etc/apache2/apache2.conf директива AllowOverride должна иметь значение All в блоке:
Options Indexes FollowSymLinks AllowOverride All Require all granted
Следует заметить, что вместо «/var/www/html» может быть указан и другой каталог, в зависимости от того, как и где настроено расположение корневого каталога виртуальных хостов Apache. Также необходимо проверить, что в файле /etc/sites-enabled/000-default.conf не содержится лишних директив (а лучше их убрать) AllowOverride, противоречащих тем, что установлены в файле apache2.conf. После сохранения всех изменений необходимо перезапустить веб-сервер:
$ sudo systemctl restart apache2
Далее, в начало файла .htaccess нужно добавить директиву:
RewriteEngine on
Она указывает, что Apache должен использовать модуль mod_rewrite для обработки условий и правил перезаписи URL.
Файл .htaccess может быть создан, как уже отмечалось, отдельно для каждого из виртуальных хостов. Обычно его помещают в корневой каталог, в котором находятся файлы требуемого виртуального хоста. В данном руководстве для расположения файла .htaccess будет использоваться каталог /var/www/html/ для глобальной обработки URL на веб-сервере.
Для демонстрации работы модуля mod_rewrite по перезаписи URL страницы, можно эту самую страницу создать (в самом простом варианте) и применить к ней (точнее, к её адресу) простой шаблон перезаписи.
Итак, нужно создать файл HTML-страницы hello.html, которая будет размещаться в каталоге /var/www/html/hello.html со следующим содержимым:
<html> <head> <title>Hello, World</title> </head> <body> <h1>Hello, Worl</h1> </body> </html>
Эта страница будет доступна по адресу ip_server/hello.html. Здесь «ip_server»– это IP-адрес сервера, на котором работает Apache. Вместо IP-адреса также можно использовать и доменное имя при должных настройках.
Особенность в том, что эта страница доступна только если вводить адрес, содержащий «hello.html». Любое другое написание, например «hello» приведёт к ошибке 404 — нет такого документа. Чтобы иметь возможность получать доступ к странице hello.html по «hello» нужно всего лишь настроить перезапись адреса. Редактирование файла .htaccess:
$ sudo nano /var/www/html/.htaccess
После ранее добавленной строки «RewriteEngine on» нужно добавить следующую:
RewriteRule ^hello$ hello.html [NC]
Только после этих изменений в веб-браузере по адресу ip_server/hello страница hello.html будет доступна.
Синтаксис добавленной записи следующий:
В результате, теперь страница hello.html будет доступна по следующим адресам: ip_server/hello, ip_server/Hello и ip_server/hello.html.
Таким образом и происходит перезапись URL модулем mod_rewrite по инструкциям из .htaccess.
Выражения в файле .htaccess, применённые в предыдущей главе — это ничто иное, как правила перезаписи. В общем виде они имеют следующий синтаксис:
RewriteRule pattern substitution [flags]
Здесь RewriteRule – это, собственно, сама директива, pattern – шаблон, задаваемый регулярным выражением. Он предназначен для поиска подстроки. Далее, substitution – это целевой действительный URL. А flags – флаги опций, которые задают определённое специфическое поведение правил.
Самым наглядным и общим примером является перезапись (точнее, упрощение) строки дополнительного запроса. Они используются веб-приложениями для передачи параметров скриптам, по которым нужно получить соответствующий результат. Строки запроса начинаются с символа «?» и заканчиваются символом «&». Например:
http://my-site.ru/results.php?item=shoes&season=summer
Если этот URL очистить с помощью правил перезаписи, то упрощённый вариант будет выглядеть примерно так:
http://my-site.ru/shoes/summer
Это куда как более удобно для восприятия. Подобные результаты очистки URL достигаются наиболее часто используемыми шаблонами перезаписи:
В первом случае нужно создать следующее правило:
RewriteRule ^shoes/summer$ results.php?item=shoes&season=summer
В результате подстрока URL «results.php?item=shoes&season=summer» будет переписываться строкой «shoes/summer».
Второй случай используется, когда нужно оптимизировать используемое правило так, чтобы оно являлось универсальным для разных строк запросов, т. е. с разными параметрами. Для данного примера пусть требуется, чтобы правило обрабатывало строку запросов для нескольких сезонов, а не только для «summer». Для этого нужно сначала определить набор самих параметров, которые должны разделяться символом вертикальной черты «|». После этого можно в регулярном выражении ссылаться на эту группу параметров, используя переменную $1, где «1» — это номер набора. Например:
RewriteRule ^shoes/(summer|winter|autmn|spring) results.php?item=shoes&season=$1
Сопоставление набора символов используется обычно, когда нужно, чтобы пользователи могли открывать чистые ссылки любых других разделов сайта, а не только «shoes», как в данном примере. Для этого нужно:
В результате получится следующее правило:
RewriteRule ^([A-Za-z0-9]+)/(summer|winter|autmn|spring) results.php?item=$1&season=$2
Полученное правило перепишет URL:
http://my-site.ru/results.php?item=hat&season=summer
в следующую чистую ссылку:
Если задать определённое условие с помощью директивы RewriteCond, то если оно выполняется, Apache запустит выполнение правила, следующего сразу за этим условием. Синтаксис RewriteCond следующий:
RewriteCond tststr condition [flags]
Здесь tststr – строка, с которой сравнивается условие. А condition – шаблон, с которым сравнивается строка, заданная в tststr. Дополнительные параметры задаются с помощью флагов flags.
В качестве примера можно создать условие, при котором все запросы к несуществующим страница будут перенаправляться например, на домашнюю страницу:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^admin/(.*)$ /admin/home
Здесь выражение %{REQUEST_FILENAME} выполняет проверку строки запроса. Далее, оператор (!), означающий условие «не», предписывает, что отсутствие требуемого в запросе файла (-f) должно указывать Apache запускать в обработку следующее за этим условием правило перенаправления. Далее выполняется само правило переадресации, которое перенаправляет все запросы на страницу /admin/home.
Пример блокировки всего трафика, кроме поступающего с определённого IP-адреса:
RewriteCond %{REMOTE_ADDR} !^(12.38.57.123)$
RewriteRule (.*) - [F, L]
Здесь флаг «F» запрещает доступ, а флаг «L» – указывает, что данное правило должно выполниться последним.
Для обратного эффекта, т. е. для разрешения запросов с любых IP-адресов кроме 12.38.57.123 нужно перед регулярным выражением записи IP-адреса в определении условия убрать оператор «не» — символ восклицательного знака (!):
RewriteCond %{REMOTE_ADDR} ^(12.38.57.123)$
RewriteRule (.*) - [F, L]
в заключении стоит ещё раз отметить, что были рассмотрены только самые базовые приёмы управления модулем mod_rewrite для веб-сервера Apache. Для более подробного и глубокого освоения написания правили задания условий следует хорошо знать и составлять как регулярные выражения, так и назначение ключевых слов и дополнительных директив
Apache.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Многие говорят, что веб-сервер Apache не обладает достаточной производительностью. Однако, это абсолютно не соответствует действительности. Данное мнение сложилось вследствие искажения оценки объективной особенности Apache – его работу и производительность необходимо скрупулёзно оптимизировать, что не так-то и просто. На самом деле Apache – это очень мощный и очень производительный веб-сервер. Да к тому же ещё так легко масштабируется и адаптируется к различным условиям применения. Однако, это всё в совокупности и является тормозящим фактором, сильно влияющим на производительность. В данной статье речь пойдёт о том, каким образом правильно и эффективно оптимизировать работу и производительность Apache без ущерба выбранной функциональности. Предлагаемые методы являются универсальными, допускается лишь незначительные различия в их реализации, в зависимости от используемой системы Linux.
По-умолчанию практически во всех популярных дистрибутивах Apache поставляется в универсальной комплектации, т. е. снабжён большим набором модулей. Это позволяет использовать его практически для любых веб-приложений.
Однако, если наблюдается недостаточная производительность или слишком большое потребление аппаратных ресурсов (как например памяти), следует выяснить, какие модули Apache для текущей конфигурации никогда не используются и даже не актуальны. Например, для современных, даже самых требовательных веб-приложений требуется не более 10-12 модулей. Не говоря уже о среднестатистических сайтах на WordPress или Drupal.
В данном случае определение и отключение ненужных модулей определяется в соответствии с требованиями для используемых веб-приложений, которые всегда заранее известны. Например, эти требования предоставляются самими разработчиками веб-приложений и доступны в открытом доступе. Также необходимо учитывать, что отключение модуля, который был определён как «неиспользуемый» явно, может негативно повлиять на работу других — «нужных» модулей, поскольку некоторые модули связаны между собой зависимостями. Поэтому при принятии решения об отключении тех или иных модулей необходимо отслеживать их зависимости. Эту информацию легко получить из официальной документации модуля, либо экспериментально. Во втором случае после отключения модуля и перезапуска Apache будет получена ошибка, как например:
Syntax error on line 6 of /etc/apache2/sites-enabled/site-company1: Invalid command ‘DAVLock’, perhaps misspelled or defined by a module not included in server configuration Action ‘configtest’ failed
В данном случае Apache использует модуль, который, в свою очередь, не может задействовать функционал, предоставляемый модулем dav_fs, который был отключен.
В Debian-системах, таких как Ubuntu, модули Apache хранятся в каталоге /etc/apache2/mods-available, а список включенных модулей — в каталоге /etc/apache2/mods-enabled. Отключение модуля выполняется путём удаления соответствующего файла в каталоге mods-enabled, либо можно использовать команду:
$ sudo a2dismod mpm_itk
Аналогичным образом работает и команда включения модулей — a2enmod.
Самыми «прожорливыми» модулями Apache, потребляющими довольно много ресурсов системы являются: Rewrite, SSL, Phyton, PHP, Perl. Если они не используются, то конечно, их следует отключать. Либо заменять другими менее требовательными аналогами. Например, модуль Rewrite можно в большинстве случаев заменить модулем Alias.
Различные сайты написаны на различных языках программирования. Соответственно, для обслуживания HTTP-запросов к ним и их полноценной работы Apache использует интерпретаторы языков. Взаимодействие веб-сервера и интерпретатора обеспечивается соответствующими модулями. Для PHP это mod_php, а для Ruby – mod_rails. Это «стандартные» модули, предоставляемые базовой поставкой Apache. Однако, они разработаны только с учётом обеспечения дополнительной функциональности без каких-либо решений по оптимизации производительности и потребления ресурсов.
Так, например, модуль mod_php способен потреблять около 100 Мб RAM для работы всего одного процесса, обслуживающего как минимум один HTTP-запрос. Следовательно, чем больше запросов, тем больше потребляемая память только от одного PHP-модуля. В данной ситуации в качестве альтернативы, но уже с куда более оптимизированными производительностью и потреблением памяти существует модуль php-fpm. Этот модуль позволяет обрабатывать HTTP-запросы к веб-приложениям, написанным на PHP, используя технологию Fast CGI. Аналогичными решениями являются uWSGI для Python и Unicorn для Ruby.
Дело в том, что при использовании модуля php-fpm и ему подобных, изначально в памяти создаётся постоянный процесс для интерпретатора PHP ( Python или Ruby). И только после этого происходит перенаправление запросов от Apache к этому процессу для дальнейшей обработки. Таким образом, динамический контент обрабатывается всего двумя процессами. При этом потребление памяти может снизиться более чем в 8 раз.
Как было показано выше, один дочерний процесс Apache может использовать 100 Мб RAM и выше. Когда таких процессов слишком много, память системы быстро будет исчерпана и веб-сервер начнёт «тормозить». В конфигурации по-умолчанию для Apache зарезервировано определённое количество процессов, например 30. Для не самого мощного сервера это может быть слишком много. Вообще этот параметр всегда важно тщательно подбирать для конкретной системы.
Для начала важно выяснить, сколько памяти требуется (с небольшим запасом) для корректной и стабильной работы веб-приложения. Затем нужно выделить большую часть свободной памяти веб-серверу. Ситуацию с памятью можно отследить, используя команду top, например:
top -bn 1 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND ... 15015 www-data 20 0 232m 9644 1900 S 0.0 1.6 0:00.02 apache2 15016 www-data 20 0 232m 9644 1900 S 0.0 1.6 0:00.01 apache2 15017 www-data 20 0 232m 9644 1900 S 0.0 1.6 0:00.02 apache2
Как можно видеть, в системе запущено 3 процесса Apache почти по 10 Мб (столбец RES) каждый. Ели этого много для используемой конфигурации, то целесообразно уменьшить количество процессов для одновременно обрабатываемых запросов. Это делается путём изменения соответствующего параметра (или параметров) работы мультипроцессингового модуля Apache – по-умолчанию это mpm_prefork. В системах Ubuntu соответствующий конфигурационный файл находится в /etc/apache2/mods-available и называется mpm_prefork.conf. Нужно изменить значение параметра MaxClients в соответствии с расчитанным значением объёма RAM, которое можно выделить Apache для данной системы. Например, по-умолчанию это значение обычно 25 — 30. Для не самого мощного сервера можно уменьшить до 15 (и даже меньше):
StartServers 3 MinSpareServers 3 MaxSpareServers 5 MaxClients 15 MaxRequestsPerChild 0
Теперь нужно перезагрузить Apache, чтобы сделанные настройки вступили в силу. Конечно, когда количество клиентов достигнет максимального количества, то пользователь просто получит ошибку сервера. Однако, он всегда может перезагрузить страницу и снова получить доступ к серверу (веб-приложению). Поскольку ограничение обслуживающих процессов не позволяет превысить лимит памяти, отведённой Apache, то это никак не скажется на его производительности. Ведь памяти всегда хватает. Это не совсем «демократично» по отношению к пользователям. Однако это лучше, чем бесконечно поддерживать «тормозящие» или полузависшие процессы Apache.
Здесь нет чётких рекомендаций относительно того, кокой именно мультипроцессинговый модуль и для какой конфигурации использовать. Одни из них экономят процессорное время, другие — использование RAM.
Например, по-умолчанию Apache использует универсальный модуль mpm-prefork. Который работает практически со всеми интерпретаторами (PHP, Ruby и т. д.). Однако в качестве альтернативы можно использовать модуль mpm-worker. Который обладает более производительной стратегией управления дочерними процессами. Но данный модуль не поддерживает работу с интерпретаторами PHP и Ruby через стандартные внешние модули, такие как mod-php. Поэтому выбор мультипроцессингового модуля Apache – это очень выверенное и обдуманное решение.
В заключение стоит ещё раз подчеркнуть, что веб-сервер Apache, вопреки устоявшемуся мнению, на самом деле очень мощная, универсальная и высокопроизводительная система с огромным потенциалом. Однако, его раскрытие напрямую зависит от грамотной и тонкой настройки и оптимизации всех компонентов веб-сервера.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.