makoto_fujimotoのblog

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

カテゴリ: セキュリティ

元々価格が安いVPSは、オプションとして比較的高価なファイアーウォールを利用するケースは少ないと思います。その場合のセキュリティ対策は借りているVPS自体で行う必要があります。

大概のVPSサービスはLinux系のCentOSが提供されますので、標準でiptablesという簡易ファイアウォールが利用できます。このiptablesは一般的なファイアウォールの標準的機能であるパケットフィルタリング等がきめ細かくできますが、反面ネットワークの知識が必要で、慣れていない方には少し設定が難しいと思います。簡易的なアクセス制限についてはこちらを参考にしてください。

次の例では、備忘も兼ねて標準的なWebサービスを提供するサーバを運用する場合のファイアウォール設定を記述しています。なおこちらは机上での設定例を記述しただけで、実際のVPSでの動作検証は行っておりませんので、参考にされる場合はくれぐれも自己責任でお願いします。

まずは運用ポリシーを決めましょう
(1)デフォルトで全てのアクセスを拒否する
(2)必要なポートのみ解放する
(3)メンテナンス用のアクセス解放は特定IPアドレスに限定する

以下はiptablesサービスが起動時に読み込む/etc/sysconfig/iptablesファイルを編集した内容になります。 
-------------------------------------------------------
#受信、送信、通過を全て拒否
*filter
:INPUT DROP [0:0]
:OUTPUT DROP [0:0]
:FORWARD DROP [0:0]

#接続済みパケットの送受信を許可
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#VPS自身からの送受信(ループバック)を許可
#VPS⇔VPS
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT

#ping(icmp)を許可
#VPS⇔WAN
-A INPUT -p icmp -j ACCEPT
-A OUTPUT -p icmp -j ACCEPT

#名前解決の為に内部からDNS(53)参照を許可
#VPS→WAN
-A INPUT -p udp --sport 53 -j ACCEPT
-A OUTPUT -p udp --dport 53 -j ACCEPT

#時刻同期の為に内部からNTP(123)参照を許可
#VPS→WAN
-A INPUT -p udp --sport 123 -j ACCEPT
-A OUTPUT -p udp --dport 123 -j ACCEPT

#Webサービス(80)を解放
#WAN→VPS
-A INPUT -p tcp --dport 80 -j  ACCEPT
-A OUTPUT -p tcp --sport 80 -j  ACCEPT

#Webサービス(443)を解放
#WAN→VPS
-A INPUT -p tcp --dport 443 -j  ACCEPT
-A OUTPUT -p tcp --sport 443 -j  ACCEPT

#外部APIなどへのHTTP接続(80)を許可※
#VPS→WAN
-A INPUT -p tcp --sport 80 -j ACCEPT
-A OUTPUT -p tcp --dport 80 -j ACCEPT

#外部APIなどへのHTTPS接続(443)を許可※
#VPS→WAN
-A INPUT -p tcp --sport 443 -j ACCEPT
-A OUTPUT -p tcp --dport 443 -j ACCEPT

#※できれば宛先の制限をお勧めします

#SMTPサービス(25)送受信を許可
#WAN⇔VPS
-A INPUT -p tcp --sport 25 -j  ACCEPT
-A INPUT -p tcp --dport 25 -j  ACCEPT
-A OUTPUT -p tcp --sport 25 -j  ACCEPT
-A OUTPUT -p tcp --dport 25 -j  ACCEPT

#特定IPアドレスからSSH(22)を許可
#123.123.123.123→VPS
-A INPUT -p tcp -s 123.123.123.123 --dport 22 -j  ACCEPT
-A OUTPUT -p tcp -d 123.123.123.123 --sport 22 -j  ACCEPT

#特定IPアドレスからFTP(20,21)を許可
#123.123.123.123→VPS
-A INPUT -p tcp -s 123.123.123.123 --dport 20 -j ACCEPT
-A OUTPUT -p tcp -d 123.123.123.123 --sport 20 -j ACCEPT
-A INPUT -p tcp -s 123.123.123.123 --dport 21 -j ACCEPT
-A OUTPUT -p tcp -d 123.123.123.123 --sport 21 -j ACCEPT


