Japan

サイト内の現在位置を表示しています。

InfoCage SiteShell

SiteShell News バックナンバー

このページでは、今注目されているセキュリティ関連情報やInfoCage SiteShellの新バージョンの機能紹介や便利な使い方などを定期的に公開していきます。

【トピックス】クラウド環境におけるWebサイトのセキュリティ対策(2014/8/1)

今回は、利用が増えてきているクラウド環境で必要なセキュリティ対策について説明していきます。

クラウド環境の場合、ネットワーク層までのセキュリティ対策はIaaS事業者からサービスとして提供されるため、利用者はOS/ミドルウェア層以上のセキュリティ対策に注力することができます。

上図のようにOS、ミドルウェア、アプリケーション層のセキュリティ対策は利用者の責任において実施する必要があります。ここでは、アプリケーションのセキュア開発と、ソフトウェア型のセキュリティ製品の組み合わせで対策を行います。クラウド環境という特性上、HW機器を持ち込むことができないため、ソフトウェアの製品から選択する必要があります。

また、クラウド環境に対応したソフトウェアのセキュリティ製品を選択することが重要です。クラウド環境では、クラウド特有の機能があり、その機能に対応していない製品を使用すると、運用が大変になったり、非常にコストが掛かってしまう場合があるためです。

【クラウド環境ならではの検討のポイント】
  (1)オーストケール機能
  (2)従量課金
  (3)IaaS事業者が提供する運用監視サービスとの連携

InfoCage SiteShellはこれらのクラウド特有の機能に対応したソフトウェア型のWebアプリケーションファイアウォールです。

(1)オートスケール機能

オートスケールとは、しきい値を設定しその値を元にあらかじめ作成したマシンイメージから自動でサーバを追加/削除する機能です。
Webシステムの場合、このオートスケール機能を使用する場合が多いです。しかし、この機能に対応していない場合、「増加したサーバを管理できない」「増加したサーバにソフトウェアをインストールする必要がある」「増加するサーバのライセンス管理ができない」などの課題があります。
しかし、InfoCage SiteShellの場合はオートスケール機能に対応しているため、事前にInfoCage SiteShellを導入したサーバイメージを作成することで、オートスケールで増加したサーバにはInfoCage SiteShellが導入された状態で起動します。また、運用管理コンソールは増加したInfoCage SiteShellを自動で登録しますので、増加したサーバも自動で管理します。

(2)従量課金

クラウド環境の場合、サービスの課金方式はほとんどが従量課金方式です。つまり、「使った分」だけ課金が発生します。しかし、ソフトウェアのライセンスは１年間もしくは永続のライセンス形態となります。この場合、サーバライセンスのソフトウェアを使用するときにはオートスケールで増える分のサーバ数分のライセンスを事前に購入する必要があります。この課金方式ですと、1年のうち、1ヶ月だけ10ライセンス必要な場合、1年間10ライセンスを購入する必要があります。
InfoCage SiteShellは月額ライセンスを提供しています。そのため、使った分を翌月にお支払いする形となりますので、よりクラウド環境の従量課金に近い課金方式をとることができます。


(3)IaaS事業者が提供する運用監視サービスとの連携

クラウド環境の場合、IaaS事業者が提供する運用監視サービスを利用し、日々のサーバの状態を監視することがあります。
サーバの状態はIaaS事業者が提供する運用監視サービスを利用しますが、ソフトウェアの状態についてはそのソフトウェア専用の監視ツールがあります。そのため、運用者は毎日、運用監視サービスも確認し、ソフトウェアの監視ツールも確認する必要があり、システム全体として、運用管理が一本化できません。
InfoCage SiteShellでは、攻撃状況を運用監視サービスと連携し確認することができます。そのため、システムのリソース監視と攻撃の監視が同じ運用で行うことができます。

InfoCage SiteShellのIaaS環境における導入事例を紹介します。

【IaaS環境におけるInfoCage SiteShellの導入事例】

