更新: 2010年1月12日15時35分頃 「GumblarによるWeb改ざん被害が相次ぐ、ユーザーも被害防止対策を (internet.watch.impress.co.jp)」。結構大きな企業のサイトがやられているのが興味深いですね。各社きちんとお知らせを出していますが……。 原因・経緯（12月26日更新） ストリームを担当する制作会社のパソコンが、「Gumblar（ガンブラー）」亜種により、コンピュータウィルスに感染し、パソコンの情報が第三者により盗まれ、対象サイトのファイルが改ざんされました。 以上、Hondaホームページ　「ストリーム」サイトに関する報告とお詫び より ４．原因・経緯 ハウス食品「採用ホームページ」を担当する制作会社のパソコンが、コンピューターウィルス「Gumblar（ガンブラー）亜種」に感染し、パソコンの情報が第三者により盗まれ、対象ページが改ざんされました。

ModSecurityとは Breach Security, Inc.は9月24日(米国時間)、ModSecurityの最新版であるModSecurity v2.5.10をリリースした。 ModSecurityはWebアプリケーションファイアウォール(WAF)のひとつで、Apacheのモジュールとして動作する。リクエストヘッダや引数・表示するコンテンツなどから攻撃や脆弱性を検出し、悪意あるユーザの攻撃からWebアプリケーションを守ることができる。セキュリティフィルタは最初から用意されているもの以外にも、Luaを使用して自分で作成することもでき、柔軟な設定をおこなうことが可能だ。 v2.5.10でのおもな変更点は次のとおり(CHANGES_2.5.10.txtより一部を抜粋) Windowsビルドでのmlogcをクリーンアップ フィルタ中の詳細なメッセージを"Unknown error"に置

去る 8 月 27 日の 18:00 UTC に、minotaur.apache.org に不正な侵入があったらしく、十数時間オフラインとなった (Apache Infrastructure Team の blog 記事、V3.co.uk の記事、エフセキュアブログの記事より) 。 侵入が 27 日 18:00 UTC で、復帰が 28 日 10:53 UTC 頃。Apache Infrastructure Team の blog 記事によれば「ダウンロードファイルに影響が及んでいるか証拠はないんですが、ユーザはいつでもデジタル署名をチェックしてほしい。」とのこと。

以前の記事「$HOME/.ssh/configを活用していますか？」では、設定ファイルを少し頑張って書けば普段のSSHライフが随分変わりますよ、と紹介しました。今日はその続編です。前回よりマニアックな設定を紹介します。 2段以上先のサーバにログインする Dynamic Forward機能を使う 共通設定をまとめて書く 2段以上先のサーバにログインする 目的のサーバにログインするために、踏み台的なサーバを経由しないと入れない環境があります。例えば、dmz経由でないとDBサーバにログインできない環境、というのは良くある構成でしょう。 このような場合に、ProxyCommandパラメータが利用できます。 上の設定で「ssh db1」とすると、sshでdmzに接続し、dmzから192.168.0.201へログインします。これを利用するには踏み台サーバにncコマンドが必要ですが、大抵の環境にインスト

1. あるディレクトリ内でSSL通信のみ許可する SSL通信以外のアクセスの場合，HTTP Error 403 Fobbidenを返す． .htaccessに以下を記述 SSLRequireSSL 2. httpをhttpsへリダイレクト http://example.com/path/to/ 内から https://example.com/path/to/ へリダイレクト RewriteEngine On RewriteCond %{SERVER_PORT} !^443$ RewriteRule ^/path/to/(.*)?$ https://%{HTTP_HOST}/path/to/$1 [L,R] 3. 特定のファイルのみSSL通信を行わせたい場合 http://example.com/path/to/file.php のみ， https://example.com/path/to

=pod =head1 NAME NAME genrsa - generate an RSA private key genrsa - RSA 秘密鍵の生成 =head1 SYNOPSIS SYNOPSIS B<openssl> B<genrsa> [B<-out filename>] [B<-passout arg>] [B<-des>] [B<-des3>] [B<-idea>] [B<-f4>] [B<-3>] [B<-rand file(s)>] [B<-engine id>] [B<numbits>] =head1 DESCRIPTION DESCRIPTION The B<genrsa> command generates an RSA private key. genrsa コマンドは RSA 秘密鍵を生成する。 =head1 OPTIONS OPTIONS =over 4

