makoto_fujimotoのblog

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

カテゴリ: セキュリティ

2015年5月、日本年金機構が標的型メール攻撃を受け、職員のPCが不正操作されてファイルサーバーに保管していた約125万件の年金情報が漏洩したとのことです。捜査が進むにつれ攻撃者のアドレスがフリーメールだったとか、添付書類の拡張子が"exe"なのにうかつに開いてしまったというお粗末な運用実態も次々に明るみになっています。

年金機構は当然セキュリティ対策としてウィルスチェックソフトを運用していたと思われますが、標的型メールは独自にカスタマイズされていることが多いのでウィルスパターンをすり抜けて検知されないことがあるようです。

今回のようにウィルスチェックを通過してしまう可能性のある標的型メールを水際で防ぐために、Postfixメールサーバーの設定だけで比較的簡単にできる対策を4つまとめました。
(1) 送・受信容量制限を行う
(2) 偽証の元になる差出人名をフィルタして元のメアドのみ表示させる
(3) 本文内のURLをフィルタリングして非リンク化
(4) 添付ファイルの送・受信を禁止する

具体的な設定方法はこちらになりますが、実用レベルでは未検証ですので各自の責任においてお試しください。

(1) 送・受信容量制限を行う

ウィルスソフトを送りつけられるリスクを軽減するために必要最小限の容量に制限します。また盗まれた情報を外部に大量送信することを防ぐ効果もあります。

a. /etc/postfix/main.cfを編集
以下の設定を追加
------------------------------------------
message_size_limit = 102400
------------------------------------------
※単位はバイト数になりますが、通常のテキストメールのやり取りであれば100k程度で済むのでは?デフォルトでは10MByteに設定されています。

b. サービスの再起動
# service postfix reload

(2) 成りすました差出人名をフィルタして元のメアドのみ表示させる

差出人名は容易に成りすましが可能で気が付きにくいので、メールソフトがメールアドレスを直接表示するようにフィルタリング処理を行います。
From: 藤本 信 <jt85do34903h7@yahoo.com>

From: jt85do34903h7@yahoo.com

a. /etc/postfix/main.cfを編集
メールのヘッダ部分をチェックする設定ファイルを記述
------------------------------------------
header_checks = regexp:/etc/postfix/header_checks.regexp
------------------------------------------

b. /etc/postfix/header_checks.regexpを編集
------------------------------------------
/(^From: ).*<(.*)>/ REPLACE $1$2
------------------------------------------

c. サービスの再起動
# service postfix reload

(3) 本文内のURLをフィルタリングして非リンク化

メール本文内にあるURLをうかつにクリックしないように非リンク化させます。
http://www.yahoo.jp → ttp://www.yahoo.co.jp
https://www.yahoo.jp → ttps://www.yahoo.co.jp
また注意を促す文字列を挿入することもできます。
https://www.yahoo.jp → [クリック注意]https://www.yahoo.co.jp

a. /etc/postfix/main.cfを編集
メールの本文をチェックする設定ファイルを記述
------------------------------------------
body_checks = regexp:/etc/postfix/body_checks.regexp
------------------------------------------

b. /etc/postfix/body_checks.regexpを編集
------------------------------------------
/^(.*)http:(.*)/ REPLACE ${1}ttp:${2}
/^(.*)https:(.*)/ REPLACE ${1}ttps:${2}
------------------------------------------
※やや甘いので改良の余地ありです

c. サービスの再起動
# service postfix reload

(4) 添付ファイルの送・受信を禁止する

業務やサービス運営に支障が無ければ特定の添付ファイルを除外することも可能です。

拡張子のタイプを判別して除外する場合
a. /etc/postfix/header_checks.regexpを編集(複数行の設定も可能)
------------------------------------------
/name=\".*\.(exe|vbs|pif|sh|com|bat|scr|dll|wsh|cab|inf|ins|hlp|hta|js|vb|lnk|cmd|chm|cpl|msi|wsf|reg|vbe|wsc )"/ REJECT
------------------------------------------
※ファイル名に日本語が含まれていた場合に検知できるか未確認です

b. サービスの再起動
# service postfix reload

このエントリーを書くべきか少し悩みましたが、初歩的なセキュリティ対策がおろそかになっているWebサイトがあまりにも多いので注意喚起の為にあえて公開します。

