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

Как отмечалось в недавней публикации ZDNET (http://www.zdnet.com/blog/hardware/cheap-gpus-are-rendering-strong-passwords-useless/13125), если обычным процессорам могут потребоваться часы и даже дни для «переваривания» NTLM-паролей, графические процессоры способны одолеть их за несколько минут или даже секунд. Например, взлом пароля, состоящего из символов fh0GH5h, у обычного процессора может занять 4 дня, а графический процессор среднего уровня сделает это менее чем за 18 минут. Объединив усилия двух высокопроизводительных GPU, можно взломать такой пароль за считанные минуты.

Перспективы взлома паролей

По правде говоря, когда речь идет о взломе NTLM-пароля методом полного перебора, перед хакерами встает большая проблема: они не в состоянии генерировать миллиарды попыток в секунду просто потому, как я полагаю, что уже после нескольких неудачных попыток учетная запись, которую они пытаются взломать, будет заблокирована. Таким образом, мы неплохо защищены от злоумышленников, пытающихся объединить несколько GPU и взламывающих с их помощью пароли полным перебором.

Другими словами, время взлома паролей, указанное в упомянутой выше статье, не было достигнуто в результате реальных атак полным перебором на учетные записи Windows. В действительности они были организованы так, чтобы иметь неограниченный доступ к учетным записям для осуществления подбора пароля (http://www.golubev.com/hashgpu.htm).

Возьмите радужные таблицы (http://www.codinghorror.com/blog/2007/09/rainbow-hash-cracking.html), добавьте к ним массивно-параллельную природу современных GPU, предоставьте доступ к попыткам регистрации в систему без какого-либо механизма, обнаруживающего атаки полным перебором и блокирующего соответствующие учетные записи, и вы получите рецепт потенциальной катастрофы.

Какое отношение это имеет к SQL Server?

В то время как попытки взлома паролей Windows в производственной среде сталкиваются с политиками блокировки учетных записей, ситуация с проверкой подлинности SQL Server не так благоприятна.

Технология проверки подлинности SQL Server не имеет никаких средств обнаружения атак взлома паролей полным перебором.

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

Отсюда, безусловно, следует, что проверка подлинности SQL Server уже созрела для взлома паролей методом полного перебора.

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

Как защититься?

В электронной документации Books Online (http://msdn.microsoft.com/en-us/library/ms144284.aspx) сказано следующее:

«По возможности используйте проверку подлинности Windows». И далее:

«Проверка подлинности Windows является методом проверки подлинности по умолчанию, что намного безопаснее, чем проверка подлинности SQL Server».

Без необходимости не используйте проверку подлинности SQL Server (смешанный режим)

Первое, что можно предпринять против атак полным перебором — не подвергаться им вовсе, используя проверку подлинности Windows (то есть отключив проверку подлинности SQL Server, см. экран 1).

 

Используйте проверку подлинности Windows
Экран 1. Используйте проверку подлинности Windows

Одного этого изменения достаточно для защиты от атаки полным перебором, так как проверка подлинности теперь управляется системой Windows, в которой есть (или обязана быть) политика блокировки учетных записей (вы легко можете проверить наличие политики блокировки учетных записей Windows после X неудачных попыток взлома пароля).

Без необходимости не предоставляйте доступ к SQL Server из Интернета

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

Используйте парольные фразы вместо или в сочетании с политикой паролей

Я уверен, что услышу проклятия в свой адрес за такие рекомендации, но настройка политики паролей в SQL Server для проверки подлинности учетных записей SQL Server требует больших усилий (см. экран 2).

 

Настройка политики паролей в SQL Server
Экран 2. Настройка политики паролей в SQL Server

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

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

Вместо паролей я уже много лет рекомендую использовать парольные фразы (http://en.wikipedia.org/wiki/Pass_phrase), они гораздо легче для запоминания.

Не бойтесь использовать политику паролей для учетных записей SQL Server, но и не делайте сложных настроек, а просто назначьте длину пароля более 15-20 символов, этого будет достаточно.

Скройте или удалите учетную запись SA

Если ваш сервер доступен из Интернета (или вы опасаетесь внутренних злоумышленников), то стоит переименовать или удалить учетную запись SA (http://blogs.msdn.com/b/sqltips/archive/2005/08/27/457184.aspx), так как взлом паролей возможен только тогда, когда хакеры пытаются подобрать пароль существующей и включенной учетной записи. Удалите или отключите учетную запись — и вы лишите хакеров возможности взломать ее.

Включите аудит неудачных попыток регистрации

Обычная рекомендация специалистов по безопасности для серверов SQL Server — включение аудита неудачных попыток регистрации (Failed Login Auditing).

Это именно то, что вам необходимо сделать. Однако у этого вопроса есть две стороны. Во-первых, включение аудита ничего не даст, если вы не будете регулярно проверять журналы SQL Server и находить там учетные записи, имеющие повторяющиеся неудачные попытки входа. И, во-вторых, если вы разрешили проверку подлинности SQL Server, то даже если вы ежечасно проверяете журналы, вы все равно находитесь под угрозой, ведь хакеры могут обнаружить ваш SQL Server и провести против него атаку с полным перебором так быстро, что вы обнаружите ее слишком поздно, особенно в случае доступа к серверу из Интернета. Таким образом, аудит — это одна из ключевых рекомендаций по безопасности. Однако в отношении недопущения возможных атак полным перебором она не настолько важна, как переключение на режим проверки подлинности Windows, отключение доступа к серверу из Интернета и использование безопасных парольных фраз с достаточной криптографической энтропией, чтобы они не могли быть легко взломаны.

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

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

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

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

Несколько недель назад я потратил определенное время на написание простого. NET-приложения, которое читает записи журналов SQL Server, ищет там информацию об ошибках регистрации в системе login failed, суммирует эти ошибки по учетным записям и формирует простую статистику по количеству этих ошибок (X ошибок всего, Y ошибок в определенный интервал времени).

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