makoto_fujimotoのblog

株式会社進角
代表 藤本信のブログです
どうぞよろしくお願いします

カテゴリ : サーバー

「JINS ONLINE SHOP」個人情報流出の件

先週末3/14、JINSというメガネ屋さんのECサイトが不正アクセスに合っていたことが発覚し、12,036 件のクレジットカード情報が流出する事件あった模様です。セキュリティコードまで盗まれたことで注目を浴びています。
http://www.jins-jp.com/
http://www.jins-jp.com/info.pdf
http://www.jins-jp.com/info20130315-1600.pdf

当初は頻発しているSQLインジェクションを用いたデータベース流出が疑われ「そもそも何でセキュリティコードなんか記録する必要があるんだ?」という意見も飛び交いましたが、その後の調査で支払い方法入力画面のプログラムを改竄し、入力内容を第三者のサーバに送信されていたことが判明したようです。

つまり、何らかのミドルウェア層の脆弱性をつき、任意のコードを実行して決済部分のプログラムを書き換えられてしまった可能性があります。

現時点でここまで深刻な脆弱性を内包してるソリューションはJavaが真っ先に挙げられます。年明けくらいから相次いで未解決の脆弱性が指摘され、Oracle社は現在でも連日アップデートに追われている様子です。
http://jvn.jp/cert/JVNTA13-064A/

このJINSサイトがJavaソリューション(Tomcat/JRE/JDK等)を使用しているか否かについては、公開されている情報だけでは分からなかったのですが、ベンダー情報なども絡めると使用している可能性が高いと私は推測しています。

以下は私の想定シナリオです。

<潜在リスク>
1. 脆弱性のあるJavaを使用していた
2. サーバから外部へのデータ送信が可能になっていた(Firewallが未設定)

<犯行手口>
1. まず踏み台となるサーバを乗っ取り
2. 盗んだ個人情報を送るデータベースサーバを乗っ取り
3. 踏み台サーバからECサイトにjavaの脆弱性をつくハッキングを行いプログラムを改竄
4. 購入者が入力したカード情報を改竄プログラムでデータベースサーバに送信
5. データベースサーバから個人情報を奪取
6. 証拠隠滅

今回の流出事件がこれまで無かった手法を用いていたようですので、同類の潜在リスクがあるサイトは早急に点検をお勧めします。


次に

3/15、日本国内285件のウェブサイトが「Darkleech Apache Module」マルウェアに感染の件
日本国内の285件ウェブサイトが「Darkleech Apache Module」マルウェアに感染し、もし感染されたサイトをInternet ExplorerブラウザでアクセスしたらBlackholeの感染サイトに転送されてしまいます。転送されたらパソコンにあるPDF/Java/Flash古いバーションの脆弱性を使われて、パソコンがBlackholeで提供されているマルウェアに感染されます、との恐ろしい状況が現状日本に発見いたしました。
http://unixfreaxjp.blogspot.jp/2013/03/ocjp-098-285blackhole-exploit-kit.html

こちらの「Darkleech Apache Module」とJavaの脆弱性について関連性は確かではありませんが、ファイルの改竄によってマルウェアが埋め込まれたことを鑑みると、JINSサイトと同様の脆弱性をつかれた可能性があります。

WebサイトのソリューションにJava(Tomcat/JRE/JDK等)が使用されている場合は念のためご確認ください。


対象となる製品とバージョンは以下の通りです。
- Java SE JDK および JRE 7 Update 15 およびそれ以前
- Java SE JDK および JRE 6 Update 41 およびそれ以前

以前、「VPSを借りたら真っ先にやるべきセキュリティ対策」をブログに書いた通り、新規でVPSサーバを借りた状態では脆弱性があるので、真っ先にセキュリティ設定を行うことが重要です。次にApacheやMySQLなどのミドルウェア設定となりますが、Webサーバは、複数のスタッフや会社がアクセスして共同で開発・運用を行う事が多いので、利便性を高めるにはアカウント設定やディレクトリのパーミション設定等にもひと工夫必要です。

