攻撃が継続中
つい先日GitHubが標的となったmemcachedを踏み台としたUSB flood攻撃だが、まだ攻撃の手は緩んでいない。
コードリポジトリサービスを手がけるGitHubが過去最大規模となるDDoS攻撃を受け、一時サービス停止に追い込まれた1週間後、米国のあるサービスプロバイダーが同じ手法を用いたさらに大規模な攻撃の標的になった。
DDoS攻撃対策ソリューションを手がけるArbor Networksによると、この米サービスプロバイダーは攻撃によるサービス停止を免れたが、攻撃規模は過去最大となる1.7Tbpsに達したという。
GitHubに対する最大1.35Tbpsの分散型サービス妨害（DDoS）攻撃を発生させた分散型メモリキャッシュ「memcached」の悪用を試みる通信は、国内でも多数検知されていることが分かった。インターネットイニシアティブ（IIJ）が3月6日、観測状況を発表した。
考察
ここ最近、別件でもいろいろなアクセス攻撃が起きており、関連までは公開されていないもののこういった報道が相次ぐと憶測まで生んでしまう。1Tbitsの攻撃にさらされるとユーザー側では本当に何もできない。根本解決まで業界関係者は気を抜いてはいけない状況であると思う。
とにかく今回の攻撃は、memcachedがオープンしている11211/UDPポートをインターネットに対して塞がないと収束しない。インターネットにサーバーを構築している関係者は踏み台にされていないか再度、IIJの報告の通りファイアウォールの設定の見直しを行う必要があると思う。
また、踏み台にされているとすれば、データセンターからインターネットへの通信量が急増しているはずである。AWSではCloudWatchが提供されているが、他の環境でも通信量は料金に絡んでいるので見られるようになっているはずだ。何しろインターネットでmemcachedを使っている人は限られると思うので、各自で気を付けなければいけない問題と思う。また、通信料金にも跳ね返ってくるので注意したい。
そのうえで、もし収束しないようであればインターネットからデータセンターに来る、「宛先ポートが11211/UDPのもの」を全て、データセンター側で閉じなければいけないと思う。クラウドベンダーなど、インターネット通信を共用しているサービスであれば、対応できると思う。
こういった対応は、スパムメール問題の件で先行事例がある。データセンター内部から、送信元ポート25/TCP（SMTP）の通信は、全て閉じるホスティング・クラウド業者は多い。その代わりにデータセンターが用意・推奨するメールサーバーに一度587/TCPポートなどを使って暗号化してリレーし、スパムと判定されるメールはリレー先で拒否するなどの対応を取っている。
例えばAzureは、基本的にSendGridというサービスにリレーさせることを基本としている。
Azure VM からのメール送信に関するアナウンス (2017 年 11 月) – Japan Azure Technical Support Engineers' Blog
このように、明らかに攻撃のルートとなるような通信は、サーバー管理者ではなくデータセンター事業者単位あるいはインターネットキャリア側で止めてしまう施策が必要となってくる。攻撃が止んでいない以上、即座に実施することを検討するレベルだと思う。
※どんなに国内で対応しても海外からUSB floodが飛んで来たらどうしようもないので、このあたりはキャリアの対応を祈るしかないですが・・。
今のインターネットもすきを見せればこのように、地球単位の攻撃まで発展するという殺伐な状況にある。利用者はそれをふまえ、ファイアウォールについては責任をもって実装するようにしてほしいと願う。
