sshdをロックダウンする

SSH、またはSecure SHellは、1990年代のどこかで、リモートアクセスプロトコルとしてTelnetに取って代わりましたが、これには正当な理由があります。 SSHを使用すると、管理者（またはユーザー）は、SSHクライアントをSSHサーバーに接続することにより、安全なトンネルを介してリモートシェルにアクセスできます。 SSHはファイル転送も処理できます。これはFTPに取って代わるはずですが、古き良きクリアテキストFTPに依存している状況は驚くほど多くあります。

なんで？うーん。

上記の理由により、最近のLinuxシステムはSSHを介して管理されています。ほとんどの経験豊富なシステム管理者は、比較的簡単にシステムのシェルに安全に接続することで得られる直接アクセスと電力を気に入っています。この記事では、OpenSSHサーバーデーモン sshdについて具体的に説明します。。発生する可能性のあるセキュリティ問題のいくつかと、それらを軽減または完全に解決する方法について説明します。

SSHが必要な理由

前述したように、SSHは強力なツールです。 SSHセッションを介して、仮想端末をターゲットシステムに直接接続できます。悪意のある人には、この能力が問題になる可能性があるのに、なぜそのような力を利用できるようにしておくのでしょうか。さて、SSHの力には微妙なバランスが含まれます。管理者は数分以内に、インシデントに対応するためにサーバーに対して安全なセッションを開くことができます。シンプルさはエレガントです。

SSHは、Ansibleなどの自動化ツールの中核でもあります。 Ansibleは、エージェントを必要とせずにSSHを介してシステムに変更を適用できます。代わりに、SSHとPythonを使用してすべての変更が実行されます。

SSHは、前述したように、安全なファイル転送にも使用できます。たとえば、 rsync 安全なデータ同期のためにSSHを介してトンネルします。 SSHを使用して、あるシステムをトンネリングして別のシステムに到達することもできます。これは、トラブルシューティングには最適ですが、攻撃者にも最適です。

前の段落で納得がいかない場合は、もう一度言います。SSHは強力なツールであり、他の強力なツールと同様に、悪用される可能性があります。攻撃者がシステムに安全なシェルを取得できる場合、それはゲームオーバーです。また、攻撃者はこれを知っているため、攻撃できるようにSSHが世界中に公開されているシステムを常に探しています。

SSHをロックダウン

SSHに対する最も一般的な攻撃は、ブルートフォースです。私のシステムでは、SSHに対してブルートフォース攻撃が成功したことはありません。しかし、私が簡単な封鎖規則に従い始める前に、彼らが確かに試みたと言うことができます。

インターネットに接続されたデバイスを対象とする検索エンジンであるShodanをすばやく検索すると、SSHが世界中に公開されている20,984,090台のシステムが表示されます。このように設定する必要がありますか？これらのシステムのすべてが1秒間に複数のSSHブルートフォース攻撃を受けることをほぼ保証できます。この記事を書いている間、私はDigital Oceanでドロップレットを開始し、SSHを世界に公開したままにして、 / var / log / secureを尾行しました。。約20分以内に、最初のSSHプローブが表示されました。 1時間以内に、ブルートフォース攻撃の洪水が始まりました。

  Jun 23 01:35:33 centos-s-1vcpu-1gb-sgp1-01 sshd [10926]：81.22.45.137ポート61000Jun 2301:37:47centos-s-1vcpuから識別文字列を受信しませんでした-1gb-sgp1-01 sshd [10928]：104.248.132.25ポート36050からのInvaliduser fake 23 01:37:47 centos-s-1vcpu-1gb-sgp1-01 sshd [10928]：104.248.132.25ポート36050：11からの受信切断：Bye Bye [preauth]

要するに、デフォルトの sshdの不正なパスワードインストールは、悪者とあなたのシステムの間にあるすべてである可能性があります。 OpenSSHのデフォルト構成はまともな安全性を備えていますが、強化される可能性があります。幸いなことに、提案があります。

ポート22へのアクセスを制限する

まず、デフォルトのSSHポート（ポート22）が世界中に公開されているかどうかを確認します。これを行うには、Nmapを実行します。これにより、仕様に従ってネットワークがプローブされます。

  2019-06-22 20:56にNmap7.70（https://nmap.org）を開始SERVICE22 / tcp open ssh

