SSHサーバー周辺のセキュリティが完全に不浸透であることを確認するために、どのような対策を講じることができますか?
これは最初からコミュニティWikiになるので、サーバーを保護するために人々が何をするかを見てみましょう。
SSHサーバー周辺のセキュリティが完全に不浸透であることを確認するために、どのような対策を講じることができますか?
これは最初からコミュニティWikiになるので、サーバーを保護するために人々が何をするかを見てみましょう。
回答:
パスワードではなく公開/秘密キーのペアを認証に使用します。
サーバーにアクセスする必要があるすべてのコンピューターについて、パスフレーズで保護されたSSHキーを生成します。
ssh-keygen
許可されたコンピューターからの公開鍵SSHアクセスを許可します。
~/.ssh/id_rsa.pub
各コンピューターの内容を~/.ssh/authorized_keys
サーバー上の個々の行にコピーするか、ssh-copy-id [server IP address]
アクセスを許可するすべてのコンピューターで実行します(プロンプトでサーバーのパスワードを入力する必要があります)。
パスワードSSHアクセスを無効にします。
開いて/etc/ssh/sshd_config
、言う行を見つけて、#PasswordAuthentication yes
それをに変更しPasswordAuthentication no
ます。SSHサーバーデーモンを再起動して、変更を適用します(sudo service ssh restart
)。
現在、サーバーにSSHで接続する唯一の方法は、の行に一致するキーを使用すること~/.ssh/authorized_keys
です。この方法を使用すると、ブルートフォース攻撃については気にしません。パスワードを推測しても拒否されるためです。今日のテクノロジーでは、公開キーと秘密キーのペアを総当たり攻撃することは不可能です。
私はお勧めします:
総当たりログイン試行を防ぐためにfail2banを使用します。
SSH経由でのルートとしてのログインを無効にします。これは、攻撃者がユーザー名とパスワードの両方を把握して、攻撃をより困難にする必要があることを意味します。
に追加PermitRootLogin no
します/etc/ssh/sshd_config
。
サーバーにSSH接続できるユーザーを制限します。グループ別または特定のユーザーのみ。
サーバーにSSHできるAllowGroups group1 group2
ユーザーAllowUsers user1 user2
を追加または制限します。
他の回答はセキュリティを提供しますが、ログをより静かにし、アカウントからロックアウトされる可能性を低くするためにできることが1つあります。
サーバーをポート22から別のポートに移動します。ゲートウェイまたはサーバーのいずれかで。
セキュリティは向上しませんが、すべてのランダムなインターネットスキャナーがログファイルを乱雑にしないことを意味します。
2つの要素認証を有効HOTPまたはTOTPを。これは、13.10以降で利用できます。
これには、ここでの別の回答のようにパスワード認証よりも公開キー認証を使用することも含まれますが、ユーザーは自分の秘密キーに加えて第2要素デバイスも保持していることを証明する必要があります。
概要:
sudo apt-get install libpam-google-authenticator
各ユーザーにgoogle-authenticator
コマンドを実行して~/.google-authenticator
もらい、2要素デバイス(例:Google Authenticator Androidアプリ)を生成して構成を支援します。
編集/etc/ssh/sshd_config
および設定:
ChallengeResponseAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey,keyboard-interactive
を実行sudo service ssh reload
して、への変更を取得します/etc/ssh/sshd_config
。
行を編集/etc/pam.d/sshd
して置換します。
@include common-auth
で:
auth required pam_google_authenticator.so
さまざまな設定オプションの詳細は、昨年の私のブログ投稿です。Ubuntuでの2要素ssh認証の改善。
正しいログイン情報の提供に失敗したクライアントIPをsshdがブロックするようにします。「DenyHØsts」はこのジョブを非常に効果的に実行できます。私はこれをすべてのLinuxボックスにインストールし、何らかの形で外部からアクセスできるようにしました。
これにより、SSHDに対する強制攻撃が有効にならないようになりますが、パスワードを忘れた場合にロックアウトされる可能性があることを覚えておいてください(!)。これは、アクセスできないリモートサーバーで問題になる可能性があります。
簡単な1つの方法があります。ufw(「複雑でないファイアウォール」)をインストールし、それを使用して着信接続のレート制限を行います。
コマンドプロンプトから次のように入力します。
$ sudo ufw limit OpenSSH
場合UFWがインストールされていない、これを実行して、再試行してください:
$ sudo aptitude install ufw
多くの攻撃者は、パスワードをブルートフォースするためにSSHサーバーを使用しようとします。これにより、同じIPアドレスから30秒ごとに6つの接続のみが許可されます。
私はいくつかの追加のセキュリティを持ちたいか、いくつかの企業ネットワークIセットアップの奥深くSSHサーバーにアクセスする必要がある場合は隠されたサービスを匿名化ソフト使ってTorのを。
localhost
。/etc/tor/torrc
。設定HiddenServiceDir /var/lib/tor/ssh
しHiddenServicePort 22 127.0.0.1:22
ます。var/lib/tor/ssh/hostname
。のような名前がありd6frsudqtx123vxf.onion
ます。これは、非表示のサービスのアドレスです。$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でのみポートを開きます。だから、だれも「通常のインターネット」経由で接続することはできません。
このトピックに関するDebian管理の記事があります。基本的なSSHサーバー構成とファイアウォールルールについても説明します。これは、SSHサーバーを強化する場合にも興味深い場合があります。
記事「SSHアクセスを安全に保つ」を参照してください。
SSH強化に対する私のアプローチは...複雑です。次の項目は、ネットワークの最も端の境界からサーバー自体に至るまでの、その方法に関するものです。
ブロックリスト内の既知のサービススキャナーとシグネチャを使用したIDS / IPSを介したトラフィックの境界レベルフィルタリング。 私はボーダーファイアウォールを介してSnortでこれを実現しています(これが私のアプローチ、pfSenseアプライアンスです)。VPSの場合など、これができない場合もあります。
SSHポートのファイアウォール/ネットワークフィルタリング。 特定のシステムがSSHサーバーに到達することのみを明示的に許可します。これは、ネットワークの境界にあるpfSenseファイアウォールを介して行われるか、明示的に構成されている各サーバーのファイアウォールを介して行われます。ただし、これができない場合があります(プライベートペンテストや、ファイアウォールでは物事のテストが助けられないセキュリティテストラボ環境を除き、ほとんどそうではありません)。
私のpfSense、または内部ネットワークをNATし、インターネットおよびシステムから分離している境界ファイアウォール、サーバーへのVPNのみのアクセスと組み合わせて。VPNをネットワークに接続してサーバーに接続します。インターネットに直接接続するポートは存在しないためです。これは私のすべてのVPSで確実に機能するわけではありませんが、#2と組み合わせて、そのサーバーにVPNすることで1つのVPSを「ゲートウェイ」にして、他のボックスへのIPを許可することができます。そうすれば、SSHを使用できるかできないかを正確に把握できます。これが、VPNという1つのボックスです。(または、pfSenseの背後にある私のホームネットワーク、VPN接続、および私はVPNアクセスを持つ唯一のものです)。
#3が実行できない場合、4回の試行失敗後にブロックし、1時間以上IPをブロックするように構成された fail2banは、ブルートフォーシングで絶えず攻撃している人々に対するまともな保護です。ただし、fail2banの設定は苦痛です...
SSHポートを変更することによるポートの難読化。 ただし、これは追加のセキュリティ対策なしで行うことは得策ではありません。多くの場合、「セキュリティを介したセキュリティ」のスローガンは既に反論され、議論されています。IDS / IPSおよびネットワークフィルタリングと組み合わせてこれを実行しましたが、それ自体で行うのは非常に悪いことです。
Duo Securityの2要素認証ソリューションを介した必須の2 要素認証。 SSHサーバーにはすべてDuoが構成されているため、2FAのプロンプトが表示されるため、各アクセスを確認する必要があります。(これは究極の便利な機能です。誰かが私のパスフレーズを持っているか、侵入したとしても、Duo PAMプラグインをすり抜けることができないためです)。これは、SSHサーバーでの不正アクセスに対する最大の保護の1つです。各ユーザーログインはDuoの構成済みユーザーに結び付けなければなりません。また、制限セットがあるため、システムに新しいユーザーを登録できません。
SSHを保護するための2セント。または、少なくとも、アプローチに関する私の考え。
Google認証システムを使用する代わりに、RedHatからFreeOTPアプリをチェックアウトすることもできます。アプリを更新すると、ロックアウトされる場合があります!;-)
YubikeyやeToken PASSまたはNGなどの他のハードウェアトークンを使用する場合、または多数のユーザーまたは多数のサーバーがある場合は、オープンソースの2要素認証バックエンドを使用できます。
最近、これを行うための小さなチュートリアルを書きました。基本的に、PKIを使用する必要があります。また、私のチュートリアルでは、セキュリティをさらに高めるために2要素認証を使用する方法も示します。これらのどれも使用しなくても、弱い暗号スイートやその他の基本を削除することでサーバーを保護することについてのちょっとしたヒントもあります。https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/
多数のユーザー/証明書については、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
geoIPデータベースを使用して、原産国に基づいてブロックすることもできます。
基本的に、米国に住んでいる場合、ロシアの誰かがあなたのSSHに接続する理由はないので、彼らは自動的にブロックされます。
スクリプトは次の場所にあります:https : //www.axllent.org/docs/view/ssh-geoip/
また、iptablesコマンドを追加して(ドロップレットに追加しました)、それらのIPとの間のすべてのトラフィックを自動的にドロップすることもできます。