OpenSSHのバグにより攻撃者が短時間で数千のPW推測を可能に。ネットに公開されたsshアカウントのブルートフォースが可能に。通常はOpenSSHは3から6回のログイン試行しかできない。攻撃方法の詳細有り。公開鍵暗号鍵の利用が推奨http://t.co/yzmMfdYHWx
— 高梨陣平 (@jingbay) 2015, 7月 21
PasswordAuthentication yes
ChallengeResponseAuthentication yes
となっているときに、攻撃が成功するというものです。FreeBSD は ChallengeResponseAuthentication が標準で yes になっているので、標的となる可能性が高いようですが、CentOS/RHEL系は、ChallengeResponseAuthentication が標準で no なので、この攻撃は成功しないようです。
ということで、念のためサーバ設定を確認しておくことをお勧めします。一番はパスワード認証を許可しないことですね。もちろん
PasswordAuthentication no
ChallengeResponseAuthentication no
にする前に、公開鍵認証でログインできるようにしておかないと、ログインできなくなっちゃいますけど。
[追記]:
KbdInteractiveAuthentication
Specifies whether to allow keyboard-interactive authentication. The argument
to this keyword must be “yes” or “no”. The default is to use whatever value
ChallengeResponseAuthentication is set to (by default “yes”).
KbdInteractiveAuthentication が個別に設定されている例もあるかも?
ChallengeResponseAuthentication no
KbdInteractiveAuthentication yes
では影響を受けず、
ChallengeResponseAuthentication yes
KbdInteractiveAuthentication no
なら、影響を受けるようです(結局 ChallengeResponseAuthentication 次第? KbdInteractiveAuthentication の存在意義は……)
Reddit についてるコメントも参考になりますね。
OpenSSH keyboard-interactive authentication brute force vulnerability (MaxAuthTries bypass)
http://www.reddit.com/r/netsec/comments/3dnzcq/openssh_keyboardinteractive_authentication_brute/
[追記その2]:
1つ指摘頂きました。
@kunitake Linuxの場合チャレンジレスポンス認証はPAMを使うので、UsePAM yesも成功条件ですね。noにするとチャレンジレスポンス認証がコケちゃいますw
— no root, nobody (@togakushi) 2015, 7月 22
ChallengeResponseAuthentication yes
の場合でも、UsePAM が no であれば、同じパスワードでのログイン不可となるので、攻撃に成功しないよということになります。より具体的には、ozumaさんが表にまとめられている通り、下記の3つのケースで成功しません。
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM no
Also see: sshd_config(5)
IPv4/IPv6 meter |
思ったより安い……時もある、Amazon |