技術者ブログ

はじめに

ソースIPを詐称したSYNパケットを1つだけ踏み台サーバーに送ることにより、再送されるものを含め、数回SYN-ACKパケットが攻撃対象に送られてしまうのがSYN-ACKリフレクション攻撃です(※1)。あなたが(クラウド/オンプレミス問わず)サーバをOSレベルで管理している場合には、そのサーバが踏み台にされている可能性が非常に高いです。今回は私達が行った「踏み台にされないための」対策について紹介します。

ただし残念なことに、このブログで紹介する対策は万全な形ではなく、一部の種類の攻撃については対策が不完全であることを先に記しておきます。

踏み台にされているか?

ある時点で自分が管理しているサーバがSYN-ACKリフレクション攻撃の踏み台にされているかどうかを判断するには、netstatやssコマンドを使って「SYN-RECV」な状態のソケットの一覧を確認します。ssの場合には

ss state syn-recv

とします。

正常なTCP通信であれば3wayハンドシェイクはあっという間に完了するため、上記ssコマンドで確認できるSYN-RECVな状態のソケットはそれほど多くないはずです。また、仮に見つかった場合でも、1〜2秒後には消えるはずです。

しかし数秒あけてから再度ssコマンドを実行しても、SYN-RECVなままなソケットがある場合があります。この場合、踏み台にされている可能性が極めて高いです。

さらにSYN-RECVとなっているIPアドレスを調べ、それがそのサーバにおいて普段あまり通信が発生しないような海外のISPである場合には、ほぼ確実にSYN-ACKリフレクションであると言えるでしょう。

最近になり急増?

実は私もそれほど状況を把握しているわけではありませんが、去年の11月頃に比べ、今年の3月には私の管理しているサーバのうち、とても多くの割合でサーバが踏み台にされていることに気づきました。サーバの場所はIIJ系/GMO系/AWS/さくらインターネット等で、利用しているサービスによらず広い範囲が踏み台にされています。

攻撃の状況についてはIIJさんが詳しく、

https://twitter.com/MasafumiNegishi/status/1238050649129938947

https://wizsafe.iij.ad.jp/2019/12/839/

などが参考になります。

余談ですが、私はこの攻撃については2019年のCODE BLUEで知りました。何となく、たまにnetstatを実行したときにSYN-RECVが多くて変だな、と感じていたのですが、上記wizsafeの情報をまとめている守田さんのセッションで「ぐぇー、これだったのか！」と知ったという状態です。

原理的には防げない

非常につらいことに、ネット上でTCPでサーバを運用しているならば、基本的にはこの攻撃の踏み台にされてしまうことは避けることができません。SYNが来たらSYN-ACKを返すのは当たり前ですし、SYNパケットのソースIPが偽装されているかを届いた側で判断することはできないからです。

対策1: 再送を減らす

そこで、せめて攻撃の効率を悪くするため、まずSYN-ACKの再送の回数を減らすのが対策の1つとなります。Linuxサーバであれば

/proc/sys/net/ipv4/tcp_synack_retries

を0〜2くらいの数値に減らすことが考えられます。おそらくデフォルトでは5になっているサーバが多いと思いますが、例えば5から2に減らした場合には、攻撃に加担してしまうパケットを6から3に減らすことになり、つまりリフレクションの率を半減させることができます。

もちろん副作用として正常なクライアントがとても状態の悪いネットワークからアクセスしようとするときに影響があるかもしれませんが、一般的な日本の国内のインターネットであれば問題ないのではないかと私個人としては思います。

対策2: しつこく攻撃対象となっているIPを特定して遮断する

この攻撃の対象になっているアドレス(=SYNパケットのソースIP)は、ある程度の期間ずっと固定されていることがあります。これは「誰かがどこかを明示的に攻撃している」状態であればまぁそうなるだろう、と納得できます。

この場合、先に書いたようなssコマンドで調べてみると、数分から数時間、常に同じアドレスがSYN-RECVとなっており、これらのアドレスを収集することでリスト化することができます。このリスト化されたIPについて、全てiptablesでDROPします(※2)。

この場合、誤って正常なアドレスをiptablesでDROPするように設定してしまうと正常通信の妨げ、障害になってしまうため、気をつける必要があります。

私達の場合、サーバの数がそこそこ多いので、全サーバから数分おきにアドレスを中央サーバに収集し、「N個以上のサーバで観測された、明らかに攻撃対象となっているIPアドレス」について、各サーバが情報をダウンロードして、それぞれにおいてiptablesで拒否するようにしています(※3)。

この対策には抜けがあり、「ある程度の期間中、ずっと攻撃対象として固定されている」アドレスしか見つけることができません。実際には「単発で1度だけ来るアドレス」というのもあります。これは攻撃として成り立っているのかどうか、よくわからないものです。これらはSYNパケットだけを見て一瞬で攻撃かそうでないかを判断しなければならないため、現状では対策は難しいと考えています。

しかし、「ある程度の期間、固定されている」アドレスからのパケットをDROPするだけでも、我々の管理するサーバの数を考えれば、パケットの総数としてはかなりの数を(対策しない場合に比べて)送らずに済んでいるので、それなりにやり遂げた感はあります。

見て見ぬフリもアリなのか?

そもそも、この攻撃(踏み台になってしまうこと)は対策する必要があるのか？という議論のポイントがあります。それぞれの組織において、サーバ管理者を中心に、まずそこを議論するべきでしょう。プロトコル的には正しい挙動をしていますし、上記の対策2のような仕組みを作るのはそれなりに開発・運用コストが必要になります。

見て見ぬフリをするのもアリかもしれません。私も量が大したことない時点では基本的にそう考えていたのですが、3月になり増えたSYN-RECVの数の気持ち悪さと、今後さらに増えた場合にこちらのサーバのリソースが圧迫されたらイヤだな、という考えから、できる範囲での対応を行うことにしました。やはり(仕方がないとはいえ)攻撃に加担しているという状況は、長年サーバ管理者をやっている身としては気持ちが悪いものです。

私達が管理するサーバは数は多いですが構成は殆どが同じであるため、上記対策2のような「アドレス収集」や「アドレスをダウンロードしてiptables実行」する仕組みも開発してスムーズにデプロイできることも実行のモチベーションになりました。

まとめ

今回は私達が実施した、SYN-ACKリフレクションの踏み台にされないための対策について簡単に紹介しました。この攻撃の状況や原理を理解するためにIIJさんの情報に大変に助けられました。この場をお借りしてお礼申し上げます。ありがとうございます。

※1: 詳しくは「SYN-ACK Reflection」「SYN ACK リフレクション」などで検索してください。IIJさんが詳しいです。 ※2: Rejectにすると、その返答パケットもDDoSの一部になってしまいます。 ※3: Nの具体的な値については一応、伏せておきます。