SSHサーバーを強化する方法は?


128

SSHサーバー周辺のセキュリティが完全に不浸透であることを確認するために、どのような対策を講じることができますか?

これは最初からコミュニティWikiになるので、サーバーを保護するために人々が何をするかを見てみましょう。


44
絶対的な不透過性には、ボックスをオフにする必要があります。
するThorbjörnRavnアンデルセン

Wake-on-LANがある場合はどうなりますか?
rebus

あなたはWOLパッケージを送信するためにLAN内のマシンへのアクセス権を持っている必要がありますので、問題は...、LAN一部...ウェイクオンLANパッケージがルーティングされないだろう
LassePoulsen

鍵認証では、暗号を本当に必要な暗号に制限する場合があります。

回答:


108

パスワードではなく公開/秘密キーのペアを認証に使用します。

  1. サーバーにアクセスする必要があるすべてのコンピューターについて、パスフレーズで保護されたSSHキーを生成します。

    ssh-keygen

  2. 許可されたコンピューターからの公開鍵SSHアクセスを許可します。

    ~/.ssh/id_rsa.pub各コンピューターの内容を~/.ssh/authorized_keysサーバー上の個々の行にコピーするか、ssh-copy-id [server IP address]アクセスを許可するすべてのコンピューターで実行します(プロンプトでサーバーのパスワードを入力する必要があります)。

  3. パスワードSSHアクセスを無効にします。

    開いて/etc/ssh/sshd_config、言う行を見つけて、#PasswordAuthentication yesそれをに変更しPasswordAuthentication noます。SSHサーバーデーモンを再起動して、変更を適用します(sudo service ssh restart)。

現在、サーバーにSSHで接続する唯一の方法は、の行に一致するキーを使用すること~/.ssh/authorized_keysです。この方法を使用すると、ブルートフォース攻撃については気しません。パスワードを推測しても拒否されるためです。今日のテクノロジーでは、公開キーと秘密キーのペアを総当たり攻撃することは不可能です。


5
-1:通常、アクセスはコンピューターではなく個々に許可されます。サーバーに接続する潜在的なクライアントコンピューターごとにキーを作成するのは理不尽です。あなたの最後のステートメントは、あなたの提案ごとに正しくありません。また、クライアントシステムのいずれかにアクセス/危殆化する秘密鍵にパスフレーズを設定することを提案しなかったため、SSHサーバーへのアクセスが自動的に許可されます。SSHキー認証をお勧めしますが、秘密キーは適切に保護する必要があり、説明したように分散方式ではなく、個別に使用する必要があります。
ジョアンピント

7
「一般的にアクセスはコンピュータではなく個々に許可され、サーバーに接続する潜在的なクライアントコンピュータごとにキーを作成するのは不合理です」多くのオプションがあり、秘密キーをすべてのクライアントに安全に転送する方法を説明することは、この質問の範囲外と思われます。私はすべてのオプションを提示するのではなく、人々が理解できると思う単純なオプションを提示します。「...説明したように分散して使用するのではなく、個別に使用する必要があります」これはあなたの以前の声明と矛盾するようであり、私は何も分散したとは説明しませんでした。
アサエアーズ

5
「不可能」は、おそらくそれを少しやりすぎています。
するThorbjörnRavnアンデルセン

9
これが私が「不可能」と言う理由です。こんなに高速なコンピューターをこれほど多く、あるいは多くの時間に持っている人は誰もいません。「暗号化されたデータに対してキーをテストできる砂粒のサイズのコンピューターを想像してください。また、光を通過するのにかかる時間でキーをテストできると想像してください。次に、これらのコンピューターのクラスターを検討し、地球をそれらで覆うと、地球全体を1メートルの高さまで覆うことになります。コンピューターのクラスターは、1,000年で平均で128ビットのキーを解読します。」
アサエアーズ

@ThorbjørnRavnAndersen「Impossible」は、強力なキーを使用している限り、それを誇張しているわけではありません。今は引用符を見つけることができませんが、現在のキーの長さでは、ブルートフォース攻撃は「コンピューターが問題以外のもので構成され、スペース以外のものを占有するまで」実行不可能です。
マクシミリアン・ローメイスター

72