以下に複数の担当者が使用するWebサーバ構築において設定した方が良いことをまとめました。

  1. 共通グループを作成して関係者アカウントを所属させる
    # groupadd workgroup
    # vi  /etc/group
    workgroup:x:600:wuser1, wuser2

  2. FTPを使用する場合、FTPサーバのマスク値を002に設定する
    # vi /etc/vsftpd/vsftpd.conf
    local_umask=022 → 002
    # (vsftpdの再起動)
    FTPでファイルをUPした際パーミションが自動的に664になり、グループでの更新が可能になります。

  3. FTPユーザのアクセス範囲を制限する。
    コンテンツ更新などに限定したアカウントの場合、HTMLが格納されているドキュメントルートより上位のフォルダにアクセスする必要が無い場合はchrootを設定します。
    # vi /etc/vsftpd/vsftpd.conf
    chroot_list_enable=YES
    chroot_list_file=/etc/vsftpd/chroot_list
    # vi /etc/vsftpd/chroot_list
    wuser2 (制限したいアカウント名を列挙)
    # (vsftpdの再起動)
    # vi /etc/passwd
    wuser2:x:602:602::/var/www/html/ir:/bin/bash (IRフォルダしか見えなくなります)

     
  4. 各ユーザの.bashrcファイルにマスク値を設定する
    # cd ~wuser1
    # vi .bashrc
    umask 002
    SSHでログインしてファイルを作成した際、グループでの更新可能なパーミションになります。

  5. ドキュメントルートフォルダのグループ設定
    # cd /var/www
    # chgrp workgroup html
    グループ所属ユーザによるファイル更新を可能にします。

  6. ドキュメントルートフォルダのパーミション設定
    # cd /var/www
    # chmod 2775 html
    ファイルやフォルダを作成した際にグループが自動的に継承されるようになります。

  7. MT(MovableType)への配慮
    CMSとしてMTが使用されるケースが多くありますが、生成されるHTMLのファイル権限はWebサーバを実行している"apache"になります。その為、apacheユーザによるファイル操作を許可するため、強引にパーミションを777にしたり666にしている運用が多いようですが、あまり安全な状態とは言えません。そこでapacheユーザを共通グループに所属させることによってファイル更新が可能になると思います。
    # vi /etc/group
    workgroup:x:500:wuser1, wuser2, apache

Webサイトがハッカーによって不正アクセスされ、サービス妨害や改ざんや情報漏洩する事件が毎日のように発生しています。ソフトウェアに脆弱性が見つかると比較的にすぐに対策版が公開されますが、IT業者に運用を委託していても、なかなか能動的にソフトウェアのアップデートを行ってくれず(契約にもよりますが)、脆弱性が放置され、結果的に一般的に知られた攻撃手法でサービス被害を受けることあります。

ソフトウェア開発を委託してそのまま運用に移行した場合や、レンタルサーバの契約をした場合、依頼者側の心理としては、セキュリティ対策を「やってくれているんじゃないの?」「これだけ不正アクセスが多いんだからやってくれて当然でしょ?」と期待してしまうようです。

しかし、リアルの世界で考えると、例えばマンションの鍵や防犯設備について、管理会社がピッキングを始めとする最新のセキュリティ対策を適宜採ってくれて、万が一の際には保障してくれる、などと期待することはまずありませんよね?もし防犯や防災を強化したければ専門の業者に自己負担で依頼し、万が一の損害を担保するのは保険会社の領域という社会的コンセンサスがあります。

したがって、ITソリューションに対してだけセキュリティ対策を「やってくれている」と期待するのは早計だと思います(契約にもよりますが)。また「注意喚起くらいしてくれてもいいじゃないか」と期待したいところですが、個々の企業のホスピタリティのレベルであって前提とするには危険です。

セキュリティ対策については契約書や約款に謳われている場合も多いのですが、基本的に不確定要素の多いセキュリティやハードウェア故障に伴う損害については、逆にありとあらゆる可能性が免責事項として記載されています。セキュリティに関しては、いかなる大手IT業者でもテロ攻撃や暴動などと同様に、無限のリスクがある責任を保証することは不可能なので、具体的に明示されていない場合すらあります。

