/ var / log / secureの「侵入の可能性!」—これはどういう意味ですか?


96

VPSプラットフォームでCentOS 5.xボックスを実行しています。私のVPSホストは、接続に関するサポートの問い合わせを誤って解釈し、いくつかのiptablesルールを効果的にフラッシュしました。これにより、sshは標準ポートでリッスンし、ポート接続テストを承認しました。うるさい。

幸いなことに、SSH認証キーが必要です。私が知る限り、侵害が成功したとは思いません。ただし、/ var / log / secureに表示される内容については非常に心配しています。


Apr 10 06:39:27 echo sshd[22297]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:27 echo sshd[22298]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:31 echo sshd[22324]: Invalid user edu1 from 222.237.78.139
Apr 10 06:39:31 echo sshd[22324]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:31 echo sshd[22330]: input_userauth_request: invalid user edu1
Apr 10 13:39:31 echo sshd[22330]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:35 echo sshd[22336]: Invalid user test1 from 222.237.78.139
Apr 10 06:39:35 echo sshd[22336]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:35 echo sshd[22338]: input_userauth_request: invalid user test1
Apr 10 13:39:35 echo sshd[22338]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:39 echo sshd[22377]: Invalid user test from 222.237.78.139
Apr 10 06:39:39 echo sshd[22377]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:39 echo sshd[22378]: input_userauth_request: invalid user test
Apr 10 13:39:39 echo sshd[22378]: Received disconnect from 222.237.78.139: 11: Bye Bye

「侵入の可能性」とはどういう意味ですか?成功したことは?または、リクエストの送信元のIPが気に入らないということですか?

回答:


78

残念ながら、これは現在非常に一般的なことです。これはSSHに対する自動化された攻撃であり、「一般的な」ユーザー名を使用してシステムに侵入しようとします。メッセージは、まさにそれが言っていることを意味します、それはあなたがハッキングされたことを意味するのではなく、誰かが試みたことだけです。


ありがとう、レイン。気分が良くなります。sshに認証キーが必要なのは本当にうれしいです。=)
マイクB

28
「getaddrinfoの逆マッピングチェック」は、作成されたソースIP /ホスト名についての詳細です。同じ巧妙に細工されたトラフィックが悪いユーザー名を試みていますが、悪いユーザー名は「POSSIBLE BREAK-IN ATTEMPT」メッセージを生成しません。
ポイズンビット

11
@MikeyB:システムにfail2banを追加することを検討してください。これは、これらの攻撃者のIPアドレスを自動的にブロックするように構成できます。
user9517

9
「逆マッピングが失敗した」ということは、単にユーザーのISPが逆DNSを正しく構成していないことを意味することに注意してください。これは非常に一般的です。@Gaiaの回答を参照してください。
ウィルフレッドヒューズ

1
これは不正確です。逆DNSが、クライアントが自分自身を識別するために送信したホスト名と一致しないことを意味します。フラグを立てるのは、それを使用している人.rhosts.shosts認証している人の試みが中断された可能性があるためです(使用されたことは見たことがありません)。(スキャンの場合、失敗した認証/未知のユーザメッセージを探すために優れている)スキャンが起こるが、それは(任意の接続は、それをトリガすることができますが)このメッセージが何であるかではありません
ゲルトファンデンベルグ

52

具体的には、「侵入可能試行」の部分は、「getaddrinfoが失敗したことを確認する逆マッピング」の部分に関連しています。これは、接続していた人が正引きDNSと逆引きDNSを正しく構成していないことを意味します。これは、特にISP接続の場合に非常に一般的です。ISP接続では、おそらく「攻撃」が発生していました。

「POSSIBLE BREAK-IN ATTEMPT」メッセージとは無関係に、その人は実際に一般的なユーザー名とパスワードを使用して侵入しようとしています。SSHに単純なパスワードを使用しないでください。実際、パスワードを完全に無効にし、SSHキーのみを使用することをお勧めします。


