DigiLoog

ns-labのサーバ本番環境は、DNSBL・アクセスログ・ドロップログとかを解析して、
スクリプトで自動的にFWポリシーを生成しiptablesに処理を渡す構成でセキュリティ担保をしている。
と言っても、ログを処理するスクリプトを適当に書いて、cronで回しているだけですが (´・ω・｀)

このスクリプトに「処理が完了したら管理用アドレスへメールを飛ばす」処理も入れてある為、
ほぼ毎日メールが飛んできて、正常にスクリプトが動いてるとかも判別出来るようになっている。

で、先日この完了メールが飛んで来ておらず自鯖を確認した所、iptablesのプロセスが暴走しており、
再現性確認とスクリプト改修の長い旅が始まった…

ちなみに、今回発生した問題を纏めると下記のような現象が起きた

• iptablesポリシーを5,000～30,000程度読み込ませている最中にハングアップし、
  プロセスのCPU使用率が100%になる
• ハングアップすると、"Another app is currently holding the xtables lock"のエラーが出力され、
  iptablesのポリシー変更が出来ない
• ハングアップすると、"kill -9"や"killproc"によるプロセス停止も出来ない
• サーバ自体の再起動は普通に出来る

ただし、確実な再現性があるのではなく、
発生する時としない時があったので問題箇所を特定するのに時間がかかってしまった。

………

結論から書くと、netfilter/iptablesのプロセスが起動している時に、
"iptables -A"とか"iptables -I"で大量のポリシー追加を一気に行うと発生する確率が高いという、
漠然とした事だった。

先の自作スクリプトでは、一度起動したプロセスにスクリプトでポリシー追加・削除を行っていた。
丁度問題のあった日は、前日にFWポリシー基礎ルールを改良した後であり、
問題が判った日に12,000行のポリシー変更が走り今回の問題が露見した。

色々と調査した所、ハングアップが発生しないディストリとiptablesバージョンがあったり、
そもそも逐次追加ではなく、プロセス起動時から30,000行読ませればハングアップしない事から、
今回の問題はバグというよりも、デフォルト設定がどこか違う為に起こったのかも知れない。

ちなみに、ハングアップの再現性が高い事を確認出来た環境は、
"openSUSE Leap 42.1/iptables v1.4.21"の組み合わせで、CentOS7・Debian8とかでも稀に発生した。
この辺りは100%の再現性が確認出来なかった事もあり、
一概に『openSUSEが悪い!!』という事では無さそうという事までしか判らなかった。

………

今回の問題は完全な再現性が無いので、netfilterにbugzilla報告出来ないし、
そもそも自作スクリプトも微妙な設計であった結果のハングアップなので、
スクリプトを改修する方針でお茶を濁し、
大幅なポリシー変更が発生したらプロセス再起動によるポリシーファイル再読込で対処する事にした。

外部ポリシーファイルはディストリ毎に微妙に違っており、

• CentOSは、"/etc/sysconfig/iptables"
• openSUSEは、"/etc/sysconfig/SuSEfirewall2"

の様になっている。
openSUSE版の変更内容は、技術wikiにメモしたのでそちらをご確認くださいな。

そもそも、iptablesに数万ポリシーも突っ込むのが色々とマズイ気がするが、
今回の問題以外は特に大きな事が起きていないので経過観察を継続しようと思う。

---