Soft

Информация по хосту приложений.

Установка BookStack на VH

Инфо:

Установка BookStack на сервере виртуального хостинга может оказаться проблематичной так как у разных провайдеров используются различные конфигурации, ограничения и т.д. и т.п.

Имея root доступ к серверу на который будет выполняться установка оказывается не такой сложной задачей. 
В примере будет выполнена установка BookStack на сервер с панелькой HestiaCP, для пользователя solaire.

Установка:

1.  Скачиваем последнюю сборку BookStack в ./public_html сайта:

git clone https://github.com/BookStackApp/BookStack.git --branch release --single-branch

2. Переносим все файлы из диры приложения в public_html:

find ./BookStack/ -mindepth 1 -maxdepth 1 -exec mv -t ./ {} +

3. Пользователю, в качестве примера solaire нужно предоставить доступ к composer. Для этого логинимся от root и вызываем команду:

/usr/local/hestia/bin/v-add-user-composer solaire

После чего нужно запустить:

composer install --no-dev

4. Добавим группу веб-сервера для работы с файлами приложения и установим рекомендуемые права:

chown -R solaire:www-data public_html
chmod -R 755 public_html
chmod -R 775 public_html/storage public_html/bootstrap/cache public_html/public/uploads

5. Обратно, от пользователя solaire копируем файл с конфигурацией. Указываем там реквизиты БД и почту:

cp .env.example .env
chmod -R 640 .env
vim .env

6. Генерируем ключ приложения. Он автоматически будем записан в .env файл: php artisan key:generate

7. В настройках панельки HestiaCP нужно поменять пользовательский document root на public, то есть путь будет: /home/solaire/web/book.domain.com/public_html/public

8. Обновляем БД: php artisan migrate

9. Done. Можно войти в панель администратора по реквизитам:

admin@admin.com
password

Защита сайта на базе WordPress

Сайт, работающий на платформе WordPress, требует обеспечения безопасности, поскольку является одной из наиболее популярных и широко используемых систем управления контентом.

Ряд уязвимостей WordPress включает:
Наиболее распространенные причины взлома WordPress:

Обеспечение безопасности WordPress-сайта включает регулярные обновления, использование надежных плагинов и тем, сложные пароли, использование защитных плагинов и мониторинг безопасности.

Для обеспечения безопасности и защиты от уязвимостей следует принять базовые меры:

  1. Уязвимости плагинов и тем:

    • Поддерживайте все плагины и темы в актуальном состоянии, регулярно обновляя их до последних версий.
    • Устанавливайте плагины и темы только из надежных и проверенных источников, чтобы уменьшить риск внедрения вредоносного кода.

  2. Слабые пароли и учетные записи:

    • Используйте сильные и уникальные пароли для всех учетных записей, включая административные.
    • Регулярно меняйте пароли и избегайте повторного использования паролей.
    • Рассмотрите возможность использования плагинов для управления паролями и реализации двухфакторной аутентификации.

  3. Необновленный WordPress:

    • Регулярно проверяйте наличие обновлений для WordPress и его компонентов (плагины, темы).
    • Включите автоматические обновления, чтобы гарантировать, что ваш сайт будет иметь последние исправления уязвимостей.

  4. SQL-инъекции и межсайтовые сценарии (XSS):

    • Используйте фильтры данных и экранируйте пользовательский ввод для предотвращения внедрения вредоносного кода.
    • Используйте параметризованные запросы и подготавливайте данные перед внесением их в базу данных.

  5. Вредоносные программы:

    • Установите надежный антивирус и анти-вредоносное программное обеспечение на сервере.
    • Регулярно сканируйте веб-сайт на наличие вредоносного кода.
    • Ограничьте загрузку файлов на сервер и проверяйте загружаемые файлы на предмет вирусов или вредоносного кода.
Рекомендуемые настройки прав доступа для файлов и папок в WordPress:

  1. Права доступа для файлов: 644

    • Владелец (Owner): Чтение и запись
    • Группа (Group): Чтение
    • Остальные пользователи (Others): Чтение

  2. Права доступа для папок: 755

    • Владелец (Owner): Чтение, запись и выполнение
    • Группа (Group): Чтение и выполнение
    • Остальные пользователи (Others): Чтение и выполнение

Команды для массового изменения прав на папки и файлы:

find ./ -type d -exec chmod 755 {} \;
find ./ -type f -exec chmod 644 {} \;

Дополнительные рекомендации:

Отключение возможности выполнить PHP файлы в определенных каталогах:

Используя файл .htaccess:

Создайте файл .htaccess в каталоге, где вы хотите отключить выполнение PHP файлов, например в ./wp-content/uploads/.

