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

 

 

По возможности используйте только аутентификацию Windows

Использование режима аутентификации Windows Only (только Windows) предотвращает прямолинейные атаки на уязвимую модель безопасности SQL Server. Поскольку в этой модели безопасности не предусмотрено никакой системы для создания сложных паролей, уста­новки термина действия паролей и блокировок учетных записей, то SQL Server является легкой добычей для хакеров. Режим аутентификации Windows должен использоваться по умолчанию для всех новых инсталляций, а смена режима аутентификации должна происходить только для поддержки работы новых приложений.
Установить режим аутентификации для SQL Server можно с помощью Enterprise Manager или с помощью запуска следующего сценария T-SQL, который может быть запущен только системнымадминистратором.
IF (charindex('\1,@@SERVERNAME)=0) EXECUTE master.dbo.xp_regwrite N'HKEY_LOCAL_MACHINE',M'Software\Microso£t\MSSQLServer\MSSQLServer1 Ь ,N'LoginMode',N'REG_DWORD',1
ELSE
BEGIN
DECLARE @RegistryPath varchar(200)
SET @RegistryPath - 'Software\Microsoft\Microsoft SQL Server\1 +■ Ь RIGHT(@@SERVERNAME,LEN(@@SERVERHAME)-CHARINDEX(1\1,G@SERVERNAME)) 4> + 1 \NSSQLServer '
EXECUTE master..xp_regwrite 4> 1 HKEY_LOCAL_MACHTNE ' , SRegistryPath, M' LoginMode ' , N' REG_DWORD' , 1
END
Дополнительные методы обеспечения безопасности сервера SQL Server
Чтобы защитить все свои серверы SQL (SQL Server или MSDE), нужно внимательно следить за обеспечением безопасности и требовать того же от администраторов и разработчиков. Учитывайте приведенные здесь рекомендации при разработке политики безопасности организации. Однако не забывайте, что даже самая лучшая политика превращается в пустой звук, если ей не следовать. Добейтесь того, чтобы администраторы и разработчики следовали разработанной политике, несоблюдение правил должно сопровождаться наказанием.
Физически защитите серверы и файлы
Тот, кто может получить физический доступ к серверу SQL Server, получаст миллионы методов доступа к данным. Потратьте время на то, чтобы физически защитить сервер и резервные копии баз данных. Если злоумышленник (например, бывший сотрудник) знает, когда и куда складываются старые ленты с резервными копиями, он может восстановить их на своем сервере SQL. Сделайте привычкой хранить старые ленты в сейфе, а устаревшие копии ликвидируйте также, как и другие ценные документы, например, сжигайте.
Защищайте Web-серверы и клиентов, которые подключаются к серверу SQL Server
Стандартный сценарий взлома программы SQL Server предполагает проникновение на плохо администрируемый сервер MS, который затем служит в качестве плацдарма для атак на сервер SQL Server, Когда хакер получает контроль над сервером HS (или любым клиентским приложением), он обычно находит строки соединения с SQL Server. Пользуясь этой информацией, злоумышленнику легко перейти к атаке на SQL Server. Потратьте время на то, чтобы надежно защитить SQL Server и установите все выпущенные исправления не только для него, но и для всех серверов IIS и клиентов, которые подключаются к вашим серверам SQL Server.
Включите ведение журнала аутентификации в SQL Server
По умолчанию ведение журнала аутентификации в SQL Server отключено. Для исправления ситуации достаточно одной команды, и сделать это рекомендуется как можно раньше. Можно воспользоваться программой Enterprise Manager и заглянуть в свойства сервера на вкладке безопасности (Security) или вызвать команду для SQL Server с помощью программы Query Analyzer или osql. ехе (следующая далее команда разбита на строки).
Master..xp_instance_regwrite N'HKEY_LOCAL_MACHINE', 4>N'SOFTWARE\Microsoft\MSSQLServer\KSSQLServer', 1 Audi tLeve1', REG_DWORD,3
Вести ли аудит неудачных и/или успешных подключений к системе — решать вам, но аудит нужно вести обязательно. Надеемся, в следующих версиях SQL Server аудит будет включен по умолчанию. Доступны и другие средства регистрации событий, например программы Lumigent Log Explorer (http: / / www. lumigent. com) или VigilEnt Audit Manager (http://www.netiq.com/solutions/security/default.asp), которые дополняют недостатки программы ведения журнала, встроенной в SQL Server.
По возможности шифруйте данные
Очень глупо считать свою сеть абсолютно защищенной от перехвата пакетов и других методов пассивного мониторинга. Всегда включайте шифрование данных SQL Server во время проверки защищенности систем. Компания Microsoft старается предоставить огромное количество возможностей шифрования сеансов, и просто позорно не воспользоваться ими, если затраты на шифрование приемлемы (потери производительности компенсируются возможностями шифрования).
Кроме того, помните, что хотя SQL Server не имеет встроенной поддержки для шифрования отдельных полей, можно легко реализовать собственное шифрование через интерфейс Сгур-toAPl от Microsoft и размещать в базе данных зашифрованную информацию. Решения других разработчиков перечислены в конце главы, они позволяют шифровать данные на сервере SQL Server посредством расширенных хранимых процедур (используйте их на свои страх и риск). Если нужно зашифровать саму базу данных и сделать ее недоступной для других пользователей, стоит рассмотреть использование поддержки EPS (Encrypted File System — зашифрованная файловая система) в Windows для выполнения этой задачи (некоторые разъяснения по системе EFS есть в главе 14, "Физические атаки").
Используйте принцип наименьших привилегий
Если человеку, который выгуливает вашу собаку, нужны ключи от задней двери, дадите ли вы ему всю связку ключей от дома и еще ключи от своего автомобиля? Конечно, нет. Так зачем выполнять приложение с учетной записью sa или давать пользователю права владельца базы данных? Затратьте некоторое время на этапе установки приложения, чтобы создать низкопривилегированную учетную запись для ежедневного использования. Назначение конкретных прав доступа ко всем необходимым объектам может отнять немного времени, но все затраты с лихвой окупятся, если кто-то получит контроль над приложением и попытается с его помощью пробить стену защиты.
Те же принципы применяйте и к служебным учетным записям, с которыми выполняется служба MSSQLServer. Во время установки программы SQL Server есть возможность настроить ее для работы с пользовательской учетной записью. Потратьте лишнее время, создайте пользовательскую учетную запись (не администратора) и введите во время установки сервера ее данные. Таким образом, пользователи, которые выполняют расширенные хранимые процедуры как системные администраторы, не смогут получить права системного администратора локальной системы или учетной записи LocalSystem.
Локальные учетные записи в большинстве инсталляций будут работать так же хорошо, как и учетная запись LocalSystem или учетные записи доменов, это описано в документации Books Online. При использовании локальных учетных записей вторжение будет ограничен­ным, так как хакер не сможет воспользоваться полученными привилегиями для получения доступа к другим узлам домена. Учетные записи домена требуются только для вызовов удаленных процедур, интегрированных смешанных запросов, внесистемного резервного копирования или некоторых сценариев копирования. Чтобы подключить локальную учетную запись, после инсталляции воспользуйтесь вкладкой безопасности свойств сервера в программе Enterprise Manager. Просто введите имя локального сервера вместо имени домена, а затем введите имя созданной учетной записи локального пользователя (например имя_сервера\ учетная запись для sql) в поле "This Account". Если изменения вносились через программу Enterprise Manager, то программа SQL Server сама позаботится об изменении разрешений, таких как доступ к параметрам реестра и файлам баз данных.
Выполняйте тщательную проверку вводимых данных
Никогда не доверяйте информации, которая поступает от программы-клиента. Проверку данных на стороне клиента можно легко пропустить, так что ваш код JavaScript не будет надежной защитой. Единственный способ убедиться в том, что переданные клиентом данные не вызовут проблем в приложении, — тщательно их проверить. Проверка не должна быть слишком сложной. Если поле данных должно содержать число, то можно проверить, чтобы введенное число не выходило из допустимого диапазона значений. Если поле ввода может содержать цифры и буквы, то проверьте, чтобы были приемлемы длина и содержимое ввода. Для проверки входных данных на предмет запрещенных символов очень удобно использовать регулярные выражения, даже при сложном формате получаемых данных, например адресов электронной почты, паролей и IP-адресов.
Пользуйтесь хранимыми процедурами с умом
Хранимые процедуры дают приложению преимущества в производительности и безопасности. Хранимые процедуры являются заранее скомпилированными командами SQL, имеют строго типизированные параметры ввода и позволяют разработчику получить доступ на вы­полнение процедуры, не давая прямого доступа к тем объектам, которые используются в процедуре. Фактически, во многих приложениях пользователи не имеют прав ни на какие таблицы, а лишь могут выполнять группу хранимых процедур. Такая конфигурация наиболее предпочтительна, поскольку даже атака введением кода SQL не позволит хакеру получить доступ к ценным данным иначе, чем через хранимые процедуры.
Наиболее распространенная ошибка, которую делают при реализации хранимых процедур, — построение строк команд для передачи строки серверу SQL Если вы реализуете хранимую процедуру, используйте выполнение команд через объекты ADO, чтобы каждый параметр передавался правильно и не было возможности ввести код в строку команды.
Подготовьте сценарий защиты для новых версий SQL Server
Заранее подготовленный сценарий защиты для устанавливаемых версий SQL Server позволяет снизить до минимума вероятность успешной атаки. Нельзя оставлять новые версии без настроенной системы защиты до тех пор, пока до этой версии не дойдут руки системного администратора. Сценарий защиты позволяет реализовать идею "безопасности по умолчанию", что одинаково важно какдля серверных инсталляций SQL Server, так И для инсталляций на рабочих станциях.
Ссылка на пример базового сценария защиты, исходя из которого можно создать подобный сценарий для защиты своей конкретной организации, доступна в конце этой главы, в разделе "Дополнительная литература и ссылки". Среди стандартных действий, которые должны присутствовать во всех сценариях защиты, можно назвать обеспечение безопасности учетной записи sa, включение системы протоколирования событий, аутентификацию пользователей в режиме Windows Only и ограничение доступа к мощным системным и расширенным хранимым процедурам.
При создании собственных сценариев защиты не забывайте, что нужно удалить (или ограничить доступ) такие мощные хранимые процедуры, как xp_cmdshell. Для отключения расширенной хранимой процедуры введите следующие команды T-SQL.
use master . sp_dropextendedproc 'xp_cmdshell'
Если вы предпочитаете просто проверить, что члены общедоступной роли не могут получить доступ к расширенной хранимой процедуре, то можно воспользоваться следующим кодом.
REVOKE execute on xp_instance_regread to public GO
В большинстве случаев нет причин, по которым пользователь или еще кто-нибудь должен использовать ваш сервер SQL Server для выполнения команд в операционной системе. Расширенные хранимые процедуры, которые рекомендуется удалить, перечислены в табл. 11.4. Помните, что квалифицированные хакеры могут заново установить удаленные процедуры, если они уже получили достаточный контроль над сервером. Но, по крайней мере, вы заставите злоумышленника приложить дополнительные усилия, что остановит того, кто не будет иметь достаточных ресурсов для выполнения необходимых действий. Кроме того, предупреждаем, что чрезмерное удаление расширенных хранимых процедур может привести к проблемам при инсталляции пакетов обновлений (SP) и исправлений (Hotfix). При удалении каких-либо хранимых процедур их следует восстановить до использования пакета обновления или исправления Hotfix.
Используйте для поиска уязвимых мест в программах утилиту SQL Profiler
Отличный способ поиска ошибок, которые могут позволить хакеру ввести код SQL,— вводить строку потенциально опасных данных в поля ввода приложения при запушенной программе SQL Profiler и отслеживать получаемые сервером данные. Чтобы облегчить задачу, можно использовать фильтр поля TextData программы SQL Profiler, который соответствует вредоносной строке. Пример вредоносной строки — это что-то простое, например, кавычка, окруженная двумя такими редкими символами, как буква z. Такая строка показана на 8. Процедуры проверки вводящих данных должны либо удалить кавычку, либо преобразовать ее в две кавычки, чтобы кавычка передавалась как буквенный символ.
Используйте сигналы тревоги для мониторинга потенциально опасных действий
Создав сигналы тревоги для ключевых событий программы SQL Server (таких как неудачные подключения), можно оповещать администраторов о возникновении проблем. Например, можно создать сигнал тревоги для событий с номерами 18450, 18451, 18452 и 18456 (неудачная попытка подключения к серверу), в которых есть строка ' sa ' (кавычки нужны, дабы тревога не срабатывала каждый раз при подключении пользователя "Lisa"). Тогда администратор будет оповещаться об обращении к серверу SQL Server в случаях, когда в тексте сообщения встречается слово sa, что характерно для атак перебором.
Рассмотрите идею нанять или обучить персонал для тестирования
Если компания постоянно занимается разработкой нового программного обеспечения, проведение аудита посторонними специалистами может оказаться слишком дорогим мероприятием, поэтому рекомендуется проводить аудит силами существующего или специально нанятого персонала тестировщиков. Поскольку эти люди уже тестируют и проверяют ваши приложения на предмет ошибок и функциональности, они могут эффективно выполнить проверку возможности проведения атак, например атак введением кода SQL, перед выпуском программного обеспечения. Лучше потратить время на предварительное тестирование программ вместо того, чтобы получать сведения со страниц бюллетеня Bugtraq или в другой рассылке, посвященной безопасности, и выпускать потом пакеты обновления.
Эта глава посвящена программе Microsoft SQL Server, связанной с обеспечением безопасности. Начав с примера, который иллюстрирует наиболее широко распространенный механизм взлома SQL, мы продолжили изучение на примере действия модели защиты программы SQL Server. Также упоминались некоторые новые функции защиты, которые компания Microsoft внесла в программу SQL Server 2000 в целях повышения безопасности системы.
Были рассмотрены способы сбора информации о базах данных SQL перед началом атаки. Выявив возможные утечки информации в организации, можно закрыть их еще до того, как до них доберется хакер. Также были рассмотрены некоторые профессиональные программы для исследования SQL Server. Мы рассказали, почему не нужно использовать общедоступный сервер SQL Server в смешанном режиме безопасности.
Далее были изучены некоторые проблемы безопасности, которые обнаружились в SQL Server, и методы защиты в каждом случае. Мы надеемся, что вы доведете информацию о введении кода SQL до разработчиков и убедитесь в том, что причиной следующей бреши в сис­теме защите организации не станет плохое программное обеспечение.
И нахонсц, мы рассказали, как организация может защитить серверы SQL Server и приложения от внутренних и внешних атак. Потратьте время и проверьте инфраструктуру на предмет улучшения безопасности. Помните о том, что глупо полагаться на один уровень зашиты. Все методы хороши в комбинации, поскольку когда (не если) произошел сбой на одном уровне, "прикрыть'" его поможет другой уровень зашиты.
Надеемся, теперь вы полностью представляете всю важность вопросов защиты программы SQL Server и последствия ошибок в системе защите ценных данных. Уделите время созданию каталога всех серверов SQL Server организации и проверьте соответствие их конфигурации лучшим рекомендациям. Если вы всегда будете ставить себя на место хакера, искать на серверах изменения конфигурации и потенциальные ошибки в защите, то есть хорошие шансы на победу.

 

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