Служба Рассылок Городского Кота

#3

DBA И БЕЗОПАСНОСТЬ

ВНИМАНИЕ  DANGER!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
УЯЗВИМОСТЬ СЕРВЕР MS SQL SERVER 7.0 (SP1 И SP2) ПОЗВОЛЯЕТ
УЗНАТЬ ПАРОЛЬ АДМИНИСТРАТОРА (SA)
По информации Microsoft, когда СЕРВЕР SQL 7.0 (SP1 И SP2) использует
смешанный режим идентификации пользователей, пароль SA прописывается
в открытом виде в файле \%TEMP%\sqlsp.log. Заданные по умолчанию
права доступа к этому файлу позволяют любому пользователю, который может
получить доступ к этому каталогу, узнать пароль SA. Microsoft
модифицировал SP2, чтобы исключить эту уязвимость.
http://www.ntsecurity.net/go/load.asp?iD=/security/sql7-5.htm
ВНИМАНИЕ DANGER!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

В настоящее время в компьютерных кругах широко обсуждается
появившийся недавно документ:

How To Eliminate The Ten Most Critical Internet Security Threats
The Experts' Consensus
Version 1.13  June 2, 2000
Copyright, 2000, The SANS Institute

Поскольку затронутая этим документом тема весьма злободневна для
любого DBA, я счe:л своим долгом процитировать некоторые аспекты
статьи, наиболее близкие администраторам SQLS7. Более полная
информация находится на сайте SANS: http://cve.mitre.org. Нумерация
уязвимостей  соответствует оригиналу статьи.

7. Не продуманное предоставление пользователям сети доступа к
распределe:нным информационным ресурсам (file sharing) через NetBIOS
порты Windows NT 135-139 (445 в Windows2000). В результате,
доступными для несанкционированного доступа могут стать файлы,
критически важные для работы системы. Становится возможной утечка
информации или распространение вирусов аналогичных 911.
Используя null session подключения к доступным из сети ресурсам
через NetBIOS хэкер может осуществить попытку подбора пароля
методом перебора.
Советы по снижению уязвимости:
A. При совместном использовании распределe:нного ресурса убедитесь,
что они содержат только санкционированные каталоги.
B. Для усиления безопасности, разрешите доступ к распределe:нным
ресурсам ограниченному кругу IP адресов, для исключения
несанкционированного подключения под доступным для лe:гкого
определения именем DNS.
C. Учe:тные записи пользователей Windows должны использовать только
"сильные" пароли.
D. Стандартные, анонимизированные учe:тные записи Windows NT
(Administrator, guest) должны быть заблокированы или, в крайнем случае,
иметь очень "сильные" пароли. Блокируйте порт TCP 139.
NT4: http://support.microsoft.com/support/kb/articles/Q143/4/74
Win2000: http://support.microsoft.com/support/kb/articles/Q246/2/61

8. Учe:тные записи пользователей или администраторов не имеют пароля,
 используют пароль установленный по умолчанию при инсталляции или
 "слабый" пароль.
Советы по снижению уязвимости:
A. Разработайте политику обеспечения безопасности, включающую строгие
требования к периодичности смены пароля, минимальному количеству
символов пароля и его сложности. Особое внимание уделите стандартным
учe:тным записям и тем, которые получают пароли по умолчанию при
инсталляции. Установите административную ответственность пользователей
и администраторов за не исполнение политики безопасности.
B1. ОЧЕНЬ ВАЖНО!!! Получите у своего руководства санкцию на проверку
паролей пользователей.
B2. Здесь представлены ссылки на программы "раскалывания" паролей:
Для Windows NT: l0pthcrack http://www.l0pht.com
Для UNIX: http: // www.users.dircon.co.uk / ~ crypto
C. Используйте утилиты, которые контролируют время создания или смены
паролей..
Для UNIX:
http://www.utexas.edu/cc/unix/software/npasswd
Для Windows NT:
http://support.microsoft.com/support/kb/articles/Q161/9/90.asp
D. Установите периодичность и длину пароля для каждого пользователя.
E. Установите высокие требования к уникальности пароля, так, что бы
пользователи не могли повторно использовать старые пароли..
Дополнительная информация:
 http://www.cert.org/tech_tips/passwd_file_protection.html
 http://www.cert.org/incident_notes/IN-98.03.html
 http://www.cert.org/incident_notes/IN-98.01.irix.html

