Vulnerability in GNU glibc Affecting Cisco Products: February 2016
On February 16, 2016, an industry-wide, critical vulnerability in the GNU C library (glibc) was publicly disclosed. Multiple Cisco products incorporate a version of glibc that may be affected by the vulnerability. The vulnerability could allow an unauthenticated, remote attacker to trigger a buffer overflow condition that may result in a denial of service (DoS) condition or allow the attacker to e
JAWS-UG初心者支部でAWS Billingについて話しました - ぎょりの魚醤日記ʚ( ˙ ꒳ ˙ )ɞ
こんにちは。アステカ文明についてまだ学びきれていないけど引き続き、、、なぎょりです。 2016.02.16 (Tue) に汐留住友ビルD2Cさんのオフィスで開催された「JAWS-UG初心者支部」に初参加、登壇してきました。 jawsug-beginner.doorkeeper.jp 今回はAmazon Web Services実践入門、いわゆる「緑本」の内容がテーマということで、著者として登壇の依頼をいただきました。当日現地で伺ったところあまりまだ読まれていないようだったので、ぜひポチっとお願いしますね(๑́•∀•๑̀)ฅ 発表内容については他の方のブログにある程度任せるとしてｗ登壇したのでその内容を残します。ぜひこれから「登壇を依頼された！」みたいな方や「LTやってみたい」という方に少しでもお役に立てればと思っています。 登壇の依頼 1ヶ月前ぐらいにFacebook Messengerで
レスポンス比較によるDNS Anti-spoofing
Twistedの勉強がてら、並列にN回(以上)クエリをして、結果がTTLを除き一致することを確認するスプーフィング対策を考えてみた。 （商用DNSアプライアンスとかでは既に実装されてたりするんだろうか？） 前提 現在の主なDNSのspoofing手法は、リゾルバの使うUDPソースポート番号やクエリ先ネームサーバーを様々な方法で予測あるいは強制して、クエリIDがヒットするまで偽のパケットを送り続ける。 ポート番号のようなDNSの外側に付加された追加エントロピーを攻略されると、DNSパケットのクエリIDは16ビットしか無い。しかもしばしば攻撃者はブラウザやメーラー経由で能動的に好きなタイミングでクエリを発生させることができる。そのため、DNSSECなどで保護されていないDNSレスポンスは比較的短時間で攻撃成功率が現実的になる。 そのため、0x20のような追加エントロピーや、攻撃を検出してTCP
4.5. DNSSEC を使用した DNS トラフィックのセキュア化 Red Hat Enterprise Linux 7 | Red Hat Customer Portal
セキュリティーガイド 1. セキュリティーの概要 Expand section "1. セキュリティーの概要" Collapse section "1. セキュリティーの概要" 1.1. コンピューターセキュリティーとは Expand section "1.1. コンピューターセキュリティーとは" Collapse section "1.1. コンピューターセキュリティーとは" 1.1.1. セキュリティーの標準化 1.1.2. 暗号化ソフトウェアおよび認定 1.2. セキュリティーコントロール Expand section "1.2. セキュリティーコントロール" Collapse section "1.2. セキュリティーコントロール" 1.2.1. 物理的コントロール 1.2.2. 技術的コントロール 1.2.3. 管理的コントロール 1.3. 脆弱性のアセスメント Expand s
キャッシュDNSサーバのDNSSEC対応
今回は、DNSSECの検証機能を有効にしたキャッシュDNSサーバを構築・運用する方法について解説する。 DNSSECにおけるキャッシュDNSサーバの役割 キャッシュDNSサーバは、名前解決を依頼するクライアントと権威DNSサーバの間に立ち、反復検索を行うサーバである。DNSSECにおいて検証を担当するものを「バリデータ（Validator）」と呼び、多くの場合キャッシュDNSサーバがバリデータを担当する。 第2回でも簡単に説明したが、DNSSECの検証を行うためには信頼の連鎖の起点となる情報が必要となる。これを「トラストアンカー（Trust Anchor）」と呼ぶ。バリデータとなるキャッシュDNSサーバは、トラストアンカーを起点に、DNSSECの信頼の連鎖を検証していくことになる。 DNSの階層構造における委任の起点がルートゾーンであることから、一般的にはルートゾーンの公開鍵情報をトラスト
EDNS0
○ DNSトラブルシューティング IPv6,DNSSECなどで、DNSサーバの要件が大きくかわっていました。 ISP運用なら不可避な内容なのでメモを。 □ DNSの512byteの壁 元来、DNS問い合わせ・応答は(ヘッダを除く)データサイズが512byte以下でないといけませんでした。*RFC1035 当時のインターネットの信頼性を考慮した時、1パケットでうけとれるサイズ=576byteに入るようにしていたのでした。*RFC791 ＊Aレコードのラウンドロビンで8レコード以上を見ないのはこのサイズが限界になるからのようで IPv6の登場、DNSSEC対応、spam対応のTXTレコード、DomainKeysなどなどDNSデータを使ったやりとりが ふえてきたことにより、DNS応答のデータサイズが512byteというのは現実的ではなくなってきました。 で、512byteの壁をこえるための手法が
BIND 9のセキュリティ対策
DNSは広く公開するサービスであるため、その運用には細心の注意が要求される。BINDを攻撃者から守るには何をすればよいか。今回はBINDで行うべきセキュリティ対策を紹介する。（編集局） もともとがパブリックなサービスであるDNSは、ゾーン情報を広く知らしめるための手段であり、そこへアクセスする対象も不特定多数です。一方キャッシュサービスは利用対象者を限定することができます。セキュアなサービスを提供するには、まずBINDの働きを整理し、それに応じた方策と万が一の場合の善後策を準備する必要があります。 DNS全般の対策 キャッシュサーバとゾーンサーバの分離 キャッシュサーバとゾーンサーバとでは、セキュリティに対するアプローチもサービスを利用する対象も違います。サーバを物理的に、できればキャッシュサーバはNAT配下などのクローズドな環境で利用することが望ましいといえます（図1）。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
