Я уже опубликовал два материала об уязвимых местах серверов SQL Server, обращенных в Интернет (или доступных из публичной сети) и работающих с включенным режимом проверки подлинности SQL Server. В первой статье, «Спастись от надвигающейся бури» (опубликована в Windows IT Pro/RE № 11 за 2013 год), речь шла о том, почему проверка подлинности SQL Server связана с огромными неудобствами из-за отсутствия какой бы то ни было логики, блокирующей регистрацию после нескольких подряд неудачных попыток регистрации. В результате проверка подлинности SQL Server не имеет совершенно никакой защиты от атак методом подбора.

Во второй статье, SQL Server Authentication on Internet Facing Servers (http://sqlmag.com/blog/sql-server-authentication-internet-facing-servers), было показано, как часто серверы SQL Server в моей лаборатории подвергались атакам методом подбора с попыткой регистрации в качестве системного администратора после того, как я открыл сервер для «внешних сетей». В среднем каждую секунду происходило больше 6 атак методом подбора.

Краткие выводы:

  • Следует избегать использования проверки подлинности SQL Server всегда, когда это возможно. Уровень безопасности просто не такой, как при доверенной (или Windows) проверке подлинности.
  • Старайтесь не открывать серверы SQL Server для доступа из внешних сетей и используйте другой порт, если возможно. Выбор другого порта не защитит вас, но немного снизит риск, так как сервер будет гораздо менее заметной мишенью.
  • Если не удается избежать ни одного из этих сценариев, нужно использовать очень надежные (длинные) пароли и секретные фразы для регистрации и периодически просматривать журналы.

Знакомимся с IPMuncher

IPMuncher — превосходный инструмент, выполняющий следующие функции:

  • Контроль журналов ошибок Windows. По умолчанию осуществляется поиск ошибок, связанных с типовыми векторами атаки и эксплуатации уязвимостей. Но программу можно настроить для отслеживания любых ошибок или даже неструктурированных файлов, помещенных в определенный каталог.
  • Анализирует ошибки по мере возникновения и перехватывает IP-адрес, связанный с ошибкой или файлом.
  • Сопоставляет IP-адреса и события с правилами (именуемыми IPMuncher Watch Rule), определяющими дальнейшие действия.
  • Инициирует изменения в брандмауэре Windows при выполнении условий IPMuncher Watch.

Поэтому, в сущности, если SQL Server настроен на протоколирование или аудит неудачных попыток регистрации (см. раздел «Turn on Failed Login Auditing»), а затем назначено правило IPMuncher для блокирования любого IP-адреса, с которого были выполнены, например, три неудачные попытки регистрации менее чем за три минуты, то IPMuncher формирует новое правило брандмауэра Windows. Обратите внимание, что эта ошибка будет выдана независимо от того, используется ли при регистрации проверка подлинности Windows или SQL, поэтому следует соответствующим образом скорректировать частоту сбоев.

Лучше один раз увидеть, чем сто раз услышать

Чтобы получить более полное представление об инструменте, взгляните на страницу журналов SQL Server (экран 1), которую я увидел несколько месяцев назад при подключении сервера к «внешней сети» (порт 1433), когда хотел выяснить, насколько регулярно он будет подвергаться атакам.

 

Свидетельства совершенных атак
Экран 1. Свидетельства совершенных атак

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

В этих условиях IPMuncher сформировал правило (см. экран 2), которое слегка изменил (поэтому оно отличается от получаемого сразу после установки IPMuncher на компьютере).

 

Правило IPMuncher
Экран 2. Правило IPMuncher

Мое правило на пять дней блокирует любой IP-адрес, связанный с ошибкой SQL Server 18456 (определенной на вкладке Windows Log Properties), если сообщения об ошибке (или неудачные попытки регистрации) повторяются три раза за три минуты.

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

 

Три неудачных попытки регистрации с одного IP-адреса
Экран 3. Три неудачных попытки регистрации с одного IP-адреса

Причина в том, что новое правило брандмауэра Windows (созданное IPMuncher) блокировало тот самый IP-адрес, см. экран 4.

 

Блокировка IP-адреса
Экран 4. Блокировка IP-адреса

Огромное достоинство этого метода — помимо того, что он работал именно так, как предполагалось — заключается в возможности настроить правило, сделав его менее или даже более строгим, в соответствии со здравым смыслом и обстоятельствами. Это позволяет полностью компенсировать отсутствие блокировок в механизме проверки подлинности SQL Server, просто запрещая подозрительный IP-адрес на указанное (или неопределенное) время.

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

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF