今更だけどDNSキャッシュポイズニングについて簡単に説明するよ！ - そして、DNSポイズニングがなかなか対応されない理由。 - FreeBSDいちゃらぶ日記
先日IIJの一日インターンに行ってきました。 NDAがあるので、事細かに書くことは出来ないのですが、教育的なプログラムが組まれていて非常に面白かったです。 そこで、色々お話しして、その中でDNSポイズニングがなかなか対応されない理由、当たり前の理由が聞けたので、「DNSポイズニングって何がヤヴァイのか良くわかんね」って人に向けた簡単な解説とあわせて書きたいと思います。 まず、DNSキャッシュポイズニングの何が怖いか? 簡単に言うと、 「googleに繋いだはずが全く別サイトに繋がっちゃう！」 って話です。 本当に繋ぎたいサイトと違うサイトに繋いじゃう事が出来るので、例えば 実在するショッピングサイトそっくりの偽サイト作って、ショッピングさせて。クレジットカードの番号ゲットしちゃったり、住所ゲットしちゃったり。 夢が広がる怖い事が出来ちゃいます。 きちんとしたセキュリティ対策していれば大丈夫
DNSキャッシュポイズニング、各ネームサーバの対応が話題に
ここ数日ネームサーバ管理者の頭を悩ませているDNSキャッシュポイズニングの脆弱性。脆弱性を突くツールの登場により、具体的な被害が発生する可能性が高まった。 DNSキャッシュポイズニングの脆弱性を突かれると、ホスト名は正しいのにまったく違うサイトへ誘導させることが可能になるため、ファーミングなどの危険性が高まることになる。 そんな中、Webブラウザ上からDNSのランダム性を簡易的にテストできるサイトが注目を集めている。このサイトでは、ソースポートおよびDNSパケットの中に含まれる識別IDのランダム性を検証できる。同じポートや識別IDを使っているネームサーバの場合、「POOR」などが表示される。POORであれば、すでに広く知られるところとなったた攻撃・侵入ツールですぐにでもクラックされてしまうだろう。 例えば記者が利用しているYahooBB!のネームサーバについて同サイト上から検証してみたとこ
送信ドメイン認証SPFレコードについて | EZwebへメール送信する際の注意事項 | au by KDDI
送信ドメイン認証SPFレコードについて 送信ドメイン認証SPFレコードとは、メールを送信するサーバの情報をDNSサーバ上で公開し、送信されたメールのドメイン名とDNSサーバのSPFレコードとの整合性を受信サーバ側で確認することで、そのメールが正当なメールサーバから送信されたものかを認証する技術です。これにより、正当なメールサーバから送信されたメールと「なりすましメール」とを判別することが可能となります。その為には送信されているメールのドメイン (エンベロープFrom) と送信IPアドレスの関連をSPFレコードに記述していただく必要がございます。 RFC4408 (英文) Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 EZwebにSPFレコードを公開してメールを送信され
Sender ID Framework SPF Record Wizard
Sender ID Framework SPF Record Wizard This four-step wizard will guide you through the process of creating a new SPF record for your DNS domain. You should add this DNS record to your domain's DNS configuration. Note that you may need to manually edit the SPF record created by this wizard if you want to use some of the more advance features of the SPF format. For complete details plea
メール送信者認証技術 SPF/Sender ID についてお勉強
お勉強の背景に関しては 「迷惑メール対策 OP25B（Outbound Port25 Blocking）についてお勉強」 に書いたとおりですが、迷惑メール対策としての SPF/Sender ID についてもいろいろ勉強したのでそのまとめです。（DomainKeys については思いのほかエントリが長くなったのでまた別の機会で・・・）まずは参考になったサイトの紹介から。 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 Sender ID: Authenticating E-Mail DNS関連技術の最新動向 - SPF/DomainKeysとは Sendmail 社 - 送信者認証技術の導入におけるレコメンデーション メール送信者認証の仕組みを探る(2/2):スペシャル - ZD
独自ドメインのメール送信を SPF に対応させる方法 - WebOS Goodies
上記の「ステータス」というのは、メール配信時に付加される "Received-SPF:" ヘッダに表記される文字列です。 Received-SPF ヘッダに関する詳細は後述します。また、「メールの扱い」はあくまで代表的な例ですので、すべてのサーバーが上記のような動作をするとは限りません。最終的には受信側サーバーの裁量にいかんです。 Mechanism Mechanism はディレクティブの Qualifier を除く部分で、ホストのマッチングルールを指定します。多くの指定方法がありますので、それぞれ個別にご紹介します。 ip4 : IP アドレスによるマッチ "ip4" は送信元 IP アドレスが指定された IP アドレスと一致するかを確認する Mechanism です。書式は以下のようになります。 ip4:<IPアドレス> 例えば、 "+210.251.253.231" というディレクテ
Sender IDを導入してみた » skyblue.me.uk
11/28: Sender IDを導入してみた HotmailやAOLが導入しだした、Sender IDと呼ばれるメールの送信元アドレスの偽装を防止する技術を、skyblue.me.ukにも導入してみました。 送信者認証技術は、"Sender ID/SPF"Sender Policy Framework)"と"Domain Keys"の2種類が主流。 Sender ID/SPFは、Microsoftが提唱するSPAM対策の技術です。まず送信サーバがIPアドレスを、DNSにあるTXTレコードに登録し、そして電子メールを受け取った受信サーバは、DNSに参照し、受け取ったメールが登録してある送信サーバから送信されたかを確認するというもの。 サーバサイドでDNSのTXTレコードにSPFレコードを登録すればいいので、導入は非常に楽。 ただ、受信サーバにDNSを参照して、送信元がSPF
MTA/AntiSPAM/Sender ID ¤òƳÆþ¤·¤Æ¤ß¤ë - Pocketstudio.jp Linux Wiki
NTT¥É¥³¥â(docomo.ne.jp)SPFÂкö¤òBIND¤ÇÀßÄê-Á÷¿®¥É¥á¥¤¥óǧ¾Ú¡ÊSender ID¡¿SPF¡Ë Sender ID ǧ¾Ú¤¬Æ³Æþ¤µ¤ì¤Æ¤¤¤ë¾ì¹ç¤Î¥á¡¼¥ë¤Îή¤ì † Á÷¿®¼Ô¤¬Áê¼ê¤Ë¥á¡¼¥ë¤òÁ÷¿®¤¹¤ë Áê¼ê¤Î¥á¡¼¥ë¥µ¡¼¥Ð¤Ë¥á¡¼¥ë¤¬Åþ㤹¤ë Áê¼ê¤Î¥á¡¼¥ë¥µ¡¼¥Ð¤Ç¡¢¥á¥Ã¥»¡¼¥¸¤ÎÁ÷¿®¸µ¤Î¥É¥á¥¤¥ó¾ðÊó(DNS)¤ò¤·¤é¤Ù¡¢SPR ¥ì¥³¡¼¥É¤ÎÍ̵¤ò¥Á¥§¥Ã¥¯¡£¤Þ¤¿¡¢ÅŻҥ᡼¥ë¤Î IP ¥¢¥É¥ì¥¹¤¬ SPF ¥ì¥³¡¼¥É¤Ë¸ø³«¤µ¤ì¤Æ¤¤¤ë IP ¥¢¥É¥ì¥¹¤Î¤¤¤º¤ì¤«¤È°ìÃפ¹¤ë¤«¤É¤¦¤«¥Á¥
逆引きができないサーバー拒絶についての補足
以下のお問い合わせが来ましたので解説します。 SPAM対策について拝見しました。 http://www.hart.co.jp/spam/rejiponly.html 上記のページに「逆引きできないホストからのメールを遮断」とあり、タイトルの内容について言及されています。 この件について、 ・DNSの逆引きは必ずしも設定する必要がないこと ・DNSの逆引きの有無が必ずしも信用性と結びつかないこと ・DNSのトラフィックが増加するであろうこと ・DNSが停止している場合のあるべき動作 について、どうお考えかお聞かせ願えませんでしょうか？ 浅学のため、上記のデメリットに対する有効な対策が思いつきません。 ●DNSの逆引きは必ずしも設定する必要がないこと その通りです。インターネットのとりきめが書いてある文書（RFC、Request For Comme
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SPF Policy Tester - ORF
DNS逆引きチェックによるスパム対策は百害あって一利無し