OnDemand Bastionについて基本的なところおさらい

CDP：OnDemand Bastionパターン

• 踏み台サーバを必要なときだけ起動して、使用しない時はサーバを落とすという、AWS界隈では当たり前なパターン。

実際にオンプレ頭の人たちとAWS上にシステム移行してみて

• サーバを止めるという考え方がそもそもない。
• 時間帯で自動停止、運用マニュアル等で周知徹底しても踏み台サーバを落とさない
• 逆に踏み台サーバが落ちると困るとかいう話も出てきた。orz
  • Auto Scallingを使用して絶対に1台サーバが上がっている状態を維持(EIP付け替え？ELB?)
    • あれ？このパターンってCDPにない？

じゃあ、踏み台サーバを出来るだけセキュアにしますか！

１. sshポート変更
２. SGにてsshポートだけ許可

• sshを1024以上に設定してSGもそのポートのみ許可
  ３. sshと管理等に必要なデーモン以外は上げない
  ４. rootユーザでのログイン不許可
  • sshd_configにて以下の設定

   PermitRootLogin no

５. 公開鍵認証でのみログイン許可

• sshd_configにて以下の設定

  RSAAuthentication yes
  PubkeyAuthentication yes 
  AuthorizedKeysFile %h/.ssh/authorized_keys

６. パスワードのみのログインは許可しない

• sshd_configにて以下の設定

  PasswordAuthentication no

７. チャレンジレスポンス認証を不許可

• sshd_configにて以下の設定

  ChallengeResponseAuthentication no

８. rhost認証の不許可

• sshd_configにて以下の設定

  RhostsRSAAuthentication no

９. 踏み台はあくまで踏み台、sshトンネルで該当サーバにログインし、踏み台に直接ログインしない

• ssh -N -L ポート番号:ホスト:ホスト側ポート番号
  １０. sshプロトコル2のみ許可する
• sshd_configにて以下の設定

  Protocol 2

１１. ec2-user以外のログインユーザ、sudoユーザを作成し、ec2-userを削除
１２. sudoユーザの限定
１３. sudo出来るユーザで実行できるコマンドの最小化

で、どれを実装すればいいの？の考察

上記項番をそのままに
１. 【◎】これは普通に実装した方がよいだろう。sshのポートは1024以上の任意のポートにする。（ポートスキャンは大抵Well-knownポートに限られる）
２. 【◎】SGは１で設定したsshポートのみ許可する。繋げる端末のグローバルIPが決まっているなら、レンジかIPで指定するとよりよいだろう。
３. 【◎】sshや管理に必要なデーモン以外上げないというのは、オンプレでは割とセオリーで、必要なときは徹底して必要なパッケージしか入れないという状態にしていた。不要なデーモンは止めておくだけでとりあえずいいだろう。
４. 【◎】rootログイン不許可はほとんどのLinuxでそうなっている。Amazon Linuxはデフォルト。クラウドの場合、設定ファイルがそのままパラメタシートになる場合も多いので、明示的に

PermitRootLogin no

を記載してもいいかもしれない。
５. 【◎】公開鍵でのログイン許可はAWSのLinuxではデフォルトだが、４と同様にデフォルト値ではなく、明示的に設定するのもありだろう。

RSAAuthentication yes
PubkeyAuthentication yes 
AuthorizedKeysFile %h/.ssh/authorized_keys

６. 【◎】５と同様、この設定もデフォルト値。明示的に設定するのもあり。

PasswordAuthentication no

７. 【◎】チャレンジレスポンス認証はデフォルトで不許可になっている。
８. 【◎】rhostについてはデフォルト不許可になり、久しいがこれも明示的に設定する方がいいだろう。

  RhostsRSAAuthentication no

９. 【○】踏み台をトンネルにしなくてもよいが、トンネルすることで踏み台サーバ上で余計なオペレーションをしなくていい。サーバトラブルのほとんどは人的ミス（オペレーション）で生じている現状、トンネル運用が推奨。
１０. 【△】ssh2のみにするとsshのみしか対応していないクライアントは接続できない。よっぽどのことがない限り、この設定はしなくてもよいだろう。
１１. 【○】セキュリティ規約によっては、ec2-user等、クラウドでのログインユーザで有名なユーザは削除して別のユーザを作ったりする。鍵が奪われない限りは問題ないが、転ばぬ先の杖で実施しておいた方が安心だろう。
１２. 【○】１１に合わせてwheelグループに所属しているユーザの見直しをする。
１３. 【△】必要最低限の操作しか出来ないようにシンボリックリンクや障害になり得るコマンドを削除したりする。必要に応じて実装すればいいだろう。実際にそういったセキュリティ規約のところもある。

今回はssh周りに限定したが、じゃじゃ馬SELinuxを飼い馴らしたり、ログインタイムアウトを設定したり、コンソールタイムアウトを設定したり、様々な策は労せる。
ログレベルを強化して、検知を確実にするとか、そういうことも必須になってくるね。