HTTPレスポンスヘッダにサーバのバージョンの表示を消す なぜ必要? 潜在攻撃者への情報提供になることも。 もし使用中バージョンの脆弱性が明らかになった時、恰好の標的になるとか。 対応 nginx.confのhttpディレクティブに server_tokens off; を追加。
![Nginx導入時やること - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/7db318aa1897be5c04110c9559a3212abe165379/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9TmdpbnglRTUlQjAlOEUlRTUlODUlQTUlRTYlOTklODIlRTMlODIlODQlRTMlODIlOEIlRTMlODElOTMlRTMlODElQTgmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWU3NjdjNmMzMGRlOTg1ZmI5MmIzYjg4NGVhODBlM2Yy%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBraWRhY2gxJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1mMDA4Mzk3YzFlZTZlMTA4YTY1YmYwODZlYzgzZDRiZg%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-44Ki44Kr44OE44Kt%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D3ab051e68a71df4af2f794da90e4c964)
HTTPレスポンスヘッダにサーバのバージョンの表示を消す なぜ必要? 潜在攻撃者への情報提供になることも。 もし使用中バージョンの脆弱性が明らかになった時、恰好の標的になるとか。 対応 nginx.confのhttpディレクティブに server_tokens off; を追加。
10月に入り、9月までに起こったことをざっと振り返るというお題がどこかから聞こえてきたので、「じゃあ……」という感じで振り返ってみることとします。 わずか1週間程度でBashが大幅な進化を遂げた ~Shellshock大暴れ~ まだ現在進行形の事案ではありますが、9月下旬に発覚したBashの脆弱性に起因して、10月上旬までまだ収束していないShellshock。 Bash 4.3の例で説明すると、Patchlevel 25~30までは以下のような軌跡をたどっています。 9月24日にPatchlevel 25 9月26日にPatchlevel 26 9月27日にPatchlevel 27 10月1日にPatchlevel 28 10月2日にPatchlevel 29 10月5日にPatchlevel 30 この間に発見、修正された脆弱性は、CVE-2014-6271、CVE-2014-71
LinuxなどUNIXベースのOSで広く使われているシェル(コマンド実行環境)「GNU Bash」で2014年9月24日に見つかった非常に危険な脆弱性、いわゆる「ShellShock」の件で、IT業界が大騒ぎになっている(関連記事:「Bash」に重大な脆弱性、Heartbleed以上に危険との見方も)。 記者は先週末、取材でほとんど外に出ていたが、取材先を訪問するたびに必ずこの話題が出ていたほど。もちろん、ITproはじめIT系ニュースサイトもShellShock関連のニュースを盛んに取り上げている。既にこの脆弱性を悪用する攻撃も始まっており、ボットネットも出現している。この先どんな被害が出るのか、想像するのも困難な状況だ。 記者は、記者としてこの手のセキュリティ記事を書く立場だが、対策をとるべきインターネットサイトの運用者としての立場も持っている。自宅で固定IPアドレス(IPv4)を契約
Tweet 先週公開された bash の脆弱性について、管理されているサーバーへの影響を気にされている方が多いと思います。そこで緊急コラムとして、影響範囲の調査方法について紹介します。 bash は非常に多くの場面で使用されているプログラムであるため、 bash を呼び出す可能性のあるプログラムや場面をソースコード解析により列挙することは困難です。また、設定ファイルでの指定内容などにも依存する可能性もあり、文章でのお問合せにより漏れの無い的確な判断ができるかどうか不安が残ります。 Red Hat Enterprise Linux ( RHEL )には SELinux というセキュリティを強化するための機能が搭載されています。しかし、脆弱性の問題に限らず、システムのトラブル予防と適切な対処を行う上では、対象となるシステムの設定や挙動を事前に把握しておくことが重要であると考えます。 今回の脆弱
環境変数に仕込まれたコードを実行してしまうBASHの脆弱性が CGIスクリプトに影響を与えるか試してみたら結果は悲惨な感じに Tweet 2014年9月25日 嶋田大貴 この記事は2014年のものです 朝から Bash specially-crafted environment variables code injection attack なるもので騒ぎになっていたので、さっそく手元の Apacheで試してみました。 /hoge.cgiというURIで実行されるように、一行のメッセージを出力するだけの CGIスクリプトを設置します。いっけん、なんの入力もクライアント側から受け付けていないため危険のありようもなく見えます。 #!/bin/sh echo "Content-type: text/plain" echo echo "Hi! I'm an ordinary CGI script w
Fork爆弾(フォークばくだん)とは、コンピュータシステムへのDoS攻撃の一種で、新たなプロセスを生成するfork機能を使ったものである[1]。Fork爆弾はワームやウイルスのようにコンピュータからコンピュータへ広がることはない。これは、コンピュータ上で同時に実行可能なプログラム数あるいはプロセス数に制限があるという前提に依存したものである[2]。このような自己複製プログラムを wabbit、bacteria、rabbit programs などと呼ぶ。wabbit は単に自己複製するだけでなく、悪意ある副作用を持つようプログラムすることもできる[3]。 詳細[編集] fork爆弾のコンセプト。プロセスは再帰的にforkし、サービス停止状態に陥らせる。 Fork爆弾は非常に高速に多数のプロセスを生成して、コンピュータのオペレーティングシステムの管理するプロセスのリストを埋め尽くす。プロセス
古本屋で「Red Hat Linux Firewalls」の本を手に入れたのでパラパラしていたら、面白いiptablesのネタを見つけました。のでちょっと紹介します。 Red Hat Linux Firewalls (redhat PRESSシリーズ) 作者: ビルマッカーティ,Bill McCarty,中川和夫,ヴァインカーブ出版社/メーカー: ソフトバンククリエイティブ発売日: 2003/04メディア: 単行本購入: 1人 クリック: 5回この商品を含むブログ (4件) を見る この本は2003年発行ということで、既にいろんな記述が古くなっているのは確か。しかしiptablesやファイアウォールの基本的な考え方などはそうそう変わるもんでもないので、今読んでも参考になります。 リモートホストのiptables設定時の悩み RedHatやCentOSなどRH系Linuxのリモートホストにs
FFRI,Inc. 1 Monthly Research SELinux 再入門 -基礎編- 株式会社FFRI http://www.ffri.jp Ver 2.00.01 FFRI,Inc. SELinux再入門のすすめ • 近年、仮想化やコンテナ、AndroidなどでSELinuxを使ったセキュリティ強化が 進んでいる • 一方、サーバ用途において、SELinuxを無言で無効化してきた技術者は数多 い – Web検索のレコメンドで一目瞭然である • 本資料は、最新のSELinux応用事例を理解するための準備資料としての活 用を想定 • なお次回以降、数回に渡り最新のSELinux応用事例を調査する予定 2 FFRI,Inc. 3 SELinux再入門 • SELinuxの概要 • SELinuxのアクセス制御モデル – Type Enforcement (TE) – Role-base
必要な情報は http://heartbleed.com/ にまとまっているのですが、英語だし長いしって人のために手短にまとめておきます。 どうすればいいのか OpenSSL 1.0.1〜1.0.1fを使っていなければセーフ あてはまる場合には、一刻も早くバージョンアップして、サーバごと再起動(わかるひとはサービス単位でもOK、ただしreloadではだめなことも) SSL証明書でサーバを公開しているなら、秘密鍵から作り直して証明書を再発行し、過去の証明書を失効させる(末尾に関連リンクあり)。 サーバを公開していない場合も、外部へのSSL通信があれば影響を受けるので、詳しく精査する。 PFS(perfect forward secrecy)を利用していない場合、過去の通信内容も復号される可能性があるため、詳しく精査する。 漏洩する情報の具体例は、OpenSSLの脆弱性で想定されるリスクとして
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く