2014/11/22

5.ログの改ざん防止

chattrで侵入者の証拠隠滅を防止する

　コンピュータが不正アクセスを受けた場合、コンピュータの中には攻撃者によって残された様々な痕跡が存在します。
侵入された証拠を記録しているこれらのログは、必ず守る必要があります。
正確で信用できるログが残っていなければ、攻撃者の侵入経路やその手法を解析することができません。

攻撃者が残した痕跡の数々はインシデントの分析を行ううえで非常に重要な情報です。
しかし攻撃者よってroot権限まで奪われてしまった場合に、それらの痕跡が消されることを防ぐことはできるでしょうか？

　多くのOSでは、ファイルの属性に作成日や更新日が保存されます。
またLinuxとBSD系OSでは、ファイルとディレクトリに拡張属性を割り当てることが可能です。
拡張属性は、すべてのユーザーに適用される点やパーミッションやアクセスコントロール[Hack #4]に優先するという点において従来のUnixのパーミッション管理と異なります。
Linuxではファイルの属性を確認するlsattrコマンドや、変更するchattrコマンドが用意されています。
BSD系のOSでは属性の確認にls -loを、変更にはchflagsを使います。

　ログファイルの保護に便利な属性として「追加のみ許可」があります。
この属性が設定されているファイルにはデータを追加できるだけで、削除することが許されません。
Linuxで、ファイルに「追加のみ許可」属性を設定するには以下のようにコマンドを実行します。

# chattr +a filename

　またBSDでは以下のようにコマンドを実行します。

# chflags sappnd filename

　以下のコマンドを実行し、「追加のみ許可」属性を設定したファイルがどうなるかを確認してみましょう。

# touch /var/log/logfile

# echo "append-only not set" > /var/log/logfile

# chattr +a /var/log/logfile

# echo "append-only set" > /var/log/logfile

sh: /var/log/logfile: Operation not permitted 　「追加のみ許可」属性を設定したファイルの上書きは失敗しています。
この状態でも以下のようにファイルへの追記は可能です。
# echo "appending to file" >> /var/log/logfile # cat /var/log/logfile append-only not set appending to file
root権限を奪った攻撃者であれば、このファイルから痕跡を消そうとするため、 chattr -aコマンドを使用して、属性を変更しようとするかもしれません。
これを防ぐために「追加のみ許可」属性の削除を許さないよう設定することも可能です。
Linuxではカーネルの「capability」機能を使用し、BSD系のOSでは「securelevel」機能を使用します。

Linuxのcapabilityを用いると、rootアカウントの強大な権限を制限することができます。
例えばファイルに設定されている「追加のみ許可」属性の変更を禁止するには、 capabilityの設定からCAP_LINUX_IMMUTABLEを削除します。

capabilityの設定を変更するには、lcap（http://snort-wireless.org/other/lcap- 0.0.6.tar.bz2）ユーティリティを使用するとよいでしょう。
lcapのソースアーカイブを入手し、以下のようにコンパイルしてください。

# tar xvfj lcap-0.0.6.tar.bz2 && cd lcap-0.0.6 && make 　「追加のみ許可」属性の変更を禁止するには、以下の例に従ってlcapを実行します。
# ./lcap CAP_LINUX_IMMUTABLE # ./lcap CAP_SYS_RAWIO
　最初の実行例では「追加のみ許可」属性を変更するcapabilityを禁止しています。
次の実行例ではraw I/Oを使用するcapabilityを禁止しています。
この場合、ファイルシステムに直接アクセスしてファイルを変更することを防ぐと同時に CAP_LINUX_IMMUTABLEの制限を迂回できる/dev/memや/dev/kmemへのアクセスも禁止します。

　ブート時にこれらの制限を適用するには、/etc/rc.localといったスタートアップスクリプトにこれらのコマンドを記述します。
このコマンドはスタートアップスクリプトの末尾に記述するとよいでしょう。
これはスタートアップスクリプトの処理そのものが、capabilityによって影響されることを防ぐためです。
一度lcapによって禁止されたcapabilityは、システムをリブートしないかぎり元に戻すことはできません。

BSD系のOSではsecurelevelを使用して同様のことを実現します。
securelevelとは特定の機能を制限できるカーネル変数です。
securelevelを1に設定すると前に説明したLinuxの2つのcapabilityを設定した状態と同じ効果が得られます。
いったんsecurelevelに0以上を設定すると、通常のリブートではsecurelevelを下げることができません。

securelevelのデフォルト値はBSD系OSの種類によって異なり、マルチユーザーモードのOpenBSDは1で、FreeBSDは-1が設定されています†。
　セキュリティレベルを変更するには、/etc/sysctl.confに次の行を追加します††。
kern.securelevel=1 　ログファイルに「追加のみ許可」属性を設定するとログローテーションスクリプトが失敗してしまいますが、これによってログの完全性を飛躍的に高め、インシデントの際に貴重な情報をもたらします。

2014/11/19

3.書込みパーミッション設定が甘いディレクトリの捜索

パーミッション設定が甘いディレクトリを簡単に発見する

ディレクトリの書き込み権限を適切に設定することは、セキュリティを確保するうえで非常に重要です。各ユーザーのumaskが適切に設定されていない場合、気づかないうちに低いセキュリティのファイルやディレクトリを作成してしまいます。これを防止するために、普段からパーミッションの甘いディレクトリがないか検査するようにしましょう。その方法は、「SUIDおよびSGIDプログラムの調査」[Hack #2]で紹介した方法と同様に、findコマンドを利用して行います。

# find / -type d $ -perm -g+w -o -perm -o+w $ -exec ls -lad {} \;

　このコマンドを実行すると他のユーザーやグループに書き込み権限を与えているディレクトリがリストアップされます。これらのディレクトリにはstickyビットを設定すべきです。stickyビットが設定されていると、ls -lコマンドの出力のファイル属性にtの文字が表示されます。stickyビットが設定されたディレクトリ内のファイルについては、そのディレクトリの所有者、ファイルの所有者、rootにのみ書き込みや変更の権限が与えられます。　また、stickyビットが設定されてないディレクトリは、以下のコマンドを実行することで探し出します。

# find / -type d $ -perm -g+w -o -perm -o+w $ \ -not -perm -a+t -exec ls -lad {} \;

　ユーザー名と同名のクループ名のグループに属している（例えば、andrewというユーザーがandrewというグループに属している）場合にはセキュリティ上の問題にはなりませんので、グループのユーザーに書き込み権限を与えたディレクトリを探す必要はありません（さもないと、実行結果にセキュリティ上問題のないディレクトリが混ざってしまいます）。その場合はコマンドの-perm -g+wを削除して実行しましょう。

2014/11/12

21.システムアップデートの自動化

迅速なセキュリティパッチ適用により侵入を防止する

　セキュリティホールを悪用した攻撃からシステムを守るためには、ソフトウェアのアップデートやパッチ適用をこまめに実施してシステムを最新の状態に保つことが重要です。あいにく、パフォーマンスチューニングやハードウェアメンテナンス、あるいはソフトウェアのデバッグのような「より緊急の」作業が優先されるため、システムのアップデートやパッチ適用といった作業は後回しにされがちです。パッチを適用することで、システムの基本機能が向上するわけではありません。時間と費用の無駄とみなされ、低コストで最大のパフォーマンスを求める経営者の下では、システムのアップデートはたいてい作業リストの最下層に追いやられてしまいます。　スクリプトなどを使った自動化をしていないのであれば、手作業によるアップデートは非常に時間のかかる繰り返し作業です。ありがたいことに、たいていのLinuxディストリビューションはアップデートのためのパッケージをネットワークからダウンロードできます。アップデートを自動化するにはパッケージの有無や変更をモニターし、自動的に判定してダウンロードしてアップデートするツールを作成すればよいでしょう。そのようなツールにAutoRPM（http://www.autorpm.org/）があります。このツールを利用するとパッケージの配布サイトをチェックして、新しいパッケージをダウンロードする作業を自動化できます。 AutoRPMは複数のFTPサイトをチェックして新しいパッケージを探すことができる Perlスクリプトです。AutoRPMには、新しいパッケージあるいは変更されたパッケージを自動的にダウンロードして管理者に通知したり、自動的にインストールしたりする機能があります。さらに、1つのFTPサイトだけを利用できるのではなく、そのFTP サイトが利用できない時に代わりになるミラーサイトを複数登録することもできます。 AutoRPMは混んでいるFTPサイトをモニターし、これまで何度そのサイトと通信を試みたか記憶します。これにより、登録されているFTPサイトをスコアリングし、スコアが最も高いFTPサイトからチェックしていきます。 AutoRPMを使うためには、最新のパッケージをダウンロードして次のコマンドによりインストールします。

# rpm -ivh autorpm-3.3.3-1.noarch.rpm

　ソースコードからインストールすることも可能です。ただし、Makefileは用意されておらず、自分の手でファイルをコピーするしか手はありません。とても面倒なのでRPM パッケージの使用をお勧めします。 AutoRPMのデフォルト設定はRed Hat Linux用ですが、以下のようにAutoRPMの設定ファイル/etc/autorpm.d/autorpm.confを変更することでFedoraや他のRPMベースのディストリビューションでも利用することができます。

###################### BEGIN Red Hat Linux ############################## # This automatically determines the version of Red Hat Linux # You have... you can comment this out and define it yourself # if you want to Eval_Var("RHVersion", "sed 's/$Red Hat Linux $\?release $[^ ]*$ (.*)/\2/' /etc/redhat-release"); #Set_Var("RHVersion", "9.0"); # Look for official Red Hat updates # (won't automatically install anything unless you edit the file) Config_File("/etc/autorpm.d/redhat-updates.conf"); ######################## END Red Hat Linux ##############################

　まずEval_var、Set_var、Config_Fileの行をコメントアウトします。そして続くセクションのEval_val、Config_File行を以下のように変更します。

###################### BEGIN Fedora Linux ############################### # This automatically determines your version of Fedora Linux Eval_Var("FedoraVersion", "rpm -q fedora-release | awk -F'-' {'print $3'}"); # Look for official Fedora updates # (won't automatically install anything unless you edit the file) Config_File("/etc/autorpm.d/fedora-updates.conf"); ######################## END Fedora Linux ###############################

　変更が終了したなら、crontabで/etc/autorpm.d/autorpm.cronスクリプトが定期的に実行されるよう登録します。これにより、定期的にアップデートパッケージを自動的にダウンロードします†。 AutoRPMではなく、yumを使って自動的にアップデートを行う方法もあります。デフォルトでyumはアップデートのダウンロードとインストールを行いますが、 downloadonlyプラグイン（http://linux.duke.edu/projects/yum/download/yum-utils/）をインストールすることで、yumがインストールステップをスキップできるようになります。　これで以下のコマンドを実行することにより、すべてのアップデートパッケージをダウンロードすることができます。

# yum --downloadonly -y update

このコマンドをcrontabに登録することで、定期的にアップデートパッケージのダウンロードが自動で実行されます。そしてダウンロードしたアップデートパッケージを確認して、yum updateコマンドを実行することで、それらをインストールできます。 Debianベースのシステムであれば、apt-get -d -y upgradeコマンドを実行することで、似たような結果を得ることができます。このコマンドはすでにインストールしてあるパッケージのアップデートパッケージをダウンロードします。そしてapt-get upgradeを実行することでそれらのアップデートパッケージをインストールできます。　これまで見てきたように、システムを最新の状態に保つための方法はいくつか存在します。オペレーティングシステムを最新の状態に保つことは、それらが抱えるセキュリティ上の問題を修正するためにも大切な作業です。セキュリティホールを抱えたままのシステムは、攻撃者にとって格好の餌食となります。

2.SUIDおよびSGIDプログラムの調査

root権限で動作するプログラムやバックドアを素早く発見する

システム内で悪意を持ったユーザーがroot権限を獲得する方法の1つとして、脆弱性のあるSUID、SGIDの与えられたプログラムに対する攻撃があります。例えばSUID、 SGIDの与えられたプログラムとしてpasswdコマンドがあります。一般ユーザーがパスワードを変更するためには、rootによって所有されるパスワードファイルを変更する必要があるため、passwdコマンドをroot権限で実行させる必要があります。そのため passwdプログラムには、ファイルの所有者の権限で動作させるためのSUIDビットが設定されています。同様にSGIDビットが設定されている場合は、そのファイルのグループ権限で動作します。 ls -lを実行することで以下のようにSUIDビットが設定されているかどうかを確認することができます。

-r-s--x--x 1 root root 16336 Feb 13 2003 /usr/bin/passwd

　所有者の実行ビット（x）の代わりに、stickyビット（s）が設定されていることに注意してください。これはSUIDビットが設定されているファイルであることを意味しています。　困ったことに不完全にコーディングされたSUIDあるいはSGIDビットを持つプログラムの存在は、ユーザーに対してより高い権限を得るチャンスを与えてしまいます。また、すでにroot権限を入手した攻撃者がバックドアとしてSUIDビットを与えた実行ファイルを紛れ込ませる可能性があります。これらを発見するために、システム上の SUIDやSGIDビットを持ったファイルを調査する必要があります。これは以下のように簡単に実行することができます。

# find / $ -perm -4000 -o -perm -2000 $ -type f -exec ls -la {} \;

　ただし実際のところ、SUIDビットの脅威はシェルスクリプトである場合が多く、それらを利用したバックドアは何気ないファイルを装っているでしょう。またほとんどのOS はシェルスクリプトに設定されたSUIDやSGIDビットを無視します。　もしもシステム上のSUIDやSGIDビットが設定されたスクリプトを発見するのであれば、以下のように-execオプションを変更し、ELF（実行型バイナリ）ファイルを除外するためコマンドを、パイプ（|）と共に追加します。

# find / $ -perm -4000 -o -perm -2000 $ -type f -exec file {} \; | grep -v ELF

　また上記の例とは逆に実行型バイナリを表示させるなら以下のようにコマンドを実行します。

# find / $ -perm -4000 -o -perm -2000 $ -type f -exec file {} \; | grep ELF

　ほとんどのOSはELF形式の実行ファイルですが、そうでない場合はgrepコマンドのELFオプションの部分を、稼動中のOSやアーキテクチャで使われているバイナリフォーマットに応じて書き換えます。例えば、古いバージョンのLinuxはa.out、AIXは XCOFFを使用しています。 findコマンドでSUIDやSGIDビットが設定されたファイルを見つけたなら、続けて fileコマンドを使用して詳細に検査するとよいでしょう。Mac OS Xのバイナリに対してfileコマンドを実行した結果を以下に示します。

$ file /bin/sh

/bin/sh: Mach-O executable ppc

cronコマンドを使用すれば1日に1回コマンドを実行させて、結果をファイルに出力させることも可能です。例えば、次のcrontabのエントリはSUIDやSGIDビットが設定されたファイルを探し、1日前のリストと比較して相違点があれば、/var/log/sidlogファイルに記録します。　また、以下のように実行すると、/var/log/sidlogにSUIDとSGIDファイルのリストを出力します。

0 4 * * * find / $ -perm -4000 -o -perm -2000 $ -type f > \ /var/log/sidlog.new && diff /var/log/sidlog.new /var/log/sidlog && \ mv /var/log/sidlog.new /var/log/sidlog

2014/11/11

1.セキュアなマウントポイントの設定について

マウントオプションを適切に設定して攻撃による被害拡大を防ぐ

　ファイルシステムは、Unixシステムを利用するための基本的な要素です。したがって、もしも攻撃者によってコンピュータに侵入されてしまった際に、重要なファイルにアクセスされることを防ぐために、ファイルのパーミッションは適切に制限されていることが望ましいといえます。そのためにはファイルアクセスを制限できるマウントオプションを用いるとよいでしょう。　「マウントオプション」はファイルシステムへのアクセス方法を制御するためのオプションです。マウントオプションはファイルシステムがマウントされる際に、OSカーネルに引き渡されます。例えば、nodevオプションを指定すると、デバイスノード（デバイスファイル）を無効にできます。また、noexecオプションでプログラムの実行を禁止でき、nosuidオプションでSUIDビットを無効にすることができます。roオプションを指定すると、ファイルシステムを読み出し専用でマウントすることもできます。　これらのマウントオプションは、mountコマンドの-oオプションに指定します。例えば、プライマリIDEハードディスクの3番目のパーティションをnodev、noexec、 nosuidの各マウントオプションを指定して、/tmpにマウントするには、次のコマンドを実行します。

# mount -o nodev,noexec,nosuid /dev/hda3 /tmp

これを/etc/fstabで設定するには、次のように記述します。 /dev/hda3 /tmp ext3 defaults,nodev,noexec,nosuid 1 2 　使用目的を慎重に考慮して目的別にパーティションを分割し、それぞれのパーティションに適切なマウントオプションを設定します。これにより攻撃者がコンピュータに侵入した後の活動を困難にすることができます。機能別にパーティションを分割するには、システムがディレクトリへの書き込みが必要なのか、読み込みしか必要ないのかを分類することです。通常の運用中に変更する必要のないディレクトリは、読み出し専用オプション（ro）でマウントすることを推奨します。このように読み出し専用オプションを適用できるディレクトリとして/usrが考えられます。　言うまでもなく/homeのようなディレクトリは読み出し専用としてマウントするべきではありません。しかしながら通常のUnixシステムにおいて、ユーザーがホームディレクトリ上でSUIDされたプログラムを実行したり、デバイスファイルを作成したりすることを許可する必要はありません。そこで、/homeに独立したパーティションを割り当て、 nodevオプションとnosuidオプションを設定してマウントするとよいでしょう。またユーザーのホームディレクトリに実行ファイルを置かせないのであれば、noexecマウントオプションを追加するのもよいでしょう。また、/tmpや/varディレクトリについても、これらのディレクトリ上にデバイスファイルを作成したり、実行ファイル（SUIDビットの有無を問わず）を置いたりする必要はありません。/tmpやホームディレクトリのような共有のファイルシステムをマウントオプションで制限しておけば、攻撃者によるトロイの木馬などの悪意あるプログラムの実行を防ぐことができます。

nodevオプションがchroot環境で動作しているファイルシステムに適用されていた場合、chroot()を呼び出して動作しているサービスが機能しないかもしれないことに注意してください。これはchroot環境下では、/dev/logや/dev/nullなどのデバイスファイルが必要なためです。

攻撃者が前述のようなマウントオプションによる制限を回避可能な方法も数多く存在します。例えばLinuxにおいて、noexecオプションを指定したファイルシステム上であっても、/lib/ld-linux.soを使用してファイルを実行することが可能です。ld-linux.so を実行不可能とすることで、この問題を解決できると考えるかもしれませんが、そのようにするとすべての動的リンクライブラリを用いるプログラムが実行できなくなってしまいます。現実的ではありませんが、システム上のすべてのプログラムを静的リンクすることでこの問題を解決できます。　このようにLinuxにおいてnoexecオプションはほとんど役に立たない可能性があります。結局のところroot権限を奪った攻撃者に対しては、これらのマウントオプションを与えたファイルシステムでさえも無意味で、-o remountオプションで再マウントされてしまいます。　しかしながらマウントオプションを設定しておけば、root権限を奪う前の攻撃者や悪意あるユーザーの行動を制限することが可能なのです。