ネットワークセキュリティHACKS Wiki 第七章 ログの取得 - careerbeat/dit-ehime GitHub Wiki
- ログを専用のサーバに集約して、ネットワーク上に散在するコンピュータの監視を効率化する
- ネットワーク上に散在するコンピュータそれぞれがログを管理していると、コンピュータに侵入された場合にログが改ざんされる可能性がある
- 自動的に記録される必要最低限のログをシステムログという
- UNIX系OSのシステムログは「syslog」が出力する
- 実際にログを出力しているプログラム(デーモン)は「syslogd」である
HACK #5で述べた通り、コンピュータのログは改ざんされる可能性がある
HACK #5ではログファイル自体の権限を変更して変更や削除ができないようにした
ここでは、コンピュータのログを別の場所にあるログ専用のサーバに格納して、たとえコンピュータ上のログが改ざんされても改ざん前のログが残るようにする
コンピュータのログをサーバに格納するには、ネットワークでログを転送しなければならない
それを実現するために「syslogd」がリモートコンピュータからログを受信できるようにする
CentOS6ではsyslogdの変わりに「rsyslog」が標準のsyslogデーモンとして採用されている
rsyslogの「r」はreliableの頭文字で信頼性を意味する
syslogdはログを転送するためにudpポートを使用するが、rsyslogdはtcpポートを使用されており信頼性が確保されている
そこで、CentOS6の標準で信頼性のあるログ転送が行えるrsyslogdを用いたログの集中管理方法を解説する
- ログサーバのユーザー名とパスワードをほかのサーバと同じにしない(サーバーへの侵入を困難にする)
- 複数のサーバからログの転送を行う場合、ログサーバの容量を十分に確保する
- 「/etc/sysconfig/syslog」に下記を追記しましょう
SYSLOGD_OPTIONS="-m 0 -r"
- rsyslog(サーバ側)の設定を行いましょう
# vi /etc/rsyslog.conf #$ModLoad imtcp #$InputTCPServerRun 514 ↓ $ModLoad imtcp $InputTCPServerRun 514
- ポートを開放して、rsyslogを再起動しましょう iptables で UDP, TCP の514番ポートを開けておきます
# vi /etc/sysconfig/iptables -A INPUT -m state --state NEW -m udp -p udp --dport 514 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 514 -j ACCEPT # /etc/init.d/iptables restart
上記の編集が完了したらrsyslog 再起動します
# /etc/rc.d/init.d/rsyslog restart システムロガーを停止中: [ OK ] システムロガーを起動中: [ OK ]
- rsyslog(クライアント側)の設定を行いましょう
# vi /etc/rsyslog.conf # authpriv.* 認証に関するログを centos に転送する場合 authpriv.* @{受信側のIPアドレス}:514 # 72行目からのコメントを解除して有効にする $WorkDirectory /var/lib/rsyslog # where to place spool files $ActionQueueFileName fwdRule1 # unique name prefix for spool files $ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible) $ActionQueueSaveOnShutdown on # save messages to disk on shutdown $ActionQueueType LinkedList # run asynchronously $ActionResumeRetryCount -1 # infinite retries if host is down上記の編集が完了したらrsyslog 再起動します# /etc/rc.d/init.d/rsyslog restart システムロガーを停止中: [ OK ] システムロガーを起動中: [ OK ]
以上で設定は完了です
実際にログが送信されているかを以下のように確認しましょう
- 受信側
tail -f /var/log/secure
- 送信側 (今回は認証関係のログを送信しているので、sshで確認する)
ssh localhost
受信側にログが出力されない場合はIPアドレスやiptablesの設定が間違っている可能性があります
その場合はiptablesを初期化したり、そもそもログが送信されているかなどを確認して、設定を見直しましょう
ログサーバへ転送されたログは、ログサーバのsyslog.confの内容に従って処理されるので、受信側の設定を見直しましょう
- rsyslogのフィルタを利用してログの分類を行う
- デフォルトではフィルタが設定されていないため、様々なサービスが出力するが分類されていない
syslogやrsyslogのデフォルトの設定では、Sendmailやsudo、BINDなど様々なサービスのログが/var/log/messagesに混在して記録される
そのため、記録されたログの中から該当サービスのログを見つけるのは大変な作業である
そこで、syslogやrsyslogの設定を変更して、ある基準に従ってログが振り分けられるようにしていく
このHACKでは、CentOS6に標準で採用されているrsyslogにおける設定方法を解説していく
まず、rsyslogの設定は/etc/rsyslog.confで行う
- スペースまたはタブで区切られた2つのフィールド「selector」と「action」で構成されている
- selector：取得するログの指定
- action：取得したログの出力先の指定
selector action
- 「facility」と「priority」を「.」（ピリオド）で接続したもの
- 特定のactionに対して複数のselectorを指定したい場合は、「;」（セミコロン）で接続する
facility.priority{;facility.priority}
- ログの分類に当たるものである
- facilityを複数指定する場合は「,」（カンマ）で接続する
| facility | 対象のログ |
|---|---|
| auth（security） | 認証サービスのメッセージ（現在はauthprivが推奨されている） |
| authpriv | 認証サービス（カテゴリはauthと同じ。authとは出力結果が異なる） |
| cron | cronのメッセージ |
| daemon | デーモンのメッセージ |
| kern | カーネルのメッセージ |
| lpr | プリンタサービスのメッセージ |
| メールサービスのメッセージ | |
| news | ニュースサービスのメッセージ |
| syslog | syslogのメッセージ |
| user | ユーザープロセスのメッセージ |
| uucp | uucp転送を行うプログラムのメッセージ |
| local0～7 | アプリケーションに依存する |
※local0からlocal7は、特定のプログラムが所属するfacilityを既存のものと分けたいときに利用する
- プログラムが出力するメッセージのうち、ログのレベルの重要度を設定する
- 通常の設定では、指定したpriority以上のログが出力される(重要度の低いpriorityほどメッセージが多くなる)
- 指定したpriority以下のログを出力したい場合は、priorityの前に「!」をつける
- 指定したpriorityのみのログを出力したい場合は、priorityの前に「=」をつける
- priorityを「*」にすると、全てのメッセージを出力できる
| priority | 内容 |
|---|---|
| priority | 内容 |
| debug | デバッグ情報 |
| info | 情報 |
| notice | 通知 |
| warn | 警告 |
| err | 一般的なエラー |
| crit | 致命的なエラー |
| alert | 緊急に対処すべきエラー |
| emerg | システムが落ちるような状態 |
※下になるほど重要度が高くなる
- selectorで指定したログをどこに、あるいはどのように出力するかを設定する
- ファイルパスを記述すると、どのファイルに出力するかを指定できる
- 「|」(パイプ)を利用することで、ログを他のプログラムに渡すことができる
- 「@ホスト名」と記述することで、ログを他のホストに渡すことができる
- ユーザー名を記述することで、ログを指定したユーザーのコンソールに表示することができる
以上を踏まえて、実際のrsyslog.confの中身を確認してみる
*.info;mail.none;authpriv.none;cron.none /var/log/messages 1. authpriv.* /var/log/secure 2. mail.* /var/log/maillog 3. cron.* /var/log/cron 4. *.emerg * 5. uucp,news.crit /var/log/spooler 6. local7.* /var/log/boot.log 7.
- authprivとcronを除いたすべてのfacilityでinfo以上のメッセージを/var/log/messagesに出力
- authprivのfacilityはすべてのメッセージを/var/log/secureに出力
- mailのfacilityはすべてのメッセージを/var/log/maillogに出力
- cronのfacilityはすべてのメッセージを/var/log/cronに出力
- すべてのfacilityでemergのメッセージをオンラインユーザーのコンソールへ出力
- uucpとnewsのfacilityでcrit以上のメッセージを/var/log/spoolerへ出力
- local7のfacilityのすべてのメッセージを/var/log/boot.logへ出力
- 「Logwatch」を用いて大量に記録されたログの中から有用な情報だけを取り出す
- ネットワーク上にある全てのシステムとサービスのログを収集すると、記録される量が膨大になり、必要情報に辿り着くまでに手間がかかる
HACK#73のようにサービスごとにログを分類したとしても、監視対象が多ければ多いほど記録されるログの量も多くなる
その大量に記録されたログの中から、人手で必要な情報を取り出していると時間が余分にかかり、精度も低下する
また、常時監視しているログでは重要なログを見落とす可能性もある
そこで、「Logwatch」を用いてログを自動で解析して必要な情報を取り出す
- ログを解析してレポートを作成するツール
- cronを利用することにより、定期的にログ解析を実行し、その解析結果をメールで送信することができる
- Logwatchによるログ解析によって、「障害の兆候」や「原因」、「稼働状況」などを知ることができる
下記でLogwatchのインストール、利用方法を解説する
まずはLogwatchのインストールを行います。
本にはソースをダウンロードしてコンパイルをしてますが、現在はyumコマンドでインストールすることができます。
# yum install logwatch
インストールが完了するとlogwatchコマンドが使えるようになります。
# logwatch
logwatchコマンドのみを打つと画面にはなにも出力されず、メールのみが送信されます。デフォルトの設定ではrootに対して送信されるようになっています。
# mail (前略) >N 14 [email protected] Tue Mar 21 14:28 42/1508 "Logwatch for localhost.localdomain (Linux)" & 14 Message 14: From [email protected] Tue Mar 21 14:28:38 2017 Return-Path: X-Original-To: root Delivered-To: [email protected] To: [email protected] From: [email protected] Subject: Logwatch for localhost.localdomain (Linux) Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 21 Mar 2017 14:28:38 +0900 (JST) Status: R ################### Logwatch 7.3.6 (05/19/07) #################### Processing Initiated: Tue Mar 21 14:28:38 2017 Date Range Processed: yesterday ( 2017-Mar-20 ) Period is day. Detail Level of Output: 0 Type of Output: unformatted Logfiles for Host: localhost.localdomain ################################################################## --------------------- Disk Space Begin ------------------------ (以下略)
このように、メールでログのレポートが届けられます。
標準出力として画面に出力したい場合はオプションに「--print」と付けることでできます。
その他、logwatchのオプションには以下のようなものがあります。
| オプション | 説明 |
|---|---|
| 結果を画面出力する | |
| --save | 指定したファイルに出力する |
| --mailto | 指定したメールアドレスにメールが届く |
| --range | 対象期間を設定する |
| --detail | ログの詳細レベルを変更する |
| --service | 指定したサービスのログのみを表示する |
| --logfile | 指定したログファイルのみをチェックする |
また、これらのデフォルトの設定は「/usr/share/logwatch/default.conf/logwatch.conf」に記述されています。
設定内容を変更したい場合は、デフォルトのファイルを変更するのではなく、「/etc/logwatch/conf/logwatch.conf」に変更したい内容を記述することで設定できます。
ただ、一つ一つ設定項目を記述していくのが面倒な場合はデフォルトの設定を全てコピーし、その上で変更したい箇所を修正しても良いです。
| オプション | 設定例 | 説明 |
|---|---|---|
| LogDir | /var/log | ログの格納先 |
| MailTo | [email protected] | メールの送信先 |
| Detail | Med | ログの詳細レベル。0～10の整数、または「Low」「Med」「High」で指定 |
| Archives | Yes | アーカイブも参照するか |
| HostLimit | Yes | 転送されてきたログも対象に含めるか |
| Range | yesterday | いつのログファイルをチェックするか。「All」「Today」「Yesterday」から選んで設定 |
(詳しくはこちらを参照)
また、本に書かれている通り、cronで定期的に1日1回メールが送信されるようにすると日毎にログを管理できるので良いでしょう。
なおこの設定は、yumでlogwatchをインストールすると、自動的にcronに登録されて毎日logwatchが実行されるようになるので、確認しておきましょう。（設定ファイルは「/etc/cron.daily/0logwatch」）
これらの設定を適切に行って、効果的にログのレポートが見れるようにし、重要なログを見逃さないようにしましょう。
- 「Swatch」を用いてログのリアルタイム監視を実現し、イベント発生のアラートが出力されるようにする
- rsyslogなどでは、ログを解析することはできるがリアルタイムで監視してアラートを出す機能がない
サーバを無防備な状態でインターネットに接続すると、数十分もすればハッキングされてしまい、ポートスキャンや脆弱性をついた攻撃、DoS攻撃などの危険性にさらされる
それらの脅威からサーバを守るためには、ログをリアルタイムで監視して迅速に対処できるようにしておかなければならない
しかし、大量のログの中からそれらを1つ1つ分析して危険性があるかどうかを判断するとなると、人力による対策には限界がある
そこで、任意のログをリアルタイムにチェックしたり、メッセージのパターンを検知してメールを投げたりできる(アラートを出す)ツール「Swatch」でログの監視を行う
- サーバのログをリアルタイムで監視する
- 監視しているログと予め指定しておいたパターンがマッチングすると、ターミナルやメールなどでアラートを出すアクションを実行できる
Swatchの設定は、任意のファイル名(swatchrc.secureなど)で設定ファイルを作成してそこに記述する
設定ファイルは下記のような書式で記述する
下記の記述によって、「パターンにマッチした文字に対して、特定のアクションをする」という設定ができる
watchfor /パターン/
アクション1(行頭にTabを入れる)
アクション2(行頭にTabを入れる)
……
Perlの正規表現で文字列を指定する
主に下表のようなパターンがよく用いられる
| パターン | 説明 |
|---|---|
| /hoge/ | hogeにマッチする |
| /hoge/i | hogeの大文字、小文字どちらでもマッチする |
| /hoge | huga/ |
| /ho[gn]e/ | hogeまたはhoneにマッチする |
| /hoge/,/huga/ | hogeまたはhugaにマッチする（2つのパターンに分ける） |
| /h..e/ | hで始まり、間に任意の1文字が2つ入り、eで終わる場合にマッチする |
| /ho.*e/ | hoで始まり、間に任意の1文字が0回以上の繰り返し、eで終わる場合にマッチする |
パターンに一致した場合に実行される
| アクション | 説明 |
|---|---|
| echo [modes] | ターミナルにメッセージを表示 modesにより表示形式を変更可能 |
| bell [N] | beep音をN回鳴らす 数字を指定しなければ1回 |
| exec command | 指定したコマンドを実行 スペース区切りでコマンドに引数を渡すことができる コマンド内で「$0」を指定すると、表示されるログそのものを意味する 「$N」は、N番目のフィールドの文字列を意味する |
| mail [=address:address:…][,subject=your_text_here] | 指定されたアドレスにメールを送信 メールは複数指定できるほか、サブジェクトの指定が可能 アドレスを指定しなければswatchを起動したユーザーに送信 |
| pipe command[,keep_open] | パイプでコマンドに結果を渡す keep_openを指定すると異なるパイプが実行されるか、swatchが終了するまでパイプが実行されたままになる |
| write [user:user:…] | swatchを実行しているサーバにログインしているユーザーに、writeコマンドを使用して結果を送信 |
| throttle hours:minutes:seconds,[use=message|regex] | (後述するthreshold推奨)一度検出されたパターンが再度検出された場合、検出を抑えることができる 標準では「use=messges」が指定されており、同じmessagesは検出されない 「use=regex」を指定すると、同じ正規表現の場合は検出されない |
| continue | 通常は、マッチするパターンが検出されると指定されたアクションが実行されて終了するが、continueが指定されている場合はさらにマッチするパターンの検出が行われる |
| quit | マッチするパターンを検出するとswatchが終了 |
| threshold | track_by=”/hoge/”,type=limit,count=1,seconds=15といった具合に指定 track_byはマッチしする正規表現 typeはlimit,threshold,both limitはcountの回数だけログを処理>limitはcountの回数だけログを処理 これは最初のマッチからsecondsの間だけだけ有効 secondsだけ時間が過ぎたら再びリセット thresholdはcountの回数だけマッチしたら1回ログを処理 再びcountの数だけログがマッチすれば、もう一度ログを処理(例えばcount=3と指定すると、3回マッチして初めて一度だけ処理) bothはcountの回数だけマッチしたらログを1回だけ処理 thretholdと違い、有効時間内はcountの数だけマッチしてもログは処理されない |
| modes | 説明 |
|---|---|
| normal | 通常の表示 |
| bold | 太字で表示 |
| underscore | 下線で表示 |
| blink | 点滅で表示 |
| inverse | 反転して表示 |
| [color] | black、red、green、yellow、blue、magenta、cyan、whiteの色で表示 |
| [color_h] | black_、red_h、green_h、yellow_h、blue_h、magenta_h、cyan_h、white_hの色で反転 |
| random | 上記のものをランダムに使用 |
- 複数のコンピュータのログを1箇所に集約して、ログ管理を効率化する
- コンピュータを管理するためにはログが必要不可欠だが、複数台を管理する場合はログが散在していると管理しづらい
複数のコンピュータは集中管理されるべきである
なぜなら、管理下にあるコンピュータが攻撃を受けた場合、集中管理されていないとその事実に気付くのが遅れる可能性がある
また、HACK#72で述べたようにログが改ざんされて、攻撃の事実を隠される可能性もある
そこで、syslogのネットワークでログを転送する機能を活用して、複数のサーバからのログを集約する
ただし、HACK#72でも述べた通り、syslogは通信にudpを使うため信頼性が確保されずにデータを失ってしまうかもしれない
また、暗号化通信をサポートしていないため何者かに通信内容を読み取られるかもしれない
上記の理由からtcpを使用した信頼性のある通信と暗号化して情報が読み取られないようにすることをサポートしている必要がある
テキストでは、tcpによる通信と暗号化通信をサポートしたsyslog-ngが紹介されているが、CentOS6には標準で同様の機能をサポートしたrsyslogが採用されているのでそれを用いる
rsyslogによってリモートコンピュータからログを集約する上で下記の条件を満たしておく必要がある
- ログを送信するネットワーク機器とログを受信するrsyslog搭載が搭載されたOS(CetnOS6など)
- ログの送信側と受信側はネットワーク上で疎通が取れていること
- 受信側は514(UDP)のポートが開放されていること
※UDPのポートを開放するのは、全てのリモートコンピュータがsyslog-ngやrsyslogを使用しているとは限らないため
下記で詳細な設定方法を解説する
本HACKに関して内容を網羅できていないのは暗号化だけなので、暗号化部分についてのみ記載します。
- log送信先（サーバー） 192.168.1.185 (任意)
- log送信元（クライアント）192.168.1.77 (任意)
- 必要なパッケージをインストール
# yum -y install rsyslog-gnutls gnutls-utils
- CA証明書の作成、サーバ証明書の作成(既に作成している場合はそれを使いまわしても可)
- /etc/rsyslog.confの設定
# vim /etc/rsyslog.conf
以下のように設定を行う
# make gtls driver the default
$DefaultNetstreamDriver gtls ← デフォルトの受信方式をGnuTLSにする
# certificate files ← 秘密鍵・証明書を設定する
$DefaultNetstreamDriverCAFile /etc/pki/tls/rsyslog/ca.pem ← 公開鍵へのパスを指定
$DefaultNetstreamDriverCertFile /etc/pki/tls/rsyslog/cert.pem ← 証明書ファイルへのパスを指定
$DefaultNetstreamDriverKeyFile /etc/pki/tls/rsyslog/key.pem ← 秘密鍵へのパスを指定
# Provides TCP syslog reception
$ModLoad imtcp ← TCPによる通信を実現するモジュールを読み込む
$InputTCPServerStreamDriverMode 1 ← TLSによる暗号化通信を実行する
$InputTCPServerStreamDriverAuthMode anon ← anonは認証なし
$InputTCPServerRun 514 ← TCPのポートを指定して待ち受けを行う
$AllowedSender TCP, 127.0.0.1, 192.168.1.77 ← 転送を許可するクライアントを指定
-
rsyslogの再起動
-
ca.pemをlog送信元（クライアント）にコピー 例：scp /etc/pki/tls/rsyslog/ca.pem 192.168.1.77:（クライアントの鍵置場）
-
作成した公開鍵をクライアントに送る (/etc/pki/tls/rsyslogはサーバー側で作成した鍵置場、以降クライアント側でも同じパスで行う)
- 必要なパッケージをインストール
# yum -y install rsyslog rsyslog-gnutls
- 証明書権限変更
# chmod 700 /etc/pki/tls/rsyslog/
- /etc/rsyslog.confの設定
# vim /etc/rsyslog.conf
# certificate files - just CA for a client
$DefaultNetstreamDriverCAFile /etc/pki/tls/rsyslog/ca.pem ← 公開鍵を読み込む
# set up the action
$DefaultNetstreamDriver gtls ← デフォルトの受信方式をGnuTLSにする
$ActionSendStreamDriverMode 1 ← TLSによる暗号化通信を実行する
$ActionSendStreamDriverAuthMode anon ← anonは認証なし
authpriv.* @192.168.1.185:514 ← /var/log/secureに送られるログをサーバーへ転送する
- rsyslogの再起動
以上で設定は完了です。実際に暗号化されているか確認します。
sshでのログインをクライアント側で失敗した際のログが暗号化されているか確認する
# tcpdump -s0 -i eth1 -X port 514
10:02:24.329788 IP 192.168.1.77.35252 > 192.168.1.185.shell: Flags [P.], seq 85797040:85797136, ack 3977553391, win 229, options [nop,nop,TS val 2011838 ecr 3251508], length 96
0x0000: 4500 0094 43e7 4000 4006 7226 c0a8 014d E...C.@[email protected]&...M
0x0010: c0a8 01b9 89b4 0202 051d 28b0 ed14 a5ef ..........(.....
0x0020: 8018 00e5 5f21 0000 0101 080a 001e b2be ...._!..........
0x0030: 0031 9d34 3c38 363e 4d61 7220 3136 2031 .1.4<86>Mar.16.1
0x0040: 303a 3032 3a32 3520 646f 6a6f 2073 7368 0:02:25.dojo.ssh
0x0050: 645b 3334 3735 5d3a 2046 6169 6c65 6420 d[3475]:.Failed.
0x0060: 7061 7373 776f 7264 2066 6f72 2072 6f6f password.for.roo
0x0070: 7420 6672 6f6d 2031 3932 2e31 3638 2e31 t.from.192.168.1
0x0080: 2e37 3720 706f 7274 2035 3735 3834 2073 .77.port.57584.s
0x0090: 7368 320a sh2.
# tcpdump -s0 -i eth1 -X port 514
11:02:14.200443 IP 192.168.1.77.35362 > 192.168.1.185.shell: Flags [P.], seq 1932:2129, ack 1974, win 316, options [nop,nop,TS val 5601744 ecr 6864987], length 197
0x0000: 4500 00f9 b00a 4000 4006 059e c0a8 014d E.....@[email protected]
0x0010: c0a8 01b9 8a22 0202 8891 91fa bc16 9392 ....."..........
0x0020: 8018 013c 40d6 0000 0101 080a 0055 79d0 ...<@........Uy.
0x0030: 0068 c05b 1703 0200 c0bf a094 a727 b3b7 .h.[.........''..
0x0040: e469 21e5 a17a 11ce 0d56 cd7b 878a c688 .i!..z...V.{....
0x0050: c3a9 0da0 8aa8 a9e2 5949 34ac 1543 9c35 ........YI4..C.5
0x0060: ab7f 8c3d 5bb5 4a96 f779 b367 3bd8 f11f ...=[.J..y.g;...
0x0070: 2501 2a0d 4786 4ce4 6de5 5c40 bf0b 042a %.*.G.L.m.\@...*
0x0080: 53e9 9613 453d 850e b120 ddc0 affa 074d S...E=.........M
0x0090: 197b 377e de00 acf0 3374 ebf5 b42b ec94 .{7~....3t...+..
0x00a0: 9774 c56c cb71 d6ac 5bf6 51a4 e4ca 6388 .t.l.q..[.Q...c.
0x00b0: e757 06b9 350f 5e2c 430d 3f63 780b 4c48 .W..5.^,C.?cx.LH
0x00c0: c231 f6a5 ed91 656e e000 a923 58b1 dfbc .1....en...#X...
0x00d0: 82a5 f1a7 8f45 550d b0d1 c4e3 dba1 455e .....EU.......E^
0x00e0: 4d0d 9d38 568e efcf 0fe8 7447 653c 7b78 M..8V.....tGe<{x
0x00f0: 1fbd 2be5 214f c1d4 86 ..+.!O...
設定前ではログの内容が見えてしまっているが、設定後には暗号化されており盗聴することができないようになっている。
- プロセスアカウンティングによって、ユーザーの素行を監視する
- 攻撃者は部外者だけに限らず、内部犯行の可能性もある
システムに障害が発生したとき、システム自体に起因すると推測できるものであれば、システムに記録されているログを解析すれば良い
しかし、ユーザーに起因すると推測できるものであれば、ユーザーの行動を常時監視していなければ原因を追究できない
ユーザーの行動を監視するためには、「プロセスアカウンティング」を行うと良い
プロセスアカウンティングは、いつどんなコマンドを実行したのかをCPU時間やメモリの使用量などとともに詳しくログに残すものである
これにより、システムへの侵入やroot権限へのアクセスに加えて、ユーザーの不審な行動を監視することができる
CentOS上でプロセスアカウンティングを行うには、psacctパッケージを用いる
psacctのスタートアップスクリプトを実行するだけでプロセスアカウンティングが有効になる
psacctには、記録したデータを操作するために下記のようないくつかのコマンドがある
| コマンド | 概要 |
|---|---|
| ac | ユーザーがコンピュータに接続した合計時間を解析する 引数なしで自分の、-pオプションをつけると全ユーザーのログインした時間を表示する |
| lastcomm | 引数でユーザー名またはコマンド名またはターミナル名を指定すると、ユーザーが実行したコマンドの詳細情報を表示する |
| sa | 引数なしで実行された全てのコマンド、-uオプションをつけるとユーザーごとに実行されたコマンドを集計して表示する |
なお、プロセスアカウンティングは実行されたコマンドを全て記録するため、ログが膨大な量になる
そのため、下記サイトを参考にログのローテーションを設定することを推奨する
http://www.usupi.org/sysad/140.html
まず、プロセスアカウンティングを行うpsacctパッケージをインストールしましょう。 (CentOS 6.8 の場合はデフォルトでインストールされているので、この操作は必要ないです)
# yum install -y psacct
次に、psacctが自動で立ち上がるように、自動起動設定を行って、psacctを起動しましょう
# chkconfig psacct on # /etc/init.d/psacct start
それでは、ユーザーの行動記録を見ていきましょう。
まずは、ユーザーがログインしていた合計時間を調査する方法です。
acコマンドを使用することで、ユーザがコンピュータに接続した時間を表示することができます。 引数なしで実行すると自分がログインした時間を表示することができます。
# ac total 336.47
オプション「-p」を使用することで、全ユーザーがログインしていた時間を表示することができます。
# ac -p root 307.36 dojo 29.11 total 336.47
rootは307.36時間、dojoは29.11時間ログインしていたことが分かります。
これを利用することでどのユーザーがどのくらいログインしたかを調べることができ、証拠の確保することができます。
次に、アカウントログを見ていきましょう。
[lastcomm]コマンドを使用することで、psacctサービスを起動してから実行されたコマンドのログを出力することができます。
また、引数にユーザーやコマンドを指定することで、それに該当するログのみを出力することができます。
# lastcomm root vim S root pts/0 0.05 secs Tue Mar 21 10:23 touch S root pts/0 0.00 secs Tue Mar 21 10:23 packagekitd S root __ 0.01 secs Tue Mar 21 10:18 flush-vboxsf-1 F root __ 0.00 secs Tue Mar 21 10:18 lastcomm root pts/0 0.00 secs Tue Mar 21 10:20 ac root pts/0 0.00 secs Tue Mar 21 10:20 crond SF root __ 0.00 secs Tue Mar 21 10:20 sadc root __ 0.00 secs Tue Mar 21 10:20 date root __ 0.00 secs Tue Mar 21 10:20 date root __ 0.00 secs Tue Mar 21 10:20 lastcomm root pts/0 0.00 secs Tue Mar 21 10:19 (以下略)
# lastcomm touch touch S root pts/0 0.00 secs Tue Mar 21 10:23 touch S root pts/0 0.00 secs Tue Mar 21 10:19 touch root pts/0 0.00 secs Tue Mar 21 10:19
表示される内容は全て左から順に以下のようになってます。
- ユーザが実行したプロセスの名前
- システムのアカウント機能によってつけられるフラグ
- プロセスが呼ばれたコマンド名。
- プロセスが使用した CPU ( -c) または実 ( -e) またはシステム ( -s) またはユーザ ( -u) 時間の合計 (秒単位)
- プロセスが開始 ( -S) または終了 ( -E) した時刻
(http://www.yosbits.com/opensonar/rest/man/freebsd/man/ja/man1/lastcomm.1.html)
これを使用することで、いつ、どのユーザーが、どのコマンドを実行したかという証拠を確保することができます。
また、このログは「/var/account/pacct」に記載されており、削除すると履歴がクリアされてしまう。そして、psacctは機能しなくなるため、再度psacctを起動する必要があるので注意しましょう。
次に、コマンドのカウント情報を見ていきましょう。
[sa]コマンドでアカウントログに記録されているすべてのコマンドについて集計を行い、それらの実行回数、CPU時間などの詳細情報と共に表示することができます。
# sa
2414 6284.72re 0.01cp 10706k
2 2.27re 0.01cp 25888k prelink
23 5355.36re 0.00cp 24339k ***other*
65 0.00re 0.00cp 28049k find
2148 0.19re 0.00cp 9148k ld-linux-x86-64
71 1.17re 0.00cp 26582k awk
33 0.00re 0.00cp 1790k tmpwatch
18 0.00re 0.00cp 26528k makewhatis*
12 0.00re 0.00cp 25232k basename
11 0.00re 0.00cp 25232k logger
3 0.00re 0.00cp 25232k renice
3 0.00re 0.00cp 25232k cat
3 0.00re 0.00cp 26528k prelink*
3 0.00re 0.00cp 25232k rm
3 0.00re 0.00cp 25232k tr
2 925.70re 0.00cp 0k flush-vboxsf-1*
2 0.02re 0.00cp 27456k logrotate
2 0.00re 0.00cp 25864k grep
(以下略)
上記の表示内容は左から以下のようになっている。
- 実行回数
- 実行時間 (分単位)
- ユーザ時間とシステム時間を合計 (分単位)
- 1回実行したときの I/O 操作の平均回数
- CPU 時間 1 秒あたりのメモリ使用量 (KB 単位)
- コマンド名
詳しい内容は以下リンク先に載っているので、参考に。
また、オプション「-u」を用いることで、ユーザーごとにコマンドの実行履歴を集計して表示することができます。
# sa -u root 0.00 cpu 981k mem accton root 0.00 cpu 26288k mem touch root 0.03 cpu 27152k mem psacct root 0.00 cpu 26656k mem service root 0.00 cpu 1018k mem ac root 0.00 cpu 25232k mem sleep root 0.00 cpu 26496k mem awk root 0.00 cpu 27056k mem ksmtuned * root 0.01 cpu 1563k mem pgrep root 0.00 cpu 27056k mem ksmtuned * root 0.00 cpu 27056k mem ksmtuned * root 0.00 cpu 26496k mem awk root 0.00 cpu 27056k mem ksmtuned * root 0.00 cpu 25232k mem sleep root 0.00 cpu 26496k mem awk root 0.00 cpu 27056k mem ksmtuned * root 0.00 cpu 1563k mem pgrep root 0.00 cpu 27056k mem ksmtuned * root 0.00 cpu 27056k mem ksmtuned * root 0.00 cpu 26496k mem awk root 0.00 cpu 27056k mem ksmtuned * root 0.00 cpu 1642k mem lastcomm root 0.00 cpu 25232k mem sleep root 0.00 cpu 26496k mem awk root 0.00 cpu 27056k mem ksmtuned * root 0.01 cpu 1563k mem pgrep root 0.00 cpu 27056k mem ksmtuned * root 0.00 cpu 27056k mem ksmtuned * root 0.00 cpu 26496k mem awk root 0.00 cpu 27056k mem ksmtuned * root 0.01 cpu 4248k mem unix_chkpwd root 0.00 cpu 26304k mem date root 0.00 cpu 26304k mem date root 0.02 cpu 25248k mem sadc root 0.03 cpu 29216k mem crond *
コマンドごとにCPU時間、メモリの使用量などが確認できます
このコマンドを使用すると、大量のログが出力されるので、一度ファイルに書き出してから[less]コマンドなどで参照することをオススメします。
このコマンドを使用することで、ユーザーが過度にCPU時間を消費していないか、危険なコマンドを実行していないかなど、不審な振る舞いを発見することができます。
難しい内容で、なかなか理解をするのが大変ですが、このコマンドがあるということだけでも覚えておきましょう。
Linuxの理解が深まった時、役に立てる時が来るのではないでしょうか。
- IDSツールを用いてネットワーク上に接続されたシステムの状態を詳細に監視して、不正アクセスの兆候を発見できるようになる
- コンピュータを単に強固にするだけでは未知の脅威から防御することができない
- 防御できないものに関しては即座に発見して、迅速な対応をとらなければならない
近年、アンチウイルスソフトやファイアウォールでは防御できない未知の脅威が増加している
その理由は、攻撃者の目的が自己顕示からある目的を果たす(個人情報を盗むなど)ことに変化してきているからである
何としてもコンピュータに不正アクセスしようとしてあらゆる手段を試す
その結果、攻撃者に不正アクセスを許してしまう事態に陥る
つまり、不正アクセスを完全に防御することは不可能なので、不正アクセスされたときに以下に早く気付いて対策をとれるかということが重要になってくる
本で紹介されている「ossec HIDS」は統合監視ツールで、下記のような特徴を持つ
- 多種多様な形態のログファイルの相関分析を行うことができる
- Windows、Unix等様々なOSに対応しており、クライアント-サーバ方式で大規模なネットワークシステムの監視も行える
※Windowsではクライアント側のossecのみ提供されている
だが、2016年8月18日にJVNより「OSSEC」にはXSSの脆弱性があることが公表された。
以下引用(サイト: http://www.security-next.com/072863)
オープンソースのIDS「Open Source HIDS Security（OSSEC）」向けに提供されているウェブユーザーインターフェースに脆弱性が含まれていることがわかった。修正版が公開されているものの、メンテナンスは中断しており、利用は非推奨とされている。
脆弱性情報のポータルサイトであるJVNによれば、「OSSEC Web UI」にクロスサイトスクリプティング（XSS）の脆弱性「CVE-2016-4847」が含まれていることが判明したもの。ウェブブラウザ上で任意のスクリプトを実行されるおそれがある。
同脆弱性は、馬場将次氏が情報処理推進機構（IPA）へ報告したもので、修正にあたりJPCERTコーディネーションセンターが調整を行った。
同ソフトは、「同0.8」の段階ですでにメンテナンスが行われていない状況だが、OSSECの開発チームでは、今回の報告を受けて2015年12月末に同脆弱性を解消するパッチ「OSSEC Web UI 0.9」を公開している。
しかしながら、メンテナンスを実施していないことを理由に開発チームでは同ソフトの利用を避け、他製品を利用するよう推奨。同プロジェクトのメンテナンスに興味がある開発者を募集している。
内容を簡単に要約すると、この報告の脆弱性の修正は行ったが、開発団体はそれ以降メンテナンスを実施していないため「OSSEC」を利用するのは非推奨としている。
つまり、「OSSEC」をメンテナンスする企業や団体が現れない限り、脆弱性に対する対策は行われないので、利用するにはリスクを伴うことになる。
一応これからメンテナンスを行う企業や団体が現れた時のために、「ossec HIDS」を用いた監視方法について解説するが、実務では使用しないように。使うとしても、「IDS」を理解することを目的として使うこと。
ちなみに、OSSECの代わりになるHIDSとしては以下のようなものがある。
Tripwireとは、コンピュータに保存された情報の変更管理や改竄検知などができるソフトウェア。同名のTripwire社が開発しており、無償で公開されているオープンソース版と、同社が販売している商用版がある。
ファイルやフォルダ/ディレクトリの変更を監視し、いつどのように変更されたかを知ることができる。不正に改竄されたり意図せず破損してしまった場合には以前の状態に戻すことができる。
外部からの不正なアクセスによりシステムが改変されたり重要なファイルが改竄されたりした場合にこれを知ることができることから、ホスト型IDS(Intrusion Detection System：侵入検知システム)の一種として分類されることもある。
また、システムファイルやプログラムファイルを監視させることで、システムの管理や更新が正常に実施されたか確認し、異常がある場合は元の状態に復旧したり原因を調べたりすることもできるため、システム管理ソフトとして紹介されることもある。
(引用: http://e-words.jp/w/Tripwire.html)
また、Tripwireにおいてはこのような記述もあります。
変更検知のデファクトスタンダードTripwire
またクレジットカードの国際カードブランド5社 (American Express、Discover、JCB、MasterCard、VISA) 共同で策定した情報セキュリティ標準の PCI DSS に要求されるセキュリティ・コンプライアンスの遵守のために Tripwire 製品の使用が事実上必須となりました。
(引用: https://www.tripwire.co.jp/about/)
AIDEとはAdvanced Intrusion Detection Environment の略で、オープンソースの改ざん・侵入検知システムです。
おもにサーバホストのファイル改ざん・侵入検知の機能を有しています。
この分野では『Tripwire』が最も有名です。
AIDEの魅力としては、CentOSやRedhatであれば、外部レポジトリを用いることなく、オリジナルのパッケージが使えることです。
(引用: http://techblog.clara.jp/2015/04/aide_install_and_setting/)
Tripwire Tripwireには、OSS（GPLv2）のものと有償のものがあります。 OSS版であれば、すぐに使いはじめることが可能ですし、歴史も長いので情報も多いです。 しかし、2000年ごろに有償化され、現在OSSとして入手できるのはLinux版だけです。 CentOS 6では、EPELリポジトリから入手することが出来ます。 AIDE AIDEは、OSS（GPL）です。 Tripwireが有償化されたため、代替品として使われることが多くなりました。 CentOS 6では、標準リポジトリ（base）に含まれています。
(引用: https://www.fl-ops.com/mori-dojo/archives/53)
これらを考慮すると、実運用で使用する場合はデファクトスタンダードにもなっている「Trip wire」を利用するのが良いでしょう。
これから記載するのは「CentOS6.8」の場合です。他のバージョンを利用している場合は適宜そのバージョンに置き換えてください。
まず、ossecのソースアーカイブを入手して展開しましょう
下記サイトより[Server/Agent]と[Web UI]の最新のバージョンを入手します。 (現在2017/03/21の時点で、[Server/Agent]は2.9、[Web UI]は0.9) [Server/Agent] [Web UI] (元サイト: http://ossec.github.io/downloads.html)
左側にある「Latest release」をクリックすることで最新のバージョンのリンクに飛べます。下の方にスクロールして「Downloads」から「Source code(tar.gz)」を入手しましょう。
ダウンロードしたら任意の場所に解凍します。
# tar xf ossec-hids-2.9.0.tar.gz # tar xf ossec-wui-0.9.tar.gz
それではまず、HIDSの方からインストールしましょう。
展開したディレクトリ「ossec-hids-2.9.0」内に移動し、install.shを実行してossecをインストールしましょう
インストール中の問い合わせには主に下記のものがあります
-
「どの言語にしますか」
- 「jp」と入力すると日本語になる
-
「どの種類のインストールを選択しますか」
- local：1台のコンピュータ上でossecすべてを実行する場合
- agent,server：クライアント-サーバ方式にする場合 (← 今回はこれ)
-
OSSEC HIDS のインストール先を選択してください [/var/ossec]:
- 特に指定がなければ「空Enter」で「/var/ossec」にインストールします。
-
「整合性検査を行うデーモンを実行させますか?」
- 整合性検査：ファイルが改ざんされていないかを定期的にチェックします
-
「rootkit 検知エンジンを実行させますか?」
- rootkit：侵入(攻撃)者がコンピュータへのアクセスに成功したあとで実行するソフトウェアツールのセット
-
「アクティブレスポンスを有効にしますか?」
- アクティブレスポンス：既知の侵入者のIPアドレスを一定時間、自動的に遮断する機能
-
「OSSEC HIDS サーバの IP/hostname アドレスは何ですか?」(agentを選択した場合)
- serverをインストールしたコンピュータのIPアドレスを指定します
今回はクライアント-サーバ方式で構成します。 実務では1台のコンピュータでIDSを構成することは業務形態上(SOCなど)、あまり考えにくいため、こちらを採用します。
では先にサーバーにインストール(server)して、あとでクライアントにインストール(agent)します。
# cd ossec-hids-2.9.0
# . install.sh
** Para instalação em português, escolha [br].
** 要使用中文进行安装, 请选择 [cn].
** Fur eine deutsche Installation wohlen Sie [de].
** Για εγκατάσταση στα Ελληνικά, επιλέξτε [el].
** For installation in English, choose [en].
** Para instalar en Español , eliga [es].
** Pour une installation en français, choisissez [fr]
** A Magyar nyelvű telepítéshez válassza [hu].
** Per l'installazione in Italiano, scegli [it].
** 日本語でインストールします．選択して下さい．[jp].
** Voor installatie in het Nederlands, kies [nl].
** Aby instalować w języku Polskim, wybierz [pl].
** Для инструкций по установке на русском ,введите [ru].
** Za instalaciju na srpskom, izaberi [sr].
** Türkçe kurulum için seçin [tr].
(en/br/cn/de/el/es/fr/hu/it/jp/nl/pl/ru/sr/tr) [en]: (← jpと入力)
OSSEC HIDS v2.9.0 インストールスクリプト - http://www.ossec.net
OSSEC HIDS のインストール作業を始めます．
事前に C コンパイラがシステムにインストールされてる必要があります．
- システム: Linux localhost.localdomain 2.6.32-642.13.1.el6.x86_64
- ユーザ: root
- ホスト: localhost.localdomain
-- 続けるには ENTER を押してください．また，Ctrl-C で中止します． --
1- どの種類のインストールを選択しますか (server，agent，local または help)? server
- Server インストールを選択しました.
2- インストール環境を設定しています.
- OSSEC HIDS のインストール先を選択してください [/var/ossec]:
- インストール先を以下に作成します /var/ossec .
3- 設定 OSSEC HIDS.
3.1- メール通知を希望しますか? (y/n) [y]: n
--- メール通知を無効にしました.
3.2- 整合性検査を行うデーモンを実行させますか? (y/n) [y]: n
- syscheck (整合性検査デーモン) は実行させません.
3.3- rootkit 検知エンジンを実行させますか? (y/n) [y]: n
- rootcheck (rootkit 検知) は実行させません.
3.4- アクティブレスポンスによりイベントが発生した際に特定の
コマンドを実行することができます．
例えば，ある IP アドレスを遮断することや特定のユーザ
に対してアクセスを無効にすることができます．
詳細な情報は以下にあります:
http://www.ossec.net/en/manual.html#active-response
- アクティブレスポンスを有効にしますか? (y/n) [y]: n
- アクティブレスポンスを無効にしました.
3.5- リモート syslog (port 514 udp) を有効にしますか? (y/n) [y]: y
- リモート syslog を有効にしました.
3.6- 以下のログを解析するための設定を準備しています:
-- /var/log/messages
-- /var/log/secure
-- /var/log/maillog
- 他のファイルを監視したい場合は，ossec.conf を変更し
新しいエントリーを追加してください．
設定に関するどんな質問にも我々の Web サイト http://www.ossec.net
を訪れることで答えることができます．
上記画面まで表示されると、Enterの入力を求められ、入力するとインストールが始まります。
そして、下記のメッセージが表示され、Enterを更に入力すると完了です。
- システムは Redhat Linux.
- 初期スクリプトはブート中に OSSEC HIDS を起動するよう修正しました．
- 設定が完全に終了しました.
- OSSEC HIDS を開始させます:
/var/ossec/bin/ossec-control start
- OSSEC HIDS を停止させます:
/var/ossec/bin/ossec-control stop
- 以下のファイルで設定についての確認と変更ができます /var/ossec/etc/ossec.conf
OSSEC HIDS の使用に感謝します．
あなたが何らかの質問，提案したいときや，バグを発見したときは，
[email protected] まで連絡するか [email protected] にある
我々の公開メーリングリストを使ってください．
(http://www.ossec.net/main/support/)．
詳細な情報は http://www.ossec.net にあります．
--- ENTER を押すと終了します (以下，詳細な情報が続きます)．---
- エージェントを追加する前にアクセスするための認証が必要になります．
エージェントを追加するか削除する際は 'manage_agents' を実行してください:
/var/ossec/bin/manage_agents
詳細な情報は以下にあります:
http://www.ossec.net/en/manual.html#ma
上記画面のメッセージにもある通り、serverのインストールが完了したら「manage_agents」を実行するように求められます。
下記の操作をserver上で行い、serverで管理するagentを登録しましょう。
# /var/ossec/bin/manage_agents ： Choose your actions: A,E,L,R or Q: a ← agentを登録する場合はaを入力します ： A name for the new agent: dojo.local ← agentの名前を入力します The IP Address of the new agent: 192.168.1.80 ← agentのIPアドレスを入力します ： Confirm adding it?(y/n) : y ← yを入力してagentを登録します
agentの登録が完了したら、続いてagentに与える鍵を生成します。
生成した鍵をagentがインポートするとserverと通信できます。
： Choose your actions: A,E,L,R or Q: e ← 鍵を生成する場合はeを入力します ： Provide the ID of the agent to extract the key (or '\q' to quit): 001 ← agentのIDを入力します Available agents: ID: 001, Name: ossec_client, IP: 192.168.1.125 Provide the ID of the agent to extract the key (or '\q' to quit): 001 Agent key information for '001' is: MDAxIG9zc2VjX2NsaWVudCAxOTIuMTY4LjEuMTI1IGY2ZTdkY2U4MzhiNzY4NzQzZDIyZmZjMmRmOTIwZDNlOTEyMDhiY2RlOGY0MDcxMzg1M2VhODNlOWEyYzMwZjY= ** Press ENTER to return to the main menu. (Enterを入力して完了)
この時表示された「Agent key」の部分をコピーしておきましょう。後程必要になります。
これでserverの設定は完了です。では次に、agentの設定を行いましょう。
まずはserverと同様の手順で「OSSEC」をインストールします。
差異がある部分のみ記述します。
(前略) 1- どの種類のインストールを選択しますか (server，agent，local または help)? agent - Agent(client) インストールを選択しました. (中略) 3- 設定 OSSEC HIDS. 3.1- OSSEC HIDS サーバの IP/hostname アドレスは何ですか?: 192.168.1.32 - サーバの IP を加えています 192.168.1.32 (以下略)
これでインストールは完了です。
次に、下記の操作をagent上で行い、server上で生成した鍵をagentにインポートします
# /var/ossec/bin/manage_agents ： Choose your action: I or Q: i ← 鍵をインポートする場合はiを入力します ： Paste it here (or '\q' to quit): ← ここにserver上で生成した鍵をペーストします ： Confirm adding it?(y/n) : y ← yを入力してagentに鍵をインポートします Added. ** Press ENTER to return to the main menu. (Enterを入力して終了する)
これでagent側の設定が完了しました。
あとは、server上およびagent上でossecを起動して監視を開始しましょう。
設定が正しく行われていた場合、/var/ossec/logs/alertsの配下にアラートが書き出されます。 アラートは発生年、付きで名前を付けられたディレクトリに、発生日のファイル名で格納されます。ここでは「/var/ossec/logs/alerts/2017/Mar/ossec-alerts-17.log」(2017/3/17)
アラートファイルを参照すれば、クライアント側からの警告が書き込まれていることを確認できます。（以下の例はsshでの接続に失敗した時）
tail -f /var/ossec/logs/alerts/2017/Mar/ossec-alerts-17.log
** Alert 1489725748.4720: - syslog,sshd,authentication_failed,
2017 Mar 17 13:42:28 (dojo.local) 192.168.1.80->/var/log/secure
Rule: 5716 (level 5) -> 'SSHD authentication failed.'
Src IP: ::1
User: root
Mar 17 13:42:30 dojo sshd[11508]: Failed password for root from ::1 port 42358 ssh2
# /var/ossec/bin/ossec-control start
以上でOSSECの説明は終わりです。
冒頭にも説明しましたが、OSSECはメンテナンスがされておらず、脆弱性が晒される危険性は少なからずあるので、実運用では使用しないようにしましょう。
導入方法についてはそれぞれ下記を参考にしてください。