ACK パケット上の conntrack NEW が証明しないこと

ファイアウォールのログに、想定していない行が一つあります。ACK パケット、conntrack の状態は NEW、送信元アドレスは自分のものではなく、宛先ポートは開いている。これを、誰も許可していない新しい内向きの接続だと読みたくなります。しかしこの行が実際に述べているのはもっと狭いことです。そのパケットがこの hook に到達した時点で、トラッカーに一致する状態がなく、パケットは ACK を運んでいた、ということです。これは二つの異なる事柄についての二つの事実であり、どちらもハンドシェイクの完全な記録ではありません。結論を出す前に私がたどる順序は次のとおりです。

判定ではなくパケットから始める

解釈する前に観測を分けてください。TCP フラグはこのパケットを記述し、トラッカーの状態はその hook で何を知っていたかを記述し、あなたのキャプチャは記録した期間だけを記述します。

この三つを混同すると、ACK が「プロバイダーが誰かを入れた」に変わります。

hook において NEW が実際に意味するもの

iptables の conntrack 一致 は、NEW を接続を開始するパケット、または双方向のトラフィックをまだ見ていない接続に紐づくパケットとして文書化しています。ESTABLISHED は、トラッカーが両方向でパケットを見たことを意味します。どちらの定義も、そのパケットが SYN だったとも、履歴なしで到着したとも述べていません。

途中からフローを観測し始めたトラッカーは、次に来るパケットを自分が知っていることに照らして分類しますが、それが何もないこともあります。これはトラッカーの記憶についての話であり、遠隔ホストの意図についての話ではありません。

緩い追跡がほとんどの ACK の意外さを説明する

カーネルは nf_conntrack_tcp_looseを文書化しており、これによりトラッカーは開始を目にしていない TCP 接続を取り込めます。既定値のままだと、フロー途中の ACK が確立済みのフローとして採用され得ます。無効にすれば、同じパケットは NEW ではなく INVALID に分類される可能性が高くなります。どちらの結果もトラッカーの規則を述べており、アプリケーションの履歴を述べてはいません。

ですから、ラベルに基づいて理論を組み立てる前にその設定を確認してください。

退屈な原因をこの順で除外する

私が追ってきた NEW-on-ACK の事象のほとんどは、これらのいずれかで終わりました。どれも安価に確認できます。

• conntrack テーブルがフラッシュされた、またはトラッカーが再起動した。
• ホストが再起動した、またはフローが別の namespace やデバイスへ移った。
• 非対称ルーティングが SYN を、あなたがキャプチャしていない経路へ出した。
• NAT が tuple を書き換えたため、エントリが読んだ内容と一致しなくなった。
• キャプチャの開始が遅れ、先頭を一度も見ていない。

いずれも、それ以前のパケットをトラッカーの視界から外し、それ以降のパケットはそのまま残します。再起動やテーブルのフラッシュは uptime とログから確認するのが最も簡単です。非対称ルーティングは片方向のキャプチャとして現れます。NAT は厄介で、トラッカーが保存した tuple はログに印字された tuple ではありません。

先へ進む前に、どれを除外したのか、どうやって除外したのかを書き留めてください。

tuple、インターフェース、hook を読む

conntrack エントリはアドレス、ポート、プロトコルで鍵づけられるので、変換があればどのエントリに一致するかが変わります。インターフェースと hook も記録してください。誤ったインターフェースで、あるいは別のチェーンの後に見えたパケットは、経路が図のとおりではないと告げています。事象が VPN に関わる場合、 内側のパケットを見ているのか外側の搬送を見ているのかを決める。そのうえで、同じ五要素の tuple についてゲートウェイが記録した内容と比較します。

同じフローについて食い違う二つの見方は、どちらか一方だけより多くのことを教えます。

いつエスカレーションする価値があるか

到達できてはいけないサービスに到達できていることを、フロー、それを許したポリシー、両端の証拠とともに示せるときにエスカレーションしてください。状態ラベル一つや部分的なキャプチャ一つでプロバイダーの不具合を報告してはいけません。その報告は、いま読んだ説明とともに閉じられるからです。サービスが本当に露出しているなら、その境界の所有者が直すべき人であり、バグよりも委任されたポートマッピングや意図しないリスナーのほうが原因としてあり得ます。

そのうえで、一つのパケットを一つのセッション全体に見せてしまった可視性の穴を塞いでください。