◆導入の背景

  • 通販サイトの運用コストが年々増大しておりクラウド移行を決意。
  • クラウド環境においても顧客情報を守る必要があるが、既存システムはHW型WAFを利用しており、そのままIaaS環境では利用できない。
◆選定の理由
  • ソフトウェア型のWAFとして広範な実績があり、IaaS環境にもマッチ。
  • 業務量の変化により、サーバ数が増減する場合でも、特別な設定なしに増減に連動してWAF機能が利用可能。
◆導入の効果
  • 業務量に応じて自動的にサーバ数を増減できるようになり、運用の手間とコストの両方を削減。
  • セキュリティレベルを下げることなくサーバ30台をIaaS環境に移行。

InfoCage SiteShellは国内の主要IaaS基盤で動作確認を行っておりますので、IaaS環境においてもInfoCage SiteShellをぜひご活用ください。

【ケーススタディ】SiteShellによるパスワードリスト攻撃対策(2014/6/18)

SiteShellは、6月初めにパスワードリスト攻撃に対応した新バージョンをリリースしました。
このSiteShell Newsでも過去に何回か話題にしていますが、簡単にパスワードリスト攻撃について説明します。

【パスワードリスト攻撃】
悪意のある者が、なんらかの方法で入手したID、パスワードのリストを様々なサイトでログインを試みる手法です。
ID、パスワードを使いまわしている利用者が多いという状況に目を付けた攻撃手法です。

この攻撃の対策ですが、ID、パスワードの他にもう一つの認証要素を付加する2要素認証や他のサイトと同じIDとパスワードの組み合わせにしないよう呼びかけるなどがありますが、いずれもWebサイトを修正する必要があり、非常にコストが掛かります。

【SiteShellによる対策】
SiteShellの新バージョンを利用することで、このパスワードリスト攻撃の被害を軽減することができます。今回は、SiteShellによるパスワードリスト攻撃の対策方法を紹介いたします。

SiteShellによるパスワードリスト攻撃対策は以下の手順になります。


  1. IPブラックリスト機能を有効化。
  2. ユーザルール定義により攻撃の兆候となる条件を設定。
  3. パスワードリスト攻撃と判断する基準の値を設定。

【今回設定するサンプルルールの設定条件】

ログイン画面(/login.html)でログイン失敗を1分間に5回以上行ったIPアドレスからのアクセスを自動的に拒否するように設定する。
その後3分経過後にそのIPアドレスからアクセスできるようにする。


順番に説明していきます。
※本手順では、簡単のために確認画面などは省略しています。

1．IPブラックリスト機能の有効化
IPブラックリスト機能の有効化は以下の手順で行います。

【IPブラックリスト機能の有効化】
IPブラックリストに登録された際にそのIPアドレスからのアクセスを拒否するためのスイッチをONにする。

①運用管理コンソールにログインします。
②対象のノード(またはグループ)を選択し、「ノード設定(対策)」のタブをクリックします。
③カテゴリから「IPブラックリスト」を選択します。

【各属性の意味と入力例】

  • ipbl.default
    • 意味：自動生成されたIPブラックリストに対する、デフォルト対処動作を指定します。
    • 入力：deny
  • ipbl.frequency
    • 意味：IPブラックリストに追加するか否かを判断するための基準の値を指定します。
    • 入力：(空欄)
  • processor.ipbl
    • 意味：IPブラックリスト自動生成、及び防御機能の有効/無効を指定します。
    • 入力：ON

④「processor.ipbl」のプロパティ値を「ON」に設定します。

⑤変更後、「適用」をクリックします。

2．ユーザルール定義により攻撃の兆候となる条件を設定

続いて、パスワードリスト攻撃の兆候となる条件を設定します。
ここでは、以下のようなルールを作成します。

【作成するユーザルール定義】
ログイン画面(/login.html)に対してuseridというパラメータが含まれるリクエストがあり、かつそのリクエストに対するレスポンスのheaderに「Location:main」が含まれていない場合に攻撃の兆候としてカウントする。
正常にログインした場合にはheaderのLocationにmainという文字列が含まれるページが返ってくるため、含まれていない場合をログイン失敗とみなす。

