セキュリティ

やたら多いMicrosoft UpdateをVMWare Fusionで当てつつ作業。

とはいっても、元々のMTAを止めた上でルータ経由のSMTPを新MTAに流して、実際に外との導通をとってみるだけ。最初はgreylistingにひっかかってなかなか確認できなかったが、一応一通りの操作はできたので安心。内部DNSを新MTAに向けなおして実働に入る。

Postgreyは、/etc/rc.conf でホワイトリストを指定。その上で普段利用の転送サーバをホワイトリスト指定している。

postgrey_flags="--pidfile=/var/run/postgrey.pid \
        --whitelist-clients=/usr/local/etc/postfix/postgrey_whitelist_clients \
        --whitelist-recipients=/usr/local/etc/postfix/postgrey_whitelist_recipients \
        --inet=10023 -d --user=postgrey --group=postgrey --dbdir=/var/db/postgrey"

次は、Cyrus-IMAPdと併用してのSMTP Authまわりかな。まあ内部用なので割と気分的なものだし、後まわしでいいや。

Cyrus-imapdをインストールしたところから、設定を再開。まずは imapd.conf を適当に稼動しているのを見つつ操作。序盤の操作は前回同様。

# /usr/local/cyrus/mkimap
# saslpasswd2 -c cyrus-admin
# /usr/local/bin/cyradm --user cyrus-admin localhost

はまった点。

その一、認証をauxpropにしていなかった。saslauthd経由で今迄やっていたのでそうしようとしたが、よく考えるとauxpropでそのまま読んでくれた方が都合が良かった。/usr/local/lib/sasl2/Sendmail.confもauxpropに修正。

その二、ドメインが違った。外のドメインのためのメールボックスなので、saslpasswd2 -c cyrus-admin@hostname.domainname などと一々ドメイン指定しなければいけなかった。ユーザを作る際も同様。

IMAPsにするべく、SSL用の鍵を作成。

# openssl genrsa -rand /dev/urandom -out ca.key 2048
# openssl req -new -key ca.key -out ca.csr
# openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt
# openssl genrsa -rand /dev/urandom -out server.key
# openssl req -new -key server.key -out server.csr
# echo 01 > ca.srl
# openssl x509 -req -days 365 -CA ca.crt -CAkey ca.key -in server.csr -out server.crt

で、最終的なimapd.conf がこんな感じ。

configdirectory: /var/imap
partition-default: /var/spool/imap
servername: mail.fortunerinn.org
admins: cyrus-admin
sieveusehomedir: yes
subscription_db: berkeley
sasl_pwcheck_method: auxprop
sasl_auto_transition: yes
tls_cert_file: /usr/local/etc/cert/server.crt
tls_key_file: /usr/local/etc/cert/server.key
lmtpsocket: /var/imap/socket/lmtp
idlesocket: /var/imap/socket/idle

imapsyncをportsから入れて、メールボックスを仮移行

# imapsync \
  --host1 192.168.xxx.xxx \
  --user1 silver --passfile1 passwdfile1 \
  --host2 192.168.xxx.xxx \
  --user2 silver --passfile2 passwdfile2

後は、Postfix + postgrey設定だな。

UNLHA32.DLL作者による開発停止から、VectorによるLZH受付の停止まで色々とLHAに関する動きが続いている。

LHAが海外主体の製品で対応されにくいというのは、まあそうかなという気分もしなくもなく、Windowsでも日本独自の対応でLHAフォルダに対応している位な知名度なので、長年使っている愛着はあるけれど、ZIPにしたいというのならばそれはそれで止める理由も特にない。

ただ、番号体系等何か誤解しているんだろうなあ、というIPA他の対応について少々つっこみたい点があり、一応そっちの業界なもので多少なりとも補足してみる。

まず、UNLHA32.DLL作者の報告で「JVNに報告」とあるがこれは正確ではない。届出対象は「ソフトウエア等脆弱性関連情報取扱基準」（平成16年経済産業省告示第235号）により設置された、「情報セキュリティ早期警戒パートナーシップ」であり、その受付窓口がIPAとなる。

