Cisco IronPort c170による継続的なスパム保護

まえがき



画像 IronPort c170について1年前にhabrで書いた。 そして、これは私を招待した最初の記事でした。 残念ながら、それ以来、この鉄片に関する単一の(!)記事がハブに掲載されていません。これは、私の意見では、ハブなどのリソースには許可されていません。

まず、最初の記事を思い出してください: habrahabr.ru/post/148317

彼女はレビューしており、結論を導き出していません。 しかし、1年の間に、ハードウェアを少し理解し、いくつかのトリックを学び、ファームウェアエラーに遭遇しました...そして今、一般的に、私はあなたに何よりも何かを伝える準備ができています:)



そもそも、世界のスパムの量をもう一度示したいと思います。



1日10億文字。 スパムの総数は、世界のメールトラフィック全体の約85%を占めています。

効率が低いにもかかわらず、その量は減りません。 くそー、誰がそれを読むの? 人々は本当にこれらの電話を呼び出しますか? まあ、大丈夫、気を取られて...



だから。 一般的なデフォルトのスパムスクリーニング方法を思い出してみましょう。 まず第一に、IronPortは手紙の本文ではなく、その送信者を気にします。 アドレス、そのサブネットは大きな役割を果たし、各ソースに対して鉄片は-10から+10のポイントを置きます。 IronPortがsenderbase.orgから取得するポイント。 サイトにアクセスして送信メールサーバーのアドレスを入力するだけでは、短い貧しい人、良い人、または中立な人しか見ることができません。 しかし、IronPortはそれ以上のことを知っており、10分の1まで評価しています。 デフォルトでは、サーバー評価が-3未満の場合、システムはデータを転送する前にsmtpセッションを中断します。



スパム対策フィルターの改善方法



このセクションは、すでに鉄片を所有している人に適しています



それは私に合っていて、どのような種類の手紙にそのような評価が付いているのかを見ました。クライアントが否定的な評価を持っている場合、これは間違いなくこのソースから悪いコンテンツを持つ多くのメッセージが気づいたことを意味し、慎重にそのようなサーバーを信頼する価値がありますが、まったく信頼しない方が良いです

これまでのところ、監督への待望の手紙はただ落とされただけではありませんでした。 そして、私はこれを不快なイベントだと感じました。 私はすぐにサーバーをホワイトリストに追加し、なんらかの形でディレクターに穏やかに通知しました...スパムの場合、彼らは手紙を数えたので、もう一度送信できます! すべてがうまくいき、稲妻は投げられなかったので、スパムが来ず、メッセージが落ちないようにシステムをアップグレードする方法を考え始めました。



シンプルなものから始めました。トラフィック-3を分離しましたが、破壊しませんでしたが、特別な隔離を作成し、そこに文字を落とし始めました。 それは最も簡単でしたが、最も重要なことは、手紙の取り返しのつかない破壊から私を守りました。 検疫のために、2.3 GBの最大残りディスク領域を割り当てました(なぜそれがそんなに小さいのかわかりませんが、もはや不可能です)。 そして今、平均して、この隔離は55%満杯です。

しかし、これでは十分ではありませんでした。 マイナス評価が-0.5から-3の範囲にある、容認できないほど多くのスパムであることに気付きました。 それらを除外できないため、悲しいことでした-それらからの手紙の数パーセントは良性でした。 すべて同じなので、だれもテキスト全体を読んでいないので、この投稿がタオルであることを急いでお知らせします。 ただし、スパムメールには正しいPTRレコードが含まれていないことに気付きましたが、この評価の正しい文字にはすべて正しいPTR-A束が含まれています。 しかし、私の失望はまだ限界がありませんでした。 標準のフィルタリングでは、送信者グループのソースごとにフィルターを構成する方法はありません。 すぐに手紙をドロップできますが、フィルタリングすることはできません! 愚かさ。





私は先に進んでpdfの指示からほこりを吹き飛ばし、設定に他に何があるかを確認しなければなりませんでした。 PTRフリーのソースのフィルタリングの問題を解決するために、私は使いにくいコマンドインターフェイスの腸を掘り下げる必要がありました。

その結果、特別なフィルタリングルールを作成する必要がありました。 とてもシンプルに見えます:

構成テキスト
Num Active Valid Name 1 YY DNS_Fail_ToSpam DNS_Fail_ToSpam: if sendergroup == "UNVERIFIED_LowScore" { quarantine("trash"); }
      
      





そして、必要なことを実行します。UNVERIFIED_LowScore送信者グループからの手紙の場合、その特別な検疫に送られます。



その結果、-3未満の文字が単純に破壊され、ほとんどすべてがより高くなる初期設定と比較して、私の設定はより高いレベルのフィルタリングと、文字の損失に対する卓越した耐性を示し、最も悪名高いゴミでさえ保存されます...念のため: )間違った受取人の手紙だけがすぐに殺されます。



観察: すべての smtpセッションとそれらとの電子メールを受け入れ始めた瞬間から、接続の数は急激に減少しました! そして数回減少しました。 スパム送信者は、セッション、ドロップ、その他すべての時間の遅れを気にしないと判断したため、1回だけではなく、何度も手紙を送信しようとします。