Webサイトのセキュリティ対策はおなじみのファイアウォールやアクセス制限などに加えて、運用管理者機能にも適切な制限を掛ける必要があります。しかし現状では簡単に推測できる管理者用URLが一般公開されているサイトを簡単に見つけることでき、一般的なフレームワークや独自の管理者ログイン画面が認証なしに出てきてしまうサイトが沢山あります。そのようなWebサイトはログインID&パスワードも不用心なものが使用されている可能性が高く、ハッカーの格好の餌食になってしまいます。

以下に経験的に狙われやすいURLをリストアップしてみましたので参考にしてください。そもそもこのようなURLを使用しないか最低限IPアドレス制限を掛けることをお勧めします。

/admin/
/admin/wp-login.php
/wp/wp-login.php
/wp-admin/
/wp-login.php
/wordpress/
/wordpress/wp-login.php
/cms/
/cms/wp-login.php
/admin.html
/admin.php
/mt/
/ec-cube/
/eccube/
/kanri/
/phpMyAdmin/
http://admin.ドメイン名/
http://IPアドレス:8443/
http://IPアドレス:10000/
http://IPアドレス/

ちなみに以下のような名前のファイルがアップされていると外部から叩かれる可能性がありますので、見られて困るファイルはサーバに放置しないのが鉄則です。

/test.php
/test/
/phpinfo.php
/index2.php
/index.php.bak
/_index.html
/index.html.bak

今度は「ドメイン名ハイジャック」ですか。

ずいぶん派手な攻撃名が付けられたものです。
毎度この手のサイバー攻撃を命名する方の素晴らしいセンスを感じないわけにはいきません。

JPCERT/CC: 「登録情報の不正書き換えによるドメイン名ハイジャックに関する注意喚起」
https://www.jpcert.or.jp/at/2014/at140044.html

ところで早速この攻撃を受けたとされる大手新聞社関連サイトのドメインを調査しに逝ってみたところ、whois情報からドメインレジストラが判明しました。こういうダダ漏れのところが大好きです、ビバ!インターネッツ!

この有名なレジストラの仕様を改めて確認したところ、あろうことか利用者登録する際に任意のIDつまりメールアドレスが使用できるようになっているようです。当ブログをお読みになっている方ならもうお分かりですね?このようなユーザ認証方式を採用している場合に真っ先に考えられるサイバー攻撃がパスワードリスト攻撃です。

つまり、今やブラックマーケットで簡単に入手できるとされているログイン情報(メールアドレス+パスワードの組み合わせが多い)の中から影響力の高そうなドメインの管理者アカウントを抽出し、whois情報からレジストラを割りだし、不正にドメイン管理者としてログインを試み、ドメイン情報の中で特に重要なネームサーバ情報を書き替え、不正サイトに誘導させるということが行われたと考えられます。

また、攻撃対象のドメインがあらかじめ分かっていてかつレジストラがメールアドレスをログインIDに用いることができる仕様になっていれば、ドメイン管理者が使用しそうなメールアドレス、例えば
webmaster@shinkaku.com
root@shinkaku.com
admin@shinkaku.com
administrator@shinkaku.com
と、ありがちなパスワードの"123456"や"password"で難なくログインに成功してしまうかもしれません。

何度も言うようですが、ログインIDにメールアドレスや任意の文字列を利用できるような仕様を放置採用しているサイト管理者の方々には対策をお勧めします。
不正ログイン防止設計について


2014/11/7 19:16 追記

海外のメジャーなレジストラのアカウント仕様をいくつか確認したところ、ログインIDを任意に設定できる方がむしろスタンダードなようです。したがって、お名前.comのようにIDが払い出されるレジストラの方が少数派かもしれません。

昨今、ホームページの不正ログインやアカウント乗っ取り事件が後を立ちませんが、多くの原因と考えられているのが他社サービスで大量流出したログイン情報を悪用したものです。

この様な不正アクセスをリスト型アカウントハッキングあるいはパスワードリスト攻撃と呼んでいます。

一般的にはパスワードが単純すぎたり使い回しが原因とされていますが、私はログインIDにメールアドレスやユーザ任意の文字列を使用できる設計を採用しているサイト運営側にも問題があると考えます。

