Замена отправителя apache в email уведомлениях

Часто при использовании sendmail отправителем почтовых сообщений с сервера становится пользователь, от которого запущен вэб сервер, в нашем случае apache. Для исправления этой ситуации можно применить следующий конфиг: Это в конфиге виртуального хоста apache 1 php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -f [email protected]" Это в конфиге exim 1 trusted_users = apache

28 лютого 2020 · 1 хвилина · 50 слів · dimetrius

SSL между фронтендом и бэкендом через несколько прокси серверов

Сложность в том, что некоторым скриптам необходимо знать через какую схему они работают, http, или https. Таким образом они формируют ссылки, а иногда принудительно перенаправляют клиентов куда нужно. Из-за не верной настройки серверного ПО переадресация не может завершиться и браузер покажет нам ошибку ‘too many redirects’. В статье рассмотрим две схемы: nginx (front1, server2) -> nginx (front2, server1) -> php-fpm (back, server1) nginx (front1, server2) -> nginx (front2, server1) -> apache (back, server1) Первой рассмотрим схему с php-fpm: nginx (front1, server2) -> nginx (front2, server1) -> php-fpm (back, server1) На сервере nginx (front1, server2) у нас обязательно должны быть строки 1 2 3 4 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded_For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; среди которых нам важна последняя. На сервере nginx (front2, server1) в секцию http добавляем 1 2 3 4 5 6 7 8 http { ... map $http_x_forwarded_proto $fastcgi_https { default off; https on; } ... } Если его добавить в любое другое место - получите следующую ошибку при перезапуске nginx: 1 nginx: [emerg] "map" directive is not allowed here Если прописать просто $https вместо $fastcgi_https - получите следующую ошибку: 1 nginx: [emerg] the duplicate "https" variable in /etc/nginx/nginx.conf Дело в том, что начиная с какой-то бородатой версии NginX имеет встроенную переменную $https, поэтому ее повторно использовать не получится. ...

25 вересня 2016 · 3 хвилин · 476 слів · dimetrius

Как переадресовывать HTTP-соединение на HTTPS в apache web-сервере?

Http-соединения могут быть переадресованы на https с помощью модуля apache mod_rewrite, который должен быть доступен в любой версии apache. Создайте файл с именем .htaccess в корневом каталоге сайта, который содержит следующие строки: 1 2 3 RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} Если Вы используете ISPConfig 2 или 3, Вы можете также добавить эти строки в поле директив apache в настройках сайта, вместо их добавления в файл a .htaccess. Но метод с использованием файла .htaccess будет также работать и на ISPCONFIG. Источник Комтет

13 квітня 2016 · 1 хвилина · 84 слів · dimetrius

Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache

