SKILL CentOS

【攻撃遮断くん】攻撃遮断くんを導入した感想と保守メモ

更新日:

「攻撃遮断くん」というクラウド型WAFを導入する機会がありましたので、実際に導入してみての感想と、保守の際に必要な簡単なメモをまとめてみます。

スポンサーリンク


攻撃遮断くんとは?

サイバーセキュリティクラウドという会社が提供している、クラウド型のサービスで大手企業も導入しているようなサービスです。
【公式】攻撃遮断くん(サイバーセキュリティクラウド)

JDCCのレポート(JDCCインシデントレポート)にも挙がってますが、Webの改ざん被害というのは後を絶ちません。
Webの改ざん被害といってもピンとこない方もいるかもしれませんが、実はJDCCレポートにもあるように割とコンスタントに発生している問題です。

私も実際に改ざん被害にあった企業を何社か見てきましたが、残念ながら被害にあうまで特に対策をされていない(脆弱性対応のバージョンアップを怠っている等)ケースが殆どで、1度被害にあってしまうと原因となった脆弱性を調査し、すべてのコンテンツを改ざんされていないものに入れ替えるといった非常に手間と時間のかかる作業を強いられるような状況が発生します。

もちろん、この間HPはまともに公開できず、暫定的なページを公開した状態にせざるを得ないといったこともあり、企業のHPであれば社会的な信用を失いかねない重大な問題となってしまいます。

こうした改ざん被害を防ぐ手段の一つに、WAF(Web Application Firewall)があります。
読んで字のごとく、Webアプリケーション、要するにWebページ(例えば企業のHP)のセキュリティを高めるためのファイアウォールを指します。

これまでWAFというと専用の機器を購入し、専任の技術者が都度時代に合わせたチューニングを行う必要があり、運用コストが高くなってしまうといったことが問題でしたが、攻撃遮断くんのようなクラウド型のサービスであれば、専用の機器を買う必要もないですし、専任の技術者を置かなくてはならないなんてこともありません。
ここがクラウド型のWAFの最大の魅力ではないでしょうか。

サービスの内容は公式にもわかりやすく記載がありますので、そちらを見てみるのも良いと思います。
【公式】攻撃遮断くん(サイバーセキュリティクラウド) サービス概要

攻撃遮断くんを導入してみての感想

攻撃遮断くんを導入してみた感想ですが、端的に言うと「とても良い」と思いました。
具体的に良いと思ったポイントを書いてみたいと思います。

とにかく導入が楽!

攻撃遮断くんの特徴でもある、クラウド型であるメリットは非常に大きいと感じました。
アプライアンス型のWAFと異なり、新しく機器を購入して、設定して、なんてことは必要ありません。
Webサーバーに攻撃遮断君のエージェントをインストールして、必要な設定を行うだけです。
私の場合はLinux/CentOSへの導入を行いましたが、基本的な操作ができれば十分に導入することが可能です。

インストールマニュアルもしっかり用意されてますし、インストール自体も基本的にはインストーラの内容に従っていくだけなので大丈夫です。
導入するにあたり物理的な配線の変更等も必要なく、Webサイトを停止せず導入できるのも魅力かもしれません。
(もちろん間違って正しい通信が遮断されないようにホワイトリスト機能をちゃんと設定してあげる必要はありますが)

運用が楽!

WAFのキモは、「シグネチャファイル」と呼ばれる定義ファイルにあります。
この定義ファイルに攻撃パターンを記録することで、不正なアクセスかどうかを判断する基準に利用される重要なものですが、一度作ったらもう何もしなくても良いかというとそうではありません。
攻撃手法は時代と共に日々変わりゆくものですので、当然ですがこのシグネチャファイルを保守するという作業が発生します。

攻撃遮断くんの場合、エージェントを導入しておくだけです。
シグネチャの更新は攻撃遮断くんのクラウドサービス側で更新してくれるので、基本的には導入したらほったらかしで済みます。

管理画面が面白い!?

管理画面で攻撃元の国と状況を可視化(いわゆる見える化)して表示してくれます。
どこの国からどれだけ来てるか?が可視化されることによって直感的にわかるようになってます。
こうして可視化されるとちょっとした暇つぶしになっちゃうくらいには面白いです。

どういった攻撃が多いか?どこのIPから多いか?なんてのもランキング形式で表示してくれるので非常にわかりやすい。

これ以外にも簡単にではありますがレポート(PDF)を自動生成してくれる機能もあるので、毎月保守レポート作らなきゃ!なんてことも解決するのではないでしょうか。
毎月毎月攻撃状況を解析してレポートにする作業は大変ですよね・・・わかります・・・。

感想まとめ

