Защита хостов интрасети

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

Выделим основные причины уязвимости хостов.интрасети:

• открытость сети Internet, свободный доступ к информации по организации сетевого взаимодействия, протоколам и механизмам защиты;

• наличие ошибок в ПО, ОС и утилитах, которые открыто публикуются в сети;

• разнородность используемых версий ПО и ОС, которые совместно не могут обеспечить хорошую защиту хоста;

• сложность организации защиты межсетевого взаимодействия между отдельными хостами;

• ошибки конфигурирования систем и средств защиты, устанавливаемых на хостах;

• неправильное или ошибочное администрирование систем, установленных на хостах;

• несвоевременное отслеживание и выполнение рекомендаций специалистов по защите и анализу случаев вторжения для ликвидации лазеек и ошибок в ПО;

• "экономия" на средствах и системах обеспечения безопасности или полное их игнорирование;

• умолчание о случаях нарушения безопасности своего хоста или сети.

Вопрос 14.2. Информационная безопасность в сетях. Понятие и основные проблемы обеспечения информационной безопасности. Средства обеспечения информационной безопасности сети. Политика безопасности для сетей. Модели доверия

Вся информация в книге Милославской. Моделей доверия там нет, поэтому вот кое-что по ним (хотя не уверен что то, что надо):

Модели доверия

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

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

• Двусторонние, когда сервер доверяет некоторым клиентам;

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

Примеры доверия:

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

• На системной консоли вообще не проверяется пароль в предположении, что в комнате системщиков посторонних не бывает.

• Система разрешает входить особо привелигерованным пользователям только со специально оговоренных точек.

• Unix-система доверяет произвести аутентификацию NIS-серверу.

• DialUP Controller, не имеющий списка пользователей, доверяет произвести аутентификацию Tacax-серверу.

• Сервер под Windows'NT доверяет произвести аутентификацию Primary или Secondary Domain Controller'у.

• Domain Controller доверяет произвести аутентификацию своему коллеге из другого домена.

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

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