В http-сервере Apache найдена опасная уязвимость, позволяющая вызвать отказ в обслуживании через исчерпание всей доступной памяти. Опасность уязвимости усугубляется тем, что для её осуществления уже доступен готовый эксплоит, позволяющий совершить атаку с одной машины с генерацией минимального трафика. При отсутствии отдельных лимитов на размер выделяемой Apache памяти, после выполнения эксплоита наблюдается полное исчерпание памяти с уходом в бесконечный своппинг без возможности зайти в консоль. Проблема вызвана ошибкой в реализации поддержки загрузки части файла по указанному диапазону (например, после обрыва соединения можно запросить загрузку начиная с определенной позиции). Ошибка связана с тем, что при обработке запроса, содержащего большое число диапазонов (например, “Range:bytes=0-,5-1,5-2,5-3,...,5-1000”) в сочетании с использованием gzip-сжатия отдаваемого контента, расходуется слишком много памяти. Например, если в заголовке Range передана тысяча диапазонов, то Apache пытается отдельно сжать каждый диапазон. Так как каждая операция сжатия требует достаточно много памяти (даже для сжатия одного байта выделяется буфер для сжатия блока), в сумме легко исчерпать всю доступную память. Для осуществления удачной атаки достаточно отправить около 50 подобных запросов с составным Range на сервер. Проблема присутствует в Apache 2.2.x, включая последний релиз 2.2.19. Исправление пока доступно в виде патча. Также имеется несколько способов временной защиты, не требующих пересборки Apache. Например, можно принудительно очищать заголовок Range при помощи mod_header ("RequestHeader unset Range" и “RequestHeader unset Request-Range”) или блокировать длинные последовательности Range через mod_rewrite: Вариант 1: 1 2 3 4 5 RewriteEngine On RewriteCond %{HTTP:Range} bytes=0-[0-9]+, [NC,OR] RewriteCond %{HTTP:Range} bytes=([0-9-],){4,} [NC,OR] RewriteCond %{HTTP:Range} bytes=[0-9,-]+,0-(,|$) [NC] RewriteRule .? http://%{SERVER_NAME}/ [NS,L,F] Вариант 2: 1 2 3 4 RewriteEngine On RewriteCond %{REQUEST_METHOD} ^(HEAD|GET) [NC] RewriteCond %{HTTP:Range} ([0-9]*-[0-9]*)(\s*,\s*[0-9]*-[0-9]*)+ RewriteRule .* - [F] Вариант 3: 1 2 3 RewriteEngine On RewriteCond %{HTTP:Range} bytes=0-.* [NC] RewriteRule .? http://%{SERVER_NAME}/ [R=302,L] Интересно, что о теоретической возможности совершения подобной атаки Михаил Залевски (Michal Zalewski), известный польский эксперт в области компьютерной безопасности в настоящее время работающий в Google, сообщал еще 4 года назад, но проблема по каким-то причинам не была воспринята всерьез и исправления не были внесены. ...

13 квітня 2016 · 3 хвилин · 582 слів · dimetrius

Лимиты Apache на VPS сервере

Статья в виде заметки… В файле /etc/httpd/conf/httpd.conf ищем секцию и немного увеличиваем значения (MaxRequestsPerChild лучше наоборот уменьшить). Например, таким образом (по умолчанию настройки слишком зажаты, мы же здесь увеличим лимиты, съедая попутно больше оперативной памяти): 1 2 3 4 5 6 7 8 StartServers 5 MinSpareServers 5 MaxSpareServers 15 ServerLimit 30 MaxClients 30 MaxRequestsPerChild 200 MaxKeepAliveRequests 50 KeepAliveTimeout 5 И, как, обычно, после этого необходимо выполнить 1 # service httpd restart Источник и личный опыт

13 квітня 2016 · 1 хвилина · 75 слів · dimetrius

Получение списка всех виртуальных хостов, определенных во всех файлах конфигурации Apache

Вы когда-нибудь искали, где определён виртуальный хост сайта в файлах конфигурации apache? Существует удобная опция, в виде скрипта apache2ctl, который может помочь в этом вопросе. Если Вы наберёте команду: 1 apache2ctl -S в командной строке, Вы получите список всех виртуальных хостов и серверов по умолчанию, включая номер строки, где они определены. Например: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 # apache2ctl -S VirtualHost configuration: wildcard NameVirtualHosts and _default_ servers: *:8080 is a NameVirtualHost default server ispconfig.local (/etc/apache2/sites-enabled/000-ispconfig.vhost:10) port 8080 namevhost ispconfig.local (/etc/apache2/sites-enabled/000-ispconfig.vhost:10) *:8081 is a NameVirtualHost default server ispconfig.local (/etc/apache2/sites-enabled/000-apps.vhost:10) port 8081 namevhost ispconfig.local (/etc/apache2/sites-enabled/000-apps.vhost:10) *:80 is a NameVirtualHost default server ispconfig.local (/etc/apache2/sites-enabled/000-default:1) port 80 namevhost ispconfig.local (/etc/apache2/sites-enabled/000-default:1) port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.vhost:7) Syntax OK Источник КОМТЕТ

13 квітня 2016 · 1 хвилина · 124 слів · dimetrius