Sberbankにドメインの誤ったSPFレコードがあるのはなぜですか?

簡単に説明すると 、Sberbankのメインドメイン(sberbank.ru)に誤ったSPFレコードがあります。 これは、攻撃者がSberbankに代わって偽の電子メールキャンペーンを行う機会を持つという事実につながります。 レコード自体は適切に構成されていますが、エラーが発生するため、すべての作業がゼロになります。



> host -t txt sberbank.ru sberbank.ru descriptive text "v=spf1 mx mx:shark11.sberbank.ru mx:shark12.sberbank.ru mx:shark13.sberbank.ru mx:shark14.sberbank.ru mx:email1.sberbank.ru -all"
      
      





ハッピーエンド:レコードが修正された日中、RFCに準拠しました。



 > host -t txt sberbank.ru sberbank.ru descriptive text "v=spf1 mx -all"
      
      





まあ、それを読むことができる人のために、猫へようこそ。



なぜSPFが必要なのですか?



SPFは、偽造送​​信者アドレスとの闘いに役立ちます。 SPFとDMARCを混同しないでください。SPFでは、特定のIPアドレスがそのドメインに代わってメールを送信できるかどうかを確立することしかできません(多くの例外とリバースをサポートしています)。



SPF は不必要で有害であるという意見がありますが、実践が示すように、今日SPFはDMARCの主要なメカニズムであり、これまでのところ、この種のものはありません。



どのように機能しますか?



メールサーバーは、メールを受け入れながら送信者のアドレスを確認し、送信者のドメインに特別な記録を要求します。送信者のドメインでは、このドメインにメールを送信できるIPとそうでないIPが作成されます。 その結果、この手紙を受け入れるかどうかの決定が下され、場合によっては受け入れられてスパムとしてカウントされます。



それで本当に何が機能するのでしょうか?



まあ、一般的には、実際にはそうではありません。 当初、SPFはSoftfailを許可するタイプのレコードを提供していました。 それは枠のようなものですが、言い訳になります。 つまり、私のドメインからのメールはこれらのアドレスから来ることができると言いますが、それは間違いなく正常です。 そして、他の一部からの場合、これは何も許されません。



今日、スパマーはこの謝罪のポストスクリプトにしばしば陥るので、この謝罪のポストスクリプトは、一般にSPFを無意味で無効にします。



ズベルバンクの業績はどうですか?



そして、それらの記録に-allが含まれているという事実は、Softfailの謝罪の防止にすぎません。 つまり、Sberbankのメンバーは、彼らからのメールは指定されたアドレスからしか送信できないと言っているようです。 よくやった、それは素晴らしい。



しかし、Sberbankは何が悪いのでしょうか?



そして、彼らの記録が正しく表現されていないという事実。 これによりPermerrorエラーが発生し、ほとんどのメールシステムでレコードはチェックされず、メッセージは単にスキップされます。



同意します。すべてハードな記録を作成すると同時に間違いを犯し、記録全体を不正確にするのは愚かなことです。



しかし、間違いはどこにありますか?



RFC 7208では、SPFで必要なデータを取得するためにメールサーバーが行う必要があるDNSクエリの数にいくつかの制限が導入されています。 結果またはエラーが空のクエリの数を制限するのは同じRFCです。



エントリを解析します。



 "v=spf1 mx mx:shark11.sberbank.ru mx:shark12.sberbank.ru mx:shark13.sberbank.ru mx:shark14.sberbank.ru mx:email1.sberbank.ru -all"
      
      





0. v = spf1



SPFレコードのバージョン、つまり 構文



1. mx



MXとしてリストされているサーバーのみがsberbank.ruドメインからメールを送信できます



 > host -t mx sberbank.ru sberbank.ru mail is handled by 50 shark11.sberbank.ru. sberbank.ru mail is handled by 50 shark14.sberbank.ru. sberbank.ru mail is handled by 50 email1.sberbank.ru. sberbank.ru mail is handled by 50 shark12.sberbank.ru. sberbank.ru mail is handled by 50 shark13.sberbank.ru.
      
      





さて、これら5つのサーバーがあります。



2.mx:shark11.sberbank.ru



shark11.sberbank.ruドメインのMXとしてリストされているサーバーは、sberbank.ruドメインからメールを送信できます



やめて! もう一度。



shark11.sberbank.ruドメインのMXとしてリストされているサーバーは、sberbank.ruドメインからメールを送信できます



 > host -t mx shark11.sberbank.ru shark11.sberbank.ru has no MX record
      
      





そして、この結果は空としてカウントされます。 また、RFCによれば、最初の2つのエラーの後、SPFレコードの分析を停止し、エラーを見つける必要があります。 どちらが起こっているのか。



要するに、男たちはそれを少し誇張した。



どうやってやるの?



 "v=spf1 mx -all"
      
      







それとも、同僚の方がうまくいっていましたか?



実際、Sberbank自体が手紙を送信することはめったにありません。たとえば、メールシステムでは、それほど多くはありません。 それらの多くはSberbank ASTサイトから来ているので、見てみましょう。



 > host -t txt sberbank-ast.ru sberbank-ast.ru descriptive text "v=spf1 mx a:mail2.sberbank-ast.ru a:mail3.sberbank-ast.ru a:mail4.sberbank-ast.ru a:gw.sberbank-ast.ru a:mail7.sberbank-ast.ru ~all"
      
      





そして、ここで、悲しいかな、Softfail。 SPFレコードの値を無効にします。



更新

Sberbank ASTの同僚はすぐに反応しました。 今このように:



 > host -t txt sberbank-ast.ru "v=spf1 mx a:mail2.sberbank-ast.ru a:mail3.sberbank-ast.ru a:mail4.sberbank-ast.ru a:gw.sberbank-ast.ru a:mail7.sberbank-ast.ru -all"
      
      





実際、もちろん、mxおよび



 > host -t mx sberbank-ast.ru sberbank-ast.ru descriptive text sberbank-ast.ru mail is handled by 5 mail4.sberbank-ast.ru.
      
      





ただし、〜allから-allに切り替えることは称賛に値します。



All Articles