Написал статью по настройке дефолтного web сервера на Centos 8 с apache, php и mysql. Классический lamp сервер. Немного кастомизации от меня для удобства и в конце специально для любителей selinux его настройка. Хотя если бы я его выключил, то получил как минимум в 2 раза больше комментариев, где каждый второй был бы на тему того, что автор нуб, раз отключает selinux, как и разработчики kubespray, gitlab, freepbx, bitrix и т.д.
https://serveradmin.ru/ustanovka-lamp-apache-php-mysql-v-centos-8/

#статья #centos #apache #webserver

Вы никогда не задавались вопросом, почему известный веб сервер в одних дистрибутивах именуется apache (Debian, Ubuntu), а в других httpd (Centos, RHEL, Fedora)? Меня всегда это интересовало, пока в итоге не разобрался, почему так. Поделюсь с вами.

Разработкой веб сервера занимается организация Apache Foundation, а сам продукт внутри организации называется Apache HTTP Server. Для краткости в Unix его стали называть Apache httpd (http daemon), добавив d на конец, как это происходит со многими службами (sshd, rsyslogd, crond и т.д.). В Debian и производных прижилось именование apache из первой части названия.

Название httpd появилось в системах от RedHat. Зачем они это сделали - не понятно. Я не нашёл информации на тему того, чем их не устроило уже имевшееся название программы в виде apache. Но если разобраться, то под брендом apache существует множество продуктов. Именование httpd выглядит более логичным, хотя и не строго, так как службы http тоже могут быть разными. В общем, тут есть предпосылки для разночтений.

Если я не ошибаюсь, то название пакета httpd есть и в MacOS. Возможно именно они первые стали использовать это имя, а RedHat подхватили. Выяснить наверняка не удалось.

Такая вот историческая справка. Я сначала сам путался, когда только начинал администрировать. Не сразу понял, что это одно и то же, хотя по структуре конфига понятно, что что-то похожее. И в комментариях к своим статьям с веб серверами видел вопросы на тему apache и httpd. Некоторые новички реально путаются и не понимают, что httpd это apache и есть.

#webserver #apache #httpd

​​Проработал ещё один документ по безопасной настройки от CIS. На этот раз на тему Apache 2.4. Изучил 217 😱 страниц документа и постарался сделать универсальную краткую выжимку для постоянного использования. Те параметры, что есть в рекомендациях, но по умолчанию уже настроены, я не упоминаю.

📌 Как обычно, первая рекомендация по настройке — проверить список модулей и отключить ненужные. В зависимости от дистрибутива, команда на запуск бинарника может быть разная. В Debian и Ubuntu — apache2ctl, в Centos и клонах — httpd или apachectl.
# apache2ctl -M
Описание модулей можно посмотреть в документации. Для отключения комментируем строку с LoadModule и именем модуля в конфигурационном файле. Здесь же стоит убедиться, что:
◽модуль логирования log_config_module загружен;
◽модули, связанные с webdav (имеют dav в названии), отключены, если не нужны.
◽модуль статистики status_module отключен, если не используется, либо настроен, чтобы исключить доступ к статистике посторонним.
◽модуль autoindex_module отключен, он позволяет выполнять листинг директорий с файлами, если не задана индексная страница (index.html и т.д.)
◽отключены модули проксирования (proxy в названии), если не используются;
◽отключён модуль mod_info, который выводит информацию о сервере;

📌 Не используйте модуль mod_auth_basic, если доступ к сайту по http. В этом случае учётные данные передаются по сети в открытом виде и могут быть перехвачены кем угодно по пути следования пакетов.

📌 Обратите внимание на параметры для директорий AllowOverride и AllowOverrideList. Они разрешают или запрещают использование различных настроек для файлов конфигураций .htaccess, которые могут переопределять многие настройки сервера. По умолчанию подобные разрешения имеет смысл отключить и включать только точечно.
<Directory />
. . .
AllowOverride None
. . .
</Directory>

📌 Для корневой системной директории отключите все Options. По умолчанию включена опция FollowSymLinks.
<Directory />
. . .
Options None
. . .
</Directory>

📌 Традиционная рекомендация по настройке любого веб сервера — удалите весь контент, что идёт по умолчанию с установочным пакетом. Это относится к стартовой странице, страницам с кодами ошибок и т.д. Всё это помогает определить версию системы и веб сервера. Для apache это обычно директории /var/www/html и /usr/share/apache2/error/.