ファームウェアの問題



ある時点で、非常に奇妙な手紙が鉄片からメールに送信され始めました。 このようなもの:

文字のテキスト
重要なメッセージは次のとおりです。



アプリケーション障害が発生しました:( 'egg / coro_postgres.py _simple_query | 756'、 "<class 'coro_postgres.QueryError'>"、 '_simple_query(エラー53000:17144/17171のブロック14を書き込めませんでしたブラインド:開いているファイルが多すぎますシステム) '、' [egg / quarantine_hermes.py _expiration_main | 1980] [egg / quarantine.py expire_all_messages | 771] [egg / quarantine.py _process_transaction | 871] [egg / quarantine.py _expire_messages | 1355] [egg / quarant。 py _query | 1669] [egg / quarantine.py _call_db | 1643] [egg / quarantine.py _db_query | 1726] [egg / coro_postgres.py query | 346] [egg / coro_postgres.py _simple_query | 756] '))



バージョン:7.6.1-022

シリアル番号:5057A8E1583B-FGL161740BG

タイムスタンプ:2012年12月13日00:32:18 +0400



アラートの詳細については、ナレッジベースをご覧ください。 多くの場合、この特定のアラートに関する詳細情報を見つけることができます。 次のサポートポータルにログインした後、ナレッジベースのリンクをクリックしてください。



www.cisco.com/web/ironport/index.html



さらに情報が必要な場合は、サポートプロバイダーにお問い合わせください。



この問題のサポートリクエストを開くには、IronPort C170にアクセスし、「supportrequest」コマンドを発行します。 このコマンドは、診断情報を含む電子メールを直接Cisco IronPortカスタマーサポートに送信して、問題の迅速な診断を促進します。





よろしくお願いします。


テキストは常に変化しています。 しばらくの間、私は彼らに特別な注意を払わず、手紙がフィルタリングされている間、心配する必要はないと考えました。 手紙がフィルターで除去されるまではすべて順調でした:) IronPortはある時点で送信者のサーバーへのポイントの割り当てを停止し、「占星術師は1週間の長いMPHを発表しました。 スパムの量は10倍になりました。」

まあ、私はそれが書かれているようにやった:私はテクニカルサポートに連絡した。

最初に、あるアーメド・アーレフが私と会話を始めました。 おそらく日当たりの良いインドから。 しかし、その後、彼らが事件を開いたとき、ドイツからの従業員が私に連絡しました。 その後、テクニカルサポート用の特別なセキュリティチャネルを設定するという長い試練がありました。 すべてうまくいかず、完全なSSHアクセスを許可することに同意しました:)安全性はそれほど高くないと思いましたが、標準的な方法でIronPortを超えることは不可能です。 その後、エンジニアは突っ走り始めました。 そして、見よ、それは働いた。

しかし、核心に、私は失敗の理由に打たれました:

技術サポートソリューション
この問題をさらに調査し、レピュテーションエンジンのサブフォルダーが作成されていないAsyncOSバージョン7.6.1-022にアップグレードした後、アプライアンスで既知の障害86843が発生したことを確認できます。 これにより、アップグレード後の時点で問題は発生しませんでしたが、12月12日の朝にレピュテーションエンジンの更新が行われ、フォルダーが見つからないためにエンジンが適切に再起動できなくなりました。



この問題を解決するために、アプライアンスに不足しているサブフォルダーを作成しました。 レピュテーションエンジンを適切に再起動するには、アプライアンスを再起動する必要があります。 ユニットを正常に再起動してください。 再起動後、アプライアンスは再び正常に動作し、SenderBase評価スコアを取得するはずです!


たくさんのひどい間違い、そしてその理由は...サブフォルダーです。 それにもかかわらず、最終的に私は技術サポートとのコミュニケーションが好きだったと言いたいです。 彼らはある程度ステレオタイプに振る舞いましたが、そこには人々がいて、助けたいと思っていました。 彼らは私の曲がった英語を理解し、同時にそれらを理解しました)



1年間の操作で気に入らなかったもの







何が嬉しかった? それは価値がありますか?



お金に見合うかどうかはわかりません)コストはまだかなり高いです。 1ユーザーあたり年間約20〜30ドル。 たぶん今、私は他の解決策を探しますが、常に本当の問題は1つだけでした。 そして、それは上で説明されています。 ファームウェアを更新していなければ、すべてに表示されていなかったでしょう。 デバイスにこれ以上問題はありませんでした。 サーバールームで賑やかになりますが、尋ねません。 時々、管理部分をセットアップしたポートを忘れて、一般的に何かを締める必要があるときにどこにあるかを忘れます。 この点で、すべてが豪華です:)

スパムをかなり定性的にフィルタリングし、個人検疫を使用すると、管理者を手動で操作して文字を抽出する必要がなくなり、ユーザーは検疫に関する週次レポートで文字のブロックを解除できます。

それを読んだすべての人に感謝します。 誰かが鉄について質問がある場合は、全員に答えます。 もちろん、私が知っている範囲内で:)



さて、統計情報を含む画面を追加します。








All Articles