このメッセージはsyslogをあふれさせます。それがどこから来たのかを知る方法は？

実行すると、dmesgこれは1秒ごとに表示されます。

[22661.447946] [UFW BLOCK] IN=eth0 OUT= MAC=ee:54:32:37:94:5f:f0:4b:3a:4f:80:30:08:00 SRC=35.162.106.154 DST=104.248.41.4 LEN=40 TOS=0x00 PREC=0x00 TTL=37 ID=52549 DF PROTO=TCP SPT=25 DPT=50616 WINDOW=0 RES=0x00 RST URGP=0

このメッセージの原因を追跡するにはどうすればよいですか？

networking

— ピーターレティエフ
ソース

迷惑なufwロギングです。オフにすることができます。別のログチャネルを使用するようにufwを構成することもできます。したがって、dmesgを汚染することはありませんが、非常に注意が必要です（少しのufwパッチも必要になる場合があります）。

— peterh -復活モニカ

FWIW UFWに慣れていない場合は、システムをインターネットに直接接続しないでください。

— MooseBoys

回答:

既存の答えは、ファイアウォールログエントリの技術的分析では正しいですが、結論を不正確にする1つのポイントが欠落しています。パケット

であるRST（リセット）パケット
から SRC=35.162.106.154
ホストに DST=104.248.41.4
経由で TCP
彼の港から SPT=25
あなたの港へ DPT=50616
BLOCKUFWによって編集されています。

ポート25（送信元ポート）は、一般的に電子メールに使用されます。ポート50616は一時ポート範囲にあります。つまり、このポートには一貫したユーザーがいません。TCPの「リセット」パケットは、接続が閉じられた後にデータが到着したり、最初に接続を確立せずにデータが送信されたりするなど、多くの予期しない状況に応じて送信できます。

35.162.106.154cxr.mx.a.cloudfilter.netCloudMark電子メールフィルタリングサービスで使用されるドメインに逆解決します。

あなたのコンピューター、またはあなたのコンピューターを装った誰かが、CloudMarkのサーバーの1つにデータを送信しています。データが予期せず到着し、サーバーがRST送信コンピューターに停止を要求するように応答しています。ファイアウォールがRST何らかのアプリケーションに通過するのではなくドロップすることを考えると、RST送信の原因となっているデータはコンピューターから送信されたものではありません。代わりに、サービス拒否攻撃からの後方散乱が見られます。攻撃者は、CloudMarkのメールサーバーをオフラインにするために偽造された「from」アドレスを持つパケットのフラッドを送信しています（スパムをより効果的にするため）。

— マーク
ソース

すばらしい分析のために+1！

— わから

メッセージはUFW、「単純化されていないファイアウォール」に由来し、誰かが

から SRC=35.162.106.154
ホストに接続しようとしました DST=104.248.41.4
経由で TCP
彼らの港から SPT=25
あなたの港へ DPT=50616
UFWがBLOCKその試みを成功させました。

このサイトによると、送信元アドレス35.162.106.154は一部のAmazonマシン（おそらくAWS）です。このサイトによると、ポート50616はXsan Filesystem Accessに使用できます。

したがって、IP = 35.162.106.154からファイルにアクセスしようとしています。ファイアウォールの目的はそのような試みを拒否するからです。

— PerlDuck
ソース

接続の試行はAmazonアカウントから行われたようです。ポート25はメールポートです。これを報告するか、単に無視する必要がありますか？ログの

— スパム-peterretief

@peterretiefは、ルーターでブロックできます。それからあなたはそれを見ないでしょう。ただし、ISPに報告するのが賢明かもしれません。

— リンツウィンド

実際には、「SYN」ではなく「RST」と表示されるため、除外された送信SMTP試行パケットは拒否されます。

— eckes

もう1つの答えは、私にとっては正しいと思われます。

— バーマー

@Barmar確かに、非常に親切に。それは受け入れられた答えであるべきです。

— PerlDuck