Deep Security で Amazon Linux のセキュリティ対策 : インストール編

Takuro Hirayama 508views 更新:2016年4月14日

はじめに: Deep Security とは

Trend Micro Deep Securityは現在のサーバが抱えているセキュリティ課題を仮想・クラウド・物理環境にまたがって、 トータルに解決する統合型サーバセキュリティソリューションです。 ( Trend Micro Deep Security 公式サイト より引用)

Trend Micro Deep Security 公式サイト をご覧いただくと詳しく紹介されていますが、Deep Securityは下記の保護・監視機能を備えたセキュリティ対策システムです。

  • ウイルス対策(Webレピュテーション機能付)
  • Webアプリケーション保護
  • 侵入検知・防止(ホスト型IDS/IPS)
  • ファイアウォール
  • ファイルやレジストリなどの変更監視
  • セキュリティログ監視

オールインワンなセキュリティ対策システムとなっているのに加え、エージェント型・仮想アプライアンス型のモジュールが存在するので、環境に応じて柔軟に対応することができる仕組みになっています。

本記事の目的

本記事では、WordPress が稼働している AWS の EC2 のインスタンスに対して Deep Security Agent を設置してセキュリティ対策を行いました。

0. 前提条件

Deep Security

SaaSとしてサービスされている Deep Security Manager 9.6 (以下、DSM) を利用しました。

Deep Security Agent

DSM管理コンソールにて取得できるインストールスクリプトを用いて Deep Security Agent 9.6.2(以下、DSA)をインストールしました。

保護対象(DSAインストール対象)サーバ

  • OS: Amazon Linux AMI (64 bit) (4.1.17-22.30.amzn1.x86_64)
  • インスタンスタイプ: t2.medium
  • 主なアプリケーション: WordPress

1. EC2に関連付けたセキュリティグループへのルール追加

公式Q&AページDeep Security インストールガイド に、DSAが使用するポートが記載されているので、それらにしたがってセキュリティグループのルールを追加します。

監視対象サーバ上でDSAを常駐させることになるので、TCP 4118, 80, 443 へのインバウンドを許可しました。

2. DSM管理コンソールでの初期設定

DSM管理コンソールへのログイン

今回は、SaaS事業者から通知された認証情報(アカウント名・ユーザ名・パスワード)を使用してログインしました。

アクティベーション

管理 > ライセンス 画面にある 新しいアクティベーションコードの入力 ボタンを押下します。

その後、表示されるウインドウにある 複数のモジュール用の単一アクティベーションコード 欄にアクティベーションコードを入力してアクティベーションを行います。

今回は、SaaS事業者から通知されたアクティベーションコードを利用しました。

アクティベーション画面

ポリシー作成

ポリシーとは、各保護機能の設定(有効/無効、ルール割当設定…)に対して名前をつけて管理・再利用可能にするための概念です。

ポリシーを用いることで、

  • 複数台構成のサーバ群に同じポリシーを割り当てておいて、全サーバの保護設定を一括管理する
  • LAMPサーバ用ポリシー、Windowsファイルサーバ用ポリシーなど用途別にサーバ設定を管理する

といったことが可能になります。

また、ポリシーは継承機能を用いて、階層構造を構成することができるので、下記のようなことも可能です。

Windowsベース設定
  ├── Windows Server 2008
  └── Windows Server 2012

ベースとするポリシーをコピー

初期状態では、下記の Base Policy 群が存在しました。

Base Policy
  ├── Linux Server
  ├── Windows Server
  └── Solaris Server

今回は、Amazon Linuxに対してDSAをインストールするので、上記の Linux Server をベースに新しいポリシーを作れば良いのですが、 以下の様な理由から、Linux Server を複製したベースポリシー Linux Server Copy を作成して、それを継承させるようにしました。

  • オリジナルのベースポリシーを温存するため
  • ファイアウォール侵入防御 etc. のルール設定時に、継承元となる親ポリシーのルールを割当解除しないと、継承先の子ポリシーで不要なルールを割当解除できなかった

適用するポリシーの作成

実際に監視対象サーバに割り当てるポリシーを作成します。 今回は、前述の手順でコピーした Linux Server Copy を継承したポリシー( + 同等の検証環境用ポリシー )を作成しました。

ポリシー

詳しいポリシーの設定方法については、次回取り上げる予定です。

明示的に許可していない通信はすべて遮断されるので、下記の2点については十分に注意したほうが良いかと存じます。

  • ファイアウォールにてSSH接続を許可する
    • Remote Access SSH: TCP 22
  • ICMPパケットを必要最低限開ける
    • ローカルネットワーク内のICMPパケットを遮断すると、 Path MTU Discovery Black Hole などに陥り、通信不可になる恐れ

インストールスクリプト取得

右上の サポート情報 メニュー内にある インストールスクリプト を押下して、DSAのインストールスクリプトを取得します。

サポート情報

モーダルダイアログ(下図参照)にて、以下の通り設定を行いました。

  • プラットフォーム: Amazon Linux AMI (64bit)
  • インストール後にAgentを自動的に有効化: オン
  • セキュリティポリシー: 作成済みのポリシー
インストールスクリプト

3. サーバ上での初期設定

Deep Security Agent インストール

適当なディレクトリに、取得したインストールスクリプトを保存して実行します。

vim install_dsa.sh
# インストールスクリプトを貼り付けて保存
sudo bash ./install_dsa.sh

しばらくして、Command session completed. のような文言が出力されていれば成功です。

Amazon Linuxの場合、特に支障なくインストールできました。

4. DSM管理コンソールにてインストール確認

コンピュータ 画面にて下記を確認できればインストール完了です。

  • DSAをインストールしたサーバが表示される
  • ステータス管理対象 (オンライン) と表示される
インストール確認

おわりに

正常にインストールできたでしょうか?

次回は、ポリシー設定について取り扱っていきます。

ログイン / 新規登録してコメントする

このソースコードをストックして後で利用したり、作業に利用したソースコードをまとめることができます。

こちらもお役に立つかもしれません