10. При использовании SNMP, может быть использована  уязвимость
community strings, установленной по умолчанию в public или private.
SNMP широко используется сетевыми администраторами, чтобы
контролировать и управлять сетевыми устройствами от маршрутизаторов
до принтеров и компьютеров. Для опознавания таких устройств SNMP
использует незашифрованную community strings, которая большинством
производителей определяется, как "public". Нападающие могут использовать
эту уязвимость в SNMP, чтобы реконфигурировать или перегрузить
устройства дистанционно. Хэкеры, просматривая SNMP трафик могут
узнать топологию и конфигурацию вашей сети, а также какие системные
устройства в ней присутствуют.
Советы по снижению уязвимости:
A. Если есть возможность, отключите SNMP.
B. Если Вы используете SNMP, используете ту же самую политику
безопасности для имe:н семейства как было описано для паролей.
C. Проверить корректность community names с помощью snmpwalk.
D. Где это возможно, предоставляйте для MIBS права только на чтения.
Дополнительная информация:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/snmp.htm#xtocid210315

Bonus Item для пользователей и администраторов Windows.
Уязвимости скриптов, сценариев и макросов в Internet Explorer и Office2000
Советы по снижению уязвимости:
 http://www.microsoft.com/security/bulletins/ms99-032.asp
 http://www.microsoft.com/security/bulletins/MS99-048.asp
 http://www.microsoft.com/technet/security/bulletin/MS00-034.asp
 http://www.microsoft.com/msdownload/iebuild/scriptlet/en/scriptlet.htm
 http://www.microsoft.com/msdownload/iebuild/ascontrol/en/ascontrol.htm
 http://officeupdate.microsoft.com/info/ocx.htm
Рецепты всем известны: не заглядывайте без проверки в аттачмент писем,
следите за скриптами и не запускайте макросы и т.п. В общем вначале
подумайте, а потом щe:лкайте мышкой! Сразу устанавливайте заплаты и фиксы:
http://www.officeupdate.com/2000/articles/out2ksecarticle.htm
Оперативно обновляйте ваше вирусное программное обеспечение.

СОВЕТ

Чтобы оптимизировать размещение файлов SQL сервера, выполняйте хотя
бы эти четыре правила:
1. Всегда используйте дисковые массивы RAID. Это избыточность/надe:жность,
производительность, толерантность, масштабируемость - в общем, без
комментариев (тривиально).
2. Чем большее дисков в массиве, тем выше его производительность. Чем
больше каналов на RAID-контроллере, тем лучше загружена шина. Чем
больше RAID-контроллеров, тем эффективней использование дискового
массива. Чем больше шин на материнской плате, тем больше перечисленного
выше добра можно "напихать" в сервер и поднять производительность в
целом (если процессоры справятся). А дальше пойдут уже кластеры.
Кстати, даже в без кластерной системе старайтесь использовать
RAID-контроллеры, которые умеют работать в кластере (например, не
инициализируют SCSI шину при включении питания), а вдруг пригодится в
будущем.
3. Разносите на разные дисковые массивы (не имеются ввиду логические
диски созданные на одном RAID массиве) файлы последовательного доступа
и файлы случайного доступа. Как правило, журналы транзакций представляют
собой файлы последовательного доступа, а файлы баз данных - случайного
доступа. Например, Вы можете разместить LOG-файлы на RAID 1, а базу
данных на RAID 5 или 10. Далее, если Вы не хотите смешивать ваши данные
с системными, Вы можете создавать два файла данных в двух различных
filegroups. Первая filegroup будет содержать системные объекты, а другая
будет содержать ваши объекты. Это не принесe:т заметного выигрыша в
производительности, но позволит разделить принципиально разные типы
данных. Принцип разнесения данных в filegroup-ы по типу доступа к
информации можно распространить и на таблицы. Маленькие OLTP
таблицы лучше держать в filegroup-е на отдельном от "монстров" с
OLAP-уклоном дисковом массиве. Значительное усложнение
администрирования с лихвой окупится ростом производительности
приложения.
4. Размещайте файлы последовательно доступа на разных дисковых массивах.
Часто сервер должен одновременно обращаться к нескольким таблицам и/или
индексам. Оптимальное распределение таких файлов с помощью включения их
в разные  filegroups (расположенных на разных дисковых массивах) также
 способно положительно сказаться на производительности приложения.


ГОТОВИМСЯ К ТЕСТУ ПО 1139A

ШПАРГАЛКА #1 (продолжение)

SQLS7 допускает к своим объектам только зарегистрированных (имеющих у
него учe:тную запись) пользователей. Используются два типа учe:тных записей:
один для механизма идентификации SQLS7, а другой для механизма
идентификации Windows NT. Если использовать механизм SQLS7, пользователь
вводит Login, прописанный только в SQLS7. Если используется механизм
Windows NT, то используется учe:тная запись или группа, определe:нная этой
ОС (локальные или глобальные). Определить соответствие учe:тных записей
NT и SQLS7, а также приписать их к конкретным БД должен системный
администратор (SA). Проверка подлинности пользователя SQLS7
осуществляется или только с использованием механизма NT или возможен
смешанный режим, допускающий применение обоих механизмов.
SQLS7 использует понятие РОЛЬ, для объединения пользователей в условные
группы с одинаковыми правами. Роли могут быть предопределe:нными, а также
могут создаваться пользователями, имеющими на это право. Например, права SA
(в представлении SQLS6.5) состоят из нескольких предопределe:нных ролей и
могут быть делегированы или распределены между несколькими пользователями.
РОЛИ бывают двух типов: серверные (dbcreatir, diskadmin, processadmin,
securityadmin, serveradmin, setupadmin - настройка репликаций, sysadmin);
баз данных (public, db_owner, db_accessadmin, db_ddladmin - управление
объектами БД, db_securityadmin, db_backupoperator, db_datareader,
db_datawriter, db_denydatareader - не читать, db_denydatawriter - не
писать). Каждый запрос к SQLS7 проверяется на соответствие прав пославшего
запрос пользователя набору операций запроса, и, соответственно, исполняется
или отвергается.

