私はUbuntu 20.04オペレーティングシステムとdnsjavaクライアントライブラリを使用してDNSサーバーに問い合わせています。
このシステムには、dnsjava が DNS サーバーから結果を取得するために使用する一時ポート範囲 32768-61000 を除くポートのすべてのトラフィックをブロックする nftables ルールがあります。
table inet tb {
chain input {
type filter hook input priority 0; policy drop;
tcp dport 32768-61000 accept
udp dport 32768-61000 accept
....
....
}
chain forward {
....
}
chain output {
.....
}
}
32768-61000の範囲を許可することはセキュリティ上の欠陥である可能性があります。ただし、このポート範囲をブロックするとDNS解決の待ち時間が完全に増え、タイムアウトによって多くのエラーが発生します。
nftablesでポート範囲を許可するこの規則を回避する方法はありますか? DNS検証の待ち時間に影響を与えずにこれを防ぐために使用できるnftable機能はありますか?
ベストアンサー1
ステートフルファイアウォールルールを使用します。ステートフルルールの接続状態は、Netfilterによって処理されます。つながるサブシステムが利用可能nftables。
目標は、発信パケットを許可(選択)し、それを(自動で)追跡することです。つながる発信部分から元々生成されたストリームの一部のみが着信パケットとして返されることを許可します。つながるルールがこれを参照すると(すべての式ct
)、自動的に機能します。また、ルールがなくてもロードされたら、初期(ホスト)ネットワーク名前空間で自動的に機能する必要があります。
OPは完全なルールセットを提供していないため、完全なルールセットを作成せずにルールのみを置き換えています(たとえば、インターフェイスでパケットを許可するのが一般的またはlo
多分出力チェーンストアにもドロップポリシーがある可能性があります。)単純化しようとする試みはありません(たとえば、最近nftables/kernelは、TCPとUDPが単一のルールを使用できるようにします。
これは次のとおりです。
table inet tb {
chain input {
type filter hook input priority 0; policy drop;
ct state established,related accept
....
....
}
chain forward {
....
}
chain output {
.....
ct state established accept
udp dport 53 accept
tcp dport 53 accept
}
}
一時ポートはルールセットでは使用されなくなりました(ソースポート53は指定する必要はありません)。ポート53から発信されたパケットへの応答である着信パケットは自動的に受け入れられます。このrelated
セクションでは、宛先に接続できないときにICMPエラーなどの関連パケットを許可することもできます(この場合はタイムアウトを防ぎます)。
次のコマンドを使用して、プロセスの状態(コンテナが関連している場合はアプリケーションと同じネットワーク名前空間で実行されている)を追跡することもできます。
リストの場合:
conntrack -L
(ほぼリアルタイム)イベントの場合:
conntrack -E
または、より具体的には、次の2つのコマンド(両方の端末で実行)です。
conntrack -E -p tcp --dport 53
conntrack -E -p udp --dport 53
もちろん、これらすべてには多くがあります。追加文書: