次のコマンドでサーバーの認証ログを確認する場合:
grep sshd.\*Failed /var/log/auth.log | less
次のような数千行が表示されます。
Jan 12 11:27:10 ubuntu-leno1 sshd[8423]: Failed password for invalid user admins from 172.25.1.1 port 44216 ssh2
Jan 12 11:27:13 ubuntu-leno1 sshd[8425]: Failed password for invalid user phoenix from 172.25.1.1 port 20532 ssh2
Jan 12 11:27:17 ubuntu-leno1 sshd[8428]: Failed password for invalid user piglet from 172.25.1.1 port 24492 ssh2
Jan 12 11:27:22 ubuntu-leno1 sshd[8430]: Failed password for invalid user Rainbow from 172.25.1.1 port 46591 ssh2
Jan 12 11:27:25 ubuntu-leno1 sshd[8432]: Failed password for invalid user runner from 172.25.1.1 port 57129 ssh2
Jan 12 11:27:34 ubuntu-leno1 sshd[8434]: Failed password for invalid user sam from 172.25.1.1 port 11960 ssh2
Jan 12 11:27:37 ubuntu-leno1 sshd[8437]: Failed password for invalid user abc123 from 172.25.1.1 port 5921 ssh2
Jan 12 11:27:40 ubuntu-leno1 sshd[8439]: Failed password for invalid user passwd from 172.25.1.1 port 21208 ssh2
Jan 12 11:27:43 ubuntu-leno1 sshd[8441]: Failed password for invalid user newpass from 172.25.1.1 port 65416 ssh2
Jan 12 11:27:46 ubuntu-leno1 sshd[8445]: Failed password for invalid user newpass from 172.25.1.1 port 26332 ssh2
Jan 12 11:27:49 ubuntu-leno1 sshd[8447]: Failed password for invalid user notused from 172.25.1.1 port 51126 ssh2
Jan 12 11:27:52 ubuntu-leno1 sshd[8449]: Failed password for invalid user Hockey from 172.25.1.1 port 14949 ssh2
Jan 12 11:27:56 ubuntu-leno1 sshd[8451]: Failed password for invalid user internet from 172.25.1.1 port 35105 ssh2
Jan 12 11:27:59 ubuntu-leno1 sshd[8453]: Failed password for invalid user asshole from 172.25.1.1 port 7916 ssh2
Jan 12 11:28:02 ubuntu-leno1 sshd[8456]: Failed password for invalid user Maddock from 172.25.1.1 port 26431 ssh2
Jan 12 11:28:05 ubuntu-leno1 sshd[8458]: Failed password for invalid user Maddock from 172.25.1.1 port 53406 ssh2
Jan 12 11:28:09 ubuntu-leno1 sshd[8460]: Failed password for invalid user computer from 172.25.1.1 port 23350 ssh2
Jan 12 11:28:15 ubuntu-leno1 sshd[8462]: Failed password for invalid user Mickey from 172.25.1.1 port 37232 ssh2
Jan 12 11:28:19 ubuntu-leno1 sshd[8465]: Failed password for invalid user qwerty from 172.25.1.1 port 16474 ssh2
Jan 12 11:28:22 ubuntu-leno1 sshd[8467]: Failed password for invalid user fiction from 172.25.1.1 port 29600 ssh2
Jan 12 11:28:26 ubuntu-leno1 sshd[8469]: Failed password for invalid user orange from 172.25.1.1 port 44845 ssh2
Jan 12 11:28:30 ubuntu-leno1 sshd[8471]: Failed password for invalid user tigger from 172.25.1.1 port 12038 ssh2
Jan 12 11:28:33 ubuntu-leno1 sshd[8474]: Failed password for invalid user wheeling from 172.25.1.1 port 49099 ssh2
Jan 12 11:28:36 ubuntu-leno1 sshd[8476]: Failed password for invalid user mustang from 172.25.1.1 port 29364 ssh2
Jan 12 11:28:39 ubuntu-leno1 sshd[8478]: Failed password for invalid user admin from 172.25.1.1 port 23734 ssh2
Jan 12 11:28:42 ubuntu-leno1 sshd[8480]: Failed password for invalid user jennifer from 172.25.1.1 port 15409 ssh2
Jan 12 11:28:46 ubuntu-leno1 sshd[8483]: Failed password for invalid user admin from 172.25.1.1 port 40680 ssh2
Jan 12 11:28:48 ubuntu-leno1 sshd[8485]: Failed password for invalid user money from 172.25.1.1 port 27060 ssh2
Jan 12 11:28:52 ubuntu-leno1 sshd[8487]: Failed password for invalid user Justin from 172.25.1.1 port 17696 ssh2
Jan 12 11:28:55 ubuntu-leno1 sshd[8489]: Failed password for invalid user admin from 172.25.1.1 port 50546 ssh2
Jan 12 11:28:58 ubuntu-leno1 sshd[8491]: Failed password for root from 172.25.1.1 port 43559 ssh2
Jan 12 11:29:01 ubuntu-leno1 sshd[8494]: Failed password for invalid user admin from 172.25.1.1 port 11206 ssh2
Jan 12 11:29:04 ubuntu-leno1 sshd[8496]: Failed password for invalid user chris from 172.25.1.1 port 63459 ssh2
Jan 12 11:29:08 ubuntu-leno1 sshd[8498]: Failed password for invalid user david from 172.25.1.1 port 52512 ssh2
Jan 12 11:29:11 ubuntu-leno1 sshd[8500]: Failed password for invalid user foobar from 172.25.1.1 port 35772 ssh2
Jan 12 11:29:14 ubuntu-leno1 sshd[8502]: Failed password for invalid user buster from 172.25.1.1 port 18745 ssh2
Jan 12 11:29:17 ubuntu-leno1 sshd[8505]: Failed password for invalid user harley from 172.25.1.1 port 38893 ssh2
Jan 12 11:29:20 ubuntu-leno1 sshd[8507]: Failed password for invalid user jordan from 172.25.1.1 port 64367 ssh2
Jan 12 11:29:24 ubuntu-leno1 sshd[8509]: Failed password for invalid user stupid from 172.25.1.1 port 27740 ssh2
Jan 12 11:29:27 ubuntu-leno1 sshd[8511]: Failed password for invalid user Apple from 172.25.1.1 port 22873 ssh2
Jan 12 11:29:30 ubuntu-leno1 sshd[8514]: Failed password for invalid user fred from 172.25.1.1 port 54420 ssh2
Jan 12 11:29:33 ubuntu-leno1 sshd[8516]: Failed password for invalid user admin from 172.25.1.1 port 58507 ssh2
Jan 12 11:29:42 ubuntu-leno1 sshd[8518]: Failed password for invalid user summer from 172.25.1.1 port 48271 ssh2
Jan 12 11:29:45 ubuntu-leno1 sshd[8520]: Failed password for invalid user sunshine from 172.25.1.1 port 5645 ssh2
Jan 12 11:29:53 ubuntu-leno1 sshd[8523]: Failed password for invalid user andrew from 172.25.1.1 port 44522 ssh2
Sshのブルートフォース攻撃を受けているようです。これはよくあることですか?私は今どうすればいい?攻撃が成功したと考えて対策を講じる必要がありますか?
-----編集-------
攻撃が内部IPアドレスからのものであるという事実は、このサーバーが外部からsshリダイレクションを持っていることによって説明されます。これは、ポートを開いた直後に非常に迅速に発生しました。背後にある既存のサーバーを探して、すべてのパブリックIPがスキャンされていますか?
多くの人が言及しているように、fail2ban
に関するクイックノートを追加しました。フロントエンドは企業のファイアウォールであり、バックエンドはファイアウォールからのリダイレクト/プロキシ/内部アドレスのみを認識します。
したがって、172.25.1.1は、内部マシンが危険にさらされているわけではありません(そして、回答のコメントと、ここでの内部マシンであることを示す他の回答の両方が間違っているコメントする場合)。これは、ファイアウォールの内部IPアドレスの1つです。
バックエンドのFail2banは、172.25.1.1からの失敗した試行のみを確認するため、一度にストレッチにSSHを使用する可能性をすべてブロックするだけです。だから、私の答えを読んでください。
疑いの余地はありません。他の投稿が言及しているように、あなたがブルートフォース攻撃を受けていることは痛々しいほど明白です。
しかし、それはあなたが私たちが示したログから何らかの方法で侵害されたことを決して意味しません。悲しいかな、最近のssh総当たり攻撃はすべてですあまりにも一般的です。ほとんどの場合、これらは本当に自動化されており、必ずしもターゲットにされているわけではありません。
逸話的な警告話として、数年前にISPプロバイダーで新しいサーバーをセットアップした初日、インターネットに公開されているsshが1晩で200k以上のsshスキャンプローブを取得しました。
「内部IPアドレス」については、SNATまたは22/TCPプロキシリダイレクトを使用していて、ソースインターネットIPが表示されない(これはベストプラクティスではありません)か、最悪の場合、ルーター/ケーブルモデムが妥協。
実際にSNAT /プロキシSSH構成を使用している場合は、それを検討することをお勧めします。ネットワークではなく、実際のIPアドレスのログが必要です。
対策として、私はいくつかをお勧めします:
SSHインターネットを引き続き外部に開放することを強く主張する場合は、デフォルトのSSHポートを変更するとセキュリティの偽の感覚しか得られず、一時的にIPアドレスをブロックすると攻撃の速度が低下することに注意してください。ゾンビマシン。
接続しているパブリックIPアドレスを直接受け取るように構成を変更する場合は、fail2ban
を確認してください。ただし、実際にゲートウェイのIPアドレスを持つ外部IPが到着した場合、それを使用してすべての外部SSHアクセスを事実上ロックアウトしていることを考慮してください。
他の警告もあります。今日のゾンビ/マルウェアはfail2ban
を考慮に入れており、デフォルトのタイムアウト期間が経過した後に戻るか、別のIPアドレスを使用することに注意してください。 (私はそれが発生するのを見てきました。)必須のRSA証明書認証を使用しても、パスワード攻撃は引き続きログに記録され、I/O、ディスク容量、およびCPUサイクルを焼きます。
VPNについては、専用のハードウェアは必要ありません。 LinuxまたはFreeBSDサーバーでVPNを構成するのは簡単です。
最初から設定することに不安がある場合は、VM with pfSense。 for FreeBSD; strongSwan for setup LinuxサーバーのVPN。
フロントエンドサーバーがLinuxの場合、別の方法としてポートノッキングがあります。ただし、その固有の動作のため、国内の設定でのみお勧めします。正しく @ GroundZeroによって指摘されています 「ポートノッキングは無名によるセキュリティであり、攻撃者はネットワークトラフィックをアクティブに監視して、ノッキングシーケンスを発見できます。」
buntuの攻撃者からSSHデーモンを隠すためにポートノッキングを使用する方法
追加の手段として、ポート22でファイアウォール/ iptablesルールSYNを使用してレート制限することもできます。このようにして、正当な接続をレート制限せず、Linuxのiptablesまたはほとんどの商用ファイアウォールがその構成を許可します。セキュリティルールが始まる前に、ボットがいくつかのデーモンをできるだけ早く攻撃するという厄介なトリックを見てきました。ただし、実際にはsshにはそれに対する防御機能が組み込まれていると思います。
横行スキャンについてお答えしますが、確かにそうです。悪質なアクター、ゾンビネットワーク、マルウェアが多数あり、IPアドレススペースを常にスキャンして、sshdの脆弱なバージョン、脆弱な/古いsshdバージョンのサーバー、デフォルト/不正なパスワード/既知のバックドアを持つサーバー、単純にopensshを持つサーバーを見つけます。ブルートフォースまたはフィッシングを介した二面攻撃による非特権ユーザーの足場。
現在の作業の要塞ホストで(個別のイベントで)フィッシングを介した3つの攻撃に成功した後、すべてのユーザーにsshd_config
でRSA証明書を要求し、内部ネットワークのみを要求するというデュアルSSH構成を行うことにしましたパスワード認証を許可し、構成ファイルの最後にそのように追加します。
# sshd configuration allowing only RSA certificates
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/24
PasswordAuthentication yes
別の逸話的な恐ろしい話として、必須のRSA証明書に変更する前に、フィッシングの妥協案の1つが正確な週に行われ、ルートへの特権昇格を可能にする脆弱性に対する2つのカーネルアップデートがあり、その場で更新していなかったら、ルートが侵害されました。 (そして、私の記憶が私を失敗させないなら、それは7月4日頃でした...ハッカーは休暇中にこれらの厄介な攻撃を保存するのが大好きです)
実際のリアルタイムの攻撃のグラフについては、以下をご覧ください。
答えを完成させるために:
いいえ、あなたはおそらく何らかの形で危険にさらされていません。
はい、セキュリティレベルを上げるための対策を講じる必要があります。外部から企業のVPNサーバーにVPNトンネル/クライアントを勧めます。実際にやっていることです。
最後に重要なアドバイスがあります。通常のアカウントが侵害されていないことを確認するには、/var/log/auth.log
認証ログで認証が成功しているかどうかを確認してください。 anyアカウントでopensshにログインして、/var/log/wtmp
に登録せずにlast
に表示しない方法があります。コマンド。
言うまでもなく、更新のない古いマシンで通常のアカウントが侵害された場合、すべての賭けは無効になります。そして、ルートへの特権昇格という残念なケースでは、ログでさえも危険にさらされる可能性があります。
はい、ブルートフォース攻撃を受けているようです。攻撃者はクラスBプライベートアドレスを使用しているため、攻撃を行っているのは組織のネットワークにアクセスできる誰かである可能性があります。ユーザー名から、一般的なユーザー名の辞書を介して実行されているように見えます。
いくつかを軽減するための対策を講じる方法については、 'SSHブルートフォースを停止/防止する方法'(Serverfault) および 'ブルートフォースSSH攻撃の防止'(Rimu Hosting) を参照してください。 SSHブルートフォース攻撃に関連するリスクの。
はい、これはブルートフォース攻撃のように見え、グーグルした後admins phoenix piglet Rainbow
攻撃者が使用している単語リストのようです: https://github.com/hydrogen18/kojoney/blob/master/fake_users
116行目以降を確認してください。単語リストはまったく同じ順序で使用されています。
これは他のサイトにも存在するため、一般的な単語リストのようです。例えば http://src.gnu-darwin.org/ports/net/kojoney/work/kojoney/fake_users
@TheJulyPlotは、この攻撃を緩和するために何をすべきかについての良い情報を提供しています。
はい、あなたはブルートフォースされています。しかし、インターネットから来るブルートフォースを気にする必要はないと思います。ただし、自分のネットワークからの総当たり攻撃を心配する必要があります。
ブルートフォースされることは非常に一般的であり、SSHにパスワードを使用しない(または適切なパスワードを使用する)場合の場合、攻撃はまったく成功しません(特に3〜4秒ごとに1回の推測で)。 )。
ただし、IP(172.25.1.1)はあなたと同じネットワーク上にあります。 これが本当の問題です、そしてこのマシンが危険にさらされているかどうかを確認する必要がありますできるだけ早く。
あなたは外見から攻撃を生き延びています。 SSHは本来あるべきことを行っています。ただし、存続を確保するためにできるだけ早く実行する必要があるいくつかの手順については、以下を参照してください。
また、残念ながら、ネットワーク内のシステムが侵害されています。最近はあまりにも一般的です。この明らかに内部攻撃の性質を確認する必要がありますが、thisシステムがに基づいて単純に侵害されているとは想定しないでくださいこのログファイル。 Web向けのSSHDを実行している人なら誰でも、これを何年も前から何度も何度も見ています。このホスト上のSSHDインストールを修正してから、172.25.1.1でシステムを調査します。
以下のようなSSHDのベストプラクティスに従います...
鍵ベースの認証を優先してパスワード認証を無効にします:
# grep PasswordAuth sshd_config | grep no
PasswordAuthentication no
前述のように、rootログインを無効にします:
PermitRootLogin no
許可されたユーザーをsshd_configに追加します:
AllowUsers myusername the_other_sysop_guy
最後のものを実行すると、ログメッセージが「無効なユーザー」から「不正なユーザー」に変わります。
ビジネスの状況に応じて、SSHDポートのファイアウォール(承認されたIPアドレスからのSSHのみを許可)または別のポートを使用するように変更することを検討することもできます(これは実際には隠ぺいによるセキュリティですが、この性質のほとんどの攻撃は実際にスクリプト化されています)。 。悲しいかな、攻撃者がLAN内にいるように見えるという事実により、攻撃者が他の場合ほど多くの支援を提供できない可能性があります。
ちなみに、デバイスが1.1であるという事実は、ルーターに侵入したのかどうか疑問に思いますか? ;-)
ログに登録されている名前は使用されている標準の辞書からのものであるため、ログからの標準的な外観は一般的なブルートフォース攻撃のようです。一般的な単語リストでさえ、これらを主要なターゲットユーザー名と見なします。また、注入はプライベートクラスB IPから行われます。ただし、実施したパスワードが十分強力であり、これを管理するための負荷バランスが確保されている限り、心配する必要はありません。 SSHでこれを保護するための手段を探してください。SSHのブルートフォース保護手段。
サーバーへのすべてのSSHログインは同じローカルIPアドレスを介してリダイレクトされるため、fail2ban
を使用する場合は注意して使用することをお勧めします。 sshd
と同じサーバーにfail2ban
をインストールすると、IP 172.25.1.1がその場でブロックされます。その後、SSH経由でサーバーに誰もログインできなくなります。
SSHトラフィックをリダイレクトするサーバーにfail2ban
をインストールできる場合は、それを実行してください。私は自分のパブリックSSHサーバーでfail2ban
を使用しており、攻撃者を10分間で3回の試行に制限するという素晴らしい仕事をしています。スクリプトキディが使用しているほとんどの「クラッキング」スクリプトは、これらの3回の試行の後に単にタイムアウトし、何日も私を悩ませることはありません。
パスワードを推測する攻撃者をかなり簡単に遅くすることもできます。
ファイル/etc/pam.d/sshd
、次のような行を追加できます。
auth optional pam_faildelay.so delay=7000000
sshd
ログインに失敗するたびに、PAMモジュールは7秒間待機します。遅延を増やしたり減らしたりすることもできます。自分のパスワードを太い指で動かすと、7秒待って別のプロンプトが表示されるためです。ほとんどのSSHパスワード推測プログラムは非常に洗練されていないため、新しいプロンプトを待機するのにタイムアウトがありませんが、非常に長い遅延が原因で、より適切な推測プログラムがタイムアウトになる可能性があります。