サイトの立ち上げ当初はユーザの利便性を考慮してこのような仕様を採用することが多かったと思いますが、現在はログインにメールアドレス+パスワード形式を採用しているサイトはいつ不正アクセスに合ってもおかしくない状況です。

ですから今後、運用サイトのセキュリティ強化や新規に会員機能を構築する際は、既にユーザーの個人情報がブラックマーケットに流出している前提で設計する必要があります。

具体的な対策としては以下のようなものが考えられます
・ログインIDにメールアドレスや任意の文字列を使用しない(サイト側で払い出し)
・パスワードを定期的に強制リセットする(逆に変更機能は設けない)
・大量連続ログイン対策を講じる
・ログイン認証項目を増やす
(いずれもユーザの利便性は犠牲になってしまいます)

特にメールアドレスや任意のログインIDはこれだけ頻繁に大量の個人情報流出事件が発生している状況では認証に使用しない方が賢明でしょう。

現行サイトの運用や今後のサイト構築の際に参考にしていただければ幸いです。

ベネッセの個人情報流出の余波で各企業は機密情報の漏洩対策に頭を悩ませてる頃と思います。どうやら犯人の手口はスマホをUSBケーブル経由でコンピュータに接続するという単純な手法でコピーしていたようですね。したがって今更ながらベネッセはPCやサーバのUSBをはめ殺しにするこんなパーツ(480円)で対策さえしていたら200億円+信頼を毀損せずに済んだのかもしれません。マウスやキーボードは旧来のPS/2タイプに戻す必要がありますが安いもんでしょう。

41YDzz5Oc+L

アクセス元のIPアドレスによってある程度国を判別することが可能なので、国際対応していないWebサービスの"鎖国"を推奨している私ですが、JPNIC(日本ネットワークインフォメーションセンター)さんにその妥当性を質問してみました。

【質問1】
「IPアドレスより割り当てが行われた国を判別することが可能だと思いますが、例えば日本に割り当てられているブロックは 国内法が適用される日本領からのアクセスと補償されるもので しょうか?日本国に割り当てられたIPアドレスが海外で使用されている 可能性はないのでしょうか?」

【JPNIC回答】
"JPNICから分配されて日本国外で使用されているIPアドレスや、JPNIC以 外のレジストリ(APNIC, ARIN, RIPEなど)から分配されて日本国内で使用されているIPアドレスもあるかと存じます。"

【質問2】
「それでは分配されたIPアドレスに対して使用国の制約が無いので使用されている 国を断定はできないという理解でよろしいでしょうか?」

【JPNIC回答】
"ご認識の通りとなります。"


このやり取りで分かったことは、日本で発行されたIPアドレスが海外で使用されることもあれば、海外で発行されたIPアドレスが日本で使用される可能性もあるということです。これはレアケースだとは思いますがIPアドレスだけではアクセス元となる法治国家を断定できるものではないということですね。

とは言え、性善説で成り立ってきたインターネットの世界もオープン性は確保しつつ"不必要なものまで公開はしない"程度のコンセンサスがそろそろ必要な時期じゃないでしょうか。

最近はLinux系サーバ自身にもセキュリティソフト導入が要件になっている案件が増えています。以下はサーバに送信されるファイルをリアルタイムにスキャンを行うHDE社のAnti-Virus Realtime ScanというLinux系サーバソフトのインストール時のメモとなります。

【要注意2014.1.29】
現在CentOSの最新カーネルでこのソフトを使用するとOSがクラッシュする不具合が発生しているようです。したがってカーネルをアップデートしないようにするか/etc/grub.confの設定でデフォルトで古いカーネルを立ち上げるようにしておく必要があります(CentOS 2.6.32-358.el6.x86_64を起動するようにする)

