(Возврат на основную страницу)
Эдвард Харли (Edward Hurley)
Первооткрыватель уязвимости SQL Server 2000 (использованной червем Slammer) признал, что, хотя этот червь натворил немало бед, он мог оказаться еще более опасным.
«Несмотря на то, что Slammer вывел из строя множество интернет-провайдеров и сетей в прошедшие выходные, он не обладал разрушительными функциями, — говорит Дэвид Литчфиелд (David Litchfield), известый специалист в области уязвимостей и соучре- дитель компании Next Generation Security Software, расположенной в г. Cаттон (Sutton) в Англии. — Он мог быть гораздо опаснее, но его написали для того, чтобы показать, на что способны!»
Slammer использует брешь класса «переполнение буфера» SQL Server Resolution Service, открытую Литчфиелдом еще шесть месяцев назад. Пока этот червь не является разрушительным и только атакует системы Windows 2000. Он может парализовать систему, генерируя массированный сетевой трафик. Кроме того, он наугад сканирует IP-адреса в поисках других уязвимых служб.
По утверждению Литчфиелда, наилучшим способом избежать «заражения» червем является установка на систему специального пакета обновления. Также компании могут, используя брандмауэры, блокировать трафик, идущий на UDP-порт 1434. Эта установка может помешать выполнению некоторых Web-запросов, т. к. DNS-серверы часто используют этот порт для их обработки. «Пользователю достаточно просто нажать кнопку Обновить (Refresh) в браузере, и тогда запрос будет выполняться на порт 1435, — говорит он. — Стоит упомянуть, что администраторам необходимо предварительно оценить, как блокировка трафика через порт 1434 скажется на работе отдельных систем сети».
Чип Эндрюс (Chip Andrews), независимый разработчик из г. Гайнесвилл (Gainesville), штат Джорджия и автор Web-проекта SQLSecurity.com, советует администраторам полностью блокировать порт 1434. «Нет никакой необходимости держать порт 1434 открытым для доступа из Интернета, — утверждает он. — Думаю, что большинство администраторов уже установили (после этих событий) новые правила для своих брандмауэров (заблокировали UDP-порт 1434). Теперь, когда это сделано, появление новых пиков активности червя маловероятно».
Slammer появился через шесть месяцев после того, как Microsoft опубликовала пакет обновления для этой уязвимости. Литчфиелд нашел ее в ходе выполнения теста по проверке системы безопасности по заказу одного из германских банков. «Они хотели, чтобы я заглянул под каждый камень», — шутит Литчфиелд. Стоит отметить, что в ходе этой работы он нашел не только эту брешь в SQL Server, но также ряд других уязвимостей.
Литчфиелду впору сказать: «Я предупреждал вас об этом!». Еще прошлым летом (на проводимом корпорацией BlackHat брифинге по безопасности) он прогнозировал, что эта брешь может быть использована для заражения систем червем. «Я объяснял, что, по сути, это канал для заражения червем и поэтому необходимо, чтобы каждый установил на свою систему “заплату” для защиты», — говорит он.
Сама уязвимость представляет собой классическое, основанное на использовании рассылки огромного количества пакетов, переполнение буфера. По сути, атакующий наполняет выделенное системе пространство оперативной памяти таким количеством данных, что она не может его вместить. Излишние данные затем исполняются на атакуемой системе. Это потенциально опасно в случае с червем Slammer, так как SQL Server и Microsoft SQL Server Desktop Engine (MSDE) (против которых он направлен), обычно запускаются с использованием локальных привилегий. «Завладев этими привилегиями, атакующий может похитить или манипулировать данными в пораженной БД SQL», — говорит Литчфиелд.
Этот червь может быть более опасным. Литчфиелд утверждает: «Если создатель данного червя написал бы его так, чтобы для каждого пакета, который он рассылает, был установлен UDP-порт источника 53 (используемый DNS-серверами и обычно открытый в большинстве корпоративных сетей), тогда гораздо большее число SQL Server было бы заражено, что, несомненно, привело бы к более тяжелым последствиям».
Для получения дополнительной информации смотрите следующие ссылки:
инструменты безопасности SQL Server 2000 для сканирования экземпляров SQL Server для выявления уязвимостей;
Дэвид Ботзенхарт (David Botzenhart)
В службы поддержки довольно часто обращаются с вопросом, как подключиться к Microsoft Analysis Services через Интернет. Конфигурация очень проста и, поскольку вам известны шаги установки, давайте начнем.
Основное внимание в этой статье будет уделено следующим вопросам: окружение Analysis Services и почему необходима дополнительная конфигурация, какие требования предъявляются к системе и ПО для подключения к Analysis Services через Интернет, как данные и за-просы данных перемещаются в этой конфигурации и, наконец, настройка и конфигурирование.
Также нужно принять во внимание многие параметры и режимы безопасности. Затем мы рассмотрим изменение строки подключения (connection string) клиентского ПО, которое необходимо выполнить для подключения. И в заключение обсудим, как выявлять неисправности соединения и что для этого нужно делать.
Наибольшее количество вопросов обращающихся за помощью пользователей касается клиентской части аналитических служб (PivotTable Services, PTS), при помощи которой происходит подключение через Интернет, — она является «толстым» клиентом и должна быть физически загружена или установлена на клиентском компьютере.
Конечно, это создает дополнительные проблемы как при сопровождении, так и при загрузке PTS на каждый компьютер, но у меня есть пример программы, которая может упростить эту задачу, и об этом — чуть позже. если же сопровождение не является проблемой, то есть некоторые преимущества использования «толстого» клиента, например, наличие кэша.
Есть решение и для «тонкого» клиента (XML for Analysis, XML/A), при этом на клиент не надо ничего устанавливать. Это решение использует пакеты SOAP (Simple Object Access Protocol) для пересылки запросов MDX к Analysis Services, а Analysis Services посылает обратно набор данных в формате XML. В этой статье обсуждается только «толстый» клиент, или PTS-решение, подробнее же о XML for Analysis — на сайте Microsoft, а также по адресу http://msdn.microsoft.com/downloads/default.asp?url=/code/sample .asp? url=/msdn-files/027/001/633/msdncompositedoc.xml.
Брайан Келли (Brian Kelley)
EFS является новым механизмом шифрования файлов, полностью «прозрачным» для приложений высокого уровня, таких как SQL Server.
В статье, посвященной безопасности SQL Server, Крис Кемрстер (Chris Kempster) знакомит нас с новой функцией Windows 2000 — шифрующей файловой системой (Encrypting File System, EFS). Администраторам БД, стремящимся защитить уязвимые файлы данных SQL Server, следует обратить на EFS пристальное внимание. Если атакующий сможет скопировать незашифрованные файлы данных с сервера, он также без особых проблем сможет присоединить эти файлы к своему SQL Server. Применяя EFS, вы можете зашифровать все файлы данных так, что только SQL Server сможет получить доступ к ним, для других же они будут выглядеть полной бессмыслицей.
Копирование файлов данных с одного сервера на другой для последующего присоединения БД к новому SQL Server (при помощи хранимой процедуры sp_attach_db) фактически является еще одним методом миграции данных, наряду с такими, как резервное копирование/восстановление, использование мастера копирования БД (copy database wizard), сценарии T-SQL и bcp-файлы. И поскольку копирование и повторное присоединение выполняются очень просто, наибольшие опасения вызывает возможность использования этого механизма для похищения данных. EFS обеспечивает достаточно надежное решение этой проблемы, поскольку:
В этой статье я дам общий обзор того, как работает EFS, и того, как вы можете внедрить эту систему и как устранять проблемы, возникающие при использовании EFS применительно к SQL Server. Единственное, чего я хотел бы избежать, это углубления в по-дробности механизма работы EFS, поскольку многие специалисты уже сделали это. Вот ссылки на серию из двух статей Марка Русиновича (Mark Russinovich) (соавтора книги «Inside Microsoft Windows 2000»1), посвященную изложению основ EFS (эти статьи были опубликованы в журнале «Windows and .NET Magazine»):
Виас Кондредди (Vyas Kondreddi)
К сожалению, в языке T-SQL для SQL Server не предусмотрена работа с массивами. И хотя в SQL Server 2000 добавлено несколько новых типов данных, таких как sql_variant, bigint и т. д., столь необходимой поддержки массивов по-прежнему нет.
В некоторых случаях нам требуется возможность передавать список значений в хранимую процедуру. Представим себе web-страницу, которая предлагает пользователю выбрать один или несколько его предыдущих заказов, после чего выводит полную информацию о них. В этом случае одновременная передача списка выбранных номеров заказов хранимой процедуре и последующее получение результатов будет эффективнее по сравнению с вызовом этой же хранимой процедуры для каждого выбранного номера заказа отдельно.
Поскольку мы не можем напрямую создать массивы переменных, входных параметров и столбцов в T-SQL, нам стоит поискать обходные пути и альтернативные решения. Годами программисты разрабатывали различные методы реализации этой задачи. Некоторые решения были не очень эффективны, но просты, были и удачные, но более сложные. Наиболее популярным является метод, передающий список значений, разделенный запятыми (CSV, commaseparated value). В этом методе обычный входной параметр хранимой процедуры получает список, скажем, номеров заказов (OrderID), разделенный запятыми. В данной статье я познакомлю вас с некоторыми из этих решений. В конце я предоставлю вам ссылки на статьи и книги, посвященные реализации массивов в T-SQL.
Приведенный ниже пример намеренно упрощен, чтобы показать саму идею этого метода. Вы можете адаптировать его в соответствие со своими потребностями. Хранимые процедуры в этом примере запрашивают таблицу Orders из модели БД Northwind, поставляемой с SQL Server 7.0 и 2000.
Performance
Лев Вайцблит (Lev Vaitzblit)
Администраторы БД зачастую думают о журнале транзакций только в контексте резервного копирования и восстановления системы.
Наряду с тем, что журнал транзакций регистрирует все изменения в БД и поддерживает восстановление в случае системных или транзакционных отказов, файлы журнала содержат также избыточную информацию, которая может быть очень полезна для других целей. Администраторы БД могут использовать файлы журнала для восстановления в случае общих ошибок приложений, которые приводят к повреждению данных, распознаванию и решению проблем в логике программ, пониманию и анализу поведения приложений, а также проведению аудита пользователей и приложений обращающихся к БД.
Осваивая передовую практику работы с БД и журналами, а также используя преимущества программных приложений сторонних производителей, администраторы могут выполнять аудит деятельности БД без дополнительных издержек, выясняя трудноразрешимые проблемы приложений, быстро и выборочно восстанавливая данные в оперативном режиме и спасая их, когда традиционные техники восстановления не срабатывают.
(Возврат на основную страницу)