Часть 2.4. Защита Linux с помощью локального брандмауэра и разрешение удаленного http-доступа

Область применения: .NET Core 2.1, .NET Core 3.1, .NET 5

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

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

Для выполнения этой части руководства отсутствуют предварительные требования.

Цель этой части

Вы узнаете, как защитить виртуальную машину Linux, настроив брандмауэр.

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

• Nginx работает автоматически и прослушивает запросы, отправленные через порт 80
• Nginx, настроенный как обратный прокси-сервер и маршрутизация входящих запросов в приложение ASP.NET Core, прослушивающее порт 5000.
• Приложение ASP.NET Core, настроенное для автоматического запуска после перезапуска сервера или при остановке или сбое процесса.

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

Почти все дистрибутивы Linux включают локальный брандмауэр, который называется iptables. Это руководство новичка достаточно для быстрого начала. Iptables — это упрощенный, но мощный брандмауэр, использующий цепочки политик для разрешения или блокировки трафика.

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

Хотя iptables является упрощенным брандмауэром, это не просто управлять постоянными правилами. К счастью, существует несколько средств настройки брандмауэра, которые упрощают настройку правил брандмауэра в Linux. Согласно официальной документации по брандмауэру Ubuntu, используется ufwсредство настройки брандмауэра по умолчанию для Ubuntu. Это средство предоставляет более удобный для пользователя метод, чем iptables, который предоставляет для создания брандмауэра на основе узла IPv4 или IPv6.

Примечание.

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

Виртуальная машина Linux, используемая в этом руководстве, не защищена любым правилом брандмауэра. Это связано с тем, что, хотя iptables установлен и запущен, нет определенных правил.

Цель заключается в том, чтобы разрешить только трафик HTTP и SSH (Secure Shell) для доступа к виртуальной машине извне. Чтобы достичь этого, выполните следующие действия.

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

2. Внимание

   Явным образом добавьте правила SSH и HTTP allow. Кроме того, обратите внимание, что если порт SSH настроен на другое значение, отличное от значения по умолчанию 22, следует разрешить этот порт. Например, если вы изменили порт SSH на 2222, выполните следующую команду: sudo ufw allow 2222

3. Задайте правило по умолчанию как правило "запретить". Это гарантирует, что если протокол отличается от SSH или HTTP, правило по умолчанию "запретить" отклонит трафик. Например, входящий HTTP-трафик будет отклонен.
4. ufwВключите .

Команды для этих действий перечислены на следующем снимке экрана.

Это то, что происходит на каждом шаге.

1. проверяет состояние ufw, выполнив sudo ufw status verbose команду. По умолчанию ufw не включен и неактивен.

2. выполняет sudo ufw default allow команду. Так как не существует другого правила, отличного от правила "разрешить" по умолчанию, каждый порт на виртуальной машине будет открыт.

3. Внимание

   Добавьте протокол SSH в список разрешенных sudo ufw allow ssh , выполнив команду. Protocol.ssh — известный протокол, который определяется в файле /etc/services . Таким образом, "ssh" можно использовать вместо "22". Помните, что если служба SSH настроена для прослушивания порта, отличного от порта по умолчанию 22, необходимо явно добавить другой порт. Например, если вы настроите SSH для прослушивания порта 2222, выполните следующую команду: sudo ufw allow 2222

4. Разрешите протокол HTTP, выполнив команду sudo ufw allow http. HTTP — это известный протокол, определенный в файле /etc/services. Поэтому можно использовать имя протокола и sudo ufw allow http выполнить команду. Выполнение sudo ufw allow 80 также является совершенно допустимым.

   Примечание.

   После разрешения протоколов SSH и HTTP необходимо добавить все остальные протоколы в список "запрет".

5. Это можно сделать, изменив правило по умолчанию, чтобы запретить, выполнив sudo ufw default deny команду. Разрешены только протоколы SSH и HTTP. Другие протоколы будут отклонены.

6. Включение ufw.

Ниже приведены выходные sudo ufw status verbose данные после завершения этой процедуры.

После настройки брандмауэра проверьте, работает ли он.

Тестирование локального брандмауэра

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

Прежде чем создать это правило "запретить", убедитесь, что приложение доступно браузеру в текущей конфигурации. Для этого измените файл C:\Windows\System32\drivers\etc\hosts на клиентском компьютере, добавив имя узла buggyamb и используя общедоступный IP-адрес виртуальной машины Linux. Имя узла buggyamb разрешает IP-адрес виртуальной машины Linux. Вы можете добавить любое имя узла в файл узлов или подключиться непосредственно к общедоступному IP-адресу виртуальной машины Linux.

Убедившись, что HTTP-запросы могут получить доступ к виртуальной машине, попробуйте включить правило, которое блокирует ТРАФИК HTTP. Убедитесь, что брандмауэр работает. Для этого добавьте правило "запретить" для HTTP, выполнив команду sudo ufw deny http. Это добавляет два правила "запретить" для протокола HTTP (через порт 80). Один — для IPv4, другой — для IPv6.

Снова откройте браузер, а затем попробуйте получить доступ к приложению ASP.NET Core, работающему в Linux.

На этом снимка экрана показан ожидаемый результат.

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

Это то, что происходит на каждом шаге.

1. Добавлено правило "запретить" для протокола HTTP.

2. Команда была запущена wget buggyamb-external . Как можно угадать, имя узла buggyamb-external разрешает общедоступный IP-адрес виртуальной машины Linux. Для этого измените /etc/hosts файл с помощью vi. Как показано, пытались подключиться к нему, wget но никогда не удалось. Чтобы выйти из операции, пришлось нажать клавиши CTRL+C.

3. Добавлено правило allow для протокола HTTP.

4. wget buggyamb-external Выполнение команды снова дало разные результаты. На этот раз удалось подключиться, wget так как протокол HTTP был разрешен. Как показано ниже, wget скачивает файл Index.html в текущий каталог.

Теперь вы еще один шаг ближе к завершению требуемой конфигурации для отладки приложения ASP.NET Core. Прежде чем перейти к следующей части, убедитесь, что протокол SSH и HTTP разрешены в локальном брандмауэре.

Следующие шаги

Часть 2.5. Копирование файлов из среды разработки на виртуальную машину Linux и извлечение файлов в Linux.