Linux глазами хакера
Шрифт:
В Интернете и в сетях, где используется Switch, такой трюк не проходит. Сетевая карта видит только свой трафик, т.к. чужие пакеты исключаются на коммутаторах или маршрутизаторах, которые установлены у провайдера. В этом случае на помощь приходит активный сниффинг.
На первый взгляд, прослушивание трафика абсолютно безопасно для хакера, и некоторые начинающие запускают программы сниффинга и сидят с ними целый день в ожидании заветных паролей. Но администратор может и должен определить наличие в сети прослушивания, даже пассивного, и наказать любознательного умельца, пока он не натворил бед.
Начнем с поиска пассивного сниффера. Для его обнаружения необходимо разослать всем компьютерам эхо-запросы (пакеты ping),
Но хакеры не так уж глупы и защищаются сетевыми экранами. Достаточно запретить исходящий ICMP-трафик, и компьютер злоумышленника уже не ответит на ваши запросы, а значит, ничего определить нельзя.
Если на вашем сервере резко повысилась средняя загрузка процессора, то причиной может быть подброшенный сниффер, т.к. в этом случае сетевая карта начинает отдавать операционной системе весь проходящий трафик.
Чтобы узнать, в каком режиме работает ваш сетевой интерфейс, необходимо выполнить команду:
Если установлен параметр
14.5.3. Активное подслушивание
Активные снифферы делают все возможное, чтобы перенаправить чужой трафик на себя. Это достигается с помощью модификации таблиц маршрутизации и обмана сетевого оборудования.
С точки зрения реализации активный сниффер сложнее. Чтобы понять, как он работает, необходимо разобраться, как проходят пакеты на самых низших уровнях. Для передачи пакета в Интернете сетевые устройства оперируют IP- адресами. Когда вы обращаетесь по IP-адресу к какому-либо компьютеру в рамках одного и того же сегмента, используется MAC-адрес, а если адресат находится в другой сети, то пакет направляется на шлюз по умолчанию, который является маршрутизатором или компьютером, перенаправляющим пакеты на другой маршрутизатор, и он уже по IP-адресу найдет нужную сеть. Когда сеть обнаружена, внутри нее пакет следует до получателя по MAC-адресу.
Как видите, внутри сети пакеты передаются только по MAC-адресу. Вот тут нам для понимания пригодится модель OSI, которую мы рассматривали в разд. 4.5.1. Сетевая карта, хаб и большинство коммутаторов работают на канальном уровне и оперируют только MAC-адресами. Заголовки других уровней недоступны и непонятны этим устройствам. Маршрутизаторы и коммутаторы разбирают пакет до уровня сети, где есть IP-адрес, т.е. внутри сети без этих устройств пакеты могут передаваться только по MAC-адресу.
Что же получается? В локальной сети, даже если вы отправляете данные на IP-адрес, используется физический адрес компьютера. При работе через Интернет всегда используется IP-адресация. Но просто направить в сеть пакет с IP-адресом нельзя, ведь сетевые карты не работают с IP, а пользователи никогда не указывают MAC.
Как же тогда узнать MAC-адрес получателя? Сначала отправитель пытается выяснить, у какого компьютера установлен IP-адрес в виде XXX.XXX.XXX.XXX. Для этого используется протокол ARP (Address Resolution Protocol, протокол разрешения адресов), который рассылает широковещательный запрос всем компьютерам сети и выясняет, где находится экземпляр с указанным IP-адресом. В этом пакете заполнен только IP-адрес, а вместо
искомого MAC-адреса указано значение FFFFFFFFFFFFh, которое сетевая карта должна обработать и обязательно отдать на разборку операционной системе. Вот тут ОС рассматривает пакет на третьем уровне, где работает ARP-протокол, и если в сети есть компьютер с запрошенным IP, то в ответном пакете будет указан его MAC-адрес. Вот теперь мы получили искомый адрес.А кто мешает нашему компьютеру отвечать на чужие ARP-запросы и представляться участникам сети от чужого лица? Вот и я говорю, что никто. У протокола ARP нет никакой авторизации и проверки достоверности ответа. Значит пакет получит тот компьютер, который откликнется, вне зависимости от его IP.
Но неприятности еще впереди. Получив ответ на ARP-запрос, ОС кэширует результат и при последующих обращениях к IP-адресу не отправляет широковещательный запрос, а использует информацию из ARP-кэша. И вот теперь о самом страшном. Некоторые ОС (не будем указывать пальцем) кэшируют ARP-ответы не только на свои, но и на чужие запросы. Таким образом, злоумышленник может разослать информацию (ARP-ответы) со своим MAC-адресом, но чужими IP, всем компьютерам, и они добавят в кэш неверные записи.
Для просмотра текущего кэша вашей ARP-таблицы можно выполнить команду
Наиболее интересными колонками здесь являются:
□
□
□
□
Если вам необходимо обратиться к компьютеру с IP-адресом 192.168.77.10, то по этой таблице ОС определяет, что он находится на сетевом интерфейсе eth0, и его аппаратный адрес равен 00:03:0D:06:A4:6C.
Если вы явно видите, что адрес поддельный, то следует избавиться от неверных записей. После этого по MAC-адресу можно найти компьютер злоумышленника.
Для удаления записи необходимо использовать команду
Если теперь просмотреть кэш ARP-таблицы, то в результате вы увидите вместо MAC-адреса запись (
При работе с кэшем ARP вы должны знать, что записи в нем не вечны. Все, что добавляется в кэш через ARP-протокол, а не вручную, имеет статус Dynamic (динамический). Такие записи через определенное время удаляются. Хакеры знают это, поэтому могут рассылать ARP-ответы с фальшивым MAC-адресом через определенные промежутки времени. Если вы будете просто удалять каждый раз неверные записи из кэша, то эффекта это не даст. Необходимо искать злоумышленника.
Чтобы вам проще было определить поддельные записи, можно использовать протокол RARP (Reverse ARP, обратный ARP), который по известному MAC-адресу запрашивает IP-адрес. В результате вам должны вернуться ответы со всех компьютеров, IP-адреса которых находятся в вашем кэше. Помните, что записей может быть несколько. Например, в моем компьютере на сетевой карте установлено сразу два адреса для одновременной работы в двух логических сетях. Это нормальная ситуация. А вот если ответ от какого-либо IP не получен, то такую запись следует удалить.