私はお勧めします:

  • 総当たりログイン試行を防ぐためにfail2banを使用します。

  • SSH経由でのルートとしてのログインを無効にします。これは、攻撃者がユーザー名とパスワードの両方を把握して、攻撃をより困難にする必要があることを意味します。

    に追加PermitRootLogin noします/etc/ssh/sshd_config

  • サーバーにSSH接続できるユーザーを制限します。グループ別または特定のユーザーのみ。

    サーバーにSSHできるAllowGroups group1 group2ユーザーAllowUsers user1 user2を追加または制限します。


2
AllowUsersというにAllowGroupsはコンマを受け入れていない区切り文字として。リモートでこれを試さないでください。これを間違って行うと、NASからロックアウトされ続けます。
アートレスノイズ

4
sshdマシンからロックアウトされないように、sshdを再起動する前に、構成が正しいことを常に確認してください。詳細については、このブログを参照してください- sshd -Tメインを再起動する前に、構成を変更した後に実行してくださいsshd。また、構成を変更するときにマシンでSSHセッションを開いてください。また、前述のように構成を検証し、SSHログインをテストするまで、これを閉じないでください。
-RichVel

24

他の回答はセキュリティを提供しますが、ログをより静かにし、アカウントからロックアウトされる可能性を低くするためにできることが1つあります。

サーバーをポート22から別のポートに移動します。ゲートウェイまたはサーバーのいずれかで。

セキュリティは向上しませんが、すべてのランダムなインターネットスキャナーがログファイルを乱雑にしないことを意味します。


1
あいまいさ(en.wikipedia.org/wiki/Security_through_obscurity)によってセキュリティを信じている人にとっては、別のポートを使用することは理にかなっています。私はそうはしない..
ラッセポールセン

32
隠蔽によるセキュリティに関するものではありません(ただし、隠蔽はわずかなプラス効果をもたらす可能性があります)。無限のブルートフォース攻撃のバックグラウンドノイズを減らすことです。自動化された攻撃に満ちている場合、アクセス失敗ログを有効に監査することはできません。fail2banは、攻撃者の数と、分散(ボットネット)攻撃およびスロットル攻撃の普及を考えると、ボリュームを十分に削減しません。珍しいポート上のSSHを使用すると、知っているあなたがログに表示さ攻撃があなたのボックスに興味が本当の攻撃者から来ます。強くお勧めします。
ボビンス

Webに接続するsshサーバーについてshodanなどのインターネットサービスを照会したり、nmapとバナーキャプチャを使用したりすると、デフォルトポートを変更してもほとんど意味がありません。これに反対します。
スローロリス

Shodanはすべての65kポートを取得するわけではないため、高いポートに変更するとスキャンから削除される可能性があります。また、ランダムに高いポートに移動する場合、攻撃者はサービスを見つけて攻撃を開始するために65K TCPスキャン(非常に騒々しい)を行う必要があります。これらはどちらもセキュリティの観点から見れば勝ちです。そのため、ハイポートへの移行は一般的に良い計画です。もう一つは、高いポートに移動して、あなただけの一般的な背景インターネットノイズではなく、具体的としてあなたを攻撃している誰かがあなたのシステムをターゲットにしていることをより良いアイデアを持つことができるということです
RоryMcCune氏

23

2つの要素認証を有効HOTPまたはTOTPを。これは、13.10以降で利用できます。

これには、ここでの別の回答のようにパスワード認証よりも公開キー認証を使用することも含まれますが、ユーザーは自分の秘密キーに加えて第2要素デバイスも保持していることを証明する必要があります。

概要:

  1. sudo apt-get install libpam-google-authenticator

  2. 各ユーザーにgoogle-authenticatorコマンドを実行して~/.google-authenticatorもらい、2要素デバイス(例:Google Authenticator Androidアプリ)を生成して構成を支援します。

  3. 編集/etc/ssh/sshd_configおよび設定:

    ChallengeResponseAuthentication yes
    PasswordAuthentication no
    AuthenticationMethods publickey,keyboard-interactive
    
  4. を実行sudo service ssh reloadして、への変更を取得します/etc/ssh/sshd_config

  5. 行を編集/etc/pam.d/sshdして置換します。

    @include common-auth
    

    で:

    auth required pam_google_authenticator.so
    

さまざまな設定オプションの詳細は、昨年の私のブログ投稿です。Ubuntuでの2要素ssh認証の改善


