Kali Linux in Action: OS としての Kali Linux

はじめに

Kali Linux のインストールやデスクトップ環境のカスタマイズを済ませてパッケージを導入したら、それらのパッケージを使う際に基本的な動作環境となる OS そのものを、用途に応じて調整（configure：普通、configuration は「用途に応じて」調整することなので、「用途に応じた調整」というのは重複表現ですが）しておくべきでしょう。そこで、本稿では OS としての Kali Linux について解説し、Kali Linux の基本的な調整項目をご紹介します。

なお、本稿では他のページと参照文献の専用ページを共有しています。典拠表記の参照先は別のページなので、ご了承ください。

冒頭に戻る

Kali Linux について

Kali Linux の OS としての詳しい解説は、その歴史も含めて別に起稿する予定ですが、差し当たって Kali Linux をインストールしたときに知っておいた方がよいことだけを取り上げておきます。まず、Kali Linux は Linux のディストリビューションです。ということは、Kali Linux は GNU/Linux の他の多くのディストリビューション、CentOS や SUSE Linux や Ubuntu などと共通する特徴を備えているということです。これは長所にもなりますし、短所にもなるわけですが、情報セキュリティ監査やペネトレーション・テストのように特定の目的で使う OS という着眼点に絞って言えば、長所の方が確実に多いという信用があって世界中に普及していると言えるでしょう。Kali Linux は、そうした Linux ディストリビューションの中で Debian というディストリビューションの「開発版（Debian Testing）」を元に開発されている OS です。Kali Linux は Debian のソースコードを利用して開発されているため、Debian で使うために公開されているソフトウェア（パッケージ）のリポジトリも、Kali Linux の多くのパッケージで利用しています。ただし、Debian に大きく依存してはいても、Linux のディストリビューションには OS の利用者が自分自身の目的に応じて OS（つまりは OS のソースコード）へあらゆる変更を加える自由があるという点で、Kali Linux は Debian から独立しているとも言えます [Hertzog, O’Gorman, and Aharoni, 2017: 4]。

Kali Linux は、ディストリビューションの設計方針として、できる限り Debian Policy に準拠していますが、情報セキュリティ監査やペネトレーション・テストのような特定の用途でセキュリティの実務家が使うという事情を考慮して、幾つかの点で特別な設計方針を採用しています。もちろん、それらの設計方針は「ディフォールト」（無作為ならそのままということ）であって、後から幾らでも再調整できます。

スーパーユーザ（root）だけで使うシングル・ユーザでの運用を想定している

大多数の Linux ディストリビューションでは、そのコンピュータ（あるいは OS）を扱う標準的なユーザとして、スーパーユーザよりも権限の弱いアカウントを作成し、マルチ・ユーザで運用するものと想定されています。そして、管理者権限が必要な場合には、sudo などを使うわけです。破壊的なコマンドを不用意に実行してしまわないためには、こうするのがセキュリティの観点からは望ましいと言えます。ですが、Kali Linux で使う多くのソフトウェアはスーパーユーザの root 権限を必要としているため、Kali Linux では root をディフォールトのユーザとしています。Kali Linux をインストールする際にも、root のパスワードは設定しなくてはなりませんが、他のユーザを追加するような画面は出てきません。したがって、特に Linux の初心者は自分が常に root 権限で Kali Linux を運用しているという自覚が必要となります。でなければ、何かの弾みで rm -Rf / を実行してしまうとか rtpflood コマンドを自治体や大企業のサイトへ向けて実行するなどという致命的なミスをやらかして悲惨な結果を惹き起こすことになるかもしれません。

ネットワーク・サービスを無効にしている

Debian とは違って、Kali Linux では、インストールされたサービスのうちで HTTP や SSH のようなネットワーク通信のインターフェイスを提供するために外部からのアクセスを「待機する（listen）」ようなサービス（apache2, mysql, ssh, rsync, snmpd 等）は、ディフォールトでは無効にしてあります。これは、ペネトレーション・テストを実施している際にこちらの情報を可能な限り接続先へ与えないようにして、ネットワーク通信を介したやりとりでリスクを見つけたり、あなたがテストしていることを知られないようにするためのポリシーです。もちろん、後からでも systemctl コマンドであらゆるサービスを起動したり停止させられます。

アプリケーションのコレクション

Debian は汎用の OS として提供されているため、パッケージとしてどのようなものが開発されているかに頓着しません（誰かが Debian のパッケージとしてゲームを開発していようと、あるいは金融取引システム・・・どちらも似たようなものですが、そうしたものを開発していようと Debian の OS 開発者は気にしません）。これに対して、Kali Linux は特にペネトレーション・テストの実務家が使う OS として設計されているので、Kali Linux の開発元は、情報セキュリティのプロが使うものと想定できるフリーのソフトウェアだけを選び、専用のパッケージとして提供しています（なぜなら、Kali Linux の開発者は、同時にプロのペネトレーション・テストの技術者でもあるからです）。

冒頭に戻る

Kali Linux の調整

