アカウント名:
パスワード:
この手の訓練メールって、作る側のレベルが低いから、スキルのある人ほどが引っかかったことにされるという問題がある。
例えば、メールヘッダーまで確認して、組織内の正規のメールサーバーから送信されていることと、リンク先のドメイン名のIPアドレスがLAN内の正規のWebサーバとなっていることを確認して情報入力しても、「はいこれはフィッシングメールの訓練でした。情報乳利力した人は再教育プログラムを~」となったりする。
酷い組織だと、仮想環境からリンク先にアクセスしただけでも引っかかったことにされてしまう。
実際こういう「訓練」をやるならば、外部のレンタルサーバと紛らわしいドメイン名(もしくはfromの詐称などを実際に行う)などを使用するなどして、実践に近い状況を再現すべきだが、そこまでせずに正規のメールサーバと正規のWebサーバで訓練するといったろくでもない組織が多い。
うちのところは発信元メールがgmail.com等だと警告のタグが付くがgo.jpでも付くクソ仕様発信元偽装にも対応しているか疑問
発信元メアドは詐称できるから、本当に .go.jp ドメインのサーバーから送信されたことが確認できなければ、警告するのは正しい仕様。むしろ発信元の表示上のドメインで判断するコメ主のほうが遥かに危険。
発信元メアドは詐称できるから、本当に .go.jp ドメインのサーバーから送信されたことが確認できなければ、警告するのは正しい仕様。
その「本当に」はどう判定するんですか、って話ですよね。
それと、#3949390 [srad.jp]は、「本当に」かどうかとは無関係にいつも警告のタグが付く、と言っている様に読めますが。
SPFとかで認証するのが普通ですよ。
メーリングリストがあると、SFPで認証できない場合があるだろ?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
この手の訓練ってスキルのある人が引っかかったことにされる (スコア:0, すばらしい洞察)
この手の訓練メールって、作る側のレベルが低いから、スキルのある人ほどが引っかかったことにされるという問題がある。
例えば、メールヘッダーまで確認して、組織内の正規のメールサーバーから送信されていることと、リンク先のドメイン名のIPアドレスがLAN内の正規のWebサーバとなっていることを確認して情報入力しても、
「はいこれはフィッシングメールの訓練でした。情報乳利力した人は再教育プログラムを~」
となったりする。
酷い組織だと、仮想環境からリンク先にアクセスしただけでも引っかかったことにされてしまう。
実際こういう「訓練」をやるならば、外部のレンタルサーバと紛らわしいドメイン名(もしくはfromの詐称などを実際に行う)などを使用するなどして、実践に近い状況を再現すべきだが、そこまでせずに正規のメールサーバと正規のWebサーバで訓練するといったろくでもない組織が多い。
Re: (スコア:0)
うちのところは発信元メールがgmail.com等だと警告のタグが付くがgo.jpでも付くクソ仕様
発信元偽装にも対応しているか疑問
Re: (スコア:0)
うちのところは発信元メールがgmail.com等だと警告のタグが付くがgo.jpでも付くクソ仕様
発信元偽装にも対応しているか疑問
発信元メアドは詐称できるから、本当に .go.jp ドメインのサーバーから送信されたことが確認できなければ、警告するのは正しい仕様。
むしろ発信元の表示上のドメインで判断するコメ主のほうが遥かに危険。
Re:この手の訓練ってスキルのある人が引っかかったことにされる (スコア:1)
発信元メアドは詐称できるから、本当に .go.jp ドメインのサーバーから送信されたことが確認できなければ、警告するのは正しい仕様。
その「本当に」はどう判定するんですか、って話ですよね。
それと、#3949390 [srad.jp]は、「本当に」かどうかとは無関係にいつも警告のタグが付く、と言っている様に読めますが。
Re: (スコア:0)
SPFとかで認証するのが普通ですよ。
Re:この手の訓練ってスキルのある人が引っかかったことにされる (スコア:1)
メーリングリストがあると、SFPで認証できない場合があるだろ?