Руководство по безопасности в Lotus Notes

Укрепление (hardening) сервера

Разбить на страницы
Показывать лекцию целиком

Защита операционной системы осуществляется посредством процесса, называемого укреплением (hardening), в котором берется стандартная "боксовая" конфигурация (т. е. та, которая поставляется производителем для процесса установки со значениями параметров, выставленными по умолчанию) и закрываются все известные уязвимые места и потенциальные "дыры" безопасности файловой системы, фоновых служб и конфигурации сетевых служб.

В этой лекции мы рассмотрим "укрепление" тех операционных систем, на которых обычно Lotus-технологии и работают, а именно:

  • Windows (с ядром NT)-операционные системы:
  • Win32 – Windows NT4.0, Windows 2000 и Windows XP;
    •
  • UNIX/Linux-операционные системы:
  • Sun Solaris – версия 8;
  • Linux (ядро 2.4) – SuSe и Red Hat;
  • IBM AIX.

    • Наше обсуждение коснется рабочих станций, так же как и серверов, поскольку вопросы безопасности включают в себя все аспекты инфраструктуры, а не только ее наиболее видимых частей.

    9.1 Основные принципы "укрепления"

    В этом разделе мы объясним некоторые фундаментальные принципы "укрепления". Необходимо понимать эти основы до того, как мы сможем обсуждать реальное "укрепление" ИТ-системы организации.

    9.1.1 Начнем с операционной системы

    Если и существует наилучшее место, с которого следует начинать процесс "укрепления", так это операционная система. Это связано с тем, что ОС представляет собой ядро ИТ системы. В конце концов, именно ОС отвечает за то, чтобы пользователи были надежно аутентифицированы и контролировались. К счастью, "укрепление" ОС – не сложная задача, хотя первичные действия могут показаться утомительными. В этой лекции мы сделаем обзор общих методов и концепций, которые можно использовать для "укрепления" любой ОС.

    С того самого момента, как только планируется установка ОС, безопасности следует придавать наивысший приоритет. К сожалению, этого часто не происходит, результатом чего являются неполноценные установки, что в конечном итоге приводит к скомпромитированным системам. Следующие разделы описывают в общих чертах те шаги, которым надо следовать каждому администратору или пользователю во время установки.

    Делайте изолированную установку

    Во время установки ОС она должна быть физически отсоединена от любой сети, особенно от Интернета. Хотя результаты статистики варьируются в зависимости от того, кто предоставляет их, подсчитано, что установка ОС по умолчанию, будь то Windows или Linux, будет просканирована и взломана в течение часа после подсоединения к Интернету. К сожалению, для установки всех корректных патчейПатч – заплатка, набор исправлений и улучшений. безопасности часто требуется больше времени, чем это.

    Ирония в том, что этим самым операционным системам требуется тем или иным способом быть подключенными к Интернету для того, чтобы иметь возможность загрузить необходимые патчи безопасности. Решение этой проблемы – использовать отдельную машину для загрузки необходимых патчей и затем применять эти загруженные патчи к той машине, на которой происходит новая установка.

    Закрывайте ОС

    Существует почти 100% вероятность, что установка "по умолчанию" приведёт к тому, что такая машина, или конфигурация, будет иметь как минимум одно уязвимое место, которое может быть использовано взломщиком для получения неавторизированного доступа.

    Чтобы помешать этому, администратору следует быть готовым к установке всех подходящих патчей и обновлений. Это означает знание наперед, какие основные обновления доступны для данной ОС. Обновления часто бывают в форме пакетов обновлений (service pack) или обновленных релизов, которые доступны в пригодном для загрузки формате, что позволяет подготовить необходимые обновления на записываемом CD (компакт-диске) или ленте еще до установки.

    После того как ОС с текущими обновлениями установлена, важно поддерживать ее в состоянии, всегда соответствующем последним обновлениям и исправлениям. Службы обновления предлагаются большинством производителей ОС (такие, как утилита up2date компании Red Hat и Windows Update Tool компании Microsoft). Эти инструменты должны использоваться с осторожностью, и вам следует понимать, что именно сделает с системой конкретный патч, полученный при помощи такой утилиты, до того, как он будет установлен.

    Закрывайте службы

    Операционная система – это лишь небольшая часть ИТ-системы. Подключенные дополнительные службы могут дать дополнительную функциональность, не входящую в "боксовую" конфигурацию, но, с другой стороны, могут стать причиной некоторой головной боли в плане безопасности. Например, одна из наиболее известных таких служб для ОС Windows Server – Internet Information Server (IIS, Информационный сервер Интернета), который стал источником огромного количества хорошо известных "дыр".

    Точно также, как и саму ОС, все службы и программы сторонних производителей на компьютере следует проверять, чтобы гарантировать то, что они самой последней версии и безопасны в использовании. Как это ни странно, но далеко не все системные администраторы понимают этот принцип и предпринимают усилия для удаления нежелательных служб; более того, некоторые даже не знают, какие именно службы запущены на их системах.

    Пока мы в этой лекции разбираемся со специфическими инструментами и методиками, есть быстрый и легкий способ закрыть некоторые уязвимые места – проверить, какие коммуникационные порты "слушают" входящие данные. Это делается при помощи следующей команды в командной строке:

    netstat –an

    Кроме того, инструменты, такие, как Nessus, Nmap и Stealth, могут быстро выдать "снимок" ИТ-системы и того, какие потенциально уязвимые фоновые службы запущены в системе.

    Определите базовый уровень

    После того как ИТ-система пропатчена и закрыта, следующий важный шаг, который следует предпринять до того, как открывать ее миру, – это установить надлежащий базовый уровень для этой ИТ-системы.

    Главным образом это означает, что должна существовать полная документация тех изменений, которые были выполнены с ИТ-системой. Любые изменения, сделанные с базовым уровнем, могут быть проконтролированы, и приняты соответствующие меры безопасности. Этим также устанавливается в организации единый стандарт конфигурации ИТ-систем, и любые необходимые корректировки могут быть сделаны быстро и единообразно, избегая тем самым самого понятия "самое слабое звено". (То есть такой системы, которая значительно отличается своей базовой конфигурацией и в которой нечаянно оставлены открытыми службы и порты. Такая система может быть использована для подготовки атак на другие системы организации.)

    К тому же надлежащая безопасность полагается на соответствующую документацию. Именно по этой причине для организации должен существовать соответствующий ПСОНМ (политики, стандарты, общее направление мероприятий) (PSPG – Policies, Standards, Procedures Guideline) – документ, в котором содержатся детальные описания базовых конфигураций.

    9.1.2 Инструменты защиты и предохранения

    Инструменты защиты – один из самых главных элементов, который обеспечивает буфер безопасности между ИТ-системами и теми людьми, которые пытаются взломать их. Этот инструментарий включает в себя антивирусные сканнеры, фильтры приложений, брандмауэры и другие инструменты.

    Стоит упомянуть, что инструменты защиты только уменьшают вероятность того, что взломщики успешно получат доступ к ИТ-системе. Исходя из того, что существует множество способов проведения атак, вам не следует слишком полагаться на эти инструменты и рассматривать их, скорее, как сдерживающие средства, нежели как средства предохранения от взлома

    Брандмауэры

    Детальное описание брандмауэров, их архитектуры и того, как наилучшим образом их использовать, дано в 4.1, "Инфраструктура компонентов". В этом разделе мы рассмотрим лишь некоторые базовые концепции брандмауэров.

    Брандмауэр – это такое устройство, которое тщательно просматривает входящий сетевой трафик и, опираясь на набор правил, либо пропускает его, либо нет. Брандмауэры, как правило, стоят по периметру сети организации, защищая ее от Интернета, экстранета и других менее защищенных сегментов сети. Брандмауэр может работать на UNIX, Windows (предпочтительнее с ядром NT) или на любых других операционных системах с программным обеспечением, выполняющим пакетную фильтрацию, которые как минимум укреплены против взлома и имеют несколько сетевых карт для подключения к различным сегментам сети.

    В наши дни брандмауэры стали настолько обыденным явлением, что люди стали чрезмерно полагаться на них, и многие системные администраторы считают, что брандмауэры обеспечивают всю требуемую безопасность сети. Хуже того, некоторые системные администраторы думают, что могут достать брандмауэр из коробки, подключить его, никогда больше на него не смотреть и рассчитывать на то, что он все еще будет защищать их систему.

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

    Фильтры приложений

    Подобно брандмауэрам, фильтры приложений ограничивают поток данных согласно некоторому набору правил. В действительности некоторые устройства совмещают в себе брандмауэр и фильтр приложений. (Примером этого может быть Microsoft ISA Server, о котором подробнее можно узнать на странице http://www.microsoft.com/isaserver/.)

    Однако брандмауэр и фильтр приложений, по сути, совершенно разные вещи, поскольку функционируют на разных уровнях TCP-стека. Вместо отслеживания и управления трафиком на основе IP-адреса и порта (что делают брандмауэры) фильтр приложений контролируют данные, основываясь на используемом программном или коммуникационном протоколе или на фактических данных, передаваемых в пакет.

    Например, если организация хочет ограничить использование P2P служб (к примеру, таких пиринговых клиентов, как KaZaa, Morpheus, eDonkey и т.д.), между брандмауэром и внутренней сетью следует установить фильтр приложений. Этот сервер приложений затем может быть отконфигурирован так, чтобы блокировать все запросы к таким P2P службам. Обычному HTTP трафику было бы позволено проходить, но весь файлообмен, основанный на службах P2P, блокировался бы.

    Помимо управления службами, фильтры приложений часто используются для блокирования доступа пользователей к сомнительным или нелегальным Web-сайтам посредством либо проверки URL-адреса в базе данных запрещенных адресов, либо сканирования каждой запрошенной Web-страницы на предмет наличия определенных ключевых слов.

    Хотя фильтры приложений и важны для контроля того, какие данные входят и выходят из сети, тем не менее они ненадежны. Например, Web-сайты могут менять адреса и даже просто быть доступными по IP-адресу, тем самым обходя любые проверки URL-адресов. Кроме того, сайт, не содержащий ни единого слова (только рисунки), мог бы легко обойти проверку и пройти к запросившему пользователю, внезависимости от того, какие рисунки в нем содержатся.

    Системные политики и обучение

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

    К примеру, открытая беспроводная сеть могла бы позволить хакеру полностью обойти все другие защитные устройства и получить свободную власть во внутренней сети.

    Вот почему системные политики и обучение являются ключевыми предохранительными инструментами.

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

    К сожалению, как правило, настолько широко распространено и совершенно лишено смысла то, что у пользователей иногда складывается такое впечатление, будто до тех пор, пока они не раскрывают свой пароль, любая игра будет честной, включая пользование P2P-клиентом и употребление пропускных мощностей организации для обмена музыкальными (или другими) файлами с сотрудниками и, если нет должного уровня безопасности, с внешними людьми.

    Независимо от того как хорошо и всеобъемлюще написана политика безопасности, она бесполезна, если конечный пользователь не читает и не понимает ее. Обязательно прочитайте лекцию 2, "Методики построения систем безопасности", особенно те разделы, в которых говорится о политиках безопасности, о компетентности и обучении пользователей, о проверке на соответствие.

    Сканеры портов

    Сканер безопасности NMap (сокращение от Network Mapper) – замечательный инструмент для укрепления, доступный по следующему URL-адресу:

    http://www.insecure.org/nmap

    NMap – это продукт open sourceOpen source – проект с открытыми исходными программными кодами., доступный для многих почитателей как UNIX, так и Windows (NmapNT). Он позволяет системным администраторам использовать "сырые" IP-пакеты для определения (помимо всего прочего) следующего:

  • какие узлы наличествуют в заданной сети;
  • какие службы (порты) открыты;
  • какая работает операционная система и какой версии;
  • какие используются типы пакетных фильтров и брандмауэры.
    •

    NMap также имеет возможность создавать и отправлять узлу сети фрагментированные пакеты. Используя опцию –f (фрагментирование), можно заставить NMap выполнить сканирование фрагментированными IP-пакетами. В режиме фрагментирования NMap расщепляет TCP-заголовок на несколько пакетов, чтобы усложнить обнаружение сканирования пакетными фильтрами и системами обнаружения вторжения (Intrusion Detection Systems, IDS).

    Хотя этот метод и не сможет одурачить брандмауэры, которые поддерживают целостность пакетов, многие сети не способны справиться с перегрузками при отслеживании фрагментов и, таким образом, не поддерживают этого.

    В конце концов такие инструменты, как Nessus, используют NMap в своем ядре, что делает NMap еще более популярным.

    9.1.3 Резюме по основам укрепления

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

    9.2 Безопасность операционной системы

    Операционная система определяет все то, что может быть сделано с ИТ-системой, и то, каким образом это будет делаться. То ли происходит взаимодействие с файловой системой, то ли отправка электронной почты посредством Lotus Notes, то ли разговор с кем-нибудь через Sametime – за всем этим стоит "закулисная" работа операционной системы по обеспечению пользователя соответствующей технической поддержкой для интерпретации его запросов в нечто такое, с чем ИТ-система способна работать.

    И хотя операционные системы различаются на многих уровнях, наиболее общие из них определяют нечто намного большее, чем простой интерфейс между пользователем и машиной. В них входят программы, дающие пользователю многочисленные дополнительные возможности: от простых скринсейверовСкринсейвер – программа-хранитель экрана. до сложным схем файлового шифрования. Но при этом важно понимать, что все эти программы – именно дополнения, добавленные в ОС и не являющиеся необходимыми для функционирования компьютера.

    Многие пользователи тесно знакомятся с аксессуарами операционной системы (такими, как игры, идущими в комплекте с ОС), но совершенно забывают о тех средствах безопасности, которые входят в поставку, чтобы помочь им поддерживать свою операционную среду надежной и безопасной. В результате многие ИТ-системы так и находятся в небезопасном состоянии, что оставляет их подверженными опасности заражения вирусом или даже полной компрометации взломщиком.

    Данный раздел посвящен вопросам безопасности операционной системы. Его цель – рассказать о таких специальных программах настолько подробно, чтобы процесс их укрепления был легок как для понимания, так и для выполнения. Это важно, поскольку достаточно всего лишь одного вируса или программы-"трояна", чтобы запустить цепную реакцию заражения компьютеров и компрометации ИТ-систем.

    9.2.1 Обзор операционной системы

    Прежде чем углубляться в то, что называется безопасностью в операционной системе, необходимо знать, где же собственно ОС начинается и где заканчивается. Наш краткий обзор описывает функциональность и предназначение операционной системы, а также то, как она используется для создания компьютерного опыта.

    Функции операционной системы

    Кратко говоря, операционная система должна обеспечить выполнение двух основных функций. ОС должна:

  • управлять ресурсами, доступными компьютерной системе;
  • обеспечить приложениям надежный, стабильный, безопасный и совместимый интерфейс для доступа к ресурсам компьютера.
    •

    Первая функция имеет особенно критических характер, поскольку именно она определяет то, каким образом приложения получают доступ к системным ресурсам. Посредством контроля различных аспектов использования аппаратуры и программного обеспечения ОС гарантирует, что каждое приложение получит возможность использовать процессор.

    Вторая функция определяет методы, посредством которых приложение может получить доступ к этим ресурсам. Поскольку ОС зачастую выступает в качестве буфера между выполняющейся программой и аппаратурой, нужны какие-то средства, позволяющие приложениям получать доступ к ресурсам без необходимости знать всю топологию компьютерной системы.

    Виды операционных систем

    Есть четыре основных вида операционных систем, классифицируемых согласно типам программ, которые они поддерживают, и способу взаимодействия этих программ с пользователями:

  • Операционная система реального времени. Наиболее часто такая операционная система встречается в производстве роботов и в научных приборах (хороший пример – QNX). В ней нет много места для пользовательских операций за исключением отдельных изменений в конфигурации. Обычно в такой операционной системе находятся идеально отточенные механизмы работы со временем, поскольку даже самая незначительная ошибка может иметь значительные последствия в автоматическом производстве или измерениях.
  • Однопользовательская однозадачная операционная система. Этот вид операционных систем используется такими устройствами, как PDAPDA – Personal Digital Assistant, личный цифровой секретарь, тип сверхлегкого миниатюрного персонального компьютера с жидкокристаллическим экраном, клавиатурой и/или рукописным вводом. или другие миникомпьютеры (хороший пример – Palm OS). По большей части она позволяет одному пользователю работать с одной программой за один раз. Если требуется запустить еще одну программу, пользователь сначала должен закрыть текущее приложение.
  • Однопользовательская многозадачная операционная система. Этот вид операционных систем известен больше всего, так как к нему относятся и системы Microsoft Windows. В такой операционной системе пользователь может открыть множество программ и переключаться между приложениями так, как ему требуется. Фактически сейчас ведется много дебатов по поводу того, что, хотя Windows Server Operating Systems и выглядят как многопользовательские системы, тем не менее они есть не что иное, как однопользовательские многозадачные операционные системы (за исключением Terminal Services).
  • Многопользовательская операционная система. Истинная многопользовательская операционная система позволяет многим пользователям одновременно получать доступ к компьютерным ресурсам. Общеизвестный пример ОС такого типа – Linux. В системе такого типа ОС обрабатывает запросы от многих пользователей и поддерживает жесткий контроль над ресурсами, чтобы гарантировать то, что ни один пользователь никаким образом не повлияет на какого-либо другого пользователя.
    •

    Задачи операционной системы

    Операционная система отвечает за широкий спектр задач внутри компьютерного окружения. Именно эти задачи часто являются тем, что делает одну операционную систему надежнее и легче в использовании по сравнению с другой. То, как ОС управляется с этими задачами, определяет реальные возможности операционной системы.

  • Управление процессором. Операционная система должна обеспечить эффективное использование процессора при выполнении реальной работы и то, чтобы каждое приложение получило свою часть процессорного времени.
  • Управление памятью. Это определяет те методы, посредством которых операционная система выделяет приложениям и функциям самой операционной системы память.
  • Управление устройствами. Поскольку операционная система состоит из разнообразных аппаратных компонентов (жесткий диск, монитор, мышь, клавиатура и т. д.), она должны быть способна управлять тем, как все эти компоненты взаимодействуют друг с другом.
  • Управление хранением информации. Операционная система не только осуществляет контроль за активными ресурсами, но и определяет, каким образом хранятся файлы и данные, при этом обеспечивая их сохранность.
  • Прикладной интерфейс. Операционная система действительно является мостом между приложениями и компьютерными ресурсами, что означает, что она должна для связи с приложениями предоставить интерфейсы прикладного программирования (APIs, Application Programming Interfaces).
  • Пользовательский интерфейс. Будь то посредством командной строки или графического пользовательского интерфейса (Graphical User Interface, GUI), именно операционная система отвечает за взаимодействие с конечным пользователем.
    •

    Это было очень краткое резюме тех основных задач, с которыми следует управляться операционной системе.

    Следующие разделы описывают вопросы безопасности, с которыми должна иметь дело операционная система для поддержания конфиденциальности, целостности и доступности системных ресурсов. Мы пройдемся по двум наиболее известным семействам операционных систем и по присущим им особенностям реализации систем безопасности. Еще мы опишем наиболее часто встречающиеся методы взлома или обхода этих систем, а также то, каким образом можно защитить себя от подобных видов атак.

    С этого момента мы будем ссылаться на две ключевые книги по безопасности, которые в своей библиотеке следует иметь каждому администратору систем Windows или UNIX, а именно:

  • Максимальная безопасность для Windows 2000 (Maximum Windows 2000 Security, Sams, 2001, ISBN 0672319659);
  • Максимальная безопасность для Linux (Maximum Linux Security, Sams, 1999, ISBN 0672316706).
    •

    В этих книгах находится настоящее богатство полезных мыслей по поводу слабых и сильных мест в системах безопасности Windows и Linux.

    9.2.2 Слабые места операционной системы Windows

    Уже достаточно долгое время Microsoft Windows имеет репутацию системы с неадекватным уровнем безопасности, но многие эксперты в сфере безопасности полагают, что в действительности Windows отнюдь не слаба. Всю вину они возлагают непосредственно на плечи системных администраторов, которые отвечают за эти системы. Другими словами, при должном сопровождении и настройке вполне возможно сделать операционную систему Windows относительно безопасной.

    Тем не менее есть несколько областей, в которых, как известно, Windows действительно уязвима, например в следующих:

  • Размер/сложность. Microsoft запустил свою руку едва ли не в каждую дверь программного обеспечения (и даже в некоторые аппаратные двери). Хотя это и хорошо для общей интеграции, но для среднего системного администратора становится очень сложно держать себя на должном уровне в плане понимания:

    1) Где это начинается и где заканчивается; и 2) Как надлежащим образом все это использовать и настраивать.

  • Небезопасная установка. Одна из наиболее общих причин того, что сервера Windows становятся жертвами взломщиков, состоит в том, что их установили и забыли. К несчастью, Windows печально известна своей практически нулевой безопасностью при установке по умолчанию. Сюда входят и скрытые общие ресурсы, и пустые пароли, и отсутствие защиты от известных уязвимостей. Короче говоря, установки по умолчанию – это открытое приглашение для взломщиков и вообще для каждого, кому только не вздумается, даже для низкоквалифицированных "парнишек-скриптовиков".
  • Плохой аудит. Всякий раз, когда люди думают о возможностях журналирования на сервере Windows, первое, что обычно приходит в голову, – это обозреватель событий (Event Viewer). Хотя эта встроенная часть Windows действительно дает некоторую полезную информацию, тем не менее сам по себе обозреватель событий уже давно рассматривается как менее чем адекватный инструмент журналирования со своими зашифрованными записями и пропадающей информацией.
  • Ориентация системы на добавление новой функциональности. Windows всегда стремилась предоставить пользователям операционную систему, богатую своими возможностями, простую и легкую в использовании. При этом ранние версии вообще не особо утруждали себя вопросами безопасности. И так же, как и другие компании, разрабатывающие ПО, Microsoft всегда выискивала пути для добавления в свои продукты каких-то новых возможностей, новой функциональности для стимулирования своих клиентов к покупке новых версий. Кроме того, коммерческая природа компании требует обратной совместимости со старыми, менее защищенными версиями. А с добавлением каждой новой функциональной возможности, каждой новой услуги возникает целый набор новых проблем в плане безопасности.
  • Необученные пользователи. Windows – операционная система для масс. Многие пользователи не знают либо просто не волнуются по поводу опасностей, связанных с неадекватной конфигурацией системы. Помимо этой достаточно обширной группы, многие бизнесмены назначают на должности системных администраторов по совместительству людей из числа своих собственных служащих только на основании того факта, что те много знают о компьютерах. К несчастью, такая стратегия часто приводит к катастрофам при первом же простукивании хакером дверей в поисках легкой цели.
    •

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

    Невозможно, да это и не является целью настоящей лекции, подробно описать все уязвимые места Windows. Напротив, читателю предлагается обратиться к следующим сайтам за текущими обновлениями в этой области:

  • отслеживание ошибок от SecurityFocus:

    http://www.securityfocus.com/

  • отслеживание ошибок в NT:

    http://www.ntbugtraq.com/

  • консультации CERT:

    http://www.cert.org/nav/index_red.html

    •

    При помощи информации, содержащейся на этих сайтах, можно оперативно идентифицировать слабые и уязвимые места и применить соответствующие патчи. Справедливости ради надо сказать, что Windows не единственная операционная система со слабыми местами. В Linux также имеются некоторые "дырки", которые мы рассмотрим дальше.

    9.2.3 Слабые места Linux

    Многими Linux рассматривается как операционная система для компьютерных "фанатиков". Хотя когда-то подобное и было справедливо, сейчас операционные системы Linux для всех практических целей эволюционировали до той точки, когда они стали привлекательны и для обычного пользователя. От самых базовых машин Lindows и до выхода файлового сервера Red Hat-система, Linux делает значительные шаги в продвижении на основной рынок, приобретая также безусловную поддержку IBM. К сожалению, это означает, что растет также и число неопытных пользователей Linux.

    Одно из самых распространенных утверждений относительно Linux – она более безопасна, чем Windows. К сожалению, такое утверждение само по себе не совсем корректно и заставило не одного ИТ-работника поверить в то, что ИТ-инфраструктура будет безопаснее, исходя только из самого того факта, что они используют Linux. Хотя это и действительно может быть правдой, что Linux может быть сделана более безопасной, чем другие операционные системы, в руках пользователей ей присущи многие из тех же самых проблем, что и для других ОС. Основные вопросы безопасности для Linux следующие:

  • Учетная запись root. Одно из главнейших правил, которое регулярно игнорируется, – "не следует использовать учетную запись root без действительно абсолютной необходимости". Причина этого правила находится в той безграничной власти, которую предоставляет доступ под учетной записью root всякому, кто использует ее. Как и учетная запись Administrator в Windows NT®, root является учетной записью для интерактивного входа самого высокого уровня, какой только может существовать в Linux. Опасность кроется в том, что большинство вредоносных программ запускается с разрешениями того пользователя, который активировал данную программу. Другими словами, если для хождения по Интернету используется учетная запись root и если на Web-странице нечаянно запущен скрипт, этот скрипт будет иметь права доступа root и следовательно, сможет получить доступ к любому файлу и даже удалить целую файловую систему. Хуже того, некоторые дистрибутивы (такие, как Lindows) требуют использования учетной записи root при установке и работе.
  • Сложность. Несомненно, что самое пугающее в Linux – это весь тот сложный набор команд, концепций и программ, который должен быть освоен для соответствующей реализации мер безопасности. Действительно, это легко можно увидеть всякий раз, когда начинающий системный администратор в первый раз пытается установить Linux. И хотя некоторые дистрибутивы (версии) Linux уже начали ориентироваться на предпочтения человека, устанавливающего их, тем не менее многие операционные системы Linux до сих пор либо требуют в программе-установщике выбирать из списка неким загадочным образом именованные программы, содержащиеся обычно в пакете и устанавливаемые вместе с rpm, либо просто устанавливают всю операционную систему целиком. К сожалению, подобный список в несколько сотен программ часто действует угнетающе. В результате человек завершает установку всей операционной системы, включая HTTP-демон, FTP-демон, почтовые демоны и т.д., установка которых не является безопасной по умолчанию.
  • Сетевая ОС. Вот что утверждает максимальная безопасность для Linux (Maximum Linux Security): "Хотя Linux действительно хорошо приспособлена для персонального использования (даже в несетевых окружениях), по сути она все равно остается сетевой операционной системой. Ее установки по умолчанию запускают многие интернетовские службы, и, если не предпринимать должных мер предосторожности, взломщики могут удаленно начать на эти службы атаку во время вашей онлайн-сессии". Этим все сказано.
  • Обновления по принципу открытого исходного кода (open source). Большое количество программного обеспечения под Linux пишется студентами, исследовательскими группами или теми разрабатывающими ПО компаниями, которые пытаются найти способ сделать программное обеспечение под Linux выгодным. В сочетании с тем фактом, что Linux – открытая система, это означает, что все ПО также является открытым для изучения всему миру, и, следовательно, отсюда вытекает огромная потенциальная "головная боль" для безопасности всей системы. Но на самом деле проблема не в том, что открытое ПО является менее безопасным, нежели коммерческое. Действительно, известно, что распространители Linux выкладывают обновления и патчи в течение нескольких часов с момента обнаружения уязвимых мест в системе безопасности их продуктов. Нет, проблема в том, что информация об этих обновлениях просто не доходит до системных администраторов. Например, Red Hat выпускает ни много ни мало пять бюллетеней безопасности в день, которые системным администраторам надо просматривать, чтобы видеть, нужно ли их применять. Хотя большинство этих сигналов тревоги могут к делу и не относиться, тем не менее достаточно пропустить всего лишь одно предупреждение, чтобы оставить свою систему открытой для атак.
    •

    Системным администраторам Linux-систем следует регулярно заходить на Web-сайты используемых ими дистрибутивов (например, Caldera, Red Hat, SUSE, Turbolinux) за консультациями по уязвимым местам и соответствующими патчами, а также в раздел UNIX сайта SecurityFocus (http://www.securityfocus.com/unix), тоже за консультациями по вопросам безопасности, за инструментами и техниками для борьбы с уязвимостями.

    В итоговом разделе мы попытались представить ясный и сбалансированный обзор потенциальных вопросов безопасности в Linux и Windows. Это сделано для того, чтобы показать, что в обоих семействах операционных систем есть слабые места и что сознательному в плане безопасности системному администратору не следует расслабляться в чувстве комфорта от того, что он использует одну систему в противовес другой.

    В следующих разделах мы рассмотрим специфику укрепления Windows и Linux, а заодно Solaris и AIX, так как все это такие операционные системы, на которых работает и поддерживается Domino.

    Domino также работает и на таких ОС, как zOS (OS/390®) и OS/400® (которые предназначены для мейнфреймов zSeries™ и мини-компьютеров iSeries). Но поскольку для администрирования этих систем требуются очень специализированные знания, в пределах этого курса они рассматриваться не будут.

    9.3 Укрепление систем Windows (на ядре NT)

    В этом разделе мы рассмотрим процесс укрепления систем Windows (на базе Win32). Это те системы, которые включены в линейку NT-продуктов Windows, а именно:

  • Windows NT 4.0,
  • Windows 2000 Server,
  • Windows XP Professional.
    •

    Сюда мы включили и Windows XP Professional, так как Windows применяется большинством пользователей в качестве настольной системы (Linux в этой области медленно догоняет ее и все более и более привлекает к себе внимание), и, таким образом, как нам кажется, руководство по укреплению рабочих станций было бы хорошей идеей.

    Хотя укрепление сервера Windows является несколько утомительным процессом, реализовать его относительно легко, и для него, как правило, не требуются от организации какие-либо расходы на дополнительное программное или аппаратное обеспечение. Как упоминалось ранее в этой лекции, процесс достаточно прямолинеен: 1) укрепить базу операционной системы и 2) предпринять аналогичные меры к любым службам, которые планируется запускать на данной ИТ-системе. В конечном итоге это не поможет укрепить базу операционной системы и оставит зияющие "дыры" в Web-сервере и сервере баз данных. Стоит еще раз повторить, что с каждым установленным в операционную систему продуктом возрастает вероятность, что взломщики получат доступ к ИТ-системе.

    9.3.1 Укрепление Windows NT 4.0

    За долгие годы Windows NT 4.0 стала для Microsoft основной рабочей лошадкой. И хотя в настоящее время доступны более богатые своими возможностями замены ей, тем не менее до сих пор есть достаточно много причин, почему может быть развернута именно Windows NT 4.0. Тот факт, что большинство клиентов уже создали под нее стабильную и надежную основу, является, пожалуй, наиболее общераспространенным. Поэтому схема укрепления старого флагманского продукта будет рассмотрена в первую очередь. Многое из того, что будет здесь рассмотрено, применимо и к более новым версиям Windows, поэтому прочтение данного раздела очень рекомендуется.

    Основные рекомендации по установке

    При установке Windows NT 4.0 Server лучше всего следовать приведенным здесь рекомендациям настолько точно, насколько только возможно. Отдельные отклонения от нижеизложенного могут привести к тому, что будет удалена необходимая функциональность, требующаяся для приложения. Если подобное произойдет, мы встанем перед трудным выбором. В частности, если данная функциональность должна быть сохранена, от системных администраторов потребуется намного больше работы для защиты сервера, возможно даже придется использовать некоторые дополнительные инструменты и техники, упоминавшиеся ранее в этой лекции.

    Что следует делать при установке

    Начнем для начала с того, что следует делать, и отложим обсуждение того, чего делать не следует, на некоторое время. Этим будет гарантировано то, что смогут быть выработаны некие наиболее подходящие практические методы, а также то, что все необходимое для них будет установлено. Лучше всего начать с должным образом настроенной базы, чем потом встать перед необходимостью корректировки неправильной установки.

    Итак, при установке Windows NT 4.0 в целях безопасности вам следует сделать следующее:

  • Ставьте файловую систему NTFS, а не FAT. NTFS дает дополнительное управление безопасностью посредством списков контроля доступа (access control lists, ACLs) и является более "крепкой" файловой системой.

    Замечание. Некоторые системные администраторы предпочитают устанавливать файловую систему FAT, а уже затем, после установки, преобразовывать ее в файловую систему NTFS. Подобный способ действий не рекомендуется, поскольку в этом случае ACLs по умолчанию применены не будут.

  • Устанавливайте как отдельный сервер, а не как контроллер домена (если, конечно, нет действительно важных причин так делать). То есть нет никакой мыслимой необходимости включать брандмауэр, DMZ Web, Domino или DNS сервер в домен.
  • Устанавливайте самые последние пакет обновлений (Service Pack) и исправления, относящиеся к данной платформе и типу установки. Наиболее часто рекомендуемым пакетом обновлений для рассматриваемой платформы является Service Pack 6a, а также несколько дополнительных исправлений.
  • Убирайте ненужные службы, устанавливаемые автоматически во время процесса установки. К таким службам относятся следующие:
  • Remote Procedure Call (RPC),
  • NetBIOS,
  • Computer Browser.
    •

    Удаление этих служб может сильно повлиять на функциональность сервера. Для планируемой конфигурации следует проверить требования программного обеспечения или, что еще лучше, провести пробную установку и протестировать конфигурацию до ее фактического размещения в реальном рабочем окружении.

    Указанные службы могут быть удалены последовательным выбором: Панель управления -> Сеть -> Службы (Control Panel -> Network -> Services):

  • Workstation. Может повлиять на некоторые службы, такие, как at. Хотя она и не столь важна, как служба Server, тем не менее обращаться с нею следует осторожно.
  • Server. Может повлиять на отдельные части производительности сервера. С этой службой следует обращаться с величайшей осторожностью и удалять ее только в том случае, если не было замечено снижения производительности.
    •
  • Отвяжите WINS от TCP/IP. Выберите Панель управления -> Сеть -> Привязки (Control Panel -> Network -> Bindings). Из выпадающего меню выберите "Все протоколы" (All Protocols). Кликните на WINS Client (TCP/IP) и затем на "запретить/удалить" (Disable/Remove).
  • Используйте несуществующую рабочую группу. Нет никаких оснований вовлекать брандмауэр или DMZ-сервер в работу домена или рабочей группы.
  • Убедитесь, что следующие службы запрещены:
  • Alerter. Это служба оповещения, доставляющая пользователям сообщения о некоторых административных событиях.
  • ClipBook. Эта служба позволяет видеть содержимое буфера обмена в удаленном буфере обмена.
  • DHCP Client. Эта служба позволяет конфигурировать сетевые настройки удаленными средствами.
  • Messenger. Эта служба отправляет и принимает сообщения, посланные администратором или службой оповещения.
  • NetBIOS Interface. Эта служба подключает NetBIOS через TCP/IP.
  • Net Logon. Эта служба отвечает за прямой вход (рабочая станция) или за вход через аутентификацию и синхронизацию базы данных безопасности домена (сервер) на другие машины в домене.
  • Network DDE. Эта служба отвечает за обмен динамическими данными с удаленными машинами в сетевом окружении.
  • Network DDE DSDM. Эта служба управляет общими сетевыми ресурсами обмена динамическими данными (Dynamic Data Exchange, DDE) посредством общей базы данных DDE-соединений.
  • TCP/IP NetBIOS Helper. Эта служба представляет собой NetBIOS посредством TCP/IP, в которой осуществляется отображение имя IP-адрес.
    •

    Хотя это и удобно для удаленного администрирования сервера, лучше всего не добавлять дополнительные службы, включая службы удаленного управления, такие, как telnetd и FTP. Ни одна из них не осуществляет шифрования, таким образом учетные записи, пароли и другая информация запросто могут быть собраны прямо по сети. Если все же эти службы должны быть разрешены, системным администраторам следует принять иные меры предосторожности, такие, как доступ только через брандмауэр из внутренней сети и применение фильтров IP-безопасности к тем серверам, на которых эти службы работают.

  • Включите фильтры IP-безопасности на серверах DMZ. У брандмауэров имеется своя собственная IP-фильтрация, и им не нужны или не требуются родные IP-фильтры Windows NT. Выберите Панель управления -> Сеть -> Протоколы -> Протокол TCP/IP -> Свойства -> Дополнительно (Control Panel -> Network -> Protocols -> TCP/IP Protocols -> Properties -> Advanced). Отметьте "Разрешить безопасность" (Enable Security) и затем выберите "Настроить" (Configure). Добавьте те порты, входящий трафик из которых должен приниматься.
  • Уберите у пользователей права, которые разрешают им доступ к серверу по сети; доступ только через консоль.
  • Определите индивидуальные административные учетные записи, если есть необходимость во множественных административных учетных записях. Они помогут процессу аудита.
  • Переименуйте учетную запись "Администратор" (Administrator) во что-нибудь другое.
  • Создайте фиктивную учетную запись "Администратор без привилегий". Если взломщики попытаются скомпрометировать данную учетную запись, это будет зафиксировано в журналах аудита.
  • Сократите число групп, имеющих доступ к серверу, до того минимума, который необходим для работы и администрирования сервера. Возможно, следует свести все только к группам "Администраторы" и "Опытные пользователи".
  • Разрешите большее количество системных политик безопасности. Для изменения "Учетных записей", "Пользовательских прав" и системных политик "Аудита" следует использовать "Диспетчер пользователей", а именно:
  • Политики учетных записей контролируют пользовательские пароли и настройки блокировки. Срок действия паролей следует ограничивать согласно временным рамкам, установленным корпоративной политикой. Минимальную длину пароля следует установить по меньшей мере в восемь символов, в то время как 24 последних пароля следует запоминать. Блокировку учетной записи следует производить после трех неуспешных попыток регистрации. Счетчик попыток может быть сброшен спустя 30 минут.
  • Изо всех "Прав пользователей" следует удалить группу "Все" (Everyone). Удалите все группы и всех пользователей из "Доступа к этому компьютеру по сети" (Access This Computer From the Network), а также ограничьте число пользователей и групп, которые могут регистрироваться локально. Обратите особое внимание на "Управление аудитом" и "Журнал безопасности".
  • Включите отслеживание успешности и неуспешности по крайней мере для следующих событий: "Регистрация и выход"; "Изменение политики безопасности"; "Перезагрузка", "Выключение и система".
  • Включите черный скринсейвер с низким периодом неактивности (порядка 5 минут). Разрешите в нем защиту паролем.
  • Запустите утилиту SYSKEY для улучшения безопасности базы данных "Менеджера безопасности учетных записей" (Security Accounts Manager, SAM). Утилита SYSKEY стала доступной с выходом пакета обновлений 3; следовательно, после применения пакета обновлений 6a или более нового SYSKEY должна быть в наличии.
  • Удалите подсистемы OS/2® и POSIX. Это можно сделать запуском утилиты C2SECURITY из "Набора ресурсов Windows NT" (Resource Kit) или непосредственным редактированием следующих ключей регистра.

    Удалите данный ключ, а вместе с ним удалятся все нижележащие ключи, относящиеся к подсистеме OS/2 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OS/2 Subsystem for N.

    Уберите значение Os2LibPath из ключа Environment:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\EnvironmentOs2LibPath.

    Уберите ключи Optional, POSIX и OS/2 из ключа "Подсистемы менеджера сессии":

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\SubSystems.

    После этих изменений в регистре необходимо вручную удалить директорию %WINNT%\system32\os2 вместе со всеми вложенными папками.

    • Это был действительно длинный список того, что фактически должно быть сделано, но на котором многие системные администраторы почему-то спотыкаются, поскольку не осознают всего того, что им следует делать при установке операционной системы.

    Что не следует делать при установке

    Теперь перейдем к тому, чего не следует делать. Это еще один немаленький список, хотя и не совсем такой длинный, как список того, что следует делать.

  • Не устанавливайте никакого дополнительного ПО, если оно действительно не нужно. По умолчанию установка Windows NT включает в себя множество разных инструментов для повышения удобства использования ОС, аксессуаров, приложений и схем мультимедиа, приложения для коммуникации. Чем больше программного обеспечения установлено, тем выше вероятность быть взломанным. В безопасности лучше всего следовать пути Дао: простота начиная с самой установки.
  • Не устанавливайте информационный сервер Интернета (Internet Information Server, IIS) v2.0, который входит в поставку Windows NT, даже если данная машина планируется как Web-сервер. Процесс обновления ранних версий IIS не удаляет старых неиспользуемых файлов, через которые тем не менее можно взломать уже новую установку IIS. До тех пор пока процессом обновления не удаляются старые файлы, зачастую лучше будет вообще деинсталлировать IIS и затем инсталлировать новую версию, а не обновлять заменой поверх.
  • Не устанавливайте никаких других сетевых протоколов, кроме TCP/IP. Дополнительные протоколы порождают дополнительные проблемы. NetBEUI не используется вне рабочей группы, а IPX часто не обрабатывается должным образом брандмауэрами. Одна из наиболее больших и распространенных проблем безопасности – позволить IPX работать через NetBEUI. Это может позволить взломщикам обойти брандмауэр организации и получить доступ к настольным машинам.
  • Не добавляйте дополнительных служб, если машина не назначается в качестве DNS-сервера. Web-серверам, почтовым серверам и брандмауэрам обычно не требуется запуск DNS. Единственная служба, которую вы, вероятно, захотите добавить, – простой протокол управления сетью (Simple Network Management Protocol, SNMP) для удаленного наблюдения за брандмауэром и службами DMZ. Удостоверьтесь, что ее порты блокированы для доступа извне и что "имена сообществ" (community) для чтения-записи изменены с их значений по умолчанию. SNMP может легко выдавать информации больше, чем следует, если эта служба доступна из Интернета.
  • Не устанавливайте WINS. Если требуется разрешение имен NetBIOS без участия DNS, лучше использовать файл LMHOSTS.
  • Не делайте DHCP-ретрансляцию (relay). В общем, для DMZ-серверов вообще не нужно никаких ретрансляций (кроме, конечно, случаев, перечисленных в лекции о прокси).
  • Не разрешайте IP-переадресацию (IP Forwarding), если только данный сервер не будет брандмауэром. Брандмауэр никогда не сможет использовать весь свой потенциал, если не будет перенаправлять IP-трафик. Тем не менее обратитесь к лекции о разборе инфраструктуры за практическими советами относительно брандмауэров.
  • Не устанавливайте обозреватели Интернета (Internet Explorer) 5 или 5.5: в них намного больше дополнительной функциональности, нежели может понадобиться среднестатистическому серверу. Стоит вспомнить, что любая дополнительная функциональность может быть взломана самыми неочевидными способами. Обозреватели Интернета 5 и 5.5 – это не одиночные программы, а целые коллекции предназначенных для многократного использования компонентов. А это, в свою очередь, означает, что любая программа, работающая под Windows NT 4.0, может воспользоваться этой функциональностью. Как правило, лучше не давать взломщикам дополнительных средств для атаки на сервер. Если для брандмауэра Windows NT 4.0 или для DMZ-сервера требуется обновление обозревателя Интернета, лучше установить обозреватель Интернета 4.01 с пакетом обновления 2 (Internet Explorer 4.01 Service Pack 2).
    •

    Замечание. Internet Explorer 4.01 SP1® идет в поставке Windows NT на компакт-диске с опциональными компонентами (Option Pack CD), а Internet Explorer 4.01 SP2® доступен для скачивания по сети.

    Рекомендации по модификации реестра

    Есть несколько функций и особенностей Windows NT, которыми можно управлять исключительно через настройки реестра. При правке реестра следует быть особо осторожным, поскольку это быстро и легко может покалечить всю систему. Нижеследующие изменения реестра однозначно сделают Windows NT более безопасной.

  • Установите значение данного ключа в 1, чтобы из стартового диалога регистрации пользователя в системе убрать имя пользователя, последним прошедшего регистрацию:
    HKEY_LOCAL_MACHINE\SOFTWARE