①対象のノード(またはグループ)を選択し、「ユーザルール定義」のタブをクリックします。
②「レシピ追加」をクリックします。
③以下のような画面が表示されますのでそれぞれの属性を以下のように入力します。

【各属性の意味と入力例】

  • Recipe Name
    • 意味：レシピの名前(ユーザにて管理しやすい任意の名前)
    • 入力例：PW_LIST
  • Attack Type
    • 意味：攻撃の種別(パスワードリスト攻撃の場合は固定)
    • 入力：PasswordList
  • Path
    • 意味：このレシピを適用するリクエストパス。パスワードリスト攻撃の場合はログイン処理が行われるページを指定。
    • 入力例：^/login
  • Description
    • 意味：レシピの説明
    • 入力例：PW_LIST

④「ルールセット追加」をクリックします。
⑤以下のような画面が表示されますので、それぞれの属性を以下のように入力します。
   「ルール追加」ボタンをクリックし、ルールを追加します。

【各属性の意味と入力例】

  • RuleSet Name
    • 意味：ルールセットの名前。
    • 入力例：PW_LIST
  • Stage
    • 意味：ルールセットの処理対象
    • 入力例：both
  • Content Type
    • 意味：ルールセットの処理対象とするContent Type。
    • 入力例：^.*$
  • Condition
    • 意味：本ルールセット内で指定するルール要素間の関係
    • 入力例：and
  • Action Name
    • 意味：本ルールセットにマッチした際の対処動作。パスワードリスト攻撃の場合、countを指定する。
    • 入力例：count
  • Action Arg
    • 意味： 「Action Name」で「forward」を選択した場合、遷移先のurl を「～.html」の形式で指定する。パスワードリスト攻撃の場合、actionを指定する。
    • 入力例：action
  • ルール①：リクエストのuseridというパラメータにいかなる値であろうとルールにマッチさせ、真偽値をtrueにする。
  • Operator
    • 意味：ルールの正規表現式マッチの真偽判定
    • 入力例：regex (部分一致でマッチする場合、本ルールの判断結果をtrue とする)
  • Rule Arg
    • 意味：ルールのチェックするパラメータ名を指定する。ここでは、「userid」というパラメータを指定する。
    • 入力例：paramValues[userid]
  • Rule Value
    • 意味：チェックする値。ここでは、「userid」にいかなる値が来てもルールにマッチさせるため、以下の文字列を指定する。
    • 入力例：^.*$
  • Decode
    • 意味 「Rule Value」で指定した値をチェックする前のデコード処理
  • Charset
    • 意味：「Decode」属性において「M(マルチバイト除去)」を実施する際の文字コードを指定。省略時は、マルチバイト除去を行わない。
  • ルール②：レスポンスヘッダーのLocationにmainという文字列が含まれている場合にマッチさせ、真偽値をfalseとする。
  • Operator
    • 意味：ルールの正規表現式マッチの真偽判定
    • 入力例：nregex (部分一致でマッチする場合、本ルールの判断結果をfalse とする)
  • Rule Arg
    • 意味：レスポンスヘッダーのLocationを指定する。
    • 入力例：respheaders[Location]
  • Rule Value
    • 意味：Locationにmainという文字列が含まれる場合とするため以下の文字列を指定する。
    • 入力例：main

⑥「追加」をクリックし、その後の画面で「適用」をクリックします。

3．パスワードリスト攻撃と判断する基準の値を設定

続いて、パスワードリスト攻撃と判断する基準の値を設定します。
【パスワードリスト攻撃の基準値】
2で作成したユーザルール定義にマッチした数がここで指定した値を超えた場合に、IPブラックリストに攻撃元のIPアドレスが自動的に追加される。
追加された攻撃元IPアドレスが指定した時間でIPブラックリストから削除される指定を行う。

①対象のノード(またはグループ)を選択し、「ノード設定(対策)」のタブをクリックします。
②カテゴリから「パスワードリスト対策」を選択します。