ここまで主に依頼者側の意識の整理をしましたが、次にIT業者がソフトウェアのアップデートを積極的にワークできないと思われる理由を挙げてみます。

  1. セキュリティ対策の責任とコストについて顧客と業者間でコンセンサスが取れていない。
  2. サーバソフトウェアのバージョンアップを行うとWebサービスに不具合が生じる可能性がある。
  3. サーバソフトウェアのバージョンアップに伴う作業が非常にデリケートでサービス停止のリスクがある。
  4. サーバ運用を担当している業者とWebサービスを開発している業者が異なり責任を負えない。
  5. サーバソフトウェアのバージョンアップを実施する前にWebサービスの十分な動作検証が必要。
  6. そもそも脆弱性の発端は不正アクセス手法を考え出した犯罪者なので、そのコスト負担に疑問がある。
  7. 常時告知されるセキュリティ喚起情報を収集し、脆弱性がWebサービスに及ぼす影響を調査するコストが高い。
  8. "敵"の概念が希薄で性善説を前提とする民族的な習性がハッキング行為をイメージできない。

サーバ運用担当者は常日頃からサービスの永続性の確保について大変なプレッシャーの中で仕事をしています。したがって、安定稼働しているシステムに手を加えることを嫌がりますし、そのように教育を受けている場合もあります。良く言えばお客様のサービスが停止することを懸念して積極的なアップデートを推奨しません。悪く言えばリスクにコミットするのが面倒ということでしょうか。

ちなみに最大手のG社においてもセキュリティ情報の喚起は行いますが、アップデートを「やってくれる」ということは無いようです。

もしかしたら、依頼者様の立場からすると「そんなのお前らプロの責任だろ!」「契約をちゃんと守れ!」の一言で片付けられていまう事かもしれませんが、過去にサーバ運用ビジネスをしていたことがある私の経験から、身勝手ながらこの様な心理状況があることがある、ということを包括的なITリスク管理を担当する方などに参考程度にしていただければ幸いです。

現在利用しているISPが提供するホスティングやサービス面に不満があって、新たなISPに引っ越しすることは良くありますが、移行手順や設定に問題があると長時間にわたりメールが使えなくなったり、 ホームページが閲覧できなくなり、業務に支障が出ることがあります。

サーバを引っ越しすることで、OSを始めとするミドルウェアの環境が変わり、アプリケーションすなわちコンテンツやプログラムの互換性問題が起きる可能性があることは周知されていますが、引っ越しに伴うドメイン管理やネームサーバ管理の移行については少しおざなりにされがちです。また引っ越し期間中は費用も新旧重複してかかりますので、なるべく短期間に済ませたいものです。

弊社ではたびたびサーバの引っ越しを業務として請け負っておりますが、以下の手順を基本とすることでサーバ引っ越しに伴う問題を軽減することができます。

与件例
・W社のVPSからS社のVPSにサーバを移管する
・ドメイン管理業者(レジストラ)も移管したい
・上記に伴いネームサーバ(DNS)の移管が必要


(1)
現状のISP(プロバイダ)への解約通知

ISPサービスの解約は約款上1ヶ月から数ヶ月前の通知が必要とされていることが多いので、サーバの引っ越しが決定したら、まず真っ先に実施したいタスクです。

(2)
ドメインの管理業者(レジストラ)移管
レンタルサーバ契約とドメイン管理サービスがセットになっていて解約を余儀なくされたり、移管作業をスムースに行うために任意のタイミングでWhois情報を書き換える必要があります。したがってコントロールパネルでドメイン情報の管理が容易に行えるドメイン管理業者へ移管することをお勧めします。経験的にはISPやホスティング系よりドメイン登録に特化したサービス業者をお勧めします。この時点で気を付けたいのは、レジストラ移管が済むまでWhois情報のネームサーバは書き換えを行わないことです。

