Я устанавливаю ipfw, и мне было предложено следующее: если я установлю правило только для отбрасывания SYN-пакетов для TCP, соединение не может быть установлено, и брандмауэру даже не придется смотреть на другие пакеты.
Мне это кажется нелогичным. Я думаю, что брандмауэр будет работать лучше, если я заблокирую всю связь на указанном порту (без проверки пакетов), а поскольку соединение не может быть установлено в любом случае, количество входящих пакетов будет таким же.
Есть ли разница?
Изменить: конкретная проблема, блокировка SSH от некоторого хоста:
ipfw add deny tcp from somehost to any port 22 via em0 tcpflags syn
vs.
ipfw add deny tcp from somehost to any port 22 via em0
Глобальная блокировка всего трафика на указанный порт кажется более эффективным, чем блокирование определенных видов трафика, как вы сказали, меньше проверки пакетов. Это действительно зависит от вашего намерения. Если вы хотите, чтобы служба была открыта и доступна, но не хотите, чтобы кто-то SYN сканировал этот порт, есть другие методы обнаружения такого рода активности. Если вы не хотите, чтобы служба была доступна всем вместе, закройте порт.
Я думаю, это забавно: «Если я сделаю правило отбрасывать только SYN-пакеты для TCP, соединение не может быть установлено, и файерволу даже не придется смотреть на другие пакеты».
Что ж ... если вы не хотите, чтобы брандмауэр вообще просматривал какие-либо пакеты, откажитесь от всех! Если вы хотите иметь журнал (по какой-то причине) SYN-пакетов для указанного порта, вы могли бы это сделать, но я, честно говоря, заметил какую-либо выгоду.
Тот, кто предлагал блокировать SYN-пакеты и это увеличивает производительность, должен изучить его в сети +.
Моя непроверенная теория гласит, что отбрасывание всех пакетов на порт происходит быстрее, чем отбрасывание только syn пакеты. Вот почему:
Чтобы быть эффективным, брандмауэр в любом случае должен просматривать каждый пакет. В качестве межсетевого экрана с отслеживанием состояния он может дополнительно некоторое время сгореть, пытаясь сопоставить не-SYN-пакеты с существующими разрешенными потоками из других наборов правил.
Если вы собираетесь разорвать TCP-соединение с портом, отбросьте все TCP-пакеты на порт.
Есть цель отбрасывать только пакеты syn, но это не (в первую очередь) производительность; это простой способ создать правило запрета по умолчанию, которое будет применяться к входящим соединениям, но не будет возвращать пакеты для исходящих соединений. Правило вроде этого:
deny tcp from any to any in setup
(обратите внимание, что «setup» - это сокращение от «tcpflags syn,! ack») будет блокировать все входящие TCP-соединения (которые не были разрешены правилом с более высоким приоритетом).
На самом деле здесь может быть аргумент производительности, потому что альтернатива - использование правил сохранения состояния, позволяющих возвращать пакеты в исходящих соединениях - включает динамические правила (а также создание, управление и проверку всех пакетов на их соответствие), которые предположительно имеют некоторые влияние на производительность.
Имейте в виду, что это не имеет отношения к случаю, когда правило блокирует конкретный порт с низким номером (например, 22 в вашем примере), потому что вы можете быть уверены, что ни один порт ниже 1024 не будет выделен для исходящего соединения.