CentOS 6.5相当のカーネルでご利用の場合、システム動作に問題が起る問題について(2014/1/21)

  1. 評価版のダウンロード
    http://www.hde.co.jp/hav/demo/
  2. フォームに必要情報を入力
  3. 届いたメールのURLをクリック
  4. ダウンロード(PCローカルに保存)
  5. パッケージをサーバに転送(自分のhomeなど)
  6. マニュアルを入手
    http://www.hde.co.jp/hav/demo/
  7. 中身の確認
    $ tar tvf HDE_Anti-Virus_10.0-3R10_20130108180758.tar
  8. 展開
    $ tar xvf HDE_Anti-Virus_10.0-3R10_20130108180758.tar
  9. とりあえずインストーラを起動してみる
    $ su
    # cd HDE_Anti-Virus_10.0
    # ./av-install
    エラー: gd は lcserver-php53 に必要とされています。
    エラー: libpng は lcserver-php53 に必要とされています。
    エラー: libxslt は lcserver-php53 に必要とされています。
    エラー: apr は lcserver-php53 に必要とされています。
    エラー: apr-util は lcserver-php53 に必要とされています。
    エラー: perl は HDE Anti-Virus に必要とされています。
    エラー: wget は HDE Anti-Virus に必要とされています。
    エラー: gcc は HDE Anti-Virus に必要とされています。
    エラー: patch は HDE Anti-Virus に必要とされています。
    エラー: libgcc.i686 は HDE Anti-Virus に必要とされています。
    エラー: glibc.i686 は HDE Anti-Virus に必要とされています。
    エラー: pam.i686 は HDE Anti-Virus に必要とされています。
    エラー: zlib.i686 は HDE Anti-Virus に必要とされています。
    ここで要求されるパッケージはOSインストール時に選択した条件により異なります。
  10. 不足パッケージの追加(OSのインストール方法で不足パッケージが異なります)
    yum install gd
    yum install libpng (上のパッケージに含む?)
    yum install libxslt
    yum install apr
    yum install apr-util
    yum install perl
    yum install wget
    yum install gcc
    yum install patch
    yum install libgcc.i686
    yum install glibc.i686
    yum install pam.i686
    yum install zlib.i686
  11. 再度インストーラ実行
    # ./av-install
    エラー: kernel-devel-2.6.32-358.el6.x86_64 または kernel-source-2.6.32-358.el6.x86_64 は HDE Anti-Virus に必要とされています。
    まだkernel系パッケージが不足している
  12. 不足パッケージの再追加
    # yum install kernel-devel-2.6.32-358.el6.x86_64
    No package kernel-devel-2.6.32-358.el6.x86_64 available.
    Error: Nothing to do
    パッケージが無いと言われる
  13. 手動によるrpmの取得(他のMirrorサイトでもOK)
    # wget ftp://mirror.switch.ch/pool/1/mirror/scientificlinux/6.4/x86_64/os/Packages/kernel-devel-2.6.32-358.el6.x86_64.rpm
  14. rpmのインストール
    # rpm -ivh kernel-devel-2.6.32-358.el6.x86_64.rpm
  15. ホスト名の再定義(ドットが2つ以上含むFQDNにする)
    # hostname server1.hoge.local

  16. インストーラの起動(CUIで可能)
    # ./av-install
    確認[1/4]OK
    確認[2/4]
    ホスト名 server1.hoge.local (←hostnameと同じもの)
    lcadminパスワード *******
    言語 ja_JP - 日本語
    OK
    確認[3/4]OK
    完了[4/4]OK
  17. iptable(FW)の設定
    16590ポートを解放する(セキュリティ的に限定した方が良い)
  18. HDE管理画面の確認
    操作を行うPCのhostsファイルを設定
    --------------------------------------------------
    123.123.123.123 server1.hoge.local
    --------------------------------------------------
    以下管理画面URL
    https://server1.hoge.local:16590/
    ID: lcadmin
    PW: *******
  19. postfixの設定(HDEのメール送信機能を使用する場合)
    /etc/postfix/main.cfに以下記述追加
    canonical_maps = hash:/etc/postfix/canonical
    /etc/postfix/canonicalに以下記述追加(エンベロープFROMを存在しているドメインに書き換え)
    root@server1.hoge.local   root@hoge.jp
    # postmap /etc/postfix/canonical
    # service postfix reload
  20. postfixのテスト
    # /usr/lib/sendmail fujimoto@hoge.jp
    test
    test
    Ctrl+D
    #
    メールが届けばOK
  21. 後はマニュアルをご覧ください:-)

