踏み台サーバでのSSHアクセス監査


Summary

踏み台サーバでセキュアにアクセス監査を行う設定手順。

前提事項

  • 踏み台及びログイン対象サーバはLinux
  • 踏み台サーバのroot権限を持っている
  • ProxyCommnad、コマンド送信を利用した自動多段アクセスを無効化できる

方法

  • 踏み台サーバ上のsshdにForceCommandを設定
  • 踏み台サーバ上のsshdにAllowTcpForwardingを設定
  • ForceCommndでscritpを強制的にたたかせてロギング
  • ログファイルを追記のみ許可

背景

 

民間システムの中でセキュリティが最も厳しく要求されるPCIDSSという規格(クレジットカード会社のシステムに要求されるもの)によると、

以下のような監査がもとめられるらしい。

・いつ、どのユーザが、どのような操作を行ったかをすべて記録する

・それらをユーザに変更されない状態で保管する

・監査機能の起動停止、および設定変更を記録し、保管する

クレジットカード会社のシステムに限らず、情報漏洩にうるさいこのご時世ですから、

これくらいの監査を求めるシステムは多いのでは?と思う。

 

しかし、

クライアントにroot権限を渡すような場合だと、

ログの削除なんて簡単に行えちゃったり、監査の停止ができたりするため、

これらをサーバ内で完結して用意することは難しい。

 

そこでよく取られる構成は、

クライアントPC ——>  踏み台サーバ ——-> ログインしたいサーバ

というものである。

踏み台サーバの特権ユーザはクライアントに譲渡せず、

踏み台サーバ上で全てのログを取ることで、

ログイン先のサーバの特権を監査された状態で譲渡することができるというものである。

 

しかしながら、

監査機能混みのパッケージも存在するが有償だったり、

Linuxの標準機能のみで用意しようとすると、

自分の検索した限りは以下のような不十分な方法しか見つからなかった。

悪い例1

踏み台サーバの/etc/profileにscriptコマンドを記述する方法

scritpコマンドがユーザからkillできてしまうのでアウト

scritpコマンドの出力(=監査ログ)が消せてしまうのでアウト

悪い例2

bash_historyなりなんなりを上手い事をコピーしたり上手い事する。

コマンドの実行結果がロギングされないのでアウト。

悪い例3

画面出力をloggerコマンドに出力し、標準出力に戻すというやり方。

こんなスクリプトを作成し、/etc/profileの最後で読み込ませる。

するとsyslogとしてコマンドがロギングされる。

(上記の例だとlocal0.infoがどこにフォワードされるかによる)

一見良さそうだが、問題点がいくつかある。

  1. ログが見にくい

ログインユーザごとに出力先を変えるなどがないため、ごちゃごちゃになってしまう危険性がある。

2.  多段ログインを監査できない

ssh の ProxyCommnadを利用したり、sshのコマンド転送機能を使って自動で多段ログインを実装した場合、監査が起動しない。

ProxyCommandを利用した方法はこんな感じ。

コマンド転送機能を使うとこんな感じ

これはbashの仕様によるもので、/etc/profileがこれらのアクセス方法だと読み込まれないからであるとのと。

 

というわけで、これら以外の方法でうまいことPCIDSSを満たすような踏み台サーバ上での監査方法を考えた。

 

方法

概要

以下のような方法をとることで、監査を行うことができる。

  • sshの基本機能であるForceCommandを利用し、監査機能を強制実行する
  • ProxyCommnadによる多段ログインは無効化する
  • 監査ファイルを追記モードに設定し、削除を禁止する

 

監査機能の設定

以下のようなスクリプトを用意する。

scriptコマンドを利用し、日付とユーザ名をつけたファイルにロギングする。

(例えば /user/local/accesslog/accesslog_user_20160619.log)

これをsshのForceCommnadを利用して強制的に読み込ませる。

最終行に追記

 

多段ログインの禁止

上記のような設定を入れたことで、sshのコマンド転送機能は無効化される。

転送されたコマンドが実行される前にProxyCommnadが割りこむ形になるため。

 

しかし、ProxyCommnadによる多段ログインは通ってしまうので、踏み台サーバ上のsshデーモンの設定を変更しておく

最終行に以下を追記

 

踏み台サーバ上でsshdを再起動する。

 

ログファイルの保護

このままだとユーザにscriptコマンドによって取得されたログファイルが削除されてしまう。

そのため、ファイルに属性を付加し削除やcat /dev/nullを禁止する。

 

以上の方法をとることで、安全に監査することができそう。

 

あとがき

この記事で紹介した内容だと、以下のような方法の問題点が残りそう。

  1. X転送による画面操作がロギングできない
  2. 多段ログインを機能として必要としているクライアントアプリケーションが利用できない

1.についてはXを無効化し、Xを有効化するような行為で発砲するような機能を用意する必要がある。

また、2.は自社がスクラッチで作ったアプリなんかがあると必要だったりするかもしれない。

 

 

 

というわけで参考になれば。

 

 

About Hiroyuki Yahagi 5 Articles
大学時代に友人が「プログラミングやっとけば潰しきくんじゃね」と言ってたのを聞いて軽い気持ちでITをはじめました。 「自給自足のエンジニア」を目指して日々勉強中。

Be the first to comment

Leave a Reply

Your email address will not be published.


*