SQLS7 имеет системные БД (содержащие информацию, необходимую для
управления системой) и пользовательские. При инсталляции создаются 4
(а если планируется репликация - 5) системные (master - содержит объекты
SQLS7 и описания БД/пользовательских объектов - МЕТАДАННЫЕ,
model - шаблон БД, tempdb - временные таблицы и данные, msdb - содержит
информацию для SQL Server Agent, расписания, задачи и их журналы,
distribution - для поддержки репликаций) и две пробные, пользовательские
БД (pubs, northwind).
БД содержит еe: объекты (наборы данных, таблиц, индексов и т.д.) которые
могут быть следующих типов: TABLE, DATA TYPE (системные и
пользовательские), CONSTRAINT (ограничения значений, целостность, первичный
ключ PK, внешний ключ FK, проверка Check), DEFAULT - значение по
умолчанию, RULE - правила на допустимые значения и типы,
INDEX - кластерные и обычные индексы, VIEW - представление данных из
таблиц, TRIGGER - хранимая процедура, выполняемая при изменении данных в
таблице. Набор системных таблиц метаданных любой базы данных составляет
еe: КАТАЛОГ. СИСТЕМНЫЙ КАТАЛОГ хранится в БД MASTER и содержит
метаданные обо всей системе и обо всех БД. Полностью квалифицированное
имя объекта строится по правилу:
ИМЯСЕРВЕРА.ИМЯБД.ВЛАДЕЛЕЦ.ОБЪЕКТ
Указание заглавной части имени объекта может опускаться, в зависимости от
текущего контекста. При позиционировании пользователя на контекст объекта,
возможно указание только ОБЪЕКТ. При создании объекта с не полностью
квалифицированным именем, используются текущие значения контекста.
В качестве ВЛАДЕЛЕЦ пользователь может использовать доступную ему РОЛЬ.
Для ролей db_owner и db_ddladmin там можно указывать DBO. Имена
системных таблиц начинаются на SYS. Для извлечения метаданных из
системных таблиц используются системные хранимые процедуры
(не рекомендуется использовать для приложений), системные функции и т.н.
информационные схемы. Название системных хранимых процедур
начинается с SP_. Представления информационной схемы введены
стандартом ANSI SQL для обеспечения независимости от структуры
системных таблиц.

Клиент - серверные приложения для работы с SQLS7 строятся в трe:х уровнях:
презентационный (алгоритм представления данных), логический (бизнес-логика)
и уровень данных. Презентационный уровень отдаe:тся на откуп клиентскому
приложению, бизнес - логика может затрагивать как прикладную программу,
так и SQLS7, уровень данных - прерогатива SQLS7. Использование
архитектурной схемы, когда представление данных и бизнес-логика
сосредоточены в клиентской программе, а SQLS7 обслуживает только БД
является наиболее типичной для небольших организаций и именуется, как
"интеллектуальный клиент" (двухзвенка). При использовании "слабых"
компьютеров, вычислительную нагрузку можно перенести на SQLS7. Такая
схема называется   "интеллектуальный сервер" (двухзвенка). Для приложений
уровня предприятия наиболее типично использование многоярусной
архитектуры, когда между клиентами и двухзвенка встраивается серверы
приложений (трe:хзвенка). На сегодняшний день актуальна и другая
трe:хзвенная
архитектура для обслуживания клиентов из интернет. Здесь бизнес-правила и
представления обслуживаются веб-сервером, а клиенты пользуются обычным
браузером.
Разработка базы данных для клиентского применения включает этапы
проектирования БД (расчe:т производительности железа, масштабирование,
идентификация объектов, моделирование и тестирование объектов и алгоритмов,
определение типов объектов), создание БД, тестирование и настройка системы
в целом, планирование развe:ртывания, последующее администрирование.

В целом, администрирование БД SQLS7 сводится к выполнению следующих
задач: Инсталляция SQLS7, настройка прав доступа и аудита, конфигурирование
SQLS7, создание БД, загрузка данных, резервное копирование и ведение
журналов транзакций, мониторинг и регулировка параметров для обеспечения
необходимой производительности системы.

КОНЕЦ ШПАРГАЛКИ #1

Продолжение следует.