できるだけ多くの緩和策を講じてください。
あなたの目標は、さまざまな潜在的な攻撃者に、より多くの労力、リソース、コンピューター時間 (したがって電気代)、そして特に「熟練した」(希少または希少であり、したがって価値のある) 人時間を費やさせることです。すべての脅威に対して機能する保護はありません。インターネットに接続したまま、すべての脅威を防御できるわけではありません。
ただし、多数の脅威 (スクリプト キディおよびスキルの低い攻撃者やリソースの少ない攻撃者) は、多層防御 (優れた堅牢なセキュリティの多層層) を使用することで、ほぼ常に打ち負かすことができます。多くの脅威を単独で打ち負かします。したがって、システムの iptables ルールが誤って誰かを許可した場合、SSHD 証明書認証はそれらを締め出します。 SSHD サービスに欠陥がある場合、VPN によって誰もそれを見ることができなくなります。 VPN と SSHD の両方に同時に欠陥がある場合、ファイアウォール ルールにより、世界中のほとんどの IP アドレスがそれを試みることさえできなくなり、ローカルおよび大規模なボットネットのみが脆弱性を試して悪用できるようになります。
したがって、繰り返しますが、できるだけ多くのレベルでできるだけ多くの緩和策を講じてください。どの脆弱性が発見されていないか、どの順序で悪用されるかを事前に知ることはできません。
-
SSH v2 のみを許可していることを確認してください
-
sshd_config
- プロトコル 2
-
-
パッチを適用してください
-
iptables を使用して、実際に使用する IP アドレスまたは範囲のみを許可します
-
Ubuntu ヘルプ サイトの SSH/OpenSSH/Configuring ページに従って、ユーザー名/パスワードではなく、証明書によるアクセスのみを許可するように SSH を設定します
-
sshd_config
-
公開鍵認証はい
-
パスワード認証番号
-
-
暗号化されたホーム ディレクトリを使用する場合
- 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 アドレスまたは一連のホスト名に制限してください
-
from="192.168.1.2" ssh-rsa ABCDE...012 [email protected]
-
from="*.test.test,!BadPC.test.test" ssh-ed25519ABCDE...012 [email protected]
-
-
OpenSSH 6.8 以降を使用している場合は、sshd_config で認証キーを特定のタイプに制限することもできます
- PubkeyAcceptedKeyTypes ssh-ed25519*,ssh-rsa*
-
-
fail2ban を使用して、ブルート フォースの試みにより多くの労力がかかるようにします (つまり、1 台のマシンだけではなくボットネットを使用するようにするか、長時間かかるようにします)
- 証明書 (キー) の設定は、どちらを最初に行うべきかを尋ねる場合に優れています
-
ログイン猶予時間を短縮
-
証明書を使用している場合は、非常に遅い接続を使用しない限り、証明書を大幅に下げるオプションがあります
- LoginGraceTime 8
-
そうでなければ、どのくらい速くタイプしますか?
- LoginGraceTime 20
-
-
Mozilla.org Security/Guidelines/OpenSSH からの情報を使用して、暗号スイートの選択を制御します
-
それはあなたのサーバーであり、あなただけが入ってくるので、最新のクライアントだけが許可されるように、非常にタイトなグループ化を選択できます.おそらく
-
ホストキー /etc/ssh/ssh_host_rsa_key
-
sudo ssh-keygen -o -N '' -b 4096 -t rsa -f /etc/ssh/ssh_host_rsa_key
-
または
-
ホストキー /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]
-
または、あなたが最も安全だと感じる特定の選択は何でも
-
そして文献についていく。選択したものに欠陥がある場合は、その時点で欠陥が知られていないものを選択してください。
-
-
I-blocklist のブロックリストで iptables (またはファイアウォール) を使用します
-
地理的または ISP ベースの IP リストで iptables (またはファイアウォール) を使用します。そのような地理的リストのソースの 1 つが maxmind.com です
-
RFC6335 に従って 49152 から 65535 の動的 (エフェメラル) ポート範囲のポートに切り替えます
- 必要な IP アドレスのみにバインド
-
iptables を介してそのサーバー上の他のすべてのポートをブロックします。多くの攻撃を受けている可能性があります
-
MySQL データベースがある場合は、特に強化してください。IDS に対する多数の MySQL (および SQL Server) 攻撃が見られますが、どちらも実行したことも、ポートを開いたこともありません。それらをローカル、ルーティング不可能な IP のみなど、長いパスワードに設定し、それらを無効にするなど。
-
特に Web サーバーを無効にし、それらをローカルのルーティング不可能な IP のみに設定するなどしてください。
-
-
Ubuntu ヘルプ サイトまたは DigitalOcean の記事に従って、ポート ノッキングを使用してください
-
ServerFault の質問 "Hundreds of failed ssh logins" に対するこの回答に従って、新しい接続試行のレートを制限します
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 recent --set --name SSH --rsource -j ACCEPT
-
Debian ドキュメント「OpenSSH SFTP chroot() with ChrootDirectory」に従って chroot の使用を検討してください
-
sshd_config オプションで rhosts が無効になっていることを確認してください
-
はい
-
RhostsRSA認証番号
-
Rhosts認証番号
-
-
事前認証の非特権プロセスにさらに制限を追加
- PrivilegeSeparation サンドボックスを使用する
-
フォワーディングまたはトンネリングを使用していない場合は、sshd_config で無効にしてください
-
X11フォワーディングなし
-
AllowTcpForwarding いいえ
-
ゲートウェイポート番号
-
PermitTunnel 番号
-
-
ディレクトリまたは権限でのその他の安全でない設定を防止する
-
StrictModes はい
-
そして、再び機能するまで、権限と設定を確認してください:)
-
-
ホストベースの認証を無効にする
- HostbasedAuthentication no
-
「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 で接続できなくなる可能性があります。
どうぞ:
- SSH キーを生成 + パスワードで保護
- 特定のユーザーのみにログインを許可する (AllowUsers)
- 特定の IP [email protected] から許可
- デフォルトのポートを変更
- ファイアウォール ルールを作成する
- そして最後に fail2ban をインストールします。