В файл .htaccess добавьте следующий код:

RemoveHandler .php .phtml .php3
RemoveType .php .phtml .php3

или можно использовать этот код:

<Files *.php>
deny from all
</Files>

Этот код отключит обработку файлов с расширением .php, .phtml и .php3 как исполняемых PHP скриптов в выбранном каталоге.

Отключение индексирования и просмотр каталогов:

Используя файл .htaccess:

Внутри файла .htaccess добавьте следующий код:

Options -Indexes

Этот код запрещает серверу отображать список файлов и папок, если в URL указан каталог без конкретного файла.

Nginx \ Apache

Немного о веб-серверах.

Nginx и Apache являются двумя из наиболее популярных веб-серверов, и каждый из них имеет свои особенности и преимущества. Вот основные различия и случаи, когда лучше использовать каждый из них:

    1. Архитектура и производительность:

      • Apache: Apache является модульным веб-сервером, который использует множество процессов или потоков для обработки запросов. Он хорошо подходит для обработки динамического контента, такого как скрипты PHP, и может интегрироваться с различными модулями и расширениями. Однако Apache может быть менее эффективным в обработке большого количества одновременных подключений.

      • Nginx: Nginx является событийно-ориентированным сервером, оптимизированным для обработки большого количества одновременных соединений. Он эффективно обрабатывает статический контент, такой как HTML, CSS и изображения. Кроме того, Nginx также может служить прокси-сервером, балансировщиком нагрузки или кэширующим прокси, что делает его хорошим выбором для обработки статического контента и проксирования запросов к другим серверам.

    2. Конфигурация:

      • Apache: Apache имеет более гибкую и понятную конфигурацию, основанную на файлах .htaccess и конфигурационных файлах сервера. Это позволяет настраивать поведение сервера на уровне отдельных директорий и файлов, что полезно для хостинга с множеством веб-сайтов с разными требованиями.

      • Nginx: Конфигурация Nginx основана на блоках server и location в конфигурационных файлах. Она менее гибкая в сравнении с Apache, но обычно более производительная и легковесная. Однако, для изменения конфигурации Nginx требуется перезапуск или перезагрузка сервера.

    3. Проксирование и балансировка нагрузки:

      • Apache: Apache может работать в режиме прокси-сервера, но его производительность в этой роли может быть ниже, особенно при обработке большого количества одновременных запросов. Apache также поддерживает балансировку нагрузки с помощью модуля mod_proxy_balancer.

      • Nginx: Nginx изначально разработан для работы в качестве прокси-сервера и обратного прокси. Он обладает высокой производительностью и масштабируемостью в роли прокси и может эффективно распределять запросы между несколькими серверами в балансировке нагрузки.

Обработка подключений.

Apache использует модель "один процесс или поток на подключение". Это означает, что для каждого входящего подключения Apache создает новый процесс или поток, который обрабатывает запрос. Когда количество одновременных подключений увеличивается, Apache создает все больше процессов или потоков, что может привести к значительному потреблению памяти и ресурсов системы. Каждый процесс или поток занимает определенное количество памяти, что может привести к исчерпанию ресурсов сервера при очень большом количестве подключений.

Nginx использует событийную модель и асинхронный подход к обработке подключений. Вместо создания отдельного процесса или потока для каждого подключения, Nginx использует неблокирующий ввод-вывод (non-blocking I/O) и мультиплексирование событий для эффективной обработки множества подключений одновременно. Он может эффективно обслуживать множество запросов с помощью небольшого числа рабочих процессов или потоков, что приводит к более экономному использованию ресурсов сервера.

Например:

Apache Nginx + Apache
Каждый новый запрос от клиента инициирует создание нового процесса или потока в Apache для обработки этого запроса. Nginx работает как проксирующий сервер, принимая все входящие запросы от клиентов.
Создание и уничтожение процессов/потоков требует времени и ресурсов операционной системы. Nginx быстро и эффективно обрабатывает статический контент, так как он может возвращать его из своего кэша или передавать напрямую клиенту без обращения к Apache.
При большом количестве одновременных запросов возникает нагрузка на систему в виде создания и управления множеством процессов/потоков, что может вызывать задержки и снижать производительность. Когда Nginx обнаруживает запрос на динамический контент, он перенаправляет его к Apache для обработки.

Apache, в свою очередь, обрабатывает эти динамические запросы, генерирует страницы, выполняет скрипты и обращается к базе данных при необходимости.

Ответы от Apache возвращаются обратно в Nginx, который передает их клиентам.

Такой подход позволяет эффективнее обрабатывать множество подключений по сравнению с просто использованием Apache, поскольку:

Техническое преимущество комбинации Nginx + Apache.

image.png

image.png