"Oskar Andreasson. Iptables Tutorial 1.1.19 " - читать интересную книгу автора

Описание: Признак INVALID говорит о том, что пакет не может быть
идентифицирован и поэтому не может иметь определенного статуса. Это может
происходить по разным причинам, например при нехватке памяти или при
получении ICMP-сообщения об ошибке, которое не соответствует какому либо
известному соединению. Наверное наилучшим вариантом было бы применение
действия DROP к таким пакетам.

Эти четыре состояния могут использоваться в критерии -state. Механизм
определения состояния позволяет строить чрезвычайно мощную и эффективную
защиту. Раньше приходилось открывать все порты выше 1024, чтобы пропустить
обратный трафик в локальную сеть, теперь же, при наличии механизма
определения состояния, необходимость в этом отпала, поскольку появилась
возможность "открывать" доступ только для обратного (ответного) трафика,
пресекая попытки установления соединений извне.

4.4. TCP соединения

В этом и в последующих разделах мы поближе рассмотрим признаки
состояний и порядок их обработки каждым из трех базовых протоколов TCP, UDP
и ICMP, а так же коснемся случая, когда протокол соединения не может быть
классифицирован на принадлежность к трем, вышеуказанным, протоколам. Начнем
рассмотрение с протокола TCP, поскольку он имеет множество интереснейших
особенностей в отношении механизма определения состояния в iptables.
TCP соединение всегда устанавливается передачей трех пакетов, которые
инициализируют и устанавливают соединение, через которое в дальнейшем будут
передаваться данные. Сессия начинается с передачи SYN пакета, в ответ на
который передается SYN/ACK пакет и подтверждает установление соединения
пакет ACK. После этого соединение считается установленным и готовым к
передаче данных. Может возникнуть вопрос: "А как же трассируется
соединение?". В действительности все довольно просто.
Для всех типов соединений, трассировка проходит практически одинаково.
Взгляните на рисунок ниже, где показаны все стадии установления соединения.
Как видите, трассировщик, с точки зрения пользователя, фактически не следит
за ходом установления соединения. Просто, как только трассировщик "увидел"
первый (SYN) пакет, то присваивает ему статус NEW. Как только через
трассировщика проходит второй пакет (SYN/ACK), то соединению присваивается
статус ESTABLISHED. Почму именно второй пакет? Сейчас разберемся. Строя свой
набор правил, вы можете позволить покидать локальную сеть пакетам со
статусом NEW и ESTABLISHED, а во входящем трафике пропускать пакеты только
со статусом ESTABLISHED и все будет работать прекрасно. И наоборот, если бы
трассировщик продолжал считать соединение как NEW, то фактически вам никогда
не удалось бы установить соединение с "внешним миром", либо пришлось бы
позволить прохождение NEW пакетов в локальную сеть. С точки зрения ядра все
выглядит более сложным, поскольку в пространстве ядра TCP соединения имеют
ряд промежуточных состояний, недоступных в пространстве пользователя. В
общих чертах они соответствуют спецификации RFC 793 - Transmission Control
Protocol на странице 21-23. Более подробно эта тема будет рассматриваться
чуть ниже.

С точки зрения пользователя все выглядит достаточно просто, однако если