シンプルなステートフルファイアウォール - 版の履歴

Kgx: /* IPv6 */ 翻訳

2023-04-06T13:44:25Z

IPv6: 翻訳

← 古い版		2023年4月6日 (木) 22:44時点における版
330行目:		330行目:
	上記の設定だとデフォルトのリターンエラー {{ic\|--reject-with-icmp6-port-unreachable}} で拒否します。ただし、ファイアウォールの識別はポートスキャンアプリケーションの基本機能であり、大抵のポートスキャナは上記のように設定していても識別してしまうので注意してください。		上記の設定だとデフォルトのリターンエラー {{ic\|--reject-with-icmp6-port-unreachable}} で拒否します。ただし、ファイアウォールの識別はポートスキャンアプリケーションの基本機能であり、大抵のポートスキャナは上記のように設定していても識別してしまうので注意してください。

			次のステップでは、すべての新しい着信 ICMP エコー要求 (ping) に関するルールに適した IPv6 になるように、プロトコルと拡張子が変更されていることを確認します。
	In the next step make sure the protocol and extension are changed to be IPv6 appropriate for the rule regarding all new incoming ICMP echo requests (pings):

	# ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 128 -m conntrack --ctstate NEW -j ACCEPT		# ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 128 -m conntrack --ctstate NEW -j ACCEPT

Kgx: /* POSTROUTING チェインの設定 */ 翻訳

2023-04-06T13:43:12Z

POSTROUTING チェインの設定: 翻訳