📌 Отключите всё, что касается cgi скриптов, если вы их не используете. Выполнение этих скриптов — наследие прошлого и сейчас чаще всего не используется, но может быть включено по умолчанию. Отключите модуль mod_cgi и настройки с упоминанием алиаса /cgi-bin/ или опции ExecCGI.

📌 Веб клиенты не должны иметь доступ к файлам .htaccess, .htpasswd и .htgroup. Обязательно настройте для них запрет.
<FilesMatch "^\.ht"> 
Require all denied
</FilesMatch>

📌 Запретите доступ к веб серверу по IP адресу или по несуществующему домену (rewrite_module должен быть включён). Для этого создайте виртуальный хост, который будет первым в списке. И добавьте в него редирект всех, кто обращается не на ваш домен:
RewriteEngine On
RewriteCond %{HTTP_HOST} !^example\.com [NC]
RewriteRule ^.(.*) - [L,F]
Если доменов много, можно сделать редирект тех, кто обращается по IP на любой другой домен:
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^192\.168\.0\.1$
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

📌 Проверьте, что настроено логирование. Как минимум, должен быть включён error лог.
LogLevel notice core:info
ErrorLog "logs/error_log"
Если настроены access логи, не забудьте настроить их ротацию.

📌 По возможности, установите и настройте модуль mod_security. Это популярный web application firewall (WAF).

📌 Не используйте устаревшие версии TLS и Ciphers:
SSLProtocol TLSv1.2 TLSv1.3
SSLHonorCipherOrder On
SSLCipherSuite ALL:!EXP:!NULL:!LOW:!SSLv2:!RC4:!aNULL

📌 Отключите вывод информации о версии сервера:
ServerTokens Prod
ServerSignature Off

📌 Уменьшите дефолтный таймаут запросов:
Timeout 10


#cis #apache #security

У сайтов на Bitrix существует одна особенность. Специально выделил жирным, потому что это такая особенность, что всем особенностям особенность. В админке можно править исходники сайта прямо наживую, в том числе и служебные файлы .htaccess. Любой, кто имеет доступ к админке, может грохнуть сайт. И это время от времени случается.

Вчера грохнули сайт по похожей схеме. Сеошник добавлял редиректы правкой .htaccess через админку. Редиректов там сотни. Сайт очень старый. Его развивали и поддерживали за последние лет 10 несколько разных компаний и программистов. Правку файлов тоже на постоянной основе делают несколько человек - как минимум сеошник и контент менеджер.

Из-за ошибки в .htaccess апач на каждый запрос отдавал 500-ю ошибку. Это я уже потом узнал. Сначала зашёл на сервер, сразу посмотрел изменения за последние сутки:

# find /home/bitrix/ext_www/site01 -mtime -1 -ls

Когда увидел в списке файлов .htaccess сразу на него подумал. Сходил на бэкап сервер, забрал оттуда предыдущую версию файла. Он очень большой, так что глазами разницу не видно. Сравнил так:

# sdiff /root/restored/.htaccess /home/bitrix/ext_www/site01/.htaccess

Увидел много изменений. Сразу вернул прошлую версию файла. Сайт ожил. Я посмотрел на внесённые изменения. Сходил, проверил синтаксис через публичный сервис:

⇨ http://www.htaccesscheck.com (полезный, стоит сохранить)

Забавное вступительное слово у сервиса:

"Sick of one silly typo in a .htaccess file causing your entire site to be broken?" - "Устали, что банальная опечатка в .htaccess, роняет весь сайт?"

Это такая фишка Апача. И плюс, и минус одновременно.

Сервис показал ошибку. Один url, куда был направлен 301 редирект, был некорректный по формату. Из-за этого Apache на все запросы возвращал 500-ю ошибку. Я удивился от этого. Не припоминаю, что сталкивался с этим раньше. Как-то нелогично. Одно дело давать ошибку на конкретный редирект, а другое руинить всю свою работу из-за него.

В общем, файл починил, сеошнику отправил ссылку на сервис, чтобы проверял свои редиректы, прежде чем добавлять их в .htaccess. Как защититься от этого, не знаю. Это уже не первый раз, когда прямой правкой сайта через админку ломают его работу. Теоретически, я конечно знаю, как это можно исправить. Но для масштаба текущего бизнеса это будет неоправданно большой бюджет. Простой даже в несколько часов некритичен и проблем не создаёт. Напрягает это только меня, что приходится вручную решать проблемы. Но, собственно, я для этого туда и нанят.

#bitrix #webserver #apache