【各属性の意味と入力例】

  • pl.frequency
    • 意味：IPブラックリストに追加する閾値を指定します。
    • 入力例：5/60
  • pl.release.time
    • 意味：IPブラックリストに登録された攻撃元IPアドレスを自動的に解除する条件（秒）を指定します
    • 入力：180

③「変更」をクリックし、各属性のプロパティ値に上記の設定を行い、「適用」をクリックします。
④最後に、Webサーバを再起動すれば、設定は完了です。

【動作確認】
Webサーバのログイン画面にて、ログインエラーを60秒間に5回以上失敗し、その次のアクセスがエラーページ「SiteShellError.html」への画面遷移が確認できれば正しく設定が行われています。

このように、InfoCage SiteShellを使用することで、パスワードリスト攻撃からWebシステムを防御することができます。システムへの変更が難しい場合など、InfoCage SiteShellを使用しいち早く防御措置を行うことができますので、ぜひご活用ください。

【ケーススタディ】SiteShellによるApache Struts2の脆弱性対策(2014/5/21)

SiteShellは、自動更新にて提供されるブラックリストに既知の攻撃パターンが多数登録されており、様々なアプリケーション脆弱性攻撃への対応が可能です。
さらに、ブラックリストに登録されていない最新の攻撃に対しても、ユーザルール定義を作成することにより、迅速な対応が可能です。

今回は、最近流行しているApache  Struts2の脆弱性攻撃への対策を例にとり、SiteShellのユーザルール定義の作成方法を紹介いたします。
※関連情報：Apache Struts 2の脆弱性(S2-020)に関するInfoCage SiteShellの対応について
※2014年12月追記: 最新の脆弱性対策パッケージはこの内容を含むため、ユーザルールを作成する必要はありません。

【SiteShell ユーザルール定義とは】

ユーザが個別に設定する、防御設定です。例えば、ブラックリストには載っていない特定の文字列を攻撃とみなしたり、特定のフィールドへの入力を制限するなどの定義が可能です。
この定義はSiteShellのインストールフォルダ配下に設置された「ユーザルール定義ファイル」に保存され、SiteShellの管理用ツール(運用管理コンソール)から追加/変更することが可能です。

【ユーザルール定義の設定方法 ～Apache Struts2脆弱性対策の場合～ 】
SiteShellの運用管理コンソールにログインします。
対象のノード(またはグループ)を選択し、「ユーザルール定義」のタブをクリックします。
「レシピ追加」をクリックします。
※SiteShellでは、ユーザルール定義で作成するひとつひとつの定義のことを「レシピ」と呼びます。
以下のような画面が表示されますので、それぞれの属性を以下のように入力します。

【各属性の意味と入力例】
  • Recipe Name
    • 意味：レシピの名前(ユーザにて管理しやすい任意の名前)
    • 入力例：APACHESTRUTS
  • Attack Type
    • 意味：攻撃の種別(ユーザにて管理しやすい任意の種別)
    • 入力例：USER-0002-02
  • Path
    • 意味：このレシピを適用するリクエストパス
    • 入力例：^.*$
  • Description
    • 意味：レシピの説明
    • 入力例：APACHE STRUTS2 S2-021

5. 「ルールセット追加」をクリックします。
※SiteShellでは、レシピ内の詳細な防御設定(検知文字列の定義等)を「ルールセット」という単位で登録します。
6. 以下のような画面が表示されますので、それぞれの属性を以下のように入力します。

