どの言語で書いてもおかしなコードを書く奴は書く
# 書きかけです。後で編集予定
「Web屋のネタ帳」のどの言語で書いてもおかしなコードを書く奴は書くに対するコメントです。その記事にはRubyのまつもと氏のブログの引用もあるのでそちらにも対するコメントでもあります。
言語が良いコードを書けるようサポートする事はできると思います。しかし、言語だけによって良いコード（安全なコード、メンテナンスし易いコードなど）が書けるようにはならないのではないでしょうか? 言語だけでは不十分だからです。
正しいメールアドレスのチェック方法
正しいメールアドレスのチェック方法がちょっとした話題になっているようです。Web屋のネタ帳でも取り上げられていますが、メールアドレスのチェック方法自体は解説していません。ついでなので書いておきます。
「本当に正しいメールアドレスかチェック」するには実際にメールを送信して、送信されたユーザしか知り得ない情報をユーザが知っている事により確認しなければなりません。これはWeb屋のネタ帳で解説されている通りです。
Linux/Apacheを狙った攻撃 – 確認方法はmkdir 1
OpenTechPressにLinux/Apache系Webサイトを狙った正体不明の攻撃についての現状報告と気になる記事があります。
この攻撃ですが、結構話題になっていて私のブログでも先日FTPとCPanelユーザはクラッキングに注意が必要と題したエントリを公開しています。OpenTechPressの記事中にもcPanelの件は紹介されていますが、非常に気になる記述がある
問題のルートキットを検出する方法ないし、感染の確認されたサーバの洗浄法についてアドバイスが得られないかをApache Software Foundationに問い合わせてみたが、Apacheのセキュリティ対策チームに属するMark Cox氏から得られたのは、「現状で攻撃者側がサーバ群のルートアクセスを得た方法の詳細はつかみ切れていませんが、同時にApache HTTP Serverに潜む脆弱性に起因していることを示す証拠も得られていません」という回答である。
Linuxサーバにルートキットがインストールされるらしい。そしてその確認方法は
感染後は数字で始まるディレクトリの新規作成が行えなくなるとされている（例えば「mkdir 1」など）。
としています。ルートキットなのでps uaxなどとしてもプロセスリストには出てこないはずです。本当にmkdir 1でファイルが作れないなら試してみるのも良いかもしれません。ただし、mkdir 1でファイルが作れないのはルートキットのバグと考えられるます。最新版では修正済かもしれません。記事に紹介されているようにパケットをモニタリングする方法の方が確実でしょう。
rootのパスワードを推測した可能性が高いと記載されていますが本当のところはどうなのか気になります。
この攻撃のすごいところは、その手法がかなり洗練されている点です。
How a Rootkit works
1. Once the Rootkit is successfully installed, the server will sit idle until rebooted. During a server reboot, the system initialization scripts will call the infected binaries.
2. When executed, the infected binary packages use /dev/mem as a pathway to the Kernel, and then attach to several system calls within the running Kernel. This results in hidden files, broken binary packages, and random JavaScript code being seen by web visitors.
3. When the system is fully online in an infected state, the Kernel will begin serving a JavaScript payload to random web requests/visits. This occurs outside of Apache and will not be seen in any of the Apache logs. The JavaScript injection will look like:
<script language=’JavaScript’ type=’text/JavaScript’ src=’cbolw.js’></script>
http://servertune.com/kbase/entry/258/
ApacheやPHPなどのWebアプリケーションレベルで攻撃用のJavaScriptを送信しているのではなく、ルートキットがインストールされたカーネルから送信している、としています。
アプリケーションレベルはもちろん、Apacheのログにも残らず、不審なファイル/プロセスも見えないこの攻撃はかなりの脅威です。
最大のP2PネットワークはThePrivateBay
The Pirate Bay Breaks 10 Million Users
10 million simultaneous users represents a number never duplicated by any file-sharing entity. The largest P2P networks, such as FastTrack and eDonkey2000, both topped out with approximately 5 million users.
1000万「同時」ユーザだそうです。これはすごい数です。基本的にはキャッシュを効かせてリバースプロキシの効果を最大限に利用して… といった感じなのだとは思います。しかし、検索機能もあり試しに検索しても遅くないです。
もう少し覗いてい見ると日本のコンテンツはあまりないようですが、海外のコンテンツは豊富なようです。また、アダルトコンテンツが公開のページには無いようでそれが人気の理由なのかな、と思います。
確か一度閉鎖されたことがあるサイトだったと思うので調べるとありました。
http://ccr2.blog9.fc2.com/blog-entry-1761.html
今はどんな状態で運用しているのでしょうね?
コンテンツの著作権をもつ方々はこのような状態にどのように対処するか思案が必要でしょう。基本的にはDRM無しで広告収入で儲ける合法的な手法を提供するのが良いと思います。無料コンテンツはビットレートが低い物、ビットレートが高い物は有償で、といった感じが良いのではないかと思います。しかし、ビットレートが高い物を有償化しても、ビットレートの高いデータその物がまた違法に公開されるので意味が無い、となってしまうかも知れません。どう折り合いをつけるか難しいですね。
日本PostgreSQLユーザ会北海道支部 / Ruby札幌 合同セミナーのお知らせ
2月16日(土)に、日本PostgreSQLユーザ会(JPUG)北海道支部とRuby札幌の合同セミナーが開催されます。
日本PostgreSQLユーザ会北海道支部 / Ruby札幌 合同セミナーのお知らせ
私も講師の一人として参加させて頂きます。PostgreSQLとMySQLのベンチマークについて話す予定です。ご都合がよい方はお越しください。
有料と聞いていないので無料セミナーだと思います。アナウンス文には無料と記載されていないので主催者に問い合わせてみます。
追記：
現在は無料であることがアナウンス文に追加されています。
エントリのコメントに評価をつけてみました
最近のb2evolutionのフィードバック（コメント）には評価を記録できるようになっているので有効にしてみました。辛口評価コメントも歓迎です。どれが役に立ったのか、立たなかったのか、などはいろいろと参考になります。
「書かない日記」の「書かない」には
- 詳しく書かない
- あまり書かない
- きちんと書かない
の3つの「書かない」の意味があるのですが酷すぎる場合はコメントを入れていただければそのエントリ分の追加は努力します。
と書いて今思い出しました。DNS Rebinding攻撃の書きかけエントリに追記するのを忘れていました…
追記：
試しに入れてみるとフィードバックとして取り扱われるのでモデレートされます。SPAM以外は全部公開しているので安心(?)してください。公開してほしくないコメントの場合、非公開で、と書いておいてください。
Ruby on Rials – Session Fixation脆弱性の攻撃方法
前回に引き続きWeb関係のセキュリティ脆弱性がどのように攻撃されるのか解説した記事がThinkITに掲載されています。
今回はRuby on Railsの脆弱性が対象です。Ruby on Railsにもいくつかのセキュリティ脆弱性が報告されていますが、URLベースのセッションがいかに脆弱であるか解説しています。
解説対象の脆弱性
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5380
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6077
Apache httpd脆弱性のリスク評価は不十分
先日Apache httpdサーバにセキュリティ脆弱性を修正したリリースが公開されました。
例えばSecuniaのApache httpd 2.2の脆弱性ページをみると先日リリースされた2.2.8で修正された脆弱性のセキュリティリスクは低く評価されています。
http://secunia.com/advisories/28046/
ここにはmod_negotiation脆弱性の記述がありません。mod_negotiationはここに掲載されているmod_proxy_ftp,mod_status,mod_proxy_balancer,mod_imagemapと違い、多くの環境でデフォルトで有効となっていると考えられるモジュールです。
Minded Security Labs: Advisory #MSA01150108
Apache mod_negotiation Xss and Http Response Splitting
http://www.mindedsecurity.com/MSA01150108.html
によるとmod_negotiationにはXSS, HTTP Response Splittingが可能な脆弱性があり、それぞれ
Apache <=1.3.39
<= 2.0.61
<= 2.2.6
に影響があります。この脆弱性を利用した攻撃は簡単です。しかもデフォルトで有効なモジュールなので影響は大きいです。
私が管理するサーバもhttpd 2.2.6で運用している物がまだ大半だったのでmod_negotiationが有効だった物は無効化しました。
影響が大きいと考え時間差を作る為と思われますが、あえてチェンジログにはこの脆弱性の修正が記載されていなかったようです。
http://www.apache.org/dist/httpd/CHANGES_2.2.8
攻撃にはサーバ上のファイル名を操作できる必要があります。例えば、画像や添付ファイルなどをアップロードし、そのファイル名を制御できるアプリケーションを使っている場合、この攻撃可能です。CMSやブログアプリ、文書管理システムなどが脆弱である可能性があります。
Apache httpdを運用されてる方は早急に確認／対策される事をお勧めします。
Firefox chrome: URL Handling Directory Traversal
前回のエントリでFirefoxの利用をお勧めしているので未パッチのFirefoxの脆弱性を紹介しておきます。
Firefox chrome: URL Handling Directory Traversalにchromeがディレクトリ遷移攻撃に脆弱だとレポートされています。
この脆弱性を用いるとシステム内のファイルを盗まれる可能性があります。（追記に書きましたが、正確にはJavaScriptとして読み取れる必要があります。コードを見ると判りますが、JSON形式のデータファイル, prefs.js等が読みとられる可能性があります。）PoCとしてWindows上のThunderbirdのall.jsを取得するコードが公開されています。
<script>pref = function(x, y){document.write(x + ‘ -> ‘ + y + ‘<br>’);};</script>
<scriptsrc=’chrome://downbar/content/%2e%2e%2f%2e%2e%2f
%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%
2e%2f%2e%2e%2f%2e%2e%2fProgram%20Files
%2fMozilla%20Thunderbird%2fgreprefs%2fall.js’>
</script>
悪意のあるメール、ページには注意が必要です。この種の例は多数あります。Firefoxの脆弱性だけでなくFlash, Adobe Reader, QuickTime, RealPlayerが代表例です。NoScriptは必須の拡張だと言えると思います。
ところで、このようなクライアント側の脆弱性はWeb開発者には関係ない、と考えた方はいないでしょうか?このFirefoxの脆弱性ではセッションIDを盗む事はできませんが、セッションIDを盗める脆弱性もあるのです。昨年末見つかったFlashのUnversal XSS脆弱性などは最悪の部類です。
セッションIDは神経質過ぎるくらいに管理した方が良いと考えています。セミナーなどで「セッション管理は必ずセッションクッキーを使うこと」と繰り返し説明しています。もし有効期限を設定したクッキーを利用している場合、簡単にセッションIDが盗めます。セキュアなWebアプリ作りには定石があります。「セッション管理は必ずセッションクッキーを使う」は基本の中の基本です。しかし、この基本に従っていないアプリケーションも多数あります。この様なアプリケーションの場合、ユーザのセッションIDを盗まれ成りすましによる攻撃を受ける可能性があります。
フレームワークを使っているから安全、などと言うことはありません。普通のフレームワークはセッション管理に利用するクッキーの有効期限は設定可能になっているからです。Webアプリ構築はサーバ側だけでなくクライアント側の問題も考えて作らなければ安全性を維持できません。
追記：
ITMediaに関連記事が載っていました。
http://www.itmedia.co.jp/news/articles/0801/24/news014.html
PoCの見ると関数をオーバーライドして情報を取得しているのでJavaScript形式で書かれた設定ファイルでないと読み取れない。JSONのデータをCSRFで盗むのと同じ要領です。データがJavaScriptとして読み出せるファイルだけしか読みこむ事ができません。FirefoxもThunderbirdもパスワードはDBだったかな? grepしてみた限りでは特に読まれて直ぐに危険、というjsファイルはありませんでした。
一般ユーザは拡張がjarなのかそうでないのか等、気にしていないし気づく事はまずありません。jarにして問題解決ならjarにしないと読めない仕様に変更すれば良いと思います。
ちょっとずつ編集していたら結構いい加減な事を書いていたので修正しました。
FTPとCPanelユーザはクラッキングに注意が必要
Hack Attack Hits 10,000 Web Sitesによると自動化された攻撃で10000以上のサイトがブラウザやブラウザプラグインの脆弱性を攻撃するコードをホスティングさせられているそうです。
この攻撃はFTPとCPanelのパスワードをブルートフォース方式で解析、ログインできたサイトに自動的に攻撃コードを埋め込むようになっているそうです。攻撃を受けマルウェア配布に利用されているサイト管理者の多くは攻撃自体に気づいていないとしています。
自動化されているので日本語のサイトであることなど関係無しに攻撃される可能性があります。予測しやすいパスワードを利用されている方はすぐに予測できないパスワードに変更されることをお勧めします。
記事には常に変わるJavaScriptを生成するファイルが埋め込まれる、
Those servers have been infected with a pair of files that generate constantly-changing malicious JavaScript.
と書いてありますがさすがに攻撃コード自体を変更するのは難しいと思います。恐らくダウンローダーへアクセスするJavaScriptが動的に生成されているのだと思います。
どのような攻撃が考えられるか参考になるリンク
Death by iFrame
http://www.cio.com/article/135452
これを読むとマルウェアをホスティングさせられたサイトがどのように利用されるか解ると思います。
# 予想なので違っているかも知れません。
# 間違っていたら教えてください。
関連記事
Legitimate sites serving up stealthy attacks
http://www.securityfocus.com/news/11501
Attackers favor compromise over creation
http://www.securityfocus.com/brief/667
Most malware comes from legit sites, says researcher – 51% of sites spreading malicious code have been hacked
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9058599&intsrc=hm_list
攻撃に成功するとPCはボットネットに組み込まれます。この攻撃から自分（ブラウザのユーザ）を守るには
- ブラウザとプラグインを最新版にする（脆弱性がないバージョンを利用する）
- FirefoxにNoScript拡張をインストールして利用する（信頼しないサイトではiframeを無効にする）
の両方を併用することが望ましいと思います。Flash, QuickTime, RealPlayer, Adobe Readerは最低限チェックすべきプラグインです。アプリケーションが勝手にプラグイン（プロトコルハンドラも）をインストールしている場合もあるので要注意です。
上記の対策だけでは心配なので以下のチェックもする方が良いと思います。
- Windowsを安全な状態にする（Microsoft Updateで最新版の状態にする)
- 無闇にサイトを信頼しない（特に個人運営サイト）
- その他のアプリケーションも脆弱性があるバージョンはすべて更新する
個人運営サイトでなくてもホスティングサービスを利用しているサイト等ではリスクはあります。似たような攻撃ならガジェットを利用しているWebサイトでも可能です。したがってガジェットを利用しているサイトにも注意が必要です。
セキュリティアップデートに敏感なユーザでも脆弱性があるプログラムの更新を忘れている事は非常に多いようです。脆弱性情報サイトとして有名なSecuniaのPSI(Personal Security Inspector)のベータテスト、100万ユーザから得られたデータによると、95%のPCに既知の脆弱性があるプログラムがインストールされていたそうです。PSIをインストールするユーザはセキュリティアップデートには敏感なユーザと考えられますが、95%つまり100万PCのうち95万のPCには何らかの既知の脆弱性があるプログラムがインストールされていた事になります。これには驚きです。
責任あるDM送信者はどのようにメールを送信すべきか
少し前のエントリ、宛先を個人のメールアドレスに設定しているメルマガは迷惑メールに！の続きです。DM業者はどのようにメールを送信すべきか考えました。
これから書く考えはDM送信側ではなく、DM受信側の視点から考えています。
メールの種類
まず簡単にメールを分類します。受信者から見ると
- 自分のアクションが必要な個人宛メール – 問い合わせ、確認等。
- 経緯などを知らせるだけアクションが不必要なメール – 通知、記録等。
- 情報系のメール – メルマガ、ニュース等。
- スパムメール – 勝手に送ってる迷惑メール。
に分類できると思います。
受信する側から見るとそれぞれ適切であると思われる送付先アドレス設定は次の通りでしょう。
- 自分のアクションが必要な個人宛メール – To: 個人メールアドレス
- 経緯などを知らせるだけでアクションが不必要なメール – CC: 個人メールアドレス または BCC: 個人メールアドレス
- 情報系のメール – To: MLまたは発行者のアドレス
- スパムメール – 迷惑メールなので To: 個人メールアドレス でしょう
自分のアクションが必要な個人宛メール
基本的にプライベートなメール、自分のアクションが必要なメール、必ず目を通しておきたいメールです。ショッピングサイトからのメールでも「受注確認」は確認してもし自分からの注文で無い場合は「キャンセル」というアクションが必要です。この様な場合はToに個人アドレスを設定するのは当然だと思います。
アクションの必要なメールがCC、Bcc、送信元のアドレス宛で送信されてきたら困ります。
経緯などを知らせるだけでアクションが不必要なメール
基本的にプライベートなメールです。自分に経緯を連絡するCCに個人アドレスが載っているのは当然でしょう。特にアクションは必要ないが目を通すだけは通しておいて、といった場合に使う為に用意されています。
皆さんご存知とは思いますがCCとはカーボンコピーの略です。申込書等で1枚目を書くと2枚目、3枚目に写せる紙がありますが写したコピーが「カーボンコピー」です。CCとは写しを意味します。BCCとはブラインドカーボンコピーの略です。ブラインド、つまり見えないカーボンコピーの事です。メールを送信先(To)やカーボンコピー(CC)で送信したユーザに見えない様に送信するメールアドレスを設定します。
情報系のメール
非プライベートなメールです。MLやネットショップのメルマガ、ニュースサイトのメールなどがこの分類のメールになります。これらのメールは個人宛でなく、メルマガや発行者のメールアドレス宛になっている方が受信側にとって便利です。
ネットショップやニュースサイトのメールは「送信者」からするとアクション（広告クリック、商品購入)を取ってほしいメールですが、受信者からみると単なる情報メールです。個人宛に送られてきても何か必ずアクションを取る必要があるメールではありません。
スパムメール
元々スパムなので勝手に何でもするのがスパムメールです。最も効果が高いと期待できる個人宛にメールを送信するのは当然でしょう。まっとうな事業者はスパムメールの真似をする必要はありません。
どう送信すると受信側が便利か?
To, Ccに自分のメールアドレスが設定されているメール全てが個人用のプライベートなメールだと受信者は管理が容易になります。
DMを送信する場合、受信側の立場になってアクションが必要なメールかどうか判断して、個人宛とそれ以外に区別するのが理想的だと思います。しかし、個人的な好みの問題もあるので送信先アドレスを
- 発行者のアドレス
- 受信者のアドレス
のどちらかから選べるようにすれば良いと思います。
ネットショップなどの場合でも、受注確認などのメールは個人宛、利用して頂いたお客様に対して広告メールを送信する場合は非個人宛をデフォルトとして送信すると受信者側は非常に便利です。
もし全ての事業者が上記の方法でメールを送信するような状況なれば、個人宛(To, CC)に送信されるメールは必要なメールとスパムメールだけになります。
DM送信先を非個人宛にするメリット
一昔前はメールの振り分けがよく行われてきましたが、現在では減少傾向にあるのではないかと思っています。GMailの場合、メールは振り分けでなくフィルタで検索するようになっています。フィルタは振り分けと同じような動作をします。しかし、振り分けとフィルタでは大きな違いがあります。フィルタの場合は常に受信したメール全体が検索対象になります。
GMailの様なシステムでは to: yohgaki@ohgaki.net でフィルタを作成すると個人宛のメールが全部表示されます。
個人宛のメールがバルクメール（不特定多数向けに送信されたメール）であふれると不必要なメールに「迷惑メールを報告」ボタンを押して消してしまうユーザが多数いても不思議ではありません。
DM送信先を個人宛にしなければ迷惑メールとして処理されてしまう可能性を少なくできます。
メルマガを発行者アドレス宛に送信するのは発行者に不利益があるか?
メール利用者には幾つかの段階があると思います。
- メールを始めたばかりで振り分けなし
- 自分宛のメールとそれ以外に振り分ける
- 宛先、送信者、などから更に細かく振り分ける
- 振り分け自体が面倒になり振り分けなくなる
- メールを読むのが面倒になり以前ほど使わなくなる
- 迷惑メール(DM含む)が多くなり別のメールアドレスに変える
これ以外に、「捨てアド」を使う、「目的別アドレス」を使う、などの道もあります。
メルマガなどのバルクメールを送信する方にとって、1の段階のユーザにはどのような送信先であっても不利益を得る事はないはずです。2と3の段階のユーザであれば個人宛にメールを送信しないことにより不利益を得る可能性があります。私は現在4の段階ですが、この状態になると個人宛のメルマガ系のメールが非常に鬱陶しいです。実際、一部のメルマガ系のメールは迷惑メールとして処理しています。
不利益となるどうかは各段階のユーザ比率とユーザのサービス利用率で決まると思われます。正直な予想を書くと、送信先を個人宛から発行者アドレス等に変更するとDM送信者がメールから得られる利益は減少すると思います。
責任ある企業としてのメール送信の仕方
普通の企業はスパマーではありません。企業の姿勢としてメール受信者（お客様）の立場に立ってメールを送信するようにしてほしいです。たとえ広告収入が主体のメールであっても、広告をクリックしてくれるユーザを単なるメール受信者として扱うのではなく、お客様として扱ってほしいです。
普通の企業が受信者の立場でメールを送っていたなら「捨てアド」などが一般化する事もなかったかも知れません。しかし、現状は残念ながら大手であっても限りなくスパムメールに近い方法、と言われても仕方ない方法でメールを送信しているケースは少なくありません。
特に大手企業には「儲かりさえすれば良い」等と考えず、お客様の利便性(と安全性)を第一に考えたWebサイトやメールの使い方をして見本を示してほしいです。
短期的に多少の不利益があっても、誰もが認めるお客様本意のサービスを行う事は長期的に企業の利益となるのではないでしょうか。
DMにぜひ付けてほしい機能
- ワンクリック購読解除リンク
- ワンクリック送信先変更リンク
システム構成にもよりますが、どちらの機能もそれほど正しく実装すれば大掛かりな仕組みは必要ありません。リクエストが本人からかハッシュでシグニチャを確認すれば良いだけです。データベースを利用する方法やクッキーを利用する方法も考えられます。もし実装したい方でどういうことか分からない場合はコメントください。
文字エンコーディングを利用したSQLインジェクション
PHPのSQLインジェクションを実体験
http://www.thinkit.co.jp/free/article/0801/5/2/
を書かせて頂きました。この文字エンコーディングを利用した攻撃は古い脆弱性です。知っている方なら2年以上前からよくご存知とは思います。
記事のタイトル通り、文字エンコーディングを利用したSQLインジェクションを実体験できます。ご興味のある方、まだご存知でない方はぜひご覧ください。
万が一、文字エンコーディングベースの攻撃に未対策で攻撃される可能性のある方はできるだけ早く対策することをお勧めします。
UPnPルータ+Flash=深刻なセキュリティ問題
GNUCITIZENは重要なセキュリティ問題を次々に公開しているのでセキュリティに興味がある方はチェックしているのでご存知とは思いますが、
Hacking The Interwebs
http://www.gnucitizen.org/blog/hacking-the-interwebs
に非常には深刻なセキュリティ問題が解説してあります。具体的な攻撃方法などはGNUCITIZENを参照してください。日本でもいろいろ書かれるかな、と思っていたのですが予想より少ないのでブログに書くことにします。ここでは重要な部分だけ要約して書きます。
攻撃
Flashを利用したUPnPルータの攻撃シナリオは以下になります。
- UPnPが有効なルータがある
- 悪意のあるFlashをWebブラウザで参照する
- UPnPルータの設定を変更するSOAPリクエストをFlashが送信する
- UPnPルータで可能なルータ設定が変更される（乗っ取られる）
UPnPによるポートフォワード設定等には認証は必要ありません。Flashのセキュリティ脆弱性も必要ありません。ポートフォワード設定だけでも十分致命的ですが、DNSサーバ設定が変更されるとセキュリティ上致命的な問題です。
対策
UPnPルータへの攻撃を効果的に防ぐには
- ルータのUPnP機能を無効にする
しかありません。
FAQ
http://www.gnucitizen.org/blog/flash-upnp-attack-faq
から抜粋&要約
- Flashを表示するだけで攻撃される? – はい
- Flashの脆弱性に依存しているか? – いいえ
- Flashのバージョンに依存しているか? – いいえ
- 最新のUPnPルータなら安全? – いいえ
- UPnPはデフォルト有効か? – はい。ほとんど全てのSOHOルータの初期設定として有効
- UPnPは無効にできる? – はい。無効にしてください
- Flashをアンインストールすれば安全? – いいえ。他の方法で攻撃される可能性がある。
- どれくらい危険? – 非常に深刻です。UPnPを無効にしてください
備考
UPnPは必要か?というと一般的なユーザであればUPnPが無効でも困ることは無いはずです。
困るかもしれないユーザは
- ネットゲームを利用しているユーザ
- P2Pを利用しているユーザ
が考えられます。他にもあるかも知れません。
参考URL
http://www.gnucitizen.org/blog/hacking-the-interwebs
http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub-5
http://www.gnucitizen.org/blog/flash-upnp-attack-faq
http://it.slashdot.org/article.pl?sid=08/01/14/1319256
宛先を個人のメールアドレスに設定しているメルマガは迷惑メールに！
追記：
いろいろ異論がある事は分かっていながら書きましたが、ぼんやりと考えていた事は正確には伝わっていないと思います。このエントリの続きとして責任あるDM送信者はどのようにメールを送信すべきかを書きました。こちらの方が分かりやすいと思います。要はスパマーでないDM送信側は受信側にもっと配慮すべきだと考えています。その方が両方にとって利益になると考えています。
—
「迷惑メールを報告」ボタンを押させるな！
http://japan.internet.com/wmnews/20080116/7.html
によると以下が読者によって迷惑メールとして処理されてしまう代表的な原因としています。
1. 配信頻度が読者の忍耐を超えている頻度になっている
2. 内容に魅力を感じなくなり飽きている
3. 内容がミスマッチを起こしている
4. 第一印象のメルマガレイアウトが読む気をなくしている
5. 求めていないセールスプロモーションのメールである
6. 価値を感じないセールスメルマガである
7. 登録時に期待していた内容のメルマガではなかった
個人的にはTo(宛先)が自分のメールアドレスになっているメーリングリスト・メルマガが最も迷惑です。
7,8年前はメーリングリストであれば宛先にはメールリストのアドレスが記載されているのが当たり前でした。確か4,5年前くらいから宛先を個人アドレスに設定したメールリストが急増し、現在は当たり前になってしまいました。メールクライアントを使い始めたばかりのユーザでも「自分宛」、「自分にCC」、「それ以外」くらいは自動振り分けしているので、「自分宛」として送信した方が読まれる確率が高くなるのは当たり前です。
メルマガの内容など、読んでも読まなくてもよいDMと同じです。それを送り手側の勝手な意図で「個人宛」として送るのは非常に迷惑です。親展でもないのに親展とDMに書いて送っているような物です。
親展（しんてん）（英:confidential letter; private）とは、封書などにおいて、宛名となっている本人が自分で封を切って読んでほしいという意味またはそのような扱いのことである。
http://ja.wikipedia.org/wiki/%E8%A6%AA%E5%B1%95
郵便のDMもかなりの数が送られてきますが、さすがに親展でもないのに親展と書いてるDMはほとんど記憶にありません。読んだ側に「何これ?タダのDMじゃないか！」と不快に思われ逆効果だと考えているからではないでしょうか?
メーリングリスト/メルマガが個人のメールアドレス宛に送信されるのは非常に迷惑だ常々感じていました。今まで自分宛の不必要なメルマガはメールクライアントで迷惑メールとして処理させてきました。
状況を少しでも改善するために、今後Google,Yahoo,Hotmailなどの個人アドレスにメルマガを送信してきた場合は全て迷惑メールとして報告する事にします。
今や小手先のメルマガ編集方法だけでは読者の心を捕まえることができない。基本に戻ると「何が大切か」が見えてくる。
個人宛に送信するのは「小手先」テクニックの典型例だと思います。「迷惑メールを報告」ボタンを押させるな！のリストに載っていないのが残念です。
FreeBSD7はPostgreSQL, MySQLユーザにとって救いになるか?
にFreeBSD7上でのPostgreSQLとMySQLのベンチマークが載っています。
PostgreSQL 8.2.4 – 11ページ
ピーク性能でおよそ5400transactions/secほど。
MySQL 5.0.45 – 15ページ
ピーク性能でおよそ3800transactions/secほど。
Kernelの主要な部分すべてがパラレルに動作するようになったため、かなり高速（数値にして数倍）になったようです。
グラフからもPostgreSQLの方がかなり良い性能であることが分かりますが、PDFファイル（16ページ）によると
On this benchmark PostgreSQL is 35% – 45% faster thanMySQL at all loads
とPostgreSQLの方が全般的に良い性能だったそうです。PostgreSQL 8.3は確実に8.2よりもさらに良い性能を期待できると思います。MySQLも5.1や6.0を利用した方が良い性能が期待できるのかも知れません。
このPDFのベンチマークはデータベースの性能を計る為のベンチマークではなく、OSの性能を計る為のベンチマークです。データベースサーバ設定、SQL文やテーブル構成などが不明なのでデータベースの性能のベンチマークとしては参考値くらいでしかありません。MySQLのテストではMyISAMを使っていると思われますが、MyISAMならこれくらいの性能差は普通です。