オンプレミスからクラウドへの移行をはじめ、ハイブリッドクラウド環境をシームレスに保護しながら、クラウドの利点を実現します。 詳しくはこちら
![Apache HTTP サーバに存在する脆弱性「OptionsBleed」](https://cdn-ak-scissors.b.st-hatena.com/image/square/f546cfd781cca3ecfa63ff699eecc277a1fc571a/height=288;version=1;width=512/https%3A%2F%2Fwww.trendmicro.com%2Fcontent%2Fdam%2Ftrendmicro%2Fglobal%2Fja%2Fresearch%2Fblog-thumbnails-for-old-articles%2Fmitre-engenuity-blog-image.png)
概要 Apache の設定について共通化できるセキュリティ設定とその各項目についてまとめた。 設定例 必須設定 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対策 Trace
ApacheやNginxとopensslのバージョンを指定するとおすすめの暗号スイートなど、SSL設定ファイルを表示してくれるMozillaのサイトがあります。 https://mozilla.github.io/server-side-tls/ssl-config-generator/ これを使えば安全な暗号スイートのみを使ってる設定などが簡単に生成されますので、この通りに指定すれば良いです。 Apacheの場合はデフォルトでは暗号スイート設定の記述はなかったと思いますが、下記の3つは表示通りに指定しておくのが良いかと思います。 SSLProtocol SSLCipherSuite SSLHonorCipherOrder Oldを選択すると、古いブラウザにも対応してる暗号スイートを含めます。ただ暗号強度が弱いものが含まれるためサイトのアクセス傾向をみて古いブラウザのアクセスが無いのであれ
先日の日記『「10日でおぼえるPHP入門教室 第4版」はセキュリティ面で高評価』では、同書のアップロード機能のセキュリティ面を評価しつつ、「もうひと踏ん張り確認して欲しい内容がある」として、画像XSSの可能性について指摘しました。では、これを直せば完璧かというと、実はそうとも言えないという微妙な問題があります。それは、アップロード先の場所とファイル名の問題です。 ファイルをアップロードするディレクトリ: ドキュメントルート下の /php10/doc/ ファイル名: ブラウザから送信されたファイル名そのまま これらのうちファイル名の拡張子については、gif/jpg/jpeg/pngのみを許すという、いわゆるホワイトリスト検査がされていて、またgetimagesize()関数により、画像ファイルであることの簡易的なチェックをしています。しかし、この状態では、環境によってはアップロードしたファイ
Apacheの設定をディレクトリ単位で制御するためのファイル「.htaccess」。管理者だけではなく一般ユーザーにとってもお馴染みのファイルですが、急に設定を変更しようとしても、書き方を忘れてしまってすぐには出来ないという方も多いかもしれません。 「.htaccess Snippets」はそのようなときに参照したい便利な設定集です。有用な.htaccessの設定が、やりたいこと別に簡潔にまとめられています。覚えておけばいざというときに役に立つこと間違いないと思われます。 見慣れた設定も確認できる .htaccess Snippetsの内容は、リライト / リダイレクト、セキュリティ、パフォーマンス、その他に大別されていて、例えばセキュリティカテゴリの中では、アクセス制御の書き方などが説明されています。 全て禁止で一部許可する場合。 Order deny, allow Deny from
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 「細かいと言うより長いよね」 はじめに こんにちは。ATS の脆弱性を発見した小柴さんや ATS に HTTP/2 の実装を行っている大久保さんと同じチームの一年目、匿名社員M さんからいじられている新人です。今回ありがたい事に、こういったすごい方々を含めモヒカン諸先輩方より「何か書かないの?」「いつ書くの?」という数々のプレッシャーお言葉をいただきました。 というわけで、SSL/TLS の Session 再開機能に関して書いていこうかと思います。 SSL/TLS は機密性、完全性そして真正性に対して安全な通信を行うための仕組みです。しかし、この仕組みは暗号技術を多用し特に接続において複雑なプロトコルを用い、Client, Se
SSL 3.0の脆弱性 CVE-2014-3566 aka POODLE の対応でSSL v3を無効にする必要あり http://www.itmedia.co.jp/news/articles/1410/15/news054.html http://googleonlinesecurity.blogspot.jp/2014/10/this-poodle-bites-exploiting-ssl-30.html https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/ https://www.openssl.org/~bodo/ssl-poodle.pdf Apache httpd + mod_sslなら http://httpd.apache.org/docs/2.2/mod
はじめに こんにちは植木和樹です。本日は社内フォワードプロキシサーバー構築手順の備忘録になります。 お客様と案件のやりとりをする際にクラスメソッドではredmineやBacklogなどチケット管理システムを使うことが多いです。redmineを使う際には弊社グローバルIPからしか繋がらないようIP制限をかけています。redmine以外にも開発中・検証中のサーバー環境にはIP制限をかけてクローリングや第三者からの閲覧を防ぐことも多いです。 社内LANからこのredmineにコメントを書き込む際には問題ないのですが、出先や在宅勤務中はコメントが書き込めず困ってしまいます。そのためクラスメソッドにはVPN環境が用意され、社内LANに接続して作業ができるようになっています。 しかしVPN経由でIP制限のかかったサイトに繋ぐには下記のような手順をふむ必要があります。 Macbookに入っているVMwa
OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO
Apacheの設定で Order deny,allowとか Satisfy anyとか、なんだか意味わからん人のために。僕はずっとわかってなかった。 基本 Apacheのアクセス制御には、 ホストによる制御 (Order,Allow,Deny) ユーザ認証による制御 (Auth*, Require) の2通りがある。 Satisfyは、2通りあるアクセス制御の両方を満たす必要があるかどうかを決定する。デフォルトはSatisfy all。Satisfy anyなら、どちらか片方満たせばよい。 Order http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#order Order deny,allowは、全てのホストからのアクセスを許可する。 Order allow,denyは、全てのホストからのアクセスを拒否する。 Order d
2012年8月に、総務省のスマートフォンを経由した利用者情報の取り扱いに関するWGにおいて、最終とりまとめとして、「スマートフォン プライバシー イニシアティブ - 利用者情報の適正な取り扱いとリテラシー向上による新時代イノベーション」が公開されました。 ドキュメントが作成された背景としては、スマートフォンには行動履歴や通信履歴等の様々な利用者情報が蓄積されており、アプリケーションがそれらに対してアクセスを行い、外部へ送信している場合がある。 一方、利用者情報の利用目的が不明瞭で、十分な説明が無いまま取得・活用するアプリケーションも増加しており、利用者の不安が高まっているといった事があります。 このドキュメントは、アンドロイドの話だけではなく、スマートフォン全体の話になっています。またアプリ開発者だけではなく、キャリアや広告事業主、アプリケーション配布サイト、アプリケーション紹介サイト、と
このエントリでは、Cookieを用いたhashdos攻撃の可能性について検討し、実証結果と対策について報告します。 はじめに既に当ブログで報告の通り、hashdosと呼ばれる攻撃手法が公表されています。HTTPリクエストのパラメータ名に対するハッシュ値を故意に同一にした(衝突させた)ものを多数(数万程度)送信することにより、Webサーバーを数分程度過負荷にできるというDoS攻撃手法です。 先の記事でも説明しているようにPOSTパラメータ(HTTPリクエストボディ)に多数のパラメータを仕込む攻撃が典型的ですが、POSTパラメータ以外のパラメータを用いた攻撃についても検討しておかないと、防御漏れの可能性が生じます。 そこで、POSTパラメータ以外を用いた攻撃方法について検討します。 POST以外に多数のパラメータを仕込めるかPOST以外に多数のパラメータを仕込む場所があるでしょうか。候補となる
PHPを初期設定のまま使うと、いろいろ問題が起こる可能性があります。今回は、問題の発生を未然に防ぐ設定法をいくつか紹介します。(編集部) 初期設定のままでは良くないところもある ここ数回はPHP実行時の設定について解説しています。実行時設定を変更する方法として、PHPの設定ファイル(以下php.iniファイル)に設定を記述する方法と、Apache HTTP Server(以下Apache)の設定ファイルにPHPの設定を記述する方法の2つがあり、前回はその使い分けについて解説しました。 サーバ全体で標準の設定値としたいものはphp.iniファイルに、バーチャルホストやURLごとに変更したいものはApacheの設定ファイルに記述する、という使い分けの指針も示しました。 今回は、php.iniで設定できる項目、つまりサーバ全体にかかわる設定項目の中でも、初期設定のままにしておくことがあまり適切で
このエントリでは、hashdos対策としてのmod_securityの導入と設定の方法を説明します。CentOS環境でyumによりApacheを導入しているサイトに対して、yumによりmod_securityを導入するというシナリオで説明します。 はじめに既に当ブログで報告の通り、hashdosと呼ばれる攻撃手法が公表されています。HTTPリクエストのパラメータ名に対するハッシュ値を故意に同一にした(衝突させた)ものを多数(数万程度)送信することにより、Webサーバーを数分程度過負荷にできるというDoS攻撃手法です。まだhashdosによる攻撃事例は報告されていないようですが、既に攻撃コード(PoC)が公表されているため、いつ攻撃が起こっても不思議ではない状況です。 PHPも影響を受けるプラットフォームであり、PHP5.3.9で対処予定となっていますが、まだPHP5.3.9はリリースされて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く