パートナーシップとして見ると各種団体が関連しており、直接的な関連だけでも、IPA(受付・分析)、産総研(分析支援)、JPCERT/CC(製品関連調整)とある。図としてはあまり見つけられなかったが、情報セキュリティ白書2009の最終ページなどに詳しい。もちろん、この先にベンダ側がおり、ウェブ運営者、国内ベンダ、海外CERT、企業内CSIRT、個人、etc..が案件ごとに関連する。

話題となっている、JVNはJVNのサイトにあるようにJPCERT/CC, IPAの共同運営する公表用のポータルサイトである。そのため、「ベンダー，JVN / IPA 等共に」というのは、JVNが判断する主体ではないので、まあJPCERT/CC, IPA(他関与した関連団体)共に、という意味に受けとっておくのが良いのであろう。この仕組み、セキュリティ専門家ですら関わらない人はほとんど知らないので、仕方がないところではある。

不受理については不明。報告の仕方によっては脅威が出せずにCVSS基本値がつかないこともある。例えば「アンチウイルスソフトが圧縮ファイルを見逃す」とかそういう具体的な脅威があやふやな方向に該当してしまったのかもしれない^[1]。

ついでに、各種番号について。JVNの脆弱性レポートの読み方を読むとわかるのだが、「JVNVU#〜」というのは海外のCERT/CC, US-CERTから来た情報である。脆弱性早期警戒パートナーシップ経由は「JVN#」、よって受付基準が違っていても仕方がない。「CVE で採用された事案 (CVE-2010-0098) 」ともあるが、このCVEは単なる共通番号であり、発行しているMIRTEに脆弱性を受付る窓口があるわけではない。ベンダやCERTが発行しようと申請すれば普通につく。実際、VN-JP(脆弱性早期警戒パートナーシップ経由)で公表されたMovable Typeの問題はCVE-2010-1985がついている。

分野の違う人に正確に書けといっても無理なのはわかっているし、正確でなくとも趣旨は十分わかるんだけど、まあ一応気になったので。補足でした。

1. この場合、「(一般的に)アンチウイルスソフトがウイルスを見逃すのは脆弱性か?」という「ユーザからすれば検知100%未満は脆弱性」「対応していないものに対応できないのは仕様通り」という論争問題になりかねないので、受理不受理がどっちに転んでもおかしくはない。 [↩]

Interop Tokyo 2010に朝から参加。

仕事上のお付き合いやリサーチなんかはさておいて、まず気になったのがShownet。今回は初の100GB回線x2系統で商用ネット接続と実にふるっている。ネットワーク図を見ると。CISCOのCRS-3(最大通信速度322Tbps)などのコアルータ、各種豪華機器がずらりと並んでいる。対外接続はYBB, OCN, ODN, KDDI, ntt.netとトランジットしているらしい。

NOCのまわりを巡るとラックに設置した機器が見えるようになっていて、ホワイトボードでの解説もついている。イベント回線確保と相互接続検証実験を兼ねているので、各所に実験的なんだろうなあという組合せが見うけられる。いや、OPは門外漢なので数割もわからないんですけど。

今回のネットワーク図は端々にある解説と大分ずれており、どういうことなんだろうと思っていたら、ISSRまわりの説明を会場内のPODにあるラックまわりで見て納得。簡単に言えば、今回のネットワークは全部仮想化されている。

それもただ「抽象化してみました」な仮想化ではなく、「高スループット、高遅延」「低スループット、低遅延」など「違うネットワーク特徴・特性を持つ仮想面」で動作している。それぞれの仮想面をスライスと呼び、Interopでは10面位使っているようだ。

「(ISPやキャリアで?)新サービスで実験がしたい時は新スライスを切る」がコンセプトらしい。写真から復元してみると各スライスはこんな感じ。

1. Hyper Visor Slice(HVC)面
2. v4,v6,100G,MPLS IX, 2/4byte AS面 (Border Slice)
3. AIO LSN面
4. Juniper LSN面
5. グローバル面
6. グローバル面+Firewall (Juniper SRXがLSN兼FW/合体変形しません)
7. 疑似攻撃生成面 (ネットテスト機材で帯域埋めてテスト/Nicterなどで監視?)
8. DS-lite面 (A10 AX26002/ゲーム機じゃなくってIPv6関連技術の方)
9. 信頼性重視面(VoIP, BFDとか。異機種間VRRPv3切り替えもここ?)
10. 6 Rapid Deployment(6rd)面 (v4-v6 translateをCisco ASR1002で)
11. Ether OAM面 (.IAGとY.1731の相互接続)
12. 800-Auto面 (クリックひとつで面移動)

