ラベル セキュリティ の投稿を表示しています。 すべての投稿を表示
ラベル セキュリティ の投稿を表示しています。 すべての投稿を表示

2013年10月7日月曜日

自治体の Windows XP 搭載 PC について

サポート期限切れが近づいている Windows XP ですが、読売新聞で「XP期限切れ、自治体「攻撃めったにない」」でちょっとセンセーショナルに報道されたせいか、この週末に自治体で使われているPCについてちょっと辛めな反応がブログやtwitter Facebook などで見られました。

特にサポート終了によるセキュリティ上の問題が懸念されていますが、IT というものとどうつきあっていったら良いのかというテーマが内在している問題のように私には思われます。


単に更新すれば良いという問題なのか?


「サポート期限切れのWindows XP を使い続け、更新しないのはケシカラン」と言い切ってしまうのは簡単ですが、自治体のPCをめぐる環境はそれほど簡単な状況ではありません。

そんな様子を垣間見ることができるのが、同じ読売新聞に掲載された「期限切れXP、自治体54%に20万台」の記事に書かれた「 更新できない主な理由」で、以前それぞれの項目についてちょっと考えてみます。

とはいえ、私自身は現在この業種からは遠いところにいて、しかも真面目に裏をとった情報ではなく、その時々での感想や印象などを思い出して書いたのでその辺はご容赦のほどを。もちろん特定の自治体が云々という話でもございません。 妄想程度に読んでいただければ幸いです。


「更新できない主な理由」アラカルト


新しいOSがつかいこなせない


一番皮肉に見えるのはこの項目かもしれません。

端的に言えばPCを使うための研修・教育が継続的に行われていなかったということですが、じゃあ今使っている Windows XP はどうして使えるようになったのかといえば、平成13(2001)年に森内閣「e-Japan戦略」下で行われた「IT講習会」が大きかったように感じます。

丁度 Windows 2000 から Windows XP への移行期に合計550万人が受講したというこの講習会ですが、その後OSの更新時にスキルも更新しなかったケースがあるのではないでしょうか。


予算の6割を地方交付税に頼り、除雪などに使われてしまう


ITに限ったことではないのですが、地方自治体の財政は地方交付税交付金に大きく依存しているのが実情です。ITを使うためには継続的な取り組みが必要ですが、2000年代はこの
分野について先にあげた「e-Japan戦略」でおりてくる補助金に頼っていたケースが多かったように感じています。

当時はいわいる「ミレニアム(千年紀)」を合言葉に様々な政策が出されましたが結局のところ「目新しい補助金」という性格があるものだったような気がします。それなりにIT業界が活発化したので効果はゼロではありませんが、継続的な政策にするのは難しい性格があったのではないでしょうか。

今回の問題にかぎらず、補助金で導入したものをどう更新するのかというのに苦労している団体は多いのではないでしょうか。同じような問題は公立学校に導入されている教育用のPCにおいても直面しているような気がします。


パソコンのリース契約が残っており、中途解約すると清算金が発生する


これも財政がらみの理由ですが、まとまったIT投資をする際には一括で予算を確保して購入することはあまり行われず、リース契約を組むケースが多いです。現在の税法上はPCについては法定耐用年数4年間の 0.7倍以上 1.2倍以内ということで、3年あるいは4年でのリース設定が可能ということになっていますが、私が見てきた中では4年、5年というケースが多く感じていました。

もちろん中途解約すると清算金が発生するという問題もありますし、仮にOSだけを入れ替える場合であっても新しいOSのライセンス費用やOSの入れ替え作業費などは別途措置する必要があります。またシステム更新時期が到来したのだけれども予算の都合上、リース契約を延長するようなケースも存在します。


住民サービスのシステムもXPにしか対応しない。すべて変えるためには莫大(ばくだい)な金がかかる


一番やっかいなものはこの項目かもしれません。先の「e-Japan戦略」を契機に現場にはいろんな箱が増えました。特に大きな影響があったのは全国住基やLGWANですが、これらのインフラを使っているシステムに現場PCのOSの選択は大きく左右されます。使うシステムのどれか1つに「動作環境は Windwos XP」とあれば Windows XP にせざるを得ないのが実情でした(今はどうなのでしょう?)。