大半のサイバー攻撃は海外からやって来ることが多いので、顧客に半分本気で「日本国内にアクセスを限定したらいかがですか?」と提案することがあります。ちなみに最も簡単にネットワーク単位の制限を掛ける方法はApacheのアクセス制限を利用することです。

参考までに日本国に割り振られているIPアドレスにアクセスを限定するApache(.htaccess)の設定方法を記載してみました(動作の保証はできませんが)。ちなみに3千行近くありますので、毎回読み込まれるhtaccessではレスポンスに影響が出る可能性があります。
IPアドレスの入手元はこちらです http://ftp.apnic.net/stats/apnic/delegated-apnic-latest

order deny,allow
deny from all
allow from 1.0.16.0/20
allow from 1.0.64.0/18
allow from 1.1.64.0/18
allow from 1.5.0.0/16
allow from 1.21.0.0/16
allow from 1.33.0.0/16
allow from 1.66.0.0/15
allow from 1.72.0.0/13
allow from 1.112.0.0/14
allow from 14.0.8.0/22
allow from 14.1.4.0/22
allow from 14.1.8.0/21
allow from 14.3.0.0/16
allow from 14.8.0.0/13
allow from 14.101.0.0/16
allow from 14.102.132.0/22
allow from 14.102.192.0/19
allow from 14.128.0.0/22
allow from 14.128.16.0/20
allow from 14.128.64.0/19
allow from 14.128.96.0/19
allow from 14.132.0.0/15
allow from 14.137.224.0/19
allow from 14.192.32.0/20
allow from 14.192.48.0/21
allow from 14.192.56.0/22
allow from 14.192.96.0/19
allow from 14.193.0.0/16
allow from 27.0.0.0/22
allow from 27.0.16.0/20
allow from 27.0.32.0/20
allow from 27.34.128.0/19
allow from 27.34.160.0/21
allow from 27.34.168.0/21
allow from 27.34.192.0/19
allow from 27.50.12.0/22
allow from 27.50.96.0/19
allow from 27.54.96.0/20
allow from 27.54.112.0/22
allow from 27.54.124.0/22

(以降略)

コンピュータのセキュリティ対策では「パスワードを書いた紙をパソコンの周りに張り付けるな」が常識とされてきましたが、最近、僕はむしろ「張り付けた方が安全なんじゃないか」という突飛な考えに達しています。

最近の個人情報漏洩事件では、サーバに不正アクセスを行って会員データを大量に盗み出すということが頻繁に行われています。盗まれた個人情報にログイン情報としてのメールアドレスやパスワードが含まれていた場合、そのサイトのみならず、他のサイトでも悪用される可能性が高いのです。したがって、僕はこの様なログインIDとパスワードの組み合わせがブラックマーケットで"不都合なビッグデータ"として既に流通し始めていると思っています。

だから、個人個人の物理的なパスワード管理などは些末な問題とさえ思えてしまいます。

これまでも何度か問題提起してきましたが、ログインIDにメールアドレスを用いたり、任意の文字列を使用できるサイトは、個人が他のサイトで同じ形式で利用している可能性が高く、どこかで流出した場合に"合鍵"となって不正アクセスされてしまいます。
パスワードリスト攻撃について

これを防止するには、サイト独自かつ推測されにくいユーザIDをサーバから発行して、変更も出来ない仕様とすることです。さらにパスワードもサーバから発行して変更も出来ない仕様とするのが"合鍵"を利用されない最善の手段と言えます(定期的に強制的にパスワードを変えるとさらに安全ですが、ビジネスサイドからは不満が出るでしょう)。
セキュアなログインIDとは(加筆)
不正ログイン対策が急務です(さらに加筆)

ここで問題となるのがユーザにとってログインIDとパスワードを覚えるのがほとんど不可能ということでしょう。しかしセキュリティ対策の甘いサイトで漏洩した自分のログインIDとパスワードが他のサイトで不正に使用されるリスクと天秤にかけると、推測されにくいログイン情報をやむを得ずパソコンの周りに張り付けたほうが安全という結論に僕は達しました。

インターネットのどこかに潜むサイバーテロリストはあなたの机の周りを覗くことは出来ないですし、また万が一覗くことが出来ても"コスト面"で割に合わないでしょう。