COMMIT
-------------------------------------------------------

編集後iptablesを再起動するとフィルタが適用されますが、設定をミスするとVPSにつながらなくなる可能性があり、最悪OSリセットからやり直しになる可能性もあります。くれぐれも重要な設定はサービスの開始前に行うことをお勧めします。

VPSとは、GMOグループやさくらインターネット社が提供している仮想専用サーバの事で、クラウドと称されることもあります。値段が安くて契約が簡単なので、ちょっとしたスタートアップサイトや開発サーバ用として、さくっと構築するのに便利です。また昨今は構築手順やノウハウもインターネット上や書籍にたくさん出回っているので、サーバやネットワーク技術者以外の方が果敢に構築・運用にチャレンジされる事も多いようです。ただしVPSとはいえ、OSやミドルウェアの仕様は通常のRedhat LinuxやCentOSと全く一緒ですから、セキュリティ対策は万全に行っておきたいものです。
そこで以下にVPSを借りたら真っ先にやったほうがよいセキュリティ対策を挙げてみました。

【固定IPアドレスの確認】
これはVPSを借りる以前の問題ですが、インターネット関連を生業としている会社や個人の方でも、固定IPアドレスを持たないプロバイダ契約をしていることがたまにあります。これは私の感覚ではネット上の住所不定という状態であり、アクセス制限や許可も曖昧にしか出来ないので、機密度の高い仕事を任せてもらえない可能性もあります。したがって固定IPアドレス程度の微々たる投資は惜しみなく行うべきだと思います。

【sshのrootログインを禁止する】
Linux系OSはデフォルトでリモートからのrootログインが許可されている場合が多いので、これを真っ先に禁止しましょう。
$ su
# cd /etc/ssh
# vi sshd_config

  PermitRootLogin yes ------> no

# /etc/init.d/sshd restart

【sshとftpのアクセス制限を行う】
主にサーバ管理に使用するSSHやコンテンツを更新する際に良く用いられるFTPは、ハッカーから攻撃される事が多いので、安全なパスワードや鍵を運用する以前に固定IPアドレス制限をかけておくべきです。アクセス制限方法はいくつか手法があるのですが、TCP Wrapperを用いた以下の設定が簡単です。
# cd /etc
# vi hosts.allow
  
  vsftpd: 123.45.67.89  (追記)
  sshd: 123.45.67.89 (追記)

#vi hosts.deny

  vsftpd: ALL  (追記)
  sshd: ALL  (追記)

ちなみにこれらの設定をミスるとサーバにアクセスできなくなる可能性が有ります。必ずallow側(許可)から設定を行うことと、SSHを制限する前にFTPで不通・通過の確認を行ってください。

【不要なサービスを停止する】
これはサーバ運用の一般的なセオリーですが、メールサーバ(sendmail/qmail/postfix)、メールクライアント(dovecot/qpoper/pop3d)、DNS(named)、Web(httpd)、FTP(vsftpd/proftpd)、データベース(mysql/postgresql)等を明確に使用する要件が無い場合は不用意にサービスを立ち上げておかない方が安全です。

# /etc/init.d/sendmail stop
# cd /etc/rc3.d
# mv S80sendmail K80sendmail

【iptablesによるファイアウォール構築】
Linuxにはiptabesという簡易ファイアウォール機能が備わっていますが、設定が少し専門的ですので素人が触るのはおススメしません(設定を誤るとサーバにアクセスできなくなる場合があります)。こちらの設定方法については別の機会で触れたいと思います。

昨日、MUFGカードからのメールがとてもフィッシング詐欺っぽいという記事を書きましたが
11月19日からNICOSカードと統合されたシステムとなったようで、こちらでも利用者が大騒ぎしています。

「NICOSパスワード8文字切り詰め制限祭りまとめ」
http://togetter.com/li/410227

過去のメールを探してみたところ、10月15日に「ログインページリニューアルのご案内」というメールを受け取っていたようです。内容を確認したら"MUFGカードWEBサービスおよび、DCカード、NICOSカードのWEBサービスログインページを一つに統合いたします。"との趣旨でした。

そしてそこには"リニューアルに伴うID、パスワードの変更はございません。"との注意書きがあったのです。