では、Kali Linux をインストールした直後の状態を想定して、OS としての設定を調整してみましょう。Kali Linux を運用するに当たって最初に注意するべき点だけを、公式ガイドブックである Kali Linux Revealed: Mastering the Penetration Testing Distribution (2017) から拾い上げておきます。なお、僕は Kali Linux の Light 版を使っているため、グラフィカルな Gnome のツールを使った調整方法はご紹介しません。殆どがコマンドラインでの手順となりますが、このやり方は Kali Linux の色々なバージョンを区別することなく汎用的に使えるという利点があります（そもそも Linux を使っていてコマンドラインでの設定が面倒とか分からないなどという人はいないでしょうし、情報セキュリティ監査や負荷テストなどで使うツールの大半は X Window System など使いませんから、Xfce すら不要と言えば不要です）。

冒頭に戻る

ネットワーク

Kali Linux をインストールするときに、ネットワークの設定を済ませているとします。その後でネットワークの設定を改めて調整したい場合は、ifup, ifdown, systemctl といったコマンドを使います。

ifup と ifdown は、“ifupdown” というパッケージでまとめてインストールされます。それぞれのコマンドが表しているように、ifup は指定したネットワーク・インターフェイスをアップして、ifdown は逆にダウンさせます。それぞれのコマンドで指定するネットワーク・インターフェイスは、/etc/network/interfaces ファイルに、以下のように記述されているでしょう。

ネットワーク・インターフェイス名を調べるだけなら、他にも ifconfig コマンドの実行で以下のように表示されるでしょう。（但し、Kali Linux の Light 版では “net-tools” というパッケージをインストールしなければ ifconfig は使えません。）

そして、Kali Linux では ifupdown の他にも systemd-networkd というネットワーク接続用のデーモンを利用できます。始めて使うときは、systemctl コマンドで以下のように準備してデーモンを立ち上げます。

systemd-networkd を立ち上げたら、/etc/systemd/network ディレクトリにネットワーク・インターフェイスの設定ファイルを “.network” という拡張子付きで作成します。設定ファイルの記入方法は、man ページの systemd.networkd(5) 等を参照してください。本稿では、ひとまず ifupdown とは違う方法もあるのでご紹介しましたが、実は systemd.networkd の導入については論争があり、Microsoft Windows のサービス・プログラムである svchost.exe と同じくらい肥大化しているとして、わざわざ systemd をインストールしない Debian のフォークが登場するほど否定する人もいます。そういうわけで Kali Linux ではディフォールトで有効になっておらず、また ifupdown を使っていても問題はないようなので、本稿では systemd-networkd を積極的には取り上げません。なお、systemd-networkd を有効にしてあれこれと設定ファイルを作成したり編集しているうちは、ネットワークが切断されてしまうと思います（余分の設定をしなくてはならない Wi-Fi で通信する場合はなおさらです）。そのような事態になってネットに繋がらなくなった場合は、(1) もちろん systemctl stop systemd-networkd でデーモンを停止して、(2) /etc/resolv.conf のリンクを削除して、(3) /etc/systemd/network ディレクトリに作成した設定ファイルを他の場所へ退避するか削除してからコンピュータを再起動しましょう。

冒頭に戻る

UNIX ユーザと UNIX グループの管理

UNIX ユーザと UNIX グループを作成したり削除したり、あるいはそれらの管理ファイルを開いて編集するといったことは、本稿では解説しません（そんなことすら知らない人が Kali Linux を使う必要などありません）。adduser、passwd のようなコマンドについても、Kali Linux を使おうという技術者が知らないなどということは想定しません。もし、Linux/UNIX で頻繁に使われるコマンドを殆ど知らない方は、最低でも LPIC-1 (101, 102) くらいの勉強をしてから特殊な用途のディストリビューションを使ったり情報セキュリティの技術に取り組むべきであり、順番が全く間違っています。

冒頭に戻る

サービスの調整

Linux のサービス（「デーモン」とも言います）を管理するツールは systemctl や service（“Jessie” というコードネームの Debian version 8 まで使われていたコマンド）があります。Kali Linux を運用し始めるにあたって注意したいのは、既に書いていることですが、Kali Linux ではネットワーク通信を受ける（Listen する）ようなサービスをディフォールトでは無効にしているので、たとえば ssh サーバや httpd サーバは個々に起動したりサービスの run level を変更しなくてはなりません。現在（と直前）の run level は runlevel で確かめられます。chkconfig などの使い方も、Kali Linux を使う人に説明する必要はないでしょう。なお、service では「サービス型」のプロセスしか扱えないので、現在は「ユニット」として構成されている全てのプロセスを運用するには、systemctl を使う方がよいでしょう（もちろん、systemd という init システムの是非について議論があるのは知っていますが）。

冒頭に戻る

セキュリティポリシーをつくる

OS としての Kali Linux を導入するに当たり、もちろん自分が使っている OS そのものを適正に運用できなければ、情報セキュリティ監査もヘチマもありません。そのていどの見識では、子供がツールを使って上場企業のサーバにコマンドを打ち込むのと同じだからです。自分が使うツールの安全で安定した運用方針をもっていてこそ、安全で安定してはいないかもしれない相手のセキュリティを監査できると言えるでしょう。そういう基本的なレベルの非対称性（つまり監査したり試験する側の方が、監査や試験を受ける側よりも安全で安定しているということ）がない限り、プロのセキュリティ技術者として他人のセキュリティ・ポリシーをどうこう判定しうる資格などないはずです。そこで、次のような着眼点でセキュリティ・ポリシーを検討してみましょう。

