一昔前は見かけなかったが、最近時々IPv6で変なアクセスがある。
気付かなかっただけかもしれないが、今回気付いたので整理してみた。
実装
攻撃者はIPv6のアドレスを無数に生成できるので、1つのIPアドレスだけをBanしても意味はない。
それだけでなく、Banアドレスが次々追加されてしまうことから、カーネルにも負担が掛かってしまう。
そこで、nftablesでBan/Unbanするように設定した上で、IPv6の場合には/64を付けてBanする。
/etc/fail2ban/jail.local ※なければ新規作成、あれば追記
[DEFAULT]
banaction = nftables-multiport
banaction_allports = nftables-allports
/etc/fail2ban/action.d/nftables-common.local ※新規作成
[Init]
suffix =
[Init?family=inet6]
suffix = /64
addr_type = ipv6_addr \;flags interval \;
[Definition]
actionban = <nftables> add element <table_family> <table> <addr_set> \{ <ip><suffix> \}
actionunban = <nftables> delete element <table_family> <table> <addr_set> \{ <ip><suffix> \}
これによって、例えば以下のようなコマンドが生成・実行される。
nft add element inet f2b-table addr6-set-recidive \{ 2001:db8:1234:5678:90ab:cdef:0123:4567/64 \}
格好良くはないが、nftがちゃんと計算してくれて 2001:db8:1234:5678::/64 が登録される。
甘えた設計だけれど、信頼性の高いツールに計算を任せるのが一番だ。
設定をテスト。
$ sudo fail2ban-client -t
OK: configuration test is successful
設定反映。
iptablesからnftablesに変更したので、再起動している。
$ sudo systemctl restart fail2ban
動作確認。
$ sudo fail2ban-client status recidive
Status for the jail: recidive
|- Filter
| |- Currently failed: 2
| |- Total failed: 2
| `- Journal matches: _SYSTEMD_UNIT=fail2ban.service
`- Actions
|- Currently banned: 142
|- Total banned: 142
`- Banned IP list: <省略> 200.219.11.144 2001:550:9005:2000::1a 204.76.203.43 <省略>
$ sudo nft list set inet f2b-table addr6-set-recidive
table inet f2b-table {
set addr6-set-recidive {
type ipv6_addr
flags interval
elements = { 2001:550:9005:2000::/64 }
}
}
この記事を投稿した時点の話ではあるが…利用者が悪いのか、誰かが乗っ取っているのかは分からないけれど、少なくとも問題のあるアクセスだった。
設定変更前は、/128でのBanになっていたが、banactionを変更したことで、/64の範囲をBanできていることが確認できた。
ログを確認したところ、Unbanも問題なく実行できていた。
/64の範囲でBanすること
APNICの資料で、最小単位は/64、小規模拠点や一般家庭でサブネットが複数必要な場合には/56、大規模な拠点では/48を割り当てることになっているようだった。
APNIC guidelines for IPv6 allocation and assignment requests / 10. Delegations by LIRs
これはスマホであっても同様のようで、/64でIPv6アドレスが割り当てられ、時々この範囲のランダムなアドレスに変更されているということだった。
Geminiさんから、考慮点として以下が挙げられた。
- 特定の組織下で、IPv6のSNATを実装している場合に、その組織からのアクセスを全てBanする。
- ただし、これはIPv6の基本的な考え方(端末同士がユニークなIPアドレスで通信する)から外れている。
- 特殊な環境を考慮に入れて対策することで、本来の安全が確保できないのであれば、それは割り切るべき。
- モバイルの一部で/128のIPv6アドレスが割り当てられるケースがあり、広大な範囲の利用者をBanする。
- その後の確認で、これは誤認であり、1つの端末に/64の範囲が割り当てられているとの結論に至っている。
- 誤認の原因は、かつて一部の子機で、その配下にIPv6のアドレスを割り振ることができない不具合があったこと、
また、端末では/128でアドレスが見えているためだった。
以上のことから、/64の範囲でBanすることは、妥当と考えて良さそうだ。
さいごに
IPv6によるアタックは今後増えていくだろう、という時期のようだ。
今のうちから備えておけば、無駄なトラフィックやログを減らすことができて良い感じ。
今回はGeminiさんに相談していて、ちょっと困ったことがあった。
ip4mask/ip6mask、subnet_ip4/subnet_ip6といった存在しないオプションが回答される。
どうやら、Githubの公式リポジトリでそのようなやりとりが行われていたようで、それをベースに回答が生成されていた。
続けてベストプラクティスを探してもらったけれど、情報は見つからないらしい。
自分でもGoogleで検索してみたが、見つからなかった。
先輩達はとっくに答えにたどり着いていて、絶対どこかに素晴らしい回答があるはずなんだけどなぁ…
ということで、Geminiさんにnftables.confの解説をしてもらって計画を練って実装してみたのがこれ。
しばらくはこれで様子を見る。
もしも問題があれば、Logcheckがちゃんとレポートしてくれるから、その時に対処しよう。


コメントはこちらから お気軽にどうぞ ~ 投稿に関するご意見・感想・他