外部から送信を経由されている場合について

いつもお世話になっております。

AWSのサーバでキューを見ると知らないアドレスで送信がされています。

送信にはpostfixを使用しています。

reject-ipなどを設置して再三送れないようにはしておりますがキリがないです。

利用されている場合、どのような対処が必要でしょうか。
(IPアドレスやパスワードの変更など)

アドバイスいただけましたら幸いです。

下記コマンドでは実行できておりました。

linux
1ps -ef |grep saslauthd
2```結果(最終行のみ)

root 22215 21609 0 15:04 pts/0 00:00:00 grep --color=auto saslauthd


下記はmain.cf　最近の対策設定

allow_percent_hack = yes
disable_vrfy_command = yes
swap_bangpath = yes


よろしくお願いいたします。

以下追記－－－－－
postconf -nの出力結果

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_mail_to_commands = forward
allow_percent_hack = yes
anvil_rate_time_unit = 60s
body_checks = regexp:/etc/postfix/body_checks
bounce_queue_lifetime = 24h
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
default_destination_concurrency_limit = 50
disable_vrfy_command = yes
header_checks = regexp:/etc/postfix/header_checks
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
inet_protocols = ipv4
mail_owner = postfix
mailbox_size_limit = 512000000
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
maximal_backoff_time = 60s
maximal_queue_lifetime = 24h
message_size_limit = 102400000
minimal_backoff_time = 10s
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain, xxxx.xxx.xxx, mail.xxxx.xxx.xxx
mydomain = xxxx.xxx.xxx
myhostname = www.xxxx.xxx.xxx
mynetworks = xxx.xxx.xxx.xx/xx, xxx.x.x.x/x, xx.xxx.xxx.xx, xxx.x.xx.xxx
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
queue_run_delay = 10s
readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES
relay_domains = $mydestination
resolve_numeric_domain = yes
sample_directory = /usr/share/doc/postfix-2.6.6/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_client_connection_count_limit = 200
smtpd_client_restrictions = permit_mynetworks, check_client_access cidr:/etc/postfix/reject_ip , permit
smtpd_recipient_limit = 2000
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $mydomain
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = reject_unknown_sender_domain, reject_non_fqdn_sender, hash:/etc/postfix/reject_sender
smtpd_tls_cert_file = /etc/httpd/www.xxxx.xxx.xxx.crt
smtpd_tls_key_file = /etc/httpd/www.xxxx.xxx.xxx.key
smtpd_use_tls = yes
swap_bangpath = yes
unknown_local_recipient_reject_code = 550


maillogの一部です。
```ここに言語を入力
May 30 14:00:51 ip-xxx-xxx-xxx-xxx postfix/error[1540]: 88845FD358: to=<xxxxx@yahoo.ne.jp>, relay=none, delay=14504, delays=14148/355/0/0, dsn=4.7.1, status=deferred (delivery temporarily suspended: host ymobilemx1.mail.yahoo.co.jp[xxx.xxx.xxx.xxx] refused to talk to me: xxx.xxx.xxx.xxx [TS03] All messages from xxx.xxx.xxx.xxx will be temporarily deferred; If retrying does not succeed, see https://www.yahoo-help.jp/app/answers/detail/a_id/80870/p/622)
May 30 14:00:51 ip-xxx-xxx-xxx-xxx postfix/error[1541]: 82B09115EE8: to=<xxxxx@yahoo.ne.jp>, relay=none, delay=8542, delas=8187/355/0/0, dsn=4.7.1, status=deferred (delivery temporarily suspended: host ymobilemx1.mail.yahoo.co.jp[xxx.xxx.xxx.xxx] refused to talk to me: 421 4.7.1 [TS03] All messages from xxx.xxx.xxx.xxx will be temporarily deferred; If retrying does not succeed, see https://www.yahoo-help.jp/app/answers/detail/a_id/80870/p/622)
May 30 14:00:51 ip-xxx-xxx-xxx-xxx postfix/qmgr[16673]: 36A3E11927E: from=<zzzzz@asahikawa-med.ac.jp>, size=2198, nrcpt=1 (queue active)
May 30 14:00:51 ip-xxx-xxx-xxx-xxx postfix/qmgr[16673]: 3627411B038: from=<zzzzz@asahikawa-med.ac.jp>, size=2204, nrcpt=1 (queue active)
May 30 14:00:51 ip-xxx-xxx-xxx-xxx postfix/qmgr[16673]: 3C802EEF40: from=<>, size=4130, nrcpt=1 (queue active)
May 30 14:00:51 ip-xxx-xxx-xxx-xxx postfix/qmgr[16673]: 3EAAB7F247: from=<zzzzz@asahikawa-med.ac.jp>, size=2189, nrcpt=1 (queue active)
May 30 14:00:51 ip-xxx-xxx-xxx-xxx postfix/error[1514]: 97D5DF3A1F: to=<xxxxx@yahoo.ne.jp>, relay=none, delay=20629, delays=20276/353/0/0, dsn=4.7.1, status=deferred (delivery temporarily suspended: host ymobilemx1.mail.yahoo.co.jp[xxx.xxx.xxx.xxx] refused to talk to me: xxx.xxx.xxx.xxx [TS03] All messages from xxx.xxx.xxx.xxx will be temporarily deferred; If retrying does not succeed, see https://www.yahoo-help.jp/app/answers/detail/a_id/80870/p/622)

知らないアドレス(@asahikawa-med.ac.jp)からヤフーに送信されております。
届かないので最後のURLを参照してくださいという文と思っています。
main.cfの対応から行っております。導入はまだ行っていないです。

CHERRY

2019/05/27 06:25 編集

送信されていますというのは、他のサーバーへ送信が成功しているということでしょうか？それともログには、拒否したと記録されていて、送信はされていないけど、サーバーに不正に接続されるのが嫌ということでしょうか？

marionetter

2019/05/27 06:34

送信成功しているかまでは把握できていないです。不正に接続送信され、キューが溜まることが嫌です。接続されているところから、接続されないようにしたいと考えております。

take88

2019/05/27 08:53

main.cf を全部張れますか？すでに回答されてる方も居ますがオープンリレーを許可してしまってるのでは？と推測してます。

marionetter

2019/05/27 09:08

main.cfを全部はちょっと難しいです。所々に直接IPアドレスを書いて認証しているので。。。遅くはなりますが貼れそうでしたら貼ってみます

CHERRY

2019/05/27 09:49 編集

postconf -n の出力結果からサーバの IP アドレスやドメイン名やユーザー名を置き換えた内容を貼ってもらえば、Postfix 設定でまずい部分の指摘はいろいろな人からつくと思います。

scsi

2019/05/27 09:58

該当のmaillogを見ないと正しい状況が掴めないですね。ぱっと思いつくだけでもこれだけあります。オープンリレーなのかパスワードが漏れてるのか Webサーバの送信フォームなどがザルでそこから送られているのかサーバにログインされているのか実はただのバックスキャッターなのか

marionetter

2019/05/28 03:36

色々とご指摘ありがとうございます。 postconf -nの出力結果を一部編集して乗せてみます。パスワードが漏れている可能性はないと思いたいです（数ヶ月前に作成して、自分のみSSH接続できないようにしたので）サーバにログインはされていないようです（lastコマンドで確認しました）送信フォームがザル（可能性があります）バックスキャッターの可能性も十分ありそうです・・・平行して調査してみます。

CHERRY

2019/05/28 04:38

やはり、maillog の確認も必要ですね。 smtpd_sasl_auth_enable = yes になっているということは、SMTP-Auth ( smtp 認証 )は、導入済みということでしょうか？

marionetter

2019/05/28 08:23

maillogでは送信先サーバに接続できませんでした、等のエラー文が多くありました。 SMTP-Authは設定していない可能性があります。現在、確認中で導入を検討しています。

doda

2019/05/28 09:07

まず落ち着いて下さい。 postconf -n の結果をざっと見た限りではオープンリレーになったりバックスキャッターを起こすような、すぐに判るような問題は見当たりません。現状は何が原因で何が起きているかも正しく把握出来ていない状態です。この状態で闇雲にSMTP-Authを導入しようとしたり、その他の設定を追加したりしても解決しないでしょう。まずは現状を把握し、どの辺りに問題が有るかを見極める為に、問題無い範囲でmaillogを出すのが解決への一番の近道だと思います。

scsi

2019/05/28 13:41

SSLv3 に対応してそうな設定ですね。。。

marionetter

2019/05/30 05:35

コメントいただきありがとうございます。現状SMTP-Authは元々入っているようでしたら、パスワードは変更するよう動いています。 maillogを乗せました。他の部分は lost connection after RCPT from unknown[IPアドレス] connect from unknown[IPｱﾄﾞﾚｽ] がありました。 SSLｖ３はサブドメインで送信していたからかもしれません。 25番ポートが使えなくなっているので。。。

doda

2019/05/30 07:29

まず出されたログの内で一番最後のメール 97D5DF3A1F についてどこから送られたかを確認しましょう。 grep 97D5DF3A1F /var/log/maillog を実行してみて下さい。また、postcat -q 97D5DF3A1F | sed '/^$/q' の結果も参考になると思います。

marionetter

2019/05/30 09:32

doda様　ご指摘いただきありがとうございます。検索したところ、最上部に以下の履歴がありました。 May 30 08:17:02 ip-xxx-xxx-xxx-xxx postfix/smtpd[21777]: 97D5DF3A1F: client=xxx-xxx-xxx-xxx.static.imsbiz.com[xxx-xxx-xxx-xxx], sasl_method=LOGIN, sasl_username=[使用メールアドレス] sasl_method=LOGINで再検索しましたら、上記と同じ文が大量に表示されました。。。早急に使用メールアドレスのパスワードを関連性のないものに変更しました。 Linux上のユーザー名とパスワードがローカルメールアプリ(サンダーバード等)接続のパスワードになるため、進入口は変更できていると思います。他に原因がないかチェックします。また、再度起きないよう存在するメールアドレスは変更します。

行動規範の内容に同意します

回答4件

ベストアンサー

May 30 08:17:02 ip-xxx-xxx-xxx-xxx postfix/smtpd[21777]: 97D5DF3A1F: client=xxx-xxx-xxx-xxx.static.imsbiz.com[xxx-xxx-xxx-xxx], sasl_method=LOGIN, sasl_username=[使用メールアドレス]

sasl_method=LOGINで再検索しましたら、上記と同じ文が大量に表示されました。。。
早急に使用メールアドレスのパスワードを関連性のないものに変更しました。

該当のユーザのパスワードが漏洩したか、安易だったため予測されたようですね。
既にパスワードを変更したとの事なので落ち着くと思いますが、念のため他のユーザも利用されていないか確認してみて下さい。

また、現在もメールキューにメールが溜まっていると思いますので、mailq コマンドでメールキューを確認し、不要なメールを postsuper -d "該当のメールのQueue ID" で削除して下さい。

投稿2019/05/30 09:59

doda

総合スコア947

marionetter

2019/05/31 00:52

ご回答いただきましてありがとうございます。安易なパスワードを使っていたことが原因です。念のため、存在するユーザのパスワードを関連性のない重複しないパスワードにします。キューの対処も教えていただきありがとうございます。

行動規範の内容に同意します

オープンリレー対策で検索していただくと、対処方法が出てくると思います。
まずは送信者認証や接続元のIPアドレスを指定するのがいいかもしれません。

投稿2019/05/27 08:25

Lucifer_5342

総合スコア32

marionetter

2019/05/27 09:02

ご回答いただきましてありがとうございます。同一の現象だったので、解決策も見つかりやすくなりました。送信者認証が合ってると思うので、こちらを実施してみます。ありがとうございます。

行動規範の内容に同意します

どの様な用途で公開されているのか・現状がどうなっているのか、具体的な内容が不明なので、一般論ですが...

サーバーに不特定多数の相手から接続してほしくないのであれば、許可する相手を特定して特定した許可する相手のみを firewall で通過させて、それ以外は firewall で drop してアクセスをブロック等の方法になると思います。

reject-ipなどを設置して再三送れないようにはしておりますがキリがないです。

まあ、公開しているサーバーを維持管理するというのは、不正アクセスしてくる輩との戦いなので、そうゆうものです。

監視ツールを使うことで、ある程度は自動化できると思いますので、労力を減らすことは可能ですが...　完全に 0 にはできないと思います。

(追記)

キューにたまるということは、不特定多数から自ドメイン宛のメールが届いているということでしょうか？
ドメイン宛のメール受信サーバーとして運用していて、不特定多数からの受信を止めれないということであれば、Postfix 側で対処することになると思います。

思いつく範囲で...

Postscreen や Greylisting の導入
Spamhaus 等のブラックリストの活用
逆引きできない IP アドレスからの接続拒否
FQDN ではない Client の接続を拒否
TLS 接続を強制

等でしょうか。

Postfix の設定内容がわかると回答がしやすいかもしれませんが...

投稿2019/05/27 07:00

編集2019/05/27 07:14

CHERRY

総合スコア25171

marionetter

2019/05/27 08:09

ご回答いただきましてありがとうございます。サーバの用途は、サイト公開とメール運用のためです。現状は知らないメールアドレスから知らないメールアドレスに送信している、問題が起きています。スパムの送信経路にされています。 (読み返すと説明足らずの文でした、申し訳ございません) 監視ツールの導入、逆引きできないIPアドレスからの接続拒否、TLS接続の強制は有効だと感じました。今一度調べて導入してみます。ありがとうございます。

CHERRY

2019/05/27 09:51 編集

オープンリレーでしたか。オープンリレーなサーバーは、ブラックリストに登録されて、いろいろなサーバーで受信拒否される可能性が高いので、早急に対応が必要です。すぐに対処できないのであれば、一度、Postfix を止めて、メールサービスを中断したほうが影響は少ないです。先月、GMO で、アドレスブロック全体がブラックリストに登録されたため、大規模な障害になっています。 [【不具合発生/GMOクラウド/Public】一部メール送信不具合につきまして](https://support.gmocloud.com/info/detail.php?no=1555381532) この例は、おそらく、spam を送信(中継？)していたサーバーが、ある程度の長期間放置されていたためと思いますが、このように自分だけではなく、周りのサーバー利用者を巻き込むので、注意が必要です。

marionetter

2019/05/28 04:03

ご連絡いただきましてありがとうございます。大規模な現象になってしまう可能性もあるんですね。。。別の都合でメールを止めれないので、早く対処します。逆引きできないIPアドレスからの接続拒否からやってみます。

行動規範の内容に同意します

回答というか、参考までにオープンリレーを防ぐ設定を貼っておきます。
マニュアル等見ながら内容を把握した上で、ご自身のサーバーにも設定してみてください。

posftfix
1smtpd_helo_required = yes
2disable_vrfy_command = yes
3strict_rfc821_envelopes = yes
4allow_percent_hack = yes
5swap_bangpath = yes
6allow_untrusted_routing = no
7smtpd_client_restrictions = permit_mynetworks, check_client_access hash:/etc/postfix/restrict_clients, reject_unknown_client, permit
8smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, reject_unknown_client, permit
9smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, permit_auth_destination, reject
10smtpd_sender_restrictions = reject_unknown_sender_domain, reject_sender_login_mismatch
11smtpd_etrn_restrictions = permit_mynetworks, reject_invalid_hostname

あと、SMTP Authのパスワードが突破された可能性もあります。
簡単なパスワードだとすぐ突破されてしまいますので、より強力なパスワードに変更するのがおすすめです。

また、現状把握をして、被害内容を特定してください。
maillog を調査するのが良いと思います。
ログについては次の資料をご覧になって必要な設定をしてください。

https://www.jpcert.or.jp/research/APT-loganalysis_Report_20151117.pdf

投稿2019/05/28 08:02

take88

総合スコア1373

marionetter

2019/05/30 06:44

ご回答いただきましてありがとうございます。添付いただいた設定を把握した上で、現設定に反映しました。また、SMTP Authが入っていない可能性があるため、メールログにて原因把握中です。 (/usr/lib/sasl　のフォルダが存在しなかったです) 親切に参考資料を張っていただきありがとうございます。

行動規範の内容に同意します

あなたの回答