以前、サーバの安全なお引越しでサーバを移設する際の手順について書きましたが、実際の作業でコンテンツ・アプリケーションやミドルウェアの動作確認を重点的に行うのは当然として、意外と見落としがちなチェックポイントがあるのでまとめてみました。

1. cron設定
   運用関連の処理でバッチプログラムが淡々と仕事をしているかもしれませんので、/etc/cron.*や/var/spool/cronフォルダに入っているユーザアカウントの設定ファイルを確認してください。ここで実行されているスクリプトなども移設が必要な場合があります。なおユーザアカウントを削除するとcron設定も消えてしまうので注意が必要です。
   
   
2. ホームディレクトリは安易に消さない
   サーバ移設の機会に、不要なユーザアカウントを整理することがあります。しかし安易にユーザアカウントをホームディレクトリごと消去してしまうと、旧担当者が管理していた重要なファイルを消してしまう可能性があります。
   
   
3. セキュリティ設定の引き継ぎ
   参考: VPSを借りたら真っ先にやるべきセキュリティ対策
   参考: VPSのファイアウォール設定について(iptablesの例)
   
   
4. ログローテーション設定
   /etc/logrotate.d
   ログの記録方式をカスタマイズしている可能性があります。
   
   
5. メールエイリアス
   /etc/aliases
   root宛てのメールなどを管理者宛てに転送設定している場合があります。
   
   
6. ドメイン管理者情報の更新
   サーバ管理とともにドメイン管理も業者に一元管理させていた場合、管理者情報等の変更や管理アカウント権限の移譲を行っていないと、有効期限通知メールなどが届かずに、最悪失効してWebサービスが停止してしまう可能性があります。またネームサーバについても管理責任の帰属先を確認しておいた方が良いです。
   
   
7. プログラムからの通知メール等
   お問合せフォームや各種ユーザ操作の動作確認などで、運用担当者宛てにメールが通知される仕様になっているシステムが良くあります。送信の有無と宛先が適切か確認しましょう。ログから確認する場合は/var/log/maillogが参考になります。
   

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

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

(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からは概ね個人個人の意見を発信できると思います。
参考「炎上しないネット投票システム」


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

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

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