Windows XPは、サービスパックをはさみながら、2001年10月のリリースから2014年4月の間実に12年半の長寿OSとなったわけですが、それを前提に作られたシステムのどれだけが新しいOSを対象とできるのでしょうか。これは自治体だけではなくいわいる公官庁公共システム分野のベンダーにも責任の一端がある印象がいたします。


予算要求したが、財政担当に却下された


地方交付税交付金うんぬんのところとも関連しますが、財政が厳しい状況では予算が認められないケースも当然出てくるでしょう。


スキルも機械も最新のものに更新していく努力を


こうして見ていくと中長期的なビションがない状況で一時的な財政措置や政策・施策で投資を行ってきたツケがまわってきた状況のように思います。なんとなく国の政策がマズかったようにも見えますが、短命な政権が相次いだり、2度の政権交代を経験
したのは、ある意味我々国民の選択であるわけで、このあたりを考えると渋い顔をせざるを得ないのかもしれません。

また Microsoftに対して「とても困っているから救済策を」という声もありますが、救済策としてサポート期間が延長された結果が2014年4月までのサポート期間ですからそろそろ腹を決めないといけない時期に来ている感がいたします。そもそもWindows XP から数えて、Vista, 7, 8 ( ともしかしたら 8.1も? ) と、3世代(もしくは4世代)前のOSにサポートを求めるのはさすがに酷な状況ではないでしょうか。

「じゃあ Ubuntu などの Linux を使えばいいの?」と思う方もいるかもしれませんが、結局サポート期間は有限の期間でWindowsやMicrosoftだからどうだということではありまません。なんでもそうですが「時期が来たら買い換える」必要があるし「知識は最新にアップデートする」必要があります。

伊勢神宮の式年遷宮ではありませんが、どう更新し活かしていくのかという視点、目の前のものが恒久的に使えるわけではないという、至極あたりまえの見解に立ち返る必要があるように思います。

2011年9月5日月曜日

Apache の脆弱性、対策しましたか?


先月末に Web サーバ として広く使われている Apache の既存のすべてのバージョンにおいて、深刻な脆弱性をかかえていることが明らかになりました。攻撃を行うための手法はすでに広く流通しており、手元の環境でも検証することができるくらいになっています。

最悪なシチュエーションの妄想


この脆弱性を突かれると Web サーバを沈黙させることができるという状況で Web サイト運営側とすると大きな脅威となっています。最悪のシナリオを考えてみると
  1. 政治問題などで某隣国を刺激してしまう
  2. 日本国内のWebサイトを攻撃する呼びかけが広まる
  3. 自動攻撃ツールに今回の脆弱性への攻撃手法が盛り込まれる
  4. 実際に攻撃が行われ国内の多くのサイトが沈黙してしまう
ということが起こりえる状況です。少なくとも対策が一巡するまでは隣国を刺激して欲しくない(笑)のですが、この blog では「さくらのVPS」でのサーバ構築ノウハウをとりあげたことがありますので、こういった状況が発生したときに、どういった対応をとればいいのかということを書いておきたいと思います。( Web サーバについてはマニアックに lighttpd を紹介しましたが、それは聞かないお約束です)

信頼できる情報を入手し行動しよう


まず何よりも大切なのは信頼できる情報を入手するということです。「blogでヤバいって書いてあるから」 とか 「Twitter で勧められたから」という理由で行動を起こすのは非常に愚かな行為であるといえます。今回の件での情報源としてあげることができるのは JPCERT/CC の


かと思います。JPCERT/CCの注意喚起についてはアナウンス用のメーリングリストでも公表されるので、これを機会に購読しておくのも良いかと思います。実際の対策については
The Apache Software Foundation から本脆弱性を修正した Apache HTTP
Server 2.2.20 が公開されています。また、一部のディストリビュータなどか
らも修正済みプログラムが提供されています。十分なテストを実施の上、修正
済みプログラムを適用することをお勧めします。
と書かれている通り、更新された新しいバージョンのものにアップデートすれば良いということが言えると思います。

Ubuntu の場合ですと、この件について
というセキュリティ告知 ( Ubuntu Security Notice ) が出されており、それを見てみると現在サポートされているバージョンにおいて対策を講じた apache2 パッケージが公開されており、それにアップデートすれば良いようです。対策済のバージョンはそれぞれ
Ubuntu 11.04
  apache2.2-bin 2.2.17-1ubuntu1.2
