web-dev-qa-db-ja.com

ホワイトリストとブラックリストを使用してPostfix * _restrictions構成パラメーターを安全に設定するにはどうすればよいですか?

学び、理解しようとする

先週は、Postfixがスパムを減らすために何ができるかについて学びました。さまざまな*_restrictions構成パラメータcontrol whenを正しく理解していれば、チェックが行われ、次にpermit_mynetworkscheck_client_access controlなどの制限のリストwhatがチェックされます。あれは正しいですか?

私が正しく理解している場合、チェックは次の順序で実行されます。

  • smtpd_client_restrictions
  • smtpd_helo_restrictions
  • smtpd_sender_restrictions
  • smtpd_relay_restrictions
  • smtpd_recipient_restrictions

あれは正しいですか?そして、私が正しく理解していれば、smtpd_delay_rejectはチェックの順序には影響せず、whenにのみ影響します。拒否はsentです。正しい?

私のサーバー設定

smtpd_relay_restrictions構成パラメータがPlesk 11サーバで設定されていないようです。私のPostfixバージョンは2.8.4です。

また、いくつかのチェックが異なる構成パラメーターで複数回リストされていることにも気付きました。それらは複数回リストされる必要がありますか?

これが私の現在の設定です:

smtpd_sender_restrictions =
    check_sender_access hash:/var/spool/postfix/plesk/blacklists
    permit_sasl_authenticated
    check_client_access pcre:/var/spool/postfix/plesk/non_auth.re

smtpd_client_restrictions =
    permit_mynetworks

smtpd_recipient_restrictions =
    permit_mynetworks
    check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
    permit_sasl_authenticated
    reject_unauth_destination

私が正しく理解していれば、それはこれと同じです:

smtpd_sender_restrictions =

smtpd_client_restrictions =

smtpd_recipient_restrictions =
    permit_mynetworks
    check_sender_access hash:/var/spool/postfix/plesk/blacklists
    permit_sasl_authenticated
    check_client_access pcre:/var/spool/postfix/plesk/non_auth.re
    permit_mynetworks
    check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
    permit_sasl_authenticated
    reject_unauth_destination

ブラックリストファイルが空です。 no_authファイルにはこれがあります:

/^/ PREPEND X-No-Auth: unauthenticated sender

そしてno_relayファイルにはこれがあります:

/^/ PREPEND X-No-Relay: not in my network

私が正しく理解している場合、最後の2つは、まだ許可されていないすべての電子メールにヘッダーを追加します。

懸念

  • 繰り返しチェック
    複数回リストされている場合、Postfixは再度チェックを実行しますか?または、Postfixはそのチェックがすでに行われたことを知っていますか?チェックが複数回実行される場合、それは無駄のようです。それらが複数回実行されない場合、no_auh/no_relayヘッダーは実際にはすべての場合に適切に追加されますか?

  • smtpd_relay_restrictionsがありません
    Postfix SMTPリレーおよびアクセス制御 からの抜粋

    注:2.10より前のバージョンのPostfixにはsmtpd_relay_restrictionsがありませんでした。彼らは、smtpd_recipient_restrictionsの下で、メールリレーポリシーとスパムブロッキングポリシーを組み合わせました。これにより、予期しない結果が生じる可能性があります。たとえば、許容的なスパムブロッキングポリシーにより、予期せずに許容的なメールリレーポリシーが発生する可能性があります。

    別の抜粋:

    一部の人々は、smtpd_recipient_restrictionsリストにすべてのアクセス制限を配置することを推奨しています。残念ながら、これによりアクセスが許容されすぎる可能性があります。

    そのため、smtpd_recipient_restrictionsの下にすべての制限をリストしたくないのですが、複数の制限と同じチェックを異なる制限の下に置くと混乱を招きます。 smtpd_recipient_restrictionssmtpd_relay_restrictionsだけを使用して、クライアント、helo、送信者を無視しても安全ですか?

  • ブラックリスト
    そのブラックリストはリストのかなり早い段階にありませんか?送信者が私のネットワークの一部であり、認証できる場合、送信者のメールに基づいて本当にブロックする必要がありますか?現在、テーブルは空ですが、どのPleskコンポーネントがそのテーブルにメールアドレスを追加するかはわかりません。また、postmaster @およびabuse @アドレスへの100%の配信を必要とするRFCに反します。

これが私が達成したいことです

  • かなりシンプルにしてください
  • オープンリレーやその他のセキュリティホールを作成しないようにします
  • 有効なメールをブロックしないようにしてください
  • 仮想エイリアステーブルに存在するpostmaster @およびabuse @アドレスをホワイトリストに登録する
  • 中国/韓国からのスパマーのIPアドレスブロックをブラックリストに登録する
  • キャッチオールを使用するドメインの特定の受信者アドレス以外のすべてを正規表現で拒否します。 PleskがVERPをサポートしていない場合でも、VERP-yバウンスアドレスを使用できるように、1つのドメインでキャッチオールを使用しています。

これが私が考えていたことです

/etc/postfix/main.cf内