← 古い版		2023年4月6日 (木) 22:43時点における版
430行目:		430行目:
	==== POSTROUTING チェインの設定 ====		==== POSTROUTING チェインの設定 ====

			次に、インターネットへの接続を誰に許可するかを定義する必要があります。'''eth0''' にサブネット '''192.168.0.0/24''' (192.168.0.* の形式のすべてのアドレスを意味する) があるとします。まず、FORWARD テーブルでこのインターフェースのマシンを受け入れる必要があります。これが、上記の '''fw-interfaces''' チェーンを作成した理由です。
	Now, we have to define who is allowed to connect to the internet. Let's assume we have the subnet '''192.168.0.0/24''' (which means all addresses that are of the form 192.168.0.*) on '''eth0'''. We first need to accept the machines on this interface in the FORWARD table, that is why we created the '''fw-interfaces''' chain above:

	# iptables -A fw-interfaces -i eth0 -j ACCEPT		# iptables -A fw-interfaces -i eth0 -j ACCEPT

			ここで、ローカル LAN アドレスではなく、送信元アドレスとしてパブリック IP アドレスを持つように、すべての発信パケットを変更する必要があります。これを行うには、'''MASQUERADE''' ターゲットを使用します。
	Now, we have to alter all outgoing packets so that they have our public IP address as the source address, instead of the local LAN address. To do this, we use the '''MASQUERADE''' target:

	# iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE		# iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE
440行目:		440行目:
	上記の '''-o ppp0''' パラメータは必ず必要なので忘れないでください。パラメータを記述しなかった場合、ネットワークが接続できなくなります。		上記の '''-o ppp0''' パラメータは必ず必要なので忘れないでください。パラメータを記述しなかった場合、ネットワークが接続できなくなります。

			インターフェイス '''eth1''' 上に別のサブネット '''10.3.0.0/16''' (すべてのアドレスが 10.3.. であることを意味します) があるとします。上記と同じルールを再度追加します。
	Let's assume we have another subnet, '''10.3.0.0/16''' (which means all addresses 10.3..), on the interface '''eth1'''. We add the same rules as above again:

	# iptables -A fw-interfaces -i eth1 -j ACCEPT		# iptables -A fw-interfaces -i eth1 -j ACCEPT
	# iptables -t nat -A POSTROUTING -s 10.3.0.0/16 -o ppp0 -j MASQUERADE		# iptables -t nat -A POSTROUTING -s 10.3.0.0/16 -o ppp0 -j MASQUERADE

	最後に[[インターネット共有#パケット転送の有効化\|パケット転送を有効化]]してください (既に有効にしている場合は必要ありません)。		最後に [[インターネット共有#パケット転送の有効化\|パケット転送を有効化]] してください (既に有効にしている場合は必要ありません)

			これらのサブネットのマシンは、新しい NAT マシンをゲートウェイとして使用できるようになりました。'''dnsmasq''' や '''bind''' と '''dhcpd''' の組み合わせのような DNS と DHCP サーバーをセットアップして、クライアントマシンでのネットワーク設定の DNS 解決を簡略化することができます。これは、このガイドのトピックではありません。
	Machines from these subnets can now use your new NAT machine as their gateway. Note that you may want to set up a DNS and DHCP server like '''dnsmasq''' or a combination of '''bind''' and '''dhcpd''' to simplify network settings DNS resolution on the client machines. This is not the topic of this guide.

	==== PREROUTING チェインの設定 ====		==== PREROUTING チェインの設定 ====

Kgx: /* FORWARD チェインの設定 */ typo

2023-04-06T13:40:59Z

FORWARD チェインの設定: typo

← 古い版		2023年4月6日 (木) 22:40時点における版
410行目:		410行目:
	# iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT		# iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

	次のステップは、信頼できるインターフェースの転送を有効にし、すべてのパケットが "fw-open" チェーンを通過するようにすることです。		次のステップは、信頼できるインターフェースの転送を有効にし、すべてのパケットが '''fw-open''' チェーンを通過するようにすることです。

	# iptables -A FORWARD -j fw-interfaces		# iptables -A FORWARD -j fw-interfaces

Kgx: /* FORWARD チェインの設定 */ 翻訳

2023-04-06T13:39:58Z

FORWARD チェインの設定: 翻訳

← 古い版		2023年4月6日 (木) 22:39時点における版
410行目:		410行目:
	# iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT		# iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

			次のステップは、信頼できるインターフェースの転送を有効にし、すべてのパケットが "fw-open" チェーンを通過するようにすることです。
	The next step is to enable forwarding for trusted interfaces and to make all packets pass the '''fw-open''' chain.

	# iptables -A FORWARD -j fw-interfaces		# iptables -A FORWARD -j fw-interfaces

Kgx: /* ブルートフォース攻撃 */ 情報を更新

2023-04-06T13:38:11Z

ブルートフォース攻撃: 情報を更新

← 古い版		2023年4月6日 (木) 22:38時点における版
289行目:		289行目:

	# iptables -N IN_SSH		# iptables -N IN_SSH
			# iptables -N LOG_AND_DROP
	# iptables -A INPUT -p tcp --dport ssh -m conntrack --ctstate NEW -j IN_SSH		# iptables -A INPUT -p tcp --dport ssh -m conntrack --ctstate NEW -j IN_SSH
	# iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 3 --seconds 10 -j ~~DROP~~		# iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 3 --seconds 10 -j LOG_AND_DROP
	# iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 4 --seconds 1800 -j ~~DROP~~		# iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 4 --seconds 1800 -j LOG_AND_DROP
	# iptables -A IN_SSH -m recent --name sshbf --set -j ACCEPT		# iptables -A IN_SSH -m recent --name sshbf --set -j ACCEPT
			# iptables -A LOG_AND_DROP -j LOG --log-prefix "iptables deny: " --log-level 7
			# iptables -A LOG_AND_DROP -j DROP

	ほとんどのルールは特に説明を要しないはずです。最初のルールは最大で10秒間で最大3回までの接続パケットを許可し、同じ IP からの4回以上のパケットは破棄します。次のルールでは30分以内で最大4回のパケットを許可するように規則を追加します。一部のブルートフォース攻撃はゆっくりと実行されることがあり、短い時間で何度も試行されないことがあるためです。上記のルールは追加のオプションを使用しています。オプションについて詳しくは [http://compilefailure.blogspot.com/2011/04/better-ssh-brute-force-prevention-with.html compilefailure.blogspot.com] を参照してください。		ほとんどのルールは特に説明を要しないはずです。最初のルールは最大で10秒間で最大3回までの接続パケットを許可し、同じ IP からの4回以上のパケットは破棄します。次のルールでは30分以内で最大4回のパケットを許可するように規則を追加します。一部のブルートフォース攻撃はゆっくりと実行されることがあり、短い時間で何度も試行されないことがあるためです。上記のルールは追加のオプションを使用しています。オプションについて詳しくは [http://compilefailure.blogspot.com/2011/04/better-ssh-brute-force-prevention-with.html compilefailure.blogspot.com] を参照してください。
298行目:		301行目:
	上のルールはどんなサービスでも保護することができますが、最も保護が必要なデーモンはおそらく SSH デーモンでしょう。		上のルールはどんなサービスでも保護することができますが、最も保護が必要なデーモンはおそらく SSH デーモンでしょう。

			順序に関しては、{{ic\|-A INPUT -p tcp --dport ssh -m conntrack --ctstate NEW -j IN_SSH}} が iptables シーケンスの正しい位置にあることを確認する必要があります。最初に新しい SSH 接続をキャッチするために、TCP チェーンが INPUT に接続されます。このウィキのこれまでのすべての手順が完了している場合、次のポジショニングが機能します。
	In terms of order, one must ensure that {{ic\|-A INPUT -p tcp --dport ssh -m conntrack --ctstate NEW -j IN_SSH}} is at the right position in the iptables sequence: it should come before the TCP chain is attached to INPUT in order to catch new SSH connections first. If all the previous steps of this wiki have been completed, the following positioning works:
	...		...
	-A INPUT -m conntrack --ctstate INVALID -j DROP		-A INPUT -m conntrack --ctstate INVALID -j DROP
307行目:		310行目:
	...		...

	{{Tip\|~~For self-testing the rules after setup, the actual blacklisting can slow the test, making it difficult to fine-tune parameters. One can watch the incoming attempts via~~ {{ic\|cat /proc/net/xt_recent/sshbf}}. ~~To unblock the own~~ IP ~~during testing, root is needed~~ {{ic\|# echo / > /proc/net/xt_recent/sshbf}}}}		{{Tip\|セットアップ後にルールを自己テストする場合、実際のブラックリスト登録によってテストが遅くなり、パラメーターの微調整が難しくなる可能性があります。{{ic\|cat /proc/net/xt_recent/sshbf}} を介して着信試行を監視できます。テスト中に自分の IP のブロックを解除するには、ルートが必要です {{ic\|echo / > /proc/net/xt_recent/sshbf}}}}

	=== IPv6 ===		=== IPv6 ===

Kgx: /* シングルマシン用のファイアウォール */ ip6tables.rules ファイルを翻訳して追加

2023-04-06T13:34:15Z

シングルマシン用のファイアウォール: ip6tables.rules ファイルを翻訳して追加

@@ 308行目: / 308行目: @@
 {{Tip|For self-testing the rules after setup, the actual blacklisting can slow the test, making it difficult to fine-tune parameters. One can watch the incoming attempts via {{ic|cat /proc/net/xt_recent/sshbf}}. To unblock the own IP during testing, root is needed {{ic|# echo / > /proc/net/xt_recent/sshbf}}}}
 === IPv6 ===
@@ 356行目: / 341行目: @@
 設定が完了したら、''ip6tables'' サービスを[[有効化]]してください。''iptables'' とは別個に実行させます。
 == NAT ゲートウェイの設定 ==

Kusakata: 同期

2018-01-29T14:34:54Z

同期

差分を表示

Tezca: /* INPUT チェイン */

2017-05-11T18:08:13Z

INPUT チェイン

← 古い版		2017年5月12日 (金) 03:08時点における版
112行目:		112行目:

	新しい接続を処理するために、INPUT チェインに TCP チェインと UDP チェインを適用します。いったん TCP チェインや UDP チェインで接続が許可されると、以降は		新しい接続を処理するために、INPUT チェインに TCP チェインと UDP チェインを適用します。いったん TCP チェインや UDP チェインで接続が許可されると、以降は
	~~RRELATED~~/ESTABLISHED のルールで処理されます。TCP チェインと UDP チェインはどちらも新しい接続を許可するか、または丁寧にそれらを REJECT します。新しい TCP 接続は必ず SYN		RELATED/ESTABLISHED のルールで処理されます。TCP チェインと UDP チェインはどちらも新しい接続を許可するか、または丁寧にそれらを REJECT します。新しい TCP 接続は必ず SYN
	パケットから始まります。		パケットから始まります。

Tezca: /* INPUT チェイン */

2017-05-11T09:17:59Z

INPUT チェイン

← 古い版		2017年5月11日 (木) 18:17時点における版
111行目:		111行目:
	# iptables -A INPUT -p icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT		# iptables -A INPUT -p icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT

	新し~~く来た~~接続を処理するために、INPUT チェインに TCP チェインと UDP チェインを適用します。いったん TCP チェインや UDP チェインで接続が許可されると、以降は		新しい接続を処理するために、INPUT チェインに TCP チェインと UDP チェインを適用します。いったん TCP チェインや UDP チェインで接続が許可されると、以降は
	RRELATED/ESTABLISHED のルールで処理されます。TCP チェインと UDP チェインはどちらも新し~~く来た~~接続を許可するか、または丁寧にそれらを REJECT します。新しい TCP 接続は必ず SYN		RRELATED/ESTABLISHED のルールで処理されます。TCP チェインと UDP チェインはどちらも新しい接続を許可するか、または丁寧にそれらを REJECT します。新しい TCP 接続は必ず SYN
	パケットから始まります。		パケットから始まります。

Tezca: /* INPUT チェイン */

2017-05-11T09:17:24Z

INPUT チェイン

← 古い版		2017年5月11日 (木) 18:17時点における版
111行目:		111行目:
	# iptables -A INPUT -p icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT		# iptables -A INPUT -p icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT

			新しく来た接続を処理するために、INPUT チェインに TCP チェインと UDP チェインを適用します。いったん TCP チェインや UDP チェインで接続が許可されると、以降は
	Now we attach the TCP and UDP chains to the INPUT chain to handle all new incoming connections. Once a connection is accepted by either TCP or UDP chain, it is handled by the RELATED/ESTABLISHED traffic rule. The TCP and UDP chains will either accept new incoming connections, or politely reject them. New TCP connections must be started with SYN packets.
			RRELATED/ESTABLISHED のルールで処理されます。TCP チェインと UDP チェインはどちらも新しく来た接続を許可するか、または丁寧にそれらを REJECT します。新しい TCP 接続は必ず SYN
			パケットから始まります。

	{{Note\| NEW but not SYN is the only invalid TCP flag not covered by the INVALID state. The reason is because they are rarely malicious packets, and they should not just be dropped. Instead, we simply do not accept them, so they are rejected with a TCP RESET by the next rule.}}		{{Note\| NEW but not SYN is the only invalid TCP flag not covered by the INVALID state. The reason is because they are rarely malicious packets, and they should not just be dropped. Instead, we simply do not accept them, so they are rejected with a TCP RESET by the next rule.}}