もちろん、全てがIPv4/IPv6のDual Stack。IPv4のIANA枯渇があと1年少々になったのもふまえ、IPv4は基本的にLSN(Large Scale NAT)の配下や6RDなどで押しこめているのも興味深い。

他にも、光ファイバを束ねてワイヤリングを楽にしたり、NTPと同期した時計だったり、これだけ複雑な各機器の監視を行ったり、それを情報視覚化していたり、アタックを監視していたり、とトピックが満載。一応一通りは巡ったはずだが見落していることが絶対に多くありすぎると断言できる。

余談だが、久しぶりにluminさんに再会。何年ぶりだろうか、同じ業界なのに意外なほど会わないので実に懐しいものがある。私が見た時はiPadでデモをやろうとしていて、Flash問題でPBHの動画リプレイがデモできなくってと嘆いていた。話によるとおーざく氏もこられているとか。どこかのイベントでばったり逢えると良いのだが。

【漏洩なう】ユニクロ行列漏洩騒ぎのまとめ – uinyan.com

簡単に言えば「Twitter連動の企画をつくったが、参加リストの一部が見える状態になっていた」こと。でも、よく考えるとほとんど普通にTwitterで検索できる公開情報なので、ユーザとしては別に大した話ではない。個人情報か?と聞かれれば「ユニクロにとっては、将来はともかく現状は違う」と考える位。

運営側には多少言いたいこともあり、例えばOAuthでないのでTwitterのID/パスワードが取り放題(実際にしているかはともかく)だったり、謎ドメインにHTTPで情報が渡っていたりと、微妙にあやしげなことはある。騒ぐ程ではないけど、よく見ると私は参加を止めておきたい、という程度。

ユニクロのプレスリリースも出たし、対応待ちかな。

ちなみに上記のまとめサイトは、当初はID漏洩した! ハッカーならパスワードまでわかっちゃう大変! なサイトだった。「不安を煽るような表現」というのがそれ。修正が入って何より。

新たな手口を用いるワーム「オートラン」確認。AutoKeyを悪用 | トレンドマイクロ セキュリティ ブログ （ウイルス解析担当者による Trend Micro Security Blog）

ユーザが回避策を考案するように、このワームの拡散を企むサイバー犯罪者もまた、新しい手口を発案し続けます。そのため、ワーム感染の防止策を講じたユーザであっても、サイバー犯罪者の餌食となる可能性があります。そして今回、ワーム「オートラン」拡散に用いられる新しい手口として、autorun.inf内の「ActionKey」を利用した事例が確認されました。

詳しくは調べていないから不明だけど、どの程度の対策が無理になるのかは重要。流石にパッチあててパッチあててグループポリシーかけて、まで無効なら泣く。まあ、多分大丈夫だと思うんだけどなあ。

IANAのIPv4プールから1.0.0.0/8が割り当てられた時にも話題になったが、とにかく1.0.0.0とか1.2.3.4とか、マニュアルに適当に書いたりデフォルト値にする人達がいる。そういう人達にはRFC(今ならRFC3330)を読めといいたいが、事実そういうトラフィックは出てしまっているし、たまに経路情報やDNS情報としても出ているらしい。

そして、APNICが2010/2/22〜2010/3/1の間だけ経路情報を流してみて調査した結果がこちら。本来ならばほとんど何も出ないはず。

Traffic in Network 1.0.0.0/8

ところが、蓋をあけてみると1.0.0.0/8全体で平均160Mbpsのトラフィックがあり、バーストトラフィクとして1〜30秒間で200Mbpsとか300Mbpsとか、あげくの果てには3秒間で860Mbpsとか10秒間で750Mbpsとか。かなりのトラフィックがあったようだ。

(元)上司のA氏はDDoSの偽装IPのリプライが戻ってきているんじゃないかと分析していたが、パケットの90%弱がUDPパケットだし、バースト部分についてはその可能性がかなり高いと思う。ただ、それを除いても定常的に一定の数値が出ているし、平均160MbpsのすべてがDDoSだとも思いにくい。