1
ISP経由の(有効な)接続によって生成された場合、/ etc / hostsファイルにエントリを追加して、この逆マッピングエラーを取り除くことができます。エラーが無害であり、ログをクリーンアップする必要があることがわかっている場合にのみ、これを行うことは明らかです。
artfulrobot

32

「「可能性のある侵入」とはどういう意味ですか?」

これは、ネットブロックの所有者が範囲内の静的IPのPTRレコードを更新せず、PTRレコードが古い、または ISPが動的IPの顧客に適切な逆引きレコードを設定しないことを意味します。これは、大規模なISPでも非常に一般的です。

不適切なPTRレコード(上記の理由のいずれか)のあるIPから来た誰かがサーバーにSSHを試みるために一般的なユーザー名を使用しようとしているため、ログにメッセージが表示されます(ブルートフォース攻撃、またはおそらく正直な間違い) )。

これらのアラートを無効にするには、2つの選択肢があります。

1)静的IPがある場合は、逆マッピングを/ etc / hostsファイルに追加します(詳細はこちらを参照してください)。

10.10.10.10 server.remotehost.com

2)動的IPがあり、それらのアラートを本当に消したい場合は、/ etc / ssh / sshd_configファイルの「GSSAPIAuthentication yes」をコメントアウトします。


2
コメントGSSAPIAuthentication私の場合には役立ちません(
SET

UseDNS noおそらくそれを取り除くためのより良い設定です(そして、サーバーにDNSの問題がある場合の遅いログイン...)
Gert van den Berg

15

sshd_config(UseDNS no)で逆引きをオフにすることで、ログを読みやすくしたり確認したりすることができます。これにより、sshdが「ノイズ」行に「可能性のある侵入」を含むログを記録することを防ぎ、「IPADDRESSからの無効なユーザーUSER」を含む少し興味深い行に集中することができます。


4
パブリックインターネットに接続されたサーバーでsshdの逆ルックアップを無効にすることのマイナス面は何ですか?このオプションを有効にしたままにしておくと、利点はありますか?
エディ

2
@Eddie sshdによって実行されるDNSルックアップが有用な目的を果たすとは思わない。DNSルックアップを無効にする理由は2つあります。DNSルックアップは、ルックアップがタイムアウトした場合、ログインを遅くする可能性があります。また、ログ内の「侵入の可能性」メッセージは誤解を招く恐れがあります。そのメッセージは、クライアントがDNSを誤って設定したことを意味しています。
カスペルド

1
@OlafMに同意しません-「UseDNS no」はsshdにリバースマッピングチェックを実行しないように指示するため、システムログに「POSSIBLE BREAK-IN ATTEMPT」を含む行を追加しません。副作用として、逆DNSが正しく構成されていない場合よりも、ホストからの接続試行を高速化する可能性があります。
-TimT

1
はい、@ OlafMは4〜5年前にLinuxで実行しました。それは私のログをかなり短縮し、logcheck価値のないメールレポートで私を悩ませることを止めました。
TimT

1
の主な用途はUseDNS(使用するのは悪い考えです).rhostsおよび.shosts認証(HostbasedAuthentication)です。(FromSSHD configおよびauthorized_keys の一致オプション)(HostbasedUsesNameFromPacketOnlyHostsベースの認証の逆ルックアップの切り替えにも必要な場合がありますが、Hostsbasedauthenticationを使用するよりも悪い考えです...)
Gert van den Berg

5

ログインに成功する必要はありませんが、「可能」および「試行」と言うものです。

悪意のある少年または脚本家の子供が、偽造IPを使用して細工したトラフィックを送信しています。

元のIPの制限をSSHキーに追加して、fail2banなどを試すことができます。


2
ありがとう。一部のソースからのSSH接続のみを許可するようにiptablesを設定しています。また、fail2banをインストールして実行しています。
マイクB
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.