One place for hosting & domains

      What are the Differences Between IaaS, PaaS and SaaS?


      Cloud technology has become exponentially more important for organizations over time. With a myriad of applications running on different cloud models, some work needs to be done to examine whether these solutions are a best fit to meet a company’s needs effectively and efficiently. Are you sure each application in your portfolio is using the right cloud model for your organization and end-users?

      Cloud computing is primarily comprised of three “as a service” models:

      • Infrastructure as a Service (IaaS)
      • Platform as a Service (PaaS)
      • Software as a Service (SaaS)

      The primary differences between IaaS, PaaS and SaaS essentially boil down to how much of the stack you manage relative to the service provider. Depending on your need for flexibility and customization, each model has its pros and cons. For example, standard, unmanaged IaaS solutions require more monitoring and management than a fully packaged SaaS application, but offer the control and flexibility to deploy virtually any type of workload. The models you’ll choose depend largely on the functions of specific applications and needs of your IT operations.

      IaaS PaaS SaaS

      Below, we explore these models in detail to help you identify which model is best for your organizational requirements.

      Infrastructure as a Service (IaaS)

      IaaS provides a robust ability to distribute a compute stack—servers, storage, networking and operating software—while permitting users to consume only what they need while offloading infrastructure management tasks to their provider, as noted in the figure above. The organization or consumer will control the software (think Virtual Machines) but not the physical infrastructure that the virtual machines run on.

      Example of IaaS Solutions

      IaaS models encompass a wide range of hosted infrastructure: hyperscale public cloud, Dedicated Private Cloud (DPC), Virtual Private Cloud (VPC) and bare metal. IaaS providers you’ll run into (including the one behind the blog your reading):

      • INAP Bare Metal using accessible API
      • Amazon Web Services (AWS)
      • Google Compute
      • Azure

      IaaS Limitations

      As the buyer, you will always want to run a Return on Investment (ROI) formula to ensure your budget, efficiency and workload are on target. Assume that some work time will be needed to train users and administrators as features, products and compute resources change.

      IaaS Exploration

      Ask yourself these questions when contemplating an IaaS solution:

      • Do we have the infrastructure in house to support our users/client base?
      • Would we save financial and individual resources with this model?
      • What are our current redundancy and compliance requirements or goals?

      IaaS with a Managed Service Provider

      Pairing managed services with an IaaS model offers efficiency for organizations looking for the highest security, network throughput, redundancy and cost effectiveness. Whether a company turns to managed services for monitoring, security or to optimize IT infrastructure, working with a managed service provider allows you to concentrate on mission critical applications while the provider manages the backend infrastructure. Managed services can also include network management, capacity planning, performance monitoring, continuous technical support and more.

      Be mindful that different providers offer different levels of services. For example, AWS and Azure fall on the self-managed side, while DPC and VPCs at INAP, on the other hand, are fully managed through the OS level, including monitoring.

      Platform as a Service (PaaS)

      PaaS is a computing platform delivered by a service provider that allows the client to develop, run and manage applications without needing to focus on infrastructure maintenance. The PaaS model is for organizations that do not want to manage or administer the essential foundation of network, hardware, storage and compute nodes, choosing instead to focus on software and application development and consumer use changes and needs.

      In the PaaS model, the solution stack might be a set of components or software subsystems used to develop a fully operational product or service. For example, the service could be a web application that uses an OS, web server, database and programming language. The solution stack might also deliver an OS, database, middleware or application. Your development team and administrators will manage the applications and usually the configuration and settings of the environment in this model, but not the operating system, update patching or hardware assessment.

      The PaaS model is greatly advantageous for a large development team with members working on distinctive and isolated action items in partnership, all without an in-person presence.

      Examples of PaaS Solutions

      • Windows Azure VM
      • Google App Engine
      • Linux Apache Stratos

      PaaS Limitations

      The most acknowledged limitation of the PaaS model is that clients are assigned to the PaaS vendor’s hardware inventory, which may not explicitly decide the application requirements without certain fine-tuning. Be aware that vendor lock-in is commonly cited for PaaS, as well.

      Another limitation is that data protection and network bandwidth are out of your organization’s immediate authority or supervision, which unfortunately could result in adverse unforeseen challenges.

      PaaS Exploration

      Ask yourself these questions when considering a PaaS solution:

      • Do we want to focus developing our applications with efficiency and minimal supervision of the hardware assets?
      • Is our application hardware and network limited to specialized hardware or CPU processors?
      • Can we allow for a minor risk of abrupt but controllable matters?

      Software as a Service (SaaS)

      SaaS is a model to distribute software online. The users of these products interact via a web browser or program interface and have no control of the compute resources, network, storage or operating systems. Users have no need for an IT department to install, perform quality assurance or patch the software being used, allowing them to meet their day-to-day work objectives. The software vendor handles these functions for you.  The software provider hosts the application at its data center.

      There are a few major characteristics that apply to most SaaS vendors:

      • Updates are applied automatically and no need for action on the customer’s end
      • Services are purchased via subscription
      • The customer is not required to install any hardware

      The SaaS model is in place for end users and consumers that have no understanding of (or need to understand) backend development or administration of the applications they use. Ultimately, they just want to open the software and use it with partial configuration, installation and time to learn.

      Examples of SaaS Solutions

      • Hubspot
      • Dropbox
      • Zoom
      • O365

      SaaS Limitations

      There are constraints with the SaaS model, such as unforeseen interruptions for critical patching, and limited end user customization of the software. The SaaS model generally requires specific versions or operating system, web browser or program interface installation that are out of the user’s realm of expertise or knowledge.

      SaaS Exploration

      Ask yourself these questions when considering a SaaS solution:

      • Can the software run in a browser or smart device for the users with limited administration?
      • Will our software be secure and stable for the users while also maintaining normal version releases?
      • Will the end user environment adapt to standard system configurations such as similar operating systems, processor speeds, memory available and internet access?
      • Is the software mission critical for organizations therefore not allowing any downtime?

      If the answer is YES to the last question, then SaaS is perhaps not the right choice for your organization.

      Moving Forward with a Best-Fit Cloud Model

      Consider the tools you are currently using and what makes them run behind the scenes. Many of these solutions are cloud-based and implemented via one of the three models we have described in this article: IaaS, PaaS and SaaS. Are the solutions you currently use modeled in a way that’s optimal for your business?

      If you are considering expanding your online personnel or cloud development, confirm you understand the differences and ask the right questions. Our teams at INAP are always here to help address your needs in the efficient, cost effective and honest guidance, ensuring you find the best-fit cloud model for your company’s needs.

      Explore INAP Cloud.

      LEARN MORE

      Allan Williamson
      • Technical Account Manager


      READ MORE



      Source link

      Automating Server Setup with Ansible: Набор материалов для тренинга DigitalOcean


      Материалы для проведения тренинга по автоматизации настройки сервера с помощью Ansible

      Данный набор материалов для тренинга предназначен для ознакомления технических специалистов с понятиями управления конфигурацией и использованием Ansible для автоматизации настройки инфраструктуры сервера.

      Его цель — предоставление полного набора ресурсов для докладчика при проведении мероприятия и выступления со вступительной речью, посвященной Ansible. Он включает следующее:

      • Слайды и заметки для докладчика, включая короткие демонстрационные видеоматериалы и команды для запуска вспомогательного демонстрационного рабочего приложения. Длительность доклада составляет примерно 50 минут.
      • Репозиторий GitHub, содержащий код демоприложения и необходимые скрипты Ansible для развертывания этого приложения на сервере Ubuntu.
      • Данное руководство, которое знакомит пользователя с процессом развертывания демоприложения Travellist на базе Laravel на удаленном сервере.

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

      Введение

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

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

      Данное руководство, предназначенное для использования вместе со слайдами и замечаниями докладчика набора материалов для тренинга по автоматизации настройки сервера с помощью Ansible, демонстрирует, как настроить inventory-файл и выполнить набор скриптов для полной автоматизации процесса настройки удаленного сервера LEMP (Linux, ENginx, MariaDB и PHP-FPM) на Ubuntu 18.04, а также выполнить развертывание демонстрационного приложения Laravel для данной системы.

      Примечание. Этот материал предназначен для демонстрации использования плейбуков для автоматизации настройки сервера с помощью Ansible. Хотя наше демо включает приложение Laravel, запущенное на сервере LEMP, читатели могут вносить изменения и адаптировать указанную настройку согласно собственным потребностям.

      Предварительные требования

      Для данного обучающего руководства вам потребуется следующее:

      Шаг 1 — Клонирование репозитория с демо

      Прежде всего вам необходимо клонировать репозиторий со скриптами конфигурирования Ansible и демоприложением Laravel, которое мы будем развертывать на удаленных серверах. Все необходимые файлы можно найти в репозитории do-community/ansible-laravel-demo на Github.

      После входа на контрольный узел Ansible с помощью вашего пользователя sudo клонируйте репозиторий и перейдите в директорию, созданную командой git​​:

      • git clone https://github.com/do-community/ansible-laravel-demo.git
      • cd ansible-laravel-demo

      Теперь вы можете запустить команду ls для просмотра содержимого клонированного репозитория:

      • ls -l --group-directories-first

      Вывод будет выглядеть следующим образом:

      ansible-laravel-demo

      drwxrwxr-x 3 sammy sammy 4096 Mar 24 15:24 application
      drwxrwxr-x 2 sammy sammy 4096 Mar 24 15:24 group_vars
      drwxrwxr-x 7 sammy sammy 4096 Mar 24 15:24 roles
      -rw-rw-r-- 1 sammy sammy  102 Mar 24 15:24 inventory-example
      -rw-rw-r-- 1 sammy sammy 1987 Mar 24 15:24 laravel-deploy.yml
      -rw-rw-r-- 1 sammy sammy  794 Mar 24 15:24 laravel-env.j2
      -rw-rw-r-- 1 sammy sammy  920 Mar 24 15:24 readme.md
      -rw-rw-r-- 1 sammy sammy  318 Mar 24 15:24 server-setup.yml
      

      Ниже вы найдете описание каждой из этих папок и файлов и их значения:

      • application/: эта директория содержит демоприложение Laravel, которое будет развернуто на удаленном сервере к концу тренинга.
      • group_vars/: эта директория содержит файлы с переменными, содержащие пользовательские опции настройки приложения, такие как учетные данные базы данных и место хранения файлов приложения на удаленном сервере.
      • roles/: эта директория содержит различные роли Ansible, которые определяют конфигурацию LEMP-сервера на Ubuntu.
      • inventory-example: этот файл может использоваться в качестве основы для создания пользовательского inventory-файла для вашей инфраструктуры.
      • laravel-deploy.yml: этот плейбук будет выполнять развертывание демоприложения Laravel на удаленном сервере.
      • laravel-env.j2: этот шаблон используется плейбуком laravel-deploy.yml для настройки файла среды приложения.
      • readme.md: этот файл содержит общую информацию о конфигурации, содержащейся в этом репозитории.
      • server-setup.yml: этот плейбук будет выполнять конфигурацию сервера LEMP, используя роли, определенные в директории roles/.

      Шаг 2 — Настройка inventory-файла и тестирование подключения к узлам

      Теперь мы создадим inventory-файл для просмотра списка хостов, которые мы будем администрировать с помощью Ansible. Сначала скопируйте файл inventory-example в новый файл с именем hosts:

      • cp inventory-example hosts

      Теперь необходимо воспользоваться текстовым редактором по вашему выбору, чтобы открыть новый inventory-файл и обновить его на ваших серверах. Мы будем использовать nano:

      Пример inventory-файла, который входит в комплект материалов для тренинга, содержит две группы Ansible: dev и production. Это сделано для демонстрации использования переменных групп для настройки развертывания в разных средах. Если вы хотите протестировать эту настройку на отдельном узле, вы можете использовать группу dev или production и удалить другую группу из inventory-файла.

      ansible-laravel-demo/hosts

      [dev]
      203.0.113.0.101
      
      [prod]
      203.0.113.0.102
      
      [all:vars]
      ansible_python_interpreter=/usr/bin/python3
      

      Примечание. Переменная ansible_python_interpreter определяет путь к исполняемому файлу Python на удаленном хосте. Здесь мы просим Ansible задать эту переменную для всех хостов в этом inventory-файле.

      Сохраните и закройте файл после завершения. Если вы использовали nano, нажмите CTRL+X, а затем Y и ENTER для подтверждения.

      После внесения изменений в inventory-файл вы можете запустить модуль ping в Ansible для тестирования возможности подключения узла к хостам:

      • ansible all -i hosts -m ping -u root

      Давайте разберем эту команду:

      • all: эта опция просит Ansible запустить следующую команду для всех хостов из указанного inventory-файла.
      • -i hosts: указывает, какой inventory-файл необходимо использовать. Если эта опция не указана, Ansible будет пытаться использовать inventory-файл по умолчанию, который обычно находится в директории /etc/ansible/hosts.
      • -m ping: эта опция запускает модуль ping в Ansible, который будет тестировать подключение к узлам и проверять, находится ли исполняемый файл Python на удаленных системах.
      • -u root: этот опция указывает, какой удаленный пользователь должен использоваться для подключения к узлам. Здесь мы используем учетную запись root в качестве примера, поскольку это, как правило, единственная учетная запись, доступная на новых серверах. Другие опции подключения могут потребоваться в зависимости от поставщика инфраструктуры и конфигурации SSH.

      Если ваше SSH-подключение к узлам настроено корректно, вы получите следующий вывод:

      Output

      203.0.113.0.101 | SUCCESS => { "changed": false, "ping": "pong" } 203.0.113.0.102 | SUCCESS => { "changed": false, "ping": "pong" }

      Вывод pong означает, что ваш контрольный узел может подключаться к управляемым узлам и что Ansible может выполнять команды Python на удаленных хостах.

      Шаг 3 — Настройка файлов с переменными

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

      Откройте файл group_vars/all в используемом вами текстовом редакторе:

      ansible-laravel-demo/group_vars/all.yml

      ---
      # Initial Server Setup
      remote_user: sammy
      
      # MySQL Setup
      mysql_root_password: MYSQL_ROOT_PASSWORD
      mysql_app_db: travellist
      mysql_app_user: travellist_user
      mysql_app_pass: DB_PASSWORD
      
      # Web Server Setup
      http_host: "{{ ansible_facts.eth0.ipv4.address }}"
      remote_www_root: /var/www
      app_root_dir: travellist-demo
      document_root: "{{ remote_www_root }}/{{ app_root_dir }}/public"
      
      # Laravel Env Variables
      app_name: Travellist
      app_env: dev
      app_debug: true
      app_url: "http://{{ http_host }}"
      db_host: localhost
      db_port: 3306
      db_database: "{{ mysql_app_db }}"
      db_user: "{{ mysql_app_user }}"
      db_pass: "{{ mysql_app_pass }}"
      

      Вам необходимо обратить внимание на следующие переменные:

      • remote_user: указанный пользователь будет создан на удаленном сервере и получит привилегии sudo.
      • mysql_root_password: эта переменная определяет root-пароль базы данных для сервера MariaDB. Обратите внимание, что это должен быть защищенный пароль по вашему выбору.
      • mysql_app_db: имя базы данных, которую необходимо создать для приложения Laravel. Вам не обязательно изменять это значение, но вы можете сделать это, если хотите. Это значение будет использоваться для настройки файла конфигурации Laravel .env.
      • mysql_app_user: имя пользователя базы данных для приложения Laravel. Вам также не обязательно изменять это значение, но вы можете сделать это.
      • mysql_app_pass: пароль базы данных для приложения Laravel. Это должен быть защищенный пароль по вашему выбору.
      • http_host: доменное имя или IP-адрес удаленного хоста. Здесь мы используем факт Ansible, который содержит IPv4-адрес для сетевого интерфейса eth0. Если у вас есть доменные имена, указывающие на ваши удаленные хосты, вы можете создать отдельные файлы с переменными для каждого из них, перезаписав это значение, чтобы конфигурация Nginx содержала корректное имя хоста для каждого сервера.

      Когда вы закончите редактирование этих значений, сохраните и закройте файл.

      Создание дополнительных файлов с переменными для нескольких сред

      Если вы настроили ваш inventory-файл для нескольких узлов, вы, возможно, захотите создать дополнительные файлы с переменными для настройки каждого узла. В нашем примере inventory-файла мы создали две отдельные группы: dev и production. Чтобы избежать использования одних и тех же учетных данных базы данных и других настроек в двух средах, нам необходимо создать отдельный файл для хранения значений группы production.

      Вы, возможно, захотите скопировать файл с переменными по умолчанию и использовать его в качестве основы для ваших значений для группы production:

      • cp group_vars/all.yml group_vars/production.yml
      • nano group_vars/production.yml

      Поскольку файл all.yml содержит значения по умолчанию, которые будут корректными для всех сред, вы можете удалить все переменные, которые не будут изменены, в новом файле production.yml. Переменные, которые вам необходимо обновить для каждой среды, указаны здесь:

      ansible-laravel-demo/group_vars/production

      ---
      # Initial Server Setup
      remote_user: prod_user
      
      # MySQL Setup
      mysql_root_password: MYSQL_PROD_ROOT_PASSWORD
      mysql_app_pass: MYSQL_PROD_APP_PASSWORD
      
      # Laravel Env Variables
      app_env: prod
      app_debug: false
      

      Обратите внимание, что мы изменили значение app_env на prod и задали значение false для app_debug​​​. Это рекомендуемые настройки Laravel для среды production.

      После завершения настройки переменных для production сохраните и закройте файл.

      Шифрование файлов с переменными с помощью Ansible Vault

      Если вы захотите поделиться своей настройкой Ansible с другими пользователями, необходимо обеспечить безопасность учетных данных базы данных и других конфиденциальных данных в ваших файлах с переменными. Это можно сделать с помощью Ansible Vault, утилиты, которая поставляется с Ansible по умолчанию. Ansible Vault позволяет вам шифровать файлы с переменными, чтобы только пользователи с доступом к паролю Vault могли просматривать, изменять или расшифровывать эти файлы. Пароль Vault также требуется для запуска плейбука или команды, которые используют шифрованные файлы.

      Для шифрования вашего файла с переменными для production выполните следующую команду:

      • ansible-vault encrypt group_vars/production.yml

      Вам будет предложено ввести пароль Vault и подтвердить его. После этого, если вы решите просмотреть содержимое этого файла, вы увидите, что данные зашифрованы.

      Если вы хотите просмотреть файл с переменными, не изменяя его содержимое, воспользуйтесь командой view:

      • ansible-vault view group_vars/production.yml

      Вам будет предложено указать тот же пароль, который вы задали при шифровании этого файла с помощью ansible-vault. После предоставления пароля содержимое файла появится в вашем терминале. Чтобы закрыть просмотр файла, введите q.

      Для редактирования файла, который ранее был зашифрован с помощью Ansible Vault, используйте команду edit:

      • ansible-vault edit group_vars/production.yml

      Эта команда будет запрашивать пароль Vault для этого файла. Затем ваш редактор по умолчанию, поддерживающий работу в терминале, будет использован для открытия файла для редактирования. После внесения желаемых изменений сохраните и закройте файл, после чего он снова будет автоматически зашифрован в Ansible Vault​​​.

      Вы успешно завершили настройку ваших файлов с переменными. В следующем шаге мы запустим плейбук для настройки Nginx, PHP-FPM и MariaDB (которые, наряду с операционной системой на базе Linux, например Ubuntu, формируют стек LEMP) на вашем удаленном сервере (или серверах).

      Шаг 4 — Запуск плейбука LEMP

      Перед развертыванием демоприложения Laravel на удаленном сервере (серверах) нам необходимо настроить среду LEMP, которая будет обслуживать приложение. Плейбук server-setup.yml содержит роли Ansible, необходимые для настройки. Чтобы просмотреть его содержимое, выполните следующую команду:

      ansible-laravel-demo/server-setup.yml

      ---
      - hosts: all
        become: true
        roles:
          - { role: setup, tags: ['setup'] }
      
          - { role: mariadb, tags: ['mysql', 'mariadb', 'db', 'lemp'] }
      
          - { role: php, tags: ['php', 'web', 'php-fpm', 'lemp'] }
      
          - { role: nginx, tags: ['nginx', 'web', 'http', 'lemp'] }
      
          - { role: composer, tags: ['composer'] }
      

      Ниже вы найдете обзор всех ролей, включенных в этот плейбук:

      • setup: содержит задачи, необходимые для создания нового пользователя системы и предоставления ему привилегий sudo, а также активации брандмауэра ufw.
      • mariadb: устанавливает сервер базы данных MariaDB и создает базу данных приложения и пользователя.
      • php: устанавливает модули php-fpm и PHP, которые необходимы для запуска приложения Laravel.
      • nginx: устанавливает веб-сервер Nginx и разрешает доступ к порту 80.
      • composer: устанавливает Composer на глобальном уровне.

      Обратите внимание, что мы задали несколько тегов для каждой роли. Это нужно для перезапуска только отдельных частей данного плейбука, если возникнет такая необходимость. Если вы внесете изменения в ваш файл шаблонов Nginx, например, вам может понадобиться только перезапуск роли Nginx.

      Следующая команда будет запускать этот плейбук на всех серверах из вашего inventory-файла. --ask-vault-pass требуется только в случае, если вы использовали ansible-vault для шифрования файлов на предыдущем шаге:

      • ansible-playbook -i hosts server-setup.yml -u root --ask-vault-pass

      Вывод будет выглядеть следующим образом:

      Output

      PLAY [all] ********************************************************************************************** TASK [Gathering Facts] ********************************************************************************** ok: [203.0.113.0.101] ok: [203.0.113.0.102] TASK [setup : Install Prerequisites] ******************************************************************** changed: [203.0.113.0.101] changed: [203.0.113.0.102] ... RUNNING HANDLER [nginx : Reload Nginx] ****************************************************************** changed: [203.0.113.0.101] changed: [203.0.113.0.102] PLAY RECAP ********************************************************************************************** 203.0.113.0.101 : ok=31 changed=27 unreachable=0 failed=0 skipped=0 rescued=0 ignored=1 203.0.113.0.102 : ok=31 changed=27 unreachable=0 failed=0 skipped=0 rescued=0 ignored=1

      Теперь ваш узел (узлы) готов к обслуживанию приложений PHP с помощью Nginx+PHP-FPM и MariaDB в качестве сервера базы данных. В следующем шаге мы будем развертывать демоприложение Laravel, включенное в набор материалов, используя плейбук Ansible laravel-deploy.yml.

      Шаг 5 — Развертывание приложения Laravel

      Теперь, когда у вас есть рабочая среда LEMP на вашем удаленном сервере (серверах), вы можете запустить плейбук laravel-deploy.yml. Этот плейбук выполняет следующие задачи:

      1. Создание корневой директории документов приложения на удаленном сервере, если она еще не была создана.
      2. Синхронизация локальной папки приложения с удаленным сервером с помощью модуля sync.
      3. Настройка с помощью модуля acl разрешений для пользователя www-data при работе с папкой хранилища.
      4. Настройка приложения .env на основе шаблона laravel-env.j2.
      5. Установка зависимостей приложения с помощью Composer.
      6. Создание ключа безопасности приложения.
      7. Создание публичной ссылки для папки storage.
      8. Запуск процессов миграции и пополнения базы данных.

      Плейбук необходимо запускать с помощью пользователя non-root user с привилегиями sudo. Этот пользователь был создан при запуске плейбука server-setup.yml на предыдущем шаге, а его имя задано в переменной remote_user.

      Когда все будет готово, запустите плейбук laravel-deploy.yml с помощью следующей команды:

      • ansible-playbook -i hosts laravel-deploy.yml -u sammy --ask-vault-pass

      --ask-vault-pass требуется только в случае, если вы использовали ansible-vault для шифрования файлов на предыдущем шаге.

      Вывод будет выглядеть следующим образом:

      Output

      PLAY [all] ********************************************************************************************** TASK [Gathering Facts] ********************************************************************************** ok: [203.0.113.0.101] ok: [203.0.113.0.102] TASK [Make sure the remote app root exists and has the right permissions] ******************************* ok: [203.0.113.0.101] ok: [203.0.113.0.102] TASK [Rsync application files to the remote server] ***************************************************** ok: [203.0.113.0.101] ok: [203.0.113.0.102] ... TASK [Run Migrations + Seeders] ************************************************************************* ok: [203.0.113.0.101] ok: [203.0.113.0.102] PLAY RECAP ********************************************************************************************** 203.0.113.0.101 : ok=10 changed=9 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 203.0.113.0.102 : ok=10 changed=9 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

      После завершения выполнения команды вы сможете получить доступ к демоприложению, указав в браузере доменное имя или IP-адрес вашего узла:

      http://node_domain_or_IP
      

      Вы увидите подобную страницу:

      Демоприложение Travellist на базе Laravel

      Заключение

      Это обучающее руководство демонстрирует процесс настройки inventory-файла Ansible и подключения к удаленным узлам, а также запуск плейбуков Ansible для настройки сервера LEMP и развертывания на нем демоприложения Laravel. Данное руководство служит дополнением к слайдам и заметкам для докладчика из набора материалов для тренинга по автоматизации настройки сервера с помощью Ansible и использует репозиторий GitHub, содержащий все необходимые файлы для выполнения демонстрации в рамках тренинга.



      Source link

      Настройка Packet Filter (PF) в FreeBSD 12.1


      Автор выбрал COVID-19 Relief Fund для получения пожертвования в рамках программы Write for DOnations.

      Введение

      Брандмауэр, вероятно, является одной из наиболее важных линий защиты от кибератак. Способность настроить брандмауэр с нуля — это очень важный навык, который позволяет администратору получить контроль над своими сетями.

      Packet Filter (PF) — это известный брандмауэр, поддерживаемый в рамках проекта OpenBSD для обеспечения безопасности. Если быть более точным, это инструмент фильтрации пакетов, как видно из названия, который известен простым синтаксисом, удобством для пользователей и обширным функционалом. PF — это по умолчанию хранящий состояние брандмауэр, помещающий информацию о подключениях в таблице состояния, которую можно использовать в аналитических целях. PF — это часть базовой системы FreeBSD, которая поддерживается активным сообществом разработчиков. Хотя между версиями PF во FreeBSD и OpenBSD существуют различия, связанные с разной архитектурой ядра, в целом они используют один синтаксис. В зависимости от сложности общий набор правил можно изменить, чтобы работать с любым дистрибутивом с минимальными усилиями.

      В этом обучающем руководстве мы выполним сборку брандмауэра с нуля на сервере FreeBSD 12.1 с помощью PF. Вы создадите базовый набор правил, который можно использовать в качестве шаблона для будущих проектов. Также вы познакомитесь с рядом продвинутых функций PF, таких как гигиена пакетов, предотвращение атак brute force, мониторинг и логирование, а также рядом сторонних инструментов.

      Предварительные требования

      Перед началом выполнения этого обучающего руководства вам потребуется следующее:

      • Сервер FreeBSD 12.1 с 1 ГБ памяти (ZFS или UFS). Вы можете воспользоваться нашим руководством по началу работы с FreeBSD для настройки вашего сервера согласно предпочитаемой конфигурации.
      • FreeBSD не имеет активированного по умолчанию брандмауэра, кастомизация — это один из важнейших принципов FreeBSD. Таким образом, при первом запуске вашего сервера вам потребуется временная защита, пока будет выполняться настройка PF. Если вы используете DigitalOcean, вы можете активировать облачный брандмауэр сразу после запуска сервера. Инструкции по настройке облачного брандмауэра см. в кратком руководстве по брандмауэру DigitalOcean. Если вы используете услуги другого поставщика облачных решений, воспользуйтесь самым быстрым способом для немедленной защиты перед началом работы. Какой бы метод вы ни выбрали, ваш временный брандмауэр должен разрешать только входящий трафик SSH и может разрешать любой исходящий трафик.

      Шаг 1 — Создание предварительного набора правил

      Начните выполнение данного руководства, создав черновик предварительного набора правил, который обеспечивает базовую защиту и доступ к важнейшим услугам через Интернет. В настоящий момент у вас есть работающий сервер FreeBSD 12.1 с активным облачным брандмауэром.

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

      Набор правил PF записывается в файл конфигурации /etc/pf.conf, который также является местом его расположения по умолчанию. Вы можете хранить этот файл в другом месте, если это указано в файле конфигурации /etc/rc.conf. В этом руководстве вы будете использовать местоположение по умолчанию.

      Войдите на сервер с пользователем non-root user:

      • ssh freebsd@your_server_ip

      Далее создайте ваш файл /etc/pf.conf:

      Примечание. Если вы захотите посмотреть полный базовый набор правил в любой момент при выполнении руководства, см. примеры в шаге 4 и шаге 8.

      PF фильтрует пакеты в соответствии с тремя основными действиями: block, pass и match. В сочетании с другими опциями они образуют правила. Действие выполняется, когда пакет соответствует критериям, указанным в правиле. Как вы можете ожидать, правила pass и block будут пропускать и блокировать трафик. Правило match выполняет действие с пакетом при обнаружении соответствующих критериев, но не пропускает или блокирует его. Например, оно может выполнять преобразование сетевых адресов (NAT) для соответствующего пакета, не блокируя или пропуская его, пакет останется на месте, пока вы не скажете ему сделать что-то в другом правиле, например, направите его на другой сервер или шлюз.

      Далее добавьте первое правило в ваш файл /etc/pf.conf:

      /etc/pf.conf

      block all
      

      Это правило блокирует все формы трафика в каждом направлении. Поскольку направление на указано, по умолчанию блокируется входящий и исходящий трафик. Данное правило является законным для локальных рабочих станций, которые необходимо изолировать от мира, однако оно во многом не пригодно к использованию на практике и не будет работать на удаленном сервере, поскольку оно запрещает трафик SSH. На деле, если бы вы активировали PF, то могли бы заблокировать для себя доступ к серверу.

      Измените ваш файл /etc/pf.conf, чтобы разрешить трафик SSH в следующих выделенных строках:

      /etc/pf.conf

      block all
      pass in proto tcp to port 22
      

      Примечание. В качестве альтернативы вы можете использовать имя протокола:

      /etc/pf.conf

      block all
      pass in proto tcp to port ssh
      

      Для единообразия мы будем использовать номера портов, если нет веских причин не делать этого. Существует подробный список протоколов и соответствующих номеров портов в файле /etc/services, который мы рекомендуем просмотреть.

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

      Теперь вы можете подключиться к серверу через SSH, но вы все равно можете блокировать все формы исходящего трафика. Это проблема, поскольку вы не можете получить доступ к критическим сервисам из Интернета для установки пакетов, обновления настроек времени и т. д.

      Для устранения этой проблемы добавьте следующее выделенное правило в конце файла /etc/pf.conf:

      /etc/pf.conf

      block all
      pass in proto tcp to port { 22 }
      pass out proto { tcp udp } to port { 22 53 80 123 443 }
      

      Теперь ваш набор правил разрешает исходящий трафик SSH, DNS, HTTP, NTP и HTTPS, а также блокирует весь входящий трафик (за исключением SSH). Вы размещаете номера портов и протоколы в фигурные скобки, которые образуют список в синтаксисе PF, что позволяет добавлять дополнительные номера портов, если это потребуется. Также вы добавляете разрешающее правило для протокола UDP на портах 53 и 123, поскольку DNS и NTP часто переключаются между протоколами TCP и UDP. Вы почти закончили работу с предварительным набором правил, осталось только добавить несколько правил для получения базового функционала.

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

      Preliminary Ruleset /etc/pf.conf

      set skip on lo0
      block all
      pass in proto tcp to port { 22 }
      pass out proto { tcp udp } to port { 22 53 80 123 443 }
      pass out inet proto icmp icmp-type { echoreq }
      

      Сохраните и закройте файл.

      Вы создали правило set skip для устройства закольцовывания, поскольку ему не требуется фильтр трафика, а такая фильтрация может вызывать заметное замедление работы сервера. Вы добавили правило pass out inet​​​ для протокола ICMP, которое позволяет использовать утилиту ping(8) для поиска и устранения проблем. Опция inet представляет семейство адресов IPv4.

      ICMP — это многоцелевой протокол обмена сообщениями, используемый сетевыми устройствами для различных видов коммуникации. Например, утилита ping использует сообщения, известные как echo request, которые вы добавили в список icmp_type. В качестве меры предосторожности вы разрешаете только типы сообщений, которые вам нужны для предотвращения контакта нежелательных устройств с вашим сервером. По мере роста ваших потребностей вы можете добавить в список новые типы сообщений.

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

      Шаг 2 — Тестирование вашего предварительного набора правил

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

      Наборы правил PF являются простым текстовым файлом, что означает, что при загрузке новых наборов правил не потребуются сложные процедуры. После загрузки нового набора правил старый исчезает. Очень редко, если это вообще возможно, требуется удалить существующий набор правил.

      FreeBSD использует сеть shell-скриптов, известную как система rc, чтобы управлять запуском служб во время загрузки, а мы укажем эти службы в разных файлах конфигурации rc. Для таких глобальных служб, как PF, вы будете использовать файл /etc/rc.conf. Поскольку файлы rc имеют критическое значение для нормальной работы системы FreeBSD, они не должны редактироваться напрямую. Вместо этого FreeBSD предоставляет утилиту командной строки sysrc, которая предназначена для безопасного редактирования этих файлов.

      Давайте активируем PF, используя утилиту командной строки sysrc:

      • sudo sysrc pf_enable="YES"
      • sudo sysrc pflog_enable="YES"

      Проверьте внесение изменений, отобразив содержимое вашего файла /etc/rc.conf:

      Результат будет выглядеть следующим образом:

      Output

      pf_enable="YES" pflog_enable="YES"

      Также вы активируете службу pflog, которая, в свою очередь, активирует демон pflogd для ведения журнала PF. Вы поработаете с журналами позже.

      Вы должны указать две глобальные службы в вашем файле /etc/rc.conf, но они не инициализируются, пока вы не перезагрузите сервер или не запустите их вручную. Перезапустите сервер, чтобы протестировать ваш доступ через SSH.

      Запустите PF, перезапустив сервер:

      Подключение будет сброшено. Подождите несколько минут, пока не закончится процесс обновления.

      Теперь снова подключитесь по SSH к серверу:

      • ssh freebsd@your_server_ip

      Хотя ваши службы PF уже проинициализированы, вы еще не загрузили ваш набор правил /etc/pf.conf, что означает, что ваш брандмауэр еще не активен.

      Загрузите набор правил с помощью pfctl:

      • sudo pfctl -f /etc/pf.conf

      Если ошибки или сообщения отсутствуют, это означает, что ваш набор правил не имеет ошибок, а брандмауэр активен.

      Теперь, когда PF запущен, вы можете отключить ваш сервер от облачного брандмауэра. Это можно сделать в панели управления вашей учетной записи DigitalOcean, удалив дроплет из портала облачного брандмауэра. Если вы используете другого поставщика облачных услуг, убедитесь, что все, что вы использовали для временной защиты, отключено. Запуск двух разных брандмауэров на сервере практически точно вызовет проблемы.

      В дополнение к этому перезагрузите ваш сервер еще раз:

      Через несколько минут подключитесь через SSH к вашему серверу:

      • ssh freebsd@your_server_ip

      Теперь PF — ваш действующий брандмауэр. Чтобы проверить, что он запущен, вы можете попробовать получить доступ к данным с помощью утилиты pfctl.

      Давайте рассмотрим некоторые статистические данные и счетчики с помощью pfctl -si​​​:

      Вы передаете флаги -si, которые означают show info, т. е. показать информацию. Это одна из многочисленных комбинаций параметров фильтра, которую вы можете использовать с pfctl для парсинга данных об активности брандмауэра.

      Вы увидите следующие данные в таблице (значения будут варьироваться в зависимости от сервера):

      Output

      Status: Enabled for 0 days 00:01:53 Debug: Urgent State Table Total Rate current entries 5 searches 144 1.3/s inserts 11 0.1/s removals 6 0.1/s Counters match 23 0.2/s bad-offset 0 0.0/s fragment 0 0.0/s short 0 0.0/s normalize 0 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 0 0.0/s proto-cksum 0 0.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s map-failed 0 0.0/s

      Поскольку вы только что активировали набор правил, вы не увидите большое количество информации. Однако этот вывод показывает, что PF уже записал 23 совпавших правила. Это означает, что критерии набора правил были использованы 23 раза. Вывод также подтверждает, что ваш брандмауэр работает.

      Ваш набор правил также разрешает исходящий трафик для доступа к ряду критически важных сервисов в Интернете, включая утилиту ping.

      Давайте проверим подключение через Интернет и службу DNS с помощью ping для google.com:

      Поскольку вы использовали флаг -c 3 при запуске, вы увидите три успешные попытки подключения:

      Output

      PING google.com (172.217.0.46): 56 data bytes 64 bytes from 172.217.0.46: icmp_seq=0 ttl=56 time=2.088 ms 64 bytes from 172.217.0.46: icmp_seq=1 ttl=56 time=1.469 ms 64 bytes from 172.217.0.46: icmp_seq=2 ttl=56 time=1.466 ms --- google.com ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.466/1.674/2.088/0.293 ms

      Убедитесь, что у вас есть доступ к репозиторию pkgs с помощью следующей команды:

      Если имеются какие-либо обновления для пакетов, выполните обновление.

      Если обе службы работают, это означает, что ваш брандмауэр работает, и вы можете двигаться дальше. Хотя ваш предварительный набор правил обеспечивает защиту и необходимый функционал, это по-прежнему очень простой набор, который может быть улучшен. В остальных разделах мы будем дополнять базовый набор правил и используем некоторые продвинутые функции PF.

      Шаг 3 — Дополнение базового набора правил

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

      Включение макросов и таблиц

      В предварительном наборе правил вы жестко задали все параметры для каждого правила, в нашем случае это номера портов, которые составляют список. В будущем такая конфигурация может стать неуправляемой, в зависимости от природы ваших сетей. Для большей организованности PF включает макросы, списки и таблицы. Вы уже включили списки прямо в ваши правила, но вы также можете отделить их от правил и назначить переменную с помощью макросов.

      Откройте ваш файл, чтобы передать некоторые параметры в макрос:

      Теперь добавьте в самый верх набора правил следующее содержание:

      /etc/pf.conf

      vtnet0 = "vtnet0"
      icmp_types = "{ echoreq }"
      . . .
      

      Измените ваши предыдущие правила SSH и ICMP, указав новые переменные:

      /etc/pf.conf

      . . .
      pass in on $vtnet0 proto tcp to port { 22 }
      . . .
      pass inet proto icmp icmp-type $icmp_types
      . . .
      

      Ваши предыдущие правила SSH и ICMP теперь используют макросы. Имена переменных отображаются с помощью принятого в PF синтаксиса со знаком доллара. Вы назначаете интерфейс vtnet0 для переменной с тем же именем только в качестве формальности, что позволяет переименовать ее в будущем, если возникнет такая потребность. Другие распространенные имена переменных для общедоступных интерфейсов включают $pub_if​​​ или $ext_if.

      Далее вы должны имплементировать таблицу, которая похожа на макрос, но предназначена для хранения групп IP-адресов. Давайте создадим таблицу для немаршрутизуемых IP-адресов, которые часто используются в DoS-атаках. Вы можете использовать IP-адреса, указанные в RFC6890, где определяются реестры IP-адресов особенного назначения. Ваш сервер не должен посылать пакеты на эти адреса или получать пакеты от этих адресов через общедоступные интерфейсы.

      Создайте эту таблицу, добавив следующее содержание сразу после макроса icmp_types:

      /etc/pf.conf

      . . .
      table <rfc6890> { 0.0.0.0/8 10.0.0.0/8 100.64.0.0/10 127.0.0.0/8 169.254.0.0/16          
                        172.16.0.0/12 192.0.0.0/24 192.0.0.0/29 192.0.2.0/24 192.88.99.0/24    
                        192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 203.0.113.0/24            
                        240.0.0.0/4 255.255.255.255/32 }
      . . .
      

      Теперь добавьте ваши правила для таблицы <rfc6890> под правилом set skip on lo0:

      /etc/pf.conf

      . . .
      set skip on lo0
      block in quick on egress from <rfc6890>
      block return out quick on egress to <rfc6890>
      . . .
      

      Здесь вы добавляете опцию return, которая дополняет ваше правило block out​​​. Эта команда отклоняет пакеты и отправляет сообщение RST на хост, который попытался установить эти подключения, что полезно для анализа активности хоста. Затем добавьте ключевое слово egress, которое автоматически находит маршруты по умолчанию для любых заданных интерфейсов. Обычно это более простой метод поиска маршрутов по умолчанию, особенно для сложных сетей. Ключевое слово quick выполняет правила немедленно без учета остальной части набора правил. Например, если пакет с нелогичными IP-адресами попытается подключиться к серверу, вы можете захотеть немедленно сбросить соединение, и у вас не будет причин пропускать этот пакет через остальную часть набора правил.

      Защита портов SSH

      Поскольку ваш порт SSH общедоступен, он может стать объектом атаки. Один из самых очевидных признаков нападения — это массовые попытки входа в систему. Например, если один IP-адрес пытается выполнить вход на ваш сервер 10 раз за секунду, вы можете предположить, что это дело рук не человека, а компьютерного программного обеспечения, которое пытается взломать ваш пароль входа в систему. Такие виды систематических эксплойтов часто называют атаками brute force​​​, и обычно они являются успешными, если у сервера слабый пароль.

      Предупреждение. Мы настоятельно рекомендуем использовать аутентификацию по открытому ключу на всех ваших серверах. Ознакомьтесь с руководством DigitalOcean по аутентификации на базе ключей.

      PF имеет встроенные функции для противодействия атакам brute force и другим похожим атакам. С помощью PF вы можете ограничить количество попыток одновременного подключения с одного хоста. Если хост превышает эти ограничения, соединение будет сброшено, а сам хост будет запрещен на сервере. Для этого вы можете использовать механизм устранения перегрузки PF, который поддерживает таблицу запрещенных IP-адресов.

      Измените предыдущее правило SSH, чтобы ограничить количество одновременных подключений с одного хоста, следующим образом:

      /etc/pf.conf

      . . .
      pass in on $vtnet0 proto tcp to port { 22 } 
          keep state (max-src-conn 15, max-src-conn-rate 3/1, 
              overload <bruteforce> flush global)
      . . .
      

      Вы добавили опцию keep state, которая позволяет определить критерии состояния для таблицы устранения перегрузки: Вы передаете параметр max-src-conn, чтобы указать разрешенное количество одновременных подключений с одного хоста в секунду, а также параметр max-src-conn-rate, чтобы указать разрешенное количество новых подключений с одного хоста в секунду. Вы указали 15 подключений для max-src-conn и 3 подключения для max-src-conn-rate. Если хост превышает эти ограничения, механизм устранения перегрузки добавляет IP-адрес источника в таблицу <bruteforce>, которая запрещает его использование на сервере. Наконец, опция flush global немедленно сбрасывает подключение.

      Вы определили таблицу устранения перегрузки в вашем правиле SSH, но не объявили саму таблицу в вашем наборе правил.

      Добавьте таблицу <bruteforce> под макросом icmp_types:

      /etc/pf.conf

      . . .
      icmp_types = "{ echoreq }"
      table <bruteforce> persist
      . . .
      

      Ключевое слово persist позволяет создавать пустую таблицу в наборе правил. Без него PF будет жаловаться, что в таблице нет IP-адресов.

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

      Очистка вашего трафика

      Примечание. В следующих разделах описываются базовые принципы работы протокола TCP/IP. Если вы планируете создавать веб-приложения или работать с сетью, вам будет полезно знать эти вещи. Ознакомьтесь с руководством DigitalOcean Знакомство с сетевой терминологией, интерфейсами и протоколами.

      Из-за сложности протокола TCP/IP, а также действий злоумышленников пакеты часто поступают с отклонениями и неопределенностями, например с наложением фрагментов IP-адресов, поддельными IP-адресами и многим другим. Поэтому необходимо очищать трафик, прежде чем он поступит в систему. Технический термин, используемый для обозначения этого процесса, — нормализация.

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

      Добавьте ключевое слово scrub непосредственно перед правилом block all​​​:

      /etc/pf.conf

      . . .
      set skip on lo0
      scrub in all fragment reassemble max-mss 1440
      block all
      . . .
      

      Это правило применяется для очищения входящего трафика. Вы добавили опцию fragment reassemble, которая предотвращает попадание фрагментов в систему. Вместо этого они кэшируются в памяти, пока не будут пересобраны в полные пакеты, что означает, что правилам фильтра придется работать только с единообразными пакетами. Также вы должны включить опцию max-mss 1440, которая представляет максимальный размер сегмента пересобираемых пакетов TCP, также известный как полезная нагрузка. Вы указываете значение 1440 байт, которое отражает баланс между размером и производительностью, оставляя достаточное пространство для заголовков.

      Еще один важный аспект фрагментации — это термин, известный как максимальный передаваемый модуль данных (MTU). Протоколы TCP/IP позволяют устройствам обсуждать размеры пакетов для установления подключений. Целевой хост использует сообщения ICMP для информирования IP-адреса источника о своем MTU. Данный процесс известен как открытие пути MTU. Конкретный тип сообщения ICMP — destination unreachable. Вы должны активировать открытие пути MTU, добавив тип сообщения unreach в ваш список icmp_types.

      Вы будете использовать стандартное значение MTU в 1500 байт, которое можно определить с помощью команды ifconfig:

      Вы увидите следующий вывод, который включает ваше текущее значение MTU:

      Output

      vtnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=6c07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> . . .

      Обновите список icmp_types, чтобы добавить тип сообщения destination unreachable​​​:

      /etc/pf.conf

      vtnet0 = "vtnet0"
      icmp_types = "{ echoreq unreach}"
      . . .
      

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

      Теперь вы можете заняться предотвращением другой опасности, известной как подмена IP (спуфинг). Злоумышленники часто изменяют IP-адрес источника, чтобы могло показаться, что он находится на доверенном узле внутри организации. PF включает директиву antispoofing для обработки подмененных IP-адресов источника. При применении для конкретного интерфейса (интерфейсов) эта директива блокирует весь трафик из сети данного интерфейса (если его источником не является сам интерфейс). Например, если вы примените директиву antispoofing для интерфейса (интерфейсов) с адресом 5.5.5.1/24, весь трафик из сети 5.5.5.0/24 не будет приниматься системой, если только его источником не является этот интерфейс (интерфейсы).

      Добавьте следующее выделенное содержание, чтобы применить antispoofing для интерфейса vtnet0:

      /etc/pf.conf

      . . .
      set skip on lo0
      scrub in
      antispoof quick for $vtnet0
      block all
      . . .
      

      Сохраните и закройте файл.

      Это правило для борьбы с подменой указывает, что весь трафик из сети (сетей) vtnet0 может передаваться только через интерфейс vtnet0, либо он будет немедленно отклонен с помощью ключевого слова quick. Злоумышленники не смогут скрыться в сети vtnet0 и взаимодействовать с другими узлами.

      Для демонстрации вашего правила для борьбы с подменой IP-адресов вы можете вывести ваш набор правил на экран в подробном виде. Правила в PF обычно написаны в сокращенной форме, но также они могут быть написаны в подробной форме. Как правило, не очень удобно писать правила таким образом, но для целей тестирования это может быть полезно.

      Выведите на экран содержимое /etc/pf.conf, используя pfctl со следующей командой:

      • sudo pfctl -nvf /etc/pf.conf

      Эта команда pfctl получает флаги -nvf, выводит набор правил и тестирует его без фактической загрузки данных, что известно как пробный прогон. Теперь вы увидите полное содержимое /etc/pf.conf в подробной форме.

      Вы увидите примерно следующий вывод внутри части для борьбы с подменой IP-адресов:

      Output

      . . . block drop in quick on ! vtnet0 inet from your_server_ip/20 to any block drop in quick on ! vtnet0 inet from network_address/16 to any block drop in quick inet from your_server_ip to any block drop in quick inet from network_address to any block drop in quick on vtnet0 inet6 from your_IPv6_address to any . . .

      Ваше правило показало, что это часть сети your_server_ip/20. Также оно обнаружило, что (в примере для данного обучающего руководства) сервер является частью сети network_address/16 и имеет дополнительный IPv6-адрес. Правило блокирует коммуникации системы со всеми этими сетями, если их трафик не проходит через интерфейс vtnet0.

      Ваше правило для борьбы с подменой IP-адреса является последним добавлением в базовый набор правил. На следующем шаге вы примените эти изменения и выполните ряд тестов.

      Шаг 4 — Тестирование базового набора правил

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

      Вот как выглядит ваш полный базовый набор правил:

      Base Ruleset /etc/pf.conf

      vtnet0 = "vtnet0"
      icmp_types = "{ echoreq unreach }"
      table <bruteforce> persist
      table <rfc6890> { 0.0.0.0/8 10.0.0.0/8 100.64.0.0/10 127.0.0.0/8 169.254.0.0/16          
                        172.16.0.0/12 192.0.0.0/24 192.0.0.0/29 192.0.2.0/24 192.88.99.0/24    
                        192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 203.0.113.0/24            
                        240.0.0.0/4 255.255.255.255/32 }
      
      set skip on lo0
      scrub in all fragment reassemble max-mss 1440
      antispoof quick for $vtnet0
      block in quick on $vtnet0 from <rfc6890>
      block return out quick on egress to <rfc6890>
      block all
      pass in on $vtnet0 proto tcp to port { 22 } 
          keep state (max-src-conn 15, max-src-conn-rate 3/1, 
              overload <bruteforce> flush global)
      pass out proto { tcp udp } to port { 22 53 80 123 443 }
      pass inet proto icmp icmp-type $icmp_types
      

      Убедитесь, что ваш файл /etc/pf.conf идентичен полному базовому набор правил, прежде чем продолжить. Сохраните и закройте файл.

      Ваш полный базовый набор правил предоставляет вам следующее:

      • Набор макросов, который может определять ключевые службы и устройства.
      • Политика гигиены сети для решения проблем с фрагментацией пакетов и нелогичными IP-адресами.
      • Структура фильтрации default deny​​​, которая блокирует весь трафик и разрешает только то, что вы указываете.
      • Входящий доступ через SSH с ограничением количества одновременных подключений с одного хоста.
      • Политики для исходящего трафика, которые позволяют получить доступ к критически важным сервисам в Интернете.
      • Политики ICMP, которые обеспечивают доступ к утилите ping и открытию пути MTU.

      Запустите следующую команду pfctl для выполнения пробного прогона:

      • sudo pfctl -nf /etc/pf.conf

      Вы передаете флаги -nf, которые указывают pfctl запускать набор правил без загрузки, в результате чего будут брошены ошибки, если что-то пойдет не так.

      Теперь, если ошибки отсутствуют, загрузите набор правил:

      • sudo pfctl -f /etc/pf.conf

      Если ошибок нет, это означает, что ваш базовый набор правил активен и работает корректно. Как и ранее в этом руководстве, вы выполните несколько тестов для вашего набора правил.

      Первый тест — подключение к Интернету и службе DNS:

      Результат будет выглядеть следующим образом:

      Output

      PING google.com (172.217.0.46): 56 data bytes 64 bytes from 172.217.0.46: icmp_seq=0 ttl=56 time=2.088 ms 64 bytes from 172.217.0.46: icmp_seq=1 ttl=56 time=1.469 ms 64 bytes from 172.217.0.46: icmp_seq=2 ttl=56 time=1.466 ms --- google.com ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.466/1.674/2.088/0.293 ms

      Затем проверьте, что вы можете получить доступ к репозиторию pkgs:

      Еще раз обновите пакеты, если это необходимо.

      В заключение перезапустите ваш сервер:

      Подождите несколько минут, пока сервер не перезагрузится. Вы выполнили и имплементировали базовый набор правил, что является важным шагом с точки зрения вашего прогресса. Теперь вы готовы к изучению некоторых продвинутых функций PF. На следующем шаге вы сможете продолжить работу по предотвращению атак brute force.

      Шаг 5 — Управление таблицей устранения перегрузки

      Со временем таблица устранения перегрузки <bruteforce> будет заполнена IP-адресами злоумышленников, и вам придется выполнять ее периодическую очистку. Маловероятно, что злоумышленник будет использовать один и тот же IP-адрес, поэтому нет необходимости хранить эти адреса в таблице в течение длительного времени.

      Вы можете использовать pfctl для ручной очистки IP-адресов, которые хранятся в таблице устранения перегрузки в течение 48 часов и более с помощью следующей команды:

      • sudo pfctl -t bruteforce -T expire 172800

      Вы увидите примерно следующий результат:

      Output

      0/0 addresses expired.

      Вы передаете флаг -t bruteforce, что означает table bruteforce, и флаг -T, который позволяет запускать целый ряд встроенных команд. В этом случае вы должны запустить команду expire, чтобы очистить все записи из -t bruteforce со значением времени, указанным в секундах. Поскольку вы работаете на новом сервере, в таблице, вероятно, не будет IP-адресов.

      Это правило работает для быстрого исправления ситуации, но более надежным решением будет автоматизация процесса с помощью cron, планировщика заданий FreeBSD. Давайте создадим скрипт оболочки, который запускает эту последовательность выполнения команды.

      Создайте файл скрипта оболочки в директории /usr/local/bin:

      • sudo vi /usr/local/bin/clear_overload.sh

      Добавьте в скрипт оболочки следующие строки:

      /usr/local/bin/clear_overload.sh

      #!/bin/sh
      
      pfctl -t bruteforce -T expire 172800
      

      Сделайте файл исполняемым с помощью следующей команды:

      • sudo chmod 755 /usr/local/bin/clear_overload.sh

      Далее вам необходимо создать задание cron. Это задания, которые будут запускаться периодически в соответствии с указанным вами временем. Часто они используются для резервного копирования или любого процесса, который необходимо запускать в одно и то же время каждый день. Создавать задания cron можно с помощью файлов crontab. Дополнительную информацию о cron(8) и crontab(5) см. в Man Pages.

      Создайте файл crontab пользователя root с помощью следующей команды:

      Теперь добавьте в файл crontab следующее содержимое:

      crontab

      # minute    hour    mday    month   wday    command
      
        *             0     *       *     *     /usr/local/bin/clear_overload.sh
      

      Сохраните и закройте файл.

      Примечание. Пожалуйста, сопоставьте каждое значение с соответствующим элементом в таблице для удобства чтения, если содержимое размещается некорректно при добавлении контента.

      Это задание cron запускает скрипт clear_overload.sh каждый день в полночь, удаляя IP-адреса, которые находятся в таблице перегрузки <bruteforce> более 48 часов. Далее вам необходимо добавить якоря в ваш набор правил.

      Шаг 6 — Добавление якорей в ваши наборы правил

      На этом шаге вы должны ввести якоря, которые используются для поиска правил в основном наборе правил, либо вручную, либо из внешнего текстового файла. Якоря могут содержать элементы правил, таблицы и даже другие якоря, которые называются вложенными якорями. Давайте продемонстрируем, как работают якоря, добавив таблицу во внешний файл, а затем выполним ее извлечение в ваш базовый набор правил. Ваша таблица будет включать группу внутренних хостов, для которой вы хотите ограничить подключение к внешнему миру.

      Создайте файл под именем /etc/blocked-hosts-anchor:

      • sudo vi /etc/blocked-hosts-anchor

      Добавьте в файл следующие строчки:

      /etc/blocked-hosts-anchor

      table <blocked-hosts> { 192.168.47.1 192.168.47.2 192.168.47.3 }
      
      block return out quick on egress from <blocked-hosts>
      

      Сохраните и закройте файл.

      Эти правила объявляются и определяются в таблице <blocked-hosts>​​​ и запрещают доступ с любого IP-адреса в таблице <blocked-hosts> к любым сервисам внешнего мира. Вы используете ключевое слово egress в качестве предпочитаемого метода поиска маршрута по умолчанию или выхода наружу, в Интернет.

      Вам все еще необходимо объявить якорь в вашем файле /etc/pf.conf​​​:

      Теперь добавьте следующие правила якоря после правила block all​​:

      /etc/pf.conf

      . . .
      block all
      anchor blocked_hosts
      load anchor blocked_hosts from "/etc/blocked-hosts-anchor"
      . . .
      

      Сохраните и закройте файл.

      Эти правила декларируют blocked_hosts и загружают правила якоря в ваш главный набор правил из файла /etc/blocked-hosts-anchor.

      Теперь примените эти изменения, перезагрузив ваш набор правил с помощью pfctl:

      • sudo pfctl -f /etc/pf.conf

      Если ошибок нет, это означает, что в вашем наборе правил нет ошибок, а изменения активны.

      Используйте pfctl для проверки запуска якоря:

      Флаг -s Anchors означает show anchors. Вывод должен выглядеть так:

      Output

      blocked_hosts

      Утилита pfctl также может парсить конкретные правила вашего якоря с помощью флагов -a и -s:

      • sudo pfctl -a blocked_hosts -s rules

      Результат будет выглядеть следующим образом:

      Output

      block return out quick on egress from <blocked-hosts> to any

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

      Давайте откроем /etc/pf.conf и добавим еще один якорь:

      Вы можете назвать якорь rogue_hosts и поместить его в правило block all​​​:

      /etc/pf.conf

      . . .
      block all
      anchor rogue_hosts
      . . .
      

      Сохраните и закройте файл.

      Чтобы применить изменения, перезагрузите набор правил с помощью pfctl:

      • sudo pfctl -f /etc/pf.conf

      Еще раз используйте pfctl для подтверждения запуска якоря:

      Результат будет выглядеть следующим образом:

      Output

      blocked_hosts rogue_hosts

      Теперь, когда якорь запущен, вы можете добавить к нему правила в любое время. Проверьте это, добавив следующее правило:

      • sudo sh -c 'echo "block return out quick on egress from 192.168.47.4" | pfctl -a rogue_hosts -f -'

      Здесь вызывается команда echo и строковое содержимое, которое затем передается в утилиту pfctl с символом |, где оно обрабатывается в правило якоря. Откройте новый сеанс оболочки с помощью команды sh -c. Это связано с тем, что вы создаете связь между двумя процессами, но вам необходимо использовать права sudo для прохождения всей последовательности команд. Существует несколько способов решения этой проблемы, в нашем случае вы откроете дополнительный процесс оболочки с привилегиями sudo, используя для этого команду sudo sh -c.

      Теперь воспользуйтесь pfctl еще раз, чтобы убедиться, что правила активны:

      • sudo pfctl -a rogue_hosts -s rules

      Результат будет выглядеть следующим образом:

      Output

      block return out quick on egress inet from 192.168.47.4 to any

      Использование якорей является ситуационным и субъективным решением. Как и для любых других функций, существуют плюсы и минусы использования якорей. Некоторые приложения, такие как интерфейс blacklistd, изначально имеют якоря. Далее мы рассмотрим подробнее процесс записи журналов в PF, что является критически важным аспектом сетевой безопасности. Ваш брандмауэр будет бесполезен, если вы не можете посмотреть, что он делает.

      Шаг 7 — Запись журнала активности вашего брандмауэра

      На этом шаге мы будем работать с журналом PF, который управляется с помощью псевдоинтерфейса pflog. Функция ведения журнала активируется при загрузке с помощью добавления pflog_enabled=YES в файл /etc/rc.conf, что вы уже сделали на шаге 2. Это позволяет активировать демон pflogd, который генерирует интерфейс под именем pflog0 и записывает журналы в бинарном формате в файл /var/log/pflog. Журналы можно парсить в режиме реального времени из интерфейса или читать из файла /var/log/pflog с помощью утилиты tcpdump(8)​​.

      Вначале получите доступ к журналам из файла /var/log/pflog:

      • sudo tcpdump -ner /var/log/pflog

      Вы передаете флаги -ner, которые форматируют вывод в удобочитаемый вид, а также указываете файл для чтения, в нашем случае это /var/log/pflog.

      Результат будет выглядеть следующим образом:

      Output

      reading from file /var/log/pflog, link-type PFLOG (OpenBSD pflog file)

      На этих ранних этапах в файле /var/log/pflog может не быть данных. В очень короткий срок файл журнала начнет расти в размере.

      Также вы можете просмотреть журналы в реальном времени с помощью интерфейса pflog0, используя следующую команду:

      Вы передаете флаги -nei, которые также форматируют вывод для удобства чтения, но в этот раз указываете интерфейс, в нашем случае это pflog0.

      Результат будет выглядеть следующим образом:

      Output

      tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 262144 bytes

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

      Чтобы выйти из этого состояния и вернуться в командную строку, нажмите CTRL + Z.

      В Интернете есть огромное количество информации о tcpdump(8), включая официальный сайт.

      Доступ к файлам журнала с помощью pftop

      Утилита pftop — это инструмент для быстрого просмотра активности брандмауэра в реальном времени. Ее имя отсылает к хорошо известной утилите Unix top.

      Для ее использования вам необходимо установить пакет pftop:

      Теперь запустите бинарный файл pftop:

      В результате будет получен следующий вывод (ваши IP-адреса будут отличаться):

      Output

      PR DIR SRC DEST STATE AGE EXP PKTS BYTES tcp In 251.155.237.90:27537 157.225.173.58:22 ESTABLISHED:ESTABLISHED 00:12:35 23:59:55 1890 265K tcp In 222.186.42.15:25884 157.225.173.58:22 TIME_WAIT:TIME_WAIT 00:01:25 00:00:06 22 3801 udp Out 157.245.171.59:4699 67.203.62.5:53 MULTIPLE:SINGLE 00:00:14 00:00:16 2 227

      Создание дополнительных интерфейсов журнала

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

      Создайте дополнительный интерфейс журнала с именем pflog1:

      • sudo vi /etc/hostname.pflog1

      Добавьте в файл /etc/hostname.pflog1 следующие строки:

      /etc/hostname.pflog1

      up
      

      Теперь активируйте устройство при загрузке в вашем файле /etc/rc.conf​​​:

      • sudo sysrc pflog1_enable="YES"

      Теперь вы можете контролировать и регистрировать активность брандмауэра. Это позволяет посматривать данные о том, кто подключается к серверу и какие типы подключений используются.

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

      Шаг 8 — Возврат к вашему базовому набору правил

      В этом последнем разделе вы вернетесь к базовому набору правил. Это быстрый шаг, который позволит вернуться к минимальному набору функций.

      Откройте базовый набор правил с помощью следующей команды:

      Удалите текущий набор правил в вашем файле и замените его на следующий базовый набор правил:

      /etc/pf.conf

      vtnet0 = "vtnet0"
      icmp_types = "{ echoreq unreach }"
      table <bruteforce> persist
      table <rfc6890> { 0.0.0.0/8 10.0.0.0/8 100.64.0.0/10 127.0.0.0/8 169.254.0.0/16          
                        172.16.0.0/12 192.0.0.0/24 192.0.0.0/29 192.0.2.0/24 192.88.99.0/24    
                        192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 203.0.113.0/24            
                        240.0.0.0/4 255.255.255.255/32 }
      
      set skip on lo0
      scrub in all fragment reassemble max-mss 1440
      antispoof quick for $vtnet0
      block in quick on $vtnet0 from <rfc6890>
      block return out quick on egress to <rfc6890>
      block all
      pass in on $vtnet0 proto tcp to port { 22 } 
          keep state (max-src-conn 15, max-src-conn-rate 3/1, 
              overload <bruteforce> flush global)
      pass out proto { tcp udp } to port { 22 53 80 123 443 }
      pass inet proto icmp icmp-type $icmp_types
      

      Сохраните и закройте файл.

      Перезагрузите набор правил:

      • sudo pfctl -f /etc/pf.conf

      Если ошибки при выполнении команды отсутствуют, это значит, что в вашем наборе правил нет ошибок, а ваш брандмауэр работает корректно.

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

      • sudo sysrc pflog1_enable="NO"

      Теперь удалите файл /etc/hostname.pflog1 из директории /etc:

      • sudo rm /etc/hostname.pflog1

      Прежде чем выходить, перезагрузите сервер еще раз, чтобы гарантировать, что все изменения активны и сохраняются:

      Подождите несколько минут, прежде чем выполнять вход на сервер.

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

      Simple Web Server Ruleset

      vtnet0 = "vtnet0"
      icmp_types = "{ echoreq unreach }"
      table <bruteforce> persist
      table <webcrawlers> persist
      table <rfc6890> { 0.0.0.0/8 10.0.0.0/8 100.64.0.0/10 127.0.0.0/8 169.254.0.0/16          
                        172.16.0.0/12 192.0.0.0/24 192.0.0.0/29 192.0.2.0/24 192.88.99.0/24    
                        192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 203.0.113.0/24            
                        240.0.0.0/4 255.255.255.255/32 }
      
      set skip on lo0
      scrub in all fragment reassemble max-mss 1440
      antispoof quick for $vtnet0
      block in quick on $vtnet0 from <rfc6890>
      block return out quick on egress to <rfc6890>
      block all
      pass in on $vtnet0 proto tcp to port { 22 } 
          keep state (max-src-conn 15, max-src-conn-rate 3/1, 
              overload <bruteforce> flush global)
      pass in on $vtnet0 proto tcp to port { 80 443 } 
          keep state (max-src-conn 45, max-src-conn-rate 9/1, 
              overload <webcrawlers> flush global)
      pass out proto { tcp udp } to port { 22 53 80 123 443 }
      pass inet proto icmp icmp-type $icmp_types
      

      В результате создается таблица с именем <webcrawlers>, которая имеет более гибкую политику в отношении перегрузки, чем ваш порт SSH, согласно значениям max-src-conn 45 и max-src-conn-rate. Это связано с тем, что не все перегрузки связаны с действиями злоумышленников. Они также могут быть связаны с активностью незлонамеренных сетевых ботов, поэтому вы можете избежать чрезмерных мер безопасности на портах 80 и 443. Если вы решите использовать набор правил для веб-сервера, вам необходимо добавить таблицу <webcrawlers> в /etc/pf.conf и периодически очищать IP-адреса в таблице. Подробнее см. в шаге 5.

      Заключение

      В этом обучающем руководстве вы настроили PF в FreeBSD 12.1. Теперь у вас есть базовый набор правил, который может служить в качестве отправной точки для всех ваших проектов FreeBSD. Дополнительную информацию о PF можно найти на странице pf.conf(5)​​​ в Man Pages.

      Посетите нашу страницу FreeBSD, чтобы найти дополнительные обучающие руководства и ответы на частые вопросы.



      Source link