Вопросы Теги

регистрация флагов TCP

По умолчанию .— обычный символ. Если он ведет себя так для вас, это из-за чего-то в вашей конфигурации, возможно, что-то зарыто внутри о -мой -zsh.

Привязка в основной раскладке переопределяет поведение символа даже во время добавочного поиска. Чтобы восстановить обычное поведение персонажа при инкрементальном поиске, нужно явно привязать его к self-insert. 

bindkey -M isearch. self-insert
1
06.01.2020, 16:59
1 ответ

Conntrack Netfilter для случая TCP имеет дополнительные проверки согласованности между его внутренними состояниями и эквивалентными состояниями TCP. Этот netdev 2.1 PDF документ (извините, я не смог найти его адрес netdev, это с сайта автора, вместо этого )рассказывает об этом:

L4 trackers attempt to keep state, e.g. tcp: tracks state, checks sequence numbers. Example:

  • new tcp packet? SYN bit set?
  • tcp sequence number in expected window?
  • unacknowledged data? → adjust timeout
  • rst? fin? → delete connection and/or adjust timeout

Состояние conntrack NEW соответствует состоянию TCP SYN _SENT или TCP SYN _RECEIVED . Если вы выберете условие состояния NEW в своих правилах, используя ct state new, оно никогда не будет соответствовать какому-либо пакету FIN , поскольку никогда не задействован пакет FIN . при установлении нового TCP-соединения.

Повторите попытку после удаления ct state new.

ОБНОВЛЕНИЕ:есть вторая проблема, которую я изначально не заметил. это выражение:

tcp flags & (fin | syn) == fin | syn

просто никогда не будет совпадать с флагом FIN, так как никогда не будут найдены оба FIN+SYN (, кроме нескольких случайных недопустимых попыток ). Правильное выражение должно быть:

tcp flags & (fin | syn) != 0

, который будет совпадать всякий раз, когда установлены FIN или SYN. Собственно nftables упрощает и только это отображается или требуется:

tcp flags fin,syn

Таким образом, принимая во внимание обе корректировки (ct state new, все равно необходимо удалить ), правило становится:

nft add rule filter FORWARD 'tcp dport 22 tcp flags fin,syn log prefix " my_FIN " group 1 accept

или в комплекте цепи:

 chain FORWARD {
      type filter hook forward priority 0; policy accept;
      ip saddr 1.1.1.1 ip daddr. tcp dport @myset tcp flags fin,syn counter log prefix " myprefix " group 1 accept 

 }

Если вы действительно можете обнаруживать FIN-пакеты с помощью этого вышеприведенного правила, если вы намерены фильтровать некоторые TCP-атаки (, что вам действительно нужно? ),обратите внимание, что netfilter, вероятно, сначала рассмотрит TCP FIN в первом пакете TCP-соединения как INVALID состояние :, вам может быть интересно зарегистрировать эти состояния(ct state invalid). Существуют переключатели sysctl netfilter, которые могут изменить результаты о INVALID состоянии :, включив nf _conntrack _tcp _быть _либеральным , которые не будут классифицировать это как недопустимое, и отключение nf _conntrack _tcp _loose , что остановит восстановление установленного TCP-соединения, т.е. перестанет иметь состояние NEW без SYN. Это восстановление должно произойти только после потери отслеживания соединения :после перезагрузки маршрутизатора с брандмауэром или сброса состояний conntrack с помощью conntrack -F, но кто знает, здесь можно выбрать паранойю.

1
27.01.2020, 23:40

Теги

Похожие вопросы