セキュリティ

Dan Walsh’s Blog – selinux-polgengui

SELinuxで、デーモンやCGIのサンドボックスポリシーを作成するためのGUIツール。Fedora 15で使えるらしい。

SELinuxは使ったことはあるが、デーモンを隔離しようと1からポリシーを作ろうとしただけでも、非常に広範囲な知識と、旧い文献と違う箇所がありすぎる現状と、入念な調査・検証が必要だった。GUIでさくさくできるようになるならば、これ以上に望ましいことはない。

しばらく試してみて、Safari Standとの相性を除けば特に問題もなさそうだったので1Passwordを同社ウェブページから購入。一応クーポン利用で20%引きでした。Paypal分の金利を考えても、act2価格の半額程度になるのかな。

葉っぱ日記を参考に、ApacheでX-XSS-ProtectionとX-Content-Type-Optionsを指定した。

<IfModule headers_module>
        Header append X-XSS-Protection 1
        Header append X-Content-Type-Options nosniff
</IfModule>

書いておくと、一部の攻撃が通用しにくくなるので、まあ気休めですね。

iPod touchで1Password/同Pro(無料時期に入手した。)を遊ばせておくのももったいないと思い、スタンダードなパスワード管理ソフトウェアであるし、試してみることにした。

まずは、従来使っていたKeePassXからデータをエクスポートして1PasswordのインポートでKeePassXを指定して実行。XML形式では駄目で、txt形式でエクスポートしないといけないという事に気がつくまで、すこしはまってしまった。

インポートしたとはいっても、乱雑にIDとパスワードとメモの組があるだけの情報なので、1Password本来のカテゴリわけにはまるわけもない。そもそも、1Passwordはウェブブラウザ^[1]と連携して入力するところにあるので、URIや入力対象の要素情報が無いと実質的に使いにくい。

このあたりは徐々に入力しなおして移行して行くしかないだろう。iPod touchとの同期もシンプルだった。フォルダ単位で同期するかどうか選べるので、最重要な情報は携帯しないでいられるのが嬉しい。

1ヶ月程試用できるようなので、問題がないようならば適当にクーポンを探して払うか。

1. そういえばいつの間にか「携帯」同様に「ブラウザ」でほぼ一意に通じる。本来は注釈が必要な言葉が代表一位だけで占められ、結果として他の項目で補足が必要となるというのは面白いものだ。 [↩]

新常識になる「トークナイゼーション」 – 欧米セキュリティ事情の新潮流：ITpro

カード番号の一部をでたらめな数字にして保管する方法。ハッシュ等と違い数学的根拠が無いらいので、もしかしたら再現しての挑戦も不可能なのかな。

XXXX-XXXXで潰すマスキングとの違いは、アプリケーションの改修の必要性がないのと、でたらめな数値なので利用されても問題ないあたり。

結局マスキングデータとしての利用なのか。元との関連性が無いというあたりで色々と使いにくそうに見える技術なのだけれども、PCI DSSがらみなのでそういう必要性があって出てきた手法なんだろうし。

いったいどういう所で利用される技術なのか、気になる。

人生設計について重要な住宅設計について考えましょうよ、というごく普通の訪問営業。内容についてはひとまず会社にとってどのような利益があるかを聞いた上でまあそういう考えもあるよねと合意し、できるだけ情報を出さないように拒否しようとしていたら押しが強く、次回1回だけ話を伺えれば、という所に。そこで取り出されたヒアリングシート…え、そこまで話さなければいけないの? 初対面の人にそんなことまで話せないのは普通だと思うんですけど。なるほど、困ると。

押しかけた初対面の相手に対してプライバシーポリシーひとつ出さないで個人情報の山を聞こうとするとか心理的に容認できないので拒否していたら、別な人まで登場。結局押されて座敷で話すこととなり、当初予定していた情報の最終防衛ラインを護っていたらさんざんぱっら責められた上で、方向をかえてしぶしぶ提出。なんとか最低限の情報に留めて出す。

で…結論は。そうか、そんなに買わせたかったのか。私は対象ではないということで「それをはやく言えば1分で帰った」と責められ、もう来ないと捨て台詞まで置かれた上で帰られる。あの調子で押し売るなら凄そうだ。

経過時間、実に5時間。今日やるはずだった仕事はほとんどできず終い。何より当初の話ではWin-Winだったのに、結局 Lose-Lose。つまり三方全損。

そして何より、さんざん言いたくないと言ったことを明かす羽目になり心の傷をつくった上で肉体的にも疲労。もう勘弁。

エフセキュアブログ : そのApacheのモジュールは本物ですか？

Apache moduleの改ざんによるインシデント。前提で侵入済みがあるんだろうけれども、これは嫌だ。インティグリティチェックがいるか?

パーティション切ってRead only mountはあまりやりたくないし…素直にファイルシステムで変更属性をたてて頑張るのがいいのかな?

OWASP ZAP

OWASPが公開する。オープンソースなParosベースのウェブ脆弱性スキャナ…なのは良いのだが、名前がどうにも。

完璧なコンピュータ様が脆弱性を作りこむことなどありえないわけで、もし脆弱性があるとすればそれはコミーでミュータントな反逆者の仕業に違いないわけですよ。だからスキャナなんてものではなく、むしろ担当者を抹NO CARRIER

やたら多い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も結構かかったみたいだし、割り当てを受ける方も覚悟が必要ですね。