SSHが認証していない鍵交換セッションでメモリを浪費する問題(CVE-2016-8858)はSWANStorには直接の影響はありませんが、SWANStorゲートウエイを運用されているお客様は注意をする必要があります。
この問題は、SSHのプロトコルと関係する問題です。SSHは概ね次のような手順でデータの交換を行います。
１）TCPセッションの開始
２）暗号化に関わる方式（アルゴリズム）として利用できるもののリストを通知、また相手から受け取る
３）アルゴリズムの選択と決定
４）選択されたアルゴリズムで認証、データの交換
お互いにアルゴリズムが選択できなかったり（例えば鍵交換アルゴリズムとしてお互い共通して利用できるものがない）、認証に失敗した場合、
その時点で即座に１）で開始されたTCPセッションは切断されますが、CVE-2016-8858の問題は、例えば悪意をもったSSHクライアントが上記２）の段階で処理を止めるという処理を次々に新しく行うと、SSHサーバは２）で確保したメモリをそのまま保持続けるためにメモリがどんどん消費されつづけてしまい、システムの動作に影響を及ぼす可能性があるというものです。
この問題は、OpenSSHの以下のバージョンに影響するようです。
openssh-6.8p1, openssh-6.9p1, openssh-7.0p1, openssh-7.1p1, openssh-7.2p1, openssh-7.3p1
2016年11月4日現在公式なパッチは出ていませんが、簡単な修正で解消できるようなので、間も無くパッチ提供の報告も出るものと思われます。
ところで、RedHatのセキュリティチームとしては、sshdにはいくつもの防御機能が既に備わっているため、この問題はセキュリティ脆弱性ではないと考えているそうです。その防御機能の一つが/etc/ssh/sshd_config にあるMaxStartupパラメータだということで、これについて本稿でご紹介させていただきます。
このデフォルト値は10:30:100となっていますが、この意味は
SSHサーバは、３）４）の手順に進む前の２）の接続を最大100まで受け付けるが、最初の10を超えた新たな接続は30％の確率で受付拒否する
というものです。
SWANStorゲートウエイのようなLinuxサーバの運用管理ではsshが欠かせないツールですが、サーバのsshポート（ポート22）を目掛けて至る所からの攻撃を受けているはずです。その攻撃は手順４）で認証エラーになるはずですが、パスワードを取替えひっかえ執拗にリトライするブルートフォース攻撃を受けているかも知れません。
しかし、OpenSSHではMaxStartupの機能によって、この攻撃に制限をかけることができます。例えば、MaxStartupの設定値を2:80:5にしてしまえば、SSHの開始セッションはほぼ２個に制限されてしまい、ブルートフォース攻撃を緩和することができます。
ただしこの値は、Linuxサーバ監視をSSHを使って情報を取得したり、SCPでファイル交換をする役割のサーバの場合、値を小さくしてしまうことで問題が発生する可能性があるので、運用方法やサーバ用途で慎重に決定する必要があります。また、値の変更はSSHDの再起動後に反映されます。
なお、弊社が運用しているSWANStorゲートウエイをはじめとするLinuxサーバは、SSHの接続元をIP制限しているため、本問題の影響はないものと考えています。