web-dev-qa-db-ja.com

SSHセキュリティを（さらに）保証する方法は？

Linux Ubuntuマシンをno-ip.comを介してSSHサーバーとして設定しましたが、うまく機能します。

最近、私はコマンドを発見しました、

Sudo lastb -ad -F -w

最新の失敗したSSHログイン試行のログを出力します。どのような対策を講じることができますか？パッシブ（たとえば、場所によるログイン試行のフィルタリングが向上していますか？）およびアクティブ（例：手動IPブロック）とその方法は？これは冗長な質問かもしれませんが、リンクや特定のLinux端末の例に感謝します。私は基本的にIS初心者です。

これは出力のごく一部であるため、中国の一部の人は本当に私の日を台無しにしたいと思います（リストされているIPはどちらも who.is で中国からのものだと言っています）。

root     ssh:notty    Sun Jan 31 23:48:58 2016 - Sun Jan 31 23:48:58 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:57 2016 - Sun Jan 31 23:48:57 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:55 2016 - Sun Jan 31 23:48:55 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:55 2016 - Sun Jan 31 23:48:55 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:52 2016 - Sun Jan 31 23:48:52 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:52 2016 - Sun Jan 31 23:48:52 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:49 2016 - Sun Jan 31 23:48:49 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:49 2016 - Sun Jan 31 23:48:49 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:46 2016 - Sun Jan 31 23:48:46 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:46 2016 - Sun Jan 31 23:48:46 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:43 2016 - Sun Jan 31 23:48:43 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:41 2016 - Sun Jan 31 23:48:41 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:38 2016 - Sun Jan 31 23:48:38 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:37 2016 - Sun Jan 31 23:48:37 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:35 2016 - Sun Jan 31 23:48:35 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:34 2016 - Sun Jan 31 23:48:34 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:32 2016 - Sun Jan 31 23:48:32 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:32 2016 - Sun Jan 31 23:48:32 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:30 2016 - Sun Jan 31 23:48:30 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com

私のマシンにアクセスしようとするブルートフォースの試みが疑われます（この試みは文字通り数秒ごとに発生しています）。手伝ってください。

authenticationlinuxsshbrute-forceip
6
khaverim

できる限り多くの緩和策を実行します。

あなたの目標は、さまざまな潜在的な攻撃者に、より多くの労力、リソース、コンピュータ時間（したがって電気代）、そして最も特に「熟練」した（まれまたは乏しい、したがって貴重な）人時間を費やすことを強制することです。すべての脅威に対して1つの保護が機能するわけではありません。インターネット上に残っている間、すべての脅威を防御できるわけではありません。

ただし、多数の脅威（スクリプトキディ、スキルの低い、またはリソースの少ない攻撃者）は、多層防御を実現することにより、ほぼ常に打ち負かすことができます。単独で多くの脅威を倒します。したがって、システムのiptablesルールが誤って誰かを許可した場合、SSHD証明書認証はそれらを締め出します。 SSHDサービスに欠陥がある場合、VPNは誰にも見られないようにします。 VPNとSSHDの両方に同時に欠陥がある場合、ファイアウォールルールにより、世界中のほとんどのIPアドレスがその試みを阻止し、ローカルと大規模なボットネットのみが脆弱性を悪用して攻撃できるようにします。出来るだけ早く。