(3) 新DNSの設定
私の経験上、Webやメールのサービスを行うサーバとネームサーバ(DNS)は共存しないことを推奨しています(危機意識の低いDNS構成)。なお上記の移管先レジストラの選定条件として、DNSサービスがセットになっているサービスをお勧めします。それを前提として新たなDNSの設定ですが、ゾーン情報に定義するIPアドレスはNSを除き、現行サーバを指したままとしてください。NSにはこのレジストラが提供するDNSサービスのホスト名を定義しておきます。またDNSのIPアドレス書き換えに備えてTTLを少し短めにしておくとよいでしょう(3600以下)。

(4) ネームサーバの切替え
新レジストラのドメイン情報管理画面でwhois情報のネームサーバの書き換えを行います。ネームサーバには(3)で記述したNSのホスト名をプライマリとセカンダリともに指定します。この作業を行うことで当該ドメインのネームサーバが新しく設定した方に切り替わります。このWhois情報の書き換えがインターネット全体に波及するには1~2日かかるようです。

(5) レンタルサーバの申込み
最近のレンタルサーバはオンライン上での申込みから利用開始までに、当日中や一両日中に設定が完了することが多いので、あまり契約を急ぐ必要はありません。早く契約してしまうとそれだけ現行サーバとの重複期間が長くなり料金が無駄になります。なお専用サーバでも概ね1週間以内程度で利用できるかと思います。

(6) レンタルサーバの設定
詳細はケースバイケースなので割愛します。
 

(7) アプリケーション(サイト)の移設・動作検証
詳細はケースバイケースなので割愛します。この段階ではDNSがまだ現行サーバに向いていますが、PCのhostsファイルを記述して新サーバのIPアドレスに強制的に書き換えを行うことで、本番に近いテストが可能です。
 

(8) サーバへIPアドレスを切り替え

十分なテストを行ったのち、いよいよ新サーバへIPアドレスを切り替えます。(3)でDNSのTTLを短縮してあれば、比較的すぐに新しいサーバへのアクセスが出来ると思われます。ちなみに慎重を期すならば、サーバ切替直後はサービス公開を関係者のみに限定し、最終チェックを行ったのちに一般公開するのが安全ですね。

ネット選挙とは選挙活動をインターネットを中心として行う行為で、わが国でも2月か3月にも改正案が国会に提出され、今年の夏の参院選挙で本格導入の見込みです。

先の衆院選でもソーシャルメディアを中心として、実質的にネット選挙活動に近いものが行われ、法的にグレー状態のサイトや発信行為もあったようですが、結果的にお咎めは無かった様ですね。

しかし、政党などが特設サイトを公開し、有権者へのアンケート結果を即時公開する様なサイトがいくつかありましたが、サーバやドメインの名義そして不正アクセス防止策に不備があって、政党の主義主張や民意を公平にコミュニケートするには問題があったサーバシステムもありました。

特に、アンケート結果が即時ページ反映されるような仕様のサイトが"炎上状態"となり、"魚拓"が取られ、運営側の訂正対応とイタチごっこになっている様を目撃し、支持率低下への逆効果になったのではと心配になりました。

そこで、今後ネット選挙活動が主流になることを鑑みて、インフラソリューションを提供する弊社の立場として、国政選挙におけるネット選挙用サーバに求められる要件を勝手ながら考えてみました。

(1) .jpあるいは*.jpドメインを使用する
日本国の国政選挙ですから。ネットビジネスに良く利用される.comドメインなどはふさわしくないと思います。

(2) ドメイン名義を政党や立候補者の代表として公開情報とする
ドメインのwhois情報を確認すると名義が匿名になっていたり、広告代理店やシステム会社になっていることがありますが、情報発信の主体となるドメイン名義は責任ある為政者の長になっているべきだと思います。

(3) SSLサーバ証明書の名義は政党や立候補者とする
SSLは通信暗号化の他に、サーバ証明書が「このサーバは公的証明機関の証明によって、間違いなく登録名義の組織が運営している」ということを示す証となりますので、ドメイン同様に代行業者や第三者を代理名義にすることは本末転倒だと思います。

