あいまいなポート番号を使用するとセキュリティが向上しますか？
私は最近、CTOがよく知られているポート22ではなく、サーバー上のあいまいで番号の大きいポートでSSHサービスをホストすることを好む小さな会社で仕事を始めました。これが悪い習慣と見なされているかどうか私は知りたいです。
直感的にこれは賢明なようです。しかし、私たちは両方とも大部分が独学であり、私は、十分に確立された慣例に従うよりも、独自のセキュリティ手順を即興化するという考えに不快です一般的な暗号化スキームとプロトコルは専門家のチームによって入念に設計されており、細部はどんなに軽微であっても、ある種の攻撃から保護することを目的としています。これらの推奨事項を逸脱した場合の意図しない結果について心配しています。
しかし、私の同僚は彼の側に証拠を持っているようです。彼は、ポート22を試して先に進む攻撃を毎日何十回も受けることを証明できました。 一般的にはあいまいなセキュリティを回避する必要があります ですが、この一般的なターゲットから離れることは、ほとんどの攻撃を阻止するように見えます 。
これは良い習慣ですか？よく知られたポートを使用する必要がありますか？
[〜＃〜]補遺[〜＃〜]
不明瞭なポートのみに依存することはありません。その他にも、次のような多くのセキュリティ対策を講じています。必須 ハードウェアキー 。質問をより明確に述べます。
特にポート22がSSHに選択された理由はありますか？他のポートを使用することに危険はありますか？
あいまいなポート番号を使用するとセキュリティが向上しますか？
すでに高エントロピーパスワードまたは公開鍵認証を使用している場合、答えは「実際には」ではありません。ほとんどの場合、ログのノイズを取り除くだけです。
これらの推奨事項を逸脱した場合の意図しない結果について心配しています。
選択したポートによって異なります。 Linuxでは、デフォルトで、1024未満のすべてのポートは、それらをリッスンするためにrootアクセスを必要とします。 1024を超えるポートを使用している場合、待機しているプロセスがなければ、すべてのユーザーアカウントがそのポートを待機できます。
なぜこれが問題なのですか？ sshをポート20,000にバインドするように設定したとします。誰かがサーバー上のSSHプロセスを停止でき（プロセスをクラッシュさせる方法を見つけたとしましょう）、そのサーバーへのローカルアクセスがあった場合、サービスの前にポート20,000で独自のSSHサーバーを実行できます再開した。ログインすると、悪意のあるSSHサーバーにログインすることになります。
最近ではサーバーへのログインアクセス権を付与されているのは信頼できるITスタッフのみであるため、これは以前ほど大したことではありません。ただし、攻撃者がサーバーに足を踏み入れると、特権の昇格やその他の卑劣な可能性があります。
1024未満であることを除けば、番号22について特別なことは何もありません。SSHがポート23のtelnetの代わりであり、21がFTPによってすでに使用されているため、主に22が選択されました。 1024以下のポートを選択する限り、ポートは重要ではありません。
これは良い習慣ですか？よく知られたポートを使用する必要がありますか？
私はそれをお勧めするとは言いません。私もそれに反対しません。先ほど述べたように、ログファイルでの多くのノイズを回避できますが、その利点は主にそれに限定されます。
SSHのバックグラウンドストーリーに興味のある方は、 https://www.ssh.com/ssh/port で見つけることができます。
はい、そうです。本当の質問は、次のとおりです。
なぜそうなのか？あなたはすでに基本的なセキュリティを持っているので、毎日のボット攻撃はあなたを心配しません。しかし、明日は0日になる可能性があり、攻撃者はパッチが出るまで長くはかからないので、それを使用するためにスクランブルをかけ、複雑なことに煩わされることはありません。できるだけ多くのマシンを攻撃するだけです。標準ポート。あらゆる種類の理論的なSSHワームもこの戦略を使用します。あなたはそれから守られるでしょう。
これによりどの程度のセキュリティが追加されますか？これは、おそらく2〜3の特定のシナリオから保護します。それは完全にばかではない人によるどんな標的攻撃にもせいぜい数分を追加します。すでに適切に保護されているシナリオには何もしません。
これらの数値をお気に入りのリスク分析方法に組み込むと、比較的小さなものを思い付くはずです。欠点としては、非標準のポート番号を設定したり、文書化したり、トラブルシューティング中に欠落したり、時間を浪費したりするなどの追加の労力があります。
私の推測では、分析を行っても壊れるだけだと思います。または、言い換えると、はい、セキュリティは向上しますが、改善が非常に小さいので、問題はありません。
いいえ、セキュリティは向上しません。自動化された攻撃は、たとえば、 ssh。ただし、ポートは引き続きポートスキャンでSSHとして表示され、 shodan.io となります。
これらの自動化された攻撃は、通常、root、smithなどの標準的なユーザー名と弱いパスワードを使用して、ぶら下がっている果物を狙っています。彼らが成功した場合、そもそも問題があります。
鍵認証のみを許可し、rootログインを禁止し、適切なパスワードを使用するようにsshを構成し、fail2banまたは同様のメカニズムを使用して違反者をブロックする場合、それらは実際の脅威ではありません。
私はfail3banを使用して、3回の試行が失敗した後5分間、および3 * 5回の試行が失敗した後の1週間を一時的にブロックします。これにより、ログが乱雑になり、ブルートフォース攻撃の実際の進行がブロックされます。
標的型攻撃者にとっては、どのポートがリッスンしているかに違いはありません。私の意見では、無視できるリスクである自動化された攻撃についてのみ重要です。
デフォルトポートを変更すると、ポートスキャンやスクリプトキディから解放されますが、攻撃者がポートに関係なく実行中のサービスを特定できる標的型攻撃に耐えられない可能性があります。
スクリプトキディだけを逃がしたい場合は、これは役立つかもしれませんが、残りの事前攻撃から身を守ることができない場合があります。
私の推奨は、デフォルトのポートを使用し（管理オーバーヘッドを削減する可能性があります）、攻撃を緩和するために多面的なセキュリティ防御を導入することです。
たとえば、デフォルトのポートが使用されている場合、SSHを使用した証明書ベースの認証は、特定の信頼できるソースにのみ許可されます。
そうだと思います。通常のポート番号を使用すると、自動ボットの多くが除外されます。しかし、それには依存しないでください。私が気付いたボットの多くは、ネットワーク/ホストをスキャンして開いているポートを探し、それらを試します。
最善の方法は、SSHポートに適切なセキュリティを実装することです。 rootログインを無効にし、可能であればIPをホワイトリストに登録し、ログインにパスワードを使用しない（キーを使用する）、すべてのログインの通知も有効にする。ファイアウォールを設定します。これは重要です。
このように多数のポートを隠すと、よく知られたポートを探す単純なボットのみが停止します。スクリプトキディとハッカーは、ポート範囲の残りの部分をポートスキャンしてサービスを見つけることができるため、ログノイズを停止するだけです。
そのサービスの標準ポートをリッスンしないという慣例については、特に問題ではありません。そのサービスの開発者は、他のポートでそれを実行するオプションを提供し、サービスと対話する可能性のあるすべてのプログラムは、あなたが話したいポートを指定するオプションを持っています。
SSHのような機密性の高いポートは、1024以下の特権ポートスペースに保持する必要があるという他の投稿にも同意します。
実際に機能するSSHを不明瞭にするより良い方法は、ポートをノックすることです。これには、一連のポートが「ノック」されて目的のポートが開かれるまで、iptablesでポートを閉じることが含まれます。
たとえば、8000 4545 28882 7878にパケットを送信する場合があります。必要なシーケンスを入力すると、iptablesによって目的のポートのロックが解除されます。これは、ポートがアドバタイズされていないので、スクリプトキディとハッカーの大部分を本当に止めます。しかし、これはリプレイ攻撃を阻止するものではありませんが、その時点で、より大きな問題が懸念されます。
https://en.wikipedia.org/wiki/Port_knocking 。
実際には、TCPWrappersを使用し、既知のIPとネットワーク範囲のみにSSHなどのポートへのアクセスを許可する必要があります。中国のIPがSSHにアクセスできるようにする必要がありますか？または、開発者はオフィスのLANからアクセスするだけで済みますか？リモートで作業する場合は、VPNをLANに接続します
他の人が述べたように、非標準レベルの攻撃だけを除外するため、非標準ポートへの移行はセキュリティソリューションではありません。
同時に、他の予防策と組み合わせると、移行の価値が大幅に高まります。たとえば、ハニーポットを標準ポート（システムの他の部分から物理的に分離されているが、攻撃者にとっては合法的な部分のように見える環境）に配置します。次に、ハニーポットで誰かが侵入したのを見た場合、それはハッカーである可能性が高いので、自動で禁止することができます。
そして確かに、それらがリッスンするポート番号に関係なく、既知の脆弱性を持つ古いバージョンのソフトウェアを使用しないでください。
いいえ、そうではありません。または、より正確にしたい場合脅威に対する誤った保護です。
一歩後退：私たちから保護したい脅威は何ですか？私たちが保護しようとしている脅威は、通常の認証メカニズムを迂回できる公衆インターネット上の任意の人です。それが、これらの「スクリプトキディ」が実行しようとしていることです。認証されていなくても、SSHを使用してサーバーにアクセスします。特に、上司は、これらの攻撃者がSSH接続の確立を開始できないようにしたいと考えています。
ネットワーク接続の確立を防ぐための標準テクノロジーは何ですか？ ファイアウォール。この問題に対する標準的な答えは、ポート22を完全に外部トラフィックに対して完全にブロックすることです。ここでのより大きな問題は、SSHがパブリックインターネットで利用できることであり、ファイアウォールはこれを完全に解決しますが、あいまいなポートはそれをわずかに隠すだけで、実際には妨げません。接続。外部アクセスが必要な場合、この許可されたアクセスを許可するための標準的な答えは、ネットワークへのVPNです。これにより、スクリプトキディと知識攻撃者の両方がブロックされ、実際に使用しているポートを見つける方法がわかります。
攻撃者の1％に負けても負けます。攻撃者の100％に対して機能する保護が必要です。代わりに、（これまでのところ）100％の攻撃者のブロックに成功している場合は、より強力な保護を導入する必要があります。 これらの他の保護は、あいまいなポートを無意味にします。それが（うまくいけば）ケースである場合、他のポートを使用することは、あまり馴染みのない人を混乱させることになりますあなた自身のような実際のセキュリティ慣行では、おそらく、接続しようとしたときに正当なアクセスを得ようとする人々の時間を浪費します（新しいシステムは構成されておらず、誰かに正しいポートを尋ねる必要があります、管理者は非標準ポートについて人に伝えるのを忘れましたそして人は問題を診断するためにそれらを再び悩ませる必要がありますなど）。
これが、「あいまいさによるセキュリティ」と Kerckhoffsの原則 について考えている理由です。私たちは、実際に私たちを保護していない慣習に気を取られないようにすべきです。実際に機能する保護のために時間と労力を節約し、これらの難読化方法がもたらす「セキュリティ」の誤った感覚を回避する必要があります。
最後に付け加えておきたいのは、セキュリティは双方のリソースに関するゲームです。時間はそのような資源です。
この対策は攻撃者の時間を浪費しているので、それほど悪くはありません。攻撃者のリソースがカスタムポートに接続している場合も、攻撃者のリソースについて学ぶことができます。特にあなたをターゲットにした方が興味があるかもしれません。
ただし、管理タスクにかなりのオーバーヘッドが加わる場合は、別の場所に時間を費やすことをお勧めします。そうでない場合はそれを行いますが、それに依存しないでください。