2025年01月05日(日) - 16:49 | カテゴリ:
Linux
前回書いたあらすじの通り自鯖ではiptablesとfirewalldのACLを自動生成しつつ、
日々インターネットから来るセキュリティリスクに備えている。
ACL行数が6,000～45,000行と非常に多いためルールを反映する際に時間を要したり、
CPU負荷が100%に張り付いてACL適用が終了しない事象が発生していた。
2025年始に発生した別エラーに対応をするついでにこれらの処理を最適化した所、
ACL提供時間の高速化と適用時のCPU負荷減少が出来たのでメモしておこうと思う。
過去資産の都合でRHEL系・Debian系はiptables、SUSE系はfirewalldで今回は実装した。
ACLをipset方式で書き出す方法は色々あり、
従来のipsetコマンドを利用したりfirewall-cmdコマンドを使う方法と、
生テキストでルールを直接出力しても保存・適用が出来る。
スクリプト改修をするにあたりポイントとなったのは次のコマンド類だった。
| ディストリ |
RHEL系 |
Debian系 |
SUSE系 |
| ルールタイプ |
iptables |
iptables |
firewalld |
| グループ化 |
ipset |
ipset |
firewall-cmd |
| インストール |
dnf install ipset ipset-service |
apt install ipset ipset-service |
zypper install ipset firewalld |
| ACL保存 |
ipset save >
/etc/sysconfig/ipset |
netfilter-persistent save |
ipset save >
/etc/firewalld/ipsets/rules.xml |
| ACL自動復帰 |
ipset.service |
netfilter-persistent.service |
firewalld.service |
ipsetを利用する上で特に重要なのは、ルール保存とサーバ再起動時のリストア処理の二つ。
ルール保存は上記コマンドを実行してルールを書き出せば良いのだが、
再起動時のリストアは環境によって千差万別なのでテスト含めた確認が必須となる。
firewalldかつfirewall-cmdの場合は所定のディレクトリに保存したxmlを自動で読み込むが、
iptablesかつipsetコマンドで保存している時は、別途サービスを有効化して自動復帰させる必要がある。
コレを忘れるとiptablesでルールをリストアする際にエラーが発生し、
状況によっては締め出しを食らう事になるので注意が必要だった。
………
改修後のスクリプト実行は以下の通り。
各々の環境で45,000～52,000行のACLを読み込ませているが実測2秒で適用完了できた。
改修前はCPU負荷が100%に張り付き10分待っても適用が完了しなかったので中々の速度と言える。
改修版スクリプトで3日間はサーバを連続稼働させているが正常稼働しており、
自動処理も継続出来ているので大丈夫そうだった。
RHEL
# time ./script.sh
real 0m1.510s
user 0m0.784s
sys 0m0.625s
# iptables -n -L | wc -l
87
# ip6tables -n -L | wc -l
55
# ipset list | wc -l
46153
|
Debian
# time ./firewall.sh
0.96s user 0.50s system 104% cpu 1.401 total
# iptables -n -L | wc -l
60
# ip6tables -n -L | wc -l
55
# ipset list | wc -l
52664
|
SUSE
# time ./firewall.sh
1.421u 0.590s 0:17.23 11.6%
# iptables -n -L | wc -l
333
# ip6tables -n -L | wc -l
350
# ipset list | wc -l
47491
|
………
急遽発生した冬休みの自由研究ならぬ冬休みのスクリプト改修だったが、
今までに抱えていたCPU負荷課題や処理速度の問題を解決するベストの結果となった。
今回の改修によってfirewalldでのルール生成方法と自動処理の手段も確立出来たので、
ディストリビューションでスクリプトを統一する手ごたえも得られたのでヨシとしよう。
« 続きを隠す
2025年01月04日(土) - 18:54 | カテゴリ:
Linux
“ns-lab BB”はRHEL系・Debian系・SUSE系の3ディストリビューションを併用し、
基本となるOS設計は合わせつつも導入時期によって微妙に違いがあったりする。
差異があると言ってもインターネットに接続しているサーバは、
セキュリティ対策としてファイアウォールでACLを書いてパケット制御もしている。
このACL設定量がかなりの大きさとなっており、
システムによって差異はあるとしてもACLを6,000～45,000行ほど書いている。
全盛期は60,000～70,000行はあったのでコレでも最適化して登録内容を減らした方だが、
とは言っても多いのは否めない状況になっている (´・ω・｀)
話が変わり、年末年始にSUSE系のOSをアップグレードした所、
firewalldのポリシーを自動更新するスクリプトでエラーが出る様になった。
詳細を調べたら”firewall-cmd –reload”を実行した時に25秒以上の時間を要してしまい、
d-bus応答不能と判断されてプロセス間通信をぶった切ってしまう様だった。
ややこしいのが、SUSE系でのみ問題が発生してRHEL系・Debian系は発生しない所だった。
フォーラムを読むとOS毎にfirewall-cmdとd-busの細かい実装差異がある様で、
今回はSUSE系で問題を踏み抜いた形となった。
また、timeコマンドを使って処理秒数を計測したところ、
ACLを6,000行ほど読み込む段階で約26秒を要しておりコレが原因と言えそうだった。
最終的に次の設定を行い、d-busのservice_start_timeoutを60秒(60000ms)に拡張しつつ、
ACLをipsetでまとめる事にした。
………
ACL処理のipset化とd-bus拡張を同時に実行したので何方が効いたのかわからないが、
テスト段階では正常動作しており丸一日は自動制御含め処理を継続出来た。
$ cat /etc/dbus-1/system.d/system-local.conf
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<limit name="service_start_timeout">60000</limit>
</busconfig>
|
ACLを自動生成するスクリプトの改修も年始に行い日時処理が無事通るのかテストを実施中。
こちらは土日に高負荷の処理が走るので、それを無事にオールクリアしたら記事にしようと思う。
iptablesのACLをipsetでグループ化する方法はググればいくらでも出てくるので省略するが、
今回の改修で地雷ポイントも分かって来たので、こちらも時間があれば書きたい。
« 続きを隠す
2024年12月28日(土) - 22:30 | カテゴリ:
Linux
Zabbix 7.2.0が12月10日にリリースされた事に気づかず年末になってしまったので、
休みを使って自鯖のZabbixを7.2にアップグレードしてみた。
今回はLTSからのマイナーアップグレードという事もあり、目に見えて大きな変化は見当たらなかった。
主にテンプレート関係の拡充と内部処理の最適化が行われている様で、
刺さる機能が無ければスキップしても良いかもしれない。
画像は自作したダッシュボードだが、特に変化は見当たらなかった。
以前の大型アップデートではグラフが表示されなくなる事もあり、
再発を若干気にしていたものの杞憂に終わった。
筆者は利用してないが、今回からバックエンドDBとしてOracleがサポートされなくなった模様。
使うシーンは稀とは思うものの、エンタープライズ環境で利用している人は気を付けた方が良さそう。