#smtpd_client_restrictions =
#smtpd_helo_restrictions =
#smtpd_sender_restrictions =

smtpd_relay_restrictions =
    permit_mynetworks
    check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
    permit_sasl_authenticated
    check_client_access pcre:/var/spool/postfix/plesk/non_auth.re
    reject_unauth_destination

smtpd_recipient_restrictions =
    check_recipient_access pcre:/etc/postfix/custom/recipient_checks.pcre
    check_client_access cidr:/etc/postfix/custom/sinokorea.cidr
    check_sender_access hash:/var/spool/postfix/plesk/blacklists

/etc/postfix/custom/recipient_checks.pcre内

# Always accept mail to postmaster@ and abuse@
/^postmaster@/ OK
/^abuse@/ OK

# Reject all mail sent to mailapp.ourdomain.com
# except for certain specific recipients
# and bounce messages which may use VERP
if /@mailapp\.ourdomain\.com$/
!/^(?:validuser|anothervalid|bounces(?:\+.+)?)@/ REJECT
endif

正規表現で@がエスケープされている例を見つけました。特別なキャラクターじゃないですか?

私の提案した構成は私が望んでいることを達成しますか?

(自分自身および他のPleskユーザがこれを読んでいることに注意してください-一部のPleskアクションがこのファイルを上書きしているように見えるため、main.cfファイルへの変更を定期的に復元するには、cronジョブが必要になる場合があります。)

6
toxalot

OK、これは長い質問です。上記の質問の一部に答えてみます。そして、それらに基づいて要約を描くこともできます。

免責事項:私はpleskを使用していませんが、postfixを使用しています。この質問の年齢は1年以上だったので、多分pleskはpostfixの設定を更新しました。しかし、私はこの質問は後置制限を設計して実装する人にとって役立つと思います

Q1:これら2つの構成は同等ですか?

smtpd_sender_restrictions =
    check_sender_access hash:/var/spool/postfix/plesk/blacklists
    permit_sasl_authenticated
    check_client_access pcre:/var/spool/postfix/plesk/non_auth.re

smtpd_client_restrictions =
    permit_mynetworks

smtpd_recipient_restrictions =
    permit_mynetworks
    check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
    permit_sasl_authenticated
    reject_unauth_destination

そして

smtpd_sender_restrictions =

smtpd_client_restrictions =

smtpd_recipient_restrictions =
    permit_mynetworks
    check_sender_access hash:/var/spool/postfix/plesk/blacklists
    permit_sasl_authenticated
    check_client_access pcre:/var/spool/postfix/plesk/non_auth.re
    permit_mynetworks
    check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
    permit_sasl_authenticated
    reject_unauth_destination

Mynetworksからのメールの場合、/var/spool/postfix/plesk/no_relay.reおよび/var/spool/postfix/plesk/no_relay.reによるチェックは行われません。つまり、メールは受け入れられ、変更されません。後置アクション(REJECT、ACCEPT)に関しては、違いはありませんが、多分これらの2つのヘッダーはimportantです。

Q2:複数回リストされている場合、Postfixは再度チェックを実行しますか?または、Postfixはそのチェックがすでに行われたことを知っていますか?チェックが複数回実行される場合、それは無駄のようです。それらが複数回実行されない場合、no_auh/no_relayヘッダーは実際にはすべての場合に適切に追加されますか?

ええ、2つのチェックを繰り返すと無駄に見えるかもしれません。ただし、この繰り返しのチェックは別の場所/制限に配置されます。そして、すべてのチェックで、Postfixが電子メールをどのように処理したかに関するロジックまたはアルゴリズムがいくつかあります。チェックが check_policy_service やDNSBLなどの重いチェックである場合は、繰り返しチェックされる可能性があります。 permit_mynetwork のような軽量チェックの場合は、無視してかまいません。

Q3:smtpd_recipient_restrictionsとsmtpd_relay_restrictionsのみを使用して、クライアント、helo、送信者を無視しても安全ですか?

まあ、2つのsmtpd_recipient_restrictionsとsmtpd_relay_restrictionsがあれば、いくつかの高度な制限には十分です。しかし、それはpostfix> = 2.10のためのものです。 postfix <2.10のユーザーの場合、複数のディレクティブにチェックを配置して、postfixが になりすぎないようにすることができます。

Q4:私の提案する構成は私が望むものを達成するでしょうか?

はい、現在のpostfixの制限を単純化するための良い仕事です。しかし、postfixはpleskの一部であることに注意してください。 pleskのエンジニアは、モジュール性や単純なメンテナンスなどの理由でこれらの制限を調整する場合があります。

概要:

  • Smtpd _ * _ restrictionのすべての制限をオンにすることはお勧めしません。
  • このため、postfix> = 2.10にはsmtpd_relay_restrictionを使用でき、postfix <2.10には他の制限チェックを使用できます
2
masegaloeh

あなたが何をするにせよ、外に出ないでください:

smtpd_client_restrictions = reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net

これらは私一人で大多数を捕らえてきました。

1
lkraav