【各属性の意味と入力例】

  • RuleSet Name
    • 意味：ルールセットの名前。省略可
  • Stage
    • 意味：ルールセットの処理対象
    • 入力例：request
  • Content Type
    • 意味：ルールセットの処理対象とするContent Type。 (省略時は「^($|(application/x-www-form-urlencoded|multipart/formdata)($|\s*;))」が指定されたものとして動作する)
  • Condition
    • 意味：本ルールセット内で指定するルール要素間の関係
    • 入力例：or
  • Action Name
    • 意味：本ルールセットにマッチした際の対処動作
    • 入力例：forward
  • Action Arg
    • 意味： 「Action Name」で「forward」を選択した場合、遷移先のurl を「～.html」の形式で指定する
    • 入力例：SiteShellError.html
  • Operator
    • 意味：ルールの正規表現式マッチ判断方法
    • 入力例：regex (部分一致でマッチする場合、本ルールの判断結果をtrue とする)
  • Rule Arg
    • 意味：ルールのチェック対象
    • 入力例：：headers[Cookie],paramNames[*]
  • Rule Value
    • 意味：チェックする値
    • 入力例：(?:^|\W)class\W
  • Decode
    • 意味：「Rule Value」で指定した値をチェックする前のデコード処理
    • 入力例：UI (U：URLデコード、I：小文字化)
  • Charset
    • 意味：「Decode」属性において「M(マルチバイト除去)」を実施する際の文字コードを指定。省略時は、マルチバイト除去を行わない。

7. 「変更」をクリックし、その後の画面で「適用」をクリックすれば、設定は完了です。

【動作確認】
WebブラウザのURL入力欄に以下のように入力します。　
http://(上記設定を行ったWebサイトのURL)?class. 　
※動作確認用のサンプル文字列であり、実際の攻撃文字列とは異なります。

SiteShellの防御動作(上記例の設定であれば、エラーページ「SiteShellError.html 」への画面遷移)が確認できれば、正しく設定が行われています。

このようにSiteShellによって迅速にApache Strutsの脆弱性対策を行うことができます。 Apacheのアップデートや設定変更が、システムによっては困難な場合、SiteShellによる対策は非常に有効です。

次々と新しい脆弱性が発覚し、それを狙った攻撃による被害が多発しています。万一のための予防措置、そしていざというときの迅速な防御対策に、SiteShellをご活用ください。

【トピックス】情報セキュリティEXPOに出展します！(2014/4/25)

5月に開催される第11回情報セキュリティEXPO春に、InfoCage SiteShellを展示します。

情報セキュリティEXPOとは、情報セキュリティ対策のあらゆる製品が一堂に出展する専門展です。NECグループブース内の「NECが実現するエンタープライズセキュリティ」の1製品としてInfoCage SiteShellを展示します。
ショッピングサイトへの攻撃をInfoCage SiteShellで防御するデモのほか、標的型攻撃などのサイバー攻撃に対する総合的なセキュリティ対策についても紹介しています。
また、オープンセミナーも開催しております。

皆様のご来場を心よりお待ちいたしております。

    ＜開催概要＞
  • 展示会名：第11回 情報セキュリティEXPO 春
  • 日時：2014年5月14日（水）～5月16日（金）10:00～18:00　※最終日は、10:00～17:00
  • 場所：東京ビックサイト 東4ホール 　※NECグループブース：東26-1
  • 主催： リード エグジビション ジャパン株式会社
  • 費用：事前登録で無料   ※当日一般受付：5,000円（消費税込み）

  • NECグループブースの詳細はこちら

【トピックス】IPA発表、2014年版 情報セキュリティ10大脅威について(2014/4/16)

2014年も独立行政法人 情報処理推進機構（IPA）から『情報セキュリティ10脅威』が発表されました。

このトップ10は、2013年に発生した情報セキュリティの事故・事件から、特に社会的に影響が大きかったと考えられる項目を情報セキュリティの有識者によってランキングされたものです。
2013年との順位変動とともに今年の10大脅威を見てみましょう。

ここで注目すべきは昨年から大きくランクアップした2位～4位の脅威です。これらの脅威はいずれもウェブサービスやウェブサイトに関連する脅威です。

  • 2位「不正ログイン・不正利用」
    複数のサイトでパスワードを使いまわすことで一つのぜい弱なウェブサイトからパスワード情報が漏えいすると他のウェブサイトで不正にログインができてしまうという脅威です。
    2013年はパスワードリスト攻撃の流行により様々な企業で被害が報告されました。
  • 3位「ウェブサイトの改ざん」
    2013年に飛躍的に増えた脅威の一つです。近年のウェブサイトの改ざんは見た目の変化は無く、ウイルスをダウンロードする攻撃コードが埋め込まれている状態です。
    閲覧したユーザは知らぬ間にウイルス感染してしまいます。
  • 4位「ウェブサービスからのユーザ情報の漏えい」
    オープンソースなどの汎用的なアプリケーションのぜい弱性が狙われることが多く、“Apache Struts 2”のぜい弱性を利用した攻撃はツールが出回ったことにより爆発的に増加しました。