\Microsoft\Windows NT\CurrentVersion\Winlogin
DontDisplayLastUserName
  • Установите значение данного ключа в 1, чтобы ограничить анонимным соединениям запрос списка имен учетных записей:
    HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Control\Lsa
RestrictAnonymous
  • Создайте следующий ключ для ограничения доступа к реестру по сети, чтобы изменения реестра могли осуществляться только из локальной системы. (Для работы этой записи реестра должен быть установлен пакет обновлений 3 или выше.):
    HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Control\SecurePipeServers\winreg
  • Установите следующий ключ в 1, чтобы запретить на разделах с NTFS создание в целях совместимости имен формата 8.3. (Формат имен 8.3 обычно используется только приложениями Win16, так что о нем не стоит беспокоиться. Кроме того, это даст некоторый прирост производительности за счет уменьшения расходов на генерацию и запись имен формата 8.3.):
    HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Control\FileSystem
NtfsDisable8dot3NameCreation
  • Установите данный ключ в 0, чтобы запретить автоматическое предоставление для открытого доступа административных разделяемых ресурсов ( ADMIN$, C$ и т. д.). (Убедитесь, что вы собственноручно удалили эти ресурсы из списка разделяемых (для общего доступа) запуском команды net share /d.):
    HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Services\LanmanServer\Parameters
AutoShareServer
  • Установите в 1 относящиеся к данному журналу ключи "Приложения", "Безопасности" и "Системы" для предотвращения просмотра журналов событий из сессий "Гостя" и из нулевых сессий (сессии без имени пользователя и аутентификации паролем):
    HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Services\Eventlog\Application
\CurrentControlSet\Services\Eventlog\Security
\CurrentControlSet\Services\Eventlog\System
RestrictGuestAccess
  • Установите данный ключ в 0 для предотвращения кеширования пользовательских мандатов (обычно системой Windows NT мандаты последних 10 пользователей, интерактивно входивших в систему, локально кешируются):
    HKEY_LOCAL_MACHINE\SOFTWARE
\Microsoft\Windows NT\CurrentVersion\Winlogon
CachedLogonsCount
  • Доступ к наиболее часто атакуемым ключам реестра следует ограничивать посредством списков управления доступом (Access Control Lists, ACLs). Следующие ключи реестра следует по меньшей мере защитить предоставлением "Всем" (Everyone) прав доступа только на чтение, а прав полного контроля (Full-Control) – только "Администраторам" (Administrators) и "Системе" (SYSTEM). Создателя "Владельца" (Owner) следует наделить правами полного контроля владельца (Full-Owner control):
    HKEY_LOCAL_MACHINE\SOFTWARE
\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\SOFTWARE
\Microsoft\Windows\CurrentVersion\RunOnce
HKEY_LOCAL_MACHINE\SOFTWAR
\Microsoft\Windows\CurrentVersion\RunOnceEx
HKEY_LOCAL_MACHINE\SOFTWARE
\Microsoft\Windows NT\CurrentVersion\AeDebug
HKEY_LOCAL_MACHINE\SOFTWARE
\Microsoft\Windows NT\CurrentVersion\WinLogon
    •

    Журналирование в Windows NT 4.0

    В Windows NT 4.0 есть несколько встроенных автоматических служб журналирования. Большинство служб пользуются EventLogs, с которой следует быть знакомым едва ли не каждому хорошему администратору систем Windows.

    Замечание. Описанные здесь особенности журналирования применимы и к более поздним версиям операционной системы Windows, но рассказывается о них только в этом разделе.

    Если на сервере запускаются какие бы то ни было службы Интернета (такие, как FTP, HTTP, SMTP и т. д.), их журналирование происходит посредством разных механизмов. Очень вероятно, что для настройки или отладки сервера будет использоваться приложение "Монитор производительности" (Performance Monitor). Это приложе- ние не пользуется услугами журнала приложений службы EventLog, а вместо этогведет свой собственный набор журналов.

    И наконец, один из наиболее важных аспектов системы – расписание автоматически выполняемых заданий – ведет свой журнал посредством еще одной службы. Поскольку в Windows NT нет нормальной централизованной службы ведения журналов, каждый должен заботиться сам о себе.

    Самое первое, что нужно сделать, – это вынести все журналы на отдельный журнальный раздел. Было бы удобно, хотя и не обязательно на все 100 %, использовать в качестве такого раздела отдельный диск, чтобы не влиять на производительность работы с частью данных на сервере. После того как журнальный раздел создан, следующий шаг – перенести туда все журналы из их мест размещения по умолчанию.

    Зачем все это? Если все журналы собраны в одном месте, процедура поддержки работающего сервера становится намного легче. Это дает возможность выполнять автоматическое резервное копирование и архивирование для последующего разбора и обработки.

    EventLogs

    EventLogs – это встроенные в Windows NT журналы событий, которые используются по умолчанию и могут быть просмотрены через обозреватель событий (Event Viewer). В Windows NT EventLogs является эквивалентом службы syslogs в операционной системе UNIX.

    Сама служба EventLog состоит из журнала приложений (Application Log), журнала безопасности (Security Log) и системного журнала (System Log). Большинство приложений, служб и системных событий Windows NT записывают свои отчеты в соответствующие категории. Каждая из категорий фактически обладает своим собственным отдельным физическим файлом, который может быть перемещен.

    Эта задача выполняется редактированием следующих ключей реестра:

    HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Services\Eventlog\Application
\CurrentControlSet\Services\Eventlog\Security
\CurrentControlSet\Services\Eventlog\System

    File

    Значения параметров "File" следует установить в новое имя папки раздела журнальных файлов. После редактирования этих значений сервер должен быть перезапущен, чтобы изменения вступили в силу.

    Службы Интернета

    Службы, предоставляемые инфраструктурой Windows IIS Web-сервера, генерируют журналы для каждой из них: Web, FTP и SMTP. Журналы службы Интернета уникальны в том смысле, что для автоматического перехода к новому журналу можно настроить временной интервал. А имя журнального файла может основываться на определенном периоде времени.

    Для изменения размещения этих журнальных файлов отредактируйте свойства корневой папки Web или FTP. Выберите свойства файла журнала и в диалоговое окно "Свойства" (Properties) введите новое размещение раздела журнальных файлов.

    Журналы производительности

    Журналы производительности создаются счетчиками монитора производительности (Performance Monitor). По умолчанию они находятся в %SystemDrive%\PerfLogs. Это значение может быть изменено редактированием параметра DefaultLogFileFolder в следующем ключе реестра:

    HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Services\SysmonLog
DefaultLogFileFolder

    Журналы планировщика

    Служба планировщика обычно находится в %SystemRoot%\SchedLgU.Txt. Журнал службы планировщика определяет все запланированные и выполняемые задачи, а также то, когда каждая из них началась и закончилась. Местонахождение этого файла может быть изменено редактированием значения LogPath в ключе реестра:

    HKEY_LOCAL_MACHINE\SOFTWARE
