現在、OUTPUTチェーンをDROPに設定しています。それをREJECTに変更して、アクセスしようとしているサービスに関する問題ではなく、ファイアウォールが原因でどこかへのアクセスが妨げられていることを知りたいと思います(タイムアウトではなく即時拒否)。しかし、iptablesはこれを気にかけていないようです。保存したルールファイルを手動で編集して復元しようとすると、iptables-restore v1.4.15: Can't set policy 'REJECT' on 'OUTPUT' line 22: Bad policy name
そして、それはルールのロードを拒否します。これを手動で設定しようとした場合(iptables -P OUTPUT REJECT
)、私はiptables: Bad policy name. Run 'dmesg' for more information.
ですが、dmesgには出力がありません。
適切なルールがカーネルにコンパイルされていることを確認し、それが確実に読み込まれるように再起動しました。
# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_FILTER=y
***
CONFIG_IP_NF_TARGET_REJECT=y
***
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
(適用可能なルールを強調するためにアスタリスクを追加)
REJECTは有効なポリシー/ターゲット(一般的に)であると私が見つけることができるものはすべて示されていますが、INPUT、FORWARD、またはOUTPUTチェーンでは無効であることを示すものは何も見つかりません。私のGoogle-fuは役に立ちません。私はGentooを利用しています。ここに誰か洞察力がありますか?
REJECT
はターゲット拡張ですが、チェーンポリシーはターゲット。マニュアルページには、それは明確ではありませんが、記載されている内容の一部は間違っています。
組み込みチェーンでは、ポリシーはACCEPT
またはDROP
のみにすることができます。以前のルールに一致しないすべてのパケットを拒否する効果が必要な場合は、最後のルールがすべてに一致することを確認し、REJECT
ターゲット拡張子を持つルールを追加します。つまり、関連するすべてのルールを追加した後、iptables -t filter -A OUTPUT -j REJECT
。
詳細については、netfilterリストの "可能なチェーンポリシーとは"スレッド を参照してください。
ドキュメントに記載されていませんでしたが、参照 here は、許可されるポリシーがACCEPTor DROPのみであることを示しています。これは、コードが2429行目付近のlibiptc
(ルールの操作を担当)の source を確認することで確認できます。
2429 if (strcmp(policy, LABEL_ACCEPT) == 0)
2430 c->verdict = -NF_ACCEPT - 1;
2431 else if (strcmp(policy, LABEL_DROP) == 0)
2432 c->verdict = -NF_DROP - 1;
2433 else {
2434 errno = EINVAL;
2435 return 0;
2436 }
元の thread は、チェーンの最後にREJECTを追加することをお勧めします。これはiptables -A OUTPUT -j REJECT
。
この直前のコードは次のとおりです。
2423 if (!iptcc_is_builtin(c)) {
2424 DEBUGP("cannot set policy of userdefinedchain `%s'\n", chain);
2425 errno = ENOENT;
2426 return 0;
2427 }
2428
したがって、ユーザー定義チェーンにポリシーを設定することはできません。
REJECT
のOUTPUT
は意味がありません。 REJECT
は、ネットワークを通過する必要がある ICMPパケット を返します。
新しい-j LOG
を最後のルールとして(したがってDROP
ポリシーの前に)追加して、OUTPUT
チェーンでこれまで何が得られるかを確認します。