WiKID二要素認証でSSHデプロイメントを保護する

SSHは、サーバーのリモート管理のための非常に安全なチャネルを提供します。しかし、Visa/Mastercard PCIなどの規制やビジネス要件の監査に直面する場合、監査で頭痛の種となる可能性のあるいくつかの認証関連の短所を認識しておく必要があります。例えば：

公開鍵認証を持つユーザーを制御する方法がない
パスフレーズの複雑さを強制する方法がない（または、使用されていることを確認することもできない）
公開鍵を期限切れにする方法がない

この文書では、WiKIDの二要素認証をSSHゲートウェイサーバーとホストされた秘密鍵と組み合わせて、非常に安全で監査可能かつ使いやすいリモートアクセスソリューションを作成する方法を示します。WiKID強力認証システムは、商業用/オープンソースの二要素認証ソリューションです。まず、WiKIDサーバーにドメインを設定し、次にサーバーをWiKIDサーバーにネットワーククライアントとして追加し、最後にゲートウェイボックスとターゲットサーバー（この場合はFedora Core 6サーバー）を設定します。

WiKIDサーバーにドメインを追加する

ドメイン作成

ネットワーククライアントを作成する

ドメイン情報を保存した後、ネットワーククライアントタブをクリックし、新しいネットワーククライアントを作成をクリックします。このクライアントの名前と、内部ネットワーク上のSSHゲートウェイのIPアドレスを入力します。プロトコルとしてRadiusを選択し、上で作成したドメインを選択します。

ネットワーククライアント作成

クリックして

追加

次のページに進み、Radiusの共有シークレットを入力します。

ネットワーククライアント作成2

ネットワーク上の各サーバーについてこのプロセスを繰り返す必要があります。

SSHゲートウェイを設定する

次に、中央SSHゲートウェイを設定します。このLinuxボックスは、ファーム内のすべてのプロダクションサーバーへのゲートウェイ/プロキシです。余分なソフトウェアやサービスが実行されないように厳重にロックダウンする必要があります。外部接続用の外部インターフェースと、内部接続用の内部インターフェースを持つ必要があります。まず、SSHユーザーの強力な認証にWiKIDを使用するようにゲートウェイボックスを設定します。/etc/pam.d/sshdファイルを次のように編集します：

#%PAM-1.0   
auth       sufficient   /lib/security/pam_radius_auth.so   
auth       include      system-auth   
account    required     pam_nologin.so   
account    include      system-auth   
password   include      system-auth   
session    include      system-auth   
session    required     pam_loginuid.so

WiKIDサーバーを/etc/raddb/serverファイルに追加し、WiKIDサーバーの内部IPアドレスとネットワーククライアント作成ページで入力した共有シークレットを使用します：

# server[:port] shared_secret      timeout (s)   
127.0.0.1       secret             1   
xxx.xxx.xxx.xx  wikidserver_secret 3

SSH設定にもセキュリティを追加しましょう。/etc/ssh/sshd_config（近くのssh_configファイルではなく）を開き、次の設定オプションを追加します：

#Protocol 2,1   
#Check that only protocol 2 is allowed:   
Protocol 2   
#Disallow root login:   
PermitRootLogin no   
#Disallow accounts without passwords:   
PermitEmptyPasswords no

ポートを変更したい場合は変更できます。攻撃者を止めることはできませんが、スクリプトキディによって引き起こされるログイベントを減らすことができるかもしれません。このゲートウェイボックスは、SSH認証にWiKIDのワンタイムパスワードを使用するように設定されています。すべてのユーザーはWiKIDサーバーに登録されている必要があり、誰もrootとしてログインすることはできません。このボックスを離れる前に、少し異なることを行います - ユーザーにゲートウェイ上でRSA秘密鍵を作成させます。各ユーザーがWiKIDでボックスにサインインしたら、彼らにキーを作成させます：

ssh-keygen -t rsa

私の意見では、これらのキーのパスフレーズは冗長です。これらは、サーバーファームへのシングルサインオン機能を作成するためだけに存在します。明らかに、ユーザーが他のキーにアクセスできないように注意する必要があります。

ターゲットサーバーを設定する

明らかに、これらのサーバーはゲートウェイからのSSHリクエストのみを受け入れるように設定します。これは、ポート22のアクセスを内部アドレスに制限することで行います。/etc/sysconfig/iptablesを編集し、ポート22のSSHの行を追加または編集します：

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 192.168.1.0/24 --dport 22 -j ACCEPT

おそらく、公開鍵認証を許可する標準のsshd_configのセットアップを使用できます。これで完了です！

結論

リモートSSHは現在非常に安全です。WiKIDサーバーからワンタイムパスコードを取得せずに、サーバーファームにアクセスできるユーザーはいません。認証の二要素は、WiKIDトークン（およびその暗号鍵）の所有とPINの知識です。PINはWiKIDサーバーで検証されるため、ユーザーを無効にするのは非常に簡単です。すべてがログに記録され、監査人は非常に満足するはずです。

さらに、内部マシンでのrootアクセスにWiKIDのワンタイムパスコードを要求することもできます。su用の新しいドメインを作成し、/etc/pam.d/suを適切に編集します。これにより、サーバーを管理のために異なるグループに分けることもできます。たとえば、特定の管理者のみがrootアクセスを持つHR用のサーバーセットがある場合、特定のWiKIDドメインに設定でき、細かいアクセス制御と強力な認証を可能にします。WiKIDウェブサイトから二要素認証に関する詳細情報を入手してください。