cat << _EOF_ > /etc/httpd/conf.d/security.conf # バージョン情報の隠蔽 ServerTokens ProductOnly Header always unset "X-Powered-By" # httpoxy 対策 RequestHeader unset Proxy # クリックジャッキング対策 Header always set X-Frame-Options "SAMEORIGIN" # XSS対策 Header always set X-XSS-Protection "1; mode=block" Header always set X-Content-Type-Options "nosniff" # XST対策 TraceEnable Off <Directory /var/www/html> # .htaccess の有効化 Al
SSL アクセラレータの価格に胃を痛めている貴兄、それが買えず SSL のためだけにサーバの台数をニョキニョキ増やしている貴兄、そうでなくとも SSL のパフォーマンスでお嘆きの貴兄のために、いろいろまとめてみましたよ。 SSLセッションキャッシュのタイムアウト設定を長くしよう SSL の負荷のほとんどはセッションの生成によるものなので、当然のようにサーバ側の SSL セッションキャッシュを有効にしておられると思いますが、そのタイムアウトの設定がデフォルトのままという方が多いのではないでしょうか。 たとえばApacheでしたら、設定サンプルのまま SSLSessionCache shm:/usr/local/apache/logs/ssl_gcache_data(512000) SSLSessionCacheTimeout 300 としている方が多いのではないでしょうか。 各サーバのデフォ
既に報道されているように、ロリポップ！レンタルサーバーに対する改ざん攻撃により、被害を受けたユーザー数は8428件にのぼるということです。ここまで影響が大きくなった原因は、報道によると、(1)「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされた、(2)パーミッション設定の不備を悪用されて被害が拡大した、ということのようです。 29日夜の時点では、攻撃者の改ざん手法について「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされて「wp-config.phpの」の設定情報が抜き出されたと説明していたが、30日午後7時過ぎの説明で、この脆弱性が侵入経路となって同社のパーミッション設定の不備を悪用されたことが原因だったことを明らかにした。 「ロリポップ」のWordPressサイト改ざん被害、原因はパーミッション設定不備
クラウドのホスティングサービスは、一定リソースの時間極課金＋通信トラフィックの従量課金が一般的です。 CPUやメモリなどのリソースは、1%しか使わなくても100％使っても時間内の料金は同じです。 一方で通信料は使った分だけGB単位などで段階的に課金される仕組みです。 この料金体系では、なるべくリソースを使い切って、且つ通信料を抑えることが最も費用対効果のある利用方法となります。 サーバーからクライアントへのレスポンス、特にブラウザーのロードとレンダリングを高速化させるために、Yahoo!のYSlowやGoogleのPage Speedを使ってチューニングを行うのと同じようなアプローチで、なるべくCPUに仕事をさせて、トラフィックを減らしてみたいと思います。 キャッシュ機能を最大限利用する Expires Apacheのmod_expiresを有効にすることで、レスポンスヘッダーにExpir
予定している機能を実現するアプリが完成するだけでWebサービスが成り立つわけではありません。 運用の最中にパフォーマンスにまつわる問題が出てくる可能性があります。 それは突然大きなトラフィックがやってきたというような時だけではありません。 知識が無いうちですと、いざ運用に乗せてみるとずいぶんとサイトの読み込みが遅いといったケースが発生することもあります。 僕はいくつかのエロサイトを管理しているのですが、 その中に月間700万PVのアクセスをいただいている「サイトA」があります。 サイトAの場合、トラフィックもそこまで無かった当初からパフォーマンスに関する問題がいくつか発生し、 その都度調べては実践で試して対策をしてきました。また、できる限り少ないリソースでの運用を目指しています。 今回はWebアプリのパーフォマンスアップ作戦として、 サイトAでの運用経験からのいくつかの方針やTipsを紹介
ここ3日間ぐらい超絶な重さだったのはサーバに物理的トラブルが発生したからではなく、単純に閲覧者数が満員御礼となり、各時間で倍増したためです。LoadAverageはひどいときで15分間の平均値「27.1」程度。瞬間最大風速だともっと高いです……明らかにまずい。 というわけで、Apacheのデフォルト設定で今までは大丈夫だったのですが、ついに高負荷サイト用の設定に変更せざるを得なくなりました。 そのため、実際に行った対処方法は以下の通り。1日30万PV近い動的サイトの高負荷を緩和させる方法として参考になれば幸いです。 まず大前提として、既にDNS逆引きや.htaccessの余計な読み込みなどは停止させていました。下記ページに書いてあることは実行済み。 ＠IT：Apacheパフォーマンス・チューニングの実践（1/2） この状態で負荷が15分平均で「27」になっていたわけです。 また、LoadA
ツイッターで「Apacheログをtail中にステータスコード部分だけに色つけしたい」ってのを見たので作ってみた。 #!/bin/sed -f ## MEMO # [0m reset # [1m bold # [3m italic # [4m underline # [5m blink # [30m black # [31m red # [32m green # [33m yellow # [34m blue # [35m magenta # [36m cyan # [37m white s/\(HTTP\/1..\"\) \(2[0-9][0-9]\) /\1 \x1b[34m\2\x1b[0m / s/\(HTTP\/1..\"\) \(3[0-9][0-9]\) /\1 \x1b[32m\2\x1b[0m / s/\(HTTP\/1..\"\) \(4[0-9][0-9]\) /\1
今回は、Webサイトやサービスをメンテナンス中にする場合に、どのURLにアクセスしても「メインテナンス中です」の画面を出す正しいやり方を、人間にも検索エンジンにも適切にする作法を主眼に解説します。 この週末の土曜深夜～日曜早朝にかけて、データセンターの設備メインテナンスのため、Web担を含むインプレスグループのほとんどのWebサイトが、どのURLにアクセスしても「メンテ中です」という表示になっていました。 なのですが、その実装がちょっと気になったので、「正しいメンテナンス画面の出し方」を説明してみます。 ※2010-01-16 Retry-Afterを指定するHeaderの指定を修正しました（コメント参照） ※2009-06-17 RewriteCondから [NC] 条件を削除しました（コメント参照） ※2009-06-16 Retry-Afterの記述をGMTに変更しました（コメント参
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
