방화벽: nftable 카운터 규칙

방화벽: nftable 카운터 규칙

몇 달 전에 데비안이 추천하는 프로그램을 사용하여 데비안 노트북의 방화벽을 데비안 iptables으로 마이그레이션했는데 nftables모든 것이 괜찮아 보였습니다. 몇 달이 지난 지금, 저는 해당 마이그레이션 프로세스에서 생성된 규칙 세트를 검토하고 구문을 배우려고 노력하며 nftables, 제가 이해하지 못하고 올바르지 않을 수 있다고 의심되는 일부 카운터 기반 규칙을 살펴보겠습니다. 위키가 유용한 교육 리소스인 것을 찾지 못했고 nftables이러한 유형의 문제를 다루는 다른 온라인 교육 리소스도 찾지 못했습니다.

기본 자동 마이그레이션 규칙 세트에는 다음이 포함됩니다.

table inet filter {
  chain INPUT {
    type filter hook input priority 0; policy drop;
    counter packets 123 bytes 105891 jump ufw-before-logging-input                                                                                                                                
    counter packets 123 bytes 105891 jump ufw-before-input
    counter packets 0 bytes 0 jump ufw-after-input
    counter packets 0 bytes 0 jump ufw-after-logging-input
    counter packets 0 bytes 0 jump ufw-reject-input                                                                                                                                               
    counter packets 0 bytes 0 jump ufw-track-input                                                                                                                                                
  }

처음 두 counter진술은 내 관심을 끌었던 예입니다. 내 말이 맞나요? 그들은 "ufw-before-foo 섹션의 규칙으로 점프하지만 처음 123개 패킷과 처음 105891바이트가 수신된 후에만 가능합니다"라고 말합니다.

  1. 패킷 0바이트 0으로 즉시 시작하지 않는 이유는 무엇입니까?
  2. nftables가 지원하는 것으로 보이는 >= 구문을 사용하면 어떨까요?
  3. 이 숫자는 임의적입니까? 마이그레이션 중 결함으로 인한 것일 수 있습니까?

위의 규칙 세트에는 유사한 문제가 있을 수 있는 다음 링크로의 이동이 포함되어 있습니다. 다음은 그 일부입니다.

  chain ufw-before-input {
    iifname "lo" counter packets 26 bytes 3011 accept
    ct state related,established counter packets 64 bytes 63272 accept
    ct state invalid counter packets 0 bytes 0 jump ufw-logging-deny
    ct state invalid counter packets 0 bytes 0 drop
    ...
  }
  1. 이전에 수신된 26개 또는 64개의 패킷을 기준으로 수락 결정을 내리는 이유는 무엇입니까?
  2. 방화벽은 시작 및 네트워크 검색/연결 후 언제든지 새로 고칠 수 있는데 왜 초기 패킷을 모두 삭제합니까?

위에서 언급했듯이 이러한 규칙은 몇 달 동안 시행되었으므로 어떤 부정적인 영향을 미칠지 궁금합니다. 마음에 떠오르는 유일한 후보는 노트북이 때때로 Wi-Fi 연결을 설정하는 데 어려움을 겪는 반면(특히 절전 모드에서 다시 시작한 후) 근처에 있는 두 번째 노트북에는 그러한 문제가 없다는 것입니다.

  1. 이러한 패킷 삭제 규칙이 Wi-Fi 연결 협상에 어려움을 주는 원인이 될 수 있습니까?

답변1

아니요, 설명이 훨씬 간단합니다.카운터문에 선택적 매개변수가 있습니다.데이터 팩그리고바이트패킷이 해당 규칙에 도달할 때 카운터에서 계산된 패킷 수와 바이트 수를 표시합니다. 카운터에는 필터가 없고,어느따라서 패킷(루프백 포함)의 가치가 증가하므로 매우 조기에 신속하게 발생할 수 있습니다. 변환을 수행하는 도구는 iptables 기본 카운터를 보고 충실도를 보장하기 위해 해당 값을 변환하도록 선택합니다.

따라서 일반적으로 규칙을 작성할 때 이러한 값을 설정하지 않고 counter개별적으로 간단한 값을 입력하면 모두 기본값인 0을 얻습니다. 이 값은 패킷이 통과함에 따라 증가합니다.선택 과목, 특히 명명된 카운터에 사용되는 경우상태 저장 객체(유사한 것을 사용하여) 표시하고 재설정하는 것도 가능하며 nft reset counters, 어떤 형태의 회계에서는 규칙 세트를 작성할 때 이러한 값을 설정할 수 있습니다. 일반적으로 다시 시작하기 전에 저장된 규칙 세트를 복원할 때입니다. 이것지정된 변형으로 사용될 때만 재설정 가능, 익명 카운터를 "인라인"하는 대신. 규칙의 일치를 변경하는 데 사용할 수 없습니다.다른 선택은 없어표시하는 것보다.

발생하는 Wi-Fi 문제할 수 없다어떤 이유로든 발생한카운터성명.

이제 패킷 수를 사용하여 nftables 방화벽에서 규칙 사용을 제한하려는 경우 필요에 따라 몇 가지 다른 방법이 있습니다.

  • 또 다른 상태 저장 객체(익명으로도 사용 가능하지만,명명된 사용 시에만 재설정할 수 있습니다.). 그런 다음 규칙이 일치하지 않도록 하거나 개수에 따라 일치를 시작하도록 할 수 있습니다.

  • 가지다한계계산 명세서비율. 예를 들어 로그 규칙으로 인해 로그 파일이 너무 많아질 수 있다는 우려가 있는 경우 이를 사용하여 완료되는 로그의 양을 제한할 수 있습니다. 또한 특정 리소스의 속도를 제한할 수도 있습니다(종종 conntrack과 함께 다른 필터와 함께 사용됨).

  • 충분히 새로운 nftables(0.9.2?)와 커널(4.18?)을 사용하면CT 수 연결 추적 표현일반적으로 특정 리소스(ssh, 웹 서버...)에 대한 동시 액세스를 제한하기 위해 conntrack을 사용하여 설정된 연결 수를 계산합니다.

관련 정보