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

 

 

Меры противодействия рассмотренной атаке

Несмотря на политику безопасности в компании X и попытки следовать этой политике, в разработанных правилах есть несколько серьезных просчетов, которые стоит обсудить далее. Наиболее важные проблемы:
▼ отсутствие блокирования брандмауэром ТСР-порта 1433;
■ использование сервером SQL учетной записи с уровнем прав, большим, чем это необходимо;
■ неправильная с точки зрения защиты конфигурация IIS-серверов и отсутствие исправлений (чем можно было предотвратить использование ошибки +. htr);
* незащищенность внутренней сети от вредоносных действий внутри демилитаризованной зоны.
Правильная настройка брандмауэров является обязательным условием для существования сети. Если сервер SQL находится в демилитаризованной зоне, то доступ к нему должны получать только те машины демилитаризованной зоны, которым это действительно нужно. Ключевой ошибкой в рассмотренном примере была возможность доступа из внешней сети. Иногда удаленные разработчики требуют доступ к серверу SQL, чтобы иметь возможность работать с ним из дома, но делать этого не рекомендуется. Если удаленный доступ — обязательное условие, рассмотрите использование других средств защиты, таких к№ виртуальная частная сеть и фильтры IPSec.
Другая трагическая ошибка — использование приложением учетной записи администратора (на) и хранение ее данных в файле global.asa. Это очень распространенная ошибка, которая в большинстве случаев обусловлена элементарной ленью разработчиков. При ис­пользовании учетной записи sa разработчики никогда не должны требовать дополнительных прав или разрешений. Это может быть допустимо во время разработки, но впоследствии обязательно необходимо создать учетную запись с как можно более низким уровнем прав, достаточным для работы приложения.
В рассмотренном примере Макс смог получить данные учетной записи сервера SQL через сервер IIS, поскольку администратор не соблюдал необходимых правил применения "горячих исправлений" и/или пакетов обновления. Когда приходится работать в системе с закрытым исходным кодом, такой как система семейства Windows NT, невозможно самостоятельно исправлять ошибки защиты. Это кажется некоторым ограничением, но компания Microsoft прилагает все усилия, обеспечивая оперативный выпуск исправлений и обновлений своих программ. Все, что теперь нужно, — использовать их. Даже несмотря на то, что это вполне логично, администраторы снова и снова не следят за обновлениями. Это стратегическая ошибка, в политику обеспечения безопасности обязательно должно входить своевременное и упорядоченное использование всех выпускаемых исправлений и обновлений, связанных с защитой.
В случае ошибки + . htr даже не требовалось устанавливать обновление. В списках обязательных действий для обеспечения безопасности от Microsoft (Microsoft's IIS Security Checklists) есть подробные инструкции по отключению связей файлов сценариев с неиспользуемыми библиотеками ISAPI, этими действиями блокируется использование ошибки + .htr (см. главу 10, "Хакинг сервера IIS").
И наконец, слишком опасно устанавливать сервер SQL на машине с двумя сетевыми адаптерами, подключенной к двум физическим сетям, так как внутренняя сеть может стать доступной в результате взлома узла демилитаризованной зоны. Нужно всегда серьезно рассматривать необходимость разрешения инициации соединений с внутренней сетью для машины из демилитаризованной зоны и использовать несколько сетевых адаптеров только в тех случаях, когда это необходимо для обеспечения связи. Позже в данной главе будут описаны другие меры по защите сети от атаки, аналогичной той, которой подверглась компания X.
Концепции безопасности SQL Server
Перед тем как углубиться в систему безопасности сервера SQL, обсудим некоторые базовые концепции, сформировавшиеся за несколько последних лет. Необходимо отметить, что сервер SQL изначально разрабатывался для операционной системы OS/2 компании IBM при содействии фирмы Sybase. Когда компания Microsoft решила создать собственную версию этой программы для Windows NT, появилась программа SQL Server 4.2 (также известная как Sybase SQL Server). Вскоре компания Microsoft купила код и разработала сервер SQL Server6.0 уже без участия фирмы Sybase. С того времени были выпущены несколько исправленных И улучшенных версий, во многом программа изменилась по сравнению с исходным вариантом времен Sybase. Однако, как мы видим, компания Microsoft по-прежнему использует части исходной модели безопасности, многие из них и до сегодняшнего дня замедляют работу программы.
Сетевые библиотеки
Сетевые библиотеки (Network libraries, netlibs) — это механизмы, посредством которых клиенты и серверы SQL обмениваются пакетами данных. Один экземпляр сервера SQLServer может поддерживать одновременно несколько сетевых библиотек, ожидающих подключения, а версия программы SQL Server 2000 может теперь поддерживать несколько экземпляров сервера SQL Server одновременно — все они могут ожидать соединения с разными сетевыми библиотеками. По умолчанию включены и ожидают соединения протокол TCP/IP и именованные каналы (как и в многопротокольном сервере SQL Server 7.0). Это значит, что стандартную инсталляцию программы SQL Server можно легко обнаружить с помощью сканирования портов по используемому по умолчанию ТСР-порту 1433.
Среди сетевых библиотек, которые поддерживает сервер SQL Server, можно назвать следующие: .
Т AppleTalk
■ Multiprotocol
■ Netware IPX/SPX
■ Banyan VINES
■ Shared Memory (только для локального сервера) * Virtual Interface Architecture SAN
До появления программы SQL Server 2000 единственным способом шифрования данных между клиентом и сервером было использование многопротокольной сетевой библиотеки. Эта библиотека обеспечивала поддержку собственного симметричного алгоритма и нуждалась в аутентификации NT перед соединением. Однако в версии SQL Server 2000 появилась сетевая библиотека SuperSockets, которая дает возможность использовать протокол SSL для любой сетевой библиотеки при условии, что сертификат соответствует имени DNS для кон­кретного сервера SQL Server. Учтите, что для использования сертификата служба SQL Server (MSSQLServer) не может выполняться в контексте учетной записи LocalSystem.
Режимы безопасности
SQL Server способен работать в двух режимах безопасности: т режим аутентификации Windows;
А режим аутентификации SQL Server и Windows (смешанный режим).
В режиме аутентификации Windows пользователи системы получают доступ к серверу SQL Server напрямую (используя свои пароли в системе Windows NT), поэтому пользователю не требуется отдельное имя для доступа к службе SQL Server. Это значительно упрощает администрирование, поскольку администратор не будет постоянно создавать, обновлять и удалять пользователей сервера SQL. Такой режим официально рекомендован компанией Microsoft и спользуется в SQL Server 2000 по умолчанию.
Для подключения к серверу SQL Server в режиме аутентификации Windows используется следующая строка соединения, если используется провайдер OLE Database (OLE DB) для доступа к SQL Server.
"Pravider=SQLOLEDB;Data -Source-my_server;Initial Catalog-my_datbase; 4> Integrated Security=SSPI "
В смешанном режиме пользователи могут проходить дополнительную аутентификацию с помощью пары значений "имя пользователя/пароль". Такой режим доступен только в инстал-
ляциях сервера SQL для Windows 98/Ме (Personal Edition), поскольку эти платформы не поддерживают аутентификацию по стандарту Windows NT. Необходимо отметить, что по причине простоты модели безопасности смешанный режим используется очень часто, несмотря даже на то, что он не устанавливается по умолчанию.
Для подключения к службе SQL Server с использованием отдельных имен пользователей используется следующая строка соединения (если используется провайдер OLE DB).
"Provider=SQLOLEDB;I!ata Source=my_server;Database=my_datbase; User Id=my_user,-Password=my_password; "
Имена пользователей
Имя пользователя (login) для программы SQL Server — это учетная запись, которая дает доступ к самому серверу. Все имена пользователей SQL Server хранятся в таблице sysxlogins главной базы данных. Даже при использовании аутентификации Windows сохраняется или идентификатор S1D пользователя, или уровень доступа группы. Для имен пользователей сервера SQL Server создаются 16-байтовые глобальные идентификаторы GUID (Global Unique Identifier), которые заносятся в поле SID. Пароли учетных записей сервера SQL Server хранятся в этой же таблице в зашифрованном виде. Вход в систему предоставляет только доступ к серверу, а для работы с данными потребуется учетная запись.
Пользователи
Пользователь (user) — это отдельный тип учетной записи, которая связана с определенным именем пользователя и используется для обозначения доступа к определенной базе данных. Пользователи хранятся в отдельных базах данных в таблице sysusers. Только пользо­ватели могут получать доступ к объектам баз данных. В таблице sysusers пароли не хранятся, поскольку пользователи не аутентифицируются (как это происходит с именем пользователя). Пользователь просто связан с некоторым именем пользователя, т.е. аутентификация уже произошла.
Роли
Для удобства администрирования и обеспечения безопасности пользователи и имена пользователей могут быть сгруппированы в определяемую администратором базу данных ролей (roles). Она дает возможность не управлять отдельно правами каждого объекта и разделить по категориям специальные привилегии. Роли бывают следующих типов:
т Фиксированные серверные роли (sysadmin, serveradmin, security admin и тд..);
■ Фиксированные роли для баз данных (db_ovmer, db_ac cess admin, db_security admin итд.);
■ Пользовательские роли баз данных;
* Роли приложений (sp_setapprole).
Фиксированные серверные роли обеспечивают особые привилегии для операций на уровне сервера, таких как резервное копирование, передача больших объемов данных, администрирование безопасности. Фиксированные роли баз данных предоставляют проверенным (trusted) пользователям возможность выполнять мошные функции программ для работы с базами данных, такие как создание таблиц, создание пользователей, присваивание прав. Пользовательские роли баз данных создаются для упрощения администрирования, позволяют группировать пользователей и на-
значать права группам пользователей. Роли приложений позволяют администратору базы данных SQL вообще не давать пользователям привилегий в базе данных, вместо этого пользователи должны обращаться к базе данных через приложение, которое во время работы дает возможность всем пользователям совместно использовать одну учетную запись. Эта роль используется с целью не предоставлять пользователям возможности обращаться к серверу SQL Server вне приложения (через Excel, Access или другим способом).
Ведение журналов
К сожалению, в SQL Server механизм ведения журналов аутентификации довольно слаб. По умолчанию он отключен, а после включения создаются записи только об успешном или неудачном подключении от имени определенной учетной записи. Не записывается инфор­мация об исходном приложении, имени узла, IP-адресе, сетевой библиотеке, никакой информации, которая помогла бы определить источник атаки. Пример записей в журнале во время прямолинейной атаки с помощью подбора пароля показан на 1.
Нужно заметить, что SQL Server 2000 имеет функцию ведения журналов С2. Если в системе достаточно дискового пространства для хранения столь подробной информации (а это очень много информации), то можно включить аудит С2 с помощью следующих команд в рограмме Query Analyzer или osql.
exec sp__conf igure 'C2 AudiC Mode ' , 1 reconfigure

 

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