つまり今回騒動になっているようなパスワード桁数の変更は無いと事前にアナウンスしていたにも関わらず、パスワード認証の仕様変更を当日になって急きょメールで連絡してきたという、お粗末なシステム統合ですね。

また、これまで8ケタ以上のパスワードを入力していた場合でも、実は最大8ケタでしか認証を行っていなかったという(バグと思われる)尾ひれまでついているようで、これは補償問題に発展しないんでしょうかね?

ちなみに同じMUFGグループの三菱東京UFJ銀行のサイトには、昨今大問題となっているインターネットバンクの詐欺事件に関する注意喚起ページで以下のようなことが明記されています。
"(1)当行が電子メールで、確認番号(ご契約カード裏面の乱数表)等のパスワードの入力をご依頼することは、絶対にありませんので、決して入力することのないようご注意ください。"

「インターネットバンキングのパスワード等を騙し取る不審な電子メールにご注意ください。」
http://www.bk.mufg.jp/info/phishing/notice.html

MUFGカード(NICOSカード)からの電子メールはパスワードの再設定を促しているわけなので、同じグループの金融機関なのに言っていることが矛盾していますね。

金融機関のシステム信頼性が揺らいでいます。

うーん
まず、メアドの送信者が.comというのがあやしい
こんな重要な案内なのに電子署名が無いのがあやしい
ログイン方法変更?そんな事前のアナウンスあったっけ?
どうしてパスワードリマインダのURLが.comなの?
パスワードの有効文字数を短縮する改修なんてありえるの?

メールヘッダはまだ解析していませんが、怪しいのでとりあえず放っておきます

(一部伏字にしておきました)

差出人:MUFGカード <infomail@mufgcard.com>
件名:【MUFGカード】MUFGカードWEBサービスにおけるパスワードの入力文字の桁数に関するご案内

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

┃◆ MUFGカード ◆
┃(ご案内)MUFGカードWEBサービスにおけるパスワードの入力文字の
┃     桁数に関するご案内

┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

いつもMUFGカードならびにMUFGカードWEBサービスをご利用いただき
ありがとうございます。

------------------------------------------------------------------------
本メールはMUFGカードWEBサービスにおいて、パスワードを9桁以上
ご入力いただいているお客様へのご案内です。
※パスワードを6~8桁ご入力いただいているお客様にもご案内しておりますので、
 ご容赦ください。
------------------------------------------------------------------------

平成24年11月19日(月)にMUFGカードWEBサービスへのログイン方法を
変更いたしました。

従来、MUFGカードWEBサービスでは、お客様がパスワード登録に際して
9桁以上の文字をご入力された場合、お客様のご入力された文字数にかかわらず、
頭8桁をパスワードとして登録し、その後のご利用時に照合させていただいて
おりました。

このたび、MUFGカードWEBサービスのログイン方法変更に伴い、
同サービスのパスワードの文字数を6~8桁に限定し、ご利用時にはそのすべてを
照合させていただくことにいたしました。

パスワードご登録時に9桁以上ご入力されたお客様におかれましては、
前述のとおり、頭8桁をパスワードとして登録させていただいておりますので、
ご利用時にはこれをご入力くださいますようお願い申しあげます。(9桁以上
入力された場合はエラーとなり、ログインできませんので、ご注意ください。)

なお、パスワードの変更をご希望の場合は、MUFGカードWEBサービスの
「お客様情報の照会・変更」からお手続きいただけます。

今後とも一層のお客様サービス向上に努めてまいりますので、
引続きご愛顧を賜りますよう、何とぞお願いいたします。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
本メールは、平成24年11月19日時点で、ご入会時やWEBサービス登録時に、
Eメールアドレスをご登録いただいている
MUFGカード個人会員様にお送りしております。

▼Eメールアドレスの変更方法
1)NEWS+PLUSからMUFGカードWEBサービスへログイン。
  
https://www2.cr.mufg.jp/newsplus/
2)右メニュー「WEBサービストップ」を選択。
3)左メニュー「お客様情報の照会・変更」を選択。
4)「お客様情報の変更」メニュー内「E‐mailアドレスの変更」にて
  ご登録情報をご変更ください。

