PHPのセッションIDは暗号論的に弱い乱数生成器を使っており、セッションハイジャックの危険性がある : DSAS開発者の部屋
下記の文章は、PHPのセッションIDに対する攻撃についてFull Disclosure MLに2010年に投稿された文章を和訳したものです。訳者の意見としては、攻撃の成立条件は極めて厳しく、そこまで深刻度は高くないと考えています。 とはいえ、疑似乱数列への攻撃がどのように行われるのか、その可能性を示す文章は比較的珍しいもののように思います。暗号論的に安全な疑似乱数とは何か、なぜ必要なのかといった内容を間接的に教えてくれる面白い文章だと感じましたので、今回翻訳してみました。 （以下、原文の和訳です） 原文：http://seclists.org/fulldisclosure/2010/Mar/519 Advisory (c) 2010 Andreas Bogk <andreas () andreas org> Product:PHP Version:5.3.2 以降 脆弱性の種類:暗号論的な
MySQL 5.6 でのレプリケーション遅延は危険 : DSAS開発者の部屋
MySQL 5.6 の検証中に MySQL 5.5 とは違うタイプのレプリケーション遅延を見つけたので紹介します。 MySQL のレプリケーションのおさらい MySQL のレプリケーションは次のような仕組みで動作しています。 マスターの更新トランザクションが binlog を書く スレーブの I/O スレッドがマスターに接続し、 binlog を取得し、 relaylog を書く. マスター側はスレーブからの接続を受け付けると(dump スレッド)、指定された場所から最新までの binlog を転送する binlog が追記されるのを待ってさらにスレーブに送る スレーブのSQLスレッドが relaylog を再生する MySQL 5.5 でよくあったレプリケーション遅延 マスターは並列してトランザクションを処理して、最終的にコミットした順で反映されれば問題ないようになっています。 一方、ス
負荷試験ツール「インターネット破壊」を公開しました : DSAS開発者の部屋
負荷試験ツール インターネット破壊を公開しました。 こちらはずっと社内で負荷試験に使用していたツールです。社内で使用していたものなので、ソーシャルアプリ向けの機能などが多少追加されていますが、もちろんんそれ以外のWebアプリケーションでも使用できます。 基本的にはApache JMeterのようなWebアプリケーションむけのシナリオ負荷試験ツールです。コマンドラインオペレーションだけで実行でき、サーバー上で簡単に負荷試験を実施できるのが特徴です。POSTリクエストなどはもちろん、レスポンスのチェックやUserAgentの偽装、ランダムな値をパラメーターにセットする機能も実装しています。 注意: 当然ながら自分の管理下にないサイトに向けて負荷試験ツールを実行するのは絶対にやめてください。非常に危険です。 物騒な名前がついていますが、これは完全にわたしの小児的感性の趣味によるところです。地震で
repcached-2.0リリースのお知らせと、超簡単なサンプルコード : DSAS開発者の部屋
repcached-2.0(memcached-1.2.5ベース) をリリースしましたのでお知らせします。 http://lab.klab.org/modules/mediawiki/index.php/Repcached (日本語) http://repcached.lab.klab.org/ (英語) 今回の目玉はマルチマスタ構成のサポートです。 以前のバージョンはマスタ/スレーブ構成だったので、必ずマスタへ書き込まなければいけませんでした。そのため、接続先のサーバがマスタなのかどうかをクライアントが判別しなければいけなかったり、keepalivedなどと併用するなどの工夫が必要でしたが、今回のバージョンではその必要がなくなります。両方のサーバに対してデータを書き込むことができるようになったので、かなり使いやすくなったと感じています。 repcachedはパフォーマンスを最重視している
repcached 1.0リリースの補足とちょっとしたHowTo : DSAS開発者の部屋
前のエントリでrepcached 1.0のリリースをお知らせしました。 開発の動機はプロジェクトページにちょっと書いたのですが、たいせつなことをひとつ書き忘れていました。 repcachedを開発しようと思い立ったのは、ひとことでいうと「キャッシュサーバといっても止まらないようにしたい」、別ないい方をすると「サーバ管理者だって夜はぐっすり眠りたい」というものでした。 そしてふたりのエンジニアが自ら社内向けに企画・提案してrepcachedの設計・開発にとりかかり、プロダクション環境で使えるようなレベルのものができあがりました。 これがrepcachedを開発した動機です。 さて、昨日はrepcachedをみなさんに向けて公開しました。 いうまでもなく、repcachedを社内に閉じて外部には公開せずに使い続けるという選択肢もありました。 でもわたしたちはそうしませんでした。 わたしたちはい
DSAS開発者の部屋:特集記事『Linuxロードバランサ構築・運用ノウハウ』を公開します
『Linuxロードバランサ構築・運用ノウハウ』を公開します！ これはWEB+DB PRESS Vol.37の特集記事としてDSASチームが執筆したもので、技術評論社様の許可を得て今回公開するはこびとなりました。 一口でいうと、「Linux＋IPVS＋keepalivedを使って、冗長構成(Active/Backup)のロードバランサを作るまで」の解説記事で、 サーバ負荷分散一般についてのはなし Linuxでロードバランサを作ってみる ロードバランサを冗長化 といった構成になっています。 みなさんがLinuxロードバランサを導入・構築・運用する際の一助になれば、DSASチームとしてもうれしい限りですので、是非、ご覧になってください！ 第1章 サーバ負荷分散概論 特集のはじめに なぜサーバ負荷分散をするのか？ サーバ負荷分散の実現方法 ロードバランサのいる構成 ロードバランサはなにを元に分散す
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