ちなみに、細かくトラフィックを見ていると、多かったのは 1.1.1.0/24 (平均78Mbps,ピーク352Mbps)、1.4.0.0/24(平均12Mbps,ピーク44Mbps)、1.2.3.0/24(平均11Mbps, ピーク127Mbps)、1.0.0.0/24(平均7Mbps,ピーク30Mbps)、1.10.10.0/24(平均3Mbps, ピーク8Mbps)といったところ。

ピークが激しいのはDDoS分が含まれるとしても、1.1.1.1 とかが多そうな 1.1.1.0/24 や、1.2.3.4 が多そうな 1.2.3.0/24 はあきらかに設定で流れてきていそうだ。1.4.0.0/24 というのはピークが低い割に流れてきているんだけど、これも何か有名な機器で設定されてしまったとかあるんだろうか。

いずれにせよ、このエリアはゴミトラフィックが流れてきやすいということで。debogonも結構かかったみたいだし、割り当てを受ける方も覚悟が必要ですね。

1. yebo blog: 中国にあるDNSルートサーバが不審な動きをして停止
2. 中国国内に配置される、DNS ルート･サーバーが閉鎖された？ « Agile Cat — Azure & Hadoop — Talking Book

全世界に分散配置されているDNS Root Server。I Root Serverの分散先の一つ、中国においていたサーバが突然嘘の答えを返しはじめたらしい。

FaceBook, Twitter, YouTube等を調べると嘘をついたそうなので、検閲ですね。閉じたネットワークの出口でするならまだしも、全世界に影響する形で、しかも委託されたサーバでするあたりがえげつない。一応「やってないよ!」と主張はしているようですけど…。

当然のように、中国のI Root ServerはAnycastから外された様子。けれども、Root Serverの地図を見る限りまだ他にも中国・香港内には DNS Root はあるようだし、他の管理団体の動静が注目されます。

そして、ニュースにならんのね、この類…。インターネット接続を先進国の重要インフラに含めても良い位に、インターネットは日々の生活の裏で活用されている。DNSはその中でも間違いなく基幹となる重要サービスの一つだ。これがなければメールもウェブもまともに動かない。んだけどなあ…。

今回の事件は立派に、DNS Root Hijack という最悪の事態の一つ。メールの宛先もウェブの行き先も全部好きにかえられる。情報を隠すも盗み見るも、見にきた人を攻撃サイトに誘導するも自由自在。是非こういうことがあった、と報道をして欲しいものだ。

• [BOOK] SELinux by Example: Using Security Enhanced Linux
• [GAME][PS3] アーマード・コア フォー アンサー PLAYSTATION 3 the Best

やっと仕事上参考資料が欲しくて求めたSELinuxの本が到着。国内の本は軒並旧いバージョンで、最近のOSでいじろうとするとReference Policy未対応で参考にならない。オンラインもほとんど英語だけ。ならば、まとまっているだけそのあたりの専門家が書いた本の方が有望。

とはいっても、直接読む時間はないのでそのまま他の人にスライドしそうな予感。

情報視覚化があるというので参加。NICTのnicterが一番見栄えと機能的に面白そうだった。

サンシャイン牧場 情報「露出」問題のまとめ | 鳩丸よもやま話

要するに、こういうことか。

• 基本的なミスにより、セッション管理の方法が不味かった
• mixi IDを推測(簡単)さえすれば、一人づつ個人情報の一部が見えた。これが「個人情報漏洩のおそれ」

問題なのは、mixiがアプリケーションを審査しているわけではなく、また契約上外部に飛ばした後の行動については制限できない(していない?)ため、安全性を強要することができないという点。

審査をするとどうなるかは AppStore で見ているので、妥当な選択ではあります。ただ、これだけ人数が多いのにぐだぐだなソフトウェアで課金しようという動きが出てくると…ちょっと怖いものがありますね。課金する場合の別契約とか特約とかオプションでないのかなあ。そっちで政府系の公募のように「事前に第三者のセキュリティ審査を受けろ」とするとか。

IPv4アドレス枯渇対応セミナー「kokatsu.jp アクションプラン2010」 (発表資料)