(4) 情報・コンテンツの通信はすべて暗号化(HTTPS)方式とする
ユーザが非暗号化のHTTPでアクセスした場合でも、サーバ側で自動的にHTTPSにプロトコルを変更することができます。送受信の通信すべてを暗号化することで組織の情報管理の信頼性が向上します。

(5) メールを配信する場合は証明書付とする
インターネットメールは簡単に成りすましが可能で、フィッシングサイトへ誘導される危険性もあるので、証明書(デジタル署名)を付与して送信したほうがよいでしょう。

(6) サーバは国内法人のサービスを使用し、データセンターも国内立地を条件とする
昨今の国政選挙における主義主張の中心となるのは国内経済が第一に挙げられると思います。したがってインフラにも国内IT企業を積極的に使用して経済に貢献している方がつじつまが合うのではないでしょうか。また情報保全の点でも日本国の法律が適用される国内データセンターを利用すべきだと思います。

(7) アクセス可能なIPアドレスは日本国限定とする
ハッキング行為の9割以上は海外のIPアドレスからもたらされる現状と、情報内容と対象者が日本国籍を持つものに限られるので、思い切って国内IPアドレスからのアクセスに限定しても良いと思います。なお在海外邦人向けには登録制のプロキシサーバを提供することで対応できます。

(8) ユーザからアンケートや意見を受ける場合はIPアドレスによる重複制限を行う仕様とする
インターネットで不正な操作を行い重複投票などを行う行為がよく問題になります。しかしそれを防ぐことが技術に難しく、ユーザ側の手間を必要とする場合もあるので、IPアドレスによる重複排除を行っても支障はないのではないでしょうか。複数名でIPアドレスを共有する会社などからは一人しか意見を発信できなくなりますが、家庭のPCからは概ね個人個人の意見を発信できると思います。
参考「炎上しないネット投票システム


まとめますと、ポイントになるのは「誰が」「どんな情報を」「どれくらい」といった情報の正確性をより担保・証明できるようなサーバシステムが求められるのではないでしょうか。

なお一般的なインターネットセキュリティ対策が取られていることは前提となりますので今回は割愛させていただきました。

また気が付いたことがあったら加筆します。

Windows系VPSサーバのレンタルサービスを行っているところは あまり多くないのですが以下のようなものがあるようです。

使えるねっと
http://www.tsukaeru.net/smb/vps/
シルバー 1,880円~ (Windows Server 2008R2)

GMOクラウドVPS
http://vps.gmocloud.com/service/
スモール 2,980円~ (Windows Server 2008R2)

ちなみに主要各社の調査状況

CPI :なし
ファーストサーバ:なし
お名前.com :なし
GMO(旧アイル) :なし
さくら :なし
ビットアイル :なし

某社の大規模データ消失障害における世間の反応を観察していると、いわゆるサーバのデータバックアップについて少し誤解があるようなので整理してみます。

レンタルサーバや各種クラウドサービスやホームページ運用を業者に委託している場合「バックアップって取ってくれてるんじゃないの?」「専門業者なんだから当然でしょ?」と漠然と思われていることが多いのではないでしょうか。

これは情報保全の点では過信しすぎと言わざるを得ません。

ちなみにバックアップと言っても以下の様にいろいろな方式や考えがあります。

RAIDディスク
これはHDDが物理的に故障した際に備えてディスクを冗長化したシステムです。つまりハード故障に備えたもので、人為的ミスやプログラムミスによるデータ毀損はカバーできません。

ローカルバックアップ
これは稼働しているサーバ内のある領域に対象となるフォルダ等を世代バックアップするものです。サーバが同じなのでHDDが飛んでしまったらバックアップも失われることになります。

媒体バックアップ
これは大昔から行われている方式で磁気テープや光磁気ディスクが有名です。記録装置が機械式なので比較的高価となりメディアの交換・保管コストもかかります。最近ではHDDの低価格化とデータ取り扱いの容易さから大容量ストレージを記録媒体とすることが多くなっています。昨今のレンタルサーバやクラウドサービスのバックアップサービスはこの様なストレージを容量制限つきで共有している場合が多いと思います。