ポート22にアクセスできるユーザーを絞り込むことは、システムを保護するために実行できる最も基本的なことです。この戦術がすべてのシナリオで機能するとは限らないことを私は理解しています。公用システムを実行している場合もあれば、CIOが頻繁に移動して、さまざまな場所からシステムにアクセスする場合もあります（VPNについては後で説明します）。私のポイントは、SSHが絶対に一般に公開される必要があるという正当な理由があるかもしれないということです。 非常に考えてくださいただし、その構成を回避するのは困難です。私はそれをしましたが、ほとんど怠惰からです。通常、より良い方法があります。

クラウドプロバイダーを使用している場合は、作業元のネットワークからのSSHトラフィックのみを受け入れるようにセキュリティグループを構成します。エンタープライズ環境からこのプロバイダーにアクセスする場合、このタスクは単純である必要があります。おそらく独自のIPアドレス範囲があります。つまり、それをホワイトリストに登録して、他のすべてをブロックすることができます。ただし、自宅からクラウドプロバイダーにアクセスしている場合は、ISPの動的に割り当てられたIPブロックをホワイトリストに登録するためにいくつかのトリックを実行する必要がある場合があります。セキュリティグループを使用すると、必要に応じてクラウドプロバイダーのセルフサービスポータルを介してIPアドレスの範囲を変更できるようになります。

ファイアウォールの背後にないシステムをホストしている場合は、ホストベースのファイアウォールを使用して、今説明したのと同じ方法を使用して、IPアドレス範囲以外の場所からポート22をブロックします。もちろん、そこでの問題は、IPアドレスが変更されたためにロックアウトされた場合、必要な変更を行うのに苦労することです。

また、エンタープライズ環境にはメリットがあることを忘れないでください。サーバーがエンタープライズネットワーク上にある場合は、SSHアクセスをロックダウンするために使用できるネットワークファイアウォールがある可能性が高いため、その事実を活用してください。多層防御の人々、それは重要です！

リモートアクセスにはVPNが必要です

では、絶対に必要な旅行中のCIOについて話しましょう。ホテルの部屋からsshへのアクセス。解決策は、ブロックの周りにいる私たちにとっては明白に思えますが、SSHアクセスを全世界に開くことを検討している場合は、これを聞く必要があるかもしれません：VPN、または仮想プライベートネットワークを使用すると、暗号化されたトンネルを構築できますマウイのホテルにあるCIOのラップトップなどのエンドポイントから、シアトルのエンタープライズネットワークに戻ります。この接続は独自の方法で保護され、暗号化されます。

ただし、世界中からアクセスできない数十台のサーバーに、この1つのポイントからアクセスできるようになる可能性があります。はい、この方法では攻撃対象をVPNに移行しますが、それは悪意のあるユーザーが乗り越えるためのもう1つのハードルがあることを意味します。

rootアクセスを拒否する

ここで、実際の sshdに取り掛かります。構成。 OpenSSHデーモンには、 PermitRootLoginというオプションがあります。。デフォルトでは、このオプションは Yesに設定されています、一部のシステムをインストールすると、最初はrootのみが存在するためです。このような状況が発生した場合、システムにアクセスして初期構成を実行するには、rootアカウントが必要です。

インストールプロセス中、またはゴールデンイメージの一部としてユーザーを追加し、最初からrootログインをオフにすることをお勧めします。 rootとしてログインする理由はありません。また、SSH経由でrootとしてログインする理由もありません。したがって、構成行を次のように変更します。

  PermitRootLogin no

キーベースの認証を実装する

当初は、便宜上、キーベースの認証を使用していました。秘密鍵を生成し、公開鍵を authorized_keysに追加しました管理しているサーバーにファイルを保存すると、パスワードなしでシステムに安全に接続できます。これを行うことで時間を節約し、自動化を可能にしました。勝つ！ SSHキーベースの認証を利用して、パスワードの総当たり攻撃を排除できることがわかったのは、後でなってからでした。

キーを生成するには、 ssh-keygenを実行します MacまたはLinuxボックス。 Windowsの皆さんは今、これをネイティブに実行できるかもしれませんが、Windowsマシンでは、私は常にPuTTYGenを使用していました（その後、PuTTYクライアントでキーを使用しました）。キーの種類と長さを尋ねられます。最近、4096ビットのRSAキーを作成しています。ビットが多いほど、鍵を割るのが難しくなります。では、なぜですか？

  [gangrif @ meliodas〜] $ ssh-keygen -b 4096パブリック/プライベートrsaキーペアを生成しています。キーを保存するファイルを入力してください（/home/gangrif/.ssh/id_rsa）：./test- keyEnterパスフレーズ（パスフレーズがない場合は空）：同じパスフレーズをもう一度入力：IDは./test-keyに保存されています。公開キーは./test-key.pubに保存されています。キーの指紋は次のとおりです：SHA256：xfHOf4t3V3CCkJ + 3FbEnQusAjBw[email protected]キーのランダムアートイメージは次のとおりです。+---[RSA 4096] ---- + | ++o。+。 ....+o。|| 。 。+o.. + o + o + o .. || o + =o =B..o || =*E。+。+|| So+。 * || o..。|| o。 o || 。 .o + || ... o | + ---- [SHA256] ----- +

