Категорії
FreeBSD Security

ipfw и динамические правила

Динамические правила используются там, где нужно динамически создавать ответное правило для соединения. Без их использования нужно явно задавать правила для всех соединений.

В ipfw динамическими являются правила, в которых в качестве опций указаны такие ключевые слова: setup, eslablished, keep-state или limit. Ниже приводится описание каждого из ключевых слов.

Примечание.

Начиная с версии 11.1 вводиться дополнительный параметр NAME, который можно применять к keep-state, limit. check-state. Пример:

check-state [name]
keep-state [name]
limit {src-addr | src-port | dst-addr | dst-port} N [name]

То есть, делать сопоставление по соответствующим меткам.

keep-state

Если набор правил включает одно или несколько правил с опцией keep-state, то программа ipfw предполагает работу с сохранением состояния (stateful behaviour), т.е. при успешном сопоставлении будет создавать динамические правила, соответствующие конкретным параметрам (адресам и портам) сопоставившегося пакета. Иными словами при сопоставлении брандмауэр создаст динамическое правило, по умолчанию соответствующее двунаправленному обмену данными между исходным и целевым IP-адресом/портом по тому же самому протоколу. Это правило имеет ограниченное время существования (определяемое набором переменных sysctl(8)), и это время изменяется при выявлении каждого соответствующего пакета.
Эти динамические правила с ограниченным временем существования проверяются, начиная с первого вхождения правила check-state или keep-state, и обычно используются для приоткрытия брандмауэра по требованию только для допустимого трафика.

limit {src-addr | src-port | dst-addr | dst-port} N
То же, что и keep-state, но динамическое правило заводится только в том случае, если не превышен указанный предел. Таким образом, можно легко ограничить количество одновременных подключений к некоторому хосту или порту.

check-state
Проверяет пакет по динамическому набору правил. Если найдено соответствие, дальнейший поиск прекращается, иначе – переходим к следующему правилу. Если правило check-state не найдено, динамический набор правил проверяется с первого правила keep-state.

established
Только для TCP-пакетов. Соответствует пакетам с установленными битами RST или ACK.

setup
Только для TCP-пакетов. Соответствует пакетам с установленным битом SYN, но со сброшенным битом ACK.

tcpflags спецификация

(Только для TCP-пакетов) Соответствует пакету, если его TCP-заголовок содержит заданный в спецификации список флагов через запятую.

Поддерживаются следующие флаги TCP:

fin, syn, rst, psh, ack и urg. Отсутствие определенной опции может обозначаться восклицательным знаком (!). Правило, содержащее спецификацию tcpflags, не может сопоставиться с фрагментированным пакетом, имеющим ненулевое смещение.

fin
Заявка на закрытие соединения
syn
Заявка на открытие соединения
rst
Сброс соединения — пакет высылается в том случае, если открывающей стороне отказано в соединении.
psh
Указание на то, что принимающая сторона должна сбросить буфер. Флаг выставляется в пакетах принадлежащих интерактивным соединениям. Таким как ssh(1)telnet(1) и т.п.
ack
Подтверждение о доставке.
urg
Указание на большую важность данных.

Подробнее о сопоставлении фрагментированных пакетов см. в описании опции frag.

Один из наиболее важных флагов для нас — флаг SYN, так как он выставляется у пакета открывающего TCP соединение. Из-за его важности у ipfw(8) есть специальное правило, которое отслеживает именно этот флаг — setup. Правило setup эквивалентно правилу tcpflags syn,!ack, таким образом, оно ловит первый, но не второй пакет тройного рукопожатия.

Параметры sysctl для динамических правил:

net.inet.ip.fw.dyn_buckets: 256
net.inet.ip.fw.curr_dyn_buckets: 256

Первоначально сконфигурированный и текущий размер хеш-таблицы, использующейся для хранения динамических правил. Значение должно быть степенью 2. Размер таблицы можно менять только когда она пуста, так что для изменения размера на ходу, вероятно, придется сбросить (flush) и повторно загрузить набор правил.

net.inet.ip.fw.dyn_count: 3

Текущее количество динамических правил (доступна только для чтения).

net.inet.ip.fw.dyn_max: 1000

Максимальное количество динамических правил. При достижении этого предела нельзя больше добавлять динамические правила, пока прежние не устареют.

net.inet.ip.fw.dyn_ack_lifetime: 300
net.inet.ip.fw.dyn_syn_lifetime: 20
net.inet.ip.fw.dyn_fin_lifetime: 20
net.inet.ip.fw.dyn_rst_lifetime: 5
net.inet.ip.fw.dyn_short_lifetime: 30

Эти переменные задают время существования динамических правил в секундах. При первоначальном обмене SYN-пакетами время существования устанавливается небольшим, а после получения обоих SYN-пакетов увеличивается, и снова уменьшается в ходе обмена завершающими пакетами FIN или RST.

Динамические правила выполняются не там, где они были созданы, а на первом вхождении check-state, или на первом правиле, имеющем предложение keep-state.

Итог:

setup пропускает SYN пакеты.
eslablished – пакеты с ACK’ами.
keep-state безопаснее.

Пример.

Для защиты сайта от атак шквалом поддельных пакетов TCP, безопаснее
использовать динамические правила:

ipfw add check-state
ipfw add deny tcp from any to any established
ipfw add allow tcp from my-net to any setup keep-state

Это позволит брандмауэру устанавливать динамические правила только для подключения, которое начинается с обычного пакета SYN, поступающего из нашей сети. Динамические правила проверяются при обработке первого правила check-state или keep-state. Правило check-state обычно надо помещать ближе к началу набора правил, чтобы уменьшить объем работы при просмотре набора правил. Но возможны и другие решения.

УЧТИТЕ: правила, учитывающие состояние, уязвимы для атак на службы (denial-of-service attacks) путем забрасывания шквалом SYN-пакетов, что приводит к созданию множества динамических правил. Ущерб от таких атак можно частично ограничить путем установки соответствующих переменных sysctl(8), которые управляют работой брандмауэра.

Ну ещё можно добавить такую цитату из man’a:

Dynamic rules will be checked at the first check-state, keep-state or limit occurrence, and the action performed upon a match will be the same as in the parent rule.

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *

Домашняя страничка Andy
Записки молодого админа
Самостоятельная подготовка к Cisco CCNA
Самостоятельная подготовка к Cisco CCNP
Powered by Muff