したがって、もう一度言いますが、できる限り多くのレベルで多くの緩和策を講じます。未発見の脆弱性がある脆弱性と、それらが悪用される順序を事前に知ることはできません。

  • SSH v2のみを許可するようにしてください

    • sshd_config

      • プロトコル2

  • パッチを当てる

  • Iptablesを使用して、実際に使用するIPアドレスまたは範囲のみを許可する

  • UbuntuヘルプサイトのSSH/OpenSSH /設定ページ に従って、ユーザー名/パスワードではなく証明書によるアクセスのみを許可するようにSSHを設定します

    • sshd_config

      • PubkeyAuthenticationはい

      • PasswordAuthenticationいいえ

    • 暗号化されたホームディレクトリを使用する場合

      • AuthorizedKeysFile/etc/ssh /％u/authorized_keys

    • そうでない場合は、ホームディレクトリの通常の設定が機能します。

      • AuthorizedKeysFile％h/.ssh/authorized_keys

      • 過度のアクセス許可がないことを確認してください。

        • chmod 700〜/ .ssh

        • chmod 600〜/ .ssh/authorized_keys

        • chmod go-w〜

    • そして、できるだけ強力な証明書を設定します。キーの生成は UbuntuヘルプサイトのSSH/OpenSSH/Keysページでカバーされています

      • 私は、4096ビットのRSAキーまたは長い強力なパスフレーズを持つed25519キーから始めます。必ずローカルで生成し、プロンプトが表示されたら長く強力なパスフレーズを入力します。-oを使用して新しいOpenSSH 6.5の鍵形式を確認し、サーバーに公開鍵以外のものがないことを確認します。

        • ssh-keygen -o -t ed25519 -f〜/ .ssh/id_ed25519

        • ssh-keygen -o -b 4096 -t rsa -f〜/ .ssh/id_rsa

        • 既存のキーの長さを確認するには、ssh-keygen -e -f mykeyfileを使用します

    • 可能であれば、authorized_keysファイルのキーを特定のIPアドレスまたはホスト名のセットに制限します

    • OpenSSH 6.8以降を使用している場合は、 sshd_configで許可されたキーを特定のタイプに制限することができます

      • PubkeyAcceptedKeyTypes ssh-ed25519 *、ssh-rsa *

  • fail2ban を使用して、ブルートフォースの試行により多くの労力がかかるようにします（つまり、1台のマシンだけではなく、ボットネットを使用するか、長時間かかるようにします）。

    • 証明書（キー）のセットアップは、最初にどちらを行うかを尋ねる場合に優れています

  • ログイン猶予時間を短縮する

    • 証明書を使用している場合、非常に低速の接続を使用しない限り、証明書をWAYダウンするオプションがあります。

      • LoginGraceTime 8

    • それ以外の場合、まあ、どのくらい速くタイプしますか？

      • LoginGraceTime 20

  • Mozilla.org Security/Guidelines/OpenSSH の情報を使用して、暗号スイートの選択を制御します

    • それはあなたのサーバーであり、あなただけが入っているので、最新のクライアントだけが許可されるように非常に非常にタイトなグループを選択できます。たぶん

    • HostKey/etc/ssh/ssh_Host_rsa_key

      • Sudo ssh-keygen -o -N '' -b 4096 -t rsa -f/etc/ssh/ssh_Host_rsa_key

        • または

        • HostKey/etc/ssh/ssh_Host_ed25519_key

        • Sudo ssh-keygen -o -N '' -t ed25519 -f/etc/ssh/ssh_Host_ed25519_key

      • 明らかにHostKeyファイル名を正確に一致させてください！

        • または両方（最初に優先）

        • すべてのdsaキーを完全に削除します。 SSHの悲惨な1024ビットに修正されています

    • Ssh -Qディレクティブを使用して、システムが暗号スイートオプションに対してサポートするものを決定します。

    • KexAlgorithms [email protected]

    • 暗号chacha20-poly1305 @ openssh.com、aes256-gcm @ openssh.com、aes128-gcm @ openssh.com

    • MAC [email protected]

    • または、具体的な選択が最も安全だと感じること

    • そして、文学についていく。選択したものに欠陥がある場合は、その時点で既知の欠陥のないものを選択します。

  • I-blocklist のブロックリストでiptables（またはファイアウォール）を使用します

  • 地理的またはISPベースのIPリストでiptables（またはファイアウォール）を使用します。そのような地理的リストのソースの1つは maxmind.com です。

  • RFC6335 ごとに49152〜65535のダイナミック（エフェメラル）ポート範囲のポートに切り替えます

    • 必要なIPアドレスにのみバインドする

  • Iptablesを介してそのサーバー上の他のすべてのポートをブロックします。多くの攻撃に見舞われる可能性があります

    • 特にMySQLデータベースを強化します（ある場合）。IDSに対するMySQL（およびSQL Server）攻撃がたくさんあり、どちらも実行したり、ポートを開いたりしたことがありません。それらをローカルのルーティング不可能なIPのみなどに設定し、長いパスワードを設定し、無効にするなどします。

    • 特にWebサーバーを無効にして、ローカルのルーティング不可能なIPのみに設定します。

  • Ubuntuヘルプサイト または A DigitalOcean記事 に従ってポートノッキングを使用する

  • ServerFaultの質問「何百もの失敗したsshログイン」へのこの回答に対する、新しい接続試行のレート制限

