Многие программисты полагают, что после того как данные попали в сеть, противник может разве что прочитать их, но не модифицировать. Часто разработчик вообще не задумывается о конфиденциальности на уровне сети, поскольку заказчик не выдвигал таких требований. Однако существуют инструменты, позволяющие перенаправить трафик и даже манипулировать потоком данных.
Большинство людей считают, что данные поступают в сеть слишком быстро для того, чтобы противник сумел вклиниться в поток, а потом они передаются от одного маршрутизатора другому, где находятся в безопасности. Программисты, работающие в сетях, оборудованных коммутаторами, часто уверены, что никаких проблем возникнуть не может.
Но в реальном мире противник, оборудовавший себе плацдарм в локальной сети по любую сторону от маршрутизатора, занимает прекрасную позицию для организации атаки на сеть в силу отсутствия защитных мер в инфраструктуре сети–жертвы. Если противник находится в том же сегменте сети, что и одна из оконечных точек (например, подключен к концентратору), то он может просматривать весь трафик в этом сегменте и обычно способен перехватить его. Но даже если противник подключен к коммутатору (концентратор, в котором отдельные порты не «видят» трафика на других портах), то и тогда техника подлога по протоколу ARP (Address Resolution Protocol – протокол разрешения адресов) позволяет ему притвориться шлюзом и перенаправить на себя весь трафик. Обработав трафик, противник может отправить его первоначальному адресату. Есть и другие методы. Например, некоторые коммутаторы можно затопить потоком ARP–запросов, в результате чего они переходят в пропускающий (promiscuous) режим и начинают работать как обычный концентратор.
Как все это реализуется? ARP – это протокол, отображающий адреса уровня 2 (Ethernet MAC) на адреса уровня 3 (IP). Противник может объявить, что его собственный МАС–адрес соответствует IP–адресу шлюза. Когда остальные машины видят такое объявление, они начинают маршрутизировать весь трафик через компьютер противника. У этой проблемы нет практичного и универсального решения, которое можно было бы реализовать быстро, поскольку речь идет о базовых службах на уровне Ethernet, которые только–только начинают обсуждать в органах стандартизации. Кстати, в беспроводных сетях эта проблема стоит еще более остро.
Даже на уровне маршрутизатора не всегда можно предполагать отсутствие вектора атаки. Популярные маршрутизаторы работают под управлением больших и сложных программ на языке С, которые могут быть подвержены ошибкам переполнения буфера и иным, что позволит противнику исполнить произвольный код. Пока производители маршрутизаторов не перейдут на технологии, которые сведут к минимуму или вообще исключат риск такой катастрофы, опасность будет существовать. И ведь находили же в прошлом ошибки переполнения буфера в маршрутизаторах. См., например, бюллетени CVE–2002–0813, CVE–2003–0100 и CAN–2003–0647 в базе данных CVE (http://cve.mitre.org).
Сетевые атаки весьма разнообразны.
□ Подслушивание. Противник прослушивает сеанс связи и извлекает всю ценную информацию, например имена и пароли пользователей. Даже если пароль передается не в читаемом виде (а часто так и есть), почти всегда возможно путем перебора по словарю раскрыть его. А иногда и это не нужно, поскольку пароль не шифруется, а лишь маскируется.
□ Воспроизведение. Противник извлекает уже имеющиеся в потоке данные и воспроизводит их. Это может быть весь поток или какая–то его часть. Например, можно воспроизвести данные аутентификации, чтобы зарегистрироваться под чужим именем, а затем начать сеанс от чужого имени.
□ Подлог (spoofing) . Противник представляет данные, как бы пришедшие от другого участника сеанса связи, хотя на самом деле данные подложные. Обычно для этого требуется открыть новое соединение, возможно, воспроизведя данные, посланные во время предыдущей аутентификации. В некоторых случаях такую атаку можно провести против уже существующего соединения, особенно когда виртуальное соединение устанавливается поверх транспортного протокола, не поддерживающего соединений (обычно UDP). Очень трудно (хотя и возможно) проделать такое с протоколами, требующими установления соединения, если операционная система должным образом рандомизирует порядковые номера, применяемые в протоколе TCP.
□ Вмешательство. Противник модифицирует передаваемые данные, возможно, вполне невинно, например заменяя единичный бит нулевым. В протоколах на базе TCP это довольно сложно из–за кодов циклической избыточности (CRC), но поскольку CRC–код не является криптографически безопасным, то такую защиту легко обойти, когда есть возможность поменять несколько битов, не оказывающих существенного влияния на обработку данных.
□ Перехват. Противник ждет момента установления соединения, а затем отрезает одного из участников, подменяя все исходящие от него данные своими. В наши дни внедрить новый трафик в середину сеанса или подделать существующий довольно трудно (по крайней мере, в случае использования протокола TCP и современных операционных систем на обоих концах), но все–таки возможно.
Если вас беспокоит безопасность сетевых соединений, то вы должны знать, какие услуги могут предоставлять приложения. Мы сначала поговорим о базовых службах, а потом – в разделе «Искупление греха» – о способе достижения цели. Как бы то ни было, для защиты от такого рода атак необходимо обеспечить три основных сервиса безопасности.
□ Начальная аутентификация. Необходимо гарантировать, что каждая сторона знает, с кем общается. Есть много способов добиться этого, но самыми распространенными являются пароли в силу своего удобства. Говоря о данном грехе, мы не будем затрагивать вопросы аутентификации, но еще вернемся к ним в грехах 10, 11 и 17.
□ Аутентификация во время сеанса. Даже если вы уверены в том, с кем начали общаться, хотелось бы удостовериться, что вы продолжаете обмен данными с тем же лицом. Это более строгий вариант обеспечения целостности сообщений. Легко убедиться в том, что пришло именно то сообщение, которое было отправлено, но неплохо бы знать еще, что его отправил законный пользователь, а не противник. Например, протокол TCP обеспечивает слабую проверку целостности сообщения, но никакой аутентификации.
□ Конфиденциальность. Это, наверное, наименее важный из сервисов безопасности. Есть немало ситуаций, когда нужно лишь гарантировать аутентичность данных, а шифровать их необязательно. Обычно не имеет смысла обеспечивать конфиденциальность без начальной и последующей аутентификации. Например, если противник пользуется потоковым шифром, например RC4 (у него есть также режимы работы, обеспечивающие блочное шифрование), то он может переставить случайные биты в шифртексте, и без надлежащей аутентификации сообщения об этом никто не узнает. Если противнику известен формат данных, то он сможет добиться и более разрушительного эффекта, поменяв конкретные биты.
Родственные грехи
Совсем несложно полностью игнорировать вопросы безопасности в сети. Но не менее просто воспользоваться сервисами безопасности неправильно, особенно это относится к протоколам Secure Sockets Layer и Transport Layer Security (SSL / TLS) (Грех 10). Аутентификация тоже является важной частью инфраструктуры сетевой безопасности и также нередко становится точкой отказа (см., например, грехи 11, 15 и 17). Для обеспечения конфиденциальности нужен криптографически сильный алгоритм генерирования случайных чисел (грех 18).