Я учусь на бакалавриате в области компьютерных наук и надеялся получить некоторые знания о способах предотвращения IP-спуфинга, но все ресурсы, которые я опробовал, развивают эту концепцию теоретически. Я хочу попробовать свои силы в одной из техник, например:
http://en.wikipedia.org/wiki/Port_knocking
http://en.wikipedia.org/wiki/SYN_cookies
Как мне смоделировать всю эту ситуацию в моей собственной системе, если я сам являюсь атакующим и сам должен защищать ее? И как только я понял это, как мне начать переводить это в термины программирования?
Первое, что вам нужно сделать, это понять, от каких атак вы хотите защититься. Я не думаю, что что-то может дать вам лучшее понимание атак, чем написание кода для проведения атак.
Я знаю три класса атак, связанных со спуфингом IP::
Опишу каждую из них более подробно. Атаки с использованием класса потребления ресурсов означают, что сервер будет получать поток пакетов, большинство из которых имеют поддельный IP-адрес источника. Поскольку поддельные IP-адреса могут иметь любое распределение, выбранное злоумышленником, нельзя отличить поддельные пакеты от легитимных. У сервера есть ресурсы только для обработки некоторого количества этих пакетов, чем больше пакетов отправляет злоумышленник, тем меньшая часть легитимных пакетов может быть обработана сервером.
Типичная атака этого класса - это SYN-флуд, о котором много лет назад было известно. Ресурс, который он потребляет на сервере, - это в основном память для сохранения состояния каждого TCP-соединения.
Файлы cookie SYN предназначены для защиты именно от этой атаки. Они берут концепцию cookie и втискивают ее в рукопожатие TCP. Файл cookie - это короткое значение, которое сервер отправляет клиенту с единственной целью: клиент может отправить его обратно на сервер. Это доказывает, что клиент получил cookie. Обычный сценарий подмены позволяет злоумышленнику отправлять пакеты только с поддельного IP-адреса, но не получать пакеты, которые сервер отправляет на этот IP-адрес.
Файлы cookie SYN действительно теряют небольшую часть функциональности по сравнению с TCP. Это было следствием необходимости быть совместимой с существующими TCP-клиентами и в то же время не использовать память на сервере, пока клиент не подтвердил IP-адрес, вернув cookie.
Стук в портах не соответствует обеим вышеупомянутым целям проектирования. Это совсем не прозрачно для клиента. Кроме того, он также требует, чтобы состояние сохранялось даже после того, как первый (детальный) пакет был отправлен на сервер. Блокировка портов просто не предназначена для предотвращения подмены IP-адресов, она предназначена для совершенно другой цели. Если вам действительно нужна эффективная защита от IP-спуфинга и вы хотите требовать обновления программного обеспечения на клиенте, есть гораздо более эффективные подходы.
Атаки отражения нацелены на использование пропускной способности сети, а не на ресурсы самого сервера. Такие атаки помещают IP-адрес жертвы в исходный IP-адрес, а любой подходящий сервер - в IP-адрес назначения. Как только сервер получит запрос, он ответит ложному источнику ответом, который может быть намного больше, чем запрос. Это позволяет злоумышленнику затопить жертву гораздо большим объемом трафика, чем он отправляет.
В этом классе атак могут использоваться несколько сервисов на основе UDP. DNS и NTP - хорошо известные службы, которые при получении небольшого запроса могут отправить большой ответ.
Самый эффективный метод защиты от атак отражения состоит в том, что сервер никогда не отправляет более одного пакета в ответ на запрос с IP-адреса, правильность которого ранее не была подтверждена, и этот ответ не должен содержать больше байтов, чем запрос. . TCP обычно считается невосприимчивым к атакам отражения, но службы на основе UDP могут быть уязвимы.
Третий класс атак - это атаки, при которых вы выполняете полную транзакцию на сервере, используя один поддельный IP-адрес на протяжении всей коммуникации. Во всех журналах на сервере будет указано, что эта транзакция была выполнена с помощью поддельного IP-адреса. Обычно это считается чисто теоретической атакой.
Обычно связь, когда это действительно важно, осуществляется по TCP. Злоумышленник должен угадать 32-битный порядковый номер, чтобы даже установить соединение. Злоумышленнику также может потребоваться угадать размер каждого ответа от сервера. А если используется шифрование, злоумышленнику, возможно, даже придется угадывать часть содержимого. Более того, злоумышленник должен завершить транзакцию до того, как хост, который подвергается спуфингу, успел отправить на сервер сообщение об ошибке, которое закрыло бы соединение.
Как проверить атаки
Создав небольшую сеть машин, несложно подменить IP-адрес любого хоста в Интернете и отправить пакеты с этого IP-адреса на ваш собственный сервер. В то же время вы можете настроить таблицу маршрутизации так, чтобы ответы на них направлялись в Интернет. С такой настройкой у вас есть реалистичная сеть для тестирования IP-спуфинга. Не забывайте подделывать только IP-адреса, которые нельзя объявлять через BGP, чтобы не создавать проблем для кого-то с отраженными пакетами.
После того, как вы подготовили установку, достаточно обычного TCP или DNS-клиента для отправки поддельных пакетов на сервер. Реальный флуд потребует немного больше усилий для настройки, но это несложно.
Как защитить DNS от спуфинга
Прежде всего, если у вас есть DNS-сервер, вы можете обнаружить, что он используется для отражения атаки. Атака отражения вызовет появление ошибки ICMP после того, как сервер отправит ответ на поддельный IP-адрес.
Что вы можете сделать, чтобы смягчить атаку? Прежде всего, вы можете отслеживать проверенные IP-адреса клиентов и поддельные IP-адреса. Очевидно, что большинство IP-адресов относятся к категории «не знаю». Когда вы получаете сообщение об ошибке ICMP в ответ на ответ DNS, IP-адрес помещается в категорию поддельных IP-адресов. Когда IP-адрес вошел в эту группу, должны быть применены меры по снижению рисков.
Чтобы смягчить атаку, DNS-сервер отправляет ответ, содержащий только запрос, но без реального ответа. Дополнительно усеченный бит должен быть установлен. Это скажет клиенту повторить запрос с использованием TCP. Успешный запрос по TCP докажет, что IP является IP-адресом реального клиента, и переместит IP-адрес в набор проверенных IP-адресов.
Если набор известных поддельных IP-адресов становится больше, чем вы хотите отслеживать, вы просто прекращаете его отслеживание и переключаетесь на использование защиты даже на IP-адресах, где состояние подделки неизвестно.
Как защитить все протоколы от спуфинга
Написание кода для каждой отдельной службы, работающей на UDP, не кажется правильным способом защиты от спуфинга. Должен быть независимый от служб способ защиты от спуфинга.
Я не думаю, что вы можете сделать это полностью обратно совместимым способом. Но давайте предположим, что мы могли бы добавить что-то новое между IP-уровнем и транспортным уровнем, что помогло бы противодействовать спуфингу, и давайте предположим, что спуфинг является достаточной проблемой для развертывания такой защиты, тогда как может выглядеть такая защита?
У меня есть идея, основанная на заголовке расширения IPv6 для достижения этой цели. Несколько месяцев назад я набросал некоторые детали. Если вы готовы реализовать его в стеке IPv6 с открытым исходным кодом, я с удовольствием переведу свой черновик на английский.