Защита от хакеров корпоративных сетей

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

Спуфинг никогда не бывает случайным

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

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

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

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

Это особенно важно, потому что проведенный Кеао анализ случайных изменений маршрутизации, главным образом рабочих станций Sun с многочисленными сетевыми портами, свидетельствует о том, что рабочие станции информируют о передаче данных идентификации, используя протоколы маршрутизации первых версий, например RIPvl (RIPvl, Routing Information Protocol версии 1 – протокол маршрутной информации, стандарт IGP. В сетях IP – внутренний протокол маршрутизации, используемый также для обмена информацией между сетями. В сетях IPX – это динамический протокол, используемый для сбора информации о сети и управления ею). Все, что необходимо выполнить для обновления общедоступных маршрутов по протоколу RIPvl, – это выдать широковещательное объявление о своей доступности. При этом вся сеть переводится в нестабильное состояние.

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

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

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

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