FTシステム(あるいはホットスタンバイ)
フォールトトレラントと言いますが、一部のシステムが故障しても自動的に冗長化された機器やソフトウェアの切替が行われ、サービスの継続性を高めた仕組みです。高度な技術が用いられてる為、2重化としてもシステムコストは2倍ではなく5倍以上などと高価になります。非常に難しい仕組みの為、しばし最大手が構築したシステムでも思うように動作しないことがあるようです。

コールドスタンバイ
ハード故障が発生した場合、交換機の調達には何日もかかる場合があるのであらかじめ予備機を用意しておき、いざ故障が発生した場合に速やかにセットアップを行ってサービスを回復させる方式です。その名の通り平時は予備機に電源を入れていない場合もあります。

いずれにしてもバックアップには追加コストがかかりますので、契約上オプション扱いになっている場合が多く、導入時に額面の安さにつられて契約しても適用外になったままの可能性があります。そのうえ全てのISP業者においてデータの毀損やサービスにおける二次損害については保証の対象外となっているはずです(但し重過失をのぞく)。したがってバックアップ方式においてもハード故障または人為ミスのいずれか一方にしか対応できない不充分な仕様になっていないか確認が必要です。

あと冒頭の「取ってくれてるんじゃないの?」という期待ですが、業者によっては自分達の運用上の瑕疵や品質を問われるハード故障、さらにはお客様の人為的ミスで泣きつかれた場合に備えて非公式にバックアップを取っているケースがあるかもしれせん。これはとらえ方によっては個人情報を含む機密情報の無断複製にあたるといえなくもないですが、有事の際には救いになる可能性もありますね。

某VPSをとことん利用してみて気になった問題点を上げてみました。

  1. 1契約1ドメインの制約があってWebサーバの並列構成やWebとMailサーバ等を分けることが実質不可能。
  2. VPS用DNSには契約サーバに割り当てられているIPアドレス以外のレコードを記述できない。
  3. VPS用DNSにAレコードしか記述できないしTTLも変更不可能。
  4. DNSに他のDNSを使用するとSSLオプションなどの手続きが出来ない。
  5. VPS用DNSにデフォルトで設定されるレコードの内容が確認できない。
  6. SSL申込み時の承認メールが"webmaster@ドメイン"ではなく"webmaster@コモンネーム"に送信される。しかもその旨を申込みの後に通達してきたにも関わらず、直後に承認メールを送信してくるので準備が間に合わずメールを取りこぼしてしまう可能性がある。
  7. SSLオプションを依頼するとconfファイルがデフォルト状態に設定されてしまう(既存設定は引き継がれない)。
  8. SSLオプション適用の為にFTPのアクセス解放が必要になる。あとhtaccess等での認証も解除する必要がある。
  9. 他のVPSと共有しているハードウェアメモリ領域が不足すると勝手にプロセスが終了されることがある。
  10. ファイルシステムに仮想メモリ領域が無いので過負荷時は前項のプロセス自滅が発生する。

あ、ちなみに月額分の仕事は十分してくれていることは付け加えておきます。

grepコマンドは検索対象にパーティションデバイスを指定できるので、消してしまったファイルに含まれるキーワードをヒントとして部分的なデータのサルベージに利用できることがあります。

<コマンド例>
grep -a -B1 -A100000 "CREATE DATABASE faceback" /dev/sda13 > o &

この例は誤って消してしまったデータベースのダンプデータからデータを復元するコマンドになります(ただしテキストファイルに限ります)。

つまり単純にファイルを削除しただけでは、この様に簡単なコマンドでデータを復元できる可能性が残っているのです。

だから、逆に個人情報などを記録していたHDDを完全に削除するには再物理フォーマットくらいしないと心配です。ちなみに僕の運用チームではサーバ廃棄を行う際には必ずルーチーンとして実施させていました。

このページのトップヘ