LinuxサーバーのデフォルトのSSHポートを変更する必要がありますか？
SSHポートを変更することに何か利点はありますか、私は人々がそうするのを見てきましたが、その理由を見つけることができないようです。
強力なパスワードや証明書がある場合、それは何かに役立ちますか？
編集：
総当たり攻撃を制限するためにiptablesルールを使用していることにも言及する必要があります。IPアドレスごとに許可されるログイン試行は1分あたり5回のみです。
インターネットはワイルドで恐ろしい場所であり、好奇心から犯罪組織にいたるまでその動機はさまざまです。これらの非保存は、悪用しようとするサービスを実行しているコンピューターを常にスキャンしています。通常、SSH、HTTP、FTPなどのより一般的なサービス。スキャンは通常、次の2つのカテゴリのいずれかに分類されます。
- Reconスキャンは、これらのサービスが開いているIPアドレスを確認します。
- エクスプロイトは、特定のサービスを実行していることが判明したIPアドレスに対してスキャンします。
インターネットの大きさを考えると、すべてのIPアドレスのすべてのポートを調べて、どこでもリッスンしているものを見つけることは通常不可能です。これは、デフォルトのポートを変更するためのアドバイスの要です。これらの不満のある個人がSSHサーバーを見つけたい場合は、ポート22で各IPアドレスの調査を開始します（222や2222などの一般的な代替を追加することもあります）。次に、ポート22を開いた状態でIPアドレスのリストを取得すると、パスワード総当たり攻撃を開始してユーザー名/パスワードを推測するか、選択したエクスプロイトキットを起動して、ターゲットシステムで既知の（少なくとも彼らにとって）脆弱性のテストを開始します。
つまり、SSHポートを34887に変更すると、そのスイープが通り過ぎ、フォローアップの侵入のターゲットにならなくなる可能性があります。
バラ色そうですね？ただし、欠点もあります。
- クライアントサポート：サーバーに接続するすべての人が、変更されたポートを認識して使用する必要があります。厳重に管理された環境にいる場合、この構成はクライアントにプッシュダウンできます。または、十分な数のユーザーがいない場合は、簡単に通信できます。
- ドキュメントの例外：ファイアウォールやIDSなどのほとんどのネットワークデバイスは、共通ポートで実行される共通サービス用に事前設定されています。このデバイスのこのサービスに関連するファイアウォールルールは、検査し、場合によっては変更する必要があります。同様に、IDS署名はポート22でのみSSHインスペクションを実行するように調整されます。すべての署名は、更新されるたびに、新しいポートで変更する必要があります。 （データポイントとして、現在、SSHに関連する136のVRTおよびET snortシグネチャがあります）。
- システム保護：最近のLinuxは、多くの場合、カーネルレイヤーMACおよび/またはRBACシステム（RedHatベースのSELinuxまたはDebianベースのAppAmorなど）を搭載して出荷され、アプリケーションが意図したとおりの動作を実行できるように設計されています。その範囲は、
/etc/hostsファイルへのアクセスから、特定のファイルへの書き込み、ネットワーク上でのパケットの送信までさまざまです。このシステムの構成方法によっては、デフォルトで、sshdが非標準ポートにバインドすることを禁止する場合があります。それを許可するローカルポリシーを維持する必要があります。 - 第三者による監視：外部の情報セキュリティ部門がある場合、または監視を外部委託している場合は、変更を認識してもらう必要があります。セキュリティ評価を実行するとき、またはセキュリティの脅威を探すログを分析するときに、標準以外のポートで実行されているSSHサーバー（またはUNIX/Linux以外のSSHサーバー）が表示された場合、それを潜在的なバックドアとして扱いますインシデント処理手順の侵害されたシステム部分を呼び出します。管理者に電話をかけて正当なものであると言われた後、5分で解決することもありますが、その時点でドキュメントを更新します。いずれにしても、電話に応答して「こんにちは、情報セキュリティオフィスのボブです。私にいくつか質問があります。 」
ポートを変更する前に、これらすべてを考慮に入れて、最善の決定をしていることを確認する必要があります。これらの欠点のいくつかは当てはまらないかもしれませんが、確かに当てはまるものもあります。また、あなたが身を守ろうとしていることも考慮してください。多くの場合、インターネット全体ではなく、特定のホストからの22へのアクセスのみを許可するようにファイアウォールを設定する方が簡単です。
はい、可能です。セキュリティを強化することではありませんが、サーバーでの失敗したログイン試行の量を減らすことができます。私は常にデフォルトのsshを変更して、ossecから受け取る警告を減らしています。また、本当にランダムなポートを使用していて、誰かがまだマシンにアクセスしようとしている場合、ランダムスキャナーではなく、標的型攻撃である可能性が高くなります。
他の人が言ったように、22以外のポートにSSHを配置すると、ランダムスキャンでヒットする可能性が低くなります。攻撃者が任意のサーバーではなくyourサーバーを取得しようとしている場合は、標的になります。
sshがランダムなハイポートにバインドされているサーバーがあります。そして、私はポート22にsshハニーポットを持っています。これは、あらゆるログイン試行に「アクセス拒否」メッセージで応答します。
obdefcurityによる防御ではないと思いますが、-多層防御：サーバーを攻撃するには、攻撃者はまずポートを見つける必要があります。いくつかの偽のハニーポット（同じハニーポットにリダイレクトする多数のポート）がある場合、攻撃者は多くの偽物を攻撃し、それが実際のsshを攻撃したかどうかを知る方法がありません。
ただし、これは防御にすぎません。私もportsentryをアクティブにしているので、誰かがポートスキャンを試みた場合、それらは1時間ブロックされます。正しいSSHでパスワードをブルートフォースにすると、「アクセス拒否」が1時間届きます。ユーザーがパスワードの推測に成功すると、Google認証トークンを要求するPAMプロンプトが表示されます。
ポートを変更するコストは非常に低く、マイナス面はプラス面によって正当化されると思います。
ほとんどの人が主に不利な点（これは本当のことです）について話しているので、ここでいくつかの利点を共有したいと思います。
あなたは本当に自動化された攻撃を避けたいです。あなたが知名度の高いユーザーでない限り、攻撃の大部分はあなたを標的にせず、デフォルトのポートを試すだけの自動ベストエフォート攻撃です。それらを回避すると、いくつかの点で役立ちます。
- 攻撃対象を減らします（ほとんどの自動化された攻撃）
- 使用するsshdまたは暗号化ライブラリのバグによる露出を減らす
- heartbleed のようないくつかのバグにより、パスワードやキーを知らなくても、開いているポートに接続するだけでサーバーを悪用することができます。非標準のポートを使用することで、これを回避できます。
- weak private keys のようないくつかのバグにより、パッチを適用する前にサーバーを自動攻撃することができます。非標準ポートを再び使用すると、攻撃者の最初の波を回避し、パッチを適用するためのより多くの時間を提供します。
- ログの乱雑さを軽減し、ログを確認する際の管理時間を大幅に節約し、より問題の多い標的型攻撃に集中することができます
- アップデートで言及したkludgeよりも少ない作業でより優れた保護を提供します（5回の不正なログイン後にIPをブロックします-特にIPが変化し続ける場合、一部の攻撃を許可します;特に、各攻撃者が何十億もの余裕を持つIPv6の世界では;そして、kludgeは、正当なユーザーを締め出し、より多くのサポートコールを生成する誤検知を生成する可能性があります）
- 場合によっては、適切なパスワードでさえも（他の場所にある他のいくつかのバグ、あるいは不注意なユーザーがキーログに記録されたマシンに入力して）侵害され、後で攻撃に使用される辞書に保存されます。繰り返しになりますが、ランダムなポートにより、このクラスの自動化された攻撃の大部分が回避されます（ほとんどのキーロガーは、ユーザー名とパスワードのペアのみを保存し、構成でポートを探しません）。
攻撃者が予期しないものは何でも、常に完全に彼をオフにするか、彼のためにより多くの仕事を作成するか、またはあなたをあまり興味のないターゲットにします。また、攻撃を検出して防御する時間も長くなります。
1024を超えるポートで実行する場合、sshdをrootとして実行する必要はありません。これにより、必要なユーザーは1人だけになり、1つのクラスのバグ全体を回避できます（一部のsshd実装が低い特権で実行するように細心の注意を払っている場合でもtrue不要な場合）。
私はそれがあなたがあなたのサーバーにパッチを当てることにどのくらいの速度で行くか、そしてあなたがサーバーの前に何らかの種類のファイアウォールを持っているかどうかに依存すると思います。
サーバーを世界中に公開したままにしておき、アラートやOpenSSHパッチの自動インストールを行う設定がない場合は、サーバーをランダムに大きい番号のポートに移動することをお勧めします。
結局のところ、ポート番号を移動するだけでは全員を抑止できますが、ポート80、22、23などをチェックしているだけのスクリプトキディを抑止できます。
ポートを変更しても、SSHおよび一部のスクリプトキディに対する自動攻撃のみが停止します。誰かがあなたをターゲットにしていた場合、彼らは新しいSSHポートに罰金を科すことができます。利点は、失敗したログイン試行がログで停止することです。 sshd_configでPasswordAuthenticationをnoに設定して実行している別のポートで、通常LogwatchやSSHなどを使用しています。
他の人がすでに述べたように、デフォルトのSSHポートを変更しても、セキュリティの観点からはあまりメリットはありません。ただし、管理者がポート22をロックダウンしているネットワークからマシンに接続する場合は、そうすることは依然として有利です。（多くの学校、職場、無料のWiFiホットスポットは、デフォルト以外のすべての送信トラフィックをブロックしますDNS、HTTP、およびHTTPSポート。）この場合、SSHポートを53、80、または443に変更する（またはルーターにこれらのポートの1つを22に転送させる）と、通常、勉強/作業/旅行。
まれに、これらのネットワークが単にポートをブロックしているだけでなく、トラフィックを検査してssh接続を除外している場合もあります。この状況では 他の選択肢を調査する が必要です。
これは哲学的な質問のようなものです：「コントロールXは役に立ちますか？」また、ベストアンサーが指摘しているように、「コントロールXのコスト（クライアントサポート、ドキュメントの免除、システムサポート、監視サポート、直接コスト、ライセンスコストなどを投入します）についても考慮してください。
特定の状況では何でも役立ちます。どのコンテキストにいるかを自問することをお勧めします。コンテキストはコンプライアンスの1つである場合があります-特定の要件を満たすためにコントロールXを展開しています。 「システムポリシーでポート22のリスナーが禁止されているため、sshポートを移動する必要があります。」次に、それを実行するか、例外を申請するか、ポリシーを変更するために作業します。 [それは、私見では、賢明な政策ではないでしょう。]
ここでのコンテキストは、おそらく「私はランダムな男で、ホストが制御されていないネットワーク上にあり、自分のボックスの制御を失いたくない」です。攻撃には常に調査フェーズがあります。調査が「ポート22にSYNを送信し、誰が応答するかを確認する」場合、その特定の脅威ベクトルから保護しています。 （調査が「ポートスイープを実行し、バナーを収集し、興味深いものが表示されるかどうかを確認する」である場合、あなたのコントロールは効果がありません。）しかし、今、あなたはあなた自身のために多くの作業をしました-ツールを使用している場合サーバーに接続するには、その非標準ポートでの作業方法を理解する必要があります-いくつかのツールでは、それさえ不可能かもしれません。全体として、この文脈では、ポートを変更することはお勧めしません。
注目された利点の1つは、誤検知に関連するログイベントの減少でした。私は実際にそれがネガティブであることを発見しました！ポート22でのインバウンド攻撃の着実な流れは実際に役立ちます。攻撃が停止した場合、インターネットフィードに問題があることを知っています。認識されているメリットは間違っていると思います。正しい答えは、異常検出システムを調整して、外部ネットワークからの失敗したログイン試行を除外することです。