Механизм трансляции (преобразования, замены) адресов (Network Address Translation) позволяет полностью скрыть внутреннее устройство сети (предотвратить распространение информации об адресах корпоративной сети) от пользователей Internet. При прохождении пакетов через МЭ адреса внутренних хостов могут заменяться на адрес внешнего интерфейса межсетевого экрана или на специально определенный адрес.
Дополнительно, механизм трансляции адресов позволяет решить проблемы нехватки реальных адресов путем сокращения необходимого зарегистрированного адресного пула и использования во внутренних сетях адресов из специально отведенных адресных пространств для частных сетей (либо произвольно выбранных адресов).
Указанный механизм транслирует (преобразует) адреса узлов из внутреннего адресного пространства в официально зарегистрированные адреса организации, обеспечивая полноценный доступ пользователей корпоративной сети к ресурсам услугам Internet (или других открытых сетей). Различают два основных способа отображения внутренних адресов на внешние — статический и динамический.
Динамический режим трансляции адресов обеспечивает доступ внутренних пользователей к ресурсам сети Internet, экономя зарегистрированное адресное пространство и скрывая внутренние адреса корпоративной сети. Динамический режим использует единственный реальный внешний IP-адрес для отображения всех соединений, проходящих через защищенную точку доступа (неограниченное количество внутренних адресов динамически отображаться на единственный внешний IP-адрес). Этот IP-адрес используется в динамическом режиме только для установления исходящих (от узлов внутренней сети) соединений. Используя его невозможно получить доступ к внутренним сетевым ресурсам или осуществить взлом каких-либо внутренних узлов сети снаружи.
При расширении сетевой инфраструктуры компании возникает потребность в организации доступа внешних пользователей из сети Internet к определенным ресурсам сети организации, например, для сотрудников, работающих удаленно. Кроме того, организация может создать свой Web- или FTP-сервер, который должен быть доступен для всех внешних пользователей.
Для этого используется статический режим трансляции адресов, устанавливающий однозначное соответствие адресов внутренних ресурсов их реальным адресам в глобальной сети. Этот вариант трансляции обычно используется, если по соображениям безопасности администратор не хочет использовать реальные адреса на сетевых серверах, или если по историческим причинам сеть использует произвольные внутренние адреса которым необходимо сопоставить реальные адреса серверов, чтобы пользователи Internet могли получить к ним доступ [8].
Одним из важных элементов концепции межсетевых экранов является аутентификация (проверка подлинности пользователя), то есть пользователь получает право воспользоваться тем или иным сервисом только после того, как будет установлено, что он действительно тот, за кого себя выдает. При этом считается, что сервис для данного пользователя разрешен (процесс определения, какие сервисы разрешены конкретному пользователю, называется авторизацией).
При получении запроса на использование сервиса от имени какого-либо пользователя межсетевой экран проверяет, какой способ аутентификации определен для данного субъекта, и передает управление серверу аутентификации. После получения положительного ответа от сервера аутентификации межсетевой экран осуществляет запрашиваемое пользователем соединение. Как правило, большинство коммерческих межсетевых экранов поддерживает несколько различных схем аутентификации, предоставляя администратору сетевой безопасности возможность сделать выбор наиболее приемлемой в сложившихся условиях схемы.
Многие службы сетей TCP/IP (FTP, HTTP, rlogin, Telnet и т.п.) разрабатывались довольно давно и, естественно, не учитывают современных требований по безопасности. Такого рода стандартные службы и некоторые из прикладных пользовательских приложений не требуют какой-либо идентификации и аутентификации удаленных пользователей, либо рассчитаны на управление доступом пользователей к ресурсам на основе имен и паролей, передаваемых по сети в открытом виде («открытым текстом»). Это позволяет получать доступ к таким службам и приложениям всем желающим (или тем кто может перехватить имена и пароли, передаваемые по сети).
МЭ реализуют три основных метода установления подлинности пользователя:
— User Authentication,
— Client Authentication,
— Transparent Session Authentication.
Прозрачный метод установления подлинности пользователя (User Authentication) предоставляет возможность определять привилегии доступа для каждого пользователя в отдельности (даже если это многопользовательская ЭВМ) для протоколов FTP, TELNET, HTTP и RLOGIN, независимо от IP-адреса клиентского компьютера Например, если пользователь вынужден обращаться к серверам организации из внешней сети, то администратор безопасности может разрешить ему доступ во внутреннюю сеть без того, чтобы его привилегии распространялись на всех других пользователей его рабочего компьютера.
МЭ могут выполнять проверку подлинности пользователя при помощи специального Сервера Безопасности, функционирующего на шлюзовом компьютере. МЭ перехватывает все попытки авторизации пользователя на сервере и перенаправляет их соответствующему Серверу Безопасности. После того, как подлинность пользователя установлена Сервером Безопасности МЭ открывает второе соединение на необходимый сервер приложения. Все последующие пакеты сессии также перехватываются и инспектируются межсетевым экраном на шлюзе.
Client Authentication позволяет администратору предоставлять привилегии доступа хостам (сетевым компьютерам) с определенными IP -адресами, пользователи которых, прошли соответствующие процедуры установления подлинности. В противовес User Authentication, Client Authentication не ограничена только определенными службами, и может обеспечить аутентификацию любого приложения, как стандартного, так и специфичного.
Client Authentication не является прозрачной для пользователя, но, в тоже время, не требует какого-либо дополнительного программного обеспечения или модификации существующего. Для такого вида установления подлинности администратор может указать, каким образом каждый из пользователей должен будет авторизоваться, какой сервер и какие службы ему будут доступны, сколько времени, в какие часы и дни и сколько сессий может быть им открыто.
Механизм Transparent Session Authentication можно использовать для любых служб. При этом установление подлинности будет происходить для каждой сессии.
Главный довод в пользу использования МЭ состоит в том, что без них системы подвергаются опасности со стороны таких заведомо незащищенных служб, как, например, NFS и NIS, а также зондированию и атакам с каких-либо других «доверенных» (trusted) компьютеров внутренней сети. В среде, не имеющей МЭ, безопасность целиком зависит от защиты всех компьютеров, подключенных к сети Internet. Чем больше подсеть, тем более трудно поддерживать на всех компьютерах одинаковый уровень безопасности. Поскольку ошибки и лазейки в системе безопасности становятся обычным явлением, нарушения возникают не в результате сложных атак, а из-за ошибок в конфигурации и ненадежности паролей.
МЭ может значительно повысить безопасность всей локальной сети в целом, уменьшая риск вторжения злоумышленника на каждый компьютер защищаемой сети, фильтруя заведомо незащищенные службы.
МЭ также может обеспечить защиту от таких атак, как маршрутизация источника или попытки направить маршруты к скомпрометированным объектам сети через переназначения ICMP (Internet Control Message Protocol). МЭ может (и должен) отвергать все пакеты с маршрутизацией источника или переназначенные ICMP, а затем информировать администратора о попытках нарушения защиты.
Также МЭ дает возможность контролировать доступ к отдельным системам сети. Например, одни компьютеры (информационные серверы) можно сделать достижимыми из внешних сетей, а другие (серверы поддержки локальной сети), наоборот, надежно защитить от нежелательного доступа. Это определяет политику доступа, основанную на принципе минимальной достаточности: МЭ не разрешает удаленный доступ к компьютерам или службам, которые его не требуют.
Организация МЭ может потребовать меньших затрат в том случае, если все или большая часть модифицированных программ или дополнительные программы безопасности будут размещены в системах МЭ, а не распределены по многим компьютерам сети. В частности, системы одноразовых паролей и другие дополнительные программы аутентификации можно разместить на МЭ, вместо того, чтобы устанавливать их в каждую систему, к которой необходим доступ из сети Internet.
Для некоторых приложений конфиденциальность имеет огромное значение, поскольку информация, считающаяся безобидной, на самом деле может содержать «ключи», которыми может воспользоваться нарушитель. Например, обычно с помощью МЭ блокируются (ограничиваются) такие службы, как finger и DNS. Данные, полученные от этих служб, могут быть полезными и для нарушителя, который узнает насколько часто конкретный компьютер используется, список его активных пользователей, и можно ли его атаковать, не привлекая внимания.
Если весь доступ в/из сети Internet осуществляется через МЭ, то он может регистрировать все попытки доступа и предоставлять необходимую статистику об использовании как внутренних ресурсов извне, так и ресурсов глобальной сети с компьютеров локальной сети. МЭ также может сообщать с помощью соответствующих сигналов тревоги, которые генерируются при обнаружении какой-либо подозрительной сетевой деятельности. МЭ также может генерировать различные сигналы тревоги в случае обнаружения какой-либо подозрительной сетевой деятельности.
И, наконец, следует отметить, что МЭ предоставляет средства регламентирования порядка доступа к сети, тогда как без МЭ этот порядок целиком зависит от совместных действий всех пользователей компьютеров локальной сети.
Недостатки МЭ. Существуют угрозы, которым МЭ не может противостоять. Кроме того, применение МЭ создает определенные трудности.
Наиболее очевидным недостатком МЭ является большая вероятность того, что он может заблокировать некоторые необходимые пользователю службы, такие как Telnet, FTP, XWindow, NFS и т.д. Однако, эти недостатки присущи не только МЭ, доступ к сети может быть ограничен также и на уровне отдельных СВТ, в зависимости от методики обеспечения безопасности сети.
Некоторые объекты могут обладать топологией, не предназначенной для использования МЭ, или использовать службы (сервисы) таким образом, что его использование потребовало бы полной реорганизации локальной сети.
Далее, МЭ не защищают системы локальной сети от проникновения через «люки» (backdoors). Например, если на систему, защищенную МЭ, все же разрешается неограниченный модемный доступ, злоумышленник может с успехом обойти МЭ. Связь через протоколы PPP (Point-to-Point) и SLIP (Serial Line IP) в рамках защищенной подсети является, по существу, еще одним сетевым соединением и потенциальным каналом нападения.
МЭ, как правило, не обеспечивает защиту от внутренних угроз. С одной стороны, МЭ можно разработать так, чтобы предотвратить получение конфиденциальной информации злоумышленниками из внешней сети, однако, МЭ не запрещает пользователям внутренней сети копировать информацию на магнитные носители или выводить ее на печатающее устройство. Таким образом, было бы ошибкой полагать, что наличие МЭ обеспечивает защиту от внутренних атак или вообще атак, для которых не требуется использование МЭ.
Кроме того, есть недостаток МЭ, связанный с низкой пропускной способностью — МЭ представляют собой потенциально узкое место, поскольку все соединения с сетью Internet должны осуществляться через него и еще подвергаться фильтрации.
Существует также и возможность «общего риска» — в МЭ все средства безопасности сосредоточены в одном месте, а не распределены между системами сети. Компрометация МЭ ведет к нарушению безопасности для других, менее защищенных систем.
Создание в Ethernet-сети коммутируемой структуры делает невозможным прослушивание трафика злоумышленником, находящимся в одном сегменте сети с атакуемыми узлами, поскольку в сети с коммутатором функция адресации пакетов снимается с самих компьютеров сети, и пакеты, не предназначенные конкретным хостам не проходят через них.
Можно бороться со слабостями протокола ARP кардинально — просто не использовать его. ARP-таблицу можно сформировать вручную, при этом она становится неуязвимой к ARP-атакам. Для этого нужно добавить необходимые MAC-адреса в таблицу.
Если при этом отключить использование ARP на сетевых интерфейсах, то доступны будут только те системы, MAC-адреса которых добавлены в ARP-таблицу атакуемого узла, и MAC-адрес добавлен в ARP-таблицы узлов, с которыми производится обмен трафиком [28].
Если не отключать использование ARP на сетевых интерфейсах, MAC-адрес заданный статически имеет приоритет. Если MAC-адрес для какого-то IP-адреса не задан, используется ARP-запрос.
Метод ручного формирования ARP-таблиц имеет следующие недостатки:
— добавляется много рутинной работы, связанной с добавлением и модификацией MAC-адресов (каждое изменение в сети, связанное с заменой или перестановкой сетевых карт, должно сопровождаться редактированием ARP-таблиц в файлах);
— клиентские узлы остаются по-прежнему уязвимыми к ARP-спуфингу.
Для предотвращения атак с использованием ICMP Echo Request/Reply могут быть использованы самые различные способы.
В качестве одного из таких эффективных мероприятий можно использовать запрещение приема и распространения сообщений типа directed broadcast. Использование данной меры рекомендовано документом RFC 1122, в соответствии с которым должны строиться правила функционирования маршрутизаторов в сети IP. В частности, в этом документе указано, что сообщения ICMP Echo Request, которые направлены в адрес типа directed broadcast, могут быть уничтожены без формирования какого либо диагностического сообщения [29].
Радикальным способом противодействия атакам типа smurf является запрещение трафика ICMP Echo Request/Reply на входных интерфейсах [34]. Однако данная мера лишает многих пользователей возможности использования эффективных инструментов, которые широко используются для определения статуса данного компонента сети — утилит ping, tracert и т.д.
Для устранения возможности описываемой атаки необходимо отключить на хосте обработку сообщений Redirect. Несмотря на то, что это действие противоречит требованиям к хостам, установленным в документе RFC-1122, оно выглядит совершенно разумным, особенно для хостов в сетях с единственным шлюзом, однако не все операционные системы могут поддерживать такое отключение.
Тонкий клиент (далее — терминал) представляет собой несложное устройство, предназначенное для работы в SBC (Server Based Computing) среде. В процессе работы такие клиенты взаимодействуют с развернутыми на сервере приложениями посредством ПО эмуляции терминала, отображающего передаваемую сервером информацию. У терминалов отсутствуют дисковые приводы и устройства хранения информации. Таким образом, без производительного серверного оборудования такие компьютеры работать не способны.
Процесс установки, настройки и интеграции очередного терминала занимает немного времени, как правило, в пределах одной организации используются терминалы стандартной конфигурации и вся настройка заключается в создании учетной записи на стороне сервера.
Существует мнение, что если все вычисления производятся на стороне сервера, значит его производительность должна быть равна совокупной производительности всех компьютеров, которые ранее использовали пользователи. Однако, как показывают исследования, 95% времени персональный компьютер используется на 5%, имея ярко выраженный пиковый характер загрузки. Причем пики эти от всех клиентов не носят одновременный характер.