Недостатки служб ЛВС и взаимное доверие хостов друг к другу

Хосты тяжело поддерживать в безопасном состоянии и это занимает много времени. Для упрощения управления хостами и большего использования преимуществ ЛВС, некоторые организации используют такие сервисы, как NIS(Network Information Service) и NFS(Network File system). Эти сервисы могут сильно уменьшить время на конфигурирование хостов, позволяя управлять рядом баз данных, таких как файлы паролей, с помощью удаленного доступа к ним и обеспечивая возможность совместного использования файлов и данных. К сожалению, эти сервисы небезопасны по своей природе и могут использоваться для получения доступа грамотными злоумышленниками. Если скомпрометирован центральный сервер, то другие системы, доверяющие центральной системе, также могут быть легко скомпрометированы.

Некоторые сервисы, такие как rlogin, позволяют хостам "доверять" друг другу для удобства работы пользователей и облегчения совместного использования систем и устройств. Если в систему было совершено проникновение или ее обманули с помощью маскарада, и этой системе другие системы, то для злоумышленника не составит труда получить доступ к другим системам. Например, пользователь, зарегистрированный на нескольких машинах, может избавиться от необходимости вводить пароль, сконфигурировав себя на этих машинах так, что они будут доверять подключению с основной системы пользователя. Когда пользователь использует rlogin для подключения к хосту, то машина, к которой подключаются, не будет спрашивать пароль, а подключение будет просто разрешено. Хотя это и не так уж плохо, так как пароль пользователя не передается и не сможет быть перехвачен, это имеет тот недостаток, что если злоумышленник проникнет на основную машину под именем пользователя, то злоумышленник легко сможет воспользоваться rlogin для проникновения в счета пользователя на других системах. По этой причине использование взаимного доверия хостов друг к другу не рекомендуется[Bel89][Ches94].

Сложность конфигурирования и мер защиты

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

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

Безопасность на уровне хостов не масштабируется.

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

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

Вопрос

Если говорить строго, то TCP/IP - это стек протоколов, включающий TCP, IP, UDP (User Datagram Protocol), ICMP (Internet Control Message Protocol), и ряд других протоколов. Стек протоколов TCP/IP не соответствует модели взаимодействия открытых систем (ВОС), и его структура показана на рисунке 1.1

IP

Уровень IP получает пакеты, доставлемые нижними уровнями, например драйвером интерфейса с ЛВС, и передает их лежащим выше уровням TCP или UDP. И наоборот, IP передает пакеты, полученные от уровней TCP и UDP к нижележащим уровням.

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

Высокоуровневые сервисы TCP и UDP при приеме пакета предполагают, что адрес отправителя, указанный в пакете, является истинным. Другими словами, адрес IP является основой для аутентификации во многих сервисах; сервисы предполагают, что пакет был послан от существующего хоста, и именно от того хоста, чей адрес указан в пакете. IP имеет опцию, называемую опция маршрутизации источника, которая может быть использована для для указания точного прямого и обратного пути между отправителем и получателем. Этот путь может задействовать для передачи пакета маршрутизаторы или хосты, обычно не использующиеся для передачи пакетов к данному хосту-получателю. Для некоторых сервисов TCP и UDP пакет IP c такой опцией кажется пришедшим от последней системы в указанном пути, а не от своего истинного отправителя. Эта опция появилась в протоколе для его тестирования, но [Bel89] отмечает, что маршрутизация источника может использоваться для обмана систем с целью установления соединения с ними тех хостов, которым запрещено с ними соединяться. Поэтому, то, что ряд сервисов доверяют указанному IP-адресу отправителя и полагаются на него при аутентификации, очень опасно и может привести к проникновению в систему.

TCP

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

TCP передает полученную информацию приложениям верхнего уровня, например клиенту или серверу TELNETа. Приложения, в свою очередь, передают информацию обратно уровню TCP, который передает ее ниже уровню IP, после чего она попадает к драйверам устройств, в физическую среду и по ней передается до хоста-получателя. Сервисы с установлением соединения, такие как TELNET, FTP, rlogin, X Windows и SMTP требуют надежности и поэтому используют TCP. DNS использует TCP только в ряде случаев( для передачи и приема баз данных доменных имен), а для передачи информации об отдельных хостах использует UDP .

UDP

Как показано на рисунке 1.1, UDP взаимодействует с прикладными программами на том же уровне, что и TCP. Тем не менее, он не выполняет функции исправления ошибок или повторной передачи потерянных пакетов. Поэтому UDP не используется в сервисах с установлением соединения, которым требуется создание виртуального канала. Он применяется в сервисах типа запрос-ответ, таких как NFS, где число сообщений в ходе взаимодействия гораздо меньше, чем в TELNET и FTP. В число сервисов, использующих UDP, входят сервисы на базе RPC, такие как NIS и NFS, NTP( протокол сетевого времени) и DNS(также DNS использует TCP).

Пакеты UDP гораздо проще подделать, чем пакеты TCP, так как нет этапа установления соединения( рукопожатия).[Ches94]. Поэтому с использованием сервисов на базе UDP сопряжен больший риск.

ICMP

ICMP (Протокол межсетевых управляющих сообщений) находится на том же уровне, что и IP; его назначение - передавать информацию, требуемую для управления траффиком IP. В-основном, он используется для предоставления информации о путях к хостам-получателям. Сообщения ICMP redirect информируют хосты о существовании боле коротких маршрутов к другим системам, а сообщения ICMP unreachable указывает на наличие проблем с нахождением пути к получателю пакета. Кроме того, ICMP может помочь корректно завершить соединение TCP, если путь стал недоступен. PING является широко распространенным сервисом на базе ICMP.

[Bel89] рассматривает две проблемы с ICMP: старые версии Unix могут разорвать все соединения между хостами, даже если только одно из них столкнулось с проблемами. Кроме того, сообщения о перенаправлении пути ICMP могут быть использованы для обмана маршрутизаторов и хостов с целью заставить их поверить в то, что хост злоумышленника является маршрутизатором и пакеты лучше отправлять через него. Это, в свою очередь, может привести к тому, что атакующий получит доступ к системам, которым не разрешено иметь соединения с машиной атакующего или его сетью.