Безопасность канального уровня
Канальный уровень — это самый нижний уровень в модели TCP/IP . Его также называют уровнем сетевого интерфейса и в основном эквивалентно уровню канала передачи данных плюс физическому уровню в OSI . Этот конкретный уровень имеет несколько уникальных уязвимостей безопасности, которые может использовать решительный злоумышленник.
Уровень сетевого интерфейса
[ редактировать ]Канальный уровень — это интерфейс между хост-системой и сетевым оборудованием. Он определяет, как пакеты данных должны быть отформатированы для передачи и маршрутизации. Некоторые распространенные протоколы канального уровня включают IEEE 802.2 и X.25 . [1] Уровень канала передачи данных и связанные с ним протоколы управляют физическим интерфейсом между главным компьютером и сетевым оборудованием. Цель этого уровня — обеспечить надежную связь между хостами, подключенными к сети. Услуги, предоставляемые этим уровнем сетевого стека, включают в себя: [2]
- Формирование данных – разбиение потока данных на отдельные кадры или пакеты.
- Контрольные суммы — отправка данных контрольной суммы для каждого кадра, чтобы принимающий узел мог определить, был ли получен кадр без ошибок.
- Подтверждение — отправка положительного (данные были получены) или отрицательного (данные не были получены, но ожидались) подтверждения от получателя отправителю для обеспечения надежной передачи данных.
- Управление потоком — буферизация передачи данных, чтобы гарантировать, что быстрый отправитель не перегружает более медленного получателя.
Уязвимости и стратегии их устранения
[ редактировать ]Проводные сети
[ редактировать ]Атака на исчерпание таблицы Content Address Memory (CAM)
[ редактировать ]Уровень канала передачи данных адресует пакеты данных на основе физического адреса управления доступом к среде передачи (MAC) оборудования назначения. Коммутаторы внутри сети поддерживают таблицы адресов контента (CAM), которые сопоставляют порты коммутатора с конкретными MAC-адресами. Эти таблицы позволяют коммутатору безопасно доставить пакет только на предполагаемый физический адрес. Использование коммутатора для подключения только взаимодействующих систем обеспечивает гораздо большую безопасность, чем сетевой концентратор, который передает весь трафик по всем портам. [3] позволяя перехватчику перехватывать и контролировать весь сетевой трафик. Атака на исчерпание таблицы CAM по сути превращает коммутатор в концентратор. [4] Злоумышленник заполняет таблицу CAM новыми сопоставлениями MAC-портов до тех пор, пока фиксированный объем памяти таблицы не заполнится. На этом этапе коммутатор больше не знает, как доставлять трафик на основе сопоставления MAC-адресов и по умолчанию передает трафик по всем портам. Затем злоумышленник сможет перехватывать и отслеживать весь сетевой трафик, проходящий через коммутатор, включая пароли, электронные письма, мгновенные сообщения и т. д. [5]
Атаку переполнения таблицы CAM можно смягчить, настроив безопасность порта на коммутаторе. Эта опция обеспечивает либо указание MAC-адресов на конкретном порту коммутатора, либо указание количества MAC-адресов, которые может узнать порт коммутатора. Если на порту обнаружен недействительный MAC-адрес, коммутатор может либо заблокировать нарушающий MAC-адрес, либо отключить порт. [6]
Подмена протокола маршрутизации адресов (ARP)
[ редактировать ]На уровне канала передачи данных логический IP-адрес, присвоенный сетевым уровнем, преобразуется в физический MAC-адрес . Чтобы обеспечить надежную передачу данных, все коммутаторы в сети должны поддерживать актуальные таблицы для сопоставления логических (IP) и физических (MAC) адресов. Если клиент или коммутатор не уверены в сопоставлении IP-адреса с MAC-адресом полученного пакета данных, он отправит сообщение протокола разрешения адресов ( ARP ) ближайшему коммутатору с запросом MAC-адреса, связанного с конкретным IP-адресом. Как только это будет выполнено, клиент или коммутатор обновит свою таблицу, чтобы отразить новое сопоставление. При атаке с подменой ARP злоумышленник передает IP-адрес атакуемой машины вместе со своим собственным MAC-адресом. Все соседние коммутаторы затем обновят свои таблицы сопоставления и начнут передавать данные, предназначенные для IP-адреса атакуемой системы, на MAC-адрес злоумышленника. [4] Такую атаку обычно называют атакой «человек посередине».
Защита от подмены ARP обычно основана на той или иной форме сертификации или перекрестной проверки ответов ARP. Несертифицированные ответы ARP блокируются. Эти методы могут быть интегрированы с сервером протокола динамической конфигурации хоста (DHCP), чтобы сертифицироваться как динамические, так и статические IP-адреса. Эта возможность также может быть реализована на отдельных хостах или может быть интегрирована в коммутаторы Ethernet или другое сетевое оборудование. [7]
Недостаточность протокола динамической конфигурации хоста (DHCP)
[ редактировать ]Когда клиентская система без IP-адреса входит в сеть, она запрашивает IP-адрес у резидентного DHCP-сервера . DHCP-сервер зарезервирует IP-адрес (чтобы любой, кто его запросит, не получил этот адрес) и отправит этот IP-адрес на устройство вместе с арендой, определяющей, как долго адрес будет действителен. Обычно с этого момента устройство отвечает, подтверждая IP-адрес с помощью DHCP-сервера, и DHCP-сервер, наконец, отвечает подтверждением.
При атаке с истощением DHCP, как только злоумышленник получает IP-адрес и период аренды от DHCP-сервера, он не отвечает подтверждением. Вместо этого злоумышленник наводняет DHCP-сервер запросами IP-адресов до тех пор, пока все адреса в адресном пространстве сервера не будут зарезервированы (исчерпаны). На этом этапе всем хостам, желающим присоединиться к сети, будет отказано в доступе, что приведет к отказу в обслуживании . Затем злоумышленник может настроить мошеннический DHCP-сервер, чтобы клиенты получали неправильные сетевые настройки и в результате передавали данные на компьютер злоумышленника. [8]
Одним из способов защиты от атак такого типа является использование функции защиты источника IP, доступной на многих коммутаторах Ethernet. IP Guard изначально блокирует весь трафик, кроме пакетов DHCP. Когда клиент получает действительный IP-адрес от DHCP-сервера, связь IP-адреса и порта коммутатора связывается в списке управления доступом (ACL). Затем ACL ограничивает трафик только теми IP-адресами, которые настроены в привязке. [9]
Беспроводные сети
[ редактировать ]Атака скрытого узла
[ редактировать ]В беспроводной сети многие хосты или узлы используют общую среду передачи данных. Если узлы A и B представляют собой беспроводные портативные компьютеры, взаимодействующие в офисной среде, их физическое разделение может потребовать, чтобы они взаимодействовали через точку беспроводного доступа . Но одновременно может передавать только одно устройство, чтобы избежать коллизий пакетов. Перед передачей узел А отправляет сигнал готовности к отправке (RTS). Если другой трафик не поступает, точка доступа будет транслировать по сети сигнал «Разрешена передача» (CTS). Затем узел A начнет передачу, в то время как узел B знает, что на данный момент следует приостановить передачу своих данных. Несмотря на то, что он не может напрямую связываться с узлом A, т. е. узел A скрыт, он знает, что нужно ждать, основываясь на связи с точкой доступа. Злоумышленник может воспользоваться этой функцией, наводнив сеть сообщениями CTS. Тогда каждый узел предполагает, что существует скрытый узел, пытающийся передать данные, и будет удерживать свои собственные передачи, что приводит к отказу в обслуживании. . [10]
Для предотвращения атак скрытых узлов требуется сетевой инструмент, такой как NetEqualizer. [10] Такой инструмент отслеживает трафик точки доступа и определяет базовый уровень трафика. Предполагается, что любые всплески сигналов CTS/RTS являются результатом атаки скрытого узла и впоследствии блокируются.
Атака деаутентификации (деаутентификации)
[ редактировать ]Любой клиент, подключающийся к беспроводной сети, должен сначала пройти аутентификацию в точке доступа (AP), а затем привязаться к этой точке доступа. Когда клиент покидает точку доступа, он отправляет сообщение о деаутентификации или деаутентификации, чтобы отключиться от точки доступа. Злоумышленник может отправлять сообщения о деаутентификации на точку доступа, привязанную к IP-адресам клиента, тем самым отключая пользователей от сети и требуя продолжения повторной аутентификации, что дает злоумышленнику ценную информацию о происходящем подтверждении установления связи. [11]
Чтобы смягчить эту атаку, точку доступа можно настроить на задержку эффектов запросов на деаутентификацию или разъединение (например, путем постановки таких запросов в очередь на 5–10 секунд), тем самым давая точке доступа возможность наблюдать за последующими пакетами от клиента. Если пакет данных поступает после постановки в очередь запроса на деаутентификацию или разъединение, этот запрос отбрасывается, поскольку законный клиент никогда не будет генерировать пакеты в таком порядке. [12]
Ссылки
[ редактировать ]- ^ «Структура протокола TCP/IP» . Проверено 8 февраля 2013 г.
- ^ «Уровень передачи данных» . Проверено 8 февраля 2013 г.
- ^ «Таблица CAM и атаки STP» (PDF) . Политехнический институт Нью-Йоркского университета . Проверено 8 февраля 2013 г.
- ^ Jump up to: а б О'Коннор, Терренс. «Обнаружение и реагирование на атаки на канальном уровне» . Институт САНС . Проверено 8 февраля 2013 г.
- ^ Акеунг, Дэррил. «Безопасность коммутатора — истощение DHCP и переполнение таблиц CAM (открытие при сбое), часть 1» . Архивировано из оригинала 2 февраля 2013 года . Проверено 8 февраля 2013 г.
- ^ «Сетевая безопасность на уровне канала передачи данных (уровень 2) локальной сети» . Джаввин Управление сетью и безопасность. Архивировано из оригинала 11 апреля 2013 года . Проверено 14 февраля 2013 г.
- ^ Гмосков. «Атака и защита от спуфинга ARP» . Проверено 14 февраля 2013 г.
- ^ Дмитрий, Давлетбаев. «Dhcpstarv — утилита голодания DHCP» . SourceForge.net . Проверено 14 февраля 2013 г.
- ^ «Смягчение атак уровня 2» (PDF) . Проверено 14 февраля 2013 г. [ постоянная мертвая ссылка ]
- ^ «Деаутентификация» . Aircrack-нг . Проверено 14 февраля 2013 г.
- ^ Белладо, Джон. «Атака деаутентификации» . Материалы симпозиума по безопасности USENIX, август 2003 г. Архивировано из оригинала 14 декабря 2017 года . Проверено 14 февраля 2013 г.