このブログは、「ハッキング被害が後を絶ちません」という内容が多いのですが、最近本当に多いようです。毎週のようにどこかで被害報告があります。特に他のサイトで流出したアカウント情報を用いた「パスワードリスト攻撃」と思われる攻撃手法が多く用いられ、実際に被害も発生しているようです。

2013/3/26 「
2013/4/3 【goo】不正ログイン被害のご報告とパスワード再設定のお願い
2013/4/4 【NTT東】フレッツ光メンバーズクラブ会員サイトへの不正アクセスについて
2013/4/5 【Tサイト】不正ログインによるなりすまし被害のご報告およびパスワード変更のお願い
2013/4/9 【eBookJapan】不正ログイン被害のご報告とパスワード再設定のお願い
2013/4/11 フレッツ光会員サイトで再び不正ログイン被害、全404万アカウントを凍結
2013/4/11 「gooID」不正ログイン攻撃は総当たりでなく使い回し ID/パスワード試行、全 ID をロック
2013/4/17 【JR東】My JR-EASTでの不正ログイン発生とご利用のパスワード変更のお願い


外部で流出した個人情報を悪用した不正ログインの予防では、パスワードを定期的に変更するのがオーソドックスなセキュリティ対策ですが、現在でも十分有効です。ただし、多数のサービスを利用している場合も多いので、それぞれのサービスに対して自主的に変更してまわるのは面倒ですよね。

これらを踏まえてサイト運営者には以下のような少し踏み込んだセキュリティ対策をお勧めします。

  1. パスワードを定期的かつ強制的に変更する
    もはやユーザ責任によってパスワードを自主的に変更してくれる事を期待するのは止めたほうがいいと思います。もちろん事前告知とパスワード通知方法は十分に検討する必要があります。

  2. パスワード変更機能をあえて削除する
    ログイン認証機能を持つサイトでは「パスワードを定期的に変えてください」とアナウンスされることが多いのですが、パスワード変更機能はセキュリティ保護というよりは、自分が覚えやすいものや他のサイトで使用しているのと同じものに変更してしまうリスクの方が大きいと思います。

  3. ログインIDにメールアドレスや任意IDを使用しない
    これまで多くのWebサービスがログインIDをメールアドレスや任意の文字列にしてきた理由は分かります。メールならパスワードを忘れた際にリマインドを送るのに便利だし、ユーザの利便性も高まります。しかし、これらは他のサイトと共通にしていることが多いので、他のサイトで個人情報が漏洩した場合に不正利用されてしまう可能性が高いのです。したがって、サービス独自かつ容易に推測・生成できない仕様のログインIDを用いることをお勧めします。
    参考「セキュアなログインIDとは

  4. ログインIDとパスワード以外の認証項目を追加する
    例えば会員データベースに生年月日や郵便番号が確実に入力されているとすれば、この情報も照合することで不正ログインのリスクを軽減できます。

  5. ログイン認証プログラムへの対策
    クラッカーが不正ログインを試みる際は、手元のリストやパターンリストを用い、プログラムを使って機械的に大量の不正認証を試みます。これを防ぐためには同一アクセス元からのログイン認証に対して単位時間当たりの制限を設けたり、ユーザー本人が確実にブラウザで操作を行っていることを検証できるロジック※の組み込みが考えられます。

  6. パスワードを暗号化保存する
    これは自社サイトのセキュリティ対策と言うよりは、万が一自社サイトから個人情報が流出した際に、他のサイトで不正利用されてしまう二次被害の予防となります。
    参考「


しかしながら、ほとんどのセキュリティ対策はユーザビリティを犠牲にすることになります。ログイン情報が変更になっただけで離れて行ってしまうユーザも少なくないでしょう。アナウンスやサポートの手間もかかります。したがって、不正アクセスがあった際の最大のリスク(コスト)とWebサービスのクオリティ維持コストを鑑みたマクロ視点でのビジネス判断が必要となります。

※ただし、昨今話題となっているPC乗っ取りによる成りすましのログインが行われた場合、サイト側で不正を判別する良いアイデアはなかなか思いつきません。最善の策はUSBトークンや電子証明書の物理デバイスによる認証を組み合わせることですが、コストと利便性の面で一般的に普及するにはまだ難しいでしょう。

↑このページのトップヘ