不遇のセキュリティ機能たち
RedHat Enterprise Linux や CentOS では標準で有効でありながらも、様々なサイトで最初に無効化するような指南を受けることの多い不遇のセキュリティ機能たち。
本記事は彼らの有用性の認知度と地位の向上を目指します。
SELinux と firewalld の違いの比較
以下に比較表を示します。
| SELinux | firewalld | |
| 目的 | プロセスを乗っ取られた後の 防御策 | リモートからの攻撃そのものに 対する防御策 |
| 防御方式 | ルールベース | ルールベース |
| ルールを決める人 | SELinux開発者やDistributor等 ※各サーバの管理者も追加は可能 だが削除はできない | 各サーバの管理者 |
| ルール行数 | 20万行以上 | 通常は数行～数十行 |
| 防御方法 | 乗っ取られたプロセスがカーネル を使う際に、ルールに従って アクセス制御する (ファイルシステムへのアクセス やネットワークデバイスの利用 など) | パケットがNWインタフェースから プロセスへ向かう途中で、ルール に従ってパケットをドロップする |
どちらもルールベースでありながら、目的や防御方法はまったく異なります。ルールの行数はけた違いです。
firewalld はサーバ管理者が設定することが前提ですが、SELinux はあらかじめ設定されたルールを使うことが前提です。
firewalld の使いどころ
firewalld はパケットの受信ルールを IP や TCP/UDP ポート番号に基づいて決めるものです。
firewalld はプロセスに到達する前にパケットをドロップするので、プロセスでアクセス制御するよりもセキュアです。
例えば httpd へのアクセス制御は httpd.conf でも可能ですが、パケットは httpd プロセスが受信し、httpd プロセスが処理することになります。もし httpd にバグがあると悪意あるパケットを受信するだけで問題が発生する可能性があります。
このようなケースでは firewalld が有効です。
なお、実現できることはネットワーク機器としてのファイアウォールと同じなので、サーバの手前にファイアウォールや UTM があれば無効でも問題は無いのですが、例えば、裏セグメント等の同一セグメント内での通信を拒否したい、という場合はやはり firewalld により制御します。
また、運用中の制御 (設定変更) も効果的です。プロセスの動作を確認したいけど全体には公開したくない、というケースでは送信元 IP の範囲を検証端末の範囲に限定し、検証が完了したら公開する、といった細かい制御を速やかに設定することができます。
いざというときに使えるよう、常にコマンドを打つ備えはしておきたいところです。コマンドのオプション一覧は以下をご参照下さい。
SELinux の使いどころ
SELinux はある種、宗教です。信じる者は救われます。
例えばインターネット公開している ftpd や httpd 等のサーバプロセスが脆弱性により乗っ取られ、root に昇格されたとしても、動きを MAC (強制アクセス制御) のルールによって制限することができます。
これは例えば『httpd は /var/www 配下のファイルしか触れない』といった『このプロセスはこうあるべき』というルールを SELinux 開発者 (正確には SELinux ルールを運用管理する管理者) や RedHat のディストリビューターが定義し、セットアップしているからです。
しかし前述の通り、20万行にも及ぶ大量の細かいルールが最初から設定されているわけですから、それを1つ1つ理解するなどは現実的ではありません。
RedHat でも SELinux のルール漏れを『バグ』として扱っているくらいです。まずはありのままを受け入れるしかありません。
なぜ root に昇格されても制限できるか、等の SELinux の仕組みの詳細については以下をご参照下さい。
SELinux のメリットは、標準的な Linux サービスについては SELinux はデフォルト設定でも十分に効果があることです。
SELinux のデメリットは、アプリ開発中では初期チューニングが大変だったり、運用中でルール漏れが顕在化し、サービスが動作しなくなる、といったところです。
個人的なお勧めはインターネットからのアクセスを許可している公開サーバのみに SELinux を有効化することです。
プロセス奪取の脆弱性を突く攻撃は、ほぼ 100% インターネットからされます。(内部からだったらバレやすいし、バレないようにするならもっといい方法を使うはず。)そういう意味では、DMZ 等の公開サーバへの有効化はとても効果的です。
なお、チューニングやルール漏れの対処はルール追加で対処可能ですし、慣れればそれほど難しくありません。運用ルール化も手順化も可能ですし、その場合は発覚から 10 分も掛からず対処できます。
SELinux のトラブルシューティング方法の詳細は以下の記事をご参照下さい。
また、SELinux のルール追加方法は以下の記事をご参照下さい。
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント