Deep Security as a Service (DSaaS)でProxyを利用する場合の注意事項

はじめに

くどうです。

DSaaSをProxyを使用する場合のTipsです。 ちょいとハマったので。

DSaaSは導入すると、外向けに443、80を全開放する必要があります。 Azure、AWSもですが、外向けにセキュリティグループを設定する場合、IPで指定します。 そのため、固定ではないDSaaSでは全開放するという矛盾が発生します。 http://esupport.trendmicro.com/solution/ja-JP/1104586.aspx http://esupport.trendmicro.com/solution/ja-JP/1097010.aspx

そこで、Proxyを利用し、出口を絞ることでリスクを低減します。 さらに、ホワイトリストを指定することで、DSaaSのみで利用するProxyにします。

Proxyを設定する

ホワイトリストを行うため、FQDNでフィルタリングできるProxyを設定します。 Proxyと言えばsquidということで以下は、ホワイトリストを利用できるsquid.confです。 localnetはネットワークに合わせて変更してください。 キャッシュは利用しないでください。DSaaSの挙動がおかしくなります。

/etc/squid/squid.conf

ホワイトリスト /etc/squid/whitelist

先頭は「.」要ります。

DSaaSを設定する

DSaaSのインストールは下記に従い行ってください。 http://esupport.trendmicro.com/solution/ja-JP/1110288.aspx

インストール後、有効化を行う前にAgentがProxyを利用できるよう下記のコマンドを実行します。

ここで有効化します。

有効化後、不正プログラム対策を開き、Smart ProtectionのProxyの設定をします。

WebレピュテーションのSmart ProtectionのProxyの設定も同様に行います。

他に、システム設定のプロキシも設定します。

DSaaSの設定は以上で完了。

あとは、ご勝手に。

まとめ

IPが固定できれば問題はなかったのですが、固定できないため以上の方法をとりました。 今後、クラウド環境で外向けも閉じた環境を作る機会が増えると思います。特にエンタープライズな環境とか・・・。

ではでは

[…]

Azure Load Balancerと Azure Application Gateway のアクセスログを比較してみる

はじめに

くどうです。

Azureにはアクセスを負荷分散する方法として、Load BalancerとApplication Gatewayが用意されています。 しかし、それぞれレイヤー4とレイヤー7で挙動が異なりHTTPdへのアクセスログが異なります。 そこで、今回はアクセスログについて比較していきたいと思います。

用意した環境はCentOS上にApacheをデフォルトの状態(yum install httpd)したものです。

Load Balancer

実際にログを確認してみます。

Load Balancerからの死活監視(プローブ)は「Load Balancer Agent」と表示されます。 通常の外部からのアクセスもIPアドレスなども問題なく表示されています。

ただし、Load Balancerからの死活監視のログが邪魔ですね。 /etc/httpd/conf/httpd.conf を以下のように設定し排除します。

これで出力されなくなります。

Application Gateway

実際にログを確認してみます。

アクセス元は、すべてApplication Gatewayの内部アドレスになっていることが分かります。 これでは、アクセスログの解析には役立ちません。

これを解決する方法として、X-Forwarded-ForとX-Forwarded-Protoをログに残します。 これはAWS ELBとも同じです。

/etc/httpd/conf/httpd.conf を編集しています。

実際にログを確認してみます。

末尾の方でX-Forwarded-ForとX-Forwarded-Protoが取得できていることが確認できます。 これで問題なく解析が行えるかと思います。

まとめ

アクセスを負荷分散するLoad BalancerとApplication Gatewayですが、それぞれ出力されるアクセスログも異なるため気を付けましょう。 また、対処する方法も異なるので気を付けましょう。これらはAzureに限ったことではありません。 X-Forwarded-ForとX-Forwarded-Protoが利用されるケースが多いので覚えておくとよいと思います。

ではでは

Azure上のActive Directoryをディレクトリサービス復元モード(DSRM)で復元してみる。

はじめに

くどうです。

クラウド上でActive Directory(以下AD)を設計をする場合、復元方法についてよく議題に上がります。 特にADが論理障害起きた場合です。もう全部のADが死んで使えないときです。 実際は障害が起きないように冗長構成にして念入りに設計しましょう(w

もし障害が発生した場合どうするか、Azreu上でのADを、実際にバックアップを取得し復元するまでを説明していきます。 バックアップは普段からとっていることが前提ですが、復元には「ディレクトリサービス復元モード」で起動し作業を行います。

今回、対象にしているOSはWindows Server 2012 以降になります。 また、英語OSを利用しています。日本語でも変わりません。

バックアップ方法

バックアップにはWindows Server バックアップを使用します。 その為に、バックアップ先として別のディスクを指定する必要があります。

仮想マシンからディスクを追加します。 データディスクとしてマウントします。

次にディスクの管理を起動してフォーマットし、バックアップ先として利用できるようにします。

次にWindows Server バックアップを機能として追加します。

Windows Server バックアップを起動し、バックアップの設定を行います。 今回は、テストなので一回だけバックアップ取得するように設定します。 Backup Oneceでウィザードを起動します。 Diffrent opsionsを選択します。

Customを選択します。

Add Itemsを選択します。

System State(システムの状態)を選択します。

追加されたことを確認します。

Local Drivesを選択します。

マウントしたディスクを選択します。

確認画面がでます。Backupを開始します。

初期状態だとバックアップには30分もかからず終了します。

以上でバックアップは完了です。 […]