На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

Изменения в программе SQL Server

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

10ч

[Щблйца 11 ...Изменения в SQLServer 2000|
связанные Ё системой безопасности

Изменения
Работа нескольких экземпляров
Поддержка протокола SSL для сетевых библиотек
Теперь для внутреннего шифрования используется интерфейс CryptoAPI
Аудит по стандарту С2
ТИП данных sql_variant
После установки по умолчанию используется аутентификация Windows, а не смешанный режим аутентификации
Новая исправленная серверная роль Buikadnin
Комментарии
Новый механизм, который поддерживает ату функцию, позволяет нанести ущерб, так как изменение номеров ТСР-портоа может не дать результата
Хорошее усовершенствование. Используйте его, если есть риск взлома
Удаление собственных механизмов шифрования — хороший способ защиты
Иногда эта функция позволяет получить подробнейший журнал, но использование рекомендуется при наличии больших объемов свободного места на дисках
Этот тип данных, к несчастью, упрощает хакерам SQL ввод кода в приложения, позволяя злоумышленнику обойти проверку типа данных в операторах union
Это существенное улучшение. Установленное приложение должно обеспечивать безопасность в конфигурации по умолчанию. Очень плохо, что большинство разработчиков переключаются в смешанный режим сразу после установки программы
Теперь пользователи могут загружать большие объемы данных, не имея прав системного администратора. Это просто прекрасно!
Отреагировав на предложения пользователей, компания Microsoft сможет исправить оставшиеся проблемы. Вы можете написать в Microsoft по поводу любых серьезных вопросов (sqlwisMmicrosof t. com). Наш список пожеланий включает жалобы на безопасность входа в сервер SQL (блокировки, устойчивость пароля, правила и т.д.), добавление функций шифрования (новые хранимые процедуры и т.д.) внутри сервера SQL Server и как можно более мощных функций шифрования хранимых процедур. Добавьте свои пожелания, и вполне возможно, что они будут учтены в следующей версии SQL Server (под кодовым названием "Yukon").
Хакинг SQL Server
До настоящего времени компания Microsoft пользовалась дурной славой по причине различных ошибок в US-сервере (см. главу 10, "Хакинг сервера IIS"), но SQL Server пока не подвергался серьезной критике. Это не значит, что в сервере SQL Server нет своих ошибок, — просто он не привлекает такого внимания со стороны сообщества хакеров. Наверное, такая ситуация возникла из-за относительно небольшого количества автоматизированных средств атаки на SQL Server, доступных на данный момент. Либо тот минимум знаний, необходимый для успешных атак на SQL Server, выше уровня, достаточного для про-
стых хитростей с протоколом HTTP, которые лежат в основе программ атаки на US-сервер. Какой бы ни была причина, постепенно появляются специализированные утилиты, и хакеры начинают осознавать, что знания основ SQL могут проложить широкий путь К корпо­ративным хранилищам данных. Пришло время обратить внимание на безопасность в SQL Server и защитить наиболее уязвимые ресурсы. Эта глава должна побудить вас к действиям!
Сбор информации о сервере SQL Server
Наиболее опытные хакеры готовы потратить время на сбор максимально возможного количества информации о потенциальной цели до того, как перейти к направленным действиям. Их задача — убедиться в том, что попытка взлома будет основана на подходящих методах и не вызовет ответной реакции систем обнаружения вторжений. Кроме общедоступных источников, таких как Web-сайт интересующей организации (на котором можно найти такие ценные данные, как свободные вакансии) или различные списки доменных имен, хакер обычно может собрать огромное количество информации о большинстве целей из следующих источников.
Поиск в группах новостей
Независимо от того, насколько хорошим разработчиком вы являетесь или сколько лет вы администрируете серверы Microsoft, вам обязательно когда-нибудь потребуется совет. Первым источником, где вы будете искать помощи (до того, как обратиться в службу поддержки Microsoft), станет группа новостей. Но обращаясь к другим за помощью, вы можете случайно опубликовать ценную информацию об используемых технологиях, уровне знаний персонала, а возможно даже и подробности системы защиты, такие как строки соединения ADO (ActiveX Data Object) и настройки режима безопасности в SQL Server.
Стандартным местом поиска таких технических подробностей являются хранилища групп новостей, например groups.google.com, где можно выполнить расширенный поиск информации о потенциальной цели. Обычно проводят поиск сообщений от пользователей с оп­ределенным доменным именем, а затем сосредоточиваются на статьях, в которых может быть подробная техническая информация о типах баз данных, настройках системы безопасности или определенных приложениях.
Попробуйте выполнить подобный поиск информации о своей компании.
1. Откройте Web-страничку groups . google. com.
2. Нажмите кнопку "Advanced Group Search" (Расширенный поиск групп).
3. В поле "With A]] of the Words" (Со всеми словами) введите имя своего домена.
4. В поле "With the Exact Phrase" (С точной фразой) введите слова sql server.
5. Нажмите кнопку Google Search (Поиск в Google).
Если кто-то из вашей компании с 1995 года и до настоящего времени отправил в группы новостей сообщение, касающееся программы SQL Server, оно обязательно найдется. Взгляните на найденные сообщения и посмотрите, какая информация могла попасть в руки хакеров. Другая потенциально опасная информация, которую могут найти потенциальные хакеры с помощью Google, включает в себя строки соединений (http: //www. connectionstrings. com), поля скрытых форм, уязвимые примеры Web-страниц и Web-страницы администраторов.
Мы никого не отговариваем пользоваться группами новостей, просто всегда нужно учитывать, что любое письмо может существовать вечно и его может прочитать кто угодно. Знания можно использовать и в добрых целях, и в злых.
Сканирование портов
Сканирование портов стало настолько распространенным явлением, что большинство администраторов безопасности не имеют ни времени, ни желания расследовать каждую попытку сканирования, которая появляется в журналах брандмауэра. При правильно настроенном брандмауэре сканирование портов не принесет полезных результатов. Однако во многих случаях администраторы безопасности оставляют открытыми порты сервера SQL Server, чтобы разработчики и/или удаленные сотрудники имели доступ к базам данных. Эта серьезная ошибка может стать благом для взломщиков сервера SQL Server, и можно ставить последний доллар на то, что злоумышленники постараются найти такие сведения.
Сканирование сервера SQL Server начинается с проверки открытости ТСР-порта 1433 для всех IP-адресов, использующихся интересующей организацией. ТСР-порт 1433 используется по умолчанию для подключения к серверу SQL Server сокетов TCP/IP сетевых библиотек и обычно считается доказательством запущенного сервера SQL на данном узле, поскольку по умолчанию сетевая библиотека устанавливается и с программой SQL Server 7.0 и с SQL Server 2000. Если в журналах маршрутизатора или брандмауэра обнаружатся записи о сканировании порта 1433, значит, кто-то пытается найти серверы SQL Server в организации.
Программа SQLPing
Есть еще один способ сбора информации, с помощью программы SQLPing. Поскольку сервер SQL Server 2000 поддерживает существование нескольких экземпляров программы, необходимо, чтобы сервер мог связываться с клиентом и передавать ему информацию о каждом экземпляре программы, который существует на сервере. Программа SQLPing использует механизмы сервера SQL Server 2000 для запроса информации о соединениях сервера и предоставляет полученные данные пользователю. Она работает через UDP-порт 1434, который используется распределителем экземпляров (который называют SQL Resolution Service) для службы SQL Server. Запросы можно посылать в виде широковещательной передачи по заданным подсетям, так что во многих случаях при слабой защите брандмауэра можно полностью прозондировать подсеть с помощью только одного пакета!
Рассмотрим пример запроса SQLPing, который позволил обнаружить два узла (1).
C:\tools>aqlptng 192.168.1,255
SQL-Pinging 192.168.1.255
Listening----
ServerNarae;SEAHAG InstanceName: MSSQLSERVER IsClustered;No Version:8.00.194 tcp:2 43 3
np:\\SEAHAG\pipe\sql\query
ServerName:BRUTUS2 InstanceName: MSSQL. Server IsClustered:No Version:8.00.194 Прт\\BRUTUS2\pipe\sql\query tcp:1433
Как видите, ответный пакет для SQLPing содержит следующие данные: ▼ Имя сервера SQL;
■ Имя экземпляра (по умолчанию используется экземпляр MSSQLServer);
■ Кластер-статус (является ли сервер частью кластера);
■ Версия (до версии SQLPing 1.3 предоставлялось только название основной версии);
А Подробности поддержки сетевых библиотек (в том числе используемые ТСР-порты, имена каналов и т.д.).
Фактически оказывается, что даже если предусмотрительный администратор изменил используемый по умолчанию порт программы SQL Server, который ожидает подключения соке-тов TCP/IP, то с помощью утилиты SQLPing злоумышленник может легко узнать у сервера, какой порт нужно использовать. Информация, полученная от утилиты SQLPing, может помочь выделить наиболее интересные цели (например те, которые поддерживают кластерную технологию для повышения доступности) и серверы, на которых не были установлены пакеты обновления (по версиям используемых программ). Все это может накликать беду на- ваш SQL Server. Очевидной защитой от использования SQLPing является блокирование всех (и ходящих, и исходящих) соединений для UDP-порта 1434 на серверах SQL.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика