相当数の Amazon AWSが乗っ取られているんじゃない？って思える現象に遭遇しました。
きっかけは、最近、Webサーバーにコマンド入力しようとするとレスポンスが悪いことがあることから調査を開始しました。
コマンドレスポンスが悪くなるのは、HDDへのアクセスが集中している時です。Webサービスには以前、アクセス集中が発生した時期もありましたが、最近は落ち着いていますし、そもそもWebサーバーのログに不自然なところはありません。しかし、HDDは高負荷状態。一体何？
Webサーバーの、ログチェックは欠かさないのですが、おかしなアクセスには気付いていません。
訳の分からないタイミングでサーバー高負荷が発生しているので、そのたびにWebサーバーへのアクセス記録を見るのですけど、平常。
ふと、Webサーバーのログじゃなく、netstat とファイヤーウォールの方を見てみると、Webサーバーのログに記録されていないコネクションが多数発生していることに気付きました。
Aug 21 10:46:36 TCP 116.203.201.109:41570 116.58.172.107:443 in Aug 21 10:46:36 TCP 54.84.236.184:62971 116.58.172.107:80 in Aug 21 10:46:37 TCP 34.204.127.143:52811 116.58.172.107:443 in Aug 21 10:46:40 TCP 34.204.127.143:58508 116.58.172.107:443 in Aug 21 10:46:41 TCP 54.36.148.240:21450 116.58.172.107:80 in Aug 21 10:46:42 TCP 54.36.148.240:21450 116.58.172.107:80 in Aug 21 10:46:43 TCP 35.153.29.228:38115 116.58.172.107:443 in Aug 21 10:46:43 TCP 3.210.226.246:52995 116.58.172.107:443 in Aug 21 10:46:44 TCP 54.36.148.240:21450 116.58.172.107:80 in Aug 21 10:46:45 TCP 116.202.73.20:58929 116.58.172.107:80 in Aug 21 10:46:46 TCP 116.203.142.244:48337 116.58.172.107:443 in Aug 21 10:46:47 TCP 34.204.127.143:46783 116.58.172.107:80 in Aug 21 10:46:50 TCP 3.210.226.246:34694 116.58.172.107:443 in Aug 21 10:46:51 TCP 89.248.172.101:51865 116.58.172.107:4565 in Aug 21 10:46:53 TCP 116.203.201.109:55646 116.58.172.107:443 in Aug 21 10:46:54 TCP 18.233.252.8:55606 116.58.172.107:80 in Aug 21 10:46:55 TCP 34.236.210.142:56576 116.58.172.107:80 in Aug 21 10:46:55 TCP 35.153.29.228:42325 116.58.172.107:80 in Aug 21 10:46:56 TCP 116.203.201.109:44674 116.58.172.107:443 in Aug 21 10:46:56 TCP 116.203.201.109:42454 116.58.172.107:443 in Aug 21 10:46:59 TCP 35.153.29.228:63439 116.58.172.107:80 in Aug 21 10:46:59 TCP 34.204.127.143:42804 116.58.172.107:80 in Aug 21 10:46:59 TCP 18.233.252.8:43337 116.58.172.107:80 in Aug 21 10:47:00 TCP 34.236.210.142:61242 116.58.172.107:443 in Aug 21 10:47:04 TCP 178.63.55.20:63695 116.58.172.107:80 in Aug 21 10:47:07 TCP 116.203.142.244:58107 116.58.172.107:443 in Aug 21 10:47:07 TCP 116.203.201.109:58723 116.58.172.107:443 in
ファイヤーウォールやnetstat では HTTP/HTTPS アクセスが見えているのに、Webサーバーのログには記録されていないアクセス。
IPアドレスを名前解決してみると、主にamazonaws.comからのアクセスと判明。
help.smsedge.com ec2-54-84-236-184.compute-1.amazonaws.com ec2-34-204-127-143.compute-1.amazonaws.com ec2-34-204-127-143.compute-1.amazonaws.com ip-54-36-148-240.a.ahrefs.com ip-54-36-148-240.a.ahrefs.com ec2-35-153-29-228.compute-1.amazonaws.com ec2-3-210-226-246.compute-1.amazonaws.com ip-54-36-148-240.a.ahrefs.com static.20.73.202.116.clients.your-server.de static.244.142.203.116.clients.your-server.de ec2-34-204-127-143.compute-1.amazonaws.com ec2-3-210-226-246.compute-1.amazonaws.com no-reverse-dns-configured.com help.smsedge.com ec2-18-233-252-8.compute-1.amazonaws.com ec2-34-236-210-142.compute-1.amazonaws.com ec2-35-153-29-228.compute-1.amazonaws.com help.smsedge.com help.smsedge.com ec2-35-153-29-228.compute-1.amazonaws.com ec2-34-204-127-143.compute-1.amazonaws.com ec2-18-233-252-8.compute-1.amazonaws.com ec2-34-236-210-142.compute-1.amazonaws.com static.20.55.63.178.clients.your-server.de static.244.142.203.116.clients.your-server.de help.smsedge.com
一体何が起きてんの？
ちなみに、ahrefs.com はクローラーで、攻撃ではないけど頻度が高いのでうっとうしい。
Webサーバーのログに残らないということは TCPのハンドシェークが未了でコネクションが確立してないんでしょうね。SYNを送った状態で、さよなら〜って一方的に切断して、次のコネクションを張りに来る。SYN flood 攻撃なのかな。
現代のWebサーバー自体はこんな事で落ちることはありませんが、OS処理が必要になるのかこのSYNコネクションが多いタイミングでメモリを食っている感じです。同じ時間にWebサーバーコンテンツへアクセスして来た人のレスポンスは、妨げられたり、処理が後回しにされる場合があります。コネクションが確立する前なので、HTTPDには直接被害は無いはずですがOSのリソース消費によるパフォーマンス低下の影響は受けるでしょう。そしてスワップが発生。コマンドレスポンスが悪化。という循環に陥っているようです。
Webサーバーへのアクセスは、ブラウズの他、検索エンジンのクロール、Wordpress.comとのデータ交換も入り交じっているので、ファイヤーウォールのログだけ見ても、判断できません。Webサーバーのログと比較して初めて不正アクセスだと判断できるため判定が面倒くさい。ファイヤーウォールでTCPのステータスを含めたロギングをしていないと気付くことさえ出来ないかも知れません。私のサーバーの場合はファイヤーウォールログとWebアクセスログを目視で観察できる程度のヒット数なので、あれあれ、何かおかしいぞって気付くことが出来ましたが、一日に1万ページを超えるヒットがあるサーバーでは、目視で気付くことは出来ないかも知れません。
なんて嫌らしい攻撃。
お薦めツールは iftop コマンド。このコマンドで常時ネットワークインタフェースをモニターしていれば、コネクションが残っている間はアクセス元が表示され続けるので気付くことが出来ます。
攻撃を検知する毎にアクセス元をネットワークごとファイヤーウォールでブロック掛けてゆくと、すぐに別のネットワークから攻撃が発生するので、amazonawsや、その他手先として乗っ取られているサーバーがたくさんあるものだと思います。
とりあえず、amazonaws.com からの HTTPアクセスはファイヤーウォールで全部ブロック。この中にクローラーが含まれていたらご免なさい ってところですが、まあ仕方ない。
御無沙汰しています(^^)
ウチが借りているVPNも似たような状況のようです。
以前から、ずっと稼働を続けているとカーネルはピンピンしているのにTCPが一切通らなくなる（SSH・HTTP・SMTP・IMAPが全滅、コンソールからは普通にログインできる）という現象が続いていまして、対策としてcronで月3回、NICのリセットをかけるようにしています。
/etc/crontabより：
40 1 4,14,24 * * root /root/bin/network-reset.csh
このスクリプトの中核部分は
/sbin/ifconfig vtnet0 down
/sbin/ifconfig vtnet0 up
という2行です。なぜ拡張子が .csh なのかは訊かないでください(汗)
で、ウチを攻撃している犯人の場合、いま見た限りではAmazon AWSではなくDigitalOceanというISPを使っているようです。共用しているユーザの意向も確認してから、パケットフィルタを入れようと思います。
ではでは。
追記です。
いま気付いたんですが、crontabに書くパラメータが1列足りない(汗)…正しくは
40 1 4,14,24 * * root /root/bin/network-reset.csh
となるべきでした。 (**管理者権限で、前コメントに * を追加しておきました。管理人より)
cronのログを見ても、スクリプトが起動されている形跡なし。
修正したので、次の予定日、すなわち明後日の朝まで様子見になりそうです。
お目汚し、失礼いたしました。
でるもんた・いいじま さん、お久しぶりです。
今回、このメモを書いた直後から、検索エンジンをきっかけにこのページに訪問される方が多くてびっくりしていたところです。
通常でしたら、記述直後は feedなどから訪問頂くケースが殆どなんですが、このメモに関しては検索エンジンで訪問される方が殆どで、一体何を検索してここに来ているんだろう？って不思議に思ってます。
ということは、困っている人が多いんですね。
スクリプトとcrontabは、この後訪問される、その他の被害者の役に立つと思います。
うちは、本サーバーの他、DNSを狙われています。DNSに関してはHTTPポートは不要なの、HTTP/HTTPSを閉鎖しています。
OSがFreeBSDの為かどうか分かりませんが、NICが停止するようなことは起きていないんじゃないかと思います。
面白いことに、このメモを公開した数時間後から、port 80, 443 に対する攻撃がぴたっと止まりました。攻撃が続くようなら amazonawsのトラブルページからログを入力してホスト側で対策してもらおうかと思っていたんですけどね。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/report-aws-abuse/
と、思ったら数分前から、ホストを代えて、また攻撃再開したみたい。
pppoe で接続している私のfreebsd の場合に書くとすると、cron tabの中のコマンドラインが、service ppp restart になるのかな。ちなみに私も csh派です。自分でスクラッチから書く場合は、だいたい tcsh 用に書いてます。改造の場合は、sh/bash でも仕方ないですけど。
BSD派ですからねぇ。