上司に許可をとって出かけてくる。IPv4のIANAプール枯渇は後2年程に迫っているし、そこから1年ちょっと位すれば多分JPNICの枯渇も迫ってくるだろう。その時になって騒いでも遅いし、業界的には備えておくべき事。というわけで、社内の取り組みとは別に、自主的に最近IPv6まわりを覗いている。学生時代から無駄にJANOGとかを見ているわけではないし、仕事柄一通りの通信シーケンスとパケット構造位は押さえているので、予備知識だけはある。

なお、IPv4が限界であり、時期はともあれデュアルスタックを経由して、最終的にはIPv6に移行するしかない、LSN等の技術を駆使して伸ばすにも限界がある、というのが参加者の基本的な共通認識としてあるということを記しておく。

今回知った重要なポイントは「NTTのNGNがIPv6対応することにより、一般に普及するとISP他は考えている」「NTTのNGNがIPv6対応する2011年4月が色々な計劃のマイルストーンになる」「LSN(Large Scale NAT)は思った以上に歓迎されていない」という三点。

まず、前者。今迄にもアーリーアダプタ向けにIPv6接続サービスを提供しているところはあるが、そういった所は基本的に自前の網を使っている。だが、一般へは基本的にNGNを通じてIPv6を提供するということになる。NGNとISPの相互接続方式についてはまだぶれがあるが、現在のフレッツ網の延長の感覚でエンドユーザには見えるという方向にするのだろう。

正直なところ、勘違いしてNTT-NGNとIPv6化は基本的に直行した話だと思っていたので、NGNによる集約はインパクトがあった。そして、このNGNにより、一般に対してIPv6が提供される日付が決まってくる。それが2011年4月だ。

アクションプランによると、ISP等は基本的にこの日をデッドラインとしてIPv6への対応を推進しているし、SEやASPもこの日を意識して顧客の様子を見ながた対応というシナリオになっている。よって、現行機器を入れる場合もこの日付を見込んでIPv6について考えておく必要がある。

とはいっても、いきなりIPv6が使えるようになってはいそうですかと言うわけではない。エンドユーザへのインパクトは最小にする必要があるし、機器設定の変更などが無いようにすることが至上命題となる。

と、言うわけでIPv4はLSN(Large Scale NAT)を使いできるだけ延命させつつ、IPv6+IPv4 privateの形におさめるのが、ISPには重要となる。ビッグローブの岸川氏の資料の11ページがわかりやすいが、基本的にLSNはコストが高い上に、ポート番号による同時接続数の制限やDoubleNATによる問題^[1]等で回線品質が劣化する。劣化する一方でかかる管理・運用コストは高い。ISPとしてはなるべく使いたくない技術というわけだ。

予定では、IPv4 Global+IPv6(Option)→IPv4 Global回線の受付停止&IPv6+Ipv4 Private回線受付開始→IPv4 GlobalをIPv6+IPv4に移行→IPv4 Globalの料金見直し、となっている。徐々にIPv4の状況をNGNにあわせてIPv4 Privateに移動しながら、IPv6のサービスを先行展開することで利用メリットを増大させ、最終的にはデュアルスタックでどちらも使えるが IPv6 の方が料金が安いしメリットがあるよという状態に持っていきたいわけだ。その先におそらく IPv6 native があるのだろうが、そこは通信モデムによるアクセス回線と同様に、IPv4 private になった時点で利用者数を見ながら細々と続けていくという事なのだろう。

そもそも論では、IPv6を設計した時にIPv4→IPv6の移行期間はもっとあるという前提だったらしい。IPv4 Globalが潤沢にあるうちに移行していれば、LSN等の問題がからむ事もなくより容易であったろう、との事。実際には鶏と卵の問題で明確なメリットが無く普及せず、枯渇ギリギリまで粘った結果がこれだよ、となりいらん苦労が重なっているわけですな。2011年4月というラインがあるが、これを過ぎるとどんどん面倒な事が増えるので、対応コストを考えると先にやってノウハウを確保しながら動かしつつなおして行くのが推奨策のようだ。

なお、最後に中村修氏による「大人ならそうですよねー」という大ちゃぶ台返しがあり、非常にためになった事を付け加えておく(笑) そこが重要だというのは理解したが、文章化してまとめきれる自信が無い。他のレポートが上がっているだろうから、そちらを参照して欲しい。

1. 簡単に言えば、2重にNATするとUPnPなどが効かないので、ネットゲームやメッセンジャー等(パケットペイロードにIPアドレスを含むプロトコル)が繋がらなくなる。 [↩]