▼ID・パスワードをお忘れの方へ
ID・パスワードをお忘れの場合、再度MUFGカードWEBサービスの新規ID登録が
必要となります。以下よりお手続きをお願いいたします。
https://****.mufgcard.com/****/****/ninsyou/entry/kitei2.html?pacd=1

▼ご不明な点・お問合せ
MUFGカードコールセンター
 ナビダイヤル 0570-050535 または 03-5489-6165
 受付時間9:00~17:30(無休/年末年始は休み)
※電話番号はお間違いのないようおかけください。

※ゴールドプレステージをお持ちの方は、カード裏面に記載のフリーダイヤルを
 ご利用ください。

----------------------------------------------------------------------------
※本メールに心当たりがない方は、お手数ですがお問合せ先までご連絡いただき
 ますよう、お願い申しあげます。
※本メールの送信アドレスは送信専用ですので、このメールへの返信によるご質問、
 お問合せに対するご回答はご容赦ください。
──────────────────────────────────────
発行元:三菱UFJニコス株式会社 
http://cr.mufg.jp
〒101-8960 東京都千代田区外神田4-14-1秋葉原UDX
本メールの無断転載はご遠慮ください。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Copyright(C) 2012 Mitsubishi UFJ NICOS Co.,Ltd. All Rights Reserved.

最近特定国家からの不正アクセスが増えているようです。
このような技術が必要になること自体あまり望むべきことではないのですが、万が一自社サービスが著しく毀損されるようなサイバー攻撃が発生した場合に備えて、防衛手段をシミュレーションしておいても損は無いでしょう。

この例は専用サーバやVPSなどで一般的に用いられているiptablesというファイアウォールを用いた国別フィルタリング方法です。

  1. IPアドレスリストを入手する
    $ wget http://ftp.apnic.net/stats/apnic/delegated-apnic-latest

  2. IPアドレスリストから特定の国を抽出
    $ grep "apnic|XX|ipv4" < delegated-apnic-latest > list_country
    ※ XXが2ケタの国識別コード

  3. ネットワークアドレスを抽出して成型
    $ cat list_country | awk 'BEGIN { FS = "|"; OFMT = "%d"; for (i = 0; i < 32; i++) { pow[32 - i] = 2 ^ i } } { for (j in pow) { if ($5 == pow[j]) print $4 "/" j } }' > list_nwaddr

  4. 管理者権限になる
    $ su
    #

  5. いざ実行
    # while read line;
    do /sbin/iptables -I INPUT -s $line -j DROP;
    done < list_nwaddr

 この手順はシームレスにアクセス拒否設定まで行ったものですが、実際の適用には十分な検証とリカバリー策を講じる必要があります。

POP(110)が激しくパスワードアタックされていたのを確認しましたが
/etc/hosts.denyでも/etc/postfix/client_accessでも撃退できなかったので

iptablesでやっつけました

/sbin/iptables -I INPUT -s ***.***.***.246 -j DROP

まったく夏休み前だというのに。。

昔、エンジニアをマネジメントしてた際に口を酸っぱくして言っていたことがあります。

「"phpinfo()"を書いたPHPファイルを置きっぱなしにするな」

このPHP関数はApacheやPHPの設定情報を確認する際に便利で、バージョンを初め各モジュールのインストール状態やパスや環境変数の大半を見ることができます。この情報を基準としてプログラミング作業などを行います。

反面、これらの出力はこれからサイトに攻撃を仕掛けようとするハッカーにとっても非常に有用な情報となり、つまり「手の内」を自らさらけ出してしまうことにもなります。したがってこの様なPHPファイルの所在を知られることはサイトの脆弱性を著しく高めることになります。

プログラマやネットワークエンジニアは開発初期にphpinfoの内容を確認するためにPHPファイルを使用しますが、このファイル名が"性善説"に基づいて命名されることが多く、しかもそのままサーバから削除せずに放置されていることが多くあります。

私がざっと推測できるファイル名には以下のようなものがあります。
/phpinfo.php
/info.php
/infoinfo.php
/pinfo.php
/test.php
/pi.php
/p.php
/pp.php
/ppp.php
/php.php
/i.php
/ii.php
/test/phpinfo.php
/test/info.php

