Способ обеспечения информационной безопасности при доступе пользователя к внешним информационным ресурсам через интернет
Владельцы патента RU 2445692:
Государственное образовательное учреждение высшего профессионального образования Академия Федеральной службы охраны Российской Федерации (Академия ФСО России) (RU)
Способ обеспечения информационной безопасности при доступе пользователя к внешним информационным ресурсам через Интернет относится к электросвязи и может быть использован как средство повышения защищенности ресурсов компьютерной сети при доступе пользователя к информационным ресурсам сети общего пользования посредством сетевого соединения с использованием сетевого оборудования как в локальных, так и в глобальных компьютерных сетях, в которых связь между абонентами осуществляется путем передачи пакетов данных в соответствии со стеком коммуникационных протоколов TCP/IP. Техническим результатом является повышение защищенности ресурсов информационно-вычислительной сети за счет скрытия точки выхода в сеть общего пользования. Технический результат достигается за счет использования для доступа к сети общего пользования сети доступа на основе socks серверов, позволяющей строить различные пути к ресурсам сети Интернет, динамического изменения точки выхода и пути в сеть общего пользования при доступе к сети и в момент возникновения угрозы информационной безопасности, динамического изменения параметров на средствах обеспечения информационной безопасности в случае определения в точке выхода из сети доступа угрозы информационной безопасности. 3 ил., 15 табл.
Способ обеспечения информационной безопасности при доступе пользователя к внешним информационным ресурсам через Интернет относится к электросвязи и может быть использован как средство повышения защищенности ресурсов компьютерной сети при доступе пользователя к информационным ресурсам сети общего пользования посредством сетевого соединения с использованием сетевого оборудования как в локальных, так и в глобальных компьютерных сетях, в которых связь между абонентами осуществляется путем передачи пакетов данных в соответствии со стеком коммуникационных протоколов TCP/IP.
Известен «Способ управления доступом к внешним сайтам через Интернет», по патенту РФ №2002125855, класс G06F 17/30, G06F 13/00, от 2001.03.23. Известный способ включает следующую последовательность действий: принимают запрос клиента к информационной службе, проверяют тип запроса (чтение/запись), проверяют запрос по определенным правилам на совпадение параметров запроса с имеющимися базами данных параметров, в случае если запрос удовлетворяет указанным требованиям, его выполняют, в противном случае запрос отклоняют.
Недостатком данного способа является узкая область применения, что обусловлено его предназначением в основном для фильтрации запросов к различным ресурсам сети общего пользования, при этом вопросам защищенности ресурсов информационно-вычислительной сети внимание уделено недостаточное. В прототипе не учитывают что в процессе осуществления доступа к ресурсам сети общего пользования возможны воздействия внешнего нарушителя на ресурсы информационно-вычислительной сети, известные в литературе как «хакерские атаки» (см., например, Медведовский И.Д. и др. Атака на Internet. - М.: ДМК, 1999. - 336 с.: ил., Скиба В.Ю., Курбатов В.А. Руководство по защите от внутренних угроз информационной безопасности - СПб.: Питер, 2008 - 320 с. ил.).
Кроме этого предлагаемое решение позволяет скрыть точку выхода из корпоративной сети в сеть общего пользования (например, Internet), а также осуществить раннее определение нарушителя, за счет применения в точках выхода в сеть общего пользования средств обеспечения информационной безопасности.
Наиболее близким по своей технической сущности к заявленному является способ по патенту РФ №2231115 «Способ и устройство для управления доступом к Интернету в компьютерной системе и считываемый компьютером носитель информации для хранения компьютерной программы», класс G06F 17/30, G06F 13/00, от 20.02.2002. Известный способ включает следующую последовательность действий: принимают запрос клиента к информационной службе, проверяют тип запроса (чтение/запись), проверяют запрос по определенным правилам на совпадение параметров запроса с имеющимися базами данных параметров, в случае если запрос удовлетворяет указанным требованиям, его выполняют, в противном случае запрос отклоняют.
Недостатком данного способа является узкая область применения, что обусловлено его предназначением в основном для фильтрации запросов к различным ресурсам сети общего пользования, при этом вопросам защищенности ресурсов информационно-вычислительной сети внимание уделено недостаточное. В прототипе не учитывают что в процессе осуществления доступа к ресурсам сети общего пользования возможны воздействия внешнего нарушителя на ресурсы информационно-вычислительной сети, известные в литературе как «хакерские атаки» (см., например, Медведовский И.Д. и др. Атака на Internet. - М.: ДМК, 1999. - 336 с.: ил., Скиба В.Ю., Курбатов В.А. Руководство по защите от внутренних угроз информационной безопасности. - СПб.: Питер, 2008 - 320 с. ил.).
Задачей изобретения является повышение защищенности клиентов от воздействий нарушителя при доступе пользователя к информационным ресурсам сети Internet, скрытие точки выхода из корпоративной сети в сеть общего пользования (например, Internet), а также раннее определение нарушителя за счет применения в точках выхода в сеть общего пользования средств обеспечения информационной безопасности.
Кроме этого предлагаемое решение позволяет скрыть точку выхода из корпоративной сети в сеть общего пользования (например, Internet), а также осуществить раннее определение нарушителя за счет применения в точках выхода в сеть общего пользования средств обеспечения информационной безопасности.
Поставленная задача достигается тем, что принимают запрос клиента к информационной службе, проверяют тип запроса (чтение/запись), проверяют запрос по определенным правилам на совпадение параметров запроса с имеющимися базами данных параметров, в случае если запрос удовлетворяет указанным требованиям его выполняют, в противном случае запрос отклоняют, строят SOCKS сеть доступа к ресурсам сети Internet, формируют перечень промежуточных SOCKS серверов, определяют размер цепочек SOCKS серверов, для каждого запроса определяют выходную цепочку из перечня SOCKS серверов, отправляют запрос к информационному ресурсу, в точках выхода из SOCKS сети доступа к ресурсам сети Internet контролируют входящие и исходящие пакеты антивирусными средствами, системами обнаружения атак, межсетевыми экранами, в случае тревоги блокируют входящие и исходящие пакеты.
Сущность изобретения поясняется чертежами, приведенными на фиг.1, фиг.2, фиг.3 на которых показаны:
Фиг.1. Структура информационно-вычислительной сети организации.
Фиг.2. Классификация воздействий нарушителя на информационные службы ИВС.
Фиг.3. Блок-схема способа формирования цепочек серверов при доступе к внешним ресурсам через Интернет.
На фиг.1 представлена структура информационно-вычислительной сети, в которой реализуется предлагаемый способ управления информационной безопасностью при доступе пользователей внутренней сети к сайгам, размещенным во внешней сети (Интернет). В составе информационно-вычислительной сети (ИВС) выделяют: клиентские ПЭВМ, коммуникационные устройства (маршрутизаторы, коммутаторы), обеспечивающие взаимодействия внутри сети, и серверы, обеспечивающие доступ к информационным ресурсам посредством информационных служб, таких как: служба обмена файлами на основе протокола передачи файлов FTP (File Transfer Protocol), простой протокол передачи файлов TFTP (Trivial File Transfer Protocol), служба обмена сообщениями на основе протоколов SMTP (Simple Mail Transfer Protocol) и POP3 (Post Office Protocol), Web-служба на основе протокола передачи гипертекстовой информации HTTP (Hypertext Transfer Protocol), также представлена сеть доступа к ресурсам сети Internet на основе SOCKS серверов, обеспечивающих безопасный выход в сеть общего пользования (Internet), работающие по протоколу SOCKS (RFC 1928). Известны также дополнительные службы, обеспечивающие взаимодействие в ИВС такие как: служба доменных имен DNS (Domain Name System), служба на основе протокола передачи управляющей информации ICMP (Internet Control Message Protocol), служба на основе протокола разрешения адресов ARP (Address Resolution Protocol).
В целях защиты от внешних угроз в сегменте ИВС, в точках выхода функционируют типовые средства обеспечения информационной безопасности, такие как межсетевые экраны, антивирусные средства, системы обнаружения атак, системы анализа уязвимостей. В случае доступа к сети общего пользования возможности воздействий внешнего нарушителя на процесс информационного взаимодействия существенно возрастают, что выражается в известных воздействиях нарушителя и представлены как в литературе (см., например, Уязвимость и информационная безопасность телекоммуникационных технологий: Учебное пособие для Вузов / А.А.Новиков, Г.Н.Устинов. - М.: Радио и связь. 2003. - 296 с.: ил.), так и в сети общего пользования (см., например, www.securitylab.ru, www.bugtraq.ru).
На фиг.2 представлена Классификация воздействий нарушителя на информационные службы ИВС.
По методу реализации ВН делятся на простые - "один к одному", когда нарушитель самостоятельно атакует информационную службу, и распределенные - "один ко многим", когда нарушитель использует распределенную сеть подчиненных ему машин для реализации деструктивных действий.
По характеру воздействия выделяют пассивные и активные ВН. В первом случае нарушитель работает в пассивном режиме, осуществляя сбор информации о функционирующих службах, открытых портах. Примером этих ВН является анализ сетевого графика с помощью анализаторов пакетов.
Активные ВН, в отличие от пассивных, подразумевают деятельность нарушителя по исследованию функционирования службы. Примером таких воздействий могут быть неавторизованное превышение полномочий, сканирование сети, удаленный запуск приложений, подмена доверенного субъекта сети, воздействия, направленные на отказ в обслуживании, а также другие действия нарушителя по исследованию уязвимости служб ИВС.
Основным вариантом информационного взаимодействия пользователей с удаленными ресурсами сети общего пользования является обращение пользователя в сеть общего пользования к удаленной информационной службе общего пользования;
При организации информационного взаимодействия, транспортной средой которого становится сеть общего пользования, важной задачей становится обеспечение защищенности ресурса пользователя от воздействий нарушителя.
Под ресурсом пользователя в данном случае понимаются обрабатываемая и передаваемая конфиденциальная информация, а также информация ограниченного распространения по причинам коммерческой, служебной, врачебной тайн или другим видам ограничений.
Защищенность ИВС характеризуется применяемыми видами программно-аппаратных средств защиты и набором параметров, применение которых позволяет защитить ИВС от воздействий нарушителя. Параметры, влияющие на защищенность, имеются на всех объектах информационного взаимодействия: коммуникационном оборудовании, клиентах, серверах, средствах обеспечения информационной безопасности. На коммуникационном оборудовании (коммутаторе, маршрутизаторе), такими параметрами можно считать: возможность настройки подсетей VLAN, возможность фильтрации пакетов по определенным правилам, настройки списков доступа к определенному порту, настройки скорости передачи по порту, включение/выключение порта.
Для рабочей станции, сервера перечень параметров индивидуален и характеризует возможность работы информационной службы или запрет на ее функционирование, разрешение или запрещение передачи пакетов по сети.
Основные этапы процесса доступа к внешним информационным ресурсам представлены на фиг.3.
Блок №1. Проверка работоспособности всех SOCKS серверов.
На начальном этапе осуществляется проверка всех SOCKS серверов, имеющихся в базе. Осуществляется путем посылки ICMP (Internet Control Message Protocol - RFC 792) запросов для проверки достижимости хоста (сервера). Также устанавливается значение задержки для каждого сервера, применяя запрос авторизации по протоколу SOCKS в соответствии с технической спецификацией RFC 1928.
Блок №2. Исключение из списка выборки не работоспособных SOCKS серверов.
SOCKS сервера не прошедшие проверку работоспособности удаляются из списка выборки. Это необходимо для устранения ошибок при построении цепочки (блок №6).
Блок №3. Перехват запроса пользователя.
Клиент посылает запрос для получения информационного ресурса. Межсетевое взаимодействие осуществляется согласно эталонной модели взаимодействия открытых систем ЭМВОС (OSI), на основе стэка коммуникационных протоколов TCP/IP (Transmission Control Protocol/Internet Protocol). Запрос инициируется пользователем к одной из известных информационных служб, посылается по следующим протоколам прикладного уровня (HTTP, POP3, FTP). В блоке осуществляется перехват API вызова операционной системы на установку соединения согласно эталонной модели открытых систем ЭМВОС (OSI), на основе стека коммуникационных протоколов TCP/IP (Transmission Control Protocol/Internet Protocol). Запрос помещается в буфер.
Блок №4. Определение длины цепочки.
На этом этапе происходит определение параметров взаимодействия по протоколу SOCKS (RFC 1928). Определяется длина цепочки SOCKS серверов. Данный параметр определяется исходя из двух критериев: времени отклика и уровня безопасности.
Блок №5. Определение звеньев цепочки (SOCKS серверов).
Осуществляется определение второго параметра взаимодействия по протоколу SOCKS (RFC 1928), необходимого количества SOCKS серверов для построения цепочки. Данный подбор осуществляется исходя из критерия - суммарное время отклика не должно превышать требования ко времени отклика всей цепочки, при недостижимости данного критерия требуется максимально приблизиться к нему. Также при выборе учитывается и предыдущее использование SOCKS серверов. Это необходимо для выравнивания статистики использования SOCKS серверов с целью скрытия предпочтений в выборе SOCKS серверов и удаленного анализа и определения возможной цепочки в сети доступа.
Блок №6. Формирование цепочки.
На данном этапе осуществляется объединение выбранных SOCKS серверов в единую цепь. Таким образом, формируется путь прохождения запроса пользователя.
Блок №7. Проверка возникновения ошибки при формировании цепочки. В случае если один из SOCKS серверов оказывается неработоспособным, вся цепочка оказывается неработоспособной и клиенту согласно технической спецификации на протокол SOCKS - RFC 1928 отправляется пакет с сообщением о недостижимости хоста. После чего необходимо исключить данный неработоспособный SOCKS сервер из списка рабочих (Блок №12), после чего заново переопределить звенья цепочки (возврат к блоку №5).
Блок №8. Отправка запроса пользователя по цепочке.
На данном этапе осуществляется передача перехваченного запроса пользователя по цепочке SOCKS серверов.
Блок №9. Анализ графика средствами защиты в точках выхода.
При работе клиента в сети общего пользования осуществляется анализ графика средствами защиты. В случае обнаружения атаки данная точка выхода блокируется (блок №11), SOCKS сервер исключается из списка работоспособных (блок №12). После чего заново переопределяются звенья цепочки (возврат к блоку №5). В случае обнаружения внешних угроз обслуживание клиентского запроса прекращается, осуществляется закрытие соединения (блок №10).
Блок №10. Закрытие соединения.
На данном этапе осуществляется закрытие соединения согласно рекомендации по протоколу TCP (Transmission Control Protocol), согласно техническим спецификациям RFC 793.
Блок №11. Блокировка выходной точки.
При обнаружении атаки точка выхода в сеть общего пользования INTERNET блокируется администратором до устранения угрозы раскрытия конфиденциальных данных.
Блок №12. Исключение неисправного SOCKS сервера.
Из списка выборки исключаются неработоспособные SOCKS серверы.
Предлагаемый способ осуществляется следующим образом.
Этап №1. На начальном этапе формируем сегмент сети, согласно фиг.1. В рамках этого этапа разворачиваются клиентские станции, SOCKS серверы, организуется телекоммуникационная сеть взаимодействия всех узлов. Устанавливается выход в сеть общего пользования всех узлов сети.
Следующим этапом необходимо проверить достижимость узлов сети. Осуществляется это с помощью протокол ICMP, согласно технической спецификации RFC 792.
В системе тестирования инициализируются служебные временные переменные, отвечающие за генерацию и отправку диагностических ICMP-пакетов, а также разбор принятых ответных диагностических ICMP-пакетов (общая структура диагностических ICMP-пакетов отражена в таблице 1):
| Таблица 1 | ||
| Общая структура диагностических ICMP-пакетов | ||
| TYPE | 1 байт | Тип сообщения |
| CODE | 1 байт | Код дополнительной диагностической информации |
| CHECKSUM | 2 байта | Контрольная сумма данного сообщения |
| UNUSED | 4 байта | Заполнитель |
| DATA | Варьируется | Инкапсулированные (необязательные) данные |
В тестовый блок входит один диагностический ICMP-пакет (реализованный в стандартной утилите PING по протоколу ICMP), структура и содержание задаваемых полей которого представлены в таблице 2:
| Таблица 2 | |
| Структура и содержание задаваемых полей диагностических ICMP-пакетов | |
| TYPE | 00001000 (8) |
| CODE | 00000000 (0) |
Отправив к исследуемому узлу тестовый блок, система тестирования ожидает получения подтверждения успешной его отправки.
Запускается режим прослушивания в анализаторе последовательностей и принимается ответный диагностический пакет (имеющий формат, указанный в таблице 1).
Далее ожидается получение подтверждения приема ответного диагностического пакета до момента остановки таймера ожидания диагностического пакета. Если на момент остановки таймера ответный диагностический пакет не прибывает, делается вывод о критичности отправленного тестового блока (произошел либо логический разрыв соединения, либо критический сбой в работе исследуемого узла). Соответственно данный узел должен быть исключен из списка работоспособных (фиг.3, блок №2).
Осуществив прием ответного диагностического пакета, выполняется его преобразование и разбор. Пусть на данном этапе произошел прием следующего ответного диагностического ICMP-пакета:
| Таблица 3 | |
| Содержание значимых полей ответного диагностического ICMP-пакета | |
| TYPE | 00000011 (3) |
| CODE | XXXXXXXX |
Видим, что в поле Type ответного диагностического ICMP-пакета указан общий код значения ошибки (3), соответствующий недостижимости узла назначения (Destination Unreachable). В поле Code ответного диагностического ICMP-пакета код значения ошибки уточняется (ХХХХХХХХ), где ХХХХХХХХ - одно из значений, указанных в таблице 4:
| Таблица 4 | |
| Значения кода недостижимости узла назначения | |
| 00000000 (0) | Сеть недостижима |
| 00000001 (1) | Компьютер недостижим |
| 00000010 (2) | Протокол недостижим |
| 00000011 (3) | Порт назначения недостижим |
| 00000100 (4) | Необходима фрагментация передаваемого пакета |
| 00000101 (5) | Ошибка при маршрутизации источника |
| 00000110 (6) | Сеть назначения неизвестна |
| 00000111 (7) | Компьютер назначения неизвестен |
| 00001000 (8) | Компьютер-источник изолирован |
| 00001001 (9) | Взаимодействие с сетью административно запрещено |
| 00001010 (10) | То же самое с компьютером назначения |
| 00001011 (11) | Сеть недостижима из-за класса обслуживания |
| 00001100 (12) | Компьютер недостижим из-за класса обслуживания |
В результате прихода любого из пакетов со значениями ошибки, представленными в таблице 4, сервер должен быть исключен из списка работоспособных.
В случае прихода эхо ответа формата, представленного в таблице 5:
| Таблица 5 | |
| Содержание значимых полей ответного диагностического ICMP-пакета | |
| TYPE | 00000000 (0) |
| CODE | 00000000 |
Для проверки соединения с SOCKS сервером необходимо использовать протокол SOCKS. Тестирующая станция соединяется с сервером по протоколу TCP (Transmission Control Protocol - RFC 793) и посылает сообщение формата, представленного в таблице 6:
| Таблица 6 | ||
| Структура задаваемых полей диагностических SOCKS-пакетов | ||
| VER | 1 байт | Версия протокола |
| NMETHODS | 1 байт | Число октетов в идентификаторах методов авторизации в поле METHODS |
| METHODSKL | 1-255 байт | Байты параметра метода |
Для проверки соединения с SOCKS сервером поля заполняются согласно таблице 7:
| Таблица 7 | ||
| Структура и содержание задаваемых полей диагностических SOCKS-пакетов | ||
| VER | 0110(5) | Версия протокола используется пятая |
| NMETHODS | 0000(0) | Число октетов в идентификаторах методов равно 0 значит не используется ни каких методов. |
| METHODSKL | Байты выбранных методов |
Если SOCKS сервер отвечает пакетом со структурой, представленной в таблице 8:
| Таблица 8 | ||
| Структура задаваемых полей ответных SOCKS-пакетов | ||
| VER | 1 байт | Версия протокола |
| METHODS | 1-255 байт | Выбранный метод |
В случае работоспособности сервер отправляет пакет следующего содержания (таблица 9):
| Таблица 9 | ||
| Структура и содержание задаваемых полей положительных ответов | ||
| VER | 0101 (5) | Версия протокола пятая |
| METHODS | 0000 (0) | Не используется авторизация |
В случае неработоспособности сервер отправляет пакет следующего содержания (таблица 10):
| Таблица 10 | ||
| Структура и содержание задаваемых полей отрицательных ответов | ||
| VER | 0101 (5) | Версия протокола пятая |
| METHODS | 11111111 (255) | Отказ в выбранных методах авторизации |
В случае если нет выбранных методов авторизации сервер должен быть исключен из списка работоспособных (фиг.3, блок №2).
Если на рабочей станции сети доступа к ресурсам Internet не запущена служба SOCKS сервера то, в зависимости от операционной системы, на пакет со структурой представленной в таблице 7, возможно два исхода:
- Первый исход заключается в том что, операционная система просто проигнорирует полученный пакет и отбросит. В этом случае TCP соединение, по которому шла передача пакета, закроется по таймеру простоя.
- Второй исход заключается в отправки сервером ICMP пакета о недоступности порта. Формат донного пакета представлен в таблице 3.
Независимо от исхода сервер должен быть удален из списка работоспособных. Проведя данные итерации ко всем серверам в списке, переходим к следующему этапу.
Этап №2. Пусть клиент посылает запрос типа GET по протоколу HTTP к удаленному информационному ресурсу. Осуществляется перехват запроса пользователя и помещение его во временный буфер (фиг.3, блок №3).
После чего производится определение длины цепочки SOCKS серверов (фиг.3, блок №4). Данный выбор осуществляется по трем основным параметрам:
- задержка, чем длиннее цепочка, тем выше задержка;
- безопасность, чем длиннее цепочка, тем ниже вероятность определения исходной точки;
- безопасности со стороны атаки на протокол SOCKS, чем длиннее цепочка, тем выше вероятность успешной атаки перекрытия на протокол.
Определившись с длиной цепочки, необходимо выбрать SOCKS сервера для формирования цепочки (фиг.3, блок №5). Выбор осуществляется вероятностно, чем больше задержка, тем меньше вероятность выбора данного сервера. Количество выбранных серверов равно длине цепочки.
Этап №3. На данном этапе происходит объединение всех серверов в единую цепочку посредством протокола SOCKS, согласно технической спецификации RFC 1928. Построение цепочки начинается с отправки клиентом запроса CONNECT. Формат пакета представлен в таблице 11:
| Таблица 11 | ||
| Структура задаваемых полей SOCKS-пакетов на запрос | ||
| VER | 1 байт | Версия протокола |
| CMD | 1 байт | Вид пакета |
| RSV | 1 байт | Зарезервировано |
| ATYP | 1 байт | Тип адреса |
| DST.ADDR | Варьируется | Требуемый адрес |
| DST.PORT | 2 байта | Требуемый порт (в сетевом порядке октетов) |
Заполнение значимых полей запроса представлено в таблице 12. Здесь необходимо отметить, что в рассматриваемом примере на транспортном уровне используется протокол TCP (RFC 793), согласно эталонной модели открытых систем ЭМВОС (OSI), также может быть использован и протокол UDP (User Datagram Protocol).
| Таблица 12 | ||
| Структура и содержание значимых полей SOCKS-пакетов на запрос | ||
| VER | 0101 (5) | Версия протокола пятая |
| CMD | 01 (1) | Вид пакета |
В случае успешного соединения SOCKS сервер отправляет клиенту пакет, имеющий формат, представленный в таблице 13:
| Таблица 13 | ||
| Структура задаваемых полей ответных SOCKS-пакетов | ||
| VER | 1 байт | Версия протокола |
| REP | 1 байт | Код ответа |
| RSV | 1 байт | Зарезервировано |
| ATYP | 1 байт | Тип адреса |
| BND.ADDR | Варьируется | Выданный сервером адрес |
| BND.PORT | 2 байта | Выданный сервером порт (в сетевом порядке октетов) |
Заполнение значимых полей запроса представлено в таблице 14:
| Таблица 14 | ||
| Структура и содержание значимых полей ответных SOCKS-пакетов | ||
| VER | 0101 | Версия протокола пятая |
| REP | XXXX | Код ответа |
В поле REP ответного SOCKS-пакета определяется код ответа (ХХХХ), где ХХХХ - одно из значений, указанных в таблице 15:
| Таблица 15 | |
| Значения кода ответа SOCKS-сервера | |
| 0000 (0) | Успешный |
| 0001 (1) | Ошибка SOCKS-сервера |
| 0010 (2) | Соединение запрещено набором правил |
| 0011 (3) | Сеть недоступна |
| 0100 (4) | Хост недоступен |
| 0101 (5) | Отказ в соединении |
| 0110 (6) | Истечение TTL |
| 0111 (7) | Команда не поддерживается |
| 1000 (8) | Тип адреса не поддерживается |
| 1001-1111 | Не определены |
В случае прихода пакета со значениями поля REP от 0001-1111 сервер, с которым осуществлялось соединение, должен быть удален из списка работоспособных (фигура №3 блок №12), а цепочка должно быть заново переопределена (возврат к фиг.3, блоку №5). При успешном создании туннеля (пути прохождения пакета) переходим к этапу №4.
Этап №4. Данный этап характеризуется извлечением запроса пользователя из буфера и отправка его по пути, сформированному на этапе №3.
При работе клиента в сети общего пользования Internet в точках выхода осуществляется контроль угроз внешних атак (фиг.3, блок №9). При обнаружении угрозы выходная точка должна немедленно блокироваться (фиг.3 блок №11), а точка выхода (оконечный SOCKS сервер) должен быть удален из списка работоспособных (фиг.3, блок №12). После чего цепочка должна быть заново перестроена (возврат, фиг.3, блок №5).
В случае если угроз не обнаружено, то соединение корректно закрывается после того, как пользователь закончил работу в сети общего пользования (фиг.3, блок №10).
Выше были подробно описаны некоторые варианты осуществления и преимущества настоящего изобретения, однако следует понимать, что оно допускает изменения, замены, модификации, вариации и альтернативы, не выходящие за рамки сущности и объема изобретения, которые определены прилагаемой формулой изобретения.
Настоящее изобретение может найти широкое применение в ИВС, имеющих широкое распространение в школах, больницах, государственных органах различного уровня, предприятиях различного масштаба, частных ИВС, имеющих распределенные удаленные филиалы и применяющих в своей работе сети общего пользования для обеспечения безопасного выхода в сеть общего доступа на основе технологии socks серверов.
Способ управления информационной безопасностью при доступе к внешним ресурсам через Интернет, включающий следующую последовательность действий: принимают запрос клиента к информационной службе, проверяют тип запроса (чтение/запись), проверяют запрос по определенным правилам на совпадение параметров запроса с имеющимися базами данных параметров, в случае если запрос удовлетворяет указанным требованиям, его выполняют, в противном случае запрос отклоняют, отличающийся тем, что строят SOCKS к ресурсам сети Internet, формируют перечень промежуточных SOCKS серверов, определяют размер цепочек socks серверов, для каждого запроса определяют выходную цепочку из перечня SOCKS серверов, отправляют запрос к информационному ресурсу, в точках выхода из SOCKS сети доступа к ресурсам сети Internet контролируют входящие и исходящие пакеты антивирусными средствами, системами обнаружения атак, межсетевыми экранами, в случае тревоги блокируют входящие и исходящие пакеты.
