DMARC「p=reject」 設定後の変化 - Qiita
はじめに DMARCポリシーをp=rejectに変更しました。DMARCに取り組もうとしたきっかけや、取組の経緯は、以下のブログに書いてます。 DMARCとは そもそもDMARCとはって話はいろいろな人がいろいろな記事をあげてくれているので割愛します。このへんの記事や、Youtubeがわかりやすいです。 DMARC「p=reject」設定後の変化 DMARCは認証されていないor認証が不十分なメールを受信側のメールサーバーで検疫or削除してもらうことができる設定です。ポリシーをquarantine （検疫）以上にしておけば、非正規なメールが送信先ユーザーのメールボックスに届きにくくなります。 弊テナントではDMARCポリシーを設定する前は、弊社ドメインになりすましたと思われるメールが 1日10,000通前後 送信されていることが観測されていました。 それが、DMARCポリシーをp=quar
DNSの不正使用手法をまとめた技術ドキュメントの公開 - JPCERT/CC Eyes
はじめに Domain Name System（DNS）はインターネットサービスを使用する上で欠かせない基幹サービスであり、DNSが関連するセキュリティインシデントへの対処は、健全なインターネットを維持するために重要です。本ブログでは、JPCERT/CCもメンバーとして参加しているFIRSTのDNS Abuse SIGが、2023年2月に公開したDNS Abuse Techniques Matrixについて、その日本語版をJPCERT/CCが主体となり作成および公開したので紹介します。 2023年2月、FIRSTのDNS Abuse SIGが公開したDNS Abuse Techniques Matrix - DNS Abuse Techniques Matrix https://www.first.org/global/sigs/dns/DNS-Abuse-Techniques-Matri
ぼくのかんがえたさいきょうのDNS
本記事に関連した講演が、本日13:45～開催されるIIJ Technical WEEK 2016で行われます。(該当のセッションは16:45～予定の「DNSにまつわるセキュリティのあれこれ」です)ストリーミング中継も行いますので、是非ご覧ください。 このごろ DNS ってこうげきをうけることがおおいんだって。 DNS は「どめいんなまえしすてむ」のことで、ドメインのなまえをきくと IP アドレスをおしえてくれたりするしくみだよ。わるいひとたちが DNS をいじめてつかえないようにしちゃうと、インターネットであそべなくなっちゃう。 だったら、それにまけないつよい DNS をつくればいいよね。 どんな攻撃が来るのか ……すいません、読みにくいですね。漢字使います。なお、漢字で書いたところで中身は「ぼくのかんがえたさいきょう」に違いありません。 DNS に対する攻撃は大きくわけると、2つ。DoS
#OCJP-131: 日本国内で悪用された「DNSアンプ攻撃」について
■はじめに まず、「DNSアンプ攻撃」が分からない方はこちらをご覧下さい。そしてDNS「オープンリゾルバ/Open Resolvers」についてはこちらのリンクに纏めて説明しています。 「DNSアンプ攻撃」と「オープンリゾルバ」の関係は↓ Open Resolvers pose a significant threat to the global network infrastructure by answering recursive queries for hosts outside of its domain. They are utilized in DNS Amplification attacks リファレンス： Open Resolver Project openresolverproject.org 大体４月中旬から少しずつ日本国内に悪用された「DNSアンプ攻撃」のIPレポ
Google Public DNS over HTTPS を試す | IIJ Engineers Blog
【2018/11/16 追記】 本記事は、2016 年 4 月に Google Public DNS サーバに実装された、実験的な DNS over HTTPS プロトコルについて紹介しています。DNS over HTTPS プロトコルはその後 IETF の doh ワーキンググループにて標準化が進められ、2年半後の 2018 年 10 月に RFC8484 として出版されました。本記事で紹介したプロトコルは RFC8484 に規定されたプロトコルとはいくつもの点で異なっていることにご注意ください。 Google Inc. が公開 DNS サーバを運営していることはご存知でしょうか? Google Public DNS と呼ばれるこの公開 DNS サーバは、”8.8.8.8″ という特徴的な IP アドレスで全世界のインターネットユーザに対して無料の DNS サーバ(フルレゾルバ)を提供し
(dnsmasq への追記あり) CVE-2015-7547 glibcのgetaddrinfo に stack buffer overflow の脆弱性
受ける この情報は下記から CVE-2015-7547: Critical Vulnerability in glibc getaddrinfo https://isc.sans.edu/forums/diary/CVE20157547+Critical+Vulnerability+in+glibc+getaddrinfo/20737/ getaddrinfo() を使ってる場合に、影響を受ける可能性があります。 すでに PoC は公開されていています。 https://github.com/fjserna/CVE-2015-7547 ここに公開されている CVE-2015-7547-proc.py とかを root 権限付きで実行すると、この手の buffer overflow を引き起こすパケットを返してくる DNSキャッシュサーバもどきになってくれます。 これをローカルで動かした状態
GNU Cライブラリの脆弱性（CVE-2015-7547）についてまとめてみた - piyolog
2016年2月17日に公開されたGNU Cライブラリの複数の脆弱性の内、CVE-2015-7547*1は任意のコードが実行可能であるとしてGoogleが報告しています。ここではこれら脆弱性に関連する情報をまとめます。 脆弱性情報 Vulnerability Note VU#457759 glibc vulnerable to stack buffer overflow in DNS resolver JVNVU#97236594: glibc にバッファオーバーフローの脆弱性 CVE CVE-2015-7547 CVE-2015-8776 CVE-2015-8778 CVE-2015-8779 影響 DoS/RCE DoS DoS DoS 重要度 High Low Low Low ステータス PoC公開 PoC公開 PoC公開 PoC公開 対策 修正版へ更新 修正版へ更新 修正版へ更新 修
CVE-2015-7547 (glibcの脆弱性) AWSでの対応まとめ | DevelopersIO
ども、大瀧です。 本日午前中にCVE-2015-7547に関する情報が公開されました。 AWS環境での対応方法をまとめておきます。 AWSからのアナウンス : CVE-2015-7547 Advisory AWSのマネージドサービスは影響無し RDSやS3など、AWSのマネージドサービスは影響ありません。 EC2はAWS DNSを参照する場合は影響無し 今回の脆弱性はDNS関連とのことですが、Amazon VPCで提供されるDNSキャッシュサーバー(AWS DNS)を参照するEC2インスタンスも影響ありません。 AWS DNS以外のDNSサーバーを向いているEC2では、glibcパッケージをアップデートすることで対応が必要です。Amazon Linuxの場合は、以下のyumコマンドでアップデートしましょう。 sudo yum update glibc ただし、Amazon Linuxのバー
glibcの脆弱性対策（取り急ぎiptables/firewalldで叩き落とす！）for CVE-2015-7547 - Qiita
glibcの脆弱性対策（取り急ぎiptables/firewalldで叩き落とす！）for CVE-2015-7547LinuxSecurityiptablesfirewalldglibc はじめに glibcでヤバメな脆弱性キター！ 「glibc」ライブラリに脆弱性、Linuxの大部分に深刻な影響 - ITmedia エンタープライズ Google Online Security Blog: CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow CVE-2015-7547: Critical Vulnerability in glibc getaddrinfo - SANS Internet Storm Center Carlos O'Donell - [PATCH] CVE-2015-7547 --- glibc ge
BINDの脆弱性対応についての動きまとめ - infragirl’s blog
おはこんばんにちは。ナツヨです。 いつか、脆弱性対応についての記事を書こうと思っていたら、BINDさんがまた 脆弱性を発表してくれました。（CVE-2015-8704,CVE-2015-8705) 前回の発表から１ヶ月も立っていないのに、流石BINDさんだなぁと思いました。（遠い目） 今日は、BINDに焦点をあてて、脆弱性対応とはどういうことが必要なのかまとめていこうと思います。すでに日常的に脆弱性対応されている方というよりは、「なんかしらんけどDNSサーバの管理者になっていた。とりあえずBINDというソフトウェアで動いていることは知っている」という方向けだと思います。 １．BINDの脆弱性の発表をキャッチする BINDの脆弱性について、世の中で一番早く発信するのはBINDのサポートを行っているISC本家（BIND | Internet Systems Consortium）だと思います。
複数のWebサイトでSyrian Electronic Armyの画像が表示された件をまとめてみた - piyolog
2014年11月27日21時頃より国内外複数のWebサイトでSyrian Electronic Army(SEA)の画像に転送されるとの報告が相次ぎました。ここではその関連情報をまとめます。 公式発表 Gigyaの発表 Regarding Today’s Service Attack 株式会社トーチライト GIGYAサービス DNSへのハッキング被害に伴う障害について (魚拓) SEAのTweet Happy thanks giving, hope you didn't miss us! The press: Please don't pretend #ISIS are civilians. #SEA pic.twitter.com/ZXzMWbXoYp— SyrianElectronicArmy (@Official_SEA16) 2014, 11月 27 タイムライン 日時 出来事 1
DNSサーバーをオープンリゾルバーにしない
今年に入って、DNSの再帰的な問い合わせを使ったDDos攻撃が報告されているようです。 DNSキャッシュサーバーとして運用している場合でも、制限を設けて適切に設定をしておかないと、 DDos攻撃の踏み台にされてしまいます。 詳しくはこちらのサイトを参考にしてください。 http://www.jpcert.or.jp/pr/2013/pr130002.html 管理しているサーバーがオープンリゾルバーになっていないかどうかを確認するサイトが開設されています。 http://www.openresolver.jp/ OSやBINDのバージョンによっても異なりますが、設定例をご紹介します。 まず、オープンリゾルバーになっていないかを確認します。 前述したオープンリゾルバー確認サイトも確認できますが、ここではコマンドラインで確認します。 $ wget -qO - http://www.openre
DNSの「開いたパンドラの箱」を理解するために - 権威DNSサーバが返す5種類の応答とその意味 -:Geekなぺーじ
前回からかなり時間が経過してしまいましたが、やっと新書を書き終わったので、「DNSキャッシュポイズニングの基本と重要な対策」の続きです。 まだまだ先は長いのですが、今回は権威DNSサーバがキャッシュDNSサーバに返す5種類の応答とその意味について解説します。 権威DNSサーバからの5種類の応答 ユーザからの名前解決要求を受け取ったキャッシュDNSサーバは、ルートサーバを起点とするDNSの階層構造をたどって、名前解決を実行します。名前解決の際、キャッシュDNSサーバはユーザから問い合わせがあった「名前」と「型」を、権威DNSサーバにそのまま問い合わせます。そして、キャッシュDNSサーバはそれぞれの権威DNSサーバから返される応答を解釈しながら、名前解決を進めていきます。 名前解決において、キャッシュDNSサーバがそれぞれの権威DNSサーバから受け取る応答は、以下の5種類に分類できます。この5
DNSキャッシュポイズニングの基本と重要な対策:Geekなぺーじ
2014年4月15日に公開されたJPRSの緊急注意喚起に続き、中京大学の鈴木常彦教授によるDNSキャッシュポイズニングに関する技術情報が公開されました。 今回公開された技術情報に書かれている内容には、DNSの本質につながるさまざまな要素が関係しており一回で書ききれるものではなく、また、書いている側（私）も、それぞれの要素技術について勉強しながら理解しつつ進めていかないと混乱してしまうということが良くわかったため、これから数回に分けて徐々に書いて行くことにしました。 ということで、今回はまず、そもそもDNSキャッシュポイズニングとは何かということと、JPRSの注意喚起に書かれているUDPソースポート番号のランダム化（ソースポートランダマイゼーション）の概要、そしてなぜそれが重要なのかという点について解説します。 DNSキャッシュポイズニングとは インターネットで通信を行うとき、各機器同士は通
インターネットの根幹「DNS」に根本的欠陥が見つかる(dragoner) - 個人 - Yahoo!ニュース
このJPRSの発表に対し、この欠陥を発見した中京大学の鈴木常彦教授、前野年紀氏は「危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません」を懸念し、下記のブログ記事等でこの問題の危険性を訴えています。 この問題はインターネットの根幹に関わるものですが、どんな問題を孕んでいるのでしょうか。それを理解するために、まずはDNSの仕組みから見て行きましょう。 DNSの仕組みとDNSキャッシュサーバDNSとはインターネットの根幹に関わる仕組みで、目的のサーバにアクセスする為の重要な役割を持ちます。簡単に説明すると、"http://www.example.jp"というURLのサイトを見たい場合、それを管理するサーバのインターネット上の住所（IPアドレス）が必要になります。そこで、DNSサーバに上記URLのラベル（ドメイン）に相当する"www.example.jp"を管理するサー
キャッシュポイズニングの開いたパンドラの箱 -2-
キャッシュポイズニングの開いたパンドラの箱 -2- Opened Pandora's box of Cache Poisoning -2- 鈴木常彦 2014.04.15 (Concept by 前野年紀 2014.02) 移転インジェクション攻撃: RFC2181 5.4.1 "Ranking data" の欠陥 今回、委任インジェクション攻撃に加え、さらに RFC2181 の欠陥を突いた攻撃が可能であることを確認した。 委譲元から得た最低ランクの NS キャッシュを、偽権威の Answer に付随する Authority Section の NS で上書きして毒入れすることができ、そのゾーンを自由にできる。 これにより、現状では別途示した 1, 2, 3 の条件に関係なく容易に毒入れすることが可能である。 攻撃者は以下のようにターゲットのゾーンの NS を偽権威に向けることができる。
キャッシュポイズニングの開いたパンドラの箱
キャッシュポイズニングの開いたパンドラの箱 Opened Pandora's box of Cache Poisoning 鈴木常彦 2014.04.15 (Concept by 前野年紀 2014.02) / English version 背景 Kaminsky 2008年、Dan Kaminsky 氏が TTL に影響されない毒入れ手法を発表した。 しかし、偽応答のAdditional Section で毒が入るとされたのは誤りだったことを2011年に鈴木が明かにした。 http://www.e-ontap.com/dns/bindmatrix.html Müller Bernhard Müller の "IMPROVED DNS SPOOFING USING NODE RE-DELEGATION", 2008.7.14 https://www.sec-consult.c
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
名前解決の仕組みを使ってDNSを攻撃、「NXNSAttack」とは 
オープンリゾルバー～正規キャッシュDNSサーバー経由の2段階DDoS攻撃か？ 警察庁が怪しいパケットの増加を観測
カミンスキー攻撃らしきアクセス、日本の大手ISPで増加、DNSの設定再確認を 