Ubuntu 10.10
  apache2.2-bin 2.2.16-1ubuntu3.3
Ubuntu 10.04 LTS
  apache2.2-bin 2.2.14-5ubuntu8.6
Ubuntu 8.04 LTS
  apache2-mpm-worker 2.2.8-1ubuntu0.21
  apache2-mpm-event 2.2.8-1ubuntu0.21
  apache2-mpm-prefork 2.2.8-1ubuntu0.21
  apache2-mpm-perchild 2.2.8-1ubuntu0.21
となっており、「一般的には通常の方法でアップデートすれば必要なものがすべてアップデートされる」とも書かれています。アップデートの方法は過去にこの記事で触れたので、参考にしてもらえればと思います。

なんとか対策が終わったとして、対策が済んだのかどうかを確かめる必要があるのですが、実は Ubuntu の場合ここで小さな罠があります。例えば apache2.2-bin パッケージのバージョンを調べるのに、dpkg -l を使ってこんな風に調べると
$ dpkg -l apache2.2-bin
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  apache2.2-bin  2.2.16-1ubuntu Apache HTTP Server common binary files
$ 
と、このようにバージョン文字列の表示が途中で切れてしまってセーフなのかアウトなのか分からないもどかしい表示となってしまいます。マニュアルを読んで調べれば分かることなのですが、一例しては、dpkg-query -W を使って
$ dpkg-query -W apache2.2-bin
apache2.2-bin   2.2.17-1ubuntu1.2
$ 
とすることで、対策済かどうかが判別できるかと思います。

「部品」として使われている Apache に注意


ということで、Ubuntu を使っている場合には「一般的な環境では通常通りアップデートせよ」と結果としては非常に簡単な結論になるわけですが、その根拠をこういった感じで調べるということが非常に重要なのではないかと思います。

あとは同じようなモノについても対策を講じる必要があるわけですが、Apache そのものは非常に広い範囲で使われているため「部品」として使われることも多く、Tomcat や Rails などの Web アプリフレームワークと連携をさせている場合などに盲点になりやすいので注意が必要です。

こういった脅威に対してどれだけ迅速に対応できるのかといった点が OS のサポートの質を問うバロメータの一つと言っていいかと思いますので、その辺りにも留意しておくとよいでしょう。

また、Apache を自前でコンパイルしていたり、独自のモジュールなどを組みこんでいたりするとそういったモノについてもケアする必要があるので、そこは各自頑張っていただくよりほかないことも付け加えておきたいと思います。

2011年5月6日金曜日

PSN/Qriocity での情報漏洩事件

こちらの blog では震災以降初の投稿となります。非常に深刻な災害で今なお余震や放射線の影響やいかにして復興するのかという非常に重いテーマが横たわっておりますが、一歩一歩前に進むことが重要なのではないかと考えています。私が住んでいる山形県は震源域にそれなりに近かった割に被害が少なく、そういった意味では恵まれていたのかもしれません。

さて、ここにきてソニーの PlayStation Network の情報漏洩のニュースが報じられています。当初は単なるメンテナンス・運用停止ということでしたが、時が経つにつれ個人情報の漏洩の事実が明らかになり、続報でその規模が大きく膨れ上がりつつある状況にあります。

私は幸か不幸か PSN に入っていないので今回の件での影響は全くないのですが、運用が止まっている故にサービスを受けられないということ以外に非常に大きな脅威になっているようです。というのも、この件についてJPCERTコーディネーションセンターがサービス名、会社名を出して注意喚起を行っているからです。

JPCERT-AT-2011-0011 情報流出に伴う ID とパスワードの不正使用に関する注意喚起

JPCERT の注意喚起はマイクロソフトやAdobeといった、非常に広い範囲で使われデファクトスタンダード(事実上の標準)になっているもの以外では極力固有名詞を出さずに注意喚起が行われるのが通例なのですが、今回は影響範囲の大きさから冒頭から「株式会社ソニー・コンピュータエンタテインメントより」と固有名詞を出した注意喚起となっています。内容としては
ソニー・コンピュータエンタテインメント社によると、今回の不正アクセスにより、ユーザが PlayStation Network および Qriocity に登録した氏名、住所、Eメールアドレス、生年月日、パスワード、オンライン ID といった情報が流出していた可能性があるとのことです。また、同サービスにクレジットカード情報を登録していたユーザは、登録していたクレジットカードに関する情報が流出した可能性が否定できないとのことです。

