|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Vadim Guchenko 2:5020/400 20 Jul 2007 14:00:51
To : Victor Sudakov
Subject : ipfw and keep-state
--------------------------------------------------------------------------------
>> VS> Hасчёт established спорно. Пропускать пакет от кого попало только
>> на том основании, что на нём есть ACK bit?
>> А чем это хуже ситуации с динамическими правилами?
VS> Теоретически, может случиться ACK flood и firewall не спасет.
Попробую рассмотреть все варианты, связанные с TCP.
1. Предположим, некоторый сервер, имеющий реальный адрес, установил
TCP-соединение с удаленным хостом:
local_ip:local_port <-> remote_ip:remote_port
Если никакого файрвола нет, то сервер будет принимать все приходящие
TCP-пакеты. Однако в обработку, в рамках рассматриваемого соединения,
попадут только те пакеты, которые пришли с remote_ip:remote_port на
local_ip:local_port. Остальные пакеты будут отброшены TCP-стеком (либо
обработаны в рамках других активных соединений). После того, как проверка
адресов и портов прошла успешно, анализируются другие поля в TCP-пакете, в
частности sequence number. Если тупо флудить с различных адресов и портов
TCP-пакетами на local_ip:local_port, это ничего не даст, т.к. все пакеты
будут проигнорированы TCP-стеком. Для получения результата флудить нужно
так, чтобы в src_ip был remote_ip, а в src_port - remote_port. Hо даже если
и это будет выполнено, встает вопрос об угадывании sequence number, времени
посылки пакета и т.д.
Предположим где-то на шлюзе настроен ipfw с правилом allow tcp from any to
any established. Т.е. он пропускает через себя все TCP-пакеты, кроме
запросов на установку соединения. Ситуация не меняется. Любые TCP-атаки,
включая флуд, будут прозрачно пропущены через ipfw и обработаны
(проигнорированы) TCP-стеком на локальном сервере.
Предположим на шлюзе настроен ipfw, создающий на каждое исходящее
TCP-соединение динамическое правило. Соответственно, ipfw пропустит внутрь
сети только TCP-пакеты вида:
remote_ip:remote_port -> local_ip:local_port
Разница с предыдущими двумя случаями в том, что простой флуд не дойдет до
целевого сервера, а будет отброшен еще на шлюзе с ipfw. Однако
целенаправленная атака, когда подменяются src_ip и src_port, все равно
пройдет через ipfw и дойдет до сервера назначения.
2. Теперь предположим, что сервер, который установил TCP-соединение с
удаленным хостом, имеет серый адрес и находится за натом. Для простоты будем
считать, что нат не меняет номера портов - только ip-адреса:
local_ip:local_port <-> [local_ip <- nat -> public_ip] <->
remote_ip:remote_port
TCP-пакеты в рамках установленного соединения будут приходить снаружи на нат
в виде:
remote_ip:remote_port -> public_ip:local_port
Только у таких входящих пакетов нат будет заменять public_ip на local_ip и
соответветственно только такие пакеты дойдут до нужного сервера внутри сети
в соответствии с роутингом. Все остальные пакеты, у которых хотя бы один из
четырех элементов будет другим, будут проигнорированы натом (возвращены
после диверта неизмененными). В соответствии с роутингом они осядут на
шлюзе, т.е. до целевого сервера не дойдут. Иными словами, обычный флуд будет
отброшен на шлюзе с натом. Целенаправленная же атака с подмененными src_ip и
src_port опять-таки пройдет через нат.
Выводы. Если имеет место спуфинг и кто-то целенаправленно пытается
вклиниться в TCP-соединение, то ни один из способов не поможет - все они
пропустят пакет до сервера назначения. И уже TCP-стек на сервере назначения
будет решать отбрасывать или принимать полученный пакет. Разница во всех
описанных способах только в том, где будет оседать TCP-флуд с разных
адресов - на целевом сервере или на шлюзе. Сам по себе флуд не представляет
угрозы для безопасности, он может лишь забить сетевые каналы и привести к
отказу в обслуживании. Конкретно TCP-флуд, попадающий под правило
established, к отказу в обслуживании приведет вряд ли, т.к. поддельные
TCP-пакеты будут отбрасываться TCP-стеком еще не доходя до приложения. Далее
можно рассуждать так. Если сервер имеет серый адрес, т.е. на шлюзе есть нат,
то никакого файрвола для пакетов, которые обрабатывает нат, не надо вообще.
Все функции по защите выполняет сам нат. Если же сервер имеет реальный
адрес, то видимо он принимает какие-то входящие соединения извне. А это
значит, что как минимум один порт на ipfw шлюза должен быть открыт для этого
сервера. Т.е. через этот порт можно честно флудить пакетами без всяких
заморочек со спуфингом, и эти пакеты дойдут до сервера назначения и даже
будут приняты приложением, т.е. DOS обеспечен. В этом случае делать
keep-state для TCP смысла нет. Все равно от флуда не спасет. Эффективнее
пропустить весь established TCP-трафик. А если машина не принимает никаких
соединений извне, но все же имеет реальный адрес, наверное это как раз тот
случай, когда реальный адрес берут для того, чтобы иметь полноценный выход в
инет, не ограниченный ни натом, ни файрволом. Т.е. преполагается, что такая
машина готова принимать извне любые пакеты, пришедшие на ее адрес. В том
числе флуд. Таким образом, я не вижу преимуществ использования keep-state
для исходящих TCP-пакетов. А вот для исходящих UDP без keep-state уже никак.
Почему allow tcp from any to any established эффективнее чем allow tcp from
any to any keep-state? Потому что keep-state требует памяти для создания
динамических правил. В случае большого трафика - много памяти. Этой памяти
может внезапно не хватить и часть пакетов потеряется. Кроме того, нужно
время для просмотра таблицы динамических правил.
--
Best regards, Vadim.
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