相方に言われてふと見たページで、母親のセキュリティインシデントを発見。夜中だったので、電話では無くメールで、取るべき対策方法を加えて送信する。

父親は流石元研究者^[1]だけありそれなりにITリテラシがあるので安心していたのだが、流石に掲示板の書く中身までは対応しきれないようだ。KIDS goo あたりで教えておくべきか。

それにしても、(おそらく現状では)実害は無いとはいえ、見た瞬間本当にヒヤリとしてしまった。こうなると妹夫婦が心配だな。

1. というか、私をこの道にはめた張本人。 [↩]

Inside Yahoo!メール 第1話「迷惑メールとBotnet」 (Yahoo! JAPAN Tech Blog)

ここ4,5年程のボットばらまきスパムメールに関する良いまとめ。昔は 3rd relay を許可しているメールサーバを探しだして使っていたのが、今は 3rd relay 用のサーバをボットでたてまくっているわけです。

ボットネットの裏には商売人がいて、時事ネタで罠メールをばらまき罠サイトに複雑に誘導、被害者達をボットに感染させる。そして、そうやって出来たボットネットを時間貸して貸し出している。迷惑メールを送る方は安く借りて大量にばらまいてウマウマ。記事にあるように、たとえひっかかる率が0.0.0001%だとしても、大量にばらまけば利益になる。

かくして我々はスパムメールに埋もれ、膨大なメールの配送のための回線費用を間接的に支払っているわけです(溜息)

私の場合1996年位の第一次インターネットブームあたりから使いはじめて、何度か移転しているものの、メールアドレスはもう回収不可能なほどにばらまかれてしまっている。そのため、数日放置しておくと1000通たまることもある。

そうして見るとApple の Mail.app ではサブジェクトでスレッドを寄せてくれるので、各所から同じ題名でまとまっているのがよくわかる。ベイジアンフィルタで8,9割型は防げているので処理もそれほど手間どらない。graylisting などの手法を使えばいいのだが、主なメールの受取先が共用のサーバのためあまり派手に手をいれられない。まあ、処理できているうちはまだなんとかなるので、10倍程増えたら対策を考えることにしようと思っている。

ソフトウェアの弱点(脆弱性)情報を発見して独立行政法人情報処理通信機構(IPA)に届出をすると、ソフトウェアの開発者やウェブサイト運営者に連絡して、なおすよう取り計らってくれる届出制度。

その規範となる情報セキュリティ早期警戒パートナーシップガイドラインの2009年度版で、簡単に言えば「◯◯のウェブサイトで使っている製品のバージョンが、脆弱性があるってよく知られたバージョンのままなんですけど…」的なウェブサイトの届出について、注意喚起を出してまとめて終了とバルクで取り扱えるようになった。

早速IPAで「EC-CUBE」の古いバージョンを利用しているウェブサイトへの注意喚起を出したわけだが、このEC-CUBEという製品の開発者側での公表内容が少し特徴的だった。

IPAから推奨されているEC-CUBEのバージョンアップには、現在のところ高度に専門的な知識が必要になりますが、脆弱性対策に限っては、該当箇所の修正によって対応することができます。

旧バージョンをご利用の方でバージョンアップが難しい方も、脆弱性情報の対象バージョンを参照の上、必ず対策は行って下さい。

これだけでは何を言っているのかわかりにくいが、まとめると。

1. ウェブのショッピングカートシステムとして稼動させているので、事業者から見るとうかつな「バージョンアップ」は難しい。
2. そこで、「バージョンアップ」ではなく「該当箇所の修正」で逃げてください、と告知。
3. 実際に細かい情報まで見にいくと、脆弱性ごとに「ここをこう書きかえればOK、と修正する箇所が具体的に書かれている」
4. 修正情報はプログラマにおなじみの diff などの差分ではなく、「手動でこうなおせ」というもの。

手慣れたプロならば、差分を取るなりバックアップシステムで確認しながらするなりでバージョンアップも可能だし、diff があれば一気に対応もできる。そこをあえて、普及している対象を考えてローテクな場当たり対策に徹しているところが、公知する立場と対策をして欲しい立場の違いということで実に興味深かった。この目線をしっかりと覚えておきたいものだ。