どうですか?サーバにこんなファイルが置きっぱなしになっていませんか?

実際私は、あるサイトであてずっぽでURLに/phpinfo.phpと入力したらサーバ情報が丸見えになったことがあります。あと自社または他社エンジニアがサーバに放置しているを幾度となく目撃したことがあります。

サーバ情報のダダ漏れには気をつけましょう

PS
わりとあります

Webサイトを運用してると図らずもPVの多いサイトから、アクセスが大量に流入してしまって運用に支障が生じることがありますよね?

そんな場合はApacheの.htaccessファイルに以下のような記述をすれば特定のリンク元からのアクセスをブロックすることができます。

<files ~ "\.(php|html)>
SetEnvIf Referer "^http://リンク元URL" ref_block
order allow,deny
allow from all
deny from env=ref_block
</files>

○○○○年○月○月
○○さま

本日XX:XX頃、○○○サーバに設定していた監視エージェントによって メール不正中継の兆候を検知しました。 サーバに緊急アクセスし、不正利用の様子をログなどからリアルタイムに調査したところ、一連のメール不正中継につながる原因を確認しました。

原因は"***user"というユーザアカウントを不正に利用し、メール送信の認証を通過させたことと思われます。メール認証が通過されるとスパム配信者は好きなだけメールの発送が可能です。

このサーバのユーザアカウントはOS用とメール認証用に分かれております。通常はメール認証用のセキュアなアカウントが使用されますが、利用者がOutlook等の古いバージョンのメーラを使用した場合に限り、OS用のユーザアカウントが使用される仕様になっています。ハッカーはこの仕組みを悪用してメールクライアントとして古いOutlookを偽装したものと思われます。

さらに、この"***user"というアカウント名がハッカーにとって推測しやすい名前だったこととパスワードに推測されやすいものが設定されていたと思われます。

これらの複数要因が重なって不正利用につながったと思われます。

緊急対処として***userアカウントを削除し、もう一つ****userという アカウントについても念のため削除させていただきました。 Webサービスに直接影響は及ばないかと思いますが、問題がありましたら ご連絡ください。

個人情報の漏えい事件やアカウントの乗っ取りなどの被害が後をたちません。

何らかの不正手段によってWebサイトがハッキングされて個人情報が漏えいした場合、パスワードデータが平文(非暗号)で保存される仕様になっていると、他のサービスで不正利用されるなど二次被害も予想されます。ユーザIDをメールアドレスとしているサイトが多数ありますので、使いまわしているパスワードとの組合せがあれば他のサイトでもそのまま使用できてしまいます。

日々さまざまなハッキング手法が生み出されるWebの世界では、常に完璧にセキュリティ対策を執り続けるのは不可能に近いので、「最悪盗まれても致命的なダメージとならない」という安全策も必要だと思います。

以下に既存サイトのパスワード保存形式を暗号化する改修ステップを整理してみました。

  1. 暗号化したパスワードが保管できるようにテーブルのフィールド長を拡張する
    MD5を使用する場合は最低32桁必要※
  2. ログインプログラムを改修
    パスワードを照合する際に入力値を一旦MD5ハッシュ値に変換して比較する
  3. 会員登録プログラムを改修
    入力したパスワードをMD5ハッシュ値に変換して保存する
  4. 会員情報変更プログラムを改修
    パスワードの変更があった場合に入力したパスワードをMD5ハッシュ値に変換して保存する
  5. バッチプログラムで平文パスワードを元にMD5ハッシュ変換した値に一括更新
  6. パスワードリマインダなどの機能は再発行のプロセスを仕様変更する必要あり

サービスレベルではパスワードの通知機能が使えなくなるなどのデメリットがありますが、セキュリティとのトレードオフで諦めるしかありません。

※ただしMD5やSHA1では、脆弱性が指摘されているので注意してほしい。現時点で最も手軽に使えて安全性の高いハッシュ・アルゴリズムはSHA256である。

(2014.8.19追記)
これらの暗号化方式では外部で不正流出した大量の情報によって暗号化データが解読されて出回っていることも考えられ安全とは言えないので、さらに独自の秘密キー設定も必要ですね。

↑このページのトップヘ