はじめまして、いきなりの長文をお許しください。
もう数日悩んでいるのですが、うちのサーバはspamの中継サーバに利用されているのでしょうか。
OS：CentOS release 5.5 (Final)
メールサーバ：sendmail Version 8.13.8
ドメイン名：仮にmydomainとしています
まず、以下の第３者中継チェックはすべて正常にパスしています。
http://
<pre>
全てのテストが行われました, no relays accepted.
</pre>
設定は以下を参考におこないました。
http://
http://
しかしMail Daemonからは1日で多いときで1万を超えるエラーメール「Postmaster notify: see transcript for details」が届きます。
例：
------------------------
件名：Postmaster notify: see transcript for details
本文：(抜粋)
<pre>
with id p1PJHsT3004871
----- The following addresses had permanent fatal errors -----
<microsoftcorporation@msn.com>
(reason: 550 OU-002 Unfortunately, messages from 122.249.238.201 weren't sent. Please contact your Internet s...ock list. You can also refer your provider to http://
</pre>
------------------------
これに関するメールログをみると
<pre>
sudo grep p1PJHsT3004871 /var/log/maillog
Feb 27 04:05:06 mydomain sendmail[30055]: p1PJHsT3004871: to=<microsoftcorporation@msn.com>, delay=19:15:12, xdelay=00:00:00, mailer=esmtp, pri=1925296, relay=mx2.hotmail.com., dsn=4.0.0, stat=Deferred: Connection reset by mx2.hotmail.com.
</pre>
（...中略16行...）
<pre>
Feb 27 21:04:51 mydomain sendmail[12807]: p1PJHsT3004871: to=<microsoftcorporation@msn.com>, delay=1+12:14:57, xdelay=00:00:00, mailer=esmtp, pri=3455296, relay=mx2.hotmail.com., dsn=4.0.0, stat=Deferred: Connection reset by mx2.hotmail.com.
Feb 27 22:04:52 mydomain sendmail[23137]: p1PJHsT3004871: to=<microsoftcorporation@msn.com>, delay=1+13:14:58, xdelay=00:00:01, mailer=esmtp, pri=3545296, relay=mx2.hotmail.com. [65.55.37.88], dsn=5.0.0, stat=Service unavailable
Feb 27 22:04:52 mydomain sendmail[23137]: p1PJHsT3004871: p1RD2g4d023137: return to sender: Service unavailable
</pre>
となっています。
ためしにメールログの最初のsendmail[30055]をgrepすると、
<pre>
sudo grep -c "sendmail\[30055\]" /var/log/maillog
9408
sudo grep "sendmail\[30055\]" /var/log/maillog | head -n 10
Feb 27 04:02:42 mydomain sendmail[30055]: grew WorkList for /var/spool/mqueue to 2000
Feb 27 04:02:42 mydomain sendmail[30055]: grew WorkList for /var/spool/mqueue to 3000
Feb 27 04:02:42 mydomain sendmail[30055]: grew WorkList for /var/spool/mqueue to 4000
Feb 27 04:02:42 mydomain sendmail[30055]: grew WorkList for /var/spool/mqueue to 5000
Feb 27 04:02:43 mydomain sendmail[30055]: grew WorkList for /var/spool/mqueue to 6000
Feb 27 04:02:43 mydomain sendmail[30055]: grew WorkList for /var/spool/mqueue to 7000
Feb 27 04:02:58 mydomain sendmail[30055]: p1QB2gk6011774: to=<onlinetv@pcshop.com>, delay=07:57:59, xdelay=00:00:10, mailer=esmtp, pri=768750, relay=pcshop.com. [69.64.155.160], dsn=4.0.0, stat=Deferred: Connection refused by pcshop.com.
Feb 27 04:02:58 mydomain sendmail[30055]: p1Q3Hs3N025558: to=<onlinetv@pcshop.com>, delay=15:42:31, xdelay=00:00:00, mailer=esmtp, pri=1668750, relay=pcshop.com., dsn=4.0.0, stat=Deferred: Connection refused by pcshop.com.
Feb 27 04:04:59 mydomain sendmail[30055]: p1PBHsdc012066: to=<info@abgroup.com>, delay=17:53:53, xdelay=00:02:00, mailer=esmtp, pri=1832458, relay=abgroup.com. [82.98.86.162], dsn=4.0.0, stat=Deferred: Connection timed out with abgroup.com.
Feb 27 04:04:59 mydomain sendmail[30055]: p1PAHsBe032738: to=<info@abgroup.com>, delay=17:59:45, xdelay=00:00:00, mailer=esmtp, pri=1832458, relay=abgroup.com., dsn=4.0.0, stat=Deferred: Connection timed out with abgroup.com.
</pre>
となっています。
当初はstat=Deferredとなっているので、中継禁止にひっかかって送信できずに処分保留で延期されて、それが何度も繰り返されているのかと思っていたのですが、よく見てみると
<pre>
sudo grep "sendmail\[30055\]" /var/log/maillog | grep Sent | wc -l
53
sudo grep "sendmail\[30055\]" /var/log/maillog | grep Sent | tail -20
Feb 27 08:29:45 mydomain sendmail[30055]: p1PAU0IE002432: to=<adzlin_l@yahoo.com.my>,<adzlin_l@yahoo.com.sg>,<adzlin_m@yahoo.com.my>,<adzlin_m@yahoo.com.sg>,<adzlin_n@yahoo.com.my>,<adzlin_n@yahoo.com.sg>,<adzlin_o@yahoo.com.my>,<adzlin_o@yahoo.com.sg>,<adzlin_p@yahoo.com.my>,<adzlin_p@yahoo.com.sg>,<adzlin_q@yahoo.com.my>,<adzlin_q@yahoo.com.sg>, delay=1+12:59:13, xdelay=00:00:01, mailer=esmtp, pri=3663989, relay=mx1.mail.sg1.yahoo.com. [124.108.116.109], dsn=2.0.0, stat=Sent (ok dirdel 0/12)
Feb 27 08:29:47 mydomain sendmail[30055]: p1PB8fxQ010174: to=<al.rashwa-1961@yahoo.com.my>,<al.rashwa-1961@yahoo.com.sg>,<al.rashwa-1962@yahoo.com.my>,<al.rashwa-1962@yahoo.com.sg>,<al.rashwa-1963@yahoo.com.my>,<al.rashwa-1963@yahoo.com.sg>,<al.rashwa-1964@yahoo.com.my>,<al.rashwa-1964@yahoo.com.sg>,<al.rashwa1961@yahoo.com.my>,<al.rashwa1961@yahoo.com.sg>,<al.rashwa1962@yahoo.com.my>,<al.rashwa1962@yahoo.com.sg>,<al.rashwa1963@yahoo.com.my>,<al.rashwa1963@yahoo.com.sg>,<al.rashwa1964@yahoo.com.my>,<al.rashwa1964@yahoo.com.sg>, delay=1+12:20:24, xdelay=00:00:02, mailer=esmtp, pri=3663989, relay=mx1.mail.sg1.yahoo.com.
</pre>
（後略）
となっています。
これは中継禁止が充分ではなく、spamによる踏み台送信が一部成功してしまっている、ということなのでしょうか。
そもそも中継禁止にひっかかっていればto宛への送信を試みること自体があり得ないように思えて、心配です。
もしそうであれば、少しでも早く対処したいのですが、参考になるようなサイトや情報がありましたら教えていただけませんか？
よろしくお願いいたします。
もう数日悩んでいるのですが、うちのサーバはspamの中継サーバに利用されているのでしょうか。
OS：CentOS release 5.5 (Final)
メールサーバ：sendmail Version 8.13.8
ドメイン名：仮にmydomainとしています
まず、以下の第３者中継チェックはすべて正常にパスしています。
http://
<pre>
全てのテストが行われました, no relays accepted.
</pre>
設定は以下を参考におこないました。
http://
http://
しかしMail Daemonからは1日で多いときで1万を超えるエラーメール「Postmaster notify: see transcript for details」が届きます。
例：
------------------------
件名：Postmaster notify: see transcript for details
本文：(抜粋)
<pre>
with id p1PJHsT3004871
----- The following addresses had permanent fatal errors -----
<microsoftcorporation@msn.com>
(reason: 550 OU-002 Unfortunately, messages from 122.249.238.201 weren't sent. Please contact your Internet s...ock list. You can also refer your provider to http://
</pre>
------------------------
これに関するメールログをみると
<pre>
sudo grep p1PJHsT3004871 /var/log/maillog
Feb 27 04:05:06 mydomain sendmail[30055]: p1PJHsT3004871: to=<microsoftcorporation@msn.com>, delay=19:15:12, xdelay=00:00:00, mailer=esmtp, pri=1925296, relay=mx2.hotmail.com., dsn=4.0.0, stat=Deferred: Connection reset by mx2.hotmail.com.
</pre>
（...中略16行...）
<pre>
Feb 27 21:04:51 mydomain sendmail[12807]: p1PJHsT3004871: to=<microsoftcorporation@msn.com>, delay=1+12:14:57, xdelay=00:00:00, mailer=esmtp, pri=3455296, relay=mx2.hotmail.com., dsn=4.0.0, stat=Deferred: Connection reset by mx2.hotmail.com.
Feb 27 22:04:52 mydomain sendmail[23137]: p1PJHsT3004871: to=<microsoftcorporation@msn.com>, delay=1+13:14:58, xdelay=00:00:01, mailer=esmtp, pri=3545296, relay=mx2.hotmail.com. [65.55.37.88], dsn=5.0.0, stat=Service unavailable
Feb 27 22:04:52 mydomain sendmail[23137]: p1PJHsT3004871: p1RD2g4d023137: return to sender: Service unavailable
</pre>
となっています。
ためしにメールログの最初のsendmail[30055]をgrepすると、
<pre>
sudo grep -c "sendmail\[30055\]" /var/log/maillog
9408
sudo grep "sendmail\[30055\]" /var/log/maillog | head -n 10
Feb 27 04:02:42 mydomain sendmail[30055]: grew WorkList for /var/spool/mqueue to 2000
Feb 27 04:02:42 mydomain sendmail[30055]: grew WorkList for /var/spool/mqueue to 3000
Feb 27 04:02:42 mydomain sendmail[30055]: grew WorkList for /var/spool/mqueue to 4000
Feb 27 04:02:42 mydomain sendmail[30055]: grew WorkList for /var/spool/mqueue to 5000
Feb 27 04:02:43 mydomain sendmail[30055]: grew WorkList for /var/spool/mqueue to 6000
Feb 27 04:02:43 mydomain sendmail[30055]: grew WorkList for /var/spool/mqueue to 7000
Feb 27 04:02:58 mydomain sendmail[30055]: p1QB2gk6011774: to=<onlinetv@pcshop.com>, delay=07:57:59, xdelay=00:00:10, mailer=esmtp, pri=768750, relay=pcshop.com. [69.64.155.160], dsn=4.0.0, stat=Deferred: Connection refused by pcshop.com.
Feb 27 04:02:58 mydomain sendmail[30055]: p1Q3Hs3N025558: to=<onlinetv@pcshop.com>, delay=15:42:31, xdelay=00:00:00, mailer=esmtp, pri=1668750, relay=pcshop.com., dsn=4.0.0, stat=Deferred: Connection refused by pcshop.com.
Feb 27 04:04:59 mydomain sendmail[30055]: p1PBHsdc012066: to=<info@abgroup.com>, delay=17:53:53, xdelay=00:02:00, mailer=esmtp, pri=1832458, relay=abgroup.com. [82.98.86.162], dsn=4.0.0, stat=Deferred: Connection timed out with abgroup.com.
Feb 27 04:04:59 mydomain sendmail[30055]: p1PAHsBe032738: to=<info@abgroup.com>, delay=17:59:45, xdelay=00:00:00, mailer=esmtp, pri=1832458, relay=abgroup.com., dsn=4.0.0, stat=Deferred: Connection timed out with abgroup.com.
</pre>
となっています。
当初はstat=Deferredとなっているので、中継禁止にひっかかって送信できずに処分保留で延期されて、それが何度も繰り返されているのかと思っていたのですが、よく見てみると
<pre>
sudo grep "sendmail\[30055\]" /var/log/maillog | grep Sent | wc -l
53
sudo grep "sendmail\[30055\]" /var/log/maillog | grep Sent | tail -20
Feb 27 08:29:45 mydomain sendmail[30055]: p1PAU0IE002432: to=<adzlin_l@yahoo.com.my>,<adzlin_l@yahoo.com.sg>,<adzlin_m@yahoo.com.my>,<adzlin_m@yahoo.com.sg>,<adzlin_n@yahoo.com.my>,<adzlin_n@yahoo.com.sg>,<adzlin_o@yahoo.com.my>,<adzlin_o@yahoo.com.sg>,<adzlin_p@yahoo.com.my>,<adzlin_p@yahoo.com.sg>,<adzlin_q@yahoo.com.my>,<adzlin_q@yahoo.com.sg>, delay=1+12:59:13, xdelay=00:00:01, mailer=esmtp, pri=3663989, relay=mx1.mail.sg1.yahoo.com. [124.108.116.109], dsn=2.0.0, stat=Sent (ok dirdel 0/12)
Feb 27 08:29:47 mydomain sendmail[30055]: p1PB8fxQ010174: to=<al.rashwa-1961@yahoo.com.my>,<al.rashwa-1961@yahoo.com.sg>,<al.rashwa-1962@yahoo.com.my>,<al.rashwa-1962@yahoo.com.sg>,<al.rashwa-1963@yahoo.com.my>,<al.rashwa-1963@yahoo.com.sg>,<al.rashwa-1964@yahoo.com.my>,<al.rashwa-1964@yahoo.com.sg>,<al.rashwa1961@yahoo.com.my>,<al.rashwa1961@yahoo.com.sg>,<al.rashwa1962@yahoo.com.my>,<al.rashwa1962@yahoo.com.sg>,<al.rashwa1963@yahoo.com.my>,<al.rashwa1963@yahoo.com.sg>,<al.rashwa1964@yahoo.com.my>,<al.rashwa1964@yahoo.com.sg>, delay=1+12:20:24, xdelay=00:00:02, mailer=esmtp, pri=3663989, relay=mx1.mail.sg1.yahoo.com.
</pre>
（後略）
となっています。
これは中継禁止が充分ではなく、spamによる踏み台送信が一部成功してしまっている、ということなのでしょうか。
そもそも中継禁止にひっかかっていればto宛への送信を試みること自体があり得ないように思えて、心配です。
もしそうであれば、少しでも早く対処したいのですが、参考になるようなサイトや情報がありましたら教えていただけませんか？
よろしくお願いいたします。
|
|
|
|
コメント(13)
こんばんは。
もうsendmailを離れて久しいですが…。
なんで今更sendmailを使ってるのですかというツッコミは野暮なので置いておきます。
提示された情報からの推測ですが、限りなく黒に近い感じ。
/var/log/maillogですが、
> sudo grep p1PJHsT3004871 /var/log/maillog
とやった時に、From: は出てきませんでしたか? 送信元のIPアドレスはそれでわかる筈です。もし/var/log/maillogに無いのならおそらくローテーションされてしまっていますので、/var/log/maillog.?.gzに検索を掛けてみて下さい。
あと心配なのは、本当に意図したsendmail.cfを使用しているか、という辺りですが、その辺は大丈夫ですか?
ひとまず、こんなところで。
もうsendmailを離れて久しいですが…。
なんで今更sendmailを使ってるのですかというツッコミは野暮なので置いておきます。
提示された情報からの推測ですが、限りなく黒に近い感じ。
/var/log/maillogですが、
> sudo grep p1PJHsT3004871 /var/log/maillog
とやった時に、From: は出てきませんでしたか? 送信元のIPアドレスはそれでわかる筈です。もし/var/log/maillogに無いのならおそらくローテーションされてしまっていますので、/var/log/maillog.?.gzに検索を掛けてみて下さい。
あと心配なのは、本当に意図したsendmail.cfを使用しているか、という辺りですが、その辺は大丈夫ですか?
ひとまず、こんなところで。
Wild_Geese 様、たっつぁん 様
ご助言ありがとうございます。
いろいろ調べておりましたらお返事が遅くなってしまいました。
調べた結果、またしても長文になってしまい、投稿文字長制限にひっかかってしまうので２回に分けて投稿いたします。
-------------------------------
> > sudo grep p1PJHsT3004871 /var/log/maillog
> とやった時に、From: は出てきませんでしたか?
> 1 のコメント同様に From が提示されていないので、
おふた方のご助言を元に調べてみました。
<pre>
sudo grep "sendmail\[30055\]" /var/log/maillog* | grep -i from | grep -v 'Messages from' | less
</pre>
(中略...toのアドレスにfromを含むものを目検で除外...)
<pre>
/var/log/maillog.2:Feb 19 18:29:40 mydomain sendmail[30055]: p1J9TOC7030055: from=<pirezrusso@yahoo.co.uk>, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=[41.217.65.10]
</pre>
<pre>
sudo grep "sendmail\[30055\]" /var/log/maillog.2
Feb 19 18:29:30 mydomain sendmail[30055]: AUTH=server, relay=[41.217.65.10], authid=www, mech=LOGIN, bits=0
Feb 19 18:29:37 mydomain sendmail[30055]: p1J9TOC7030055: ruleset=check_mail, arg1=<pirezrusso@yahoo.co.uk>, relay=[41.217.65.10], reject=550 5.7.1 <pirezrusso@yahoo.co.uk>... Access denied
Feb 19 18:29:40 mydomain sendmail[30055]: p1J9TOC7030055: from=<pirezrusso@yahoo.co.uk>, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=[41.217.65.10]
</pre>
fromが一件だけありました。
送信元は
from: pirezrusso@yahoo.co.uk
IP: 41.217.65.10
と解釈できました。
で、このリレー送信要求ですが、以下サイトのmaillogから拒絶できている場合の例を見ますと、rejectやAccess deniedが見えますので、拒絶されていると検討をつけました。
http://www.hart.co.jp/spam/rejiponly.html
> あと心配なのは、本当に意図したsendmail.cfを使用しているか
これも大変に気になりましたので、以下を参考に調べてみました。
http://homepage2.nifty.com/BASH/sol/mail/mail_rcpt.html
<pre>
sudo /usr/sbin/sendmail -C/etc/mail/sendmail.cf -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> .D{client_addr}41.217.65.10
> .D{client_name}yahoo.co.uk
> check_mail pirezrusso@yahoo.co.uk
check_mail input: pirezrusso @ yahoo . co . uk
</pre>
(...中略...)
<pre>
Basic_check_mail returns: < OKR >
check_mail returns: < OKR >
>
> check_rcpt pirezrusso@yahoo.co.uk
check_rcpt input: pirezrusso @ yahoo . co . uk
</pre>
(...中略...)
<pre>
Relay_ok returns: yahoo . co . uk
Basic_check_rcpt returns: $# error $@ 5 . 7 . 1 $: "550 Relaying denied. Proper authentication required."
check_rcpt returns: $# error $@ 5 . 7 . 1 $: "550 Relaying denied. Proper authentication required."
>
上記のサイトによりますと、「最後の部分が OK または error になるかでスパムのチェックがきちんと設定されているか確認できます」とのことですので、この結果をみるとsendmail.cfは一応うまく動いてくれているのか、という気がいたしました。
ここまで見てみた限り、スパムの中継を許していないように思えてしまいます。
しかし一方で、今日も引き続きMail Daemonから1600件超の「Postmaster notify: see transcript for details」が届いています。
うち、2000件ほどは送信されてしまっている(？)ようです。
<pre>
sudo grep 'Mar 1' /var/log/maillog | grep 'stat=Sent' | wc -l
2012
</pre>
ご助言ありがとうございます。
いろいろ調べておりましたらお返事が遅くなってしまいました。
調べた結果、またしても長文になってしまい、投稿文字長制限にひっかかってしまうので２回に分けて投稿いたします。
-------------------------------
> > sudo grep p1PJHsT3004871 /var/log/maillog
> とやった時に、From: は出てきませんでしたか?
> 1 のコメント同様に From が提示されていないので、
おふた方のご助言を元に調べてみました。
<pre>
sudo grep "sendmail\[30055\]" /var/log/maillog* | grep -i from | grep -v 'Messages from' | less
</pre>
(中略...toのアドレスにfromを含むものを目検で除外...)
<pre>
/var/log/maillog.2:Feb 19 18:29:40 mydomain sendmail[30055]: p1J9TOC7030055: from=<pirezrusso@yahoo.co.uk>, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=[41.217.65.10]
</pre>
<pre>
sudo grep "sendmail\[30055\]" /var/log/maillog.2
Feb 19 18:29:30 mydomain sendmail[30055]: AUTH=server, relay=[41.217.65.10], authid=www, mech=LOGIN, bits=0
Feb 19 18:29:37 mydomain sendmail[30055]: p1J9TOC7030055: ruleset=check_mail, arg1=<pirezrusso@yahoo.co.uk>, relay=[41.217.65.10], reject=550 5.7.1 <pirezrusso@yahoo.co.uk>... Access denied
Feb 19 18:29:40 mydomain sendmail[30055]: p1J9TOC7030055: from=<pirezrusso@yahoo.co.uk>, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=[41.217.65.10]
</pre>
fromが一件だけありました。
送信元は
from: pirezrusso@yahoo.co.uk
IP: 41.217.65.10
と解釈できました。
で、このリレー送信要求ですが、以下サイトのmaillogから拒絶できている場合の例を見ますと、rejectやAccess deniedが見えますので、拒絶されていると検討をつけました。
http://www.hart.co.jp/spam/rejiponly.html
> あと心配なのは、本当に意図したsendmail.cfを使用しているか
これも大変に気になりましたので、以下を参考に調べてみました。
http://homepage2.nifty.com/BASH/sol/mail/mail_rcpt.html
<pre>
sudo /usr/sbin/sendmail -C/etc/mail/sendmail.cf -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> .D{client_addr}41.217.65.10
> .D{client_name}yahoo.co.uk
> check_mail pirezrusso@yahoo.co.uk
check_mail input: pirezrusso @ yahoo . co . uk
</pre>
(...中略...)
<pre>
Basic_check_mail returns: < OKR >
check_mail returns: < OKR >
>
> check_rcpt pirezrusso@yahoo.co.uk
check_rcpt input: pirezrusso @ yahoo . co . uk
</pre>
(...中略...)
<pre>
Relay_ok returns: yahoo . co . uk
Basic_check_rcpt returns: $# error $@ 5 . 7 . 1 $: "550 Relaying denied. Proper authentication required."
check_rcpt returns: $# error $@ 5 . 7 . 1 $: "550 Relaying denied. Proper authentication required."
>
上記のサイトによりますと、「最後の部分が OK または error になるかでスパムのチェックがきちんと設定されているか確認できます」とのことですので、この結果をみるとsendmail.cfは一応うまく動いてくれているのか、という気がいたしました。
ここまで見てみた限り、スパムの中継を許していないように思えてしまいます。
しかし一方で、今日も引き続きMail Daemonから1600件超の「Postmaster notify: see transcript for details」が届いています。
うち、2000件ほどは送信されてしまっている(？)ようです。
<pre>
sudo grep 'Mar 1' /var/log/maillog | grep 'stat=Sent' | wc -l
2012
</pre>
続きを失礼します。
---------------------------
> オープンリレーではなく、内部のクライアントの bot 化の可能性も否定できません
浅学なりに、たっつぁん様がおっしゃっているのはもしかしたら外部からspamメールが送信され続けているわけではなく、サーバ内部で送信をリトライするようなプロセスが立ち上がっているのでは？というような意味に解釈して調べてみました。
<pre>
ps alx | grep sendmail | grep -v grep | grep -v fail2ban
4 0 1157 22789 16 0 8452 3092 finish T pts/0 0:00 /usr/sbin/sendmail -C/etc/mail/sendmail.cf -bt
4 0 2223 22789 16 0 8312 3024 finish T pts/0 0:00 /usr/sbin/sendmail -C/etc/mail/sendmail.cf -bt
5 0 2910 27970 15 0 9996 4320 stext S ? 0:00 sendmail: ./p1QAC82b002665 prodigy.com.: user open
5 0 4885 27970 17 0 10256 4460 stext S ? 0:03 sendmail: ./p1PBkf53017736 webmail.athens.edu.: user open
5 0 6826 27970 16 0 10400 4740 stext S ? 0:12 sendmail: ./p1PAYCEm003385 email.mayfieldewswireless.net.: user open
5 0 14974 27970 16 0 10132 4376 stext D ? 0:04 sendmail: mx2.netfirms.com.: idle
5 0 16911 27970 18 0 10264 4580 stext S ? 0:11 sendmail: ./p1P9KjQw022562 wlgdirect.com.: user open
5 0 25098 27970 15 0 10116 4404 stext S ? 0:02 sendmail: ./p1PBU1f3014143 smtp-mx1.aci.on.ca.: user open
5 0 27022 27970 16 0 10384 4664 stext S ? 0:06 sendmail: ./p1P2HsCG015627 abgroup.com.: user open
5 0 27970 1 15 0 9424 2004 stext Ss ? 0:00 sendmail: accepting connections
1 51 27979 1 18 0 8264 1520 pause Ss ? 0:00 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
5 0 28946 27970 15 0 10420 4740 stext S ? 0:10 sendmail: ./p1P9iBpD026398 dns2.mpw.net.: user open
</pre>
しかし私にはそれらしきものが分かりません。「Queue runner@01:00:00 for /var/spool/clientmqueue」をキックしているのがbotかと(根拠なく)疑ってみましたが、親IDが1となっているので、違うでしょうか。
Wild_Geese様の「今更sendmail」のご指摘もありますし、qmailかpostfixで構築し直した方が賢明、でしょうか。。
正規のメールサーバの用途としては、今はまだ小さな１法人で使用しているだけですので、ごめんなさいして再構築することも考えてみようかと思います。
なにより、無関係なひとたちにこうしてせっせと迷惑メールを送信してしまっているかもしれないと思うと、サーバ運営者として自分が残念です。
他にもし何かよい調査方法や対応方法などがありましたらお教えください。
ありがとうございましたm(_ _)m
---------------------------
> オープンリレーではなく、内部のクライアントの bot 化の可能性も否定できません
浅学なりに、たっつぁん様がおっしゃっているのはもしかしたら外部からspamメールが送信され続けているわけではなく、サーバ内部で送信をリトライするようなプロセスが立ち上がっているのでは？というような意味に解釈して調べてみました。
<pre>
ps alx | grep sendmail | grep -v grep | grep -v fail2ban
4 0 1157 22789 16 0 8452 3092 finish T pts/0 0:00 /usr/sbin/sendmail -C/etc/mail/sendmail.cf -bt
4 0 2223 22789 16 0 8312 3024 finish T pts/0 0:00 /usr/sbin/sendmail -C/etc/mail/sendmail.cf -bt
5 0 2910 27970 15 0 9996 4320 stext S ? 0:00 sendmail: ./p1QAC82b002665 prodigy.com.: user open
5 0 4885 27970 17 0 10256 4460 stext S ? 0:03 sendmail: ./p1PBkf53017736 webmail.athens.edu.: user open
5 0 6826 27970 16 0 10400 4740 stext S ? 0:12 sendmail: ./p1PAYCEm003385 email.mayfieldewswireless.net.: user open
5 0 14974 27970 16 0 10132 4376 stext D ? 0:04 sendmail: mx2.netfirms.com.: idle
5 0 16911 27970 18 0 10264 4580 stext S ? 0:11 sendmail: ./p1P9KjQw022562 wlgdirect.com.: user open
5 0 25098 27970 15 0 10116 4404 stext S ? 0:02 sendmail: ./p1PBU1f3014143 smtp-mx1.aci.on.ca.: user open
5 0 27022 27970 16 0 10384 4664 stext S ? 0:06 sendmail: ./p1P2HsCG015627 abgroup.com.: user open
5 0 27970 1 15 0 9424 2004 stext Ss ? 0:00 sendmail: accepting connections
1 51 27979 1 18 0 8264 1520 pause Ss ? 0:00 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
5 0 28946 27970 15 0 10420 4740 stext S ? 0:10 sendmail: ./p1P9iBpD026398 dns2.mpw.net.: user open
</pre>
しかし私にはそれらしきものが分かりません。「Queue runner@01:00:00 for /var/spool/clientmqueue」をキックしているのがbotかと(根拠なく)疑ってみましたが、親IDが1となっているので、違うでしょうか。
Wild_Geese様の「今更sendmail」のご指摘もありますし、qmailかpostfixで構築し直した方が賢明、でしょうか。。
正規のメールサーバの用途としては、今はまだ小さな１法人で使用しているだけですので、ごめんなさいして再構築することも考えてみようかと思います。
なにより、無関係なひとたちにこうしてせっせと迷惑メールを送信してしまっているかもしれないと思うと、サーバ運営者として自分が残念です。
他にもし何かよい調査方法や対応方法などがありましたらお教えください。
ありがとうございましたm(_ _)m
こんばんは。
先の投稿で書き忘れましたが、mailqコマンドは実行されましたでしょうか。このコマンドの出力で、現在queueに溜まったメールについて、誰が何処へ出そうとしているかがわかります。| wc -l でいま何通くらい溜まっているかも知ることができます。
-----
ただ、正直に申し上げまして、仕事として引き受けているのであれば、既に数日間に渡って状況がこの様になってしまっている点を考えると、再構築する方が正しい様な気もします。これ以上あちこちいじっても更に問題を増やすだけの様にも思います(私がリーダーだったら速攻で作り直せ命令を出している事でしょう)。
sendmailは昔から取り扱いの難しい、非常に厄介なソフトウェアです。sendmailに対して自信が持てず、かつ、もしお金と状況が許すのであれば、Postfixを使用される事を推薦したいです。ただ、qmailやPostfixであっても、おかしな設定をすればたちまち攻撃のターゲットにされてしまう事には変わりはなく、個々の設定の意味をきちんと理解する事が求められます。
こんなアドバイスしかできませんが…。
先の投稿で書き忘れましたが、mailqコマンドは実行されましたでしょうか。このコマンドの出力で、現在queueに溜まったメールについて、誰が何処へ出そうとしているかがわかります。| wc -l でいま何通くらい溜まっているかも知ることができます。
-----
ただ、正直に申し上げまして、仕事として引き受けているのであれば、既に数日間に渡って状況がこの様になってしまっている点を考えると、再構築する方が正しい様な気もします。これ以上あちこちいじっても更に問題を増やすだけの様にも思います(私がリーダーだったら速攻で作り直せ命令を出している事でしょう)。
sendmailは昔から取り扱いの難しい、非常に厄介なソフトウェアです。sendmailに対して自信が持てず、かつ、もしお金と状況が許すのであれば、Postfixを使用される事を推薦したいです。ただ、qmailやPostfixであっても、おかしな設定をすればたちまち攻撃のターゲットにされてしまう事には変わりはなく、個々の設定の意味をきちんと理解する事が求められます。
こんなアドバイスしかできませんが…。
> sudo grep "sendmail\[30055\]"
今回の場合、PID をつけてもあまり意味がありません。
p1PJHsT3004871 といったキュー ID で検索してください。
すると from= を含む行と to= を含む行がセットで出てくると思います。
from= がメールを受けたときのログです。
これの relay= に接続元の IP アドレスが書いてあります。
to= がメールを送るときのログです。
これの relay= が接続先の IP アドレスです。
この両者の IP アドレスが組織外の場合、「不正中継に利用されている」と言えます。
sendmail 自体は「今更」というほどのものではないと思います。
ちゃんと設定すればちゃんと動きます。
ただその「ちゃんと設定する」までのハードルは Postfix より高いかもしれません。
qmail は「今更」です。
http://ya.maya.st/d/201102a.html#s20110207_1
今回の場合、PID をつけてもあまり意味がありません。
p1PJHsT3004871 といったキュー ID で検索してください。
すると from= を含む行と to= を含む行がセットで出てくると思います。
from= がメールを受けたときのログです。
これの relay= に接続元の IP アドレスが書いてあります。
to= がメールを送るときのログです。
これの relay= が接続先の IP アドレスです。
この両者の IP アドレスが組織外の場合、「不正中継に利用されている」と言えます。
sendmail 自体は「今更」というほどのものではないと思います。
ちゃんと設定すればちゃんと動きます。
ただその「ちゃんと設定する」までのハードルは Postfix より高いかもしれません。
qmail は「今更」です。
http://ya.maya.st/d/201102a.html#s20110207_1
Wild_Geese様、こんばんは。
mailqは実行しておりませんでした。ログばかり気にしており、キューを見ることが頭にありませんでした。
<pre>
sudo mailq | wc -l
49112
sudo ls -l /var/spool/mqueue/ | wc -l
6629
</pre>
…grepでspamでないものが残っていないか確認したのち、キューに溜まったメールはすべて削除することにしました。
<pre>
sudo /etc/rc.d/init.d/sendmail stop
sm-client を停止中: [ OK ]
sendmail を停止中: [ OK ]
sudo find /var/spool/mqueue/ -type f -exec rm {} \;
sudo mailq | wc -l
2
sudo mailq
/var/spool/mqueue is empty
Total requests: 0
sudo /etc/rc.d/init.d/sendmail start
sendmail を起動中: [ OK ]
sm-client を起動中: [ OK ]
</pre>
今後はPostfixで再構築をおこなう方向で考えています。
利用者は法人メンバーなのですが、まだ外部への事業が始まっていないこともあって、今ならまだ影響も低めだと思います。
これがリリース後だったら、目もあてられないところでした。
今度はしっかり腰を据えて構築してみたいと思います。
とはいえあまり悠長にはしていられませんが。今回は自分でサーバを運営、管理することの大変さや責任の大きさを身に沁みて感じました。
アドバイスいただかなければ、今でも一縷の希望にしがみついてあくせくしていた気がいたします。
K-To 様
ご指摘ありがとうございます。
メールサーバといえばなんの疑いもなくsendmailと安直に考え、ハードルの高さや知識の必要性を軽視していました。
spamをバラまくソフトが仕込まれている可能性もあるのですね。
sendmail.mc の
dnl DEMON_OPTIONS('port=smtp,Addr=127.0.0.1,Name=MTA')dnl
をコメントアウト解除して、しばらくローカルしかメールを送信できないようにして様子を見てみる、という検証の仕方もありでしょうか。
今後メールを解析するときはキューIDから追いかける癖もしっかりつけておこうと思います。
次は同じ轍を踏まないよう、頑張ってみます。
ありがとうございましたm(_ _)m
mailqは実行しておりませんでした。ログばかり気にしており、キューを見ることが頭にありませんでした。
<pre>
sudo mailq | wc -l
49112
sudo ls -l /var/spool/mqueue/ | wc -l
6629
</pre>
…grepでspamでないものが残っていないか確認したのち、キューに溜まったメールはすべて削除することにしました。
<pre>
sudo /etc/rc.d/init.d/sendmail stop
sm-client を停止中: [ OK ]
sendmail を停止中: [ OK ]
sudo find /var/spool/mqueue/ -type f -exec rm {} \;
sudo mailq | wc -l
2
sudo mailq
/var/spool/mqueue is empty
Total requests: 0
sudo /etc/rc.d/init.d/sendmail start
sendmail を起動中: [ OK ]
sm-client を起動中: [ OK ]
</pre>
今後はPostfixで再構築をおこなう方向で考えています。
利用者は法人メンバーなのですが、まだ外部への事業が始まっていないこともあって、今ならまだ影響も低めだと思います。
これがリリース後だったら、目もあてられないところでした。
今度はしっかり腰を据えて構築してみたいと思います。
とはいえあまり悠長にはしていられませんが。今回は自分でサーバを運営、管理することの大変さや責任の大きさを身に沁みて感じました。
アドバイスいただかなければ、今でも一縷の希望にしがみついてあくせくしていた気がいたします。
K-To 様
ご指摘ありがとうございます。
メールサーバといえばなんの疑いもなくsendmailと安直に考え、ハードルの高さや知識の必要性を軽視していました。
spamをバラまくソフトが仕込まれている可能性もあるのですね。
sendmail.mc の
dnl DEMON_OPTIONS('port=smtp,Addr=127.0.0.1,Name=MTA')dnl
をコメントアウト解除して、しばらくローカルしかメールを送信できないようにして様子を見てみる、という検証の仕方もありでしょうか。
今後メールを解析するときはキューIDから追いかける癖もしっかりつけておこうと思います。
次は同じ轍を踏まないよう、頑張ってみます。
ありがとうございましたm(_ _)m
K-To 様
説明が至らずすみません。
> 最初の書き込みの @yahoo.com.sg
ですが、K-To 様が書き込まれる前の、まだキューIDから検索する考えがないときにPIDからgrepで"from="を含むものが1件だけ該当したので、それが送信元のspam業者と検討をつけました。
> from: pirezrusso@yahoo.co.uk
> IP: 41.217.65.10
http://www.rbl.jp/
上記のIP ブラックリストチェックにも掲載されているナイジェリアのzoomnigeria.comというドメインでした。
その後も不作為抽出で他のPIDもいろいろgrepしていたのですが、
217.115.112.38 (webworld.ie)
221.0.79.70 (apnic.net)
112.4.152.222 (chinamobile.com)
など、他のブラックリスト掲載ドメインからの不正中継も確認できました。
K-To 様のPIDよりキューIDというのは、PIDよりキューIDの方が確実だという意味で聞いておりましたが、PIDからとれるfromだと、「はたして本当にそのIPから最初に送られたかどうかはわからない」ということでしょうか。
今はそれらのブラックリストの最初の3セグメントくらいをとって/etc/mail/accessでREJECTをかけていますが、このままだといたちごっこというか、REJECTも結局8ドメインの登録で断念してしまいました。
本日、mailqをみたところ5万行近くキューがたまっているのを見て、おそらくほとんどが不正にリレーされたものなので、もっと上位レベルでの食いとめ方も分からないのにそれらを潰しながら運用していくよりは、メールサーバを構築し直した方がよいと思えてしまいました。
それで「今後は」とまるで投げ出したような発言をしてしまったようです。
たしかにそうは言っても、今すぐメールサーバを入れ替えるわけではなく、現在も動いていますし、何か対症療法でも防ぐ手立ては打たなければならないのかもしれませんが。。
いや、でもK-To様が言ってるのはそういうことではなく、もしクライアントのマシンにスパムをバラまくソフトが仕込まれていたらサーバを構築し直してもダメだから、別に個別に対処しなくてもよいから原因をもう少し追いかけないと結局同じ轍を踏むよ、ということをおっしゃっている気がしてきました^^;
見当違いかもしれませんが、sendmail.mc の
dnl DEMON_OPTIONS('port=smtp,Addr=127.0.0.1,Name=MTA')dnl
を
DEMON_OPTIONS('port=smtp,Addr=127.0.0.1,Name=MTA')dnl
にしてからキューをいったん削除して、しばらく外から送信できない状態でキューが溜まるか確認してみようとは思っていました。それで溜まるようなら内側からやられていると。
まだその場合どうしたらいいのかなど、何も考えられていないのですが。
説明が至らずすみません。
> 最初の書き込みの @yahoo.com.sg
ですが、K-To 様が書き込まれる前の、まだキューIDから検索する考えがないときにPIDからgrepで"from="を含むものが1件だけ該当したので、それが送信元のspam業者と検討をつけました。
> from: pirezrusso@yahoo.co.uk
> IP: 41.217.65.10
http://www.rbl.jp/
上記のIP ブラックリストチェックにも掲載されているナイジェリアのzoomnigeria.comというドメインでした。
その後も不作為抽出で他のPIDもいろいろgrepしていたのですが、
217.115.112.38 (webworld.ie)
221.0.79.70 (apnic.net)
112.4.152.222 (chinamobile.com)
など、他のブラックリスト掲載ドメインからの不正中継も確認できました。
K-To 様のPIDよりキューIDというのは、PIDよりキューIDの方が確実だという意味で聞いておりましたが、PIDからとれるfromだと、「はたして本当にそのIPから最初に送られたかどうかはわからない」ということでしょうか。
今はそれらのブラックリストの最初の3セグメントくらいをとって/etc/mail/accessでREJECTをかけていますが、このままだといたちごっこというか、REJECTも結局8ドメインの登録で断念してしまいました。
本日、mailqをみたところ5万行近くキューがたまっているのを見て、おそらくほとんどが不正にリレーされたものなので、もっと上位レベルでの食いとめ方も分からないのにそれらを潰しながら運用していくよりは、メールサーバを構築し直した方がよいと思えてしまいました。
それで「今後は」とまるで投げ出したような発言をしてしまったようです。
たしかにそうは言っても、今すぐメールサーバを入れ替えるわけではなく、現在も動いていますし、何か対症療法でも防ぐ手立ては打たなければならないのかもしれませんが。。
いや、でもK-To様が言ってるのはそういうことではなく、もしクライアントのマシンにスパムをバラまくソフトが仕込まれていたらサーバを構築し直してもダメだから、別に個別に対処しなくてもよいから原因をもう少し追いかけないと結局同じ轍を踏むよ、ということをおっしゃっている気がしてきました^^;
見当違いかもしれませんが、sendmail.mc の
dnl DEMON_OPTIONS('port=smtp,Addr=127.0.0.1,Name=MTA')dnl
を
DEMON_OPTIONS('port=smtp,Addr=127.0.0.1,Name=MTA')dnl
にしてからキューをいったん削除して、しばらく外から送信できない状態でキューが溜まるか確認してみようとは思っていました。それで溜まるようなら内側からやられていると。
まだその場合どうしたらいいのかなど、何も考えられていないのですが。
> "from="を含むものが1件だけ該当したので、それが送信元のspam業者と検討をつけました。
このメールのキュー ID で検索して to= を含む行は確認しましたか?
>>3 によると "Access denied" となっているので、たぶん to= の行はないと思います。
> PIDからとれるfromだと、「はたして本当にそのIPから最初に送られたかどうかはわからない」ということでしょうか。
from= だけではその IP アドレスから SMTP 接続を受けたことしかわからず、
「不正中継を確認した」ことにはなりません。
同じキュー ID を含む to= の行を見て、stat= の内容を見て、
それではじめて「不正中継を確認した」ことにはなります。
> /etc/mail/accessでREJECTをかけていますが、
botnet を使用して送られている場合はそれでは間に合いません。
http://ja.wikipedia.org/wiki/%E3%83%9C%E3%83%83%E3%83%88%E3%83%8D%E3%83%83%E3%83%88
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20041215/153889/
> 原因をもう少し追いかけないと結局同じ轍を踏むよ、
そういうことです。
このメールのキュー ID で検索して to= を含む行は確認しましたか?
>>3 によると "Access denied" となっているので、たぶん to= の行はないと思います。
> PIDからとれるfromだと、「はたして本当にそのIPから最初に送られたかどうかはわからない」ということでしょうか。
from= だけではその IP アドレスから SMTP 接続を受けたことしかわからず、
「不正中継を確認した」ことにはなりません。
同じキュー ID を含む to= の行を見て、stat= の内容を見て、
それではじめて「不正中継を確認した」ことにはなります。
> /etc/mail/accessでREJECTをかけていますが、
botnet を使用して送られている場合はそれでは間に合いません。
http://ja.wikipedia.org/wiki/%E3%83%9C%E3%83%83%E3%83%88%E3%83%8D%E3%83%83%E3%83%88
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20041215/153889/
> 原因をもう少し追いかけないと結局同じ轍を踏むよ、
そういうことです。
8>そーるわんさん
>>メールサーバといえばなんの疑いもなくsendmailと安直に考え、ハードルの高さや知識の必要性を軽視していました。
>>spamをバラまくソフトが仕込まれている可能性もあるのですね。
Postfix の方が比較的簡単とは言え、きちんと設定しなければ spam をばらまく可能性がある点については Sendmail と同じです
PID と キューID の違いとか、From に出ているアドレスの信頼性とか、(Sendmail のログ書式を知らないので何とも言えませんが) IP アドレスの信頼性とか、この辺りをきちんと理解できていないと、今後も踏み台の兆候を見逃すことになりますよ
>>メールサーバといえばなんの疑いもなくsendmailと安直に考え、ハードルの高さや知識の必要性を軽視していました。
>>spamをバラまくソフトが仕込まれている可能性もあるのですね。
Postfix の方が比較的簡単とは言え、きちんと設定しなければ spam をばらまく可能性がある点については Sendmail と同じです
PID と キューID の違いとか、From に出ているアドレスの信頼性とか、(Sendmail のログ書式を知らないので何とも言えませんが) IP アドレスの信頼性とか、この辺りをきちんと理解できていないと、今後も踏み台の兆候を見逃すことになりますよ
お返事が送れてすみません。
K-To 様
> >>3 によると "Access denied" となっているので、たぶん to= の行はないと思います。
maillogを走査してみました。
<pre>
sudo grep "Access denied" /var/log/maillog | awk '{print $6}' | sudo ruby -e "cnt=0; while qid=STDIN.gets; unless qid.include?('ruleset'); cnt+=1; system(\"grep #{qid.chomp.chomp(':')} /var/log/maillog | grep 'to=<'\"); end; end; p cnt"
1544
</pre>
Access deniedを含むレコードは1544件ありましたが、おっしゃるとおりto=を含むものは1件もありませんでした。
あれからキューIDでひっかけてfrom=を含むログを調べて、IPだけでなく、メールアカウントもREJECTかけるようにして、(対症療法ですが)ずいぶん静かになりました。
spam業者もリレー失敗を検知すると大量送信をやめる、ような印象です。
今はまだ知識が全然足りないので、しばらく勉強してから乗り換えなり、外部メールサービスを検討するなりしてみようと思います。
たっつぁん様
ありがとうございます。もう少し勉強してから、はたしてsendmailからpostfixへ乗り換えることで改善するのか（設定の容易さによってspam対策できるレベルまで自身の理解が及ぶのか）、そもそも自前のメールサーバの構築がまだ早計なのか、あらためて考えてみたいと思います。
それまでのあいだは自前のバッチで、spamと思わしき共通項(IPから逆引きできないとか)を検知したらaccess.dbに追加するなどの対応も考えてみたいと思います。
K-To 様
> >>3 によると "Access denied" となっているので、たぶん to= の行はないと思います。
maillogを走査してみました。
<pre>
sudo grep "Access denied" /var/log/maillog | awk '{print $6}' | sudo ruby -e "cnt=0; while qid=STDIN.gets; unless qid.include?('ruleset'); cnt+=1; system(\"grep #{qid.chomp.chomp(':')} /var/log/maillog | grep 'to=<'\"); end; end; p cnt"
1544
</pre>
Access deniedを含むレコードは1544件ありましたが、おっしゃるとおりto=を含むものは1件もありませんでした。
あれからキューIDでひっかけてfrom=を含むログを調べて、IPだけでなく、メールアカウントもREJECTかけるようにして、(対症療法ですが)ずいぶん静かになりました。
spam業者もリレー失敗を検知すると大量送信をやめる、ような印象です。
今はまだ知識が全然足りないので、しばらく勉強してから乗り換えなり、外部メールサービスを検討するなりしてみようと思います。
たっつぁん様
ありがとうございます。もう少し勉強してから、はたしてsendmailからpostfixへ乗り換えることで改善するのか（設定の容易さによってspam対策できるレベルまで自身の理解が及ぶのか）、そもそも自前のメールサーバの構築がまだ早計なのか、あらためて考えてみたいと思います。
それまでのあいだは自前のバッチで、spamと思わしき共通項(IPから逆引きできないとか)を検知したらaccess.dbに追加するなどの対応も考えてみたいと思います。
- mixiユーザー
- ログインしてコメントしよう！
|
|
|
|
メールサーバー 更新情報
-
最新のイベント
-
まだ何もありません
-
-
最新のアンケート
-
まだ何もありません
-
