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

авторов Коллектив

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

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

состояние, действия злоумышленника должны были быть замаскированы «неуместной благосклонностью» операционной системы.

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

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

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

В-третьих, не помогайте (вольно или невольно) злоумышленнику нанести ущерб сети.

Спуфинг вслепую и информированный спуфинг

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

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

Конечно, информированный спуфинг, предполагающий похищение или совместное использование передаваемых по сети идентификационных данных пользователя, является более честной

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

Спуфинг и предательство – разные вещи

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

Спуфинг не обязательно злонамерен

Говоря о спуфинге, важно понимать, что он не обязательно является следствием атаки. Избыточные системы, как, например, протокол «горячей» (оперативной) замены маршрутизатора HSRP (Hot Swappable Router Protocol) или проект Fake Линукса (www.au.vergenet.net/linux/fake), максимизируют период работоспособного состояния системы при помощи исключения получаемых от группы серверов символов точки, вставляемых вместо ошибочных символов. Проблема заключается в том, что при разработке протоколов IP и Ethernet в них было предусмотрено выделение каждому хосту только одного адреса. И если хост отказывает, то адрес становится недоступным. Без фальсификации адресов подключения были бы утеряны, а необходимую надежность можно обеспечить только переключением серверов. В случае фальсификации адресов время простоя можно сделать настолько малым, что для пользователя оно станет практически невидимым.

Предложенная компанией IBM системная сетевая архитектура SNA (системная сетевая архитектура SNA (Systems Network Architecture) содержит общее описание структуры, форматов, протоколов, используемых для передачи информации между программами IBM и оборудованием) является примером извлечения пользы из фальсификации передаваемых по сети данных. В архитектуре предусмотрен повторяющийся каждую секунду запрос дежурных пакетов (keepalive packets) по выделенной линии. Если один из таких пакетов будет пропущен, то связь разорвется. Предложенная архитектура приемлема для выделенных линий связи, чью пропускную способность можно прогнозировать, а туннелирование SNA через Интернет со свойственными ему непредсказуемыми задержками передаваемых данных часто приводит к приостановке передачи дежурных пакетов. В результате истекает короткий период времени тайм-аутов. В этом случае подключение должно быть разорвано и восстановлено заново, что требует значительных накладных расходов при туннелировании архитектуры SNA через Интернет. Для разрешения описанной ситуации в многочисленных системах были реализованы средства фальсификации либо дежурных пакетов, либо работы универсальных ЭВМ в локальной архитектуре SNA.

Вопрос заключается в том, что если эти системы получают сообщения, которые, по мнению их пользователей, они и должны получать, то при чем здесь спуфинг? Ответ состоит в том, что при проектировании этих систем были заложены определенные допущения относительно идентификации обрабатываемых потоков данных. В случае архитектуры SNA терминал предполагает, что дежурные пакеты были присланы универсальной ЭВМ. Если полученный терминалом пакет не был прислан универсальной ЭВМ, то заложенное на этапе проектирования предположение было фальсифицировано.