21

正しいログイン情報の提供に失敗したクライアントIPをsshdがブロックするようにします。「DenyHØsts」はこのジョブを非常に効果的に実行できます。私はこれをすべてのLinuxボックスにインストールし、何らかの形で外部からアクセスできるようにしました。

これにより、SSHDに対する強制攻撃が有効にならないようになりますが、パスワードを忘れた場合にロックアウトされる可能性があることを覚えておいてください(!)。これは、アクセスできないリモートサーバーで問題になる可能性があります。


2
IPアドレスを禁止する前に10回失敗したログイン試行のようなオプションはありますか?
sayantankhan

20

簡単な1つの方法があります。ufw(「複雑でないファイアウォール」)をインストールし、それを使用して着信接続のレート制限を行います。

コマンドプロンプトから次のように入力します。

$ sudo ufw limit OpenSSH 

場合UFWがインストールされていない、これを実行して、再試行してください:

$ sudo aptitude install ufw 

多くの攻撃者は、パスワードをブルートフォースするためにSSHサーバーを使用しようとします。これにより、同じIPアドレスから30秒ごとに6つの接続のみが許可されます。


+1制限を使用するとよい場合があります。ただし、組み込みのsftpサーバーを使用すると、この接続も制限されるため、問題が発生したことを指摘する必要があります。
マークデビッドソン

2
@マーク-良い点ですが、それは不十分に書かれたSFTPクライアントのように聞こえませんか?さらに多くのSSHチャネルを開くことができるのに、なぜ彼らはSSHポートに再接続し続けるのでしょうか?
mpontillo

12

私はいくつかの追加のセキュリティを持ちたいか、いくつかの企業ネットワークIセットアップの奥深くSSHサーバーにアクセスする必要がある場合は隠されたサービスを匿名化ソフト使ってTorのを

  1. Torをインストールし、SSHサーバー自体をセットアップします。
  2. sshdがでのみリッスンするようにしてくださいlocalhost
  3. オープン/etc/tor/torrc。設定HiddenServiceDir /var/lib/tor/sshHiddenServicePort 22 127.0.0.1:22ます。
  4. 見てくださいvar/lib/tor/ssh/hostname。のような名前がありd6frsudqtx123vxf.onionます。これは、非表示のサービスのアドレスです。
  5. $HOME/.ssh/configいくつかの行を開いて追加します。

    Host myhost
    HostName d6frsudqtx123vxf.onion
    ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050
    

さらに、ローカルホストにTorが必要です。インストールされていれば、入力ssh myhostしてSSHでTor経由で接続を開きます。反対側のSSHサーバーは、localhostでのみポートを開きます。だから、だれも「通常のインターネット」経由で接続することはできません。


10
高度な不明瞭さによるセキュリティ、しかし非常に興味深い。
ヨハネス

8

このトピックに関するDebian管理の記事があります。基本的なSSHサーバー構成とファイアウォールルールについても説明します。これは、SSHサーバーを強化する場合にも興味深い場合があります。

記事「SSHアクセスを安全に保つ」を参照してください。


3
少し遅れますが、質問に答えるときは、リンクから重要な部分をコピーして、リンクが劣化しても情報がここに残るようにしてください。
umop aplsdn

1
良いアイデア。私は参加する時間がはるかに少ない期間を経ていますが。私の答えは「コミュニティwiki」ですので、時間があればリンク情報を自由に追加してください。
ホイヘンス

6

