Mozilla SSL Configuration Generator Redirecting to the updated SSL Configuration Generator…
Redirecting to ssl-config.mozilla.org...
Mozilla SSL Configuration Generator Redirecting to the updated SSL Configuration Generator…
PHPが動くApacheのコンテナ環境をhaconiwaで1万個動かそうとしてみた - 人間とウェブの未来
RubyKaigiに行くと本にサインを求められるすごいエンジニアが書いたhaconiwaというmruby製のコンテナエンジン（コンテナ環境構築の基盤ツール）があるのですが、少し試してみようと思って、とりあえず1サーバ上に1万コンテナぐらい動かそうとしてみました。久々に今回は自分の作ったOSSではなく、OSSの検証レポート的な記事になります。 haconiwaは僕の好きなOSSの一つで、それはなぜかと言うと、 haconiwaでコンテナを作る際に、haconiwa実行環境にはコンテナの要素機能が全て入っている必要はない 必要なコンテナの要素機能を簡単に組み合わせて、自分が実現したいコンテナ、あるいは、それに準ずる環境を作れる haconiwaによるコンテナ定義をRubyのDSLで表現でき、動的な設定や組み合わせの設定を簡単にかける ということができるからです。その特性から、CentOS6のよ
mod_mrubyとngx_mrubyの最新のアーキテクチャとリファレンス公開（まだまだAdvent Calendar募集中です） - 人間とウェブの未来
この記事は、mod_mruby ngx_mruby Advent Calendar 1日目の記事になります。 現在既に13日分が登録されており非常に楽しみです。といっても、まだ12日分空いていますので今もなお募集中でございます！是非是非ご登録を！ 今日は1日目なので、mod_mrubyとngx_mrubyの最新のアーキテクチャとリファレンス公開ということで、2014年11月に情報処理学会のジャーナルに採録され公開されたmod_mrubyの元になるアーキテクチャの論文を下記のリンクからPDFで無料で公開します。どうぞ皆さんタブレットにPDFを保存したり印刷したりして読んでみてください。謝辞には馴染みの方々のお名前を書かせていただきました。 最新のアーキテクチャ論文 論文 [pdfダウンロード] mod_mruby：スクリプト言語で高速かつ省メモリに拡張可能なWebサーバの機能拡張支援機構 ス
mod_process_security - Apache上でスレッド単位で権限分離を行うファイルのアクセス制御アーキテクチャ（前半編）
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 ソース 「スレッド単位で権限分離を行うWebサーバ上のアクセス制御アーキテクチャ」として、3月15日16日に開催されたIA/IOT/SITE/ISMS合同研究会で発表してきた。概ね、好評だったように思う。ただ、やらないといけないことはいくつかあるので、そこはこれから大学で適宜やっていこうと思う。 まずは、この論文の概要としては、 大規模Webサーバ上で大多数のユーザー（仮想ホスト）を一つのサーバで処理するようなマルチテナント環境において、ユーザー間のセキュリティを担保するためのアクセス制御を行う技術 である。（これまではsuEXECが使われていた） これは、Webサービスが高度化していく時代において、低価格化がより望まれてきており、以前に増し
PHPでDNSリバインディング攻撃への対策を行う場合のチェック式はこれで問題ないでしょうか? - お世話になります。以前の質問の回... - Yahoo!知恵袋
PHPでDNSリバインディング攻撃への対策を行う場合のチェック式はこれで問題ないでしょうか? お世話になります。 以前の質問の回答の1つに、DNSリバインディング攻撃への対策を行う必要があるというものがありました。 http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q12126860057 PHPでの実装としては、Hostヘッダのチェックを行えば良いという解釈に基づき、 次のようなコードを考えました。 if(!isset($_SERVER['HTTP_HOST']) || $_SERVER['HTTP_HOST']===$_SERVER['SERVER_NAME']) Hostヘッダがある場合、$_SERVER['SERVER_NAME']と一致するかチェックしているコードです。 しかし、私の環境ではDNSリバインディング攻撃を
ApacheやNginxのSSL関連のおすすめ設定を生成する便利サイト - cakephperの日記(CakePHP, Laravel, PHP)
ApacheやNginxとopensslのバージョンを指定するとおすすめの暗号スイートなど、SSL設定ファイルを表示してくれるMozillaのサイトがあります。 https://mozilla.github.io/server-side-tls/ssl-config-generator/ これを使えば安全な暗号スイートのみを使ってる設定などが簡単に生成されますので、この通りに指定すれば良いです。 Apacheの場合はデフォルトでは暗号スイート設定の記述はなかったと思いますが、下記の3つは表示通りに指定しておくのが良いかと思います。 SSLProtocol SSLCipherSuite SSLHonorCipherOrder Oldを選択すると、古いブラウザにも対応してる暗号スイートを含めます。ただ暗号強度が弱いものが含まれるためサイトのアクセス傾向をみて古いブラウザのアクセスが無いのであれ
ApacheのAddHandlerはセキュリティ上の懸念から使用すべきではない - このブログはURLが変更になりました
元ネタはこちら。 Apache AddHandler madness all over the place Gentoo Bug 538822 どういうことか 次のような指定は危険である。 AddHandler php5-script .php この時に指定される.phpはファイル名の末尾である必要はない。例えば、 aaa.php.html bbb.php.pngなどもphp5-scriptとして解釈されてしまうのだ。これは.XXX.YYYと複数の拡張子が書かれた場合、.XXXと.YYYもAddHandlerの対象となることが原因。 ちなみに次のような場合にはphp5-scriptとして解釈されない。 ccc.php_foo (.php_fooとして解釈されるため) ddd.php_bar.html (.php_barと.htmlとして解釈されるため)実はこのことはApacheのドキュメン
Apacheチューニング
2. チューニング • KeepAliveの設定 • コンテンツの圧縮転送 • 不要モジュールの削除 • シンボリックリンク先の参照許可 • TimeOutの設定 • DNS問い合わせの無効 • .htaccessの無効化 • Prefork MPMのチューニング • Worker MPMのチューニング 3. KeepAliveの設定 ディレクティブ 値 説明 KeepAlive On 同一クライアントに対し コネクションを使い回す MaxKeepAliveRequests 1ページあたりの平均 的なコンテンツ数 + α 1つのKeepAliveで受け付け るリクエスト数 KeepAliveTimeout 1ページ当たりの平均 的な転送時間＋α クライアントからのリクエ ストがなくてもKeepAliveを 維持する秒数 5. 不要モジュールの削除 デフォルトでは多くの拡張モジュー ルが組み
複数のWebサーバでSSLセッションキャッシュを共有してSSL処理を高速化(Apache + mod_ssl + mod_socache_memcache) - 元RX-7乗りの適当な日々
HTTPS(SSL利用)サイトがSEO的に優遇されるトレンドで、世間的にもHTTPS接続でサイト運用するサービスが増えてきています。 これが、ハイトラフィックサイトになってくると、このフロントエンドでSSL処理させることが負荷的にもなかなか辛いのです。 で、Apache 2.3以降では、Shared Object Cache Providerとして、memcachedが選択できるようになっています。 この仕組みを利用して、Apacheとmemcachedを並べることで、各サーバでユーザのSSL Session Cacheを共有しながらHTTPSリクエストを負荷分散できる構成を作ってみました。 WebサーバでSSLオフロード 常時SSLを利用したWebサイトを運用するために、SSLアクセラレータといったアプライアンス製品だとか、ソフトウェアだとApacheやNginxのSSLモジュールを使う
ApacheでCGIを使う場合にpreforkを使った方が良い状況とそのチューニングについて - 人間とウェブの未来
かなり今更感の漂う内容ではありますが、意外と情報が分散していたり、Apache2.4系を考慮した場合に足りていない内容があったのでこのエントリで一度まとめてみようと思います。 CGIを使うようなシステムでそれなりにアクセスが集中するサーバ、例えば日々のピーク時のApacheのbusyワーカー数が1000になるようなサーバで、かつ、それを処理可能なマシンスペックのサーバであることを前提にしています。 ApacheのMPMとCGI実行アーキテクチャの復習 ApacheでCGIを使う場合には、MPMとCGI実行アーキテクチャの組み合わせは大きく分けて以下の2つに分ける事ができます。 worker(event) + mod_cgid prefork + mod_cgi Apacheの2.4系から特にworker(event) + mod_cgidのモデルが推奨されているようです。また、2.4系では
websec-room.com - websec room リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
最新（2013/12/26）のmod_mrubyとngx_mrubyのパフォーマンス
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 論文の執筆や発表の準備で最新のmrubyに追随できていなかったのですが、ようやくmod_mrubyとngx_mrubyを最新版のmrubyに対応させました。対応した項目は以下となります。これでmrubyの最新版でも動くようになりました。 mrb_stateが持っていたirepテーブルの削除に対応（バイトコードのGC化） symbol関連のAPI変更に対応 ARENAの持ち方を修正 パフォーマンス比較をするには良いタイミングなので、最新版のmod_mrubyとngx_mrubyのパフォーマンスを計測しました。 最新のパフォーマンス比較 計測方法はいつも通りシンプルなものなので、「この条件だと大体こういう差がでる」という意味での参考情報として見て
Why is FastCGI /w Nginx so much faster than Apache /w mod_php? - ESchrade - Kevin Schroeder
ESchrade – Kevin Schroeder Developer, author, musician, global domination theoretician I have a new post on using Jetty with PHP-FPM that, if you think this is interesting, you should check that one out. (this post has a sister post on Apache’s event MPM compared to Nginx) I was originally going to write a blog post about why NginX with FastCGI was faster than Apache with mod_php. I had heard a w
Apacheのmod_cacheを利用して静的コンテンツをキャッシュさせた話（追記あり）
Fusic 平田です。 前のエントリの延長のようなそうでもない話です。 あらすじ ある日「サーバがレスポンスをろくに返さない」と連絡があり、すわ障害発生かとおもむろにsshクライアントを立ち上げ、接続。 この時点でよくあるのは サーバがハングしていたりして接続できない なんとか繋がるもののすごく重い・ロードアベレージが鬼のように高い その他障害などでエラーが発生しているとかディスク障害が起きてるとかblog書いてる場合じゃない事態とか といったあたり（書いてる場合じゃない事態はそうそう起きません）なのですが。 普通にssh接続できるし、dstatで眺めてもCPUなりメモリなりで刺さってるわけでもなし。 はて。。。と思いつつ とかやってみると、滝のように流れまくるアクセスログ。 「どうしてこうなった」はさておき、とにかく対応せないかんという話で。 前のエントリの流れを汲むなら「よしvarni
ロリポップのサイト改ざん事件に学ぶシンボリックリンク攻撃の脅威と対策
既に報道されているように、ロリポップ！レンタルサーバーに対する改ざん攻撃により、被害を受けたユーザー数は8428件にのぼるということです。ここまで影響が大きくなった原因は、報道によると、(1)「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされた、(2)パーミッション設定の不備を悪用されて被害が拡大した、ということのようです。 29日夜の時点では、攻撃者の改ざん手法について「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされて「wp-config.phpの」の設定情報が抜き出されたと説明していたが、30日午後7時過ぎの説明で、この脆弱性が侵入経路となって同社のパーミッション設定の不備を悪用されたことが原因だったことを明らかにした。 「ロリポップ」のWordPressサイト改ざん被害、原因はパーミッション設定不備
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - phanan/htaccess: ✂A collection of useful .htaccess snippets.
IPA テクニカルウォッチ：「サーバソフトウェアが最新版に更新されにくい現状および対策」：IPA 独立行政法人 情報処理推進機構
httpsだからというだけで安全？調べたら怖くなってきたSSLの話!？ - Qiita
共用サーバにおけるSymlink Attacksによる攻撃とその対策について - さくらインターネット創業日記
http://whmscripts.net/misc/2013/apache-symlink-security-issue-fixpatch/