Вступление
Облачные брандмауэры DigitalOcean предоставляют мощную службу брандмауэра на сетевом уровне, позволяя вашим серверам выполнять свою работу по обслуживанию ваших приложений и хранению ваших данных. В этом руководстве мы адаптируем установку Wordpress и MySQL для двух серверов для использования облачных брандмауэров и продемонстрируем некоторые преимущества, которые может предоставить эта служба. Если вы хотите получить дополнительную информацию об этой службе брандмауэра, прежде чем начать, прочитайте наше руководствоIntroduction To DigitalOcean Cloud Firewalls.
Предпосылки
Перед тем, как начать это руководство, вам необходимо создать инфраструктуру, указанную вHow To Set Up a Remote Database to Optimize Site Performance with MySQL on Ubuntu 16.04. В результате у вас останется два сервера, веб-сервер Nginx с установленными PHP и WordPress и автономный сервер MySQL. В этом руководстве мы будем называть эти серверыfrontend-01 иdatabase-01 соответственно.
Наша текущая ситуация с брандмауэром
Прямо сейчас на обоих наших серверах установлены брандмауэры с помощью утилитыufw. ufw - это простая в использовании оболочка для механизма межсетевого экрана Linux iptables. Войдите на оба сервера и давайте проверим состояние наших брандмауэров:
Сначала на веб-сервереfrontend-01:
sudo ufw status verboseOutputStatus: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22/tcp (OpenSSH) ALLOW IN Anywhere
80,443/tcp (Nginx Full) ALLOW IN Anywhere
22/tcp (OpenSSH (v6)) ALLOW IN Anywhere (v6)
80,443/tcp (Nginx Full (v6)) ALLOW IN Anywhere (v6)В выводе послеDefault: нам показано, что брандмауэр по умолчанию запрещает все входящие соединения и разрешает все исходящие соединения. Кроме того, у нас есть четыре правила, которые разрешают входящие TCP-соединения IPv4 и IPv6 (ALLOW IN) к портам 22 (SSH), 80 (HTTP) и 443 (HTTPS).
Сделаем то же самое на сервере базы данныхdatabase-01:
sudo ufw status verboseOutputStatus: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22/tcp (OpenSSH) ALLOW IN Anywhere
3306 ALLOW IN Anywhere
22/tcp (OpenSSH (v6)) ALLOW IN Anywhere (v6)
3306 (v6) ALLOW IN Anywhere (v6)Этот вывод аналогичен, за исключением того, что мы поменяли местами два порта Nginx на порт 3306, который является стандартным портом MySQL. Теперь, когда мы знаем нашу текущую настройку, давайте планируем нашу замену.
План облачного брандмауэра
Хотя мы могли бы просто создать два облачных брандмауэра, один для каждого конкретного сервера, и применить один кfrontend-01, а другой кdatabase-01, мы собираемся применить более гибкий подход к организации наших правил. .
Во-первых, мы хотим оставить себя готовыми к будущему, когда нам может понадобиться добавить третий тип сервиса в эту систему (возможно, сервер кэширования). Итак, мы собираемся разделить наши правила брандмауэра на основе ролей, а не физического сервера. Мы можем применить несколько облачных брандмауэров к каждой капле, поэтому нет проблем сделать эти брандмауэры детализированными и модульными.
[.note] #Note: Если вы хотите более глубоко изучить передовой опыт по структурированию ваших облачных брандмауэров, прочтитеHow To Organize DigitalOcean Cloud Firewalls.
#
Если мы немного разберемся, мы заметим, что оба наших сервера на самом деле имеют несколько функций. Существует основная функция обслуживания веб-страниц или информации базы данных, а также есть функция управления, предоставляемая службой SSH. Для нас имеет смысл создать брандмауэрmanagement, брандмауэрfrontend и брандмауэрdatabase.
Чтобы справиться с будущим сценарием, в котором мы масштабируем наши веб-службы или службы баз данных для нескольких хостов, мы будем использовать функцию тегирования DigitalOcean для организации наших капель по ролям. Теги - это простые метки, которые мы можем применять к каплям, чтобы классифицировать их и обращаться сразу ко всем группам серверов. Служба облачного брандмауэра может применять правила брандмауэра ко всем каплям в теге, что упрощает предоставление новым каплям правильных правил брандмауэра, которые уже существуют.
Дополнительный бонус - и то, что было бы сложно сделать динамическим способом с использованиемufw - это то, что облачные брандмауэры могут ограничивать входящий доступ на основе тегов. Так, например, наши серверыdatabase должны быть доступны только с наших серверовfrontend. Текущая установкаufw имеет базу данных, открытую для всех в сети. Мы ограничим это только нашими каплями с тегомfrontend.
Давайте кратко изложим три брандмауэра, которые нам нужно установить, простым языком:
-
Management: разрешает входящий трафик на TCP-порт 22 с любого хоста
-
Frontend: разрешает входящий трафик на TCP-порты 80 и 443 с любого хоста
-
Database: разрешает входящий трафик на TCP-порт 3306 только с серверов с тегамиfrontend
Мы не собираемся вообще ограничивать исходящий трафик в этом руководстве. Это неплохая идея, но нужно позаботиться о том, чтобы не нарушить механизмы автообновления и другие важные функции базовой операционной системы.
Теперь, когда у нас есть план для наших новых брандмауэров, давайте начнем.
[[step-1 -—- tagging-our-servers]] == Шаг 1. Добавление тегов к нашим серверам
Во-первых, мы будем помечать наши капли по ролям при подготовке к нашим правилам брандмауэра. Перейдите к панели управления DigitalOcean. По умолчанию это список ваших капель. Нажмите кнопкуMore справа от каплиfrontend-01 и выберитеAdd tags:
Появится текстовое поле, в котором вы можете ввести теги для этой капли. Введитеfrontend и нажмите кнопкуAdd Tags:
Сделайте то же самое для своего сервера базы данных, присвоив ему тегdatabase. Теги появятся в вашем списке капель:
При создании будущих капель вы можете применять эти теги в процессе первоначальной подготовки. Капли будут автоматически наследовать соответствующие правила брандмауэра.
Мы установим эти правила на следующем шаге.
[[step-2 -—- create-cloud-firewalls]] == Шаг 2 - Создание облачных межсетевых экранов
Мы собираемся настроить наши облачные брандмауэры сейчас. Сначала мы сделаем брандмауэрfrontend, затемdatabase, затемmanagement. Этот заказ не должен приводить к перебоям в обслуживании посетителей вашего сайта, но мы временно потеряем возможность устанавливать новые SSH-соединения. Это не повлияет на уже установленные соединения.
Служба межсетевых экранов доступна в разделеNetworking на панели управления DigitalOcean. Оказавшись там, щелкните вкладкуFirewalls, затем нажмите кнопкуCreate Firewall, чтобы начать.
Создание Frontend Firewall
На страницеCreate Firewall нам нужно заполнитьName, настроить нашInbound Rules и выбрать, к каким каплям применить брандмауэр. Мы оставим разделOutbound Rules как есть.
Сначала мы создаем брандмауэрfrontend, поэтому введитеfrontend-fw в полеName.
[.note] #Note: Мы добавим-fw в конец имен наших брандмауэров, чтобы устранить их неоднозначность. Хотя в интерфейсе панели управления используются значки для различения типов ресурсов, это может сбить с толку, если вы используете командную строку или API и, например, имеете несколько элементовfrontend.
#
Затем нам нужно удалить правило SSH по умолчанию из разделаInbound Rules. Мы нарушим это правило на брандмауэреmanagement для гибкости. Используйте ссылкуDelete в правой части страницы, чтобы удалить правило SSH.
Затем щелкните раскрывающийся списокNew rule и выберитеHTTP. Это автоматически заполнит правильный протокол (TCP) и порт (80) и по умолчанию разрешит трафик со всех адресов IPv4 и IPv6. Это то, что мы хотим.
Если у вас включен HTTPS, повторите описанный выше процесс, чтобы создать второе правило, выбрав на этот разHTTPS. Ваш разделInbound Rules будет таким:
Наконец, в полеApply to Droplets начните вводитьfrontend, затем выберите тегfrontend, когда он предложен автоматически.
Щелкните кнопкуCreate Firewall. Новый брандмауэр будет создан и применен к любой капле с тегомfrontend. Вы вернетесь на обновленную страницу с краткой информацией о брандмауэре, где показан ваш новый брандмауэр:
Теперь мы создадим брандмауэрdatabase.
Создание Брандмауэра Базы Данных
На странице Брандмауэры еще раз щелкнитеCreate Firewall. Процесс будет в основном таким же, как и для нашего брандмауэраfrontend.
Введитеdatabase-fw в полеName.
ВInbound Rules удалите правило SSH по умолчанию. Затем создайте новое правило, используя раскрывающийся список, выбравMySQL. Будет создано правило MySQL по умолчанию, разрешающее доступ к порту 3306 со всех IP-адресов. УдалитеAll IPv4 иAll IPv6 из поляSources. Мы хотим, чтобы только наши внешние серверы имели доступ к базе данных. Начните вводитьfrontend в полеSources и выберите тегfrontend, когда он будет предложен автоматически. Теперь любой капле с этим тегом будет разрешен доступ к серверу базы данных. Все остальные IP-адреса заблокированы.
ОставьтеOutbound Rules как есть. В разделеApply to Droplets примените этот брандмауэр к тегуdatabase, затем щелкнитеCreate Firewall. Еще раз, вы вернетесь на страницу сводки брандмауэра:
Обратите внимание, что оба брандмауэра показывают, что они применяются к одной капле каждый. Если вы загружаете свой сайт, он все равно должен загружаться нормально. Теперь давайте снова включим управление через SSH.
Создание брандмауэра управления
ЩелкнитеCreate Firewall в последний раз. Добавьтеmanagement-fw в полеName.
Правило SSH по умолчанию - это все, что нам нужно для этого брандмауэра. Это позволит любому IP подключаться к порту 22.
Кроме того, вы можете изменить полеSources правила SSH на конкретный IP-адрес, с которого вы будете подключаться. Например, если у вашего офиса статический IP-адрес, и вы хотите ограничить доступ SSH только для подключений из офиса, поместите этот IP-адрес вSources, заменивAll IPv4 иAll IPv6. Если ваш IP-адрес когда-либо изменится в будущем, вам просто нужно обновить это единственное правило, чтобы восстановить доступ к управлению, что является еще одним преимуществом планирования и создания модульных правил.
В разделеApply to Droplets добавьте тегиfrontend иdatabase, затем щелкнитеCreate Firewall. Давайте посмотрим на наш итоговый обзор брандмауэра:
На этом этапе наш облачный брандмауэр должен быть полностью функциональным, но у нас все еще есть активные брандмауэрыufw для хоста. Давайте отключим их, а затем протестируем наши соединения.
[[step-3 -—- drop-the-host-firewalls]] == Шаг 3. Отключение брандмауэров хоста
Нам нужно отключить брандмауэрufw на обоих хостах. Сначала наfrontend-01:
sudo ufw disableOutputFirewall stopped and disabled on system startupЗатем наdatabase-01:
sudo ufw disableOutputFirewall stopped and disabled on system startupЭто останавливает текущий брандмауэр, сбрасывает все правила и предотвращает повторное включение правил при запуске.
На этом этапе все наши возможности подключения должны быть восстановлены. Попробуйте создать новый сеанс SSH на одном из ваших серверов. Затем загрузите свой веб-сайт, чтобы убедиться, что веб-сервер все еще подключается к базе данных и возвращает веб-страницы в браузер.
Возможность подключения ко всем нашим службам на самом деле не доказывает, что брандмауэр работает. Давайте проведем еще немного тестирования, чтобы убедиться, что наши брандмауэры действительно установлены.
[[step-4 -—- testing-our-firewalls]] == Шаг 4. Тестирование наших брандмауэров
Чтобы протестировать наши брандмауэры, мы собираемся войти в систему на третьем сервере и использовать утилиту под названиемnmap для сканирования нашего веб-сервера и серверов баз данных. nmap - это сканер портов, который сканирует наши хосты и сообщает нам, какие порты открыты, закрыты или отфильтрованы.
Войдите на другой сервер Ubuntu 16.04, который находится в том же регионе, что и ваши серверыfrontend-01 иdatabase-01. Затем установитеnmap:
sudo apt-get update
sudo apt-get install nmapЗатем используйтеnmap для сканирования общедоступного IP-адреса веб-сервера:
nmap -Pn frontend-01_public_ipOutputStarting Nmap 7.01 ( https://nmap.org ) at 2017-06-05 17:08 UTC
Nmap scan report for 203.0.113.11
Host is up (0.0022s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 4.54 secondsОбратите внимание на результат околоfiltered ports. Если брандмауэр не работал, это будет отображаться какclosed ports. Filtered означает, чтоnmap не может даже подключиться, чтобы определить, открыт порт или закрыт.
Также обратите внимание, что мы видим, что наши порты SSH, HTTP и HTTPS открыты, как и ожидалось.
Далее мы просканируем сервер базы данных. Обязательно используйте частный IP-адрес Droplet, если вы настроили его таким образом, поскольку именно это будет прослушивать база данных MySQL:
nmap -Pn database-01_private_ipOutputStarting Nmap 7.01 ( https://nmap.org ) at 2017-06-05 17:21 UTC
Nmap scan report for 198.51.100.20
Host is up (0.0024s latency).
Not shown: 999 filtered ports
PORT STATE SERVICE
22/tcp open ssh
Nmap done: 1 IP address (1 host up) scanned in 8.17 secondsМы видим, что большинство портов фильтруются, как и раньше. Однако мы видим только открытый порт SSH без доступного порта MySQL. Напомним, что мы ограничили доступ к базе данных только для серверов, помеченныхfrontend. Вернитесь в панель управления DigitalOcean и добавьте тегfrontend на сервер, с которого вы используетеnmap. Затем повторите команду:
nmap -Pn database-01_private_ipOutputStarting Nmap 7.01 ( https://nmap.org ) at 2017-06-05 17:22 UTC
Nmap scan report for 198.51.100.20
Host is up (0.0033s latency).
Not shown: 998 filtered ports
PORT STATE SERVICE
22/tcp open ssh
3306/tcp open mysql
Nmap done: 1 IP address (1 host up) scanned in 4.46 secondsПорт MySQL теперь отображается как открытый. Мы убедились, что оба наших сервера теперь защищены нашими правилами облачного брандмауэра. Теперь вы можете восстановить исходные настройки брандмауэра этого тестового сервера, вернувшись в панель управления и удалив тегfrontend капли.
Заключение
В этом руководстве мы заменили настройку брандмауэраufw на гибкую и мощную конфигурацию облачного брандмауэра на основе сети. Дополнительные сведения об использовании облачных межсетевых экранов черезdoctl или API DigitalOcean см. В следующих статьях: