私は自分のサーバーに ssh で接続できることを好みます (驚くかもしれませんが)。問題は旅行中に、ホテルやその他の施設でさまざまなファイアウォールに直面し、さまざまな設定 (時には非常に間抜けな設定) に遭遇したときに発生します。
この混乱を回避できる可能性が高いポートでリッスンする sshd を設定したいと思います。何か提案はありますか?
sshd は現在、スクリプト キディの侵入を防ぐために、非標準 (ただし 1024 未満) ポートをリッスンしています。このポートは、私の IMAP サーバーが稼働している他の非標準ポートと同様に、頻繁にブロックされます。
ポート 25 と 80 でサービスを実行していますが、それ以外は問題ありません。おそらく 443 だと思いました。
とても有難い！
リード
答え1
443 が機能しない理由がわかりません。
しかし、私はいつも 22 番以外のポートで sshd を実行することに疑問を抱いています。私自身は試したことはありませんが、これは隠蔽によるセキュリティです。これは、ほとんどが誤ったセキュリティ感覚を提供します。多くのボットは、攻撃する前に、または 22 番が閉じられている場合に、ホストのポート スキャンに時間を費やします。22 番がほとんどのファイアウォールで機能する場合は、22 番の使用に戻り、認証用のキー ペアを設定し、パスワード認証を完全に無効にします (22 番に戻すかどうかに関係なく)。
443 は頻繁に開くはずなので、良い選択のように思えます。
答え2
443 は良い考えではありません。特にポート 443 は、SSL トラフィックに使用しない場合は危険なソリューションです。まず、Gmail または大手サービス プロバイダーは、パブリック プロキシ サーバーとしてマークします (SSL 暗号化なしで 443 ですべてが機能するとマークします)。また、一部の専門的なファイアウォールも、SSL なしで 443 のトラフィックをすべてブロックします。Ultrasurf や Thor などのプロキシ プログラムが原因です。23 に戻すか、22 のままにしておくことができます。sshd でのブルートフォースが嫌いな場合は、fail2ban を使用することをお勧めします。http://www.fail2ban.org/wiki/index.php/Main_Page これは、sshd や ftp サーバーなどを保護するのに最適なソリューションです。
答え3
443 は適切なポートだと思いますが、一部のファイアウォールでは、ポート 443 のトラフィックが実際に https であることを確認するためにコンテンツ検査を実行する場合があることに注意してください。暗号化されたトラフィックが好まれない奇妙な場所もあるため、ポート 443 を拒否してください。
設定によっては、送信トラフィックを自社の DNS サーバーのみに制限していない限り、ポート 53 で問題ない場合があります。
予備の IP アドレスを使用できるかどうかも検討する必要があるかもしれません。Web サーバーが所有するすべての IP アドレスをリッスンする必要は必ずしもありません。その場合は、ブロックされる可能性が最も低いポート 80 を使用できます。
繰り返しになりますが、SSH サーバーを不明瞭にしようとしているときに、よく知られているポートに SSH サーバーを配置するのはおそらく賢明ではありません。また、ポート 80 と 443 にインライン プロキシ サーバーがあり、これを妨げる可能性があります。
答え4
私は、ネットワークの制限が厳しいシステムにシステムを持ち込む複数のユーザーのために VPN をサポートしています。私の経験では、100% の時間で機能する単一のポートは存在しません。可用性の高い接続が必要な場合は、多くのポートで接続を受け入れるようにシステムを設定する必要があるでしょう。
あるポートでリッスンするように SSH を設定し、NAT を使用して他のポートでも使用できるようにします。
ポート 80 は使用中であるとおっしゃっています。ポート 80 で Apache を実行している場合は、プロキシとして設定することもできます。ただし、オープン プロキシにならないように、アクセスを正しく設定する方法を時間をかけて理解してください。
残念ながら、制限のあるネットワークからシステムにアクセスできるようにしたい場合は、多くのスキャンが必要になる可能性があります。ファイアウォールで一般的に許可されているプロトコルは、一般的に使用され、スキャンされるプロトコルと同じです。denyhosts や fail2ban などを設定して、システムからユーザーを締め出してください。