Назад | Перейти на главную страницу

Брандмауэр Windows - массовое блокирование диапазонов IP-адресов - соображения производительности?

Одна из наших услуг - экстранет для эксклюзивного использования 200 нашими сотрудниками по всей Великобритании. Мы наблюдаем огромное количество попыток входа в систему из Китая, России, Украины и Нигерии. У меня есть большие списки диапазонов IP-адресов, которые я хотел бы заблокировать. Есть тысячи записей.

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

Я написал сценарий Powershell, который обновляет список каждые 24 часа и заполняет брандмауэр Windows правилами блокировки. Но я нервничаю по поводу его активации.

У меня вопрос: насколько эффективно брандмауэр Windows обрабатывает тысячи правил блокировки таким образом? Например, если мой скрипт содержит 10 000 правил блокировки (или даже 100 000), будет ли он работать эффективно или остановится?

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

ОБНОВИТЬ

Я решил рискнуть и запустить сценарий PowerShell. Я выбрал немного другую технику. Вместо того, чтобы создавать 6700 правил (охватывающих миллионы IP-адресов), я создал одно правило и отправил все плохие диапазоны IP-адресов в родительский раздел всех удаленных адресов.

Результат: Отлично работает. Блокирует большую часть Китая, России, Тайваня, Украины и Нигерии, откуда мы получаем большинство попыток взлома входящих сообщений. И заметной разницы в производительности нет. Кажется, мы обслуживаем такое же количество запросов без каких-либо изменений. Один для брандмауэра Windows. Кажется, он действительно может очень эффективно обрабатывать тысячи IP-блоков.

ОБНОВЛЕНИЕ 2 - ОБРАТНАЯ СВЯЗЬ

Сценарий существует уже несколько дней, поэтому я подумал, что вы будете признательны за отзывы о том, как он продвигается. Я настроил сценарий как запланированное задание для ежедневного выполнения, обновляя брандмауэр с новыми диапазонами IP-адресов, считывая из файла CSV. Все это работает отлично, межсетевой экран работает очень быстро. тем не мение Есть одно предостережение: сам сценарий занимает ок. 4–5 минут на выполнение, в течение которых ЦП работает до предела, а веб-запросы выполняются крайне медленно.

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

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

Вот сценарий:

$csv = Import-Csv -Path 'C:\Scripts\IP Block List.csv'

$data = @()
$csv | ForEach-Object { $data += $_.From + "-" + $_.To }

Set-NetFirewallRule -Name "BlockAllIPsInList" -RemoteAddress $data

А вот и образец CSV-файла:

From,To
1.2.3.4,1.2.3.255

Итак, в этом примере он заблокирует все от 1.2.3.4 до 1.2.3.255 включительно

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

Даже если наши сценарии отличаются, я хотел бы поделиться: у меня есть небольшой VPS (1 ЦП, 256 МБ ОЗУ), на котором запущено несколько сервисов в Linux, а в брандмауэре есть тысячи правил, запрещающих целые блоки адресов, охватывающих целые страны, и Я не видел замедления.

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

Мы сделали это с игровым сервером. В конце концов мы заменили его плагином на pfsense, но мы не заметили никакого снижения производительности с несколькими тысячами IP-блоков в брандмауэре Windows. Блокировка на основе IP - одна из самых элементарных задач, которые может выполнять межсетевой экран. Помимо накладных расходов на управление (у вас уже есть сценарий для этого), я не вижу никаких причин, по которым может возникнуть проблема. FWIW, я смотрел на использование route53 от Amazon для этого, но в то время это не служило нашей цели. Это позволит вам разрешить фиктивный IP-адрес в этих странах.