高度な知識も不要、導入も簡単、保守もいらない、というのはユーザ側にとってもとてもありがたいものですね。
難しい設定とかはできないし、したくない。やるにしてもコストがちょっと・・・。でも、改ざん被害の対策はしておきたい。
そんなニーズは凄く多いのではないでしょうか。
専任の技術者がいなくても簡単に導入出来て、保守コストも比較的安価なのは非常に魅力的だと思います。

是非導入したいと思った方は下記のリンクを! と言いたいところですが残念ながらアフィなどありません。
ここまで書いておいてなんですが馬鹿正直に感想を述べているのみです・・・・

遮断されては困る通信があるんだけど大丈夫か?

攻撃遮断くんにはホワイトリスト機能がありますので、遮断されては困るIPを管理画面で登録すれば大丈夫です。
ローカルホスト[127.0.0.1]の通信が遮断されて動作に影響がでる、なんてこともあったりしたので気を付けてください。
環境にもよると思いますがホワイトリストにローカルの通信は許可するようにしておいた方がいいかもしれませんね。

冗長構成サーバに導入する場合はどうなるか?

(※2018年4月時点のものなので今後変更される可能性はあります)
導入時にサーバーのIP設定とかあったらどうしよう?とか思っちゃいますが、IP等の設定は特に気にする必要はありません。
冗長構成の場合は、冗長構成サーバー全台に攻撃遮断くんのエージェントをインストールすることになります。
この場合、遮断くんの監視対象「IPアドレス/FQDN」が [ any ]という設定でエージェントキーが発行されます。
[ any ]はどのIPアドレスであっても遮断くんのサービス利用が可能になるという設定らしいです。
この場合はエージェントキーによってどのサーバからの通信かを識別するとのこと。

NAT環境下で導入する場合

(※2018年4月時点のものなので今後変更される可能性はあります)
基本的には、WAN→LANに入ってくる際の通信だけを気にすればよいです。
外部から入ってくる通信をNAT変換して中継機器のIPでサーバ側に到達する場合は注意が必要です。
基本的にはWANから入ってくる通信は、送信元のIP(つまりインターネット側のクライアント)がそのままログに表示される必要があります。

攻撃遮断くんの仕組み上、ログに記録されるIPアドレスベースを参照してiptablesに書き込み、遮断を行う仕様となっているため、中継機器のIPでログを書き込んでしまうと中継機器の通信が遮断されるなんてことになってしまうので注意。

動作確認・設定(遮断ログ)

(※2018年4月時点のものなので今後変更される可能性はあります)

動作確認コマンド

攻撃遮断くんエージェントの動作状況を確認するには、下記コマンドを実行します。

# /etc/init.d/ossec status
ossec-logcollector is running...
ossec-syscheckd is running...
ossec-agentd is running...
ossec-execd is running...

※上記4プロセスが[running]になっていればOK。

サービス停止・起動・再起動

▼サービス停止

# /etc/init.d/ossec stop

▼サービス起動

# /etc/init.d/ossec start

▼サービス再起動

# /etc/init.d/ossec restart

攻撃遮断くんログの場所

▼遮断ログ
/var/ossec/logs/active-responses.log

▼エラー/システムログ
/var/ossec/logs/ossec.log

攻撃遮断くん解析対象ログの追加方法

ログの解析を追加する場合、「/var/ossec/etc/ossec.conf」へ該当のログファイルへの絶対パスを追記する。

システムログを指定する場合はlog_formatに「syslog」を指定。
Webログを指定する場合はlog_formatに「apache」を指定のうえ、locationに該当ファイルのパスを書けばよい。

定義更新後は、エージェントを再起動する。

# /var/ossec/bin/ossec-control restart

防御証明メールの脅威レベルとその内容

防御証明メールに記載されている脅威レベルは、下記の意味を示すみたいです。
(※2018年4月時点のものなので今後変更される可能性はあります)

0~5 脅威と判断しない為ブロックしません。

↓↓↓ここから↓の脅威レベルはブロック対象↓↓↓

06 - ワームかウイルスの可能性があるものを検知。

07 - 設定された禁止後に抵触した場合に検知。
removeやshutdown等コマンドで打たれると危険な禁止後にマッチ。

08 - CMSへのログイン失敗などで検知。
IDSなどで初検知した際やユーザが初めてログインした場合も検知。

09 - 無効なIP(0.0.0.0/0など)や登録されていないユーザから接続を
試みた際などに検知。

10 - 複数のユーザによって発生したエラー。
複数ユーザでログイン失敗などで検知。

11 - 完全性チェックエラーによる検知。
バイナリの変更やrootkitの可能性あり。

12 - 重要なイベント。システムやカーネルなどのエラーや警告を検知。

13 - 通常の攻撃パターンにマッチするものがない場合に検知。

14 - 重要なセキュリティイベント。
これを検知したほとんどの場合、攻撃を受けた可能性がある。

15 - 致命的な攻撃。ただちに対応が必要。

-SKILL, CentOS
-,

Copyright© SCRAMBLE , 2019 All Rights Reserved.