これまでのあらすじ。20個の AWS EC2 のサーバーが Googlebot にモシャスして、妻の WordPress の xmlrpc.php を攻撃。哀れ、うちら夫婦のサーバーはダウンしてしまった。
ネットワーク ACL を使って、20個のサーバーの IP アドレスをギッタギタのメッタメタにブロックしてやる。おでっせい（筆者）の反撃がはじまる。
AWS でのファイアウォールの考え方
※筆者は AWS において、網元（AMIMOTO）AMI を用いてサーバーを構築しており、以下の記載も網元 AMI によって構築した Amazon Linux に沿ったものとなっています。お使いの AWS のサーバーとなんだか違っていても、あらかじめご了承ください。
Linux のファイアウォールというと iptables と教わったけれど、Amazon Linux には /etc/sysconfig/iptables ファイルが存在せず、ファイアウォールは起動していない。
# /etc/init.d/iptables status
iptables: ファイアウォールが稼働していません。
このように息してない。
ないならば、作ってしまえ、ということもできるけれど、基本的なポート関係は AWS を立ち上げた際にも作った Security Groups に依存しているらしい。
では、今回も Security Groups で解決できるのか、というと Security Groups の設計はホワイトリスト形式。アクセスを許可する IP アドレスを指定する、というもので、特定の IP アドレスをブロックすることはできそうにない。
というわけで、ここで登場するのが、VPC のネットワーク ACL である。
ネットワーク ACL を作成する
AWS のコンソールにアクセスし、サービスの中にある VPC を選択する。
VPC ダッシュボードのネットワーク ACL を選択。
ネットワーク ACL の作成をクリックし、使用している VPC サブネットを選択する。ネームタグは入力しなくても作成できる（複数のネットワーク ACL を作成する場合に区別がつくようにつけるもの）。
次にインバウンドルールタブに切り替えて、編集ボタンをクリックする。
上のスクリーンショットでは色々並んでしまっているけれど、初期状態では「ルール #100」の 0.0.0.0/0 について「すべてのトラフィック」を「許可」するルールだけがあるはず。
ここに記載したルール #（ナンバー）の順に適用されるので、ブロックする場合はルール # に100より小さな数字を指定して、拒否を選ぶ。
送信元には、ブロックする IP アドレスを CIDR で記述する必要がある。CIDR とは IP アドレスを一括りにして記述できる方式のことで、これを「サイダー」と読めるかどうかでクロウトなのかニワカなのか一発でバレる。らしい。以前外国人エンジニア氏が「シーアィディーアール」と発音していたので、もしかして「サイダー」とか読んでるのは日本だけではないのか、という疑念がぼくの中では巻き起こりつつある。
いずれにしても、CIDR を頭のなかで計算できるほど IQ は高くないので、CIDRアドレス計算ツールをありがたく使わせてもらって計算時間は別のことに有効活用させてもらうことにする。
一番単純なのは、IP アドレスに「/32」をつければ、CIDR はその IP アドレス単体となる。つまりぼくは最初 /32 をつけまくって20個のアドレスをブロックしようとしたのである。
編集が終わったら、保存ボタンをクリックして終了である。これでもうその IP アドレスからはサーバーにはアクセスできない。サーバーにログすら残らない。AWS における鉄壁の呪文アストロンである。どうだ、参ったか。
ネットワーク ACL の上限を増やす
そしてここで問題が起こった。
デフォルトではネットワーク ACL に記述できるルールはルール #100を合わせて20個までである。つまり、邪悪な20個の IP アドレスすべてはブロックできない、ということになってしまう。それでは困る。
というわけで、AWS のコンソールからサポートセンターにアクセスする。
ケースの作成ボタンをクリックする。ケースといっても箱ではなくて、案件のほうである。
「内容」ではサービス制限の増加を選択し、「制限タイプ」は VPC を、「制限」は VPC 当たりのネットワーク ACL 数、「新しい制限値」はデフォルトの倍の 40 にしてみた。
わざわざ 20 に制限しているからには、AWS 側もなるべく少なく抑えたい、ということだと空気を読み日和って倍に留めたのだけど、「いますぐ 256 にしろ」といった要求が通った方がいたら、ぜひ教えろください。おながいします。
程なくしてケースに返信が来れば、ACL 数倍が倍増する。
エピローグ
しかし、敵はバカではなかった。20個の IP アドレスをブロックされた敵はすぐにこのままでは攻撃の意味が無いことに気づいたのだろう。
翌日にはまた新たな IP アドレスから攻撃がやってきたのだ。そりゃそうだ。Elastic IP を取得しなおせば、ブロックされていない IP アドレスをもった兵隊たちの出来上がり。今度は1日でおおよそ合計30万回。一番多かったもので50892回。よく働く兵隊である。
これは僕にも原因がある。バカ正直にアタックしてきた20個の IP だけをブロックしたからだ。AWS は IP アドレスの範囲を公開しているので、JSON ファイルを確認しながら CIDR で（サイダーってちゃんと読めました？）ブロックしていく。こうしてまたサーバーに平穏が訪れた……。
かと思ったら、また翌日別の IP アドレスから攻撃がやってきた。
アンタも好きねぇ。
飽きもせずにようやるわ。再び grep して cut して sort して uniq して host して気づいた。今まで AWS のアベイラビリティーゾーン us-west-2 からのみ攻撃が来ていたのが、ap-southeast-1 や us-east-1 が混じり始めたのだ。
これは米国西部だけではなくて、米国東部やアジア・パシフィックのリージョンにあるサーバーも使い始めた、ということ。わざわざ自分で取得したのか、単に乗っ取っているゾンビなのかは不明。
ap-northeast-1 も塞がないといけなくなったら、同じアジア・パシフィック（東京）アベイラビリティーゾーンで稼働しているブログからのピンバックは捨てないとなぁ、と思い始めた頃、これ以上の新しい IP アドレスは現れなくなった。
攻撃者の夏休みが終わったのか、裏で Amazon 先生が動いてくれたのかは不明。ログをまとめて Amazon に通報しようと思っていたけれど、まだ出来ていない。というのもぼくの夏休みが終わってしまったからだ。
ふぅ、しばらくちゃんとブログを読んでくれる人だけ来てください。