同サービスに登録しているアカウント情報 (ID/Password) を他のサービスでも使用していた場合、攻撃者は不正に入手したアカウント情報を使用して、PlayStation Network および Qriocity 以外の他のサービスにログインし、サービスを不正に使用したり、そのサービスに登録されている個人情報やクレジットカード情報を窃取したりする可能性があります。
ということで、個人情報とアカウント情報、クレジットカード情報が漏洩している可能性があるという非常にショッキングな内容になっています。引用した後半の段落にも書いてありますが、アカウント情報を使いまわしていたりするとそこが突破口となって他のサービスでの不正利用を被る可能性があるということが指摘されています。

では、PSN を利用しているユーザがとらなければならない行動は何なのかということになりますが、PlayStationNetwork/Qriocity(TM)をご利用の皆様へのお詫びとお願い に書かれていますが、
PlayStation®NetworkおよびQriocity™のサービスが復旧した際は、お客様がご利用のパスワードを変更されることを強く推奨いたします。併せて、お客様がインターネット上でご利用の他のサービス等で、PlayStation®Network/Qriocity™と同じユーザーIDやパスワードを使用されている場合は、それらの変更を強くお奨めいたします。

さらに、お客様に成りすました不正ログインや不正利用を防ぐために、アカウントに登録されている情報の詳細やクレジットカードの引き落とし履歴等を定期的に確認されることを推奨いたします。(クレジットカードに関連する情報についてご不明な点等につきましては、ご利用のクレジットカード会社にお問い合わせください)
といった行動を起こすことが重要です。SCE の文章では

  1. PSN が復旧したらパスワードを変更する
  2. PSN 以外のサービスでアカウント情報を流用したらそれらを変更する
  3. クレジットカードの利用履歴をチェックする

という順番で PSN が復旧してから行動するようにも読み取ることができますが、現在は依然として PSN の復旧に目処がついていない状態である上に、アカウント情報やクレジットカード情報が漏洩している可能性が否定できないという状況ですので、これらの行動は「すべて同時並行的に」行う必要があります(もちろん PSN が復旧しないとパスワードの変更はできませんが)。

被害にあったら原因を作ったところを訴えるという考え方もあるかと思いますが、被害にあうのはユーザ自身ですので自己防衛を徹底して行うのが大切なのではないでしょうか。

2011年2月9日水曜日

相次ぐセキュリティ注意喚起にご留意を

ここ2,3日の間で、JPCERTコーディネーションセンターから注意喚起が相次いで出されました。

まずは、Adobe 関連のアップデートということですが、Flash Player および Adobe Reader/Acrobat のセキュリティアップデートが出されています。

JPCERT-AT-2011-0005 Adobe Flash Player の脆弱性に関する注意喚起
JPCERT-AT-2011-0004 Adobe Reader 及び Acrobat の脆弱性に関する注意喚起

現行の Flash Player と Adobe Reader/Acrobat は全て対象になるようですのでアップデートを行う必要があります。Adobe の Flash や Acrobat は現在広く利用されているソフトウェアではありますが、脆弱性の発見とアップデートが日常的に行われています。現在のところ JPCERT/CC では攻撃が行われたという情報は持っていないということですが、アップデートしておきたいところです。気を許すとすぐにアップデートしないといけない部分もありますが、アップデートの仕組みについても Chrome や Google 日本語入力のようにとまでは言いませんがスマートにアップデートする仕組みを Adobe さんには開発してもらいたいところです。

そして、Microsoft の月例アップデートですが

JPCERT-AT-2011-0003 2011年2月 Microsoft セキュリティ情報 (緊急 3件含) に関する注意喚起

インターネットに接続する一般ユーザが使う PC などではこの辺は「自動更新」でアップデートしてしまうのが吉だと思います。業務用に使用しているところだといろいろ制限がある場合もありますが、業務に影響しない範囲ならばこの辺はきちんと追っかけておいて損はないと思います。