最終的には、 test-keyという新しいファイルになります。（この場合）、および test-key.pub 。 test-keyのキーは私の秘密鍵であり、 test-key.pub 公開鍵が含まれています。あなたの人生で秘密鍵を保護してください。ただし、秘密鍵がないと役に立たないため、公開鍵はどこにでも置いておくことができます。

<前>の

 [gangrif @メリオーダス〜] $猫のテストkey.pubssh-RSA AAAAB3NzaC1yc2EAAAADAQABAAACAQDAQxmjoHO6i4Kkq8vp49KtqAsMcw + ptgvd + PGjxVYkDPGdzRZpJhq0c3BDstFs86ENlojs61zZaP3MihLR0BlDdIyM3jh9TmVvmOPiylhu4X9QliAca / ODxyVp76OpTKm + QcgBi / 7I / JNiJdEgcSy8izB0Oil7LZjIhS6wCs3mQFVbkPXPfe1lmHQIcuMDOKO0RuyecY / lrKodcr / YbEE4GsM / P11QdDPZ78lq83G3H5vqLqMrxVKkLw7Z4 // + PZPFFxi / N1EBwBp / uPEo4MfD1IwSmnKromRlkYTdOYlbiCNosdvEobtMARySdqjv7RDn0Iwb3JxioUW6jQdAXfl8d01LvX / 0Yb1tq5hF44ahwvI6TyoB4z3DRs + 3cFiMPWQR7LK8 / qQOvHk5I2NMBAV9KuSN2ML0d7xeB8tglw38PYjhZsXl / t2rAWT4n8PU0o6 + Hrrli + WEfvk8QWpLesmBBmzG0sLjH0mXBU / xN4UBLLJNlrsUQ / TzEsdknntMhh7leOzechlU3PiTNuUitweT9NqLJwCP + CHbeSJn2M5qzb090CPnCGpnr2GOfm2dL + RfHQi2R1Cf04nBDq3WuhAPJY5SoEw2llfSgA2GlOdhcY9N9Bl9rLUBPgQ6ttBd7qZJ6E3BkiPlHnU + kSSpYr8Gkw1oDGbtd2UUjExZqvz4rQ [email protected]   
 パスワードを使用せずに接続するマシンでは、公開鍵を .ssh / authorized_keysにコピーします （または、状況に応じて、ユーザーに実行してもらいます）。さて、私はパスワードなしで言いますが、それでも生成中に設定したパスワードで秘密鍵のロックを解除する必要があります。パスワードを設定しましたか？
 
  ssh-copy-id を使用して、このキーをサーバーにリモートでコピーすることもできます。 。
 パスワードベースの認証を無効にする
 
 キーベースの認証により、SSHブルートフォース攻撃を完全にロックダウンできる可能性があると言ったのを覚えていますか？さて、これがその方法です。秘密鍵と公開鍵を配置すると、SSHはパスワードの入力を求めなくなりますよね？では、なぜその道を攻撃のベクトルとして開いたままにしておくのですか？
 
 実行するすべてのLinuxサーバーで、基本インストールの一部として公開鍵を追加し、システムがネットワークに接続する前にSSHパスワード認証をオフにします。これはsshdの設定です の構成ファイル。繰り返しになりますが、デフォルト設定ではパスワード認証が許可されています。これは、その機能が構成のために機能する必要があるためです。ただし、キーを配置したら、それをオフにします。
   PasswordAuthentication no  
 
 おめでとうございます。これで、パスワードブルートフォース攻撃の影響を受けなくなりました。
  SSHユーザーjail、 chroot  
 
  chroot  —通常は「chi-root」または「ch-root」と発音されます—コマンドは優れたツールです。プロセスとその子から見たルートディレクトリを変更できるため、この名前が付けられています。ディスクにアクセスできるが起動しないシステムのトラブルシューティングに最適です。ディスクとchrootを/mnt/whateverにマウントするだけです。
 
 これは、シェルサーバーのようなもののための優れたセキュリティツールでもあります。ログイン時にユーザーをchrootできるため、ユーザーは文字通りファイルシステムの残りの部分を見ることができません。私はこれを頻繁に行うことはありませんが、ユーザーにとって非常に実行可能な刑務所です。ここでまともな記事のように見えるものを見つけました。
 回転
 
 パスワードとsshキーのローテーションを検討する価値があります。ここで良い点と悪い点の概要を説明します。
 パスワードポリシーとローテーション
 
 パスワードポリシーは関連しているため、パスワードローテーションと一緒にまとめます。複雑さを強制するパスワードポリシーは、ユーザーに「強力な」パスワードを選択させるための優れた方法です。ただし、これにはいくつかの注意点があります。特に、任意の（つまり、時間指定された）パスワードの有効期限と組み合わせる場合は注意が必要です。パスワードポリシーとローテーションについての私の気持ちについての記事全体を書くことはできますが、ここでは簡潔に説明します。
 
 昨年、NISTは、パスワードガイドラインについて、ほとんどのキャリアで私たちの心のほとんどに根付いていた提案のいくつかを変更して、なんらかの形で取り組みました。 Infosecコミュニティ（私が手を出している）は何年もの間、8文字のランダムパスワード、または厳密な複雑さのルールを持つ8文字の最小長が、HARMパスワードの衛生に役立つよりも多くのことを行っていることを示唆してきました。厳格な複雑さのルールと3〜6か月のパスワードローテーションポリシーを組み合わせると、ユーザーはフラストレーションを感じるようになります。その欲求不満は、パスワードの再利用やその他の悪い習慣につながります。したがって、これをユーザーに課したいかどうかをよく考えてください。新しい推奨事項は、違反または侵害が疑われる場合にのみ有効期限が切れ、ユーザーをパスワードではなく強力なパスフレーズに導くポリシーに傾いています。 「これは私のp@ssw0rd2019です。」 「W1nt3r2019」よりも推測やクラックがはるかに困難です。ちなみに、これはパスワードセッターとレッドチーマーの両方に共通の頼みの綱です。ただし、賢い管理者にパスワードのローテーションを依頼している場合は、この問題が発生しない可能性があることに注意してください（パスワードを変更する理由とその重要性を理解しているため）。しかし、ユーザー全体にとって、任意の有効期限と複雑な「パスワード」は過去のものになりつつあります。
 SSH秘密鍵ローテーション
 
 生成できる他の識別子と同様に、秘密鍵を定期的にローテーションすることを検討することをお勧めします。秘密鍵は、パスワードほど簡単に盗んだり推測したりすることはできませんが、誰かが知らないうちに鍵を盗んだ可能性があります。これは「どのように妄想的になりたいか」の領域に入ります。ただし、秘密鍵のパスワードを変更するだけでは不十分です。そのパスワードはそのキーのロックを解除します。今日私があなたのキーをスワイプし、明日あなたがパスワードを変更した場合、私が持っているあなたのキーがまだあなたの古いパスワードを持っている場合はコピーします。これを正しく行う場合は、まったく新しいキーを生成する必要があります。最後にキーを生成してから標準が上に移動した場合は、キーの長さを長くする良い機会です。多分あなたはあなたの雇用主があなたに新しいラップトップを発行するたびに新しいキーを生成します、多分あなたはあなたの仕事の記念日に年に一度それをします。しかし、これを管理するソリューションは見つかりませんでした。
 
 新しい鍵を生成するということは、世界中にあるすべての公開鍵が無効になっていることを意味することに注意してください。または、少なくとも新しいキーでは無効です。新しい公開鍵を配置するには、古い鍵を使用する必要がある可能性があります。
  MFA 
 
 多要素認証が標準になりつつあります。 SSHキーはMFAの一種であると主張しようとする人もいますが、そうではありません。特にパスワード認証を無効にしている場合。ただし、TOTPやYubiKeyなどのmfaをシステムのPAM構成に統合することはできます。 FreeIPAのような中央認証ソリューションはこれを簡単にします。
 結論
 
 これで、セキュリティを向上させるために、この情報をシステムに適用していただければ幸いです。 SSHが世界に公開されている2,100万のシステムの1つにならないでください。理由はありません。
 
 読んでくれてありがとう！
 
 この記事は元々Undrground.orgで公開されました。許可を得て再公開しました。