SSH強化に対する私のアプローチは...複雑です。次の項目は、ネットワークの最も端の境界からサーバー自体に至るまでの、その方法に関するものです。

  1. ブロックリスト内の既知のサービススキャナーとシグネチャを使用したIDS / IPSを介したトラフィックの境界レベルフィルタリング。 私はボーダーファイアウォールを介してSnortでこれを実現しています(これが私のアプローチ、pfSenseアプライアンスです)。VPSの場合など、これができない場合もあります。

  2. SSHポートのファイアウォール/ネットワークフィルタリング。 特定のシステムがSSHサーバーに到達することのみを明示的に許可します。これは、ネットワークの境界にあるpfSenseファイアウォールを介して行われるか、明示的に構成されている各サーバーのファイアウォールを介して行われます。ただし、これができない場合があります(プライベートペンテストや、ファイアウォールでは物事のテストが助けられないセキュリティテストラボ環境を除き、ほとんどそうではありません)。

  3. 私のpfSense、または内部ネットワークをNATし、インターネットおよびシステムから分離している境界ファイアウォール、サーバーへのVPNのみのアクセスと組み合わせて。VPNをネットワークに接続してサーバーに接続します。インターネットに直接接続するポートは存在しないためです。これは私のすべてのVPSで確実に機能するわけではありませんが、#2と組み合わせて、そのサーバーにVPNすることで1つのVPSを「ゲートウェイ」にして、他のボックスへのIPを許可することができます。そうすれば、SSHを使用できるかできないかを正確に把握できます。これが、VPNという1つのボックスです。(または、pfSenseの背後にある私のホームネットワーク、VPN接続、および私はVPNアクセスを持つ唯一のものです)。

  4. #3が実行できない場合、4回の試行失敗後にブロックし、1時間以上IPをブロックするように構成された fail2banは、ブルートフォーシングで絶えず攻撃している人々に対するまともな保護です。ただし、fail2banの設定は苦痛です...

  5. SSHポートを変更することによるポートの難読化。 ただし、これは追加のセキュリティ対策なしで行うことは得策ではありません。多くの場合、「セキュリティを介したセキュリティ」のスローガンは既に反論され、議論されています。IDS / IPSおよびネットワークフィルタリングと組み合わせてこれを実行しましたが、それ自体で行うのは非常に悪いことです。

  6. Duo Securityの2要素認証ソリューションを介した必須の2 要素認証 SSHサーバーにはすべてDuoが構成されているため、2FAのプロンプトが表示されるため、各アクセスを確認する必要があります。(これは究極の便利な機能です。誰かが私のパスフレーズを持っているか、侵入したとしても、Duo PAMプラグインをすり抜けることができないためです)。これは、SSHサーバーでの不正アクセスに対する最大の保護の1つです。各ユーザーログインはDuoの構成済みユーザーに結び付けなければなりません。また、制限セットがあるため、システムに新しいユーザーを登録できません。

SSHを保護するための2セント。または、少なくとも、アプローチに関する私の考え。


1

Google認証システムを使用する代わりに、RedHatからFreeOTPアプリをチェックアウトすることもできます。アプリを更新すると、ロックアウトされる場合があります!;-)

YubikeyやeToken PASSまたはNGなどの他のハードウェアトークンを使用する場合、または多数のユーザーまたは多数のサーバーがある場合は、オープンソースの2要素認証バックエンドを使用できます。

最近、これについてハウツーを書きました。


0

最近、これを行うための小さなチュートリアルを書きました。基本的に、PKIを使用する必要があります。また、私のチュートリアルでは、セキュリティをさらに高めるために2要素認証を使用する方法も示します。これらのどれも使用しなくても、弱い暗号スイートやその他の基本を削除することでサーバーを保護することについてのちょっとしたヒントもあります。https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/


0

多数のユーザー/証明書については、LDAP統合を検討してください。大規模な組織では、認証または電子メールの署名に証明書が使用されているかどうかにかかわらず、バッジまたはフォブに保存されているユーザー資格情報と証明書のリポジトリとしてLDAPを使用します。例には、openLDAP、openDJ、Active Directory、Oracle Universal Directory、IBM Directory Server、snareWorks ...が含まれます。

コンピューターとグループをLDAPで管理して、中央の資格情報を管理することもできます。そうすれば、ヘルプデスクは、大勢の人々に対処するためのワンストップショップを持つことができます。

ここではCentOSの統合へのリンクです:http://itdavid.blogspot.com/2013/11/howto-configure-openssh-to-fetch-public.html


0

geoIPデータベースを使用して、原産国に基づいてブロックすることもできます。

基本的に、米国に住んでいる場合、ロシアの誰かがあなたのSSHに接続する理由はないので、彼らは自動的にブロックされます。

スクリプトは次の場所にあります:https : //www.axllent.org/docs/view/ssh-geoip/

また、iptablesコマンドを追加して(ドロップレットに追加しました)、それらのIPとの間のすべてのトラフィックを自動的にドロップすることもできます。


1
時折、GeoIPデータベースが間違っている可能性があります-私は昨日モスクワにいましたかと尋ねられました... :)
ショーン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.