さて、問題は次の

JPCERT-AT-2011-0002 主に UNIX / Linux 系サーバを対象としたインターネット公開サーバのセキュリティ設定に関する注意喚起

で、この注意喚起の内容が非常につかみづらいところがあります。要は「5060/udp を scan する試みが広く行われていて、それらは踏み台にされた UNIX/Linux サーバが使われているようだから気をつけろ」ということなのですが、注意喚起文のなかに掲げられている、定点観測システムでの検出状況をみると

(上のグラフは国内、下のグラフはアジア太平洋での観測動向です )

と、昨年の 7~9月 に観測実績があがり、ここ最近では小康状態を保っているように感じられます。このような小康状態期にあえて JPCERT/CC が注意喚起するということは量的なところではなく別の要因があると考えるのが自然です。こういった注意喚起文ではナーバスなところはボカすどころかまったく言及されない性質があるのですが、もう一度読んでみると
今回、情報提供者から本事例に関する情報と攻撃者によって設置されたプログラムの提供を受けて調査した結果、攻撃の流れが判明した事に加え、インターネット定点観測システム (ISDAS/TSUBAME) で観測した送信元IPアドレスが国内に多数存在していることから、不正侵入されたサーバへのセキュリティ対策の実施や、同様の被害の未然防止を目的として、本注意喚起を発行しました。
と書いてあることに気が付きました。つまり、

  • 攻撃メカニズムが分かってきた
  • 5060/udp scan を仕掛けている送信元IPアドレスに国内のものが多数存在する
というのがキーポイントのようです。攻撃メカニズムについては注意喚起文に詳しく説明されているのでそちらを読んでいただくとして、scan 元に国内IPアドレスが多数存在するという記述はその真偽も含めて興味が出るところです。

ということで、色々なところのパケットフィルタログを掘り出してきて 5060/udp scan を仕掛けてきた国内IPアドレスについて調査をしてみました。といっても仕事で解析した部分もあるので、おおまかな傾向のみですが書いてみたいと思います。

  • 5060/udp scan をかけてくるIPアドレスの多くは中国もしくはアメリカからのものである ( 国内IPアドレスからの scan は構成比でトップになるほど多いというわけではない )
  • scan 実績があったIPアドレスの多くはホスティングサーバやVPSサーバからのものが多い。自宅サーバもないわけではないけれどもどちらかというと少数派
  • 中には色々な RBL やブラックリスト的なものに登録されているサイトもある
  • 確かに弱点がありそうな(笑)運用状態のサイトもまま見受けられる
とこういった傾向がみられました。特にここ最近低価格のホスティングサービスや VPS サービスが出てきてユーザの人気を集めていますが ( さくらのVPS についてはこのブログでも取り上げました ) せっかくお金を出してそういったサービスを利用するわけですから、ある程度のところまではがんばって構築をして最低限のセキュリティを保ってもらいたいなと思います。

イマドキの Linux ディストリビューションでは、サービスを立ち上げることだけに焦点をあてると比較的簡単に構築できるわけですが、長く使うのであればセキュリティにも注意を払い、知らず知らずのうちに加害者にならないことが肝要です。このブログのさくらのVPSシリーズでいえば、ufwによるファイヤーウォールの設定、かなりはしょって書いてしまいましたが、SSHサーバの設定といったところは非常に重要な要素になると思います。特に SSH サーバについては、パスワード認証を使わずに公開鍵認証のみに絞ることができればパスワードが破られて侵入されるといった脅威をかなりとり除くことができます。

中途半端な状況で放置するくらいなら一旦サーバを初期化してもう一度トライしてみるというのも良い経験になるかと思います。末長く運営するための手間は一見無駄なものに見えるかもしれませんが後でかならずその苦労は帰ってきますので、よくよく確認していただければと思います。

とはいえ、中には業務で使用しているものがそのような状況に陥っているところもごく一部に見受けられますが、何らかの方法できちんとマネジメントしてもらうか、それができなければ相応の報いを受けるしかないかと思います。日本には不正アクセス禁止法 ( 不正アクセス行為の禁止等に関する法律 ) という法律がありますが、法律そのものがサーバのセキュリティを守ってくれるというものではないということを知るべきなのかもしれません。

2011年1月7日金曜日