• 何を保護したいのか。
• 何から保護したいのか。
• 誰から保護したいのか。

まず、保護するべきなのはデータなのか、それともコンピュータというハードウェアを制御する権限なのかといった、保護するべき対象を特定しなければなりません。そして、ディスクの物理的な故障といったインシデントからデータを保護するのか、あるいは新しく導入したソフトウェアの脆弱性による侵入からコンピュータを守りたいのかを決めます。また、侵入からコンピュータやデータを守るとは言っても、子供がツールを使って無作為にアクセスしてくるのと、プロの攻撃者があなたを特別に狙ってくるのとではわけが違うという点も考慮するべきでしょう。そして、[Hertzog, O’Gorman, and Aharoni, 2017: 150] でもブルース・シュナイアの言葉を引いて小さなコラムに書かれているとおり、情報セキュリティというものは一つのポリシーを立てて終わるものではなく、技術としてもポリシーとしても常にアップデートするべきものだという理解が必要でしょう。

ということで、ここでは僕が Kali Linux を運用する環境という前提でポリシーを立ててみます。すると、先のページでご紹介したように、僕は単独で（つまり当社の人間で僕以外には誰も使わない・・・「使えない」と言う方が正確だというのが、自称 IT 企業としてお恥ずかしい限りですが）運用しているラップトップ・コンピュータに Kali Linux をインストールしています。したがって、プロダクション用途のウェブサーバとはぜんぜん運用条件が違っており、リモートのサーバへアクセスして情報セキュリティ監査するというだけの運用目的で Kali Linux が動作するラップトップ・コンピュータを使うのであれば、httpd, ssh, ftp といった多くのサービスは起動したり有効にしなくてもよいでしょう（寧ろソフトウェアとしてバイナリファイルがコマンド一つで起動しうる状況にあること自体がリスキーだとも言えるので、アンインストールしてもいいくらいです）。しかし逆に、ラップトップ・コンピュータでの運用は、データセンターで格納されているウェブサーバには無い、別のリスクがあるかもしれません。たとえば会社から自宅に持ち帰って作業したり、会社からクライアントへ持ち込んでプレゼンテーションするような場合、ラップトップ・コンピュータを持ち運ぶ移送中のトラブルを考慮しなくてはなりません。駅のトイレに置き忘れたり、空港で置き引きに遭ったり、あるいは自社ビルの階段の途中で専用ケースのバンドが切れたり外れてパソコンを何十段も下まで転げ落としてしまうかもしれません。もし、そのラップトップ・コンピュータでクライアント企業のクローズドなサイトの監査をしていた場合は、紛失したり盗難に遭ってアクセス情報が漏洩しないよう、ディスク全体を暗号化した状態で Kali Linux をインストールした方がよいでしょう。また、Kali Linux を暗号化されたファイルシステムへインストールする場合に、nuke という特別なパスフレーズを設定できます。nuke パスフレーズは、暗号化されたディスクへアクセスするための鍵を全て削除してしまう罠であり、ラップトップ・パソコンを拾ったり盗んだ人が適当に “1234” とか “asdfghjkl” などと入力すれば、それがあらかじめ設定しておいた nuke パスフレーズに合致すると、誰もデータにアクセスできなくなるという「自爆装置」になっています。僕のラップトップ・コンピュータの事例では、さしあたりラップトップ・コンピュータの BIOS が提供している BIOS パスワードと HDD パスワードを二重に設定していること、そして Kali Linux でクライアントのサーバへアクセスするような正式の業務に使ってはいないことという二つの理由で、nuke パスフレーズを設定するほどの厳格な運用は必要ないと判断しています。

次にネットワーク・サービスについては、いま起動しているサービスは service --status-all や systemctl list-units で確認できるとおり、apache2, mysql, openvpn, rsync, snmpd, ssh といったサービスはディフォールトでは起動していません。そして、これらを起動して外部からのアクセスを listen させるのであれば、Kali Linux ではファイアーウォールを起動していないため、Netfilter を使わなくてはなりません。具体的には iptables、ip6tables コマンドを使ってルールを登録してゆくわけですが、具体的には LPIC-3（303）レベルの知識はあった方がよいでしょう。

また、[Hertzog, O’Gorman, and Aharoni, 2017] のようなガイドブックではログ監視についても解説されていますが、これも Kali Linux を使うコンピュータに外部からのアクセスがあるとか、何かのレスポンスとして（通常の syslog で管理しているログとは別の）ログを取るような運用では、特別のポリシーを立てて対処する必要があると思います。しかし、さしあたって個人がペネトレーション・テストのツールを自分のサイトに向かって試したり、ローカル環境でのパスワード・クラックを行う程度の用途であれば、特別なポリシーは不要でしょう。

冒頭に戻る