iptables -A INPUT -p tcp --dport 22 -m Recent --update --seconds 60 --hitcount 5 --name SSH --rsource -j DROP

iptables -A INPUT -p tcp --dport 22 -m latest --set --name SSH --rsource -j ACCEPT

  • Debianのドキュメント「OpenSSH SFTP chroot（）with ChrootDirectory」 に従ってchrootを使用することを検討してください

  • Sshd_configオプションでrhostsが無効になっていることを確認します

    • IgnoreRhostsはい

    • RhostsRSAAuthenticationいいえ

    • RhostsAuthenticationいいえ

  • 認証前の非特権プロセスにさらに制限を追加する

    • UsePrivilegeSeparationサンドボックス

  • フォワーディングやトンネリングを使用していない場合は、sshd_configで無効にしてください

    • X11転送なし

    • AllowTcpForwarding no

    • GatewayPortsいいえ

    • PermitTunnelいいえ

  • ディレクトリまたは権限で他の安全でないセットアップを防止する

    • StrictModesはい

    • そして、それが再び機能するまで、あなたの許可と設定を調べてください:)

  • ホストベースの認証を無効にする

    • HostbasedAuthenticationいいえ

  • 「OpenSSHデーモンがServerKeyBitsディレクティブを無視する」に対するこのServerfaultの回答 に従って、最初のSSH v1を許可しないため、古いServerKeyBits sshd_configディレクティブは適用されなくなりました。場所。

  • Sshd_configでrootを許可しない

    • PermitRootLoginいいえ

  • 別のユーザー（おそらく、インストールするパッケージのサービスユーザー）に他のオプションを許可しない

    • PermitUserEnvironmentいいえ

  • pfSense または Ubiquiti Edgerouter Lite のような個別のオールアップファイアウォールをそのマシンと外界の間にインストールします。

    • そして、組み込みのVPNを使用しますさらに強化されたSSHログイン

    • また、ユーザー名/パスワードベースのログインではなく、証明書ベースのログイン

    • OpenVPNを使用している場合

      • --tls-auth "ta.key"事前共有鍵も必ず使用してください

      • デフォルトよりも優れた暗号を選択します

    • そして、このレベルでも上記のブロックリストを使用します

DeerHunterが述べたように、他の方法なしでsshやiptablesやその他のファイアウォール設定を変更すると、SSHを実行できない可能性があります。

18
Anti-weakpasswords

どうぞ：

  • Generete SSHキー+パスワードでそれらを保護
  • 特定のユーザーのみにログインを許可する（AllowUsers）
  • 特定のIPユーザー名から許可する@ 192.168.1.1
  • デフォルトのポートを変更する
  • ファイアウォールルールを作成する
  • そして最後にfail2banをインストールします。
3
Mirsad

あなたはその特定のIPを正常にブロックしましたが、何千ものそのような悪意のあるコンピューターがあなたのsshを強引に押し込もうとしてボックスに侵入しようとしていることを私に話させてください。

いくつかのヒント：

  • パスワードよりも証明書による認証に切り替える
  • デフォルトのsshポートを変更します（これは非常に便利です-デフォルトは22です）

下位レベルのヒント：

0
Silverfox