このようにウェブサービスやウェブサイトを狙った攻撃は増加しており、その攻撃の特性上今後も増えていくと考えられます。これらの脅威からウェブサイトを守るにはInfoCage SiteShellが有効です。

ウェブサイト改ざん検知やApache Struts2などのアプリケーションのぜい弱性を狙った攻撃はInfoCage SiteShellを導入することで防御することができます。
パスワードリスト攻撃は2014年6月に対応版をリリース予定です。

InfoCage SiteShellを導入することで、2014年情報セキュリティ10大脅威の上位にランキングしている脅威から自社/お客様システムを守ることができます。この機会にご検討ください。

また、5月に開催される情報セキュリティEXPOに展示します。

【トピックス】OWASP AppSec Apac 2014に出展します！(2014/2/19)

InfoCage SiteShellは3月に開催される、OWASP AppSec Apac 2014に出展いたします。

OWASP AppSec Apac はWebアプリケーションにかかわるソフトウェアの安全性に取り組む人のための国際カンファレンスです。
Training DayとConference Dayに分かれており、SiteShellはConference Dayに出展します。

開催概要

  • OWASP Global AppSec APAC
  • 2014年3月17日から20日まで
  • 東京・お茶の水ソラシティ・カンファレンスセンター
OWASP(正式名称：The Open Web Application Security Project)は、Webアプリケーションセキュリティを取り巻く課題を解決することを目的とする、国際的なオープンなコミュニティです。

このコミュニティは企業や自治体等の組織が直面している重要なWebアプリケーションのセキュリティリスクをTop10として発表しています。このTop10はPCIDSSなど様々なセキュリティ基準の中で条件として用いられています。
InfoCage SiteShellでのOWASP Top 10の対応状況としては、WAFで対応すべき項目についてはすべて対応しています。
OWASP Top 10 for 2013 SiteShell対応状況
ID SiteShell対応状況 概要
2013-A1 ○ インジェクション
2013-A2 ○ 認証とセッション管理の不備
2013-A3 ○ クロスサイトスクリプティング（XSS）
2013-A4 ○ 安全でないオブジェクト直接参照
2013-A5 ○ セキュリティ設定のミス
2013-A6 - 機密データの露出
2013-A7 ○ 機能レベルアクセス制御の欠落
2013-A8 ○ クロスサイトリクエストフォージェリ(CSRF)
2013-A9 ○ 既知の脆弱性を持つコンポーネントの使用
2013-A10 - 未検証のリダイレクトとフォワード
A6とA10はWAFでの対応は難しく、アプリケーション側で対応となります。

Webアプリケーションの開発者は、上記の項目を意識したアプリケーション開発を求められますが、InfoCage SiteShellのようなセキュリティツールをご利用いただくことで、アプリケーションへの依存が低い部分のセキュリティレベルを確保でき、開発者はアプリケーションへの依存が高い項目(A6, A10等)の対策に注力できるようになります。

この手法は、対策の網羅性やシステム保守の観点からとても有効な対策であり、PCIDSSの認定取得している企業でも採用されています。

展示会場ではInfoCage SiteShellのデモをご覧いただけます。ぜひともお越しください。

【トピックス】リスト型アカウントハッキング攻撃について(2014/1/29)

さて、今回のテーマはJNSA 2013セキュリティ十大ニュースの【第5位】アカウントリスト型ハッキングです。

この攻撃は2013年初めに報告され、大手サイトでも被害にあっています。
この攻撃はアカウントリスト型ハッキングやリスト型アカウントハッキング、パスワードリスト攻撃、リスト型攻撃など様々な名称で呼ばれています。

