HTTP/3のお話
IETFやGoogleは、Webの世界を発展させるためにはHTTP/HTTPSをもっと最適化させなければいけないと思っています。これは正しいです。
ただ、今考えられているHTTP over QUIC、これをHTTP/3と呼ぶ、と決まったらしいのですが。
インターネットのネットワークプロトコルを標準化する業界団体のInternet Engineering Task Force(IETF)が、これまで「HTTP-over-QUIC(hq)」と呼ばれていたプロトコルを「HTTP/3」という名称に変更すると発表しました。
技術的な説明は下記が詳しいです。
で、私なぞは基本サーバー屋だったのでネットワークのこのあたりのプロトコルスタックの話は読んでもなかなか頭に入ってこないのですが。このUDPを採用しているあたりに恐怖感があるのです。
UDPによる様々な攻撃
TCP/IPにおけるトランスポート層は、TCPとUDPがあることは有名です。アプリケーション層であるHTTPやHTTPSは、TCPにくるまれて送受信されています。
TCPは、セッションを確立しないと通信そのものが始まりません。その後も受け取ったかどうかの確認を行いながら通信を行い、終了確認まで行います。したがって、セッションを確立する手順を経ないでパケットを投げつけても、ファイアウォールなどで弾くことが可能です。セキュリティーの教科書的な考え方です。いろいろと理論はあるのですが今回は大雑把に説明します。
最近は、なんでもかんでもHTTPSでやろうというトレンドがあり、HTTPはできるだけなくそうというGoogleの意向もあり、HTTP over なんたらかんたら、という通信手順が非常に増えたのは実感できると思います。
一方で、UDPはセッションレスと呼ばれ一方的にパケットを投げつけても良いことになっています。有料のファイル転送ソフトウェアはUDPを使うことで、SCPやSFTP、FTP、CIFSを使うことに比べ数倍早く送ることができるようです。ただし、ファイアウォールでUDPのポートをオープンしておかないといけません。特にUDPはセッションを見ないので、インバウンドもアウトバウンドも両方通信できるようにしてあげる必要があります。ステートフルセッションの設定ができません。
さて、このUDPですが、UDP floodという攻撃が大変有名です。例を挙げていきます。
DNSリフレクション攻撃
下記にわかりやすい説明を置いておきます。
「DNSリフレクション（リフレクター）攻撃」とは？ | マルウェア情報局
UDPは、IPアドレスの詐称がTCPより簡単なので、ボットネットからたくさんのリクエストを53/UDPをオープンするDNSサーバーに大量に送り、攻撃対象のIPアドレスに大量のUDPレスポンスを返す。
流行当時は、オープンリゾルバ撲滅運動のようなものが起こりましたね実際。
オープンリゾルバ(Open Resolver)に対する注意喚起 - JPNIC
memcachedリクレクション攻撃
これは、当ブログでも過去説明しました。
GitHubとmemcachedとDDoS攻撃とAkamaiの件。きちんと理解する。 - orangeitems’s diary
UDPを開けっぴろげなmemcachedに、ガツガツget要求を投げ、またまた送信者を偽装する。GitHubはこれで大量のトランザクションを投げつけられAkamaiが救ったという件です。
memcachedをちゃんと閉じろ運動が起こりましたねこれも。
とにかくUDP使うなら何でも
まとまっている記事がありますので紹介しておきます。
リフレクション攻撃(アンプ攻撃）を防御する方法 | ブログ | 最新情報 | A10ネットワークス ロードバランサ｜アプリケーション配信｜プロキシ｜DDoS防御
このタイプの最も一般的な攻撃では、数百万もの無防備なDNS、NTP、SSDP、SNMP、その他のUDPベースのサービスを使用します。このような攻撃は、1.3TbpsのMemcachedベースのGithub攻撃など、記録的な大容量攻撃となっており、これらのDDoS攻撃の大部分を占めています。以下の図1のグラフは、2018年7月のある1週間において、DDoS攻撃の約73%がamp_flood（増幅かつフラッド型）だったことを示しています。こちらから、現在の攻撃プロトコルの頻度のチャートを確認できます。
UDPは送信者を簡単に偽装できる、ことから始まる無限のストーリーです。
今回、HTTP/3がUDPを使うと聞いて、かなりの不安を持っています。何番を使うかは知りませんが、UDPを待ち受けるサービスなど無くなってしまえばいいのにと個人的には思っておりました。
LAN内のセキュアなネットワークならともかく、インターネットでUDPをANYにオープンするサービスが増やすのはどうなんだろう－－－。
ファイアウォールで閉めればいいは間違い
UDP floodを食らったシステム運用者はわかるはずです。
ファイアウォールは無力です。
数Gbps～数十Gbpsのトランザクションを一方的に投げられたら、ルータのCPUが100％になって、正常な通信ができなくなります。
Akamaiなど、CDN業者の超広帯域で吸収してやらないと攻撃を回避できないのは有名な話です。上のGitHubの話などがそうです。
一方で、Youtubeを持つGoogleや大量の通信をさばくCDN業者が、UDP通信をHTTPSの世界に適用することへの魅力もよくわかります。彼らもUDP Floodに対しては何か知恵があるのでしょう。ただし、そこまでは現在情報が公開されていないように見受けられます。
私がシステム運用を行う際には絶対にUDPのインバウンド通信は通してませんが（リフレクションの踏み台にならないために）。
ハラハラしながらこの件の進展を待ちたいと思います。
追記（2018/11/14）
最新のドラフトを見つけましたが、なかなか読み込むのが大変そう。ConnectionとかStateとかいう表現を捉えるに、UDPにTCPが持つトランザクション系の一部機能をくるんで、アプリケーション側に管理させようとしているように見えますが・・。
追記2（2018/11/14）
いい使い方に気が付いたのでメモ。