\Microsoft\SchedulingAgent
LogPath

    Этим завершается наше обсуждение укрепления Windows NT. Как уже упоминалось ранее, многое из рассмотренного здесь применимо и к новым версиям Windows. Однако, исходя из того факта, что после NT 4.0 в Windows было сделано множество улучшений, важно также рассмотреть и эти новые версии и наметить некие наиболее подходящие практические методы обеспечения безопасности с точки зрения процесса укрепления.

    9.3.2 Укрепление Windows 2000

    Windows 2000 является намного более большим и сложным продуктом, чем Windows NT 4.0, и, по сути, для полного анализа ее установок безопасности по умолчанию и защиты от любых недочетов требуется гораздо больше времени. Исходя из этого, рекомендации по укреплению, приведенные в настоящей лекции, следует рассматривать как некий след во времени, поэтому в текущий момент они могут оказаться и не совсем корректными. Таким образом, самые лучшие практические советы здесь ссылаются на несколько реально существующих документов, опубликованных Microsoft в своей библиотеке Technet, которые предоставят самую последнюю информацию.

    Рекомендации по укреплению установки

    При установке Windows 2000 лучше всего следовать данному методическому указанию настолько точно, насколько возможно. Везде, где это только применимо, используйте рекомендации, приводившиеся в предыдущем разделе, наряду с обсуждаемыми здесь указаниями, специфичными для Windows 2000.

    При установке Windows 2000 лучше всего попытаться уменьшить число устанавливаемых компонентов Windows 2000. По умолчанию Windows 2000 предлагает намного больше функциональных возможностей, чем Windows NT 4.0. Многое из этой функциональности лучше вообще НЕ предоставлять людям как внутри организации (если машина каким-либо образом доступна из Интернета), так и тем более кому бы то ни было снаружи.

    По умолчанию в установку Windows 2000 входит множество аксессуаров, утилит, мультимедийных приложений и схем, а также приложений коммуникации. Можно, конечно, впасть в искушение установить набор программного обеспечения, предлагаемого по умолчанию. Однако лучше все-таки уделить время для определения того, что действительно стоит устанавливать, а что нет. Не будет лишним повторить: чем больше установлено программного обеспечения, тем выше вероятность быть взломанным.

    Так же, как это делали в разделе о Windows NT 4.0, здесь мы расскажем о том, что делаем и чего не делаем при установке Windows 2000 в плане обеспечения безопасности и укрепления окружения.

    При установке делаем

    Прежде всего начнем с того, что следует делать. Этим будет гарантировано то, что смогут быть выработаны некие наиболее подходящие практические методы, а также то, что все необходимое для них будет установлено. Лучше всего начать с должным образом настроенной базы, чем потом оказаться перед необходимостью корректировки неправильной установки.

  • Ставьте под Windows 2000 файловую систему NTFS, а не FAT. NTFS дает дополнительное управление безопасностью посредством списков контроля доступа (ACLs) и является более "крепкой" файловой системой.

    Замечание. Некоторые системные администраторы предпочитают устанавливать файловую систему FAT, а уже затем, после установки, преобразовывать ее в файловую систему NTFS. Подобный способ действий не рекомендуется, поскольку в этом случае ACLs по умолчанию применены не будут.

  • Выбирайте только те компоненты и службы, которые необходимы для целей, ставящихся перед сервером. Для большинства брандмауэров и серверов DMZ "Службы терминала", "службы удаленной установки", "Службы сети" или "Службы файлов и принтеров" вообще не понадобятся. Например, стоит удостовериться, что в IIS-сервере не загружается поддержка FTP, если данный сервер предназначен только для обслуживания HTML-страниц. Или, если обработки потокового медиа не планируется, значит, и "Службы Windows Media" тоже подгружать не нужно.
  • Удалите "Общий доступ к файлам и принтерам в сети Microsoft" (File and Printer Sharing for Microsoft Networks). При настройке конфигурации сети следует выбирать "Выборочную установку" (Custom), чтобы вручную настроить сетевые компоненты.

    Если данный сервер предполагается в качестве Web или почтовой станции SMTP, "Клиента для сетей Microsoft" (Microsoft Networking Client) следует отключить снятием галочки пометки, хотя установлен он тем не менее все равно должен быть. Очевидно, что используемая для выполнения аутентификации "Служба локатора RPC" будет доступна только при установленном "Клиенте сетей Microsoft". Без этой службы нельзя запустить ни IIS, ни службы SMTP.

    Затем следует выбрать "Свойства протокола IP" (IP Protocol Properties). Для настройки IP адреса и информации DNS не используйте DHCP. После установки вручную сетевых параметров нажмите на кнопку "Дополнительно" (Advanced) и внесите следующие изменения:

  • Выберите закладку DNS. Снимите пометку с "Зарегистрировать адреса этого соединения в DNS" (Register This Connection's Addresses in DNS).
  • Выберите закладку WINS; удалением каких бы то ни было адресов оттуда запретите WINS. Если требуется ввести имена NetBIOS, делать это следует через содержимое файла LMHOSTS. Выбором "Запретить NetBIOS через TCP/IP" запретите работу NetBIOS посредством протокола TCP/IP.
  • Выберите закладку "Свойства" (Options) для настройки любой TCP/IP-фильтрации, как было описано ранее в разделе об Windows NT 4.0.
    •
  • Используйте несуществующую рабочую группу. Нет никаких причин включать брандмауэр или DMZ-сервер в работу домена или рабочей группы.
  • Запретите службу telnetd. Если в конечной системе все-таки сессии telnet должны быть разрешены, всех пользователей telnet следует ограничить одной группой аутентифицированных пользователей TelnetClients. Создайте группу TelnetClients, а затем добавьте в нее тех пользователей, которым доступ посредством telnet будет разрешен. Служба telnetd сама автоматически ограничит доступ к Telnet только членами группы TelnetClients.
  • Закройте ваш DNS-сервер. Передачи в пределах зоны следует ограничить только авторизированными службами. Для изменения свойств зоны следует использовать менеджер DNS. На закладке "Уведомления" (Notify) включите опцию "Разрешить доступ только с тех вторичных серверов, которые включены в список уведомлений" (Only Allow Access From Secondaries Included on Notify List). Позаботьтесь о защите первичных зон так же, как и вторичных. К сожалению, встроенные DNS-серверы, идущие в комплекте с Windows NT и 2000, не имеют средств для ограничения запросов. Если такая функциональность все же нужна, можно воспользоваться кроссплатформенной реализацией ISC BIND (Internet Software Consortium Berkeley Internet Name Daemon), используемой в большинстве UNIX-систем. С одной стороны, будет потеряна возможность администрирования посредством встроенного GUIGUI – Graphical User Interface (Графический интерфейс Пользователя., но взамен станет доступна вся мощь структурированности и возможностей управления, присущих реализации BIND. Исходные коды и бинарные сборки можно найти на сайте ISC по следующему адресу:

    http://www.isc.org/products/BIND/

    • При установке не делаем

    Сейчас о том, чего делать не следует.

  • Не загружайте "Службы сертификатов": им следует быть службой только для внутреннего пользования, так как закрытые ключи CA [Certificate Authorities (Полномочия сертификатов)] следует держать в тайне, и обычно вы не предлагаете регистрацию сертификата всяким пользователям Интернета. Общепринятым правилом является содержание корпоративных "Полномочий сертификатов" в жестко контролируемой, безопасной среде в изолированной внутренней сети. Более того, поскольку Lotus Domino вероятнее всего будет предлагать использование SSL, для данного компонента – не для операционной системы – будет лучше принять это предложение, что является еще одним аргументом в пользу того, чтобы не загружать "Служб сертификатов".

    Если требуется системный мониторинг, установите SNMP из "Набора для управления и мониторинга" (Management and Monitoring Tools), но соответствующим образом измените "имена сообществ" (community) для чтения и записи.

  • Не делайте установку в домен или в структуру "Активных каталогов" (Active Directory). Нет никаких разумных причин брандмауэру, DMZ-серверу, внешнему серверу DMZ или серверу DNS принимать участие в работе домена.
    •

    Политики Windows 2000

    Если укрепление Windows NT 4.0 показалось несколько бессистемным, то на самом деле так оно и есть. Нет никакого простого способа определить и применить все изменения реестра, файловой системы, настроек сети и политики пользователь/группа. Хуже того, нет никакого простого способа следить за внесенными изменениями для гарантии того, что изменения в политике не были отменены взломщиками, установленным программным обеспечением или примененным пакетом обновлений.

    С выходом Windows 2000 корпорация Microsoft ввела замечательный набор интегрируемых инструментов для "Консоли управления Microsoft" (Microsoft Management Console, MMC). Набор "Шаблонов безопасности" (Security Templates Tool) позволяет системным администраторам выбирать, просматривать и даже создавать самостоятельно шаблоны политики безопасности. Набор для "Конфигурации и анализа системы безопасности" (Security Configuration and Analysis Tool) дает системным ад министраторам возможность не только применять все эти политики одним простым действием, но и осуществлять наблюдение за сделанными изменениями, чтобы видеть, не изменилось ли чего впоследствии.

    Изначально "Набор шаблонов шезопасности" и "набор для конфигурации и анализа системы безопасности" не видны в MMC. Для управления серверными политиками и настройками оба эти инструмента следует туда добавить.

    Существует много пакетных шаблонов безопасности, среди которых и "Высокая безопасность для рабочих станций" (High Security for Workstations), которые определены в шаблоне HISECWS.INF. Кроме того, Microsoft выпустила "Шаблон высокой безопасности", предназначенный для Web-серверов. Шаблоны безопасности включают в себя большинство изменений в политике и в реестре, сделанные ранее для Windows NT 4.0. Шаблон безопасности HISECWEB.INF имеется в наличии на сайте Microsoft по следующему URL:

    http://support.microsoft.com/support/misc/kblookup.asp?id=Q316347

    Для использования шаблона выполните следующие шаги:

  • Скопируйте шаблон в папку %windir%\security\templates.
  • Откройте "Набор шаблонов безопасности" и тщательно просмотрите его настройки.
  • Откройте "Набор для конфигурации и анализа системы безопасности" и загрузите шаблон.
  • Кликните правой кнопкой мыши на "Наборе для конфигурации и анализа системы безопасности" и выберите "Анализировать компьютер" (Analyze Computer Now) из появившегося меню.
  • Дождитесь окончания работы.
  • Просмотрите найденное и, если необходимо, обновите шаблон.
    •

    Уделите некоторое время просмотру и чтению индивидуальных шаблонов. Вы можете сделать это либо посредством "Набора шаблонов безопасности", либо вручную при помощи текстового редактора вроде WordPad. Пробегите глазами по предлагаемым изменениям, чтобы определить, имеют ли они смысл для размещения в данной ИТ системе конкретного приложения. Готовый шаблон из "Набора шаблонов безопасности" можно использовать как основу для разработки индивидуального шаблона безопасности. После получения шаблона, удовлетворяющего нашим требованиям, следующий шаг – проанализировать, как он повлияет на сервер.

    Для загрузки шаблона используйте "Набор для конфигурации и анализа системы безопасности"; правый клик на иконке "Набора для конфигурации и анализа системы безопасности"; выберите "Анализировать компьютер". Найденное будет отображено на правой панели, показывая установки шаблона, текущие установки сервера и любые несоответствия. Просмотрите найденное и, если необходимо, настройте шаблон.

    После того как шаблон безопасности был полностью настроен со всеми соответствующими разрешениями, политиками, установками реестра и ограничениями, кликните правой кнопкой мыши на иконке "Набора для конфигурации и анализа системы безопасности" и выберите "Анализировать компьютер". Затем откиньтесь на спинку стула и позвольте программе закончить свою работу.

    У "набора для конфигурации и анализа системы безопасности" есть очень хороший эквивалент командной строки. Для анализа, настройки, обновления и сопоставления текущей серверной политики с вашим известным шаблоном можно использовать SECEDIT. Он удобен тем, что может быть запущен из сессии Telnet. Однако управлять сервером через нешифрованную удаленную сессию не рекомендуется.

    Укрепление, относящееся к работе с приложениями

    Ориентированные на приложения серверы, обитающие внутри брандмауэра, потребуют запуска дополнительных служб, которые будут предлагаться интернет-аудитории. Поскольку существует огромное количество приложений и вообще невообразимое множество различных комбинаций настроек этих приложений, попытка описать конфигурацию даже самых общих из них, таких, как HTTP, FTP и SMTP, выходит далеко за пределы данного курса.

    Если же ничего больше не делать, приложения примеров, устанавливаемые по умолчанию с IIS и различными компонентами, следует удалить. Приложения-примеры и их каталоги приведены в табл. 9.1.

    Месторасположение приложений-примеров, устанавливаемых вместе с IIS
    Приложение Куда установлено
    IIS \inetpub\iissamples
    IIS SDK \inetpub\iissamples\sdk
    Admin Scripts \inetpub\AdminScripts
    Data Access \Program Files\Common Files\System\msadc\Samples

    Нужно сказать, что существуют реальные документы, которые дают замечательную отправную точку для должной настройки более общих служб приложений DMZ-сервера:

  • Microsoft Windows NT 4.0 and IIS 4.0:

    http://www.microsoft.com/technet/security/iischk.asp

  • Microsoft Windows 2000 Server and IIS 5.0:

    http://www.microsoft.com/technet/security/iis5chk.asp

  • Microsoft SQL Server:

    http://www.microsoft.com/technet/SQL/Technote/secure.asp

    http://www.sqlsecurity.com/faq.asp

    •

    Этим мы завершаем наше обсуждение Windows 2000. Хотя между укреплением Windows NT 4.0 и Windows 2000 и есть некоторые совпадения, инструменты и методы с течением времени тем не менее эволюционировали. В результате при помощи политик процесс укрепления сервера Windows 2000 значительно менее бессистемный, нежели процесс укрепления сервера Windows NT 4.0.

    9.3.3 Укрепление рабочей станции Windows

    До настоящего момента основное внимание уделялось укреплению серверных конфигураций, чтобы сделать их более устойчивыми к атакам. Поскольку безопасность является суммой всех своих составных частей и в то же время наиболее уязвима в своей самой слабой точке, важно также обсудить и процесс укрепления конфигураций рабочих станций, особенно тех, которые работают под управлением операционных систем Windows (NT, 2000, XP), так как именно они на момент публикации данной книги были самыми распространенными настольными операционными системами.

    Также это является фундаментальной областью знаний о безопасности, в которой постоянно обнаруживаются все новые и новые слабые и уязвимые места во всех ИТ- системах, и операционная система Windows в этом плане не исключение.

    В результате, если нет систематического процесса по поддержанию конфигураций ИТ-систем (серверов и рабочих станций) в соответствии с последними обновлениями поставщика (в форме патчей или пакетов обновлений), последствия будут слишком предсказуемы: эти системы падут жертвой взлома.

    Этот раздел сосредоточивает свое внимание на рекомендациях по выбору инструментов, методик и технологий по укреплению рабочих станций Windows NT, 2000 и XP; и в частности на том, как применять патчи и настраивать эти системы для лучшей их защиты от компрометации. Рассмотренное в предыдущих разделах также следует принимать во внимание, так как у Windows в качестве серверной операционной системы и Windows в качестве рабочей станции много общего.

    Поскольку в нашем курсе речь идет о продуктах Lotus Collaborative, данный список не является исчерпывающим. Точно так же, если приведено число уязвимых мест, которые должны быть освещены для данных версий операционной системы Windows, совершенно невозможно составить список, который будет включать в себя рекомендации по всем конфигурациям. Основная же идея состоит в том, чтобы предоставить самую базовую информацию для стимуляции желания узнать больше и уменьшения риска компрометации настолько, насколько это только возможно.

    Мы рекомендуем вам прочитать статью Microsoft "Семь шагов к персональной компьютерной безопасности" ("Семь Steps to Personal Computing Security"), которая доступна на их корпоративном сайте по следующему URL:

    http://www.microsoft.com/security/articles/steps_default.asp

    В конечном итоге здесь мы пытаемся сфокусировать наше внимание на более защищенных конфигурациях Windows, а точнее на тех, которые построены вокруг ядра Windows NT (NT 4.0, 2000 и XP). Этот раздел не затрагивает конфигураций, построенных на ядре Windows "9x" – 95, 98, 98SE и ME, поскольку они создавались без учета аспектов безопасности и взламываются слишком легко. Организациям, действительно заботящимся о своей ИТ-безопасности, но имеющим рабочие станции на основе ядра 9x, следует рассмотреть перспективу замены их на конфигурации с ядром Windows NT.

    Использование учетной записи "Администратор"

    Для поддерживания рабочей станции Windows NT, 2000 или XP вам потребуется доступ к учетной записи "Администратор". (Это отличается от Windows 95, 98 и ME, в которых все пользователи имеют полные права доступа ко всей системе. Фактически это одна из главнейших причин, почему системы 9x являются незащищенными по своему дизайну.) В этом разделе мы обсудим привилегии, дающиеся конечному пользователю по отношению к учетной записи "Администратор", и затем рассмотрим защиту этой учетной записи.

    И наоборот, лучше разработать такие конфигурации рабочей станции Windows, которые не наделяют конечного пользователя администраторскими правами (или предоставление им привилегий администратора) на их машинах. Ограничение на то, какое программное обеспечение конечные пользователи могут установить на свои рабочие станции и каким образом, предохраняет многие "дыры" безопасности от вскрытия и делают всю ИТ-инфраструктуру более безопасной.

    Это обычно не согласуется с желаниями большинства пользователей. Большинство из них полагает, что на корпоративной рабочей станции (или даже на терминале) им следует обладать такой же степенью свободы, как и на своем собственном домашнем компьютере. Это вполне понятно, но машины не являются собственностью конечного пользователя, они являются собственностью организации. А значит, организации следует иметь в наличии политику безопасности, в соответствии с которой конечные пользователи не обладают на своих машинах администраторскими правами. (Если у организации ее нет, самое время вернуться к лекции 2, "Методологии построения систем безопасности", и написать набор соответствующих политик безопасности вместе с правилами пользования для конечного пользователя.) Если же такая политика имеется, данная тема закрыта для обсуждения и вам не придется тратить кучу времени на объяснения пользователям.

    Учетная запись "Администратор" имеет привилегии делать с системой Windows все что заблагорассудится. Хакеры-злоумышленники будут выискивать подсоединенные к Интернету рабочие станции, в которых учетная запись "Администратор" имеет либо тривиальный пароль, либо вообще не имеет пароля как такового. Как только эта учетная запись взломана, хакер получает полный контроль над рабочей станцией.

    Поэтому есть два варианта: один – иметь учетную запись "Администратор", другой – избавиться от нее (хотя и не полностью). Давайте рассмотрим их оба.

  • Если учетная запись "Администратор" остается как есть, ей следует быть защищенной нетривиальным паролем, который трудно угадать. Вот некоторые советы для генерации такого пароля:
  • В нем должно быть как минимум восемь символов. (Его следует рассматривать как парольную фразу, и, таким образом, в нем может быть символов намного больше восьми.)
  • Следует использовать по меньшей мере три различных типа символов (алфавитные, числовые и, если возможно, знаки пунктуации).
  • Он должен быть настолько случайным, насколько это возможно; вариаций словарных слов следует избегать.
    •
  • Потенциально более эффективный подход – создать альтернативную администраторскую учетную запись, с другим именем, которая использовалась бы для всех административных задач и имела бы все привилегии учетной записи "Администратор". То есть удалите оригинальную учетную запись "Администратор" и создайте фиктивную учетную запись "Администратор", без привилегий. Как только взломщики попытаются взломать эту учетную запись, запись о них будет оставлена в журналах аудита.

    • Установка и поддержка антивирусной защиты

    Важно обеспечить чистоту конфигурации рабочей станции, чтобы никакой файл не был взломан во время его обычного режима использования и чтобы никакие вновь вводимые в систему файлы не причинили ей вреда.

    Вот почему так важно иметь установленную антивирусную защиту, которая может выполнять периодическое сканирование файловой системы и памяти для обнаружения вирусов, "троянов" и "червей", возможно, обосновавшихся там. Так же как ИТ-системам требуются постоянное наблюдение и улучшения для поддержания их в соответствии с последними изменениями, так и антивирусные файлы не являются исключением. Чтобы этот инструмент безопасности был эффективным, в него должны входить самые последние антивирусные базы. Для поддержания этих баз файлы, содержащие их, следует обновлять еженедельно.

    У большинства организаций есть лицензии на Norton Anti-Virus (NAV), McAffee's VirusScan или на другие антивирусные программы, которые охватывают все рабочие станции. Нет причин, почему бы не использовать их на всех машинах. Антивирусная защита – это первая линия обороны рабочих станций Windows.

    Обновление при помощи центра обновлений Microsoft (Microsoft Update Center)

    Microsoft попыталась сделать управление обновлениями на рабочих станциях Windows относительно легким. Установка текущих исправлений и пакетов обновлений посредством центра обновлений Microsoft состоит из нескольких нажатий на кнопки и зачастую перезагрузки (или иногда нескольких перезагрузок), так что на первый взгляд процесс кажется несколько нудным. Тем не менее система проработала достаточно долго и хорошо зарекомендовала себя, и, исходя из количества ее пользователей, мы должны заключить, что она действительно не сложна в использовании.

    Следуйте нижеприведенным шагам для обновления конфигурации рабочей станции:

  • Используя учетную запись "Администратор" или любую другую запись с аналогичными привилегиями, зайдите в центр обновлений Microsoft (http://windowsupdate.microsoft.com/) и кликните на ссылке "Product Updates".
  • Сайт выделит подсветкой, есть ли в найденном какие-нибудь критические обновления ("CRITICAL UPDATES AND SERVICES PACKS"); их следует применить немедленно. Выберите подходящие обновления и нажмите на иконку "Загрузить" (Download).
    •

    Всегда есть риск того, что исправление или пакет обновлений может нежелательно повлиять на конфигурацию рабочей станции. Обратная сторона медали – неприменение критического патча с большой вероятностью оставит рабочую станцию открытой для взлома. Стоит помнить, что у патчей, вышедших достаточно давно, очень низкая вероятность оказаться неадекватными, так как с тех пор они уже были протестированы другими людьми.

    Применение пакетов обновлений и текущих исправлений может показаться утомительной и неблагодарной работой, но причина того, что такое множество червей буйно расплодилось по Интернету, в том, что они в точности используют известные и опубликованные "дыры". В общем, применение патчей к ИТ-системам, и к рабочим станциям в частности, – очень важная линия обороны.

    Советник по основным направлениям безопасности Microsoft (Microsoft Baseline Security Advisor, MBSA)

    Советник по основным направлениям безопасности Microsoft определит патчи, которые необходимо применить. URL для MBSA следующий:

    http://www.microsoft.com/technet/security/tools/mbsahome.

    MBSA поставляется как стандартный набор инструментов для установки. Он был выпущен в апреле 2002 г. и заменил собою более ранний, основывающийся на Web инструмент, называемый Microsoft's Personal Security Advisor (MPSA), который был предназначен для рабочих станций. MBSA – очень хороший инструмент для оценки степени защищенности рабочих станций Windows NT 4.0, Windows 2000 или Windows XP (также его можно использовать для оценки уровня безопасности серверов, работающих под управлением тех же версий операционной системы Windows). Еще он очень полезен для оценки безопасности серверов MS IIS и MS SQL.

    MBSA определит патчи (пакеты обновлений и текущие исправления), которые следует применять. Еще MBSA выдаст рекомендации по нескольким важным настройкам защиты. Он работает достаточно хорошо, и системные администраторы, вероятно, найдут его более чем полезным для обеспечения безопасности ИТ-систем, находящихся под их контролем и ответственностью.

    Для установки пакета надо обязательно обладать доступом к учетной записи Администратор и не менее важно также входить в систему как администратор для сканирования рабочей станции или сервера на наличие проблем. Если инструмент используется для сканирования безопасности, он загрузит и запустит содержимое, полученное от Microsoft, которое по идее предоставит самые последние и самые лучшие советы и настройки конфигурации на основании информации, предоставленной MBSA.

    При применении патчей хорошим стилем считается агрессивная стратегия. В конце концов, если поставщик рекомендует применить патчи, было бы совершенно глупо – или для этого понадобятся действительно веские причины – игнорировать этот совет. К слову, если продукт был взломан через какое-то уязвимое место, а патч, закрывающий это место, уже был выпущен ранее поставщиком, но не применен, очень трудно будет после этого идти с жалобой к поставщику.

    Что же касается самих патчей, лучше всего опробовать их на нескольких системах до того, как ставить на все ИТ-системы. Были случаи, когда Microsoft выпускал патч, который не работал или вызывал другие проблемы. Тем не менее вы можете быть в более чем достаточной мере уверенными в любом патче, с момента выхода которого прошло несколько недель, поскольку к этому моменту многие люди уже загрузили его, посмотрели, не вызывает ли он каких проблем, и, если таковые обнаружились, сообщили о них.

    Рекомендации MBSA могут быть несколько раздражающими при применении, но все они действительно стоят тех усилий. Обычно рекомендации MBSA точно такие же, какие предложили бы любые другие хорошо известные организации, занимающиеся безопасностью.

    IIS Web-сервер Microsoft

    Многие системы Windows NT 4.0, 2000 и XP сконфигурированы для работы с Web сервером, который называется "Информационный сервер Интернета Microsoft" (Internet Information Server, IIS). Он стал источником слишком большего числа взломов, самый известный из которых – червь "Code Red", который существует и по сей день, выискивая непропатченные или плохо настроенные серверы IIS. Ниже приводится то, что следует сделать для любой ИТ-системы, запускающей MS IIS Web-сервер.

  • Остановите MS IIS Web-сервер, если он не нужен.

    Если конечным пользователям MS IIS Web-сервер не нужен или если конфигурация сервера организации не требует его, будет намного безопаснее не запускать этот сервер вообще. Логика – и совершенно справедливая – в том, что в первую очередь Web-сервер (такой, как IIS) невозможно взломать, если он не запущен. Точно так же, если он не работает, то в плане безопасности для системных администраторов одной головной болью меньше. В конце концов, можно вообще удалить подсистему IIS с рабочей станции или сервера, но, пожалуй, лучше все-таки будет только его остановить, потому что между различными компонентами версий операционной системы Windows существует слишком много взаимозависимостей, чтобы быть на 100 % уверенным в том, что удаление компонентов подсистемы позже не повлияет на что-нибудь еще.

  • Обновляйте MS IIS Web-сервер.

    Обновления для MS IIS Web-сервера можно найти при помощи инструмента MBSA, который обсуждался ранее. Как уже упоминалось, он эволюционировал из более раннего, основанного на Web-интерфейсе инструмента (который больше уже недоступен). Причиной для такой эволюции стала невозможность отследить текущие исправления для MS IIS Web-сервера. Фирме Microsoft пришлось рекомендовать "инструмент для проверки текущих исправлений", особенно для IIS, который больше не требуется для Windows 2000 и Windows XP.

  • Посмотрите "Инструмент для проверки текущих исправлений системы безопасности в сетях Microsoft" (Microsoft Network Security Hot Fix Checker), Hfnetchk.exe, который находится по следующему URL:

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;q303215

  • Загляните также в "Часто задаваемые вопросы об инструменте для проверки текущих исправлений системы безопасности в сетях Microsoft", Hfnetchk.exe, (Q305385) по адресу:

    http://support.microsoft.com/default.aspx?scid=kb;en-us;Q305385

    •

    Упомянутые патчи все есть в "Бюллетене безопасности Microsoft", который находится на сайте Microsoft Technet Web по следующему URL:

    http://www.microsoft.com/technet/security/current.asp

    И наконец, Microsoft опубликовал инструмент для запирания MS IIS Web-сервера и закрытия многих общеизвестных "дыр". См. "Инструмент для Запирания IIS Microsoft", который находится по следующему URL:

    http://www.microsoft.com/technet/security/tools/tools/locktool.asp

    Microsoft SQL-сервер

    Некоторые системы Windows NT 4.0, 2000 и XP настроены с поддержкой сервера баз данных, способного обрабатывать запросы языка структурных запросов (Structure Query Language, SQL). Этот сервер баз данных называется MS SQL-сервером. Так же как и MS IIS, данный сервер стал источником нескольких "дыр". Самая известная – червь "Slammer".

    Небольшими усилиями Microsoft SQL-сервер можно сделать безопасным. Если его не обезопасить, шансы на то, что он будет взломан, слишком велики. Для любой ИТ-системы с работающим на ней MS SQL-сервером рекомендации для защиты системы следующие:

  • Остановите MS SQL-сервер, если он не нужен.

    Если конечным пользователям MS SQL-сервер не нужен или если конфигурация сервера организации не требует его, будет намного безопаснее не запускать этот сервер вообще. Опять же, логика в том, что в первую очередь сервер баз данных (такой, как MS SQL-сервер) невозможно взломать, если он не запущен. Точно так же, если он не работает, то в плане безопасности для системных администраторов одной головной болью меньше.

    Далее, если MS SQL-сервер все-таки нужен, лучше установить его на какой-нибудь другой машине. Приложения для работы с базами данных не обязательно запускать на той же машине, на которой находится и сервер баз данных.

    Хотя и можно вообще удалить подсистему MS SQL-сервера с рабочей станции или сервера, но, пожалуй, лучше все-таки будет только его остановить, потому что между различными компонентами версий операционной системы Windows существует слишком много взаимозависимостей, чтобы быть на 100 % уверенным в том, что удаление компонентов подсистемы позже не повлияет на что-нибудь еще.

    И последнее, если MS SQL-сервер уже намеренно установлен, его следует немедленно отключить до тех пор, пока к нему не будут применены все патчи и текущие исправления и пока не будет завершен процесс укрепления.

  • Обновляйте MS SQL-сервер

    Обновления для MS SQL-сервера (пакеты обновлений и текущие исправления) можно найти при помощи инструмента MBSA, который обсуждался ранее. Все еще не установленные патчи должны быть применены как можно быстрее, и ни один MS SQL-сервер не следует открывать до тех пор, пока к нему не были применены все патчи. MBSA определит некоторые проблемы, которые в противном случае могли быть упущены и которые следует изучить незамедлительно.

  • См. "Инструмент для проверки текущих исправлений системы безопасности в сетях Microsoft", Hfnetchk.exe, (Q303215), уже упоминавшийся ранее.
  • Загляните также в "Часто задаваемые вопросы об инструменте для проверки текущих исправлений системы безопасности в сетях Microsoft", Hfnetchk.exe, (Q305385).
    •

    Упомянутые патчи все есть в "Бюллетене безопасности Microsoft", который находится на сайте Microsoft Technet Web.

    Тесты на проникновение

    Многие поставщики продуктов безопасности распространяют бесплатные инструменты для оценки ИТ-систем (тем самым в действительности они подталкивают вас к покупке их товаров). Эти поставщики проверяют, насколько хорошо укреплена тестируемая система, при помощи так называемого теста на проникновение.

    Например, Symantec, создатель антивируса Norton Anti-Virus, предлагает Symantec Security Check" (Проверка безопасности от Symantec), в котором можно найти несколько очень хороших бесплатных услуг. Их можно найти по следующему URL:

    http://security.symantec.com/ssc/home.asp

    Среди предоставляемых бесплатных услуг инструменты "Scan for Security Risks" (Сканирование на наличие угроз для безопасности, т. е. как раз тест на проникновение), "Scan for Viruses" ("Сканирование на наличие вирусов", очень похож на сам Norton Anti-Virus) и "Trace a Potential Attacker" (Для выслеживания потенциальных взломщиков, данного IP-номера). Эти инструменты очень компетентны в том, что они делают.

  • Если система, которую нужно протестировать, уже укреплена, то "Scan for Security Risks" будет прекрасным средством ля проверки того, что работа была выполнена должным образом. Также он определит, нет ли в ИТ-системе нежелательных служб, установленных кем-то из наиболее распространенных троянских коней.
  • Если система еще не укреплена или если система укреплена, но только до того момента, когда антивирусный сканер еще не установлен "Scan for Viruses" будет превосходным выбором, с чего начать. Он просканирует файловую систему ИТ-системы на наличие зараженных файлов. После этого, независимо от результатов сканирования, следует установить антивирусный сканер и применить к рабочей станции соответствующие меры по укреплению.
    •

    Замечания. Есть два очень важных замечания.

    Во-первых, инструменты Symantec подгружают в ИТ-систему содержимое ActiveX. Обычно подобного не следует допускать, кроме тех редких случаев, когда организации, делающей это, можно доверять. Что касается упомянутых здесь специфических инструментов, Symantec – компания, проработавшая долго и упорно в сфере безопасности и более чем завоевавшая себе доверие. Кроме того, ее инструменты действительно работают хорошо и помогают обеспечить лучшую безопасность; не отвергайте их.

    Во-вторых, Symantec тем не менее тоже делает ошибки. Например, такая проблема безопасности, как переполнение буфера ActiveX в "Проверке безопасности Symantec" от 25.06.2003, которая была открыта (и исправлена) в компоненте ActiveX, используемом для реализации проверки безопасности. Подробности находятся по адресу:

    http://www.sarc.com/avcenter/security/Content/2003.06.25.html

    У Symantec нет монополии на подобные устройства. Другие поставщики продуктов безопасности выпускают сходные инструменты, которые для поднятия уровня безопасности ИТ-системы не менее компетентны. Например, Gibson Research Corporation предлагает популярный тест "ShieldsUp!", который является еще одним очень хорошим тестом на проникновение. Он находится по следующему URL:

    http://grc.com/intro.htm

    Важно! Представленные здесь предположительные инструменты выступают в качестве примеров, а не поддержки или рекламы компаний Symantec или Gibson Research. На рынке есть и другие инструменты и поставщики услуг безопасности, на которые тоже стоит обратить внимание, чтобы гарантировать, что к ИТ-системам организации может быть применен достойный уровень укрепления.

    9.3.4 Дальнейшее чтение

    В этом курсе невозможно охватить все аспекты укрепления серверов и рабочих станций Windows.

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

  • Безопасность от Microsoft (http://www.microsoft.com/security/)
  • "Семь шагов к персональной компьютерной безопасности":

    http://www.microsoft.com/security/articles/steps_default.asp

  • "Инструменты и контрольные списки безопасности"

    http://www.microsoft.com/technet/security/tools/tools.asp

    •
  • Безопасность Windows NT и конфигурационные ресурсы от координационного центра CERT (http://www.cert.org/tech_tips/win-resources.html)
  • "Руководство по настройке Windows NT"

    http://www.cert.org/tech_tips/win_configuration_guidelines.html

  • "Безопасность домашней сети"

    http://www.cert.org/tech_tips/home_networks.html

  • "Ресурсы о компьютерных вирусах"

    http://www.cert.org/other_sources/viruses.html

  • Читальный зал информационной безопасности в институте SANS (http://www.sans.org/rr/index.php)
  • "Вопросы по Windows 2000"

    http://www.sans.org/rr/catindex.php?cat_id=66

    • Данные – всего лишь отправная точка. В Web есть множество других сайтов, на которых имеется прекрасная информация.

    9.4 Укрепление систем UNIX

    В этом разделе мы рассмотрим укрепление UNIX-серверов. Системы UNIX и системы Windows в достаточной мере отличаются друг от друга, чтобы для них требовались совершенно раздельные обсуждения.

    Относительно UNIX говорят, что самое замечательное в стандартах – это то, что их так много и можно выбирать. UNIX выпускается целым рядом семейств, два доминирующих из которых произошли от BSD и от ATT System V. Некоторые из характерных реализаций UNIX в этих двух категориях приведены ниже.

    Системы UNIX, полученные из BSD:

  • OpenBSD,
  • FreeBSD,
  • NetBSD,
  • BSDi,
  • MacOS X,
  • SunOS 4.
  • Системы UNIX, полученные из System V:
  • HP-UX,
  • Solaris (SunOS 5).
    •

    Замечание. AIX, по сути, подходит к любой категории, поддерживая команды, которые будут работать в стиле либо BSD, либо System V в зависимости от того, как они вызываются. Из-за этого отличия AIX мы посвятили отдельный раздел. См. 9.5, "Укрепление операционной системы AIX".

    Из этого возникает вопрос, куда же отнести Linux? Это хороший вопрос, так как Linux не является производным от какого бы то ни было UNIX. Тем не менее – и это полностью зависит от дистрибутива – он придерживается семантики и BSD и System V. Фактически, чтобы не давать неоднозначных ответов, сам по себе Linux – это просто ядро операционной системы и несколько драйверов поддержки. Большинство дистрибутивов Linux использует систему GNU (http://www.gnu.org), из-за чего они называются дистрибутивами GNU/Linux. Существуют сотни доступных дистрибутивов GNU/Linux, но даже "лидирующая пятерка" различается по своим командам по умолчанию, начальным загрузочным скриптам, раскладкам файловой системы, включая утилиты и системы пакетов.

    На основании всего этого надо сказать, что, в отличие от Windows NT, Windows 2000 и Windows XP, описание того, как укреплять сервер UNIX или Linux, – намного более сложная задача.

    Тем не менее данный раздел дает некоторые общие процедуры, которые можно применять ко всем версиям UNIX и дистрибутивам Linux. После него приведены некоторые ссылки на реальные документы в Интернете, которые отслеживают имеющиеся в наличии данные и релизы, а также углубляются в более детальные описания того, как укреплять сервер для конкретной задачи.

    9.4.1 Общие шаги по укреплению серверов UNIX и Linux

    Говоря в целом, системное укрепление сервера UNIX (сюда входят и серверы GNU/Linux) – это целая глобальная философия системной безопасности, которая особенно фокусируется не только на обнаружении, но и на предотвращении. Сюда входят и удаление ненужных служб из базовой конфигурации операционной системы, и ограничение пользовательского доступа к системе, и накладывание ограничений на пароли, и контроль прав пользователей и групп, и разрешение системного учета.

    Во время процедуры минимизации, описываемой в этом разделе, следует идентифицировать и запретить те компоненты и службы операционной системы, которые не нужны для выполнения текущей задачи.

    Например, если система используется в качестве файлового сервера, от разрешения служб электронной почты (e-mail) будет немного пользы. Служба e-mail запускается от имени root, и у взломов, связанных с электронной почтой, долгая история. Процедуры должного системного укрепления взывают к тому, чтобы подобные службы были отключены, что приводит к конечной системе с минимальной вероятностью взлома.

    Процесс укрепления серверов UNIX или GNU/Linux начинается с самого момента установки. Соответственно выполняются дополнительные действия, в которые входят:

  • как устранение возможных точек атаки остановкой или перенастройкой служб и портов, так и удаление ненужных библиотек;
  • добавление устойчивости файловой системе посредством рассмотрения файловой принадлежности и разрешений;
  • надлежащая настройка пользовательских учетных записей, чтобы привилегированные учетные записи использовались только тогда, когда они специально определены (и необходимы), и чтобы все учетные записи имели соответствующие нетривиальные пароли.
    •

    Некоторые общие рекомендации по конфигурированию серверов UNIX, чтобы сделать их более безопасными по умолчанию, находятся на Web-сайте CERT по следующему URL:

    ftp://info.cert.org/pub/tech_tips/UNIX_configuration_guidelines

    9.4.2 Разбиение на разделы для лучшей защиты

    Обычно, вне зависимости от устанавливаемого клона UNIX, количество дисковых разделов определено и каждый из них имеет свое собственное специальное предназначение, это такие разделы, как SWAP и /tmp. Кроме этих очевидных разделов, следует проделать некоторую работу для защиты от атак типа "отказа от обслуживания" ( denial-of-service ) "нехватка места на диске" ( out-of-disc-space ).

    Некоторые типичные атаки пытаются создать непомерное образование журнальных данных: или заполняют файловую систему сервера UNIX большими файлами через FTP, или, если ваш Domino-сервер не настроен должным образом, пытаются послать чрезмерно большие сообщения, которые заставят файл mail.box вырасти соответственно и занять требуемое место на жестком диске.

    Самый лучший способ защититься от такого рода атак – это сегментировать иерархию файловой системы на несколько отдельных физических разделов.

    Корневой раздел ( "/" ). Этот раздел может быть маленьким, потому что обычно на нем находится только ядро, подразумевающее необходимые файлы, библиотеки и конфигурацию для начальной загрузки, которые находятся в /bin, /sbin, /etc и /lib. Доступ к присоединенным устройствам осуществляется через папки /dev и /devices. Многие дистрибутивы GNU/Linux хранят ядра и символьные данные в папке /boot, в то время как библиотеки ядра расположены в /lib.

    Раздел /usr. Как правило, это раздел для хранения приложений, доступных обычному пользователю. Обычно в /usr не содержится никаких данных или файлов конфигурации, способных изменяться; по этой причине – как дополнительная мера безопасности – его можно подсоединять (монтировать, mount) только для чтения.

    Раздел /var. На этом разделе хранятся системные журналы и данные таких служб, как почта, Web, базы данных, принтеры, запущенные службы, управление пакетами и т. д. Если под корневым каталогом/создается всего один отдельный раздел, /var как раз и есть один из тех, которые следует создавать отдельно.

    Каталог /usr/local ( /opt в Solaris). Эти папки часто содержат локально установленные "по выбору" программное обеспечение, конфигурационные файлы и данные. На каталог /usr/local обычно не влияют обновления операционной системы. В зависимости от того, каким образом эти каталоги используются системой UNIX, они тоже могут быть подсоединены только для чтения.

    Детали могут варьироваться в различных версиях UNIX (и дистрибутивах GNU/ Linux), так что для определения наилучшего способа установить их с ориентацией на должный уровень безопасности мы рекомендуем вам прочитать замечания по установке, которые поставляются вместе с той версией UNIX, которая планируется к установке.

    9.4.3 Запрет внешней службы inetd

    Служба inetd – это "суперсервер Интернета" в UNIX. В основном это процесс-демонПроцесс-демон – это такой процесс, который постоянно находится в оперативной памяти компьютера и работает в фоновом режиме, без вывода в консоль. Аналоги – службы в Windows или резидентные программы в DOS., который вызывается во время загрузки системы и который читает текстовый конфигурационный файл, находящийся обычно в /etc/inetd.conf.

    Служба inetd слушает входящие соединения по предопределенным IP-портам. Когда соединение по заданному порту установлено, она вызывает заранее настроенную программу для обработки запроса. После того как соединение завершилось, процесс вызывает службу, которая обрабатывает запрос. Первоначальная причина для создания данной службы состояла в том, чтобы уменьшить нагрузку и ресурсы, требуемые для ИТ-системы.

    Через inetd запускается целый набор служб, и почти все из них следует запретить, как часть должным образом укрепленного сервера. Помимо стандартно-запрещаемых FTP, TFTP, Telnet и команд Berkley r*, также следует запретить и следующее.

    Служба in.named. Это демон служб разрешения имен BIND. Помимо серверов, которые специально определяются в качестве DNS-серверов организации, DNS не следует запускать на укрепленном сервере UNIX.

    Служба in.fingerd. Это демон программы finger, которую можно использовать для отображения информации о пользователе и для вывода списка пользователей, в данный момент находящихся в системе. На должным образом укрепленном сервере UNIX нет причин для афиширования подобной информации, которая могла бы оказаться полезной для предполагаемых взломщиков.

    Служба daytime. Эта служба выводит дату и время в системе в строковом формате. Не позволяйте возможным взломщикам получить дату и время системы, так как они могут воспользоваться этими данными для реализации повторяющихся атак.

    Служба time. Это служба, которая возвращает время в виде 32-битового значения, представляющего количество секунд, прошедших после полуночи 1 января 1900 г. Не позволяйте возможным взломщикам получить точное системное время.

    Служба echo. Это диагностическая служба, которая отражает входящие данные обратно к подсоединившийся машине. Не позволяйте возможным взломщикам получить информацию о системах, которые отвечают на подобные запросы.

    Служба discard. Это диагностическая служба, которая не отражает входящий поток данных обратно к подсоединившейся машине (таким образом, просто избавляясь от них). Не позволяйте возможным взломщикам посылать информацию в "черную дыру".

    Служба chargen. Это диагностическая служба, которая автоматически генерирует поток символов для отправки к подсоединившейся машине. Не позволяйте возможным взломщикам получить машину для генерации потока данных, который будет отослан другой машине в пределах или за пределами сети организации.

    Служба systat. Эта служба предоставляет список всех процессов и их статусов. Не позволяйте возможным взломщикам получать такую жизненно важную информацию.

    Служба netstat. Эта служба предоставляет список всех текущих сетевых подключений и их статусов. Не позволяйте возможным взломщикам получать такую жизненно важную информацию.

    Этот список ни в коем случае не является исчерпывающим. Для определения, какие службы могут быть установлены, что открывает уязвимые точки входа и методы для доступа к серверу и внутри сервера UNIX, следует провести надлежащее рассмотрение устанавливаемой системы UNIX.

    9.4.4 Установка и настройка tcp_wrappers

    Мы рекомендуем на укрепляемый сервер UNIX установить tcp_wrappers (созданные Wietse Venema), которые позволят вам задать контроль доступа к различным службам по ограниченному набору критериев, таких, как, например, имя пользователя, IP-адрес или домен DNS. Они невелики и чрезвычайно полезны на внутренних серверах, не только на внешних боксах, которые могут быть настроены как брандмауэры, серверы DMZ или прокси-серверы (не важно, основные ли они или резервные). Так вот, они по умолчанию устанавливаются и конфигурируются большинством дистрибутивов GNU/Linux и релизов BSD. Для тех же систем UNIX, в которых tcp_wrappers по умолчанию не установлены, исходники можно найти по следующему URL (затем их можно откомпилировать и полученные исполняемые модули установить на сервер):

    ftp://ftp.porcupine.org/pub/security/index.html

    Причина для установки такого дополнительного компонента в существующую конфигурацию UNIX состоит в том, чтобы избежать единых точек отказа (single points of failure) и обеспечить безопасность по всем уровням. Если один уровень взломан или обойден, другие уровни будут стоять на страже перед взломом.

    Полезно помнить, что большинство пробоев информационной безопасности, случайных или преднамеренных, происходит изнутри. Внимание прессы же привлекают только внешние взломы, массивные распределенные атаки вида отказа от обслуживания (DDoS, Distributed Denial of Service), горячие вирусы/"черви"/"трояны" и украденные базы данных кредитных карт.

    Добавочный компонент tcp_wrappers имеет два основных файла, которые разрешают доступ к индивидуально определенным службам. Два нижеприведенных файла проверяются на правила, определяющие доступ к индивидуальным или заданным по шаблону службам.

    /etc/hosts.allow
/etc/hosts.deny

    Как и в большинстве машин, осуществляющих фильтрацию tcp/ip-запросов (таких, как брандмауэры или серверы, доступ к которым сильно ограничен), доступ предоставляется или запрещается на основании первого же совпадающего правила.

    Правила проверяются в следующем порядке: сначала в hosts.allow, затем в hosts.deny. Будьте осторожны в использовании шаблонов KNOWN или UNKNOWN. ALL всегда будет совпадать, какие бы критерии ни тестировались. За дальнейшими подробностями по синтаксису и по написанию правил обращайтесь к man-страницеВ системах UNIX и GNU/Linux документация, как правило, поставляется в виде так называемых man-страниц (man pages), которые вызываются из командной строки командой man [параметры] "имя запрашиваемой команды/процедуры/файла/службы/темы". Например, man hosts_access или man bash. hosts_access, идущей в комплекте с tcp_wrappers.

    9.4.5 Сжатие опций по умолчанию программы sendmail

    Sendmail идет едва ли не с каждой установкой UNIX (включяя GNU/Linux) как агент по умолчанию для пересылки почты (Mail Transfer Agent, MTA). В результате такого широкого распространения по приблизительным оценкам оказалось, что sendmail обрабатывает подавляющее большинство почты в Интернете. А поскольку он запускается как suid rootАтрибут (бит) прав доступа suid (set-UID) позволяет программам запускаться от имени и с правами пользователя-владельца программы (т. е. соответствующего исполняемого файла), а не того пользователя, который запустил программу (как происходит обычно). Например, "suid root" обозначает, что программа принадлежит пользователю root и обычный пользователь исполняет ее с правами root., взлом sendmail влияет на миллионы машин.

    Последняя версия sendmail поддерживает такие новые возможности, как STARTTLS и шифрование SMTP AUTH. Если в комплект с устанавливаемой операционной системой UNIX входит более старая версия sendmail (подразумевается та, которая не поддерживает эти новые возможности), вам следует подумать об обновлении ее на самую последнюю из имеющихся в наличии. По крайней мере убедитесь, что эта версия не старее версии 8.9.3 из-за хорошо известных "дыр" безопасности.

    Чтобы разрешить Realtime Blackhole List (черный список реального времени), который помимо прочего защитит систему и пользователей от спама, в файл sendmail.mc следует вписать следующее:

    FEATURE(rbl)dnl

    Кроме того, в самом sendmail рекомендуется запретить команды SMTP VRFY и EXPN. Эти команды зачастую используются взломщиками для сбора информации о сервере. Запретите их при помощи следующего:

    define('confPRIVACY_FLAGS', 'novrfy,noexpn')dnl

    Есть несколько дополнительных флагов, которые вы можете установить, чтобы заставить sendmail вести себя более безопасным образом:

  • authwarnings: при определенных условиях в сообщения следует добавлять заголовок X-Authentication-Warning, что может сообщить почтовой системе о попытках обмана;
  • needmailhelo: требует от сайта-отправителя при начале соединения для отправки почты сначала использовать команду SMTP HELO ;
  • needexpnhelo: требует от сайта-отправителя использовать команду SMTP HELO до разрешения какого бы то ни было применения EXPN;
  • needvrfyhelo: требует от сайта-отправителя использовать команду SMTP HELO до разрешения какого бы то ни было применения VRFY;
  • noreceipts: запрещает уведомления о статусе доставки (Delivery Status Notifications, DSNs) и чтение подтверждений;
  • goaway: устанавливает все флаги, кроме restrictmailq и restrictqrun ;
  • restrictmailq: не дает возможности пользователям употреблять команду mailq для просмотра содержимого почтовой очереди;
  • restrictqrun: удерживает пользователей от обработки очереди.
    •

    Верно также, что при запущенном сервере Domino поверх операционной системы UNIX или GNU/Linux можно также sendmail отключить вообще и больше не забивать себе голову данным вопросомЕсли вы используете в качестве почтового (SMTP) сервера Domino, то вам необходимо отключить службу sendmail, так как она применяет тот же стандартный порт 25..

    9.4.6 Задачи, характерные для Linux

    В мире существует много дистрибутивов GNU/Linux. Самый маленький из них так мал, что полностью помещается на флоппи-диске 1.44 Мб (и называется Minix). У каждого производителя имеется свой собственный процесс установки, который обычно еще и изменяется от версии к версии дистрибутива данного производителя.

    Среди дистрибутивов GNU/Linux лидерами являются Red Hat, SUSE, TurboLinux, Mandrake, Caldera, Slackware и Debian. Хотя основная идея состоит в том, что следует использовать такой дистрибутив GNU/Linux, который поддерживается Domino, многие серверы могут использовать вообще другие дистрибутивы. Это происходит потому, что большое количество дистрибутивов позволяет производителям подгонять свои дистрибутивы GNU/Linux под специфические задачи, такие, как встроенные системы, маршрутизаторы и брандмауэры. Внимательно ознакомьтесь с доступными дистрибутивами и определите, который из них наилучшим образом подходит для нужд организации, исходя из того места, где должен быть размещен сервер, и его роли в общей ИТ-инфраструктуре организации.

    В свете вышесказанного из наиболее распространенных дистрибутивов особо выделяются двое, но по разным причинам.

    Red Hat. Данный дистрибутив обладает самым признаваемым именем и, как правило, первым получает любой вид корпоративной поддержки в плане коммерческого программного обеспечения или коммерческой технической службы. Многие производители, включая Oracle, IBM и Check Point, сделали релизы своих продуктов под дистрибутивы Red Hat. Это не означает, что данные программные релизы не будут работать под другими дистрибутивами GNU/Linux, но в случае каких-либо проблем производитель может не оказать поддержки вашей установке своего продукта на дистрибутиве, отличном от Red Hat.

    Debian. Этот дистрибутив тоже заслуживает упоминания. Прежде всего не потому, что он полностью бесплатен, а потому, что он поддерживается некоммерческой организацией, созданной исключительно из добровольцев. Эти добровольцы очень сильно мотивированы качеством и гордятся своими усилиями сделать Debian самым стабильным и полностью на все 100 % бесплатным дистрибутивом изо всех имеющихся в наличии. Debian зарекомендовал себя как в высшей степени стабильный и легкий в управлении и удаленном обновлении. Процесс обновления общепризнанно является самым легким среди всех дистрибутивов GNU/Linux. Установки Debian можно обновлять без необходимости перезагрузки, замещая любой из установленных пакетов и затем перезапуская его процесс, за исключением ядра ОС. Кроме того, пакетная система Debian и его пользовательские интерфейсы обеспечивают очень подробный контроль относительно того, какие пакеты, утилиты, библиотеки и файлы есть в вашей системе. Также в настоящий момент Debian поддерживает шесть различных архитектур и включает в себя более 3 900 пакетов программного обеспечения, которые можно выбрать при установке.

    Другие достойные упоминания дистрибутивы – это SUSE, являющиеся самыми предпочитаемыми в Германии и предлагающие действительно хороший инструмент для установки, называемый YAST2, который делает процесс установки дистрибутива невероятно легким. В списке поддерживаемых дистрибутивов GNU/Linux, на которых будет запускаться сервер Domino, находятся также TurboLinux и Caldera.

    Для всех дистрибутивов GNU/Linux, в которых имеется программа установки, следует выбирать установку компонентов вручную по выбору пользователя (Custom Installation) и устанавливать только те конкретные пакеты, которые требуются для установки сервера. Кроме как для удобства использования, нет никакой необходимости устанавливать пакеты для разработчиков, какие бы то ни было новые настольные системы KDE или GNOME, и определенно не X Windows (особенно в сочетании с Domino, поскольку Domino работает на сервере через консоль). К сожалению, ни один из вышеупомянутых дистрибутивов не предлагает такого варианта установки, как минимальный по объему защищенный сервер. Поэтому приходится укреплять сервер вручную.

    Во время процесса установки обязательно следует выбрать поддержку файла теневых паролей (enable shadow password); также вместо стандартной функции crypt для паролей следует выбрать хеширование MD5. Если данные опции недоступны во время установки, их можно изменить после нее. В Red Hat следует использовать утилиту setup. В Debian для разрешения или запрещения теневых паролей – утилиту shadowconfig. В других дистрибутивах GNU/Linux о подробностях по данному вопросу смотрите man-страницы. Для разрешения хеширования MD5 и включения хешей md5 в строки паролей следует отредактировать соответствующие файлы в папке /etc/pam.d.

    Также следует включить поддержку ipchains, даже если данный сервер в DMZ, так как ipchains добавляет дополнительные уровни защиты и закрывает сервер от трафика, по каким-то причинам миновавшего брандмауэр.

    Кроме того, нужно следить за информацией относительно безопасности и списками исправлений/обновлений на сайтах производителей дистрибутивов GNU/Linux. В Debian очень легко автоматически устанавливать обновления системы безопасности с помощью утилиты apt-get. В установках Red Hat, начиная с версии 6.0, для получения обновленных пакетов вашего релиза введена утилита up2date. За информацией о деталях реализации подобных инструментов, если они есть, обращайтесь к сайтам производителей данных дистрибутивов GNU/Linux.

    Для тех людей, которые решили устанавливать Red Hat Linux, существует занимающийся вопросами безопасности проект, называемый Bastille Linux, целью которого является не просто укрепить вашу установку Linux, а именно обучить администраторов, как вообще укреплять систему.

    Bastille Linux поддерживает дистрибутивы Red Hat и Mandrake LinuxВ настоящий момент проектом Bastille Linux поддерживаются следующие дистрибутивы: Red Hat (Fedora Core, Enterprise, Numbered/Classic), SUSE, Debian, Gentoo, Mandrake и HP-UX. Также в стадии бета находится разработка поддержки для Full Mac OS X., и цель данного проекта – сделать дистрибутив, и привкус UNIX в нем, более агностическим. Сам по себе продукт Bastille Linux является набором сценариев, которые задают ряд вопросов и затем дают возможность тому, кто устанавливает дистрибутив (или администратору, это не всегда бывает одно и то же лицо), применить эти модификации к своей системе. Вопросы описывают, что нужно сделать, почему это следует делать и почему делать этого может быть нежелательно. Очень познавательно, особенно для тех администраторов, которые только начинают знакомиться с Linux. Bastille Linux можно найти по следующему URL:

    http://www.bastille-linux.org/

    Еще один замечательный источник информации для администраторов – "Руководство по безопасности для администраторов Linux". Оно охватывает чрезвычайно широкий спектр тем касательно Linux и безопасности. "Руководство по безопасности для администраторов Linux" может быть найдено по адресу:

    http://www.securityportal.com/lasg/

    9.4.7 Задачи, характерные для Solaris

    Solaris по умолчанию поставляется в четырех возможных конфигурациях: базовая (Core), для конечного пользователя (End-User), для разработчика (Developer) и полный дистрибутив (Entire Distribution). Установка любой конфигурации, отличной от базовой, включает в себя большее количество служб, чем требуется для укрепления сервера. На практике же часто можно убрать даже значительную часть базовой конфигурации в зависимости от тех требований, которые предъявляются к серверу.

    О серверах Solaris есть несколько замечательных документов, опубликованных компанией Sun в своем архиве Blueprints Online, который находится по URL:

    http://www.sun.com/software/solutions/blueprints/online.html

    Следующие три статьи являются прекрасным отправным пунктом для построения безопасных серверов Solaris.

    "Минимизация операционного окружения Solaris для целей безопасности: простая, легко повторяемая и безопасная методология установки приложений" ("Solaris Operating Environment Minimization for Security: A Simple, Reproducible and Secure Application Installation Methodology"), написанная Алексом Ноордерграафом (Alex Noordergraaf) и Кейт Уотсон (Keith Watson). Хотя данная статья прежде всего описывает требования Web-сервера iPlanet, к использованию Apache, Domino или других Web-серверов предъявляются аналогичные требования.

    "Безопасность операционного окружения Solaris" ("Solaris Operating Environment Security"), написанная Алексом Ноордерграафом и Кейт Уотсон. Это обзор общих настроек безопасности сервера Solaris. В эту статью вошли некоторые особенности SPARC-архитектуры; тем не менее большая часть материала применима и к архитектуре Intel®.

    "Сетевые настройки операционного окружения Solaris, влияющие на безопасность" ("Solaris Operating Environment Network Settings for Security"), написанная опять же Алексом Ноордерграафом и Кейт Уотсон, – еще одна превосходная статья о настройке ядра и о влияющих на сетевую безопасность параметрах приложений.

    На самом деле Blueprints Online компании Sun – настоящий кладезь документации, описывающей все самое лучшее об операционном окружении Solaris, будь то Web-сервер в DMZ, брандмауэр или внутренний широкодоступный кластер Domino.

    У Ланса Шпицнера (Lance Spitzner) тоже есть замечательный документ об укреплении Solaris, в котором для построения брандмауэра Check Point FireWall-1 детально описывается процесс укрепления на нескольких последних версиях Solaris (вплоть до версии 8) под платформы Intel и SPARC. Настоящий документ находится по следующему URL:

    http://www.enteract.com/~lspitz/armoring.html

    И наконец, для Solaris тоже есть эквивалент укрепляющих сценариев Bastille-Linux, который называется TITAN. Проект TITAN и документация по нему находятся по следующему URL:

    http://www.fish.com/titan/

    9.4.8 Настройка сетевых конфигураций для целей безопасности

    Для защиты от наиболее общих атак WAN-соединений, брандмауэра и DMZ-серверов организации надо выполнить следующие простые шаги, чтобы запретить определенную функциональность TCP/IP.

    Сброс трафика с явной маршрутизацией

    Фактически есть две формы трафика с явной маршрутизацией: жесткий (Strict SourceRouted) и свободный (Loose Source-Routed). Данное отличие не играет роли, поскольку лучше сбрасывать весь трафик с явной маршрутизацией.

    Traceroute – самая известная команда, использующая явную маршрутизацию. Она позволяет провести диагностику проблемных мест в сети посредством прямого определения маршрута, по которому будут следовать контрольные пакеты.

    К сожалению, возможные взломщики могут использовать явную маршрутизацию для попытки обхода правил брандмауэра и фильтров TCP/IP. Сброс трафика с явной маршрутизацией следует осуществлять на граничных маршрутизаторах и на любых несущих шлюзах безопасности:

    в Solaris используйте следующую команду:

    ndd -set /dev/ip ip_forward_src_routed 0

    в GNU/Linux используйте команду

    echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

    Сброс направленного широковещательного трафика

    Атака Smurf типа отказа от обслуживания и подобные ей могут быть побеждены простым запретом направленного широковещания (direct broadcast) на границах маршрутизаторов и серверов, открытых Интернету:

    для Solaris используйте следующую команду:

    ndd -set /dev/ip ip_forward_directed_broadcasts 0

    Игнорирование эха широковещательных запросов ICMP (ICMP echo)

    Существует draft RFC, называемый draft-vshah-ddos-smurf-00, который находится по следующему URL-адресу:

    http://www.ietf.org/internet-drafts/draft-vshah-ddos-smurf-00.txt

    В нем утверждается, что, если в сетевом узле установлено отвечать на IP ICMP-эхо по широковещательным или множественным (multicast) адресам, узел должен убедиться в том, что адрес отправителя находится в локальной по отношению к сетевому узлу сети. Если адрес отправителя нелокален, ответ должен быть отброшен. Изменение поведения, чтобы вообще не отвечать на широковещательные сообщения ICMP, гарантирует, что ответы будут отбрасываться всегда:

    в Solaris используйте следующую команду:

    ndd -set /dev/ip ip_respond_to_echo_broadcast 0

    в GNU/Linux используйте следующую команду:

    echo 1 > /proc/sys/net/ipv4/icmp_echo_ ignore_broadcasts

    В GNU/Linux имеется дополнительный элемент управления для запрещения вообще всех запросов на эхо-ответы ICMP. Вызов следующей команды заставит ядро Linux игнорировать все запросы эха ICMP:

    echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

    Игнорирование ICMP-сообщений о перенаправлении (ICMP redirect)

    Предполагаемый взломщик мог бы попытаться перенаправить трафик с серверов организации к другому, а то и вообще к несуществующему шлюзу. Кроме того, предполагаемый взломщик мог бы попытаться вставить фальшивые маршруты в таблицу маршрутизации сервера.

    Все это может быть выполнено посредством скромного ICMP-сообщения о перенаправлении, и это очень эффективная атака типа отказа от обслуживания. Помимо блокирования ICMP-сообщений перенаправления на брандмауэре, если конечно операционная система поддерживает, следует ввести следующие дополнительные уровни защиты для игнорирования ICMP-сообщений о перенаправлении:

    в Solaris используйте следующую команду:

    ndd -set /dev/ip ip_ignore_redirect 1

    в GNU/Linux команда будет такой:

    echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

    Запрещение отправки ICMP-сообщений о перенаправлении

    Только маршрутизаторам требуется отправка ICMP-сообщений о перенаправлении. Поскольку DMZ-серверы и брандмауэр организации не занимаются маршрутизацией каких бы то ни было пакетов, совершенно нет причин отправлять их:

    в Solaris используйте следующую команду:

    ndd -set /dev/ip ip_send_redirects 0

    в GNU/Linux команда будет такой:

    echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

    Широковещательный запрос на временной штамп

    ICMP-запрос на штамп времени (ICMP type 13) позволяет одной системе запросить другую о текущем времени. Возвращаемое значение – количество миллисекунд с полуночи.

    ICMP-запросы на временной штамп используются для синхронизации часов между системами вместо использования команды rdate из-за лучшей точности.

    Индивидуальные запросы на штамп времени – это стандартная практика, но нет никакой необходимости системе отвечать на широковещательные запросы. В конце концов для синхронизации времени между серверами следует рассмотреть вариант использования NTP, поскольку для поддерживания времени оно намного лучше и, кроме того, поддерживает аутентификацию и совместную обработку нескольких источников, что делает его намного более устойчивым к фальсификации. Это дает возможность отказаться от использования ICMP типа 13 (запрос на временной штамп) и типа 14 (ответ о временном штампе) совершенно.

    В Solaris используйте следующую команду:

    ndd -set /dev/ip ip_respond_to_timestamp_ broadcast 0

    9.4.9 Удаленный сервер ведения журналов

    Одна из многочисленных техник, которые используются предполагаемыми взломщиками для скрытия своего присутствия, – это очистка любых средств журналирования, которые могут (и даже должны) быть включены. Сюда входит: ведение журнала учетных записей, системные сообщения, записи об ошибках, слежение за трафиком и т. п.

    Один из способов обойти эту проблему – вести журналы всех серверов организации на отдельной удаленной машине. Этой удаленной машине по ведению журналов следует принимать только журнальный трафик с этих серверов. Таким образом, даже если какой-то сервер был взломан, все равно останутся записи журналов для дальнейшего анализа того, что произошло.

    На журнальном сервере следует соответствующим образом настроить пакетный фильтр для отбрасывания любого трафика, кроме UDP/514. Журналы на журнальном сервере могут, помимо прочего, еще и архивироваться на съемные носители, такие ,как CD-R, WORM, или магнитную ленту.

    В UNIX имеется очень мощная централизованная система ведения журналов. Действительно, некоторые приложения ведут свои собственные файлы журналов и не пользуются syslog. Тем не менее сама иерархия файловой системы разработана с поддержкой централизованного размещения, /var/log.

    Кроме того, большинство систем UNIX и дистрибутивов GNU/Linux поставляются с автоматизированной системой ротации и управления журналами. Журналы автоматически ротируются на основании таких критериев, как размер или возраст, и могут автоматически же сжиматься (компрессироваться), переименовываться и даже архивироваться.

    Чтобы еще сильнее улучшить журнальные возможности сервера UNIX или GNU/Linux, следует стандартный syslogd заменить на более прочную, настраиваемую и безопасную альтернативу, известную как syslog-ng. В ней имеются несколько значительных улучшений по сравнению со стандартным syslogd, куда входит возможность фильтрации сообщений на основании их содержимого, а не только пар facility.priority (источник.приоритет).

    При помощи регулярных выражений информация об отдельных хостах может сохранятся в индивидуальных журналах. Syslog-ng, вероятно, уже входит в поставку операционной системы UNIX или дистрибутива GNU/Linux. Если же нет, его можно найти по следующему URL:

    http://www.balabit.hu/en/products/syslog-ng/

    На этом завершается наше обсуждение укрепления операционных систем UNIX и дистрибутивов GNU/Linux. Хотя данный материал также применим и к AIXНапример, настроить сетевую подсистему, как было показано в разделе 9.4.8, в ОС AIX можно при помощи команды "no"., в AIX присутствуют некоторые уникальные особенности, о которых будет рассказано отдельно в следующем разделе.

    9.5 Укрепление операционной системы AIX

    AIX – это открытое операционное окружение UNIX, которое обеспечивает повышенные уровни целостности, гибкости и надежности, что является существенным для удовлетворения высоких потребностей современных приложений электронного бизнеса. Такой фокус на многогранности позволяет AIX использоваться в широчайшем спектре различных задач, от работы на симметричной мультипроцессорной системе, способной обрабатывать тысячи транзакций в минуту, до запуска на отдельностоящей рабочей станции, используемой для разработки приложений.

    Поскольку одно из предназначений AIX состоит в достижении должного уровня многогранности и производительности, многие службы становятся доступными немедленно, едва только завершится процесс установки операционной системы. Но, с другой стороны, подобный подход может привести к такой конфигурации, которая будет уязвима для прорех безопасности, если систему не отконфигурировать надлежащим образом.

    Для минимизации числа возможных дыр безопасности администратор системы AIX должен быть способен идентифицировать рабочие характеристики окружения.

    В данном разделе приводится информация по укреплению AIX, но это не означает, что он должен стать единственным источником информации обо всех вопросах безопасности относительно систем AIX, например по использованию протоколов Lightweight Directory Access Protocol (LDAP) или Internet Protocol Security (IPSec). За информацией по этим и другим вопросам обращайтесь к соответствующим источникам документации, перечисленным на Web-странице IBM AIX по адресу:

    http://www-1.ibm.com/servers/aix/library/index.html

    Информация этого раздела включает в себя выработку адекватных правил составления пароля, реализацию соответствующих механизмов пользовательской безопасности, разрешение системного аудита и наблюдение за доступом к каталогам и файлам. Также затрагиваются важные вопросы безопасности X11 и CDE наряду с тем, как идентифицировать открытые коммуникационные порты и перечислить открытые файлы.

    Во время прочтения данного материала, описывающего потребности безопасности сервера AIX, важно определить те файлы, которые нуждаются в модификации, и сделать их резервные копии. Вообще резервное сохранение модифицированных файлов – всегда хорошая идея, поскольку оно позволяет вам в любой момент вернуться к предыдущей конфигурации, если возникает необходимость восстановить предыдущие настройки безопасности. После того как модификация завершена, как следует протестирована и все работает так, как запланировано, резервные файлы следует сохранить в безопасном месте вне только что защищенной системы, например на сервере резервного хранения. Такая мера предосторожности воспрепятствует неавторизованному восстановлению предыдущей конфигурации, которая бы свела к нулю все сделанные модификации по укреплению системы.

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

    9.5.1 Удаление информации с экранов регистрации

    Со стандартного по умолчанию экрана регистрации (login) AIX предполагаемые взломщики могут получить ценнейшую информацию, такую, как имя хоста и версия операционной системы. Подобная информация позволит им определить, какие существующие "дыры" можно попробовать. Так что лучше будет не отображать некоторой информации на экранах регистрации.

    Это делается редактированием параметра herald в файле /etc/security/login.cfg.

    По умолчанию он содержит приветственное сообщение, которое отображается вместе с приглашением к регистрации AIX. Для изменения этого параметра можно использовать команду chsec или непосредственно отредактировать сам файл. Далее пример применения команды chsec:

    # chsec -f /etc/security/login.cfg -a default -herald
"Only authorized use of this system is allowed.\n\nlogin: "

    Для непосредственного редактирования содержимого файла откройте файл /etc/security/login.cfg и измените параметр herald следующим образом:

    default:
herald ="Only authorized use of this system is allowed.\n\nlogin:"

    Изменение экрана регистрации CDE

    Данный вопрос безопасности не обошел и пользователей CDE (Common Desktop Environment). Экран регистрации CDE по умолчанию тоже выводит имя хоста и версию операционной системы. Чтобы помешать отображению такой информации, отредактируйте файл /usr/dt/config/$LANG/Xresources, где переменная $LANG ссылается на местный язык, установленный на машине с AIX.

    Защита неиспользуемых терминалов

    Для защиты от неавторизованного доступа неиспользуемый терминал всегда следует запирать. Оставление системного терминала незащищенным представляет собой потенциальную угрозу безопасности. Терминал просто можно запереть командой lock или, если пользовательским интерфейсом является AIX windows, командой xlock.

    9.5.2 Усиление пользовательской безопасности

    Чтобы достичь должного уровня безопасности на сервере AIX, для управления пользовательскими учетными записями следует создать непротиворечивую политику безопасности. (На самом деле это относится ко всем операционным системам, не только к AIX.)

    Безопасность пароля

    Угадывание паролей – одна из самых распространенных хакерских атак, которым подвергаются системы. Поэтому необходимы контроль и наблюдение за политикой ограничения паролей. У AIX есть механизмы для поддержания жесткой парольной политики, такие, как установление значений для следующего:

  • минимальное и максимальное число недель, которые могут пройти до и после того, как пароль может быть изменен;
  • минимальная длина пароля;
  • минимальное число символов алфавита, которые могут быть использованы при выборе пароля.
    •

    Помимо этих механизмов, можно установить даже более жесткие правила, ограничивая пароли тем, чтобы в них не содержались стандартные слова UNIX, которые могут быть взломаны. Данная функциональная возможность использует dictionlist (словарный список), для которого требуется, чтобы первоначально были установлены файлы bos.data и bos.txt.

    Для вызова dictionlist добавьте следующую строку в файл /etc/security/users:

    dictionlist = /usr/share/dict/words

    Теперь для предотвращения использования в качестве пароля стандартных UNIX-слов dictionlist будет применять файл /usr/share/dict/words.

    Запрещение входа под именем root

    Одним из наиболее распространенных методов возможных взломщиков является получение пароля суперпользователя, или пользователя с именем root. Для избежания подобного вида атак можно вообще запретить прямой доступ к ID root и потребовать от администраторов системы AIX получать привилегии при помощи команды su.

    Помимо разрешения на удаление пользователя root как точки приложения атак, ограничение прямого доступа к root позволит вам отслеживать, какие пользователи получили суперпользовательский доступ, а также время их активности. Эту информацию можно получить просмотром файла /var/adm/sulog. Другой альтернативой будет разрешить системный аудит, который тоже будет сообщать о подобном виде активности.

    Для запрещения удаленного входа для пользователя root отредактируйте файл /etc/security/user. В качестве значения переменной rlogin для записи root поставьте "false".

    До запрещения удаленного входа для root очень важно изучить и выработать планы на ситуации, которые помешали бы администратору системы AIX войти под ID-пользователя, отличного от root. Например, если домашняя файловая система пользователя заполнена, пользователь не сможет войти в систему. Если удаленный вход для root запрещен и если у пользователя, который мог бы при помощи su стать root, домашняя файловая система переполнена, то root никогда не сможет получить контроль над системой. Системные администраторы такую проблему могут обойти, просто создав для себя домашние файловые системы, большие, чем файловые системы обычного пользователя.

    Принудительное автоматическое отключение

    Еще один значительный вопрос безопасности происходит из того, что пользователи оставляют свои учетные записи без присмотра на продолжительные периоды времени. Подобная ситуация дает возможность предполагаемому взломщику заполучить контроль над пользовательским терминалом, потенциально компрометируя безопасность системы.

    Для предотвращения такого типа потенциальной угрозы безопасности можно включить автоматическое отсоединение от системы. Чтобы сделать это, отредактируйте файл /etc/security/.profile и впишите значения времени автоматического отсоединения для всех пользователей, как в следующем примере:

    TMOUT=300 ; TIMEOUT=300 ; export readonly TMOUT TIMEOUT

    В этом примере 300 – число секунд, что эквивалентно 5 минутам.

    Хотя предыдущее действие введет политику автоматического отсоединения для всех пользователей, тем не менее пользователи системы смогут обойти некоторые ограничения редактированием своих собственных индивидуальных файлов профиля. Для того же, чтобы ввести политику автоматического отключения целиком и полностью, следует предпринять авторитетные действия, снабдив пользователей соответствующими файлами профилей и убрав права на запись в эти файлы. Это действие гарантирует, что только root сможет изменить переменную окружения, INTERNAL FIELD SEPARATOR (IFS), которая берется некоторыми программами, такими, как sed, awk и cut, из файлов профиля.

    Запрещение групповых и внешних прав доступа на файлы

    Еще одна мера, которая ведет к очень прочной безопасности, – это установить по умолчанию запреты на групповые и внешние разрешения пользовательских файлов. Это можно сделать установлением значения umask для учетной записи пользователя в 077.

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

    Замечание. На машинах SP во время установки значение umask следует устанавливать в 022. Значение umask по умолчанию для нового пользователя тоже устанавливается в 022. Для повышения уровня безопасности важно после завершения установки не забыть изменить это значение на 077. Его можно задать в разделе значений по умолчанию файла etc/security/user.

    Скрытие пользовательских имен и паролей

    Чтобы добиться очень высокого уровня безопасности, убедитесь, что пользовательские ID и пароли не видны изнутри системы. ID и пароли пользователей находятся в файле .netrcЭти файлы могут создаваться пользователями. Подробнее описано в документации по ОС AIX.. Эти файлы не защищены ни шифрованием, ни каким бы то ни было кодированием, а значит, их содержимое ясно отображается в виде обычного текста.

    Чтобы найти эти файлы, запустите следующую команду:

    # find 'awk -F: '{print $6}' /etc/passwd' -name .netrc –ls

    После того как данные файлы были найдены, их следует удалить. Более эффективным способом хранения паролей будет установка Kerberos.

    Установка опций пользовательского пароля

    Табл. 9.2 приводит рекомендуемые значения для некоторых атрибутов безопасности, относящихся к пользовательским паролям. Парольные опции находятся в файле /etc/usr/securityЗдесь ошибка: имеется в виду файл /etc/security/user ..

    Данный файл можно редактировать для введения каких-либо значений по умолчанию, которые требуется определить для администрирования пользовательских паролей. В качестве альтернативы можно применять команду chsec (заметьте, что значения, представленные в нижеследующей таблице, взяты из книги "IBM Redbook AIX Security Tools, SG24-5971-00").

    Парольные опции
    Атрибут Описание Рекомендуемое значение
    dictionlist Проверяет, не входят ли в пароль стандартные слова UNIX /usr/share/dict/words
    histexpire Количество недель, после которых пароль может быть использован повторно 26
    histsize Число допустимых парольных итераций 20
    maxage Максимальное число недель до того, как пароль должен быть в обязательном порядке изменен 4
    maxexpired Максимальное число недель после maxage, когда просроченный пароль еще может быть изменен пользователем 2
    maxrepeats Максимальное число повторений одного и того же символа в пароле 2
    minage Минимальное число недель до того, как пароль может быть изменен 1В документации по безопасности обычно рекомендуется устанавливать это значение в 0, т. е. пароли можно менять так часто, как это потребуется.
    minalpha Минимальное число алфавитных символов, которые должны содержаться в пароле 2
    mindiff Минимальное число отличающихся друг от друга символов, которые должны содержаться в пароле 4
    minlen Минимальная длина пароля 6 (8 для пользователя root) minother Минимальное число неалфавитных символов, которые должны содержаться в пароле 2
    pwdwarntime Число дней до окончания срока действия пароля, за которое система начинает выдавать предупреждение о том, что пароль должен быть изменен 5

    Подтягивание значений по умолчанию системных параметров входной регистрации

    Для установки базовых значений по умолчанию для многих параметров входной регистрации, вроде тех, которые могли бы быть установлены для нового пользователя (например, число попыток входа, повторное разрешение регистрации и регистрационный интервал), следует отредактировать файл etc/security/login.cfgФайл /etc/security/login.cfg..

    Удаление лишних пользовательских учетных записей, созданных по умолчанию при установке

    Во время процесса установки операционной системы AIX по умолчанию создается некоторое количество ID пользователей и групп. В зависимости от того, какие приложения будут запускаться на данном сервере AIX, и от того, где этот сервер будет располагаться в сети, некоторые из этих ID пользователей и групп могут стать слабыми местами в системе безопасности, уязвимыми для взлома. Если такие ID не нужны, для минимизации связанного с ними риска их можно удалить.

    В табл. 9.3 приведены наиболее общие создаваемые по умолчанию пользовательские ID, которые вы, вероятно, захотите удалить.

    Создаваемые по умолчанию пользовательские ID – кандидаты на удаление
    Пользовательский ID Описание
    uucp, nuucp Владелец скрытых файлов, используемых протоколом uucp
    lpd Владелец файлов, используемых системой печати
    imnadm Поисковый движок IMN [используется поиском по библиотеке документации (Documentation Library Search]
    guest Разрешает доступ тем пользователям, у которых нет доступа к учетным записям

    Аналогично в табл. 9.4 приводятся наиболее общие ID групп, которые, возможно, не понадобятся.

    Наиболее общие групповые ID – кандидаты на удаление
    Групповой ID Описание
    uucp Группа, к которой принадлежат пользователи uucp и nuucp
    printq Группа, к которой принадлежит пользователь lpd
    imnadm Группа, к которой принадлежит пользователь imnadm

    Могут быть и другие ненужные ID пользователей и групп; проанализируйте систему на наличие других ID, которые можно удалить. Прежде чем система "выйдет в свет", проведите всеобъемлющую оценку всех имеющихся ID.

    9.5.3 Определение доступа к доверенному коммуникационному пути

    Trusted Computing Base (Доверенная вычислительная база, TCB) является частью системы, которая отвечает за проведение в жизнь общесистемных политик информационной безопасности. Установкой и использованием TCB можно определить доступ пользователя к доверенному коммуникационному пути (trusted communication path), который предполагает защищенную коммуникацию между пользователями и TCB.

    Функциональные возможности TCB могут быть включены только во время установки системы. Для того чтобы установить TCB на уже готовую машину, нужно выполнить установку в режиме "preservation". Включение TCB дает возможность доступа к доверенной оболочке (trusted shell), к доверенным процессам и к ключу безопасности внимание (Secure Attention Key, SAK).

    Поскольку каждое устройство является частью TCB, каждый файл каталога /dev отслеживается системой TCB. Кроме того, TCB автоматически следит за более чем 600 дополнительными файлами, сохраняя критическую информацию об этих файлах в /etc/security/syschk.cfg. Если TCB установлена, сразу же после установки с этого файла следует снять резервную копию на съемный носитель, такой, как лента, CD или диск, и на носитель, хранимый в безопасном месте.

    9.5.4 Обработка особых ситуаций

    В процессе укрепления своих систем администраторы систем AIX могут столкнуться со множеством различных ситуаций. Данный раздел как раз и проливает свет на подобные особые ситуации.

    Особые разрешения

    Если для каких-либо пользователей и групп устанавливаются особые разрешения, все эти выделенные особые разрешения следует задокументировать и наметить шаги для согласования с вопросами безопасности. Если особые разрешения не задокументированы, другие не будут в курсе этих особых ситуаций и могут пренебречь теми шагами, которые должны быть предприняты.

    Особые привилегии

    При установке нового программного обеспечения, такого, как сервер Domino или сервер DB2, могут возникнуть вопросы в связи с созданием новых учетных записей и выделением особых привилегий для них. Отдавайте себе отчет по всем новым ID, их привилегиям и правам собственности на файлы и папки, чтобы потом не оказалось непреднамеренного обмана политики безопасности организации.

    Особые пароли

    Пароль на включение питания. Данный пароль, если установлен, препятствует кому бы то ни было перезагружать сервер простым его выключением из сети питания и затем включением вновь. Если в CD-ROM-привод вставлен загрузочный CD-носитель, система перезагружается, а затем уже будет грузиться с CD и, следовательно, не станет придерживаться своей безопасной конфигурации, что приводит к нарушению режима безопасности. Если система перезагружается и если пароль на включение питания установлен, во время цикла перезагрузки система потребует ввести этот пароль. Это может повлиять на действующие соглашения об уровне сервиса (Service Level Agreements, SLAs), так как может быть определенная задержка по времени между моментом, когда сервер перезагружается до точки запроса пароля на включение питания, и моментом, когда ему будет позволено продолжать свою загрузочную последовательность после того, как пароль был введен. В идеале первостепенность будет установлена политикой безопасности организации (безопасность против соглашений по предоставлению услуг).

    Пароль супервизора. Данный пароль не дает неавторизованному пользователю загрузиться в режим поддержки при помощи загрузочного носителя (загрузочный CD, mksysb лента/CD). Загрузка с подобного носителя предоставляет полный доступ к файлам и каталогам абсолютно без ограничений в плане безопасности. Пароль супервизора закрывает систему, и, если этот пароль утерян, понадобится помощь обслуживающего персонала IBM для того, чтобы отпереть ее.

    Пароль root. Это пароль суперпользователя, который время от времени может быть нужен. Важно отдавать себе отчет в том, когда действительно может понадобиться учетная запись root, и на такие случаи в реализации системы безопасности организации должны присутствовать планы.

    Слабые места системы безопасности

    Каждому хорошему системному администратору AIX следует быть осведомленным о тех системах в ИТ-инфраструктуре организации, в которых могут иметься слабые места для общей системы безопасности. Если предполагаемый взломщик взломает одну из машин, находящихся внутри сети организации, он может получить доступ и к другим машинам посредством разрешений, установленных между данной машиной и другими системами в сети.

    Некоторые из предполагаемых взломщиков сканируют сети на наличие определенного типа машин и определенных версий операционных систем с целью найти какую-нибудь одну такую, которую можно было бы взломать, а затем они могут использовать эту точку входа для получения доступа ко всем машинам в сети.

    9.5.5 Разрешение системного аудита

    Пользователи регулярно производят различные системные действия, за которыми не мешало бы наблюдать более тщательно. Установкой системного аудита дается возможность записывать касающуюся безопасности информацию, которая затем может быть проанализирована на факт наличия потенциальных и фактических нарушений системной политики безопасности.

    Предопределенные события аудита можно найти в файле /etc/security/audit/events. Для генерации регулярных отчетов при помощи возможностей службы cron можно установить автоматическое ведение аудита.

    9.5.6 Слежение за файлами, каталогами и программами

    Наше обсуждение укрепления было бы неполным без рассмотрения механизмов, которые можно использовать для наблюдения за доступом к файлам, каталогам и исполняемым программам.

    Удаление устаревших файлов

    Время от времени появляется необходимость в удалении нежелательных и ненужных файлов с сервера AIX.

    AIX предоставляет системному администратору команду skulker, которая может автоматически отследить и удалить устаревшие файлы. Кандидатами на обработку данным средством являются файлы, расположенные в каталоге /tmp, исполняемые файлы a.out, файлы core и ed.hup. Для запуска команды skulker введите в командную строку следующее:

    # skulker -p

    Вы можете автоматизировать команду skulker, заставив cron регулярно выполнять данную задачу.

    Удаление файлов, не имеющих владельца

    Когда ID пользователя удаляется, файлы этого пользователя больше не имеют владельца, приписанного к ним. Для нахождения файлов, не имеющих владельца, используйте команду find так, как показано ниже:

    # find / -nouser -ls

    После идентификации файлов без владельца определите, нужны ли еще эти файлы. Если нужны, их следует приписать другому пользователю. В противном случае эти файлы можно удалить из системы.

    Управление неавторизованным удаленным доступом к хосту

    Для получения доступа к системе некоторые программы используют файл .rhosts. В некоторых случаях доступ может быть предоставлен и неавторизованным пользователям. Для избежания подобной ситуации файл .rhosts следует удалить с сервера AIX.

    Для кластеров HACMP файлы .rhosts нужныВ HACMP 5.x этот файл больше не нужен.. В таких конфигурациях вместо удаления этим файлам следует установить разрешения 600 и назначить права собственности root.system.

    Для нахождения файлов .rhosts запустите следующую команду:

    # find / -name .rhosts -ls

    Слежение за исполняемыми файлами

    Для слежения за активностью исполняемых файлов особой важности требуется хорошее понимание того, как эти файлы используются. Исполняемые файлы, за которыми требуется наблюдение, – это те файлы, которые принадлежат пользователю root и у которых установлен хотя бы один из битов SUID и SGID.

    После тщательного наблюдения за этими файлами во время нормальной работы системы можно составить отчет, в который будет входить список файлов, которые работают нормально. Затем этот отчет можно сверить с последующими отчетами, что выявит все новые файлы, атрибуты которых были выставлены без ведома системного администратора AIX. Для создания шаблонного отчета воспользуйтесь следующими командами:

    # find / -perm -4000 -user 0 -ls
# find / -perm -2000 -user 0 -ls

    Управление задачами cron и at

    Для управления задачами cron и at проделайте следующее. Убедитесь в том, что единственным пользователем, упоминающимся в файлах cron.allow и at.allow, является root.

    Из каталога /var/adm/cron удалите cron.deny и at.deny.

    Убедитесь в том, что задачи cron и at принадлежат пользователю и могут выполняться только им root.

    9.5.7 Управление тем, что относится к X11 и CDE

    В этом разделе рассказывается о потенциальных "дырах" безопасности, пришедших вместе с X-сервером X11 и с окружением CDE (Common Desktop Environment).

    Удаление файла /etc/rc.dt

    Хотя запуск графического пользовательского интерфейса CDE и удобен для пользователей, с ним связаны некоторые проблемы для безопасности. По этой причине CDE не следует запускать на серверах, для которых требуется высокий уровень безопасности.

    Самым лучшим решением было бы вообще избегать установки файловых наборов CDE (dt). Если же данные наборы все-таки были установлены на сервер, следует рассмотреть вопрос их удаления, особенно сценария /etc/rc.dt, который запускает CDE.

    Предотвращение неавторизованного слежения за удаленным X-сервером

    Важный вопрос безопасности, связанный с сервером X11, – это неавторизованное тихое слежение за удаленным сервером. Для слежения за работой X-сервера могут быть использованы команды xwd и xwud, поскольку они обладают возможностью перехватывать нажатия клавиш, что может раскрыть пароли и другие важные данные. Для решения данной проблемы либо просто удалите эти исполняемые файлы, если они не нужны для текущей конфигурации сервера, либо разрешите доступ к этим командам только пользователю root.

    Команды xwd и xwud можно найти в файловом наборе X11.apps.clients.

    Если команды xwd и xwud нужно оставить, подумайте об использовании OpenSSH или MIT Magic Cookies. Эти приложения сторонних производителей помогут предотвратить риск, связанный с запуском команд xwd и xwud.

    Разрешение и запрещение контроля доступа

    X-сервер дает возможность удаленным хостам использовать команду xhost+ для соединения с сервером AIX. Убедитесь, что вместе с командой xhost+ задано и имя хоста, потому что иначе контроль доступа для данного X-сервера будет запрещен. Это разрешит предоставление доступа к конкретным хостам, которые облегчат слежение за потенциальными атаками на X-сервер. Для предоставления доступа к конкретным хостам запустите команду xhost следующим образом:

    # xhost + имя хоста

    Запрещение пользовательских разрешений для запуска команды xhost

    Еще один способ гарантировать то, что команда xhost используется должным образом, – это ограничить выполнение этой команды только при наличии полномочий суперпользователя. Для этого воспользуйтесь командой chmod и измените разрешения файла /usr/bin/X11/xhost на 744, как показано ниже:

    # chmod 744/usr/bin/X11/xhost

    Убедитесь, что вместе с командой xhost задано имя хоста. Это разрешит предоставление доступа к конкретным хостам, которые упрощают слежение за потенциальными атаками на X-сервер.

    Замечание. Если имя хоста не задано, доступ будет предоставлен всем хостам.

    9.5.8 Запрещение ненужных служб

    В этом разделе обсуждаются открытые коммуникационные порты, как их можно идентифицировать и как закрыть.

    Определение сетевых служб с открытыми коммуникационными портами

    Клиент-серверные приложения открывают на сервере коммуникационные порты, позволяя приложениям слушать входящие запросы клиентов.

    Поскольку открытые порты – потенциальные кандидаты для атаки, определите, какие приложения открыли порты; но совсем не обязательно закрывать все порты, которые открыты. Это упражнение полезно уже тем, что дает системным администраторам возможность понять, что системы являются доступными любому, у кого есть доступ к Интернету.

    Для определения того, какие порты открыты, проделайте следующее.

    Идентифицируйте службы при помощи команды netstat:

    # netstat -af inet

    Результат работы данной команды достаточно ясен для интерпретирования. Последний столбец вывода команды netstat обозначает состояние каждой службы.

    После определения того, какие службы в настоящий момент слушают, откройте файл /etc/services и проверьте его при помощи служб центра по присвоению номеров Интернета (Internet Assigned Numbers Authority, IANA) для постановки в соответствие службы номеру порта внутри операционной системы.

    Закройте ненужные порты удалением запущенных служб.

    Составление списка открытых файлов

    Полезно определить TCP-сокеты, которые находятся в состоянии LISTEN, и ненагруженные UDP-сокеты, которые ожидают получения данных.

    Для этой цели воспользуйтесь командой lsof, которая является вариантом команды netstat -af. Команда lsof входит в AIX 5.1 и находится на диске "AIX Toolbox for Linux Applications CD".

    Например, чтобы вывести на экран TCP-сокеты, находящиеся в состоянии LISTEN, и UDP-сокеты, находящиеся в состоянии IDLE, запустите команду lsof следующим образом:

    # lsof -i | egrep "COMMAND|LISTEN|UDP"

    После определения ID процесса можно получить более подробную информацию о самой программе, выполнив следующую команду:

    " # ps -fp PID#"

    Вывод будет содержать путь к имени команды, который можно использовать для доступа к man-странице данной программы.

    9.6 Резюме

    В этой лекции мы рассмотрели инструменты и техники, используемые для защиты ИТсистем и предотвращения атак.

    Мы дали подсказки по укреплению операционной системы, рассказали об инструментах и программах, используемых для создания сплошной защиты, а также о методах профессионалов безопасности по сбору сведений в тех случаях, когда взломщики пробили внешнюю защиту.

    Предоставленная нами информация может принести пользу организации любого размера, от маленькой домашней фирмы до очень большой организации с офисами по всему миру.

    Хотя самое важное, что нужно запомнить, – это то, что нет 100 % надежных ИТ-систем в течение 100 % времени.

    Таким образом, важно еще понять, что, как только система – и ее безопасность – на месте, начинается следующая фаза работы по обеспечению безопасности. То есть время наблюдать за ИТ-системой и определять, какие еще улучшения могут быть внесены в систему для продолжения и совершенствования ее безопасности, а также для поддержания целостности и конфиденциальности содержащейся в ней информации. Тогда и только тогда будет иметь место надлежащая и адекватная безопасность.

    Страницы:

    Защита операционной системы осуществляется посредством процесса, называемого укреплением (hardening), в котором берется стандартная "боксовая" конфигурация (т. е. та, которая поставляется производителем для процесса установки со значениями параметров, выставленными по умолчанию) и закрываются все известные уязвимые места и потенциальные "дыры" безопасности файловой системы, фоновых служб и конфигурации сетевых служб.

    В этой лекции мы рассмотрим "укрепление" тех операционных систем, на которых обычно Lotus-технологии и работают, а именно:

  • Windows (с ядром NT)-операционные системы:
  • Win32 – Windows NT4.0, Windows 2000 и Windows XP;
    •
  • UNIX/Linux-операционные системы:
  • Sun Solaris – версия 8;
  • Linux (ядро 2.4) – SuSe и Red Hat;
  • IBM AIX.

    • Наше обсуждение коснется рабочих станций, так же как и серверов, поскольку вопросы безопасности включают в себя все аспекты инфраструктуры, а не только ее наиболее видимых частей.

    9.1 Основные принципы "укрепления"

    В этом разделе мы объясним некоторые фундаментальные принципы "укрепления". Необходимо понимать эти основы до того, как мы сможем обсуждать реальное "укрепление" ИТ-системы организации.

    9.1.1 Начнем с операционной системы

    Если и существует наилучшее место, с которого следует начинать процесс "укрепления", так это операционная система. Это связано с тем, что ОС представляет собой ядро ИТ системы. В конце концов, именно ОС отвечает за то, чтобы пользователи были надежно аутентифицированы и контролировались. К счастью, "укрепление" ОС – не сложная задача, хотя первичные действия могут показаться утомительными. В этой лекции мы сделаем обзор общих методов и концепций, которые можно использовать для "укрепления" любой ОС.

    С того самого момента, как только планируется установка ОС, безопасности следует придавать наивысший приоритет. К сожалению, этого часто не происходит, результатом чего являются неполноценные установки, что в конечном итоге приводит к скомпромитированным системам. Следующие разделы описывают в общих чертах те шаги, которым надо следовать каждому администратору или пользователю во время установки.

    Делайте изолированную установку

    Во время установки ОС она должна быть физически отсоединена от любой сети, особенно от Интернета. Хотя результаты статистики варьируются в зависимости от того, кто предоставляет их, подсчитано, что установка ОС по умолчанию, будь то Windows или Linux, будет просканирована и взломана в течение часа после подсоединения к Интернету. К сожалению, для установки всех корректных патчейПатч – заплатка, набор исправлений и улучшений. безопасности часто требуется больше времени, чем это.

    Ирония в том, что этим самым операционным системам требуется тем или иным способом быть подключенными к Интернету для того, чтобы иметь возможность загрузить необходимые патчи безопасности. Решение этой проблемы – использовать отдельную машину для загрузки необходимых патчей и затем применять эти загруженные патчи к той машине, на которой происходит новая установка.

    Закрывайте ОС

    Существует почти 100% вероятность, что установка "по умолчанию" приведёт к тому, что такая машина, или конфигурация, будет иметь как минимум одно уязвимое место, которое может быть использовано взломщиком для получения неавторизированного доступа.

    Чтобы помешать этому, администратору следует быть готовым к установке всех подходящих патчей и обновлений. Это означает знание наперед, какие основные обновления доступны для данной ОС. Обновления часто бывают в форме пакетов обновлений (service pack) или обновленных релизов, которые доступны в пригодном для загрузки формате, что позволяет подготовить необходимые обновления на записываемом CD (компакт-диске) или ленте еще до установки.

    После того как ОС с текущими обновлениями установлена, важно поддерживать ее в состоянии, всегда соответствующем последним обновлениям и исправлениям. Службы обновления предлагаются большинством производителей ОС (такие, как утилита up2date компании Red Hat и Windows Update Tool компании Microsoft). Эти инструменты должны использоваться с осторожностью, и вам следует понимать, что именно сделает с системой конкретный патч, полученный при помощи такой утилиты, до того, как он будет установлен.

    Закрывайте службы

    Операционная система – это лишь небольшая часть ИТ-системы. Подключенные дополнительные службы могут дать дополнительную функциональность, не входящую в "боксовую" конфигурацию, но, с другой стороны, могут стать причиной некоторой головной боли в плане безопасности. Например, одна из наиболее известных таких служб для ОС Windows Server – Internet Information Server (IIS, Информационный сервер Интернета), который стал источником огромного количества хорошо известных "дыр".

    Точно также, как и саму ОС, все службы и программы сторонних производителей на компьютере следует проверять, чтобы гарантировать то, что они самой последней версии и безопасны в использовании. Как это ни странно, но далеко не все системные администраторы понимают этот принцип и предпринимают усилия для удаления нежелательных служб; более того, некоторые даже не знают, какие именно службы запущены на их системах.

    Пока мы в этой лекции разбираемся со специфическими инструментами и методиками, есть быстрый и легкий способ закрыть некоторые уязвимые места – проверить, какие коммуникационные порты "слушают" входящие данные. Это делается при помощи следующей команды в командной строке:

    netstat –an

    Кроме того, инструменты, такие, как Nessus, Nmap и Stealth, могут быстро выдать "снимок" ИТ-системы и того, какие потенциально уязвимые фоновые службы запущены в системе.

    Определите базовый уровень

    После того как ИТ-система пропатчена и закрыта, следующий важный шаг, который следует предпринять до того, как открывать ее миру, – это установить надлежащий базовый уровень для этой ИТ-системы.

    Главным образом это означает, что должна существовать полная документация тех изменений, которые были выполнены с ИТ-системой. Любые изменения, сделанные с базовым уровнем, могут быть проконтролированы, и приняты соответствующие меры безопасности. Этим также устанавливается в организации единый стандарт конфигурации ИТ-систем, и любые необходимые корректировки могут быть сделаны быстро и единообразно, избегая тем самым самого понятия "самое слабое звено". (То есть такой системы, которая значительно отличается своей базовой конфигурацией и в которой нечаянно оставлены открытыми службы и порты. Такая система может быть использована для подготовки атак на другие системы организации.)

    К тому же надлежащая безопасность полагается на соответствующую документацию. Именно по этой причине для организации должен существовать соответствующий ПСОНМ (политики, стандарты, общее направление мероприятий) (PSPG – Policies, Standards, Procedures Guideline) – документ, в котором содержатся детальные описания базовых конфигураций.

    9.1.2 Инструменты защиты и предохранения

    Инструменты защиты – один из самых главных элементов, который обеспечивает буфер безопасности между ИТ-системами и теми людьми, которые пытаются взломать их. Этот инструментарий включает в себя антивирусные сканнеры, фильтры приложений, брандмауэры и другие инструменты.

    Стоит упомянуть, что инструменты защиты только уменьшают вероятность того, что взломщики успешно получат доступ к ИТ-системе. Исходя из того, что существует множество способов проведения атак, вам не следует слишком полагаться на эти инструменты и рассматривать их, скорее, как сдерживающие средства, нежели как средства предохранения от взлома

    Брандмауэры

    Детальное описание брандмауэров, их архитектуры и того, как наилучшим образом их использовать, дано в 4.1, "Инфраструктура компонентов". В этом разделе мы рассмотрим лишь некоторые базовые концепции брандмауэров.

    Брандмауэр – это такое устройство, которое тщательно просматривает входящий сетевой трафик и, опираясь на набор правил, либо пропускает его, либо нет. Брандмауэры, как правило, стоят по периметру сети организации, защищая ее от Интернета, экстранета и других менее защищенных сегментов сети. Брандмауэр может работать на UNIX, Windows (предпочтительнее с ядром NT) или на любых других операционных системах с программным обеспечением, выполняющим пакетную фильтрацию, которые как минимум укреплены против взлома и имеют несколько сетевых карт для подключения к различным сегментам сети.

    В наши дни брандмауэры стали настолько обыденным явлением, что люди стали чрезмерно полагаться на них, и многие системные администраторы считают, что брандмауэры обеспечивают всю требуемую безопасность сети. Хуже того, некоторые системные администраторы думают, что могут достать брандмауэр из коробки, подключить его, никогда больше на него не смотреть и рассчитывать на то, что он все еще будет защищать их систему.

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

    Фильтры приложений

    Подобно брандмауэрам, фильтры приложений ограничивают поток данных согласно некоторому набору правил. В действительности некоторые устройства совмещают в себе брандмауэр и фильтр приложений. (Примером этого может быть Microsoft ISA Server, о котором подробнее можно узнать на странице http://www.microsoft.com/isaserver/.)

    Однако брандмауэр и фильтр приложений, по сути, совершенно разные вещи, поскольку функционируют на разных уровнях TCP-стека. Вместо отслеживания и управления трафиком на основе IP-адреса и порта (что делают брандмауэры) фильтр приложений контролируют данные, основываясь на используемом программном или коммуникационном протоколе или на фактических данных, передаваемых в пакет.

    Например, если организация хочет ограничить использование P2P служб (к примеру, таких пиринговых клиентов, как KaZaa, Morpheus, eDonkey и т.д.), между брандмауэром и внутренней сетью следует установить фильтр приложений. Этот сервер приложений затем может быть отконфигурирован так, чтобы блокировать все запросы к таким P2P службам. Обычному HTTP трафику было бы позволено проходить, но весь файлообмен, основанный на службах P2P, блокировался бы.

    Помимо управления службами, фильтры приложений часто используются для блокирования доступа пользователей к сомнительным или нелегальным Web-сайтам посредством либо проверки URL-адреса в базе данных запрещенных адресов, либо сканирования каждой запрошенной Web-страницы на предмет наличия определенных ключевых слов.

    Хотя фильтры приложений и важны для контроля того, какие данные входят и выходят из сети, тем не менее они ненадежны. Например, Web-сайты могут менять адреса и даже просто быть доступными по IP-адресу, тем самым обходя любые проверки URL-адресов. Кроме того, сайт, не содержащий ни единого слова (только рисунки), мог бы легко обойти проверку и пройти к запросившему пользователю, внезависимости от того, какие рисунки в нем содержатся.

    Системные политики и обучение

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

    К примеру, открытая беспроводная сеть могла бы позволить хакеру полностью обойти все другие защитные устройства и получить свободную власть во внутренней сети.

    Вот почему системные политики и обучение являются ключевыми предохранительными инструментами.

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

    К сожалению, как правило, настолько широко распространено и совершенно лишено смысла то, что у пользователей иногда складывается такое впечатление, будто до тех пор, пока они не раскрывают свой пароль, любая игра будет честной, включая пользование P2P-клиентом и употребление пропускных мощностей организации для обмена музыкальными (или другими) файлами с сотрудниками и, если нет должного уровня безопасности, с внешними людьми.

    Независимо от того как хорошо и всеобъемлюще написана политика безопасности, она бесполезна, если конечный пользователь не читает и не понимает ее. Обязательно прочитайте лекцию 2, "Методики построения систем безопасности", особенно те разделы, в которых говорится о политиках безопасности, о компетентности и обучении пользователей, о проверке на соответствие.

    Сканеры портов

    Сканер безопасности NMap (сокращение от Network Mapper) – замечательный инструмент для укрепления, доступный по следующему URL-адресу:

    http://www.insecure.org/nmap

    NMap – это продукт open sourceOpen source – проект с открытыми исходными программными кодами., доступный для многих почитателей как UNIX, так и Windows (NmapNT). Он позволяет системным администраторам использовать "сырые" IP-пакеты для определения (помимо всего прочего) следующего:

  • какие узлы наличествуют в заданной сети;
  • какие службы (порты) открыты;
  • какая работает операционная система и какой версии;
  • какие используются типы пакетных фильтров и брандмауэры.
    •

    NMap также имеет возможность создавать и отправлять узлу сети фрагментированные пакеты. Используя опцию –f (фрагментирование), можно заставить NMap выполнить сканирование фрагментированными IP-пакетами. В режиме фрагментирования NMap расщепляет TCP-заголовок на несколько пакетов, чтобы усложнить обнаружение сканирования пакетными фильтрами и системами обнаружения вторжения (Intrusion Detection Systems, IDS).

    Хотя этот метод и не сможет одурачить брандмауэры, которые поддерживают целостность пакетов, многие сети не способны справиться с перегрузками при отслеживании фрагментов и, таким образом, не поддерживают этого.

    В конце концов такие инструменты, как Nessus, используют NMap в своем ядре, что делает NMap еще более популярным.

    9.1.3 Резюме по основам укрепления

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

    9.2 Безопасность операционной системы

    Операционная система определяет все то, что может быть сделано с ИТ-системой, и то, каким образом это будет делаться. То ли происходит взаимодействие с файловой системой, то ли отправка электронной почты посредством Lotus Notes, то ли разговор с кем-нибудь через Sametime – за всем этим стоит "закулисная" работа операционной системы по обеспечению пользователя соответствующей технической поддержкой для интерпретации его запросов в нечто такое, с чем ИТ-система способна работать.

    И хотя операционные системы различаются на многих уровнях, наиболее общие из них определяют нечто намного большее, чем простой интерфейс между пользователем и машиной. В них входят программы, дающие пользователю многочисленные дополнительные возможности: от простых скринсейверовСкринсейвер – программа-хранитель экрана. до сложным схем файлового шифрования. Но при этом важно понимать, что все эти программы – именно дополнения, добавленные в ОС и не являющиеся необходимыми для функционирования компьютера.

    Многие пользователи тесно знакомятся с аксессуарами операционной системы (такими, как игры, идущими в комплекте с ОС), но совершенно забывают о тех средствах безопасности, которые входят в поставку, чтобы помочь им поддерживать свою операционную среду надежной и безопасной. В результате многие ИТ-системы так и находятся в небезопасном состоянии, что оставляет их подверженными опасности заражения вирусом или даже полной компрометации взломщиком.

    Данный раздел посвящен вопросам безопасности операционной системы. Его цель – рассказать о таких специальных программах настолько подробно, чтобы процесс их укрепления был легок как для понимания, так и для выполнения. Это важно, поскольку достаточно всего лишь одного вируса или программы-"трояна", чтобы запустить цепную реакцию заражения компьютеров и компрометации ИТ-систем.

    9.2.1 Обзор операционной системы

    Прежде чем углубляться в то, что называется безопасностью в операционной системе, необходимо знать, где же собственно ОС начинается и где заканчивается. Наш краткий обзор описывает функциональность и предназначение операционной системы, а также то, как она используется для создания компьютерного опыта.

    Функции операционной системы

    Кратко говоря, операционная система должна обеспечить выполнение двух основных функций. ОС должна:

  • управлять ресурсами, доступными компьютерной системе;
  • обеспечить приложениям надежный, стабильный, безопасный и совместимый интерфейс для доступа к ресурсам компьютера.
    •

    Первая функция имеет особенно критических характер, поскольку именно она определяет то, каким образом приложения получают доступ к системным ресурсам. Посредством контроля различных аспектов использования аппаратуры и программного обеспечения ОС гарантирует, что каждое приложение получит возможность использовать процессор.

    Вторая функция определяет методы, посредством которых приложение может получить доступ к этим ресурсам. Поскольку ОС зачастую выступает в качестве буфера между выполняющейся программой и аппаратурой, нужны какие-то средства, позволяющие приложениям получать доступ к ресурсам без необходимости знать всю топологию компьютерной системы.

    Виды операционных систем

    Есть четыре основных вида операционных систем, классифицируемых согласно типам программ, которые они поддерживают, и способу взаимодействия этих программ с пользователями:

  • Операционная система реального времени. Наиболее часто такая операционная система встречается в производстве роботов и в научных приборах (хороший пример – QNX). В ней нет много места для пользовательских операций за исключением отдельных изменений в конфигурации. Обычно в такой операционной системе находятся идеально отточенные механизмы работы со временем, поскольку даже самая незначительная ошибка может иметь значительные последствия в автоматическом производстве или измерениях.
  • Однопользовательская однозадачная операционная система. Этот вид операционных систем используется такими устройствами, как PDAPDA – Personal Digital Assistant, личный цифровой секретарь, тип сверхлегкого миниатюрного персонального компьютера с жидкокристаллическим экраном, клавиатурой и/или рукописным вводом. или другие миникомпьютеры (хороший пример – Palm OS). По большей части она позволяет одному пользователю работать с одной программой за один раз. Если требуется запустить еще одну программу, пользователь сначала должен закрыть текущее приложение.
  • Однопользовательская многозадачная операционная система. Этот вид операционных систем известен больше всего, так как к нему относятся и системы Microsoft Windows. В такой операционной системе пользователь может открыть множество программ и переключаться между приложениями так, как ему требуется. Фактически сейчас ведется много дебатов по поводу того, что, хотя Windows Server Operating Systems и выглядят как многопользовательские системы, тем не менее они есть не что иное, как однопользовательские многозадачные операционные системы (за исключением Terminal Services).
  • Многопользовательская операционная система. Истинная многопользовательская операционная система позволяет многим пользователям одновременно получать доступ к компьютерным ресурсам. Общеизвестный пример ОС такого типа – Linux. В системе такого типа ОС обрабатывает запросы от многих пользователей и поддерживает жесткий контроль над ресурсами, чтобы гарантировать то, что ни один пользователь никаким образом не повлияет на какого-либо другого пользователя.
    •

    Задачи операционной системы

    Операционная система отвечает за широкий спектр задач внутри компьютерного окружения. Именно эти задачи часто являются тем, что делает одну операционную систему надежнее и легче в использовании по сравнению с другой. То, как ОС управляется с этими задачами, определяет реальные возможности операционной системы.

  • Управление процессором. Операционная система должна обеспечить эффективное использование процессора при выполнении реальной работы и то, чтобы каждое приложение получило свою часть процессорного времени.
  • Управление памятью. Это определяет те методы, посредством которых операционная система выделяет приложениям и функциям самой операционной системы память.
  • Управление устройствами. Поскольку операционная система состоит из разнообразных аппаратных компонентов (жесткий диск, монитор, мышь, клавиатура и т. д.), она должны быть способна управлять тем, как все эти компоненты взаимодействуют друг с другом.
  • Управление хранением информации. Операционная система не только осуществляет контроль за активными ресурсами, но и определяет, каким образом хранятся файлы и данные, при этом обеспечивая их сохранность.
  • Прикладной интерфейс. Операционная система действительно является мостом между приложениями и компьютерными ресурсами, что означает, что она должна для связи с приложениями предоставить интерфейсы прикладного программирования (APIs, Application Programming Interfaces).
  • Пользовательский интерфейс. Будь то посредством командной строки или графического пользовательского интерфейса (Graphical User Interface, GUI), именно операционная система отвечает за взаимодействие с конечным пользователем.
    •

    Это было очень краткое резюме тех основных задач, с которыми следует управляться операционной системе.

    Следующие разделы описывают вопросы безопасности, с которыми должна иметь дело операционная система для поддержания конфиденциальности, целостности и доступности системных ресурсов. Мы пройдемся по двум наиболее известным семействам операционных систем и по присущим им особенностям реализации систем безопасности. Еще мы опишем наиболее часто встречающиеся методы взлома или обхода этих систем, а также то, каким образом можно защитить себя от подобных видов атак.

    С этого момента мы будем ссылаться на две ключевые книги по безопасности, которые в своей библиотеке следует иметь каждому администратору систем Windows или UNIX, а именно:

  • Максимальная безопасность для Windows 2000 (Maximum Windows 2000 Security, Sams, 2001, ISBN 0672319659);
  • Максимальная безопасность для Linux (Maximum Linux Security, Sams, 1999, ISBN 0672316706).
    •

    В этих книгах находится настоящее богатство полезных мыслей по поводу слабых и сильных мест в системах безопасности Windows и Linux.

    9.2.2 Слабые места операционной системы Windows

    Уже достаточно долгое время Microsoft Windows имеет репутацию системы с неадекватным уровнем безопасности, но многие эксперты в сфере безопасности полагают, что в действительности Windows отнюдь не слаба. Всю вину они возлагают непосредственно на плечи системных администраторов, которые отвечают за эти системы. Другими словами, при должном сопровождении и настройке вполне возможно сделать операционную систему Windows относительно безопасной.

    Тем не менее есть несколько областей, в которых, как известно, Windows действительно уязвима, например в следующих:

  • Размер/сложность. Microsoft запустил свою руку едва ли не в каждую дверь программного обеспечения (и даже в некоторые аппаратные двери). Хотя это и хорошо для общей интеграции, но для среднего системного администратора становится очень сложно держать себя на должном уровне в плане понимания:

    1) Где это начинается и где заканчивается; и 2) Как надлежащим образом все это использовать и настраивать.

  • Небезопасная установка. Одна из наиболее общих причин того, что сервера Windows становятся жертвами взломщиков, состоит в том, что их установили и забыли. К несчастью, Windows печально известна своей практически нулевой безопасностью при установке по умолчанию. Сюда входят и скрытые общие ресурсы, и пустые пароли, и отсутствие защиты от известных уязвимостей. Короче говоря, установки по умолчанию – это открытое приглашение для взломщиков и вообще для каждого, кому только не вздумается, даже для низкоквалифицированных "парнишек-скриптовиков".
  • Плохой аудит. Всякий раз, когда люди думают о возможностях журналирования на сервере Windows, первое, что обычно приходит в голову, – это обозреватель событий (Event Viewer). Хотя эта встроенная часть Windows действительно дает некоторую полезную информацию, тем не менее сам по себе обозреватель событий уже давно рассматривается как менее чем адекватный инструмент журналирования со своими зашифрованными записями и пропадающей информацией.
  • Ориентация системы на добавление новой функциональности. Windows всегда стремилась предоставить пользователям операционную систему, богатую своими возможностями, простую и легкую в использовании. При этом ранние версии вообще не особо утруждали себя вопросами безопасности. И так же, как и другие компании, разрабатывающие ПО, Microsoft всегда выискивала пути для добавления в свои продукты каких-то новых возможностей, новой функциональности для стимулирования своих клиентов к покупке новых версий. Кроме того, коммерческая природа компании требует обратной совместимости со старыми, менее защищенными версиями. А с добавлением каждой новой функциональной возможности, каждой новой услуги возникает целый набор новых проблем в плане безопасности.
  • Необученные пользователи. Windows – операционная система для масс. Многие пользователи не знают либо просто не волнуются по поводу опасностей, связанных с неадекватной конфигурацией системы. Помимо этой достаточно обширной группы, многие бизнесмены назначают на должности системных администраторов по совместительству людей из числа своих собственных служащих только на основании того факта, что те много знают о компьютерах. К несчастью, такая стратегия часто приводит к катастрофам при первом же простукивании хакером дверей в поисках легкой цели.
    •

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

    Невозможно, да это и не является целью настоящей лекции, подробно описать все уязвимые места Windows. Напротив, читателю предлагается обратиться к следующим сайтам за текущими обновлениями в этой области:

  • отслеживание ошибок от SecurityFocus:

    http://www.securityfocus.com/

  • отслеживание ошибок в NT:

    http://www.ntbugtraq.com/

  • консультации CERT:

    http://www.cert.org/nav/index_red.html

    •

    При помощи информации, содержащейся на этих сайтах, можно оперативно идентифицировать слабые и уязвимые места и применить соответствующие патчи. Справедливости ради надо сказать, что Windows не единственная операционная система со слабыми местами. В Linux также имеются некоторые "дырки", которые мы рассмотрим дальше.

    9.2.3 Слабые места Linux

    Многими Linux рассматривается как операционная система для компьютерных "фанатиков". Хотя когда-то подобное и было справедливо, сейчас операционные системы Linux для всех практических целей эволюционировали до той точки, когда они стали привлекательны и для обычного пользователя. От самых базовых машин Lindows и до выхода файлового сервера Red Hat-система, Linux делает значительные шаги в продвижении на основной рынок, приобретая также безусловную поддержку IBM. К сожалению, это означает, что растет также и число неопытных пользователей Linux.

    Одно из самых распространенных утверждений относительно Linux – она более безопасна, чем Windows. К сожалению, такое утверждение само по себе не совсем корректно и заставило не одного ИТ-работника поверить в то, что ИТ-инфраструктура будет безопаснее, исходя только из самого того факта, что они используют Linux. Хотя это и действительно может быть правдой, что Linux может быть сделана более безопасной, чем другие операционные системы, в руках пользователей ей присущи многие из тех же самых проблем, что и для других ОС. Основные вопросы безопасности для Linux следующие:

  • Учетная запись root. Одно из главнейших правил, которое регулярно игнорируется, – "не следует использовать учетную запись root без действительно абсолютной необходимости". Причина этого правила находится в той безграничной власти, которую предоставляет доступ под учетной записью root всякому, кто использует ее. Как и учетная запись Administrator в Windows NT®, root является учетной записью для интерактивного входа самого высокого уровня, какой только может существовать в Linux. Опасность кроется в том, что большинство вредоносных программ запускается с разрешениями того пользователя, который активировал данную программу. Другими словами, если для хождения по Интернету используется учетная запись root и если на Web-странице нечаянно запущен скрипт, этот скрипт будет иметь права доступа root и следовательно, сможет получить доступ к любому файлу и даже удалить целую файловую систему. Хуже того, некоторые дистрибутивы (такие, как Lindows) требуют использования учетной записи root при установке и работе.
  • Сложность. Несомненно, что самое пугающее в Linux – это весь тот сложный набор команд, концепций и программ, который должен быть освоен для соответствующей реализации мер безопасности. Действительно, это легко можно увидеть всякий раз, когда начинающий системный администратор в первый раз пытается установить Linux. И хотя некоторые дистрибутивы (версии) Linux уже начали ориентироваться на предпочтения человека, устанавливающего их, тем не менее многие операционные системы Linux до сих пор либо требуют в программе-установщике выбирать из списка неким загадочным образом именованные программы, содержащиеся обычно в пакете и устанавливаемые вместе с rpm, либо просто устанавливают всю операционную систему целиком. К сожалению, подобный список в несколько сотен программ часто действует угнетающе. В результате человек завершает установку всей операционной системы, включая HTTP-демон, FTP-демон, почтовые демоны и т.д., установка которых не является безопасной по умолчанию.
  • Сетевая ОС. Вот что утверждает максимальная безопасность для Linux (Maximum Linux Security): "Хотя Linux действительно хорошо приспособлена для персонального использования (даже в несетевых окружениях), по сути она все равно остается сетевой операционной системой. Ее установки по умолчанию запускают многие интернетовские службы, и, если не предпринимать должных мер предосторожности, взломщики могут удаленно начать на эти службы атаку во время вашей онлайн-сессии". Этим все сказано.
  • Обновления по принципу открытого исходного кода (open source). Большое количество программного обеспечения под Linux пишется студентами, исследовательскими группами или теми разрабатывающими ПО компаниями, которые пытаются найти способ сделать программное обеспечение под Linux выгодным. В сочетании с тем фактом, что Linux – открытая система, это означает, что все ПО также является открытым для изучения всему миру, и, следовательно, отсюда вытекает огромная потенциальная "головная боль" для безопасности всей системы. Но на самом деле проблема не в том, что открытое ПО является менее безопасным, нежели коммерческое. Действительно, известно, что распространители Linux выкладывают обновления и патчи в течение нескольких часов с момента обнаружения уязвимых мест в системе безопасности их продуктов. Нет, проблема в том, что информация об этих обновлениях просто не доходит до системных администраторов. Например, Red Hat выпускает ни много ни мало пять бюллетеней безопасности в день, которые системным администраторам надо просматривать, чтобы видеть, нужно ли их применять. Хотя большинство этих сигналов тревоги могут к делу и не относиться, тем не менее достаточно пропустить всего лишь одно предупреждение, чтобы оставить свою систему открытой для атак.
    •

    Системным администраторам Linux-систем следует регулярно заходить на Web-сайты используемых ими дистрибутивов (например, Caldera, Red Hat, SUSE, Turbolinux) за консультациями по уязвимым местам и соответствующими патчами, а также в раздел UNIX сайта SecurityFocus (http://www.securityfocus.com/unix), тоже за консультациями по вопросам безопасности, за инструментами и техниками для борьбы с уязвимостями.

    В итоговом разделе мы попытались представить ясный и сбалансированный обзор потенциальных вопросов безопасности в Linux и Windows. Это сделано для того, чтобы показать, что в обоих семействах операционных систем есть слабые места и что сознательному в плане безопасности системному администратору не следует расслабляться в чувстве комфорта от того, что он использует одну систему в противовес другой.

    В следующих разделах мы рассмотрим специфику укрепления Windows и Linux, а заодно Solaris и AIX, так как все это такие операционные системы, на которых работает и поддерживается Domino.

    Domino также работает и на таких ОС, как zOS (OS/390®) и OS/400® (которые предназначены для мейнфреймов zSeries™ и мини-компьютеров iSeries). Но поскольку для администрирования этих систем требуются очень специализированные знания, в пределах этого курса они рассматриваться не будут.

    9.3 Укрепление систем Windows (на ядре NT)

    В этом разделе мы рассмотрим процесс укрепления систем Windows (на базе Win32). Это те системы, которые включены в линейку NT-продуктов Windows, а именно:

  • Windows NT 4.0,
  • Windows 2000 Server,
  • Windows XP Professional.
    •

    Сюда мы включили и Windows XP Professional, так как Windows применяется большинством пользователей в качестве настольной системы (Linux в этой области медленно догоняет ее и все более и более привлекает к себе внимание), и, таким образом, как нам кажется, руководство по укреплению рабочих станций было бы хорошей идеей.

    Хотя укрепление сервера Windows является несколько утомительным процессом, реализовать его относительно легко, и для него, как правило, не требуются от организации какие-либо расходы на дополнительное программное или аппаратное обеспечение. Как упоминалось ранее в этой лекции, процесс достаточно прямолинеен: 1) укрепить базу операционной системы и 2) предпринять аналогичные меры к любым службам, которые планируется запускать на данной ИТ-системе. В конечном итоге это не поможет укрепить базу операционной системы и оставит зияющие "дыры" в Web-сервере и сервере баз данных. Стоит еще раз повторить, что с каждым установленным в операционную систему продуктом возрастает вероятность, что взломщики получат доступ к ИТ-системе.

    9.3.1 Укрепление Windows NT 4.0

    За долгие годы Windows NT 4.0 стала для Microsoft основной рабочей лошадкой. И хотя в настоящее время доступны более богатые своими возможностями замены ей, тем не менее до сих пор есть достаточно много причин, почему может быть развернута именно Windows NT 4.0. Тот факт, что большинство клиентов уже создали под нее стабильную и надежную основу, является, пожалуй, наиболее общераспространенным. Поэтому схема укрепления старого флагманского продукта будет рассмотрена в первую очередь. Многое из того, что будет здесь рассмотрено, применимо и к более новым версиям Windows, поэтому прочтение данного раздела очень рекомендуется.

    Основные рекомендации по установке

    При установке Windows NT 4.0 Server лучше всего следовать приведенным здесь рекомендациям настолько точно, насколько только возможно. Отдельные отклонения от нижеизложенного могут привести к тому, что будет удалена необходимая функциональность, требующаяся для приложения. Если подобное произойдет, мы встанем перед трудным выбором. В частности, если данная функциональность должна быть сохранена, от системных администраторов потребуется намного больше работы для защиты сервера, возможно даже придется использовать некоторые дополнительные инструменты и техники, упоминавшиеся ранее в этой лекции.

    Что следует делать при установке

    Начнем для начала с того, что следует делать, и отложим обсуждение того, чего делать не следует, на некоторое время. Этим будет гарантировано то, что смогут быть выработаны некие наиболее подходящие практические методы, а также то, что все необходимое для них будет установлено. Лучше всего начать с должным образом настроенной базы, чем потом встать перед необходимостью корректировки неправильной установки.

    Итак, при установке Windows NT 4.0 в целях безопасности вам следует сделать следующее:

  • Ставьте файловую систему NTFS, а не FAT. NTFS дает дополнительное управление безопасностью посредством списков контроля доступа (access control lists, ACLs) и является более "крепкой" файловой системой.

    Замечание. Некоторые системные администраторы предпочитают устанавливать файловую систему FAT, а уже затем, после установки, преобразовывать ее в файловую систему NTFS. Подобный способ действий не рекомендуется, поскольку в этом случае ACLs по умолчанию применены не будут.

  • Устанавливайте как отдельный сервер, а не как контроллер домена (если, конечно, нет действительно важных причин так делать). То есть нет никакой мыслимой необходимости включать брандмауэр, DMZ Web, Domino или DNS сервер в домен.
  • Устанавливайте самые последние пакет обновлений (Service Pack) и исправления, относящиеся к данной платформе и типу установки. Наиболее часто рекомендуемым пакетом обновлений для рассматриваемой платформы является Service Pack 6a, а также несколько дополнительных исправлений.
  • Убирайте ненужные службы, устанавливаемые автоматически во время процесса установки. К таким службам относятся следующие:
  • Remote Procedure Call (RPC),
  • NetBIOS,
  • Computer Browser.
    •

    Удаление этих служб может сильно повлиять на функциональность сервера. Для планируемой конфигурации следует проверить требования программного обеспечения или, что еще лучше, провести пробную установку и протестировать конфигурацию до ее фактического размещения в реальном рабочем окружении.

    Указанные службы могут быть удалены последовательным выбором: Панель управления -> Сеть -> Службы (Control Panel -> Network -> Services):

  • Workstation. Может повлиять на некоторые службы, такие, как at. Хотя она и не столь важна, как служба Server, тем не менее обращаться с нею следует осторожно.
  • Server. Может повлиять на отдельные части производительности сервера. С этой службой следует обращаться с величайшей осторожностью и удалять ее только в том случае, если не было замечено снижения производительности.
    •
  • Отвяжите WINS от TCP/IP. Выберите Панель управления -> Сеть -> Привязки (Control Panel -> Network -> Bindings). Из выпадающего меню выберите "Все протоколы" (All Protocols). Кликните на WINS Client (TCP/IP) и затем на "запретить/удалить" (Disable/Remove).
  • Используйте несуществующую рабочую группу. Нет никаких оснований вовлекать брандмауэр или DMZ-сервер в работу домена или рабочей группы.
  • Убедитесь, что следующие службы запрещены:
  • Alerter. Это служба оповещения, доставляющая пользователям сообщения о некоторых административных событиях.
  • ClipBook. Эта служба позволяет видеть содержимое буфера обмена в удаленном буфере обмена.
  • DHCP Client. Эта служба позволяет конфигурировать сетевые настройки удаленными средствами.
  • Messenger. Эта служба отправляет и принимает сообщения, посланные администратором или службой оповещения.
  • NetBIOS Interface. Эта служба подключает NetBIOS через TCP/IP.
  • Net Logon. Эта служба отвечает за прямой вход (рабочая станция) или за вход через аутентификацию и синхронизацию базы данных безопасности домена (сервер) на другие машины в домене.
  • Network DDE. Эта служба отвечает за обмен динамическими данными с удаленными машинами в сетевом окружении.
  • Network DDE DSDM. Эта служба управляет общими сетевыми ресурсами обмена динамическими данными (Dynamic Data Exchange, DDE) посредством общей базы данных DDE-соединений.
  • TCP/IP NetBIOS Helper. Эта служба представляет собой NetBIOS посредством TCP/IP, в которой осуществляется отображение имя IP-адрес.
    •

    Хотя это и удобно для удаленного администрирования сервера, лучше всего не добавлять дополнительные службы, включая службы удаленного управления, такие, как telnetd и FTP. Ни одна из них не осуществляет шифрования, таким образом учетные записи, пароли и другая информация запросто могут быть собраны прямо по сети. Если все же эти службы должны быть разрешены, системным администраторам следует принять иные меры предосторожности, такие, как доступ только через брандмауэр из внутренней сети и применение фильтров IP-безопасности к тем серверам, на которых эти службы работают.

  • Включите фильтры IP-безопасности на серверах DMZ. У брандмауэров имеется своя собственная IP-фильтрация, и им не нужны или не требуются родные IP-фильтры Windows NT. Выберите Панель управления -> Сеть -> Протоколы -> Протокол TCP/IP -> Свойства -> Дополнительно (Control Panel -> Network -> Protocols -> TCP/IP Protocols -> Properties -> Advanced). Отметьте "Разрешить безопасность" (Enable Security) и затем выберите "Настроить" (Configure). Добавьте те порты, входящий трафик из которых должен приниматься.
  • Уберите у пользователей права, которые разрешают им доступ к серверу по сети; доступ только через консоль.
  • Определите индивидуальные административные учетные записи, если есть необходимость во множественных административных учетных записях. Они помогут процессу аудита.
  • Переименуйте учетную запись "Администратор" (Administrator) во что-нибудь другое.
  • Создайте фиктивную учетную запись "Администратор без привилегий". Если взломщики попытаются скомпрометировать данную учетную запись, это будет зафиксировано в журналах аудита.
  • Сократите число групп, имеющих доступ к серверу, до того минимума, который необходим для работы и администрирования сервера. Возможно, следует свести все только к группам "Администраторы" и "Опытные пользователи".
  • Разрешите большее количество системных политик безопасности. Для изменения "Учетных записей", "Пользовательских прав" и системных политик "Аудита" следует использовать "Диспетчер пользователей", а именно:
  • Политики учетных записей контролируют пользовательские пароли и настройки блокировки. Срок действия паролей следует ограничивать согласно временным рамкам, установленным корпоративной политикой. Минимальную длину пароля следует установить по меньшей мере в восемь символов, в то время как 24 последних пароля следует запоминать. Блокировку учетной записи следует производить после трех неуспешных попыток регистрации. Счетчик попыток может быть сброшен спустя 30 минут.
  • Изо всех "Прав пользователей" следует удалить группу "Все" (Everyone). Удалите все группы и всех пользователей из "Доступа к этому компьютеру по сети" (Access This Computer From the Network), а также ограничьте число пользователей и групп, которые могут регистрироваться локально. Обратите особое внимание на "Управление аудитом" и "Журнал безопасности".
  • Включите отслеживание успешности и неуспешности по крайней мере для следующих событий: "Регистрация и выход"; "Изменение политики безопасности"; "Перезагрузка", "Выключение и система".
  • Включите черный скринсейвер с низким периодом неактивности (порядка 5 минут). Разрешите в нем защиту паролем.
  • Запустите утилиту SYSKEY для улучшения безопасности базы данных "Менеджера безопасности учетных записей" (Security Accounts Manager, SAM). Утилита SYSKEY стала доступной с выходом пакета обновлений 3; следовательно, после применения пакета обновлений 6a или более нового SYSKEY должна быть в наличии.
  • Удалите подсистемы OS/2® и POSIX. Это можно сделать запуском утилиты C2SECURITY из "Набора ресурсов Windows NT" (Resource Kit) или непосредственным редактированием следующих ключей регистра.

    Удалите данный ключ, а вместе с ним удалятся все нижележащие ключи, относящиеся к подсистеме OS/2 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OS/2 Subsystem for N.

    Уберите значение Os2LibPath из ключа Environment:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\EnvironmentOs2LibPath.

    Уберите ключи Optional, POSIX и OS/2 из ключа "Подсистемы менеджера сессии":

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\SubSystems.

    После этих изменений в регистре необходимо вручную удалить директорию %WINNT%\system32\os2 вместе со всеми вложенными папками.

    • Это был действительно длинный список того, что фактически должно быть сделано, но на котором многие системные администраторы почему-то спотыкаются, поскольку не осознают всего того, что им следует делать при установке операционной системы.

    Что не следует делать при установке

    Теперь перейдем к тому, чего не следует делать. Это еще один немаленький список, хотя и не совсем такой длинный, как список того, что следует делать.

  • Не устанавливайте никакого дополнительного ПО, если оно действительно не нужно. По умолчанию установка Windows NT включает в себя множество разных инструментов для повышения удобства использования ОС, аксессуаров, приложений и схем мультимедиа, приложения для коммуникации. Чем больше программного обеспечения установлено, тем выше вероятность быть взломанным. В безопасности лучше всего следовать пути Дао: простота начиная с самой установки.
  • Не устанавливайте информационный сервер Интернета (Internet Information Server, IIS) v2.0, который входит в поставку Windows NT, даже если данная машина планируется как Web-сервер. Процесс обновления ранних версий IIS не удаляет старых неиспользуемых файлов, через которые тем не менее можно взломать уже новую установку IIS. До тех пор пока процессом обновления не удаляются старые файлы, зачастую лучше будет вообще деинсталлировать IIS и затем инсталлировать новую версию, а не обновлять заменой поверх.
  • Не устанавливайте никаких других сетевых протоколов, кроме TCP/IP. Дополнительные протоколы порождают дополнительные проблемы. NetBEUI не используется вне рабочей группы, а IPX часто не обрабатывается должным образом брандмауэрами. Одна из наиболее больших и распространенных проблем безопасности – позволить IPX работать через NetBEUI. Это может позволить взломщикам обойти брандмауэр организации и получить доступ к настольным машинам.
  • Не добавляйте дополнительных служб, если машина не назначается в качестве DNS-сервера. Web-серверам, почтовым серверам и брандмауэрам обычно не требуется запуск DNS. Единственная служба, которую вы, вероятно, захотите добавить, – простой протокол управления сетью (Simple Network Management Protocol, SNMP) для удаленного наблюдения за брандмауэром и службами DMZ. Удостоверьтесь, что ее порты блокированы для доступа извне и что "имена сообществ" (community) для чтения-записи изменены с их значений по умолчанию. SNMP может легко выдавать информации больше, чем следует, если эта служба доступна из Интернета.
  • Не устанавливайте WINS. Если требуется разрешение имен NetBIOS без участия DNS, лучше использовать файл LMHOSTS.
  • Не делайте DHCP-ретрансляцию (relay). В общем, для DMZ-серверов вообще не нужно никаких ретрансляций (кроме, конечно, случаев, перечисленных в лекции о прокси).
  • Не разрешайте IP-переадресацию (IP Forwarding), если только данный сервер не будет брандмауэром. Брандмауэр никогда не сможет использовать весь свой потенциал, если не будет перенаправлять IP-трафик. Тем не менее обратитесь к лекции о разборе инфраструктуры за практическими советами относительно брандмауэров.
  • Не устанавливайте обозреватели Интернета (Internet Explorer) 5 или 5.5: в них намного больше дополнительной функциональности, нежели может понадобиться среднестатистическому серверу. Стоит вспомнить, что любая дополнительная функциональность может быть взломана самыми неочевидными способами. Обозреватели Интернета 5 и 5.5 – это не одиночные программы, а целые коллекции предназначенных для многократного использования компонентов. А это, в свою очередь, означает, что любая программа, работающая под Windows NT 4.0, может воспользоваться этой функциональностью. Как правило, лучше не давать взломщикам дополнительных средств для атаки на сервер. Если для брандмауэра Windows NT 4.0 или для DMZ-сервера требуется обновление обозревателя Интернета, лучше установить обозреватель Интернета 4.01 с пакетом обновления 2 (Internet Explorer 4.01 Service Pack 2).
    •

    Замечание. Internet Explorer 4.01 SP1® идет в поставке Windows NT на компакт-диске с опциональными компонентами (Option Pack CD), а Internet Explorer 4.01 SP2® доступен для скачивания по сети.

    Рекомендации по модификации реестра

    Есть несколько функций и особенностей Windows NT, которыми можно управлять исключительно через настройки реестра. При правке реестра следует быть особо осторожным, поскольку это быстро и легко может покалечить всю систему. Нижеследующие изменения реестра однозначно сделают Windows NT более безопасной.

  • Установите значение данного ключа в 1, чтобы из стартового диалога регистрации пользователя в системе убрать имя пользователя, последним прошедшего регистрацию:
    HKEY_LOCAL_MACHINE\SOFTWARE
\Microsoft\Windows NT\CurrentVersion\Winlogin
DontDisplayLastUserName
  • Установите значение данного ключа в 1, чтобы ограничить анонимным соединениям запрос списка имен учетных записей:
    HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Control\Lsa
RestrictAnonymous
  • Создайте следующий ключ для ограничения доступа к реестру по сети, чтобы изменения реестра могли осуществляться только из локальной системы. (Для работы этой записи реестра должен быть установлен пакет обновлений 3 или выше.):
    HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Control\SecurePipeServers\winreg
  • Установите следующий ключ в 1, чтобы запретить на разделах с NTFS создание в целях совместимости имен формата 8.3. (Формат имен 8.3 обычно используется только приложениями Win16, так что о нем не стоит беспокоиться. Кроме того, это даст некоторый прирост производительности за счет уменьшения расходов на генерацию и запись имен формата 8.3.):
    HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Control\FileSystem
NtfsDisable8dot3NameCreation
  • Установите данный ключ в 0, чтобы запретить автоматическое предоставление для открытого доступа административных разделяемых ресурсов ( ADMIN$, C$ и т. д.). (Убедитесь, что вы собственноручно удалили эти ресурсы из списка разделяемых (для общего доступа) запуском команды net share /d.):
    HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Services\LanmanServer\Parameters
AutoShareServer
  • Установите в 1 относящиеся к данному журналу ключи "Приложения", "Безопасности" и "Системы" для предотвращения просмотра журналов событий из сессий "Гостя" и из нулевых сессий (сессии без имени пользователя и аутентификации паролем):
    HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Services\Eventlog\Application
\CurrentControlSet\Services\Eventlog\Security
\CurrentControlSet\Services\Eventlog\System
RestrictGuestAccess
  • Установите данный ключ в 0 для предотвращения кеширования пользовательских мандатов (обычно системой Windows NT мандаты последних 10 пользователей, интерактивно входивших в систему, локально кешируются):
    HKEY_LOCAL_MACHINE\SOFTWARE
\Microsoft\Windows NT\CurrentVersion\Winlogon
CachedLogonsCount
  • Доступ к наиболее часто атакуемым ключам реестра следует ограничивать посредством списков управления доступом (Access Control Lists, ACLs). Следующие ключи реестра следует по меньшей мере защитить предоставлением "Всем" (Everyone) прав доступа только на чтение, а прав полного контроля (Full-Control) – только "Администраторам" (Administrators) и "Системе" (SYSTEM). Создателя "Владельца" (Owner) следует наделить правами полного контроля владельца (Full-Owner control):
    HKEY_LOCAL_MACHINE\SOFTWARE
\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\SOFTWARE
\Microsoft\Windows\CurrentVersion\RunOnce
HKEY_LOCAL_MACHINE\SOFTWAR
\Microsoft\Windows\CurrentVersion\RunOnceEx
HKEY_LOCAL_MACHINE\SOFTWARE
\Microsoft\Windows NT\CurrentVersion\AeDebug
HKEY_LOCAL_MACHINE\SOFTWARE
\Microsoft\Windows NT\CurrentVersion\WinLogon
    •

    Журналирование в Windows NT 4.0

    В Windows NT 4.0 есть несколько встроенных автоматических служб журналирования. Большинство служб пользуются EventLogs, с которой следует быть знакомым едва ли не каждому хорошему администратору систем Windows.

    Замечание. Описанные здесь особенности журналирования применимы и к более поздним версиям операционной системы Windows, но рассказывается о них только в этом разделе.

    Если на сервере запускаются какие бы то ни было службы Интернета (такие, как FTP, HTTP, SMTP и т. д.), их журналирование происходит посредством разных механизмов. Очень вероятно, что для настройки или отладки сервера будет использоваться приложение "Монитор производительности" (Performance Monitor). Это приложе- ние не пользуется услугами журнала приложений службы EventLog, а вместо этогведет свой собственный набор журналов.

    И наконец, один из наиболее важных аспектов системы – расписание автоматически выполняемых заданий – ведет свой журнал посредством еще одной службы. Поскольку в Windows NT нет нормальной централизованной службы ведения журналов, каждый должен заботиться сам о себе.

    Самое первое, что нужно сделать, – это вынести все журналы на отдельный журнальный раздел. Было бы удобно, хотя и не обязательно на все 100 %, использовать в качестве такого раздела отдельный диск, чтобы не влиять на производительность работы с частью данных на сервере. После того как журнальный раздел создан, следующий шаг – перенести туда все журналы из их мест размещения по умолчанию.

    Зачем все это? Если все журналы собраны в одном месте, процедура поддержки работающего сервера становится намного легче. Это дает возможность выполнять автоматическое резервное копирование и архивирование для последующего разбора и обработки.

    EventLogs

    EventLogs – это встроенные в Windows NT журналы событий, которые используются по умолчанию и могут быть просмотрены через обозреватель событий (Event Viewer). В Windows NT EventLogs является эквивалентом службы syslogs в операционной системе UNIX.

    Сама служба EventLog состоит из журнала приложений (Application Log), журнала безопасности (Security Log) и системного журнала (System Log). Большинство приложений, служб и системных событий Windows NT записывают свои отчеты в соответствующие категории. Каждая из категорий фактически обладает своим собственным отдельным физическим файлом, который может быть перемещен.

    Эта задача выполняется редактированием следующих ключей реестра:

    HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Services\Eventlog\Application
\CurrentControlSet\Services\Eventlog\Security
\CurrentControlSet\Services\Eventlog\System

    File

    Значения параметров "File" следует установить в новое имя папки раздела журнальных файлов. После редактирования этих значений сервер должен быть перезапущен, чтобы изменения вступили в силу.

    Службы Интернета

    Службы, предоставляемые инфраструктурой Windows IIS Web-сервера, генерируют журналы для каждой из них: Web, FTP и SMTP. Журналы службы Интернета уникальны в том смысле, что для автоматического перехода к новому журналу можно настроить временной интервал. А имя журнального файла может основываться на определенном периоде времени.

    Для изменения размещения этих журнальных файлов отредактируйте свойства корневой папки Web или FTP. Выберите свойства файла журнала и в диалоговое окно "Свойства" (Properties) введите новое размещение раздела журнальных файлов.

    Журналы производительности

    Журналы производительности создаются счетчиками монитора производительности (Performance Monitor). По умолчанию они находятся в %SystemDrive%\PerfLogs. Это значение может быть изменено редактированием параметра DefaultLogFileFolder в следующем ключе реестра:

    HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Services\SysmonLog
DefaultLogFileFolder

    Журналы планировщика

    Служба планировщика обычно находится в %SystemRoot%\SchedLgU.Txt. Журнал службы планировщика определяет все запланированные и выполняемые задачи, а также то, когда каждая из них началась и закончилась. Местонахождение этого файла может быть изменено редактированием значения LogPath в ключе реестра:

    HKEY_LOCAL_MACHINE\SOFTWARE
\Microsoft\SchedulingAgent
LogPath

    Этим завершается наше обсуждение укрепления Windows NT. Как уже упоминалось ранее, многое из рассмотренного здесь применимо и к новым версиям Windows. Однако, исходя из того факта, что после NT 4.0 в Windows было сделано множество улучшений, важно также рассмотреть и эти новые версии и наметить некие наиболее подходящие практические методы обеспечения безопасности с точки зрения процесса укрепления.

    9.3.2 Укрепление Windows 2000

    Windows 2000 является намного более большим и сложным продуктом, чем Windows NT 4.0, и, по сути, для полного анализа ее установок безопасности по умолчанию и защиты от любых недочетов требуется гораздо больше времени. Исходя из этого, рекомендации по укреплению, приведенные в настоящей лекции, следует рассматривать как некий след во времени, поэтому в текущий момент они могут оказаться и не совсем корректными. Таким образом, самые лучшие практические советы здесь ссылаются на несколько реально существующих документов, опубликованных Microsoft в своей библиотеке Technet, которые предоставят самую последнюю информацию.

    Рекомендации по укреплению установки

    При установке Windows 2000 лучше всего следовать данному методическому указанию настолько точно, насколько возможно. Везде, где это только применимо, используйте рекомендации, приводившиеся в предыдущем разделе, наряду с обсуждаемыми здесь указаниями, специфичными для Windows 2000.

    При установке Windows 2000 лучше всего попытаться уменьшить число устанавливаемых компонентов Windows 2000. По умолчанию Windows 2000 предлагает намного больше функциональных возможностей, чем Windows NT 4.0. Многое из этой функциональности лучше вообще НЕ предоставлять людям как внутри организации (если машина каким-либо образом доступна из Интернета), так и тем более кому бы то ни было снаружи.

    По умолчанию в установку Windows 2000 входит множество аксессуаров, утилит, мультимедийных приложений и схем, а также приложений коммуникации. Можно, конечно, впасть в искушение установить набор программного обеспечения, предлагаемого по умолчанию. Однако лучше все-таки уделить время для определения того, что действительно стоит устанавливать, а что нет. Не будет лишним повторить: чем больше установлено программного обеспечения, тем выше вероятность быть взломанным.

    Так же, как это делали в разделе о Windows NT 4.0, здесь мы расскажем о том, что делаем и чего не делаем при установке Windows 2000 в плане обеспечения безопасности и укрепления окружения.

    При установке делаем

    Прежде всего начнем с того, что следует делать. Этим будет гарантировано то, что смогут быть выработаны некие наиболее подходящие практические методы, а также то, что все необходимое для них будет установлено. Лучше всего начать с должным образом настроенной базы, чем потом оказаться перед необходимостью корректировки неправильной установки.

  • Ставьте под Windows 2000 файловую систему NTFS, а не FAT. NTFS дает дополнительное управление безопасностью посредством списков контроля доступа (ACLs) и является более "крепкой" файловой системой.

    Замечание. Некоторые системные администраторы предпочитают устанавливать файловую систему FAT, а уже затем, после установки, преобразовывать ее в файловую систему NTFS. Подобный способ действий не рекомендуется, поскольку в этом случае ACLs по умолчанию применены не будут.

  • Выбирайте только те компоненты и службы, которые необходимы для целей, ставящихся перед сервером. Для большинства брандмауэров и серверов DMZ "Службы терминала", "службы удаленной установки", "Службы сети" или "Службы файлов и принтеров" вообще не понадобятся. Например, стоит удостовериться, что в IIS-сервере не загружается поддержка FTP, если данный сервер предназначен только для обслуживания HTML-страниц. Или, если обработки потокового медиа не планируется, значит, и "Службы Windows Media" тоже подгружать не нужно.
  • Удалите "Общий доступ к файлам и принтерам в сети Microsoft" (File and Printer Sharing for Microsoft Networks). При настройке конфигурации сети следует выбирать "Выборочную установку" (Custom), чтобы вручную настроить сетевые компоненты.

    Если данный сервер предполагается в качестве Web или почтовой станции SMTP, "Клиента для сетей Microsoft" (Microsoft Networking Client) следует отключить снятием галочки пометки, хотя установлен он тем не менее все равно должен быть. Очевидно, что используемая для выполнения аутентификации "Служба локатора RPC" будет доступна только при установленном "Клиенте сетей Microsoft". Без этой службы нельзя запустить ни IIS, ни службы SMTP.

    Затем следует выбрать "Свойства протокола IP" (IP Protocol Properties). Для настройки IP адреса и информации DNS не используйте DHCP. После установки вручную сетевых параметров нажмите на кнопку "Дополнительно" (Advanced) и внесите следующие изменения:

  • Выберите закладку DNS. Снимите пометку с "Зарегистрировать адреса этого соединения в DNS" (Register This Connection's Addresses in DNS).
  • Выберите закладку WINS; удалением каких бы то ни было адресов оттуда запретите WINS. Если требуется ввести имена NetBIOS, делать это следует через содержимое файла LMHOSTS. Выбором "Запретить NetBIOS через TCP/IP" запретите работу NetBIOS посредством протокола TCP/IP.
  • Выберите закладку "Свойства" (Options) для настройки любой TCP/IP-фильтрации, как было описано ранее в разделе об Windows NT 4.0.
    •
  • Используйте несуществующую рабочую группу. Нет никаких причин включать брандмауэр или DMZ-сервер в работу домена или рабочей группы.
  • Запретите службу telnetd. Если в конечной системе все-таки сессии telnet должны быть разрешены, всех пользователей telnet следует ограничить одной группой аутентифицированных пользователей TelnetClients. Создайте группу TelnetClients, а затем добавьте в нее тех пользователей, которым доступ посредством telnet будет разрешен. Служба telnetd сама автоматически ограничит доступ к Telnet только членами группы TelnetClients.
  • Закройте ваш DNS-сервер. Передачи в пределах зоны следует ограничить только авторизированными службами. Для изменения свойств зоны следует использовать менеджер DNS. На закладке "Уведомления" (Notify) включите опцию "Разрешить доступ только с тех вторичных серверов, которые включены в список уведомлений" (Only Allow Access From Secondaries Included on Notify List). Позаботьтесь о защите первичных зон так же, как и вторичных. К сожалению, встроенные DNS-серверы, идущие в комплекте с Windows NT и 2000, не имеют средств для ограничения запросов. Если такая функциональность все же нужна, можно воспользоваться кроссплатформенной реализацией ISC BIND (Internet Software Consortium Berkeley Internet Name Daemon), используемой в большинстве UNIX-систем. С одной стороны, будет потеряна возможность администрирования посредством встроенного GUIGUI – Graphical User Interface (Графический интерфейс Пользователя., но взамен станет доступна вся мощь структурированности и возможностей управления, присущих реализации BIND. Исходные коды и бинарные сборки можно найти на сайте ISC по следующему адресу:

    http://www.isc.org/products/BIND/

    • При установке не делаем

    Сейчас о том, чего делать не следует.

  • Не загружайте "Службы сертификатов": им следует быть службой только для внутреннего пользования, так как закрытые ключи CA [Certificate Authorities (Полномочия сертификатов)] следует держать в тайне, и обычно вы не предлагаете регистрацию сертификата всяким пользователям Интернета. Общепринятым правилом является содержание корпоративных "Полномочий сертификатов" в жестко контролируемой, безопасной среде в изолированной внутренней сети. Более того, поскольку Lotus Domino вероятнее всего будет предлагать использование SSL, для данного компонента – не для операционной системы – будет лучше принять это предложение, что является еще одним аргументом в пользу того, чтобы не загружать "Служб сертификатов".

    Если требуется системный мониторинг, установите SNMP из "Набора для управления и мониторинга" (Management and Monitoring Tools), но соответствующим образом измените "имена сообществ" (community) для чтения и записи.

  • Не делайте установку в домен или в структуру "Активных каталогов" (Active Directory). Нет никаких разумных причин брандмауэру, DMZ-серверу, внешнему серверу DMZ или серверу DNS принимать участие в работе домена.
    •

    Политики Windows 2000

    Если укрепление Windows NT 4.0 показалось несколько бессистемным, то на самом деле так оно и есть. Нет никакого простого способа определить и применить все изменения реестра, файловой системы, настроек сети и политики пользователь/группа. Хуже того, нет никакого простого способа следить за внесенными изменениями для гарантии того, что изменения в политике не были отменены взломщиками, установленным программным обеспечением или примененным пакетом обновлений.

    С выходом Windows 2000 корпорация Microsoft ввела замечательный набор интегрируемых инструментов для "Консоли управления Microsoft" (Microsoft Management Console, MMC). Набор "Шаблонов безопасности" (Security Templates Tool) позволяет системным администраторам выбирать, просматривать и даже создавать самостоятельно шаблоны политики безопасности. Набор для "Конфигурации и анализа системы безопасности" (Security Configuration and Analysis Tool) дает системным ад министраторам возможность не только применять все эти политики одним простым действием, но и осуществлять наблюдение за сделанными изменениями, чтобы видеть, не изменилось ли чего впоследствии.

    Изначально "Набор шаблонов шезопасности" и "набор для конфигурации и анализа системы безопасности" не видны в MMC. Для управления серверными политиками и настройками оба эти инструмента следует туда добавить.

    Существует много пакетных шаблонов безопасности, среди которых и "Высокая безопасность для рабочих станций" (High Security for Workstations), которые определены в шаблоне HISECWS.INF. Кроме того, Microsoft выпустила "Шаблон высокой безопасности", предназначенный для Web-серверов. Шаблоны безопасности включают в себя большинство изменений в политике и в реестре, сделанные ранее для Windows NT 4.0. Шаблон безопасности HISECWEB.INF имеется в наличии на сайте Microsoft по следующему URL:

    http://support.microsoft.com/support/misc/kblookup.asp?id=Q316347

    Для использования шаблона выполните следующие шаги:

  • Скопируйте шаблон в папку %windir%\security\templates.
  • Откройте "Набор шаблонов безопасности" и тщательно просмотрите его настройки.
  • Откройте "Набор для конфигурации и анализа системы безопасности" и загрузите шаблон.
  • Кликните правой кнопкой мыши на "Наборе для конфигурации и анализа системы безопасности" и выберите "Анализировать компьютер" (Analyze Computer Now) из появившегося меню.
  • Дождитесь окончания работы.
  • Просмотрите найденное и, если необходимо, обновите шаблон.
    •

    Уделите некоторое время просмотру и чтению индивидуальных шаблонов. Вы можете сделать это либо посредством "Набора шаблонов безопасности", либо вручную при помощи текстового редактора вроде WordPad. Пробегите глазами по предлагаемым изменениям, чтобы определить, имеют ли они смысл для размещения в данной ИТ системе конкретного приложения. Готовый шаблон из "Набора шаблонов безопасности" можно использовать как основу для разработки индивидуального шаблона безопасности. После получения шаблона, удовлетворяющего нашим требованиям, следующий шаг – проанализировать, как он повлияет на сервер.

    Для загрузки шаблона используйте "Набор для конфигурации и анализа системы безопасности"; правый клик на иконке "Набора для конфигурации и анализа системы безопасности"; выберите "Анализировать компьютер". Найденное будет отображено на правой панели, показывая установки шаблона, текущие установки сервера и любые несоответствия. Просмотрите найденное и, если необходимо, настройте шаблон.

    После того как шаблон безопасности был полностью настроен со всеми соответствующими разрешениями, политиками, установками реестра и ограничениями, кликните правой кнопкой мыши на иконке "Набора для конфигурации и анализа системы безопасности" и выберите "Анализировать компьютер". Затем откиньтесь на спинку стула и позвольте программе закончить свою работу.

    У "набора для конфигурации и анализа системы безопасности" есть очень хороший эквивалент командной строки. Для анализа, настройки, обновления и сопоставления текущей серверной политики с вашим известным шаблоном можно использовать SECEDIT. Он удобен тем, что может быть запущен из сессии Telnet. Однако управлять сервером через нешифрованную удаленную сессию не рекомендуется.

    Укрепление, относящееся к работе с приложениями

    Ориентированные на приложения серверы, обитающие внутри брандмауэра, потребуют запуска дополнительных служб, которые будут предлагаться интернет-аудитории. Поскольку существует огромное количество приложений и вообще невообразимое множество различных комбинаций настроек этих приложений, попытка описать конфигурацию даже самых общих из них, таких, как HTTP, FTP и SMTP, выходит далеко за пределы данного курса.

    Если же ничего больше не делать, приложения примеров, устанавливаемые по умолчанию с IIS и различными компонентами, следует удалить. Приложения-примеры и их каталоги приведены в табл. 9.1.

    Месторасположение приложений-примеров, устанавливаемых вместе с IIS
    Приложение Куда установлено
    IIS \inetpub\iissamples
    IIS SDK \inetpub\iissamples\sdk
    Admin Scripts \inetpub\AdminScripts
    Data Access \Program Files\Common Files\System\msadc\Samples

    Нужно сказать, что существуют реальные документы, которые дают замечательную отправную точку для должной настройки более общих служб приложений DMZ-сервера:

  • Microsoft Windows NT 4.0 and IIS 4.0:

    http://www.microsoft.com/technet/security/iischk.asp

  • Microsoft Windows 2000 Server and IIS 5.0:

    http://www.microsoft.com/technet/security/iis5chk.asp

  • Microsoft SQL Server:

    http://www.microsoft.com/technet/SQL/Technote/secure.asp

    http://www.sqlsecurity.com/faq.asp

    •

    Этим мы завершаем наше обсуждение Windows 2000. Хотя между укреплением Windows NT 4.0 и Windows 2000 и есть некоторые совпадения, инструменты и методы с течением времени тем не менее эволюционировали. В результате при помощи политик процесс укрепления сервера Windows 2000 значительно менее бессистемный, нежели процесс укрепления сервера Windows NT 4.0.

    9.3.3 Укрепление рабочей станции Windows

    До настоящего момента основное внимание уделялось укреплению серверных конфигураций, чтобы сделать их более устойчивыми к атакам. Поскольку безопасность является суммой всех своих составных частей и в то же время наиболее уязвима в своей самой слабой точке, важно также обсудить и процесс укрепления конфигураций рабочих станций, особенно тех, которые работают под управлением операционных систем Windows (NT, 2000, XP), так как именно они на момент публикации данной книги были самыми распространенными настольными операционными системами.

    Также это является фундаментальной областью знаний о безопасности, в которой постоянно обнаруживаются все новые и новые слабые и уязвимые места во всех ИТ- системах, и операционная система Windows в этом плане не исключение.

    В результате, если нет систематического процесса по поддержанию конфигураций ИТ-систем (серверов и рабочих станций) в соответствии с последними обновлениями поставщика (в форме патчей или пакетов обновлений), последствия будут слишком предсказуемы: эти системы падут жертвой взлома.

    Этот раздел сосредоточивает свое внимание на рекомендациях по выбору инструментов, методик и технологий по укреплению рабочих станций Windows NT, 2000 и XP; и в частности на том, как применять патчи и настраивать эти системы для лучшей их защиты от компрометации. Рассмотренное в предыдущих разделах также следует принимать во внимание, так как у Windows в качестве серверной операционной системы и Windows в качестве рабочей станции много общего.

    Поскольку в нашем курсе речь идет о продуктах Lotus Collaborative, данный список не является исчерпывающим. Точно так же, если приведено число уязвимых мест, которые должны быть освещены для данных версий операционной системы Windows, совершенно невозможно составить список, который будет включать в себя рекомендации по всем конфигурациям. Основная же идея состоит в том, чтобы предоставить самую базовую информацию для стимуляции желания узнать больше и уменьшения риска компрометации настолько, насколько это только возможно.

    Мы рекомендуем вам прочитать статью Microsoft "Семь шагов к персональной компьютерной безопасности" ("Семь Steps to Personal Computing Security"), которая доступна на их корпоративном сайте по следующему URL:

    http://www.microsoft.com/security/articles/steps_default.asp

    В конечном итоге здесь мы пытаемся сфокусировать наше внимание на более защищенных конфигурациях Windows, а точнее на тех, которые построены вокруг ядра Windows NT (NT 4.0, 2000 и XP). Этот раздел не затрагивает конфигураций, построенных на ядре Windows "9x" – 95, 98, 98SE и ME, поскольку они создавались без учета аспектов безопасности и взламываются слишком легко. Организациям, действительно заботящимся о своей ИТ-безопасности, но имеющим рабочие станции на основе ядра 9x, следует рассмотреть перспективу замены их на конфигурации с ядром Windows NT.

    Использование учетной записи "Администратор"

    Для поддерживания рабочей станции Windows NT, 2000 или XP вам потребуется доступ к учетной записи "Администратор". (Это отличается от Windows 95, 98 и ME, в которых все пользователи имеют полные права доступа ко всей системе. Фактически это одна из главнейших причин, почему системы 9x являются незащищенными по своему дизайну.) В этом разделе мы обсудим привилегии, дающиеся конечному пользователю по отношению к учетной записи "Администратор", и затем рассмотрим защиту этой учетной записи.

    И наоборот, лучше разработать такие конфигурации рабочей станции Windows, которые не наделяют конечного пользователя администраторскими правами (или предоставление им привилегий администратора) на их машинах. Ограничение на то, какое программное обеспечение конечные пользователи могут установить на свои рабочие станции и каким образом, предохраняет многие "дыры" безопасности от вскрытия и делают всю ИТ-инфраструктуру более безопасной.

    Это обычно не согласуется с желаниями большинства пользователей. Большинство из них полагает, что на корпоративной рабочей станции (или даже на терминале) им следует обладать такой же степенью свободы, как и на своем собственном домашнем компьютере. Это вполне понятно, но машины не являются собственностью конечного пользователя, они являются собственностью организации. А значит, организации следует иметь в наличии политику безопасности, в соответствии с которой конечные пользователи не обладают на своих машинах администраторскими правами. (Если у организации ее нет, самое время вернуться к лекции 2, "Методологии построения систем безопасности", и написать набор соответствующих политик безопасности вместе с правилами пользования для конечного пользователя.) Если же такая политика имеется, данная тема закрыта для обсуждения и вам не придется тратить кучу времени на объяснения пользователям.

    Учетная запись "Администратор" имеет привилегии делать с системой Windows все что заблагорассудится. Хакеры-злоумышленники будут выискивать подсоединенные к Интернету рабочие станции, в которых учетная запись "Администратор" имеет либо тривиальный пароль, либо вообще не имеет пароля как такового. Как только эта учетная запись взломана, хакер получает полный контроль над рабочей станцией.

    Поэтому есть два варианта: один – иметь учетную запись "Администратор", другой – избавиться от нее (хотя и не полностью). Давайте рассмотрим их оба.

  • Если учетная запись "Администратор" остается как есть, ей следует быть защищенной нетривиальным паролем, который трудно угадать. Вот некоторые советы для генерации такого пароля:
  • В нем должно быть как минимум восемь символов. (Его следует рассматривать как парольную фразу, и, таким образом, в нем может быть символов намного больше восьми.)
  • Следует использовать по меньшей мере три различных типа символов (алфавитные, числовые и, если возможно, знаки пунктуации).
  • Он должен быть настолько случайным, насколько это возможно; вариаций словарных слов следует избегать.
    •
  • Потенциально более эффективный подход – создать альтернативную администраторскую учетную запись, с другим именем, которая использовалась бы для всех административных задач и имела бы все привилегии учетной записи "Администратор". То есть удалите оригинальную учетную запись "Администратор" и создайте фиктивную учетную запись "Администратор", без привилегий. Как только взломщики попытаются взломать эту учетную запись, запись о них будет оставлена в журналах аудита.

    • Установка и поддержка антивирусной защиты

    Важно обеспечить чистоту конфигурации рабочей станции, чтобы никакой файл не был взломан во время его обычного режима использования и чтобы никакие вновь вводимые в систему файлы не причинили ей вреда.

    Вот почему так важно иметь установленную антивирусную защиту, которая может выполнять периодическое сканирование файловой системы и памяти для обнаружения вирусов, "троянов" и "червей", возможно, обосновавшихся там. Так же как ИТ-системам требуются постоянное наблюдение и улучшения для поддержания их в соответствии с последними изменениями, так и антивирусные файлы не являются исключением. Чтобы этот инструмент безопасности был эффективным, в него должны входить самые последние антивирусные базы. Для поддержания этих баз файлы, содержащие их, следует обновлять еженедельно.

    У большинства организаций есть лицензии на Norton Anti-Virus (NAV), McAffee's VirusScan или на другие антивирусные программы, которые охватывают все рабочие станции. Нет причин, почему бы не использовать их на всех машинах. Антивирусная защита – это первая линия обороны рабочих станций Windows.

    Обновление при помощи центра обновлений Microsoft (Microsoft Update Center)

    Microsoft попыталась сделать управление обновлениями на рабочих станциях Windows относительно легким. Установка текущих исправлений и пакетов обновлений посредством центра обновлений Microsoft состоит из нескольких нажатий на кнопки и зачастую перезагрузки (или иногда нескольких перезагрузок), так что на первый взгляд процесс кажется несколько нудным. Тем не менее система проработала достаточно долго и хорошо зарекомендовала себя, и, исходя из количества ее пользователей, мы должны заключить, что она действительно не сложна в использовании.

    Следуйте нижеприведенным шагам для обновления конфигурации рабочей станции:

  • Используя учетную запись "Администратор" или любую другую запись с аналогичными привилегиями, зайдите в центр обновлений Microsoft (http://windowsupdate.microsoft.com/) и кликните на ссылке "Product Updates".
  • Сайт выделит подсветкой, есть ли в найденном какие-нибудь критические обновления ("CRITICAL UPDATES AND SERVICES PACKS"); их следует применить немедленно. Выберите подходящие обновления и нажмите на иконку "Загрузить" (Download).
    •

    Всегда есть риск того, что исправление или пакет обновлений может нежелательно повлиять на конфигурацию рабочей станции. Обратная сторона медали – неприменение критического патча с большой вероятностью оставит рабочую станцию открытой для взлома. Стоит помнить, что у патчей, вышедших достаточно давно, очень низкая вероятность оказаться неадекватными, так как с тех пор они уже были протестированы другими людьми.

    Применение пакетов обновлений и текущих исправлений может показаться утомительной и неблагодарной работой, но причина того, что такое множество червей буйно расплодилось по Интернету, в том, что они в точности используют известные и опубликованные "дыры". В общем, применение патчей к ИТ-системам, и к рабочим станциям в частности, – очень важная линия обороны.

    Советник по основным направлениям безопасности Microsoft (Microsoft Baseline Security Advisor, MBSA)

    Советник по основным направлениям безопасности Microsoft определит патчи, которые необходимо применить. URL для MBSA следующий:

    http://www.microsoft.com/technet/security/tools/mbsahome.

    MBSA поставляется как стандартный набор инструментов для установки. Он был выпущен в апреле 2002 г. и заменил собою более ранний, основывающийся на Web инструмент, называемый Microsoft's Personal Security Advisor (MPSA), который был предназначен для рабочих станций. MBSA – очень хороший инструмент для оценки степени защищенности рабочих станций Windows NT 4.0, Windows 2000 или Windows XP (также его можно использовать для оценки уровня безопасности серверов, работающих под управлением тех же версий операционной системы Windows). Еще он очень полезен для оценки безопасности серверов MS IIS и MS SQL.

    MBSA определит патчи (пакеты обновлений и текущие исправления), которые следует применять. Еще MBSA выдаст рекомендации по нескольким важным настройкам защиты. Он работает достаточно хорошо, и системные администраторы, вероятно, найдут его более чем полезным для обеспечения безопасности ИТ-систем, находящихся под их контролем и ответственностью.

    Для установки пакета надо обязательно обладать доступом к учетной записи Администратор и не менее важно также входить в систему как администратор для сканирования рабочей станции или сервера на наличие проблем. Если инструмент используется для сканирования безопасности, он загрузит и запустит содержимое, полученное от Microsoft, которое по идее предоставит самые последние и самые лучшие советы и настройки конфигурации на основании информации, предоставленной MBSA.

    При применении патчей хорошим стилем считается агрессивная стратегия. В конце концов, если поставщик рекомендует применить патчи, было бы совершенно глупо – или для этого понадобятся действительно веские причины – игнорировать этот совет. К слову, если продукт был взломан через какое-то уязвимое место, а патч, закрывающий это место, уже был выпущен ранее поставщиком, но не применен, очень трудно будет после этого идти с жалобой к поставщику.

    Что же касается самих патчей, лучше всего опробовать их на нескольких системах до того, как ставить на все ИТ-системы. Были случаи, когда Microsoft выпускал патч, который не работал или вызывал другие проблемы. Тем не менее вы можете быть в более чем достаточной мере уверенными в любом патче, с момента выхода которого прошло несколько недель, поскольку к этому моменту многие люди уже загрузили его, посмотрели, не вызывает ли он каких проблем, и, если таковые обнаружились, сообщили о них.

    Рекомендации MBSA могут быть несколько раздражающими при применении, но все они действительно стоят тех усилий. Обычно рекомендации MBSA точно такие же, какие предложили бы любые другие хорошо известные организации, занимающиеся безопасностью.

    IIS Web-сервер Microsoft

    Многие системы Windows NT 4.0, 2000 и XP сконфигурированы для работы с Web сервером, который называется "Информационный сервер Интернета Microsoft" (Internet Information Server, IIS). Он стал источником слишком большего числа взломов, самый известный из которых – червь "Code Red", который существует и по сей день, выискивая непропатченные или плохо настроенные серверы IIS. Ниже приводится то, что следует сделать для любой ИТ-системы, запускающей MS IIS Web-сервер.

  • Остановите MS IIS Web-сервер, если он не нужен.

    Если конечным пользователям MS IIS Web-сервер не нужен или если конфигурация сервера организации не требует его, будет намного безопаснее не запускать этот сервер вообще. Логика – и совершенно справедливая – в том, что в первую очередь Web-сервер (такой, как IIS) невозможно взломать, если он не запущен. Точно так же, если он не работает, то в плане безопасности для системных администраторов одной головной болью меньше. В конце концов, можно вообще удалить подсистему IIS с рабочей станции или сервера, но, пожалуй, лучше все-таки будет только его остановить, потому что между различными компонентами версий операционной системы Windows существует слишком много взаимозависимостей, чтобы быть на 100 % уверенным в том, что удаление компонентов подсистемы позже не повлияет на что-нибудь еще.

  • Обновляйте MS IIS Web-сервер.

    Обновления для MS IIS Web-сервера можно найти при помощи инструмента MBSA, который обсуждался ранее. Как уже упоминалось, он эволюционировал из более раннего, основанного на Web-интерфейсе инструмента (который больше уже недоступен). Причиной для такой эволюции стала невозможность отследить текущие исправления для MS IIS Web-сервера. Фирме Microsoft пришлось рекомендовать "инструмент для проверки текущих исправлений", особенно для IIS, который больше не требуется для Windows 2000 и Windows XP.

  • Посмотрите "Инструмент для проверки текущих исправлений системы безопасности в сетях Microsoft" (Microsoft Network Security Hot Fix Checker), Hfnetchk.exe, который находится по следующему URL:

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;q303215

  • Загляните также в "Часто задаваемые вопросы об инструменте для проверки текущих исправлений системы безопасности в сетях Microsoft", Hfnetchk.exe, (Q305385) по адресу:

    http://support.microsoft.com/default.aspx?scid=kb;en-us;Q305385

    •

    Упомянутые патчи все есть в "Бюллетене безопасности Microsoft", который находится на сайте Microsoft Technet Web по следующему URL:

    http://www.microsoft.com/technet/security/current.asp

    И наконец, Microsoft опубликовал инструмент для запирания MS IIS Web-сервера и закрытия многих общеизвестных "дыр". См. "Инструмент для Запирания IIS Microsoft", который находится по следующему URL:

    http://www.microsoft.com/technet/security/tools/tools/locktool.asp

    Microsoft SQL-сервер

    Некоторые системы Windows NT 4.0, 2000 и XP настроены с поддержкой сервера баз данных, способного обрабатывать запросы языка структурных запросов (Structure Query Language, SQL). Этот сервер баз данных называется MS SQL-сервером. Так же как и MS IIS, данный сервер стал источником нескольких "дыр". Самая известная – червь "Slammer".

    Небольшими усилиями Microsoft SQL-сервер можно сделать безопасным. Если его не обезопасить, шансы на то, что он будет взломан, слишком велики. Для любой ИТ-системы с работающим на ней MS SQL-сервером рекомендации для защиты системы следующие:

  • Остановите MS SQL-сервер, если он не нужен.

    Если конечным пользователям MS SQL-сервер не нужен или если конфигурация сервера организации не требует его, будет намного безопаснее не запускать этот сервер вообще. Опять же, логика в том, что в первую очередь сервер баз данных (такой, как MS SQL-сервер) невозможно взломать, если он не запущен. Точно так же, если он не работает, то в плане безопасности для системных администраторов одной головной болью меньше.

    Далее, если MS SQL-сервер все-таки нужен, лучше установить его на какой-нибудь другой машине. Приложения для работы с базами данных не обязательно запускать на той же машине, на которой находится и сервер баз данных.

    Хотя и можно вообще удалить подсистему MS SQL-сервера с рабочей станции или сервера, но, пожалуй, лучше все-таки будет только его остановить, потому что между различными компонентами версий операционной системы Windows существует слишком много взаимозависимостей, чтобы быть на 100 % уверенным в том, что удаление компонентов подсистемы позже не повлияет на что-нибудь еще.

    И последнее, если MS SQL-сервер уже намеренно установлен, его следует немедленно отключить до тех пор, пока к нему не будут применены все патчи и текущие исправления и пока не будет завершен процесс укрепления.

  • Обновляйте MS SQL-сервер

    Обновления для MS SQL-сервера (пакеты обновлений и текущие исправления) можно найти при помощи инструмента MBSA, который обсуждался ранее. Все еще не установленные патчи должны быть применены как можно быстрее, и ни один MS SQL-сервер не следует открывать до тех пор, пока к нему не были применены все патчи. MBSA определит некоторые проблемы, которые в противном случае могли быть упущены и которые следует изучить незамедлительно.

  • См. "Инструмент для проверки текущих исправлений системы безопасности в сетях Microsoft", Hfnetchk.exe, (Q303215), уже упоминавшийся ранее.
  • Загляните также в "Часто задаваемые вопросы об инструменте для проверки текущих исправлений системы безопасности в сетях Microsoft", Hfnetchk.exe, (Q305385).
    •

    Упомянутые патчи все есть в "Бюллетене безопасности Microsoft", который находится на сайте Microsoft Technet Web.

    Тесты на проникновение

    Многие поставщики продуктов безопасности распространяют бесплатные инструменты для оценки ИТ-систем (тем самым в действительности они подталкивают вас к покупке их товаров). Эти поставщики проверяют, насколько хорошо укреплена тестируемая система, при помощи так называемого теста на проникновение.

    Например, Symantec, создатель антивируса Norton Anti-Virus, предлагает Symantec Security Check" (Проверка безопасности от Symantec), в котором можно найти несколько очень хороших бесплатных услуг. Их можно найти по следующему URL:

    http://security.symantec.com/ssc/home.asp

    Среди предоставляемых бесплатных услуг инструменты "Scan for Security Risks" (Сканирование на наличие угроз для безопасности, т. е. как раз тест на проникновение), "Scan for Viruses" ("Сканирование на наличие вирусов", очень похож на сам Norton Anti-Virus) и "Trace a Potential Attacker" (Для выслеживания потенциальных взломщиков, данного IP-номера). Эти инструменты очень компетентны в том, что они делают.

  • Если система, которую нужно протестировать, уже укреплена, то "Scan for Security Risks" будет прекрасным средством ля проверки того, что работа была выполнена должным образом. Также он определит, нет ли в ИТ-системе нежелательных служб, установленных кем-то из наиболее распространенных троянских коней.
  • Если система еще не укреплена или если система укреплена, но только до того момента, когда антивирусный сканер еще не установлен "Scan for Viruses" будет превосходным выбором, с чего начать. Он просканирует файловую систему ИТ-системы на наличие зараженных файлов. После этого, независимо от результатов сканирования, следует установить антивирусный сканер и применить к рабочей станции соответствующие меры по укреплению.
    •

    Замечания. Есть два очень важных замечания.

    Во-первых, инструменты Symantec подгружают в ИТ-систему содержимое ActiveX. Обычно подобного не следует допускать, кроме тех редких случаев, когда организации, делающей это, можно доверять. Что касается упомянутых здесь специфических инструментов, Symantec – компания, проработавшая долго и упорно в сфере безопасности и более чем завоевавшая себе доверие. Кроме того, ее инструменты действительно работают хорошо и помогают обеспечить лучшую безопасность; не отвергайте их.

    Во-вторых, Symantec тем не менее тоже делает ошибки. Например, такая проблема безопасности, как переполнение буфера ActiveX в "Проверке безопасности Symantec" от 25.06.2003, которая была открыта (и исправлена) в компоненте ActiveX, используемом для реализации проверки безопасности. Подробности находятся по адресу:

    http://www.sarc.com/avcenter/security/Content/2003.06.25.html

    У Symantec нет монополии на подобные устройства. Другие поставщики продуктов безопасности выпускают сходные инструменты, которые для поднятия уровня безопасности ИТ-системы не менее компетентны. Например, Gibson Research Corporation предлагает популярный тест "ShieldsUp!", который является еще одним очень хорошим тестом на проникновение. Он находится по следующему URL:

    http://grc.com/intro.htm

    Важно! Представленные здесь предположительные инструменты выступают в качестве примеров, а не поддержки или рекламы компаний Symantec или Gibson Research. На рынке есть и другие инструменты и поставщики услуг безопасности, на которые тоже стоит обратить внимание, чтобы гарантировать, что к ИТ-системам организации может быть применен достойный уровень укрепления.

    9.3.4 Дальнейшее чтение

    В этом курсе невозможно охватить все аспекты укрепления серверов и рабочих станций Windows.

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

  • Безопасность от Microsoft (http://www.microsoft.com/security/)
  • "Семь шагов к персональной компьютерной безопасности":

    http://www.microsoft.com/security/articles/steps_default.asp

  • "Инструменты и контрольные списки безопасности"

    http://www.microsoft.com/technet/security/tools/tools.asp

    •
  • Безопасность Windows NT и конфигурационные ресурсы от координационного центра CERT (http://www.cert.org/tech_tips/win-resources.html)
  • "Руководство по настройке Windows NT"

    http://www.cert.org/tech_tips/win_configuration_guidelines.html

  • "Безопасность домашней сети"

    http://www.cert.org/tech_tips/home_networks.html

  • "Ресурсы о компьютерных вирусах"

    http://www.cert.org/other_sources/viruses.html

  • Читальный зал информационной безопасности в институте SANS (http://www.sans.org/rr/index.php)
  • "Вопросы по Windows 2000"

    http://www.sans.org/rr/catindex.php?cat_id=66

    • Данные – всего лишь отправная точка. В Web есть множество других сайтов, на которых имеется прекрасная информация.

    9.4 Укрепление систем UNIX

    В этом разделе мы рассмотрим укрепление UNIX-серверов. Системы UNIX и системы Windows в достаточной мере отличаются друг от друга, чтобы для них требовались совершенно раздельные обсуждения.

    Относительно UNIX говорят, что самое замечательное в стандартах – это то, что их так много и можно выбирать. UNIX выпускается целым рядом семейств, два доминирующих из которых произошли от BSD и от ATT System V. Некоторые из характерных реализаций UNIX в этих двух категориях приведены ниже.

    Системы UNIX, полученные из BSD:

  • OpenBSD,
  • FreeBSD,
  • NetBSD,
  • BSDi,
  • MacOS X,
  • SunOS 4.
  • Системы UNIX, полученные из System V:
  • HP-UX,
  • Solaris (SunOS 5).
    •

    Замечание. AIX, по сути, подходит к любой категории, поддерживая команды, которые будут работать в стиле либо BSD, либо System V в зависимости от того, как они вызываются. Из-за этого отличия AIX мы посвятили отдельный раздел. См. 9.5, "Укрепление операционной системы AIX".

    Из этого возникает вопрос, куда же отнести Linux? Это хороший вопрос, так как Linux не является производным от какого бы то ни было UNIX. Тем не менее – и это полностью зависит от дистрибутива – он придерживается семантики и BSD и System V. Фактически, чтобы не давать неоднозначных ответов, сам по себе Linux – это просто ядро операционной системы и несколько драйверов поддержки. Большинство дистрибутивов Linux использует систему GNU (http://www.gnu.org), из-за чего они называются дистрибутивами GNU/Linux. Существуют сотни доступных дистрибутивов GNU/Linux, но даже "лидирующая пятерка" различается по своим командам по умолчанию, начальным загрузочным скриптам, раскладкам файловой системы, включая утилиты и системы пакетов.

    На основании всего этого надо сказать, что, в отличие от Windows NT, Windows 2000 и Windows XP, описание того, как укреплять сервер UNIX или Linux, – намного более сложная задача.

    Тем не менее данный раздел дает некоторые общие процедуры, которые можно применять ко всем версиям UNIX и дистрибутивам Linux. После него приведены некоторые ссылки на реальные документы в Интернете, которые отслеживают имеющиеся в наличии данные и релизы, а также углубляются в более детальные описания того, как укреплять сервер для конкретной задачи.

    9.4.1 Общие шаги по укреплению серверов UNIX и Linux

    Говоря в целом, системное укрепление сервера UNIX (сюда входят и серверы GNU/Linux) – это целая глобальная философия системной безопасности, которая особенно фокусируется не только на обнаружении, но и на предотвращении. Сюда входят и удаление ненужных служб из базовой конфигурации операционной системы, и ограничение пользовательского доступа к системе, и накладывание ограничений на пароли, и контроль прав пользователей и групп, и разрешение системного учета.

    Во время процедуры минимизации, описываемой в этом разделе, следует идентифицировать и запретить те компоненты и службы операционной системы, которые не нужны для выполнения текущей задачи.

    Например, если система используется в качестве файлового сервера, от разрешения служб электронной почты (e-mail) будет немного пользы. Служба e-mail запускается от имени root, и у взломов, связанных с электронной почтой, долгая история. Процедуры должного системного укрепления взывают к тому, чтобы подобные службы были отключены, что приводит к конечной системе с минимальной вероятностью взлома.

    Процесс укрепления серверов UNIX или GNU/Linux начинается с самого момента установки. Соответственно выполняются дополнительные действия, в которые входят:

  • как устранение возможных точек атаки остановкой или перенастройкой служб и портов, так и удаление ненужных библиотек;
  • добавление устойчивости файловой системе посредством рассмотрения файловой принадлежности и разрешений;
  • надлежащая настройка пользовательских учетных записей, чтобы привилегированные учетные записи использовались только тогда, когда они специально определены (и необходимы), и чтобы все учетные записи имели соответствующие нетривиальные пароли.
    •

    Некоторые общие рекомендации по конфигурированию серверов UNIX, чтобы сделать их более безопасными по умолчанию, находятся на Web-сайте CERT по следующему URL:

    ftp://info.cert.org/pub/tech_tips/UNIX_configuration_guidelines

    9.4.2 Разбиение на разделы для лучшей защиты

    Обычно, вне зависимости от устанавливаемого клона UNIX, количество дисковых разделов определено и каждый из них имеет свое собственное специальное предназначение, это такие разделы, как SWAP и /tmp. Кроме этих очевидных разделов, следует проделать некоторую работу для защиты от атак типа "отказа от обслуживания" ( denial-of-service ) "нехватка места на диске" ( out-of-disc-space ).

    Некоторые типичные атаки пытаются создать непомерное образование журнальных данных: или заполняют файловую систему сервера UNIX большими файлами через FTP, или, если ваш Domino-сервер не настроен должным образом, пытаются послать чрезмерно большие сообщения, которые заставят файл mail.box вырасти соответственно и занять требуемое место на жестком диске.

    Самый лучший способ защититься от такого рода атак – это сегментировать иерархию файловой системы на несколько отдельных физических разделов.

    Корневой раздел ( "/" ). Этот раздел может быть маленьким, потому что обычно на нем находится только ядро, подразумевающее необходимые файлы, библиотеки и конфигурацию для начальной загрузки, которые находятся в /bin, /sbin, /etc и /lib. Доступ к присоединенным устройствам осуществляется через папки /dev и /devices. Многие дистрибутивы GNU/Linux хранят ядра и символьные данные в папке /boot, в то время как библиотеки ядра расположены в /lib.

    Раздел /usr. Как правило, это раздел для хранения приложений, доступных обычному пользователю. Обычно в /usr не содержится никаких данных или файлов конфигурации, способных изменяться; по этой причине – как дополнительная мера безопасности – его можно подсоединять (монтировать, mount) только для чтения.

    Раздел /var. На этом разделе хранятся системные журналы и данные таких служб, как почта, Web, базы данных, принтеры, запущенные службы, управление пакетами и т. д. Если под корневым каталогом/создается всего один отдельный раздел, /var как раз и есть один из тех, которые следует создавать отдельно.

    Каталог /usr/local ( /opt в Solaris). Эти папки часто содержат локально установленные "по выбору" программное обеспечение, конфигурационные файлы и данные. На каталог /usr/local обычно не влияют обновления операционной системы. В зависимости от того, каким образом эти каталоги используются системой UNIX, они тоже могут быть подсоединены только для чтения.

    Детали могут варьироваться в различных версиях UNIX (и дистрибутивах GNU/ Linux), так что для определения наилучшего способа установить их с ориентацией на должный уровень безопасности мы рекомендуем вам прочитать замечания по установке, которые поставляются вместе с той версией UNIX, которая планируется к установке.

    9.4.3 Запрет внешней службы inetd

    Служба inetd – это "суперсервер Интернета" в UNIX. В основном это процесс-демонПроцесс-демон – это такой процесс, который постоянно находится в оперативной памяти компьютера и работает в фоновом режиме, без вывода в консоль. Аналоги – службы в Windows или резидентные программы в DOS., который вызывается во время загрузки системы и который читает текстовый конфигурационный файл, находящийся обычно в /etc/inetd.conf.

    Служба inetd слушает входящие соединения по предопределенным IP-портам. Когда соединение по заданному порту установлено, она вызывает заранее настроенную программу для обработки запроса. После того как соединение завершилось, процесс вызывает службу, которая обрабатывает запрос. Первоначальная причина для создания данной службы состояла в том, чтобы уменьшить нагрузку и ресурсы, требуемые для ИТ-системы.

    Через inetd запускается целый набор служб, и почти все из них следует запретить, как часть должным образом укрепленного сервера. Помимо стандартно-запрещаемых FTP, TFTP, Telnet и команд Berkley r*, также следует запретить и следующее.

    Служба in.named. Это демон служб разрешения имен BIND. Помимо серверов, которые специально определяются в качестве DNS-серверов организации, DNS не следует запускать на укрепленном сервере UNIX.

    Служба in.fingerd. Это демон программы finger, которую можно использовать для отображения информации о пользователе и для вывода списка пользователей, в данный момент находящихся в системе. На должным образом укрепленном сервере UNIX нет причин для афиширования подобной информации, которая могла бы оказаться полезной для предполагаемых взломщиков.

    Служба daytime. Эта служба выводит дату и время в системе в строковом формате. Не позволяйте возможным взломщикам получить дату и время системы, так как они могут воспользоваться этими данными для реализации повторяющихся атак.

    Служба time. Это служба, которая возвращает время в виде 32-битового значения, представляющего количество секунд, прошедших после полуночи 1 января 1900 г. Не позволяйте возможным взломщикам получить точное системное время.

    Служба echo. Это диагностическая служба, которая отражает входящие данные обратно к подсоединившийся машине. Не позволяйте возможным взломщикам получить информацию о системах, которые отвечают на подобные запросы.

    Служба discard. Это диагностическая служба, которая не отражает входящий поток данных обратно к подсоединившейся машине (таким образом, просто избавляясь от них). Не позволяйте возможным взломщикам посылать информацию в "черную дыру".

    Служба chargen. Это диагностическая служба, которая автоматически генерирует поток символов для отправки к подсоединившейся машине. Не позволяйте возможным взломщикам получить машину для генерации потока данных, который будет отослан другой машине в пределах или за пределами сети организации.

    Служба systat. Эта служба предоставляет список всех процессов и их статусов. Не позволяйте возможным взломщикам получать такую жизненно важную информацию.

    Служба netstat. Эта служба предоставляет список всех текущих сетевых подключений и их статусов. Не позволяйте возможным взломщикам получать такую жизненно важную информацию.

    Этот список ни в коем случае не является исчерпывающим. Для определения, какие службы могут быть установлены, что открывает уязвимые точки входа и методы для доступа к серверу и внутри сервера UNIX, следует провести надлежащее рассмотрение устанавливаемой системы UNIX.

    9.4.4 Установка и настройка tcp_wrappers

    Мы рекомендуем на укрепляемый сервер UNIX установить tcp_wrappers (созданные Wietse Venema), которые позволят вам задать контроль доступа к различным службам по ограниченному набору критериев, таких, как, например, имя пользователя, IP-адрес или домен DNS. Они невелики и чрезвычайно полезны на внутренних серверах, не только на внешних боксах, которые могут быть настроены как брандмауэры, серверы DMZ или прокси-серверы (не важно, основные ли они или резервные). Так вот, они по умолчанию устанавливаются и конфигурируются большинством дистрибутивов GNU/Linux и релизов BSD. Для тех же систем UNIX, в которых tcp_wrappers по умолчанию не установлены, исходники можно найти по следующему URL (затем их можно откомпилировать и полученные исполняемые модули установить на сервер):

    ftp://ftp.porcupine.org/pub/security/index.html

    Причина для установки такого дополнительного компонента в существующую конфигурацию UNIX состоит в том, чтобы избежать единых точек отказа (single points of failure) и обеспечить безопасность по всем уровням. Если один уровень взломан или обойден, другие уровни будут стоять на страже перед взломом.

    Полезно помнить, что большинство пробоев информационной безопасности, случайных или преднамеренных, происходит изнутри. Внимание прессы же привлекают только внешние взломы, массивные распределенные атаки вида отказа от обслуживания (DDoS, Distributed Denial of Service), горячие вирусы/"черви"/"трояны" и украденные базы данных кредитных карт.

    Добавочный компонент tcp_wrappers имеет два основных файла, которые разрешают доступ к индивидуально определенным службам. Два нижеприведенных файла проверяются на правила, определяющие доступ к индивидуальным или заданным по шаблону службам.

    /etc/hosts.allow
/etc/hosts.deny

    Как и в большинстве машин, осуществляющих фильтрацию tcp/ip-запросов (таких, как брандмауэры или серверы, доступ к которым сильно ограничен), доступ предоставляется или запрещается на основании первого же совпадающего правила.

    Правила проверяются в следующем порядке: сначала в hosts.allow, затем в hosts.deny. Будьте осторожны в использовании шаблонов KNOWN или UNKNOWN. ALL всегда будет совпадать, какие бы критерии ни тестировались. За дальнейшими подробностями по синтаксису и по написанию правил обращайтесь к man-страницеВ системах UNIX и GNU/Linux документация, как правило, поставляется в виде так называемых man-страниц (man pages), которые вызываются из командной строки командой man [параметры] "имя запрашиваемой команды/процедуры/файла/службы/темы". Например, man hosts_access или man bash. hosts_access, идущей в комплекте с tcp_wrappers.

    9.4.5 Сжатие опций по умолчанию программы sendmail

    Sendmail идет едва ли не с каждой установкой UNIX (включяя GNU/Linux) как агент по умолчанию для пересылки почты (Mail Transfer Agent, MTA). В результате такого широкого распространения по приблизительным оценкам оказалось, что sendmail обрабатывает подавляющее большинство почты в Интернете. А поскольку он запускается как suid rootАтрибут (бит) прав доступа suid (set-UID) позволяет программам запускаться от имени и с правами пользователя-владельца программы (т. е. соответствующего исполняемого файла), а не того пользователя, который запустил программу (как происходит обычно). Например, "suid root" обозначает, что программа принадлежит пользователю root и обычный пользователь исполняет ее с правами root., взлом sendmail влияет на миллионы машин.

    Последняя версия sendmail поддерживает такие новые возможности, как STARTTLS и шифрование SMTP AUTH. Если в комплект с устанавливаемой операционной системой UNIX входит более старая версия sendmail (подразумевается та, которая не поддерживает эти новые возможности), вам следует подумать об обновлении ее на самую последнюю из имеющихся в наличии. По крайней мере убедитесь, что эта версия не старее версии 8.9.3 из-за хорошо известных "дыр" безопасности.

    Чтобы разрешить Realtime Blackhole List (черный список реального времени), который помимо прочего защитит систему и пользователей от спама, в файл sendmail.mc следует вписать следующее:

    FEATURE(rbl)dnl

    Кроме того, в самом sendmail рекомендуется запретить команды SMTP VRFY и EXPN. Эти команды зачастую используются взломщиками для сбора информации о сервере. Запретите их при помощи следующего:

    define('confPRIVACY_FLAGS', 'novrfy,noexpn')dnl

    Есть несколько дополнительных флагов, которые вы можете установить, чтобы заставить sendmail вести себя более безопасным образом:

  • authwarnings: при определенных условиях в сообщения следует добавлять заголовок X-Authentication-Warning, что может сообщить почтовой системе о попытках обмана;
  • needmailhelo: требует от сайта-отправителя при начале соединения для отправки почты сначала использовать команду SMTP HELO ;
  • needexpnhelo: требует от сайта-отправителя использовать команду SMTP HELO до разрешения какого бы то ни было применения EXPN;
  • needvrfyhelo: требует от сайта-отправителя использовать команду SMTP HELO до разрешения какого бы то ни было применения VRFY;
  • noreceipts: запрещает уведомления о статусе доставки (Delivery Status Notifications, DSNs) и чтение подтверждений;
  • goaway: устанавливает все флаги, кроме restrictmailq и restrictqrun ;
  • restrictmailq: не дает возможности пользователям употреблять команду mailq для просмотра содержимого почтовой очереди;
  • restrictqrun: удерживает пользователей от обработки очереди.
    •

    Верно также, что при запущенном сервере Domino поверх операционной системы UNIX или GNU/Linux можно также sendmail отключить вообще и больше не забивать себе голову данным вопросомЕсли вы используете в качестве почтового (SMTP) сервера Domino, то вам необходимо отключить службу sendmail, так как она применяет тот же стандартный порт 25..

    9.4.6 Задачи, характерные для Linux

    В мире существует много дистрибутивов GNU/Linux. Самый маленький из них так мал, что полностью помещается на флоппи-диске 1.44 Мб (и называется Minix). У каждого производителя имеется свой собственный процесс установки, который обычно еще и изменяется от версии к версии дистрибутива данного производителя.

    Среди дистрибутивов GNU/Linux лидерами являются Red Hat, SUSE, TurboLinux, Mandrake, Caldera, Slackware и Debian. Хотя основная идея состоит в том, что следует использовать такой дистрибутив GNU/Linux, который поддерживается Domino, многие серверы могут использовать вообще другие дистрибутивы. Это происходит потому, что большое количество дистрибутивов позволяет производителям подгонять свои дистрибутивы GNU/Linux под специфические задачи, такие, как встроенные системы, маршрутизаторы и брандмауэры. Внимательно ознакомьтесь с доступными дистрибутивами и определите, который из них наилучшим образом подходит для нужд организации, исходя из того места, где должен быть размещен сервер, и его роли в общей ИТ-инфраструктуре организации.

    В свете вышесказанного из наиболее распространенных дистрибутивов особо выделяются двое, но по разным причинам.

    Red Hat. Данный дистрибутив обладает самым признаваемым именем и, как правило, первым получает любой вид корпоративной поддержки в плане коммерческого программного обеспечения или коммерческой технической службы. Многие производители, включая Oracle, IBM и Check Point, сделали релизы своих продуктов под дистрибутивы Red Hat. Это не означает, что данные программные релизы не будут работать под другими дистрибутивами GNU/Linux, но в случае каких-либо проблем производитель может не оказать поддержки вашей установке своего продукта на дистрибутиве, отличном от Red Hat.

    Debian. Этот дистрибутив тоже заслуживает упоминания. Прежде всего не потому, что он полностью бесплатен, а потому, что он поддерживается некоммерческой организацией, созданной исключительно из добровольцев. Эти добровольцы очень сильно мотивированы качеством и гордятся своими усилиями сделать Debian самым стабильным и полностью на все 100 % бесплатным дистрибутивом изо всех имеющихся в наличии. Debian зарекомендовал себя как в высшей степени стабильный и легкий в управлении и удаленном обновлении. Процесс обновления общепризнанно является самым легким среди всех дистрибутивов GNU/Linux. Установки Debian можно обновлять без необходимости перезагрузки, замещая любой из установленных пакетов и затем перезапуская его процесс, за исключением ядра ОС. Кроме того, пакетная система Debian и его пользовательские интерфейсы обеспечивают очень подробный контроль относительно того, какие пакеты, утилиты, библиотеки и файлы есть в вашей системе. Также в настоящий момент Debian поддерживает шесть различных архитектур и включает в себя более 3 900 пакетов программного обеспечения, которые можно выбрать при установке.

    Другие достойные упоминания дистрибутивы – это SUSE, являющиеся самыми предпочитаемыми в Германии и предлагающие действительно хороший инструмент для установки, называемый YAST2, который делает процесс установки дистрибутива невероятно легким. В списке поддерживаемых дистрибутивов GNU/Linux, на которых будет запускаться сервер Domino, находятся также TurboLinux и Caldera.

    Для всех дистрибутивов GNU/Linux, в которых имеется программа установки, следует выбирать установку компонентов вручную по выбору пользователя (Custom Installation) и устанавливать только те конкретные пакеты, которые требуются для установки сервера. Кроме как для удобства использования, нет никакой необходимости устанавливать пакеты для разработчиков, какие бы то ни было новые настольные системы KDE или GNOME, и определенно не X Windows (особенно в сочетании с Domino, поскольку Domino работает на сервере через консоль). К сожалению, ни один из вышеупомянутых дистрибутивов не предлагает такого варианта установки, как минимальный по объему защищенный сервер. Поэтому приходится укреплять сервер вручную.

    Во время процесса установки обязательно следует выбрать поддержку файла теневых паролей (enable shadow password); также вместо стандартной функции crypt для паролей следует выбрать хеширование MD5. Если данные опции недоступны во время установки, их можно изменить после нее. В Red Hat следует использовать утилиту setup. В Debian для разрешения или запрещения теневых паролей – утилиту shadowconfig. В других дистрибутивах GNU/Linux о подробностях по данному вопросу смотрите man-страницы. Для разрешения хеширования MD5 и включения хешей md5 в строки паролей следует отредактировать соответствующие файлы в папке /etc/pam.d.

    Также следует включить поддержку ipchains, даже если данный сервер в DMZ, так как ipchains добавляет дополнительные уровни защиты и закрывает сервер от трафика, по каким-то причинам миновавшего брандмауэр.

    Кроме того, нужно следить за информацией относительно безопасности и списками исправлений/обновлений на сайтах производителей дистрибутивов GNU/Linux. В Debian очень легко автоматически устанавливать обновления системы безопасности с помощью утилиты apt-get. В установках Red Hat, начиная с версии 6.0, для получения обновленных пакетов вашего релиза введена утилита up2date. За информацией о деталях реализации подобных инструментов, если они есть, обращайтесь к сайтам производителей данных дистрибутивов GNU/Linux.

    Для тех людей, которые решили устанавливать Red Hat Linux, существует занимающийся вопросами безопасности проект, называемый Bastille Linux, целью которого является не просто укрепить вашу установку Linux, а именно обучить администраторов, как вообще укреплять систему.

    Bastille Linux поддерживает дистрибутивы Red Hat и Mandrake LinuxВ настоящий момент проектом Bastille Linux поддерживаются следующие дистрибутивы: Red Hat (Fedora Core, Enterprise, Numbered/Classic), SUSE, Debian, Gentoo, Mandrake и HP-UX. Также в стадии бета находится разработка поддержки для Full Mac OS X., и цель данного проекта – сделать дистрибутив, и привкус UNIX в нем, более агностическим. Сам по себе продукт Bastille Linux является набором сценариев, которые задают ряд вопросов и затем дают возможность тому, кто устанавливает дистрибутив (или администратору, это не всегда бывает одно и то же лицо), применить эти модификации к своей системе. Вопросы описывают, что нужно сделать, почему это следует делать и почему делать этого может быть нежелательно. Очень познавательно, особенно для тех администраторов, которые только начинают знакомиться с Linux. Bastille Linux можно найти по следующему URL:

    http://www.bastille-linux.org/

    Еще один замечательный источник информации для администраторов – "Руководство по безопасности для администраторов Linux". Оно охватывает чрезвычайно широкий спектр тем касательно Linux и безопасности. "Руководство по безопасности для администраторов Linux" может быть найдено по адресу:

    http://www.securityportal.com/lasg/

    9.4.7 Задачи, характерные для Solaris

    Solaris по умолчанию поставляется в четырех возможных конфигурациях: базовая (Core), для конечного пользователя (End-User), для разработчика (Developer) и полный дистрибутив (Entire Distribution). Установка любой конфигурации, отличной от базовой, включает в себя большее количество служб, чем требуется для укрепления сервера. На практике же часто можно убрать даже значительную часть базовой конфигурации в зависимости от тех требований, которые предъявляются к серверу.

    О серверах Solaris есть несколько замечательных документов, опубликованных компанией Sun в своем архиве Blueprints Online, который находится по URL:

    http://www.sun.com/software/solutions/blueprints/online.html

    Следующие три статьи являются прекрасным отправным пунктом для построения безопасных серверов Solaris.

    "Минимизация операционного окружения Solaris для целей безопасности: простая, легко повторяемая и безопасная методология установки приложений" ("Solaris Operating Environment Minimization for Security: A Simple, Reproducible and Secure Application Installation Methodology"), написанная Алексом Ноордерграафом (Alex Noordergraaf) и Кейт Уотсон (Keith Watson). Хотя данная статья прежде всего описывает требования Web-сервера iPlanet, к использованию Apache, Domino или других Web-серверов предъявляются аналогичные требования.

    "Безопасность операционного окружения Solaris" ("Solaris Operating Environment Security"), написанная Алексом Ноордерграафом и Кейт Уотсон. Это обзор общих настроек безопасности сервера Solaris. В эту статью вошли некоторые особенности SPARC-архитектуры; тем не менее большая часть материала применима и к архитектуре Intel®.

    "Сетевые настройки операционного окружения Solaris, влияющие на безопасность" ("Solaris Operating Environment Network Settings for Security"), написанная опять же Алексом Ноордерграафом и Кейт Уотсон, – еще одна превосходная статья о настройке ядра и о влияющих на сетевую безопасность параметрах приложений.

    На самом деле Blueprints Online компании Sun – настоящий кладезь документации, описывающей все самое лучшее об операционном окружении Solaris, будь то Web-сервер в DMZ, брандмауэр или внутренний широкодоступный кластер Domino.

    У Ланса Шпицнера (Lance Spitzner) тоже есть замечательный документ об укреплении Solaris, в котором для построения брандмауэра Check Point FireWall-1 детально описывается процесс укрепления на нескольких последних версиях Solaris (вплоть до версии 8) под платформы Intel и SPARC. Настоящий документ находится по следующему URL:

    http://www.enteract.com/~lspitz/armoring.html

    И наконец, для Solaris тоже есть эквивалент укрепляющих сценариев Bastille-Linux, который называется TITAN. Проект TITAN и документация по нему находятся по следующему URL:

    http://www.fish.com/titan/

    9.4.8 Настройка сетевых конфигураций для целей безопасности

    Для защиты от наиболее общих атак WAN-соединений, брандмауэра и DMZ-серверов организации надо выполнить следующие простые шаги, чтобы запретить определенную функциональность TCP/IP.

    Сброс трафика с явной маршрутизацией

    Фактически есть две формы трафика с явной маршрутизацией: жесткий (Strict SourceRouted) и свободный (Loose Source-Routed). Данное отличие не играет роли, поскольку лучше сбрасывать весь трафик с явной маршрутизацией.

    Traceroute – самая известная команда, использующая явную маршрутизацию. Она позволяет провести диагностику проблемных мест в сети посредством прямого определения маршрута, по которому будут следовать контрольные пакеты.

    К сожалению, возможные взломщики могут использовать явную маршрутизацию для попытки обхода правил брандмауэра и фильтров TCP/IP. Сброс трафика с явной маршрутизацией следует осуществлять на граничных маршрутизаторах и на любых несущих шлюзах безопасности:

    в Solaris используйте следующую команду:

    ndd -set /dev/ip ip_forward_src_routed 0

    в GNU/Linux используйте команду

    echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

    Сброс направленного широковещательного трафика

    Атака Smurf типа отказа от обслуживания и подобные ей могут быть побеждены простым запретом направленного широковещания (direct broadcast) на границах маршрутизаторов и серверов, открытых Интернету:

    для Solaris используйте следующую команду:

    ndd -set /dev/ip ip_forward_directed_broadcasts 0

    Игнорирование эха широковещательных запросов ICMP (ICMP echo)

    Существует draft RFC, называемый draft-vshah-ddos-smurf-00, который находится по следующему URL-адресу:

    http://www.ietf.org/internet-drafts/draft-vshah-ddos-smurf-00.txt

    В нем утверждается, что, если в сетевом узле установлено отвечать на IP ICMP-эхо по широковещательным или множественным (multicast) адресам, узел должен убедиться в том, что адрес отправителя находится в локальной по отношению к сетевому узлу сети. Если адрес отправителя нелокален, ответ должен быть отброшен. Изменение поведения, чтобы вообще не отвечать на широковещательные сообщения ICMP, гарантирует, что ответы будут отбрасываться всегда:

    в Solaris используйте следующую команду:

    ndd -set /dev/ip ip_respond_to_echo_broadcast 0

    в GNU/Linux используйте следующую команду:

    echo 1 > /proc/sys/net/ipv4/icmp_echo_ ignore_broadcasts

    В GNU/Linux имеется дополнительный элемент управления для запрещения вообще всех запросов на эхо-ответы ICMP. Вызов следующей команды заставит ядро Linux игнорировать все запросы эха ICMP:

    echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

    Игнорирование ICMP-сообщений о перенаправлении (ICMP redirect)

    Предполагаемый взломщик мог бы попытаться перенаправить трафик с серверов организации к другому, а то и вообще к несуществующему шлюзу. Кроме того, предполагаемый взломщик мог бы попытаться вставить фальшивые маршруты в таблицу маршрутизации сервера.

    Все это может быть выполнено посредством скромного ICMP-сообщения о перенаправлении, и это очень эффективная атака типа отказа от обслуживания. Помимо блокирования ICMP-сообщений перенаправления на брандмауэре, если конечно операционная система поддерживает, следует ввести следующие дополнительные уровни защиты для игнорирования ICMP-сообщений о перенаправлении:

    в Solaris используйте следующую команду:

    ndd -set /dev/ip ip_ignore_redirect 1

    в GNU/Linux команда будет такой:

    echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

    Запрещение отправки ICMP-сообщений о перенаправлении

    Только маршрутизаторам требуется отправка ICMP-сообщений о перенаправлении. Поскольку DMZ-серверы и брандмауэр организации не занимаются маршрутизацией каких бы то ни было пакетов, совершенно нет причин отправлять их:

    в Solaris используйте следующую команду:

    ndd -set /dev/ip ip_send_redirects 0

    в GNU/Linux команда будет такой:

    echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

    Широковещательный запрос на временной штамп

    ICMP-запрос на штамп времени (ICMP type 13) позволяет одной системе запросить другую о текущем времени. Возвращаемое значение – количество миллисекунд с полуночи.

    ICMP-запросы на временной штамп используются для синхронизации часов между системами вместо использования команды rdate из-за лучшей точности.

    Индивидуальные запросы на штамп времени – это стандартная практика, но нет никакой необходимости системе отвечать на широковещательные запросы. В конце концов для синхронизации времени между серверами следует рассмотреть вариант использования NTP, поскольку для поддерживания времени оно намного лучше и, кроме того, поддерживает аутентификацию и совместную обработку нескольких источников, что делает его намного более устойчивым к фальсификации. Это дает возможность отказаться от использования ICMP типа 13 (запрос на временной штамп) и типа 14 (ответ о временном штампе) совершенно.

    В Solaris используйте следующую команду:

    ndd -set /dev/ip ip_respond_to_timestamp_ broadcast 0

    9.4.9 Удаленный сервер ведения журналов

    Одна из многочисленных техник, которые используются предполагаемыми взломщиками для скрытия своего присутствия, – это очистка любых средств журналирования, которые могут (и даже должны) быть включены. Сюда входит: ведение журнала учетных записей, системные сообщения, записи об ошибках, слежение за трафиком и т. п.

    Один из способов обойти эту проблему – вести журналы всех серверов организации на отдельной удаленной машине. Этой удаленной машине по ведению журналов следует принимать только журнальный трафик с этих серверов. Таким образом, даже если какой-то сервер был взломан, все равно останутся записи журналов для дальнейшего анализа того, что произошло.

    На журнальном сервере следует соответствующим образом настроить пакетный фильтр для отбрасывания любого трафика, кроме UDP/514. Журналы на журнальном сервере могут, помимо прочего, еще и архивироваться на съемные носители, такие ,как CD-R, WORM, или магнитную ленту.

    В UNIX имеется очень мощная централизованная система ведения журналов. Действительно, некоторые приложения ведут свои собственные файлы журналов и не пользуются syslog. Тем не менее сама иерархия файловой системы разработана с поддержкой централизованного размещения, /var/log.

    Кроме того, большинство систем UNIX и дистрибутивов GNU/Linux поставляются с автоматизированной системой ротации и управления журналами. Журналы автоматически ротируются на основании таких критериев, как размер или возраст, и могут автоматически же сжиматься (компрессироваться), переименовываться и даже архивироваться.

    Чтобы еще сильнее улучшить журнальные возможности сервера UNIX или GNU/Linux, следует стандартный syslogd заменить на более прочную, настраиваемую и безопасную альтернативу, известную как syslog-ng. В ней имеются несколько значительных улучшений по сравнению со стандартным syslogd, куда входит возможность фильтрации сообщений на основании их содержимого, а не только пар facility.priority (источник.приоритет).

    При помощи регулярных выражений информация об отдельных хостах может сохранятся в индивидуальных журналах. Syslog-ng, вероятно, уже входит в поставку операционной системы UNIX или дистрибутива GNU/Linux. Если же нет, его можно найти по следующему URL:

    http://www.balabit.hu/en/products/syslog-ng/

    На этом завершается наше обсуждение укрепления операционных систем UNIX и дистрибутивов GNU/Linux. Хотя данный материал также применим и к AIXНапример, настроить сетевую подсистему, как было показано в разделе 9.4.8, в ОС AIX можно при помощи команды "no"., в AIX присутствуют некоторые уникальные особенности, о которых будет рассказано отдельно в следующем разделе.

    9.5 Укрепление операционной системы AIX

    AIX – это открытое операционное окружение UNIX, которое обеспечивает повышенные уровни целостности, гибкости и надежности, что является существенным для удовлетворения высоких потребностей современных приложений электронного бизнеса. Такой фокус на многогранности позволяет AIX использоваться в широчайшем спектре различных задач, от работы на симметричной мультипроцессорной системе, способной обрабатывать тысячи транзакций в минуту, до запуска на отдельностоящей рабочей станции, используемой для разработки приложений.

    Поскольку одно из предназначений AIX состоит в достижении должного уровня многогранности и производительности, многие службы становятся доступными немедленно, едва только завершится процесс установки операционной системы. Но, с другой стороны, подобный подход может привести к такой конфигурации, которая будет уязвима для прорех безопасности, если систему не отконфигурировать надлежащим образом.

    Для минимизации числа возможных дыр безопасности администратор системы AIX должен быть способен идентифицировать рабочие характеристики окружения.

    В данном разделе приводится информация по укреплению AIX, но это не означает, что он должен стать единственным источником информации обо всех вопросах безопасности относительно систем AIX, например по использованию протоколов Lightweight Directory Access Protocol (LDAP) или Internet Protocol Security (IPSec). За информацией по этим и другим вопросам обращайтесь к соответствующим источникам документации, перечисленным на Web-странице IBM AIX по адресу:

    http://www-1.ibm.com/servers/aix/library/index.html

    Информация этого раздела включает в себя выработку адекватных правил составления пароля, реализацию соответствующих механизмов пользовательской безопасности, разрешение системного аудита и наблюдение за доступом к каталогам и файлам. Также затрагиваются важные вопросы безопасности X11 и CDE наряду с тем, как идентифицировать открытые коммуникационные порты и перечислить открытые файлы.

    Во время прочтения данного материала, описывающего потребности безопасности сервера AIX, важно определить те файлы, которые нуждаются в модификации, и сделать их резервные копии. Вообще резервное сохранение модифицированных файлов – всегда хорошая идея, поскольку оно позволяет вам в любой момент вернуться к предыдущей конфигурации, если возникает необходимость восстановить предыдущие настройки безопасности. После того как модификация завершена, как следует протестирована и все работает так, как запланировано, резервные файлы следует сохранить в безопасном месте вне только что защищенной системы, например на сервере резервного хранения. Такая мера предосторожности воспрепятствует неавторизованному восстановлению предыдущей конфигурации, которая бы свела к нулю все сделанные модификации по укреплению системы.

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

    9.5.1 Удаление информации с экранов регистрации

    Со стандартного по умолчанию экрана регистрации (login) AIX предполагаемые взломщики могут получить ценнейшую информацию, такую, как имя хоста и версия операционной системы. Подобная информация позволит им определить, какие существующие "дыры" можно попробовать. Так что лучше будет не отображать некоторой информации на экранах регистрации.

    Это делается редактированием параметра herald в файле /etc/security/login.cfg.

    По умолчанию он содержит приветственное сообщение, которое отображается вместе с приглашением к регистрации AIX. Для изменения этого параметра можно использовать команду chsec или непосредственно отредактировать сам файл. Далее пример применения команды chsec:

    # chsec -f /etc/security/login.cfg -a default -herald
"Only authorized use of this system is allowed.\n\nlogin: "

    Для непосредственного редактирования содержимого файла откройте файл /etc/security/login.cfg и измените параметр herald следующим образом:

    default:
herald ="Only authorized use of this system is allowed.\n\nlogin:"

    Изменение экрана регистрации CDE

    Данный вопрос безопасности не обошел и пользователей CDE (Common Desktop Environment). Экран регистрации CDE по умолчанию тоже выводит имя хоста и версию операционной системы. Чтобы помешать отображению такой информации, отредактируйте файл /usr/dt/config/$LANG/Xresources, где переменная $LANG ссылается на местный язык, установленный на машине с AIX.

    Защита неиспользуемых терминалов

    Для защиты от неавторизованного доступа неиспользуемый терминал всегда следует запирать. Оставление системного терминала незащищенным представляет собой потенциальную угрозу безопасности. Терминал просто можно запереть командой lock или, если пользовательским интерфейсом является AIX windows, командой xlock.

    9.5.2 Усиление пользовательской безопасности

    Чтобы достичь должного уровня безопасности на сервере AIX, для управления пользовательскими учетными записями следует создать непротиворечивую политику безопасности. (На самом деле это относится ко всем операционным системам, не только к AIX.)

    Безопасность пароля

    Угадывание паролей – одна из самых распространенных хакерских атак, которым подвергаются системы. Поэтому необходимы контроль и наблюдение за политикой ограничения паролей. У AIX есть механизмы для поддержания жесткой парольной политики, такие, как установление значений для следующего:

  • минимальное и максимальное число недель, которые могут пройти до и после того, как пароль может быть изменен;
  • минимальная длина пароля;
  • минимальное число символов алфавита, которые могут быть использованы при выборе пароля.
    •

    Помимо этих механизмов, можно установить даже более жесткие правила, ограничивая пароли тем, чтобы в них не содержались стандартные слова UNIX, которые могут быть взломаны. Данная функциональная возможность использует dictionlist (словарный список), для которого требуется, чтобы первоначально были установлены файлы bos.data и bos.txt.

    Для вызова dictionlist добавьте следующую строку в файл /etc/security/users:

    dictionlist = /usr/share/dict/words

    Теперь для предотвращения использования в качестве пароля стандартных UNIX-слов dictionlist будет применять файл /usr/share/dict/words.

    Запрещение входа под именем root

    Одним из наиболее распространенных методов возможных взломщиков является получение пароля суперпользователя, или пользователя с именем root. Для избежания подобного вида атак можно вообще запретить прямой доступ к ID root и потребовать от администраторов системы AIX получать привилегии при помощи команды su.

    Помимо разрешения на удаление пользователя root как точки приложения атак, ограничение прямого доступа к root позволит вам отслеживать, какие пользователи получили суперпользовательский доступ, а также время их активности. Эту информацию можно получить просмотром файла /var/adm/sulog. Другой альтернативой будет разрешить системный аудит, который тоже будет сообщать о подобном виде активности.

    Для запрещения удаленного входа для пользователя root отредактируйте файл /etc/security/user. В качестве значения переменной rlogin для записи root поставьте "false".

    До запрещения удаленного входа для root очень важно изучить и выработать планы на ситуации, которые помешали бы администратору системы AIX войти под ID-пользователя, отличного от root. Например, если домашняя файловая система пользователя заполнена, пользователь не сможет войти в систему. Если удаленный вход для root запрещен и если у пользователя, который мог бы при помощи su стать root, домашняя файловая система переполнена, то root никогда не сможет получить контроль над системой. Системные администраторы такую проблему могут обойти, просто создав для себя домашние файловые системы, большие, чем файловые системы обычного пользователя.

    Принудительное автоматическое отключение

    Еще один значительный вопрос безопасности происходит из того, что пользователи оставляют свои учетные записи без присмотра на продолжительные периоды времени. Подобная ситуация дает возможность предполагаемому взломщику заполучить контроль над пользовательским терминалом, потенциально компрометируя безопасность системы.

    Для предотвращения такого типа потенциальной угрозы безопасности можно включить автоматическое отсоединение от системы. Чтобы сделать это, отредактируйте файл /etc/security/.profile и впишите значения времени автоматического отсоединения для всех пользователей, как в следующем примере:

    TMOUT=300 ; TIMEOUT=300 ; export readonly TMOUT TIMEOUT

    В этом примере 300 – число секунд, что эквивалентно 5 минутам.

    Хотя предыдущее действие введет политику автоматического отсоединения для всех пользователей, тем не менее пользователи системы смогут обойти некоторые ограничения редактированием своих собственных индивидуальных файлов профиля. Для того же, чтобы ввести политику автоматического отключения целиком и полностью, следует предпринять авторитетные действия, снабдив пользователей соответствующими файлами профилей и убрав права на запись в эти файлы. Это действие гарантирует, что только root сможет изменить переменную окружения, INTERNAL FIELD SEPARATOR (IFS), которая берется некоторыми программами, такими, как sed, awk и cut, из файлов профиля.

    Запрещение групповых и внешних прав доступа на файлы

    Еще одна мера, которая ведет к очень прочной безопасности, – это установить по умолчанию запреты на групповые и внешние разрешения пользовательских файлов. Это можно сделать установлением значения umask для учетной записи пользователя в 077.

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

    Замечание. На машинах SP во время установки значение umask следует устанавливать в 022. Значение umask по умолчанию для нового пользователя тоже устанавливается в 022. Для повышения уровня безопасности важно после завершения установки не забыть изменить это значение на 077. Его можно задать в разделе значений по умолчанию файла etc/security/user.

    Скрытие пользовательских имен и паролей

    Чтобы добиться очень высокого уровня безопасности, убедитесь, что пользовательские ID и пароли не видны изнутри системы. ID и пароли пользователей находятся в файле .netrcЭти файлы могут создаваться пользователями. Подробнее описано в документации по ОС AIX.. Эти файлы не защищены ни шифрованием, ни каким бы то ни было кодированием, а значит, их содержимое ясно отображается в виде обычного текста.

    Чтобы найти эти файлы, запустите следующую команду:

    # find 'awk -F: '{print $6}' /etc/passwd' -name .netrc –ls

    После того как данные файлы были найдены, их следует удалить. Более эффективным способом хранения паролей будет установка Kerberos.

    Установка опций пользовательского пароля

    Табл. 9.2 приводит рекомендуемые значения для некоторых атрибутов безопасности, относящихся к пользовательским паролям. Парольные опции находятся в файле /etc/usr/securityЗдесь ошибка: имеется в виду файл /etc/security/user ..

    Данный файл можно редактировать для введения каких-либо значений по умолчанию, которые требуется определить для администрирования пользовательских паролей. В качестве альтернативы можно применять команду chsec (заметьте, что значения, представленные в нижеследующей таблице, взяты из книги "IBM Redbook AIX Security Tools, SG24-5971-00").

    Парольные опции
    Атрибут Описание Рекомендуемое значение
    dictionlist Проверяет, не входят ли в пароль стандартные слова UNIX /usr/share/dict/words
    histexpire Количество недель, после которых пароль может быть использован повторно 26
    histsize Число допустимых парольных итераций 20
    maxage Максимальное число недель до того, как пароль должен быть в обязательном порядке изменен 4
    maxexpired Максимальное число недель после maxage, когда просроченный пароль еще может быть изменен пользователем 2
    maxrepeats Максимальное число повторений одного и того же символа в пароле 2
    minage Минимальное число недель до того, как пароль может быть изменен 1В документации по безопасности обычно рекомендуется устанавливать это значение в 0, т. е. пароли можно менять так часто, как это потребуется.
    minalpha Минимальное число алфавитных символов, которые должны содержаться в пароле 2
    mindiff Минимальное число отличающихся друг от друга символов, которые должны содержаться в пароле 4
    minlen Минимальная длина пароля 6 (8 для пользователя root) minother Минимальное число неалфавитных символов, которые должны содержаться в пароле 2
    pwdwarntime Число дней до окончания срока действия пароля, за которое система начинает выдавать предупреждение о том, что пароль должен быть изменен 5

    Подтягивание значений по умолчанию системных параметров входной регистрации

    Для установки базовых значений по умолчанию для многих параметров входной регистрации, вроде тех, которые могли бы быть установлены для нового пользователя (например, число попыток входа, повторное разрешение регистрации и регистрационный интервал), следует отредактировать файл etc/security/login.cfgФайл /etc/security/login.cfg..

    Удаление лишних пользовательских учетных записей, созданных по умолчанию при установке

    Во время процесса установки операционной системы AIX по умолчанию создается некоторое количество ID пользователей и групп. В зависимости от того, какие приложения будут запускаться на данном сервере AIX, и от того, где этот сервер будет располагаться в сети, некоторые из этих ID пользователей и групп могут стать слабыми местами в системе безопасности, уязвимыми для взлома. Если такие ID не нужны, для минимизации связанного с ними риска их можно удалить.

    В табл. 9.3 приведены наиболее общие создаваемые по умолчанию пользовательские ID, которые вы, вероятно, захотите удалить.

    Создаваемые по умолчанию пользовательские ID – кандидаты на удаление
    Пользовательский ID Описание
    uucp, nuucp Владелец скрытых файлов, используемых протоколом uucp
    lpd Владелец файлов, используемых системой печати
    imnadm Поисковый движок IMN [используется поиском по библиотеке документации (Documentation Library Search]
    guest Разрешает доступ тем пользователям, у которых нет доступа к учетным записям

    Аналогично в табл. 9.4 приводятся наиболее общие ID групп, которые, возможно, не понадобятся.

    Наиболее общие групповые ID – кандидаты на удаление
    Групповой ID Описание
    uucp Группа, к которой принадлежат пользователи uucp и nuucp
    printq Группа, к которой принадлежит пользователь lpd
    imnadm Группа, к которой принадлежит пользователь imnadm

    Могут быть и другие ненужные ID пользователей и групп; проанализируйте систему на наличие других ID, которые можно удалить. Прежде чем система "выйдет в свет", проведите всеобъемлющую оценку всех имеющихся ID.

    9.5.3 Определение доступа к доверенному коммуникационному пути

    Trusted Computing Base (Доверенная вычислительная база, TCB) является частью системы, которая отвечает за проведение в жизнь общесистемных политик информационной безопасности. Установкой и использованием TCB можно определить доступ пользователя к доверенному коммуникационному пути (trusted communication path), который предполагает защищенную коммуникацию между пользователями и TCB.

    Функциональные возможности TCB могут быть включены только во время установки системы. Для того чтобы установить TCB на уже готовую машину, нужно выполнить установку в режиме "preservation". Включение TCB дает возможность доступа к доверенной оболочке (trusted shell), к доверенным процессам и к ключу безопасности внимание (Secure Attention Key, SAK).

    Поскольку каждое устройство является частью TCB, каждый файл каталога /dev отслеживается системой TCB. Кроме того, TCB автоматически следит за более чем 600 дополнительными файлами, сохраняя критическую информацию об этих файлах в /etc/security/syschk.cfg. Если TCB установлена, сразу же после установки с этого файла следует снять резервную копию на съемный носитель, такой, как лента, CD или диск, и на носитель, хранимый в безопасном месте.

    9.5.4 Обработка особых ситуаций

    В процессе укрепления своих систем администраторы систем AIX могут столкнуться со множеством различных ситуаций. Данный раздел как раз и проливает свет на подобные особые ситуации.

    Особые разрешения

    Если для каких-либо пользователей и групп устанавливаются особые разрешения, все эти выделенные особые разрешения следует задокументировать и наметить шаги для согласования с вопросами безопасности. Если особые разрешения не задокументированы, другие не будут в курсе этих особых ситуаций и могут пренебречь теми шагами, которые должны быть предприняты.

    Особые привилегии

    При установке нового программного обеспечения, такого, как сервер Domino или сервер DB2, могут возникнуть вопросы в связи с созданием новых учетных записей и выделением особых привилегий для них. Отдавайте себе отчет по всем новым ID, их привилегиям и правам собственности на файлы и папки, чтобы потом не оказалось непреднамеренного обмана политики безопасности организации.

    Особые пароли

    Пароль на включение питания. Данный пароль, если установлен, препятствует кому бы то ни было перезагружать сервер простым его выключением из сети питания и затем включением вновь. Если в CD-ROM-привод вставлен загрузочный CD-носитель, система перезагружается, а затем уже будет грузиться с CD и, следовательно, не станет придерживаться своей безопасной конфигурации, что приводит к нарушению режима безопасности. Если система перезагружается и если пароль на включение питания установлен, во время цикла перезагрузки система потребует ввести этот пароль. Это может повлиять на действующие соглашения об уровне сервиса (Service Level Agreements, SLAs), так как может быть определенная задержка по времени между моментом, когда сервер перезагружается до точки запроса пароля на включение питания, и моментом, когда ему будет позволено продолжать свою загрузочную последовательность после того, как пароль был введен. В идеале первостепенность будет установлена политикой безопасности организации (безопасность против соглашений по предоставлению услуг).

    Пароль супервизора. Данный пароль не дает неавторизованному пользователю загрузиться в режим поддержки при помощи загрузочного носителя (загрузочный CD, mksysb лента/CD). Загрузка с подобного носителя предоставляет полный доступ к файлам и каталогам абсолютно без ограничений в плане безопасности. Пароль супервизора закрывает систему, и, если этот пароль утерян, понадобится помощь обслуживающего персонала IBM для того, чтобы отпереть ее.

    Пароль root. Это пароль суперпользователя, который время от времени может быть нужен. Важно отдавать себе отчет в том, когда действительно может понадобиться учетная запись root, и на такие случаи в реализации системы безопасности организации должны присутствовать планы.

    Слабые места системы безопасности

    Каждому хорошему системному администратору AIX следует быть осведомленным о тех системах в ИТ-инфраструктуре организации, в которых могут иметься слабые места для общей системы безопасности. Если предполагаемый взломщик взломает одну из машин, находящихся внутри сети организации, он может получить доступ и к другим машинам посредством разрешений, установленных между данной машиной и другими системами в сети.

    Некоторые из предполагаемых взломщиков сканируют сети на наличие определенного типа машин и определенных версий операционных систем с целью найти какую-нибудь одну такую, которую можно было бы взломать, а затем они могут использовать эту точку входа для получения доступа ко всем машинам в сети.

    9.5.5 Разрешение системного аудита

    Пользователи регулярно производят различные системные действия, за которыми не мешало бы наблюдать более тщательно. Установкой системного аудита дается возможность записывать касающуюся безопасности информацию, которая затем может быть проанализирована на факт наличия потенциальных и фактических нарушений системной политики безопасности.

    Предопределенные события аудита можно найти в файле /etc/security/audit/events. Для генерации регулярных отчетов при помощи возможностей службы cron можно установить автоматическое ведение аудита.

    9.5.6 Слежение за файлами, каталогами и программами

    Наше обсуждение укрепления было бы неполным без рассмотрения механизмов, которые можно использовать для наблюдения за доступом к файлам, каталогам и исполняемым программам.

    Удаление устаревших файлов

    Время от времени появляется необходимость в удалении нежелательных и ненужных файлов с сервера AIX.

    AIX предоставляет системному администратору команду skulker, которая может автоматически отследить и удалить устаревшие файлы. Кандидатами на обработку данным средством являются файлы, расположенные в каталоге /tmp, исполняемые файлы a.out, файлы core и ed.hup. Для запуска команды skulker введите в командную строку следующее:

    # skulker -p

    Вы можете автоматизировать команду skulker, заставив cron регулярно выполнять данную задачу.

    Удаление файлов, не имеющих владельца

    Когда ID пользователя удаляется, файлы этого пользователя больше не имеют владельца, приписанного к ним. Для нахождения файлов, не имеющих владельца, используйте команду find так, как показано ниже:

    # find / -nouser -ls

    После идентификации файлов без владельца определите, нужны ли еще эти файлы. Если нужны, их следует приписать другому пользователю. В противном случае эти файлы можно удалить из системы.

    Управление неавторизованным удаленным доступом к хосту

    Для получения доступа к системе некоторые программы используют файл .rhosts. В некоторых случаях доступ может быть предоставлен и неавторизованным пользователям. Для избежания подобной ситуации файл .rhosts следует удалить с сервера AIX.

    Для кластеров HACMP файлы .rhosts нужныВ HACMP 5.x этот файл больше не нужен.. В таких конфигурациях вместо удаления этим файлам следует установить разрешения 600 и назначить права собственности root.system.

    Для нахождения файлов .rhosts запустите следующую команду:

    # find / -name .rhosts -ls

    Слежение за исполняемыми файлами

    Для слежения за активностью исполняемых файлов особой важности требуется хорошее понимание того, как эти файлы используются. Исполняемые файлы, за которыми требуется наблюдение, – это те файлы, которые принадлежат пользователю root и у которых установлен хотя бы один из битов SUID и SGID.

    После тщательного наблюдения за этими файлами во время нормальной работы системы можно составить отчет, в который будет входить список файлов, которые работают нормально. Затем этот отчет можно сверить с последующими отчетами, что выявит все новые файлы, атрибуты которых были выставлены без ведома системного администратора AIX. Для создания шаблонного отчета воспользуйтесь следующими командами:

    # find / -perm -4000 -user 0 -ls
# find / -perm -2000 -user 0 -ls

    Управление задачами cron и at

    Для управления задачами cron и at проделайте следующее. Убедитесь в том, что единственным пользователем, упоминающимся в файлах cron.allow и at.allow, является root.

    Из каталога /var/adm/cron удалите cron.deny и at.deny.

    Убедитесь в том, что задачи cron и at принадлежат пользователю и могут выполняться только им root.

    9.5.7 Управление тем, что относится к X11 и CDE

    В этом разделе рассказывается о потенциальных "дырах" безопасности, пришедших вместе с X-сервером X11 и с окружением CDE (Common Desktop Environment).

    Удаление файла /etc/rc.dt

    Хотя запуск графического пользовательского интерфейса CDE и удобен для пользователей, с ним связаны некоторые проблемы для безопасности. По этой причине CDE не следует запускать на серверах, для которых требуется высокий уровень безопасности.

    Самым лучшим решением было бы вообще избегать установки файловых наборов CDE (dt). Если же данные наборы все-таки были установлены на сервер, следует рассмотреть вопрос их удаления, особенно сценария /etc/rc.dt, который запускает CDE.

    Предотвращение неавторизованного слежения за удаленным X-сервером

    Важный вопрос безопасности, связанный с сервером X11, – это неавторизованное тихое слежение за удаленным сервером. Для слежения за работой X-сервера могут быть использованы команды xwd и xwud, поскольку они обладают возможностью перехватывать нажатия клавиш, что может раскрыть пароли и другие важные данные. Для решения данной проблемы либо просто удалите эти исполняемые файлы, если они не нужны для текущей конфигурации сервера, либо разрешите доступ к этим командам только пользователю root.

    Команды xwd и xwud можно найти в файловом наборе X11.apps.clients.

    Если команды xwd и xwud нужно оставить, подумайте об использовании OpenSSH или MIT Magic Cookies. Эти приложения сторонних производителей помогут предотвратить риск, связанный с запуском команд xwd и xwud.

    Разрешение и запрещение контроля доступа

    X-сервер дает возможность удаленным хостам использовать команду xhost+ для соединения с сервером AIX. Убедитесь, что вместе с командой xhost+ задано и имя хоста, потому что иначе контроль доступа для данного X-сервера будет запрещен. Это разрешит предоставление доступа к конкретным хостам, которые облегчат слежение за потенциальными атаками на X-сервер. Для предоставления доступа к конкретным хостам запустите команду xhost следующим образом:

    # xhost + имя хоста

    Запрещение пользовательских разрешений для запуска команды xhost

    Еще один способ гарантировать то, что команда xhost используется должным образом, – это ограничить выполнение этой команды только при наличии полномочий суперпользователя. Для этого воспользуйтесь командой chmod и измените разрешения файла /usr/bin/X11/xhost на 744, как показано ниже:

    # chmod 744/usr/bin/X11/xhost

    Убедитесь, что вместе с командой xhost задано имя хоста. Это разрешит предоставление доступа к конкретным хостам, которые упрощают слежение за потенциальными атаками на X-сервер.

    Замечание. Если имя хоста не задано, доступ будет предоставлен всем хостам.

    9.5.8 Запрещение ненужных служб

    В этом разделе обсуждаются открытые коммуникационные порты, как их можно идентифицировать и как закрыть.

    Определение сетевых служб с открытыми коммуникационными портами

    Клиент-серверные приложения открывают на сервере коммуникационные порты, позволяя приложениям слушать входящие запросы клиентов.

    Поскольку открытые порты – потенциальные кандидаты для атаки, определите, какие приложения открыли порты; но совсем не обязательно закрывать все порты, которые открыты. Это упражнение полезно уже тем, что дает системным администраторам возможность понять, что системы являются доступными любому, у кого есть доступ к Интернету.

    Для определения того, какие порты открыты, проделайте следующее.

    Идентифицируйте службы при помощи команды netstat:

    # netstat -af inet

    Результат работы данной команды достаточно ясен для интерпретирования. Последний столбец вывода команды netstat обозначает состояние каждой службы.

    После определения того, какие службы в настоящий момент слушают, откройте файл /etc/services и проверьте его при помощи служб центра по присвоению номеров Интернета (Internet Assigned Numbers Authority, IANA) для постановки в соответствие службы номеру порта внутри операционной системы.

    Закройте ненужные порты удалением запущенных служб.

    Составление списка открытых файлов

    Полезно определить TCP-сокеты, которые находятся в состоянии LISTEN, и ненагруженные UDP-сокеты, которые ожидают получения данных.

    Для этой цели воспользуйтесь командой lsof, которая является вариантом команды netstat -af. Команда lsof входит в AIX 5.1 и находится на диске "AIX Toolbox for Linux Applications CD".

    Например, чтобы вывести на экран TCP-сокеты, находящиеся в состоянии LISTEN, и UDP-сокеты, находящиеся в состоянии IDLE, запустите команду lsof следующим образом:

    # lsof -i | egrep "COMMAND|LISTEN|UDP"

    После определения ID процесса можно получить более подробную информацию о самой программе, выполнив следующую команду:

    " # ps -fp PID#"

    Вывод будет содержать путь к имени команды, который можно использовать для доступа к man-странице данной программы.

    9.6 Резюме

    В этой лекции мы рассмотрели инструменты и техники, используемые для защиты ИТсистем и предотвращения атак.

    Мы дали подсказки по укреплению операционной системы, рассказали об инструментах и программах, используемых для создания сплошной защиты, а также о методах профессионалов безопасности по сбору сведений в тех случаях, когда взломщики пробили внешнюю защиту.

    Предоставленная нами информация может принести пользу организации любого размера, от маленькой домашней фирмы до очень большой организации с офисами по всему миру.

    Хотя самое важное, что нужно запомнить, – это то, что нет 100 % надежных ИТ-систем в течение 100 % времени.

    Таким образом, важно еще понять, что, как только система – и ее безопасность – на месте, начинается следующая фаза работы по обеспечению безопасности. То есть время наблюдать за ИТ-системой и определять, какие еще улучшения могут быть внесены в систему для продолжения и совершенствования ее безопасности, а также для поддержания целостности и конфиденциальности содержащейся в ней информации. Тогда и только тогда будет иметь место надлежащая и адекватная безопасность.

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^