具体的な攻撃方法を説明します。

  1. 攻撃者は、どこか脆弱性のあるサイトからアカウント情報(アカウント名+パスワード)を取得します。
  2. 攻撃者は、取得したアカウント情報を用いて他のサイトにログインを試みます。
  3. ユーザが、他のサイトと同じアカウント名/パスワードを設定している場合は、攻撃者のログイン試行によりログインに成功してしまいます。
この攻撃のポイントは、他のサイトと同じアカウント情報を使用するユーザが多いという実態を悪用していることになります。
本来は、登録するサイトごとにアカウント名/パスワードを使い分けることが理想ですが、実際には一つのパスワードを使いまわしているユーザが多いため、この攻撃は成功しやすくなっています。

様々な企業が被害にあっていることから、2013年12月に総務省からも対応方策が公表されました。
「リスト型アカウントハッキングによる不正ログインへの対応方策について(サイト管理者などインターネットサービス事業者向け対策集)」の公表(総務省)

総務省から公表された効果的な対応方策はこちらです。

攻撃を予防する対策

  1. ID・パスワードの使い回しに関する注意喚起の実施
  2. パスワードの有効期間設定
  3. パスワードの履歴の保存
  4. 二要素認証の導入
  5. ID・パスワードの適切な保存
  6. 休眠アカウントの廃止
  7. 推測が容易なパスワードの利用拒否

攻撃による被害の拡大を防ぐ対策

  1. アカウントロックアウト
  2. 特定のIPアドレスからの通信の遮断
  3. 普段とは異なるIPアドレスからの通信の遮断
  4. ログイン履歴の表示
いずれの対策もWebアプリケーションを修正する必要があり、なかなか対策が進んでいないのが現状です。

WAFとしては「2．特定のIPアドレスからの通信の遮断」の対策が可能です。
現在、SiteShellではこの対策でアカウントリスト型ハッキングに対応できるように機能強化しています。
今年の春頃に対応版のリリースを予定しております。ぜひご利用ください。

【トピックス】JNSA 2013 セキュリティ十大ニュースについて(2014/1/15)

日本ネットワークセキュリティ協会(Japan Network Security Association：JNSA)は2013年12月25日に2013年のセキュリティ十大ニュースを公開しました。
　JNSA　セキュリティ十大ニュース
　JNSA　https://www.jnsa.org/active/news10/

2013年も様々なセキュリティニュースがありました。その中でも注目していただきたいのはこちらです。

【第2位】韓国へのサイバーテロ攻撃
【第4位】日本を狙いとした高度な標的型攻撃による被害を確認
【第5位】アカウントリスト型ハッキング
【第6位】Webサイト改ざんの多発


これらはサーバサイドにセキュリティソフトウェアを導入することによって被害を防止/軽減することができます。

今回は第6位の「Webサイト改ざんの多発」の対策について説明します。
Webサイト改ざんの多発は特に2013年上半期に例年に比べ非常に多くの報告があり、JPCERT/CCからも注意喚起(*1)が行われました。

Webサイト改ざん被害にあわないためにはベンダーから提供されるパッチを素早くあてることや、ログインパスワードを定期的に変えるなどの基本的な対策が効果的です。
といっても、現実問題としてシステムへのパッチ適用には時間がかかりますし、パスワードを定期的に変える運用は非常に面倒です。

そこで、改ざんを検知/自動復旧するソフトウェアが注目されています。
SiteShell Web改ざん防止は自動で改ざんを検知/復旧するソフトウェアです。導入することで、人の目では気づきにくいWebサイトの改ざんもいち早く認識し、早期の復旧が可能です。
SiteShell Web改ざん防止の機能詳細はこちらをご覧ください。

多発しているWebサイト改ざんの対策として、ぜひSiteShell Web改ざん防止をご検討ください！

次回は第5位の「アカウントリスト型ハッキング」への対策について説明します。お楽しみに！

(*1) Webサイト改ざんに関する注意喚起
JPCERT/CC　　https://www.jpcert.or.jp/at/2014/at140037.html