全体の流れ まず、SSL/TLS を導入するために何が必要なのかをまとめておきます。 それぞれの作業を「誰が」行うのかを意識してください。 サーバ管理者が RSA 秘密鍵を生成します。 サーバ管理者が RSA 秘密鍵を元に CSR (Certificate Signing Request: 証明書要求) ファイルを生成し、認証局に送付します。 認証局が受け取った CSR を元にサーバ証明書を生成し、サーバ管理者に送付します。 サーバ管理者は受け取ったサーバ証明書を Web サーバに組み込みます。 登場人物は「サーバ管理者」と「認証局」がいます。 「サーバ管理者」は「Web サーバに SSL/TLS を導入したい人」です。 「認証局」は VeriSign など、証明書を発行している企業です。 RSA 秘密鍵生成 まずはじめに、OpenSSL で RSA 秘密鍵を作成します。 root 権限は

ここでは、推奨されるパッチ適用手順を解説しているが、この手順は、システムやサービスのバージョンアップにも当てはまる。システムやサービスに変更を加えるような場合は、このような手順にしたがい実施することが望ましい。 ア) パッチの入手 前述した「1）セキュリティ情報収集」の各リンク先などから入手したセキュリティ情報に基づき、対象システムに必要なパッチがあるかを判断し、必要であれば対象のパッチを入手する。通常、セキュリティアドバイザリ情報中にパッチ入手先が記載されている。また、パッチはベンダ/ソフトウェアのオフィシャルサイトもしくはベンダーから郵送されるCD-ROMなどから入手する。 イ) テスト環境への適用 直接本番機へパッチを適用するのではなく、本番機と同じ環境を持つテスト環境マシンを用意しておき、そのマシンにパッチを適用し、適用後も対象システムに問題が発生せずに通常サービスの提供が実施可能

OpenSSH SSH デーモン 設定ファイル 書式 /etc/ssh/sshd_config 説明 sshd (8) は/etc/ssh/sshd_config(あるいはコマンドラインから-f オプションで指定したファイル) から設定を読み込みます。このファイルの各行は"キーワード 引数"の形式になっており、空行あるいは # で始まる行はコメントとみなされます。空白を含む引数はダブルクォート で囲んで表現することもできます。 使用できるキーワードとその説明は以下の通りです(キーワードでは大文字小文字は区別されませんが、引数では区別されることに注意してください): AcceptEnv (受け付ける環境変数) クライアントから送られた環境変数のうち、どれをそのセッションのenviron (7) にコピーするかを指定します。クライアント側をどのように設定するかについてはssh_config (

sshへのトラフィックが増加傾向にあるのは知っていますか？ パスワードに安易なものや一般的な単語等を使ってる人はいませんか？ インターネット定点観測システムによると、sshへの不正トラフィックは増加傾向にあります。 攻撃者はおもに辞書によるパスワードへの攻撃を試みており、安易なパスワード(admin / secret 等) 非常に危険ですってか、sshは単に経路を暗号化しているだけなので、盗聴によらずパスワードが 推測できれば攻略されてしまうのはあたりまえですね。 (ネタ元：警察庁、SSHを利用した不正侵入行為の増加を警告) 通常のsshユーザはパスワード認証を使わなくてはならない理由は存在しませんので、 速やかに公開鍵認証に切替えた上でパスワード認証を禁止しましょう。 /etc/ssh/sshd_configのPasswordAuthenticationをno にするだけ...ではなく、

ウェブサーバーのセキュリティ上、やっておいたほうがよい必須の設定等はありますか？ ・ポートは80以外開けていないし、通していない。 ・常に最新のapacheバッチをあてている。(yum updateですが・・) 特にウイルス感染系の処置を何もしていないので、心配です。 そのようなことが書いてあるサイトでもいいので教えて下さい。