Q&A
172.31.40.3はクラス BのプライベートIP（終りの方）っぽいですね。172.31.40.3から自前のサーバーの"/usr/share/nginx/html/(doc_root)/m/item/itemShw.php"にやたらアクセスしたがっているログ、という理解であっていますか？
お世話になります。
AWS+EC2+Ubuntu+nginxでWebサーバーを立てています。
ALBでロードバランサーを建ててACMで証明書を取ってHTTPS化しました。
HTTPポートはHTTPSポートにリダイレクトしています。
EC2のインスタンスはSSHとHTTPポートが空いている状態です。
EC2のインスタンスとALBはHTTP接続しています。
お名前.comでDNS名を取って、Route53でALBのAレコードを作っています。
今日、error.logを見たら、以下のようなエラーが大量に（数秒に一回）吐き出されていました。
$ tail /var/log/nginx/error.log
2021/10/23 10:32:45 [error] 1793#1793: *32690 open() "/usr/share/nginx/html/(doc_root)/m/item/itemShw.php" failed (2: No such file or directory), client: 172.31.40.3, server: (domain), request: "GET /m/item/xxxx.php?cd=xxxxxx HTTP/1.1", host: "xxx.xxxxxxxxxx.xx"
※(doc_root)は自分で掘ったドキュメントルート。(domain)はお名前.comで取ったDNS名です。
エラーメッセージ通り、/usr/share/nginx/html/(doc_root)/の下にm/item/xxxx.phpというファイルはありませんし、mというディレクトリも作っていません。
xxx.xxxxxxxxx.xxというサイト（企業）に用事もありません。
ググったら、m/item/xxxxxx.phpというプログラムは、www.xxxxxxxxx.xx配下の、何らかのECサイトのプログラムらしいです。
これですが、何らかの攻撃を外部から受けていると考えていいでしょうか？
すでに、何らかの踏み台サーバーやトロイの木馬的なものを仕込まれていると考えたほうがいいでしょうか？
上記のようなエラーが出ないようにセキュリティを強化する方法はあるでしょうか？
よろしくお願いします。
★
（同日17時半追記）
情報提供・修正依頼をいただいて、誰かのクライアントが私のサイトを某ECサイトと間違って叩いているのではないかと予想し、ロードバランサーのアクセスログを取ってみました。
すると、ログを取得し始めた13時ごろから、この追記を書いている17時半までの間に、以下のようなリクエストが、数秒ごとに、数百回発生していることが分かりました。
（ログの解析は以下の記事を参考にしました）
https://dev.classmethod.jp/articles/alb-log-to-s3/
https [リクエストタイプ]
2021-10-23T04:09:39.511097Z [リクエストがあった時間]
app/(load balancer name)/xxxxxxxxxxxxx [私のサーバーのロードバランサー情報]
XXX.XXX.XXX.XXX:52695 [クライアントのIPアドレス:ポート番号]
172.31.xxx.xxx:80 [私のターゲットのIPアドレス:ポート番号(プライベートIP)]
0.000 [ロードバランサーがリクエストを受け取った時点からターゲットに送信するまでの合計経過時間]
0.000 [ロードバランサーがターゲットにリクエストを送信した時点から、そのターゲットが応答ヘッダーの送信を開始した時点までの合計経過時間]
0.000 [ロードバランサーがターゲットから応答ヘッダーを受け取った時点から、クライアントへの応答の送信を開始した時点までの合計経過時間]
404 [ロードバランサーからの応答のステータスコード]
404 [ターゲットから応答のステータスコード]
360 [クライアントから受け取ったリクエストのサイズ (バイト単位)]
705 [クライアントに返される応答のサイズ(バイト単位)]
"GET https://www.sonymusicshop.jp:443/m/arti/artiItm.php?cd=60022866&ima=3931&site=SHTTP/1.1" [クライアントからのリクエスト]
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36" [リクエスト元のクライアントを特定する User-Agent 文字列]
xxxxxxxxxxxxxxxxx [HTTPSリスナーのSSL暗号]
TLSv1.2 [HTTPSリスナーのSSLプロトコル]
arn:aws:elasticloadbalancing:ap-northeast-1:xxxxxxxxxx:targetgroup/(target group name)/xxxxxxxx [私のターゲットグループのAmazonリソースネーム(ARN)]
"Root=1-xxxxxxxxxxxxxxxx" []
"XXX.XXXXXXXXXXXXX.XX" [TLS ハンドシェイク中にクライアントから提供されるSNIドメイン]
"arn:aws:acm:ap-northeast-1:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxx" [クライアントに提示される私の証明書のARN]
0 [リクエストに一致したルールの優先度の値]
2021-10-23T04:09:39.510000Z [ロードバランサーがクライアントからリクエストを受け取った時刻]
"forward" [リクエストの処理時に実行されるアクション]
"-" [HTTPレスポンスのロケーションヘッダーのリダイレクトターゲットのURL]
"-" [エラー理由コード]
"172.31.xxx.xxx:80" [私のターゲットのIPアドレス:ポート番号(プライベートIP)]
"404" [ターゲットの応答からのステータスコード]
"-" []
"-" []
すべて同じ「XXX.XXX.XXX.XXX」というIPアドレスからのアクセスです。
また、「 "XXX.XXXXXXXXXXXXX.XX" [TLS ハンドシェイク中にクライアントから提供されるSNIドメイン]」は、nginx側に残っていたのと同じECサイトを運営している名のある企業です。
ということで、以下は私の質問です。
0. 現状は、持っていないリソースにアクセスを掛けられて、持ってないよ（404）と返事をしているだけ、ということなので、特に問題はないということでしょうか。
0. クライアント「XXX.XXX.XXX.XXX」を拒否すればいいだけの話でしょうか。（イタチゴッコになるような。。）
0. 大企業「"XXX.XXXXXXXXXXXXX.XX"」に何か言った方がいいでしょうか。（AWS配下らしい？）
0. Amazonに何か問い合わせてもいい案件でしょうか。（こちらの不手際で問い合わせるのは気がすすまないので。。）
0. その他、私がセキュリティを強化し、エラーログを見やすくする上でアドバイスがあればお願いします。
以上、よろしくおねがいします。
はい。それでそのまま残したのですが、修正した方がいいでしょうか。
cd=SQEX000010866をソニーミュージックに入れたらちゃんとアクセスできました。
ゲームミュージック
NieR Replicant -10+1 Years- / Emil
https://www.sonymusicshop.jp/m/item/itemShw.php?site=S&cd=SQEX000010865
ゲームミュージック
NieR Replicant -10+1 Years- / Devola ＆ Popola
https://www.sonymusicshop.jp/m/item/itemShw.php?site=S&cd=SQEX000010866
> はい。それでそのまま残したのですが、修正した方がいいでしょうか。
ローカルIPであれば多分漏れても（グローバルIPが分からないと）誰も手が出せないのでそこまで気にしなくてもいい気がします。
はい。ただ、私のサイトからソニーミュージックにアクセスしたつもりはないので、誰かが数秒に一回このエラーを出しているのか心配になり、またこのエラーで埋め尽くされて自分のエラーが見られないので質問しました。
googleなどのclawlerらしいアクセス(?)とかはないですか？
それってどうすれば調べられますか？あと、それだとGoogle=>自分のサイトのアクセスで、ソニーミュージックは絡まないですよね？
Clawlerはたとえの一つです。プログラムらしいアクセスをしていないか、人間っぽい動きか見えないかなぁと思っただけです。
連番でアクセスしてきた、ブルートフォース的な動きをしていた→多分プログラムのせい
全然違うアクセスをしてきた→人間臭い しかも頻繁であればquery1000さんのとこに何人も誤ってアクセスされているかも？
私のサイトをソニーミュージックと間違って大量のアクセスをしてる可能性ですか？なるほど。なぜそんなことが起こったのでしょうか？これを止められますか？ALBのログを見ればいいのかなー
https://aws.amazon.com/jp/route53/
route 53がグローバルIP→ローカルIP云々とあるので、ここがこじらせてSonymusicに飛ばすところをquery1000さんのところに飛ばしてしぱっている、ような気がします。
少し調べるとSonymusicのサービスはAWSにおんぶにだっこなのでありえるのではないかと…。
もしそうならアマゾンのサービスの未知のバグ（？）かもしれませんね :)
いつから始まったとか分かると何かAmazonに聞ける材料になると思います。
「○○日から急に～」などがあれば、Amazonの中の人が「実は変更を～」ということもありえそうですね。
にゃるほど、それはありそうですね！！ありがとうございます！！
ALBのアクセスログを読んだ結果を質問の補足として追記しました！
回答1件
0
ベストアンサー
nginxのログはnginxがそういうリクエストを受けてそれがエラーになっている、というだけのログです。
問題があるかどうかはそのリクエストを受けてアプリケーションがどう動くかによります。
何かをインターネットに公開すると攻撃のようなアクセスは必ず来ます。
気になるならどこかで接続拒否しましょう。
もちろん、ALBに対して不審なアクセスをしてくるクライアントのIPを、です。
ALBを使っているのでAWS WAFを使うと簡単です。
AWS WAFV2でIPアドレス制限してみた
追記された質問に対する回答を自分の見解で書くと
-
存在しないファイルに対するアクセスなので何も起きないと思われ、特に問題はありません。ただ、エラーと言えどレスポンスを返しているので過剰な数のリクエストが来た場合はパフォーマンスに影響する可能性があります。
-
いたちごっこなのはそのとおりですが、残念ながらそうするぐらいしかありません。
-
関係ないので言っても仕方ないです。リクエストをクライアントが勝手に送ってるだけなので。その大企業のIPから接続が来てるなら別ですが。
-
問い合わせるのは別にいいと思いますが、現実的にはIPを拒否するとかアプリケーションの挙動を見直すとかの一般的な対処くらいしかないと思われます。
-
前述の通りWAFで不審なアクセスをしてくるIPを拒否するくらいではないでしょうか。
投稿2021/10/23 11:52
総合スコア7447
回答ありがとうございます！
実は、思い余ってAWSのサポートセンターに問い合わせしたのですが、教えていただいたような事情ですと、無料期間中ですので無視されるかもしれませんね。
教えていただいた方法でWAFを設定し、当該IPアドレスをブロックしました。10分ほど経ちますが、気持ち悪いぐらいエラーがなくなりました。
CIDR表記のサブネットというものを初めて設定しましたが、、とりあえず１ホストだけブロックすればいいかと思って/32を設定しました。
私は大企業（ないしAWSの大企業担当）がしくっているのではないかと思っています。なぜかというと、攻撃でもプライバシー侵害でもなく、「素」の買い注文が来ているだけだからです。
ですから、注文をリダイレクトするサーバーのDNS引きがうまくいっていず、私のサーバーにリダイレクトしているんじゃないかと思います。
と、いった状況を、問題のECサイトの問い合わせ窓口に投げてみようと思います。
無視されてもいいですし、まさか変な言いがかりをつけてきたりはしないでしょう。
もしかしたら大量の注文が宙に消えていたら消費者がかわいそうだからです。
ありがとうございます！
スミマセン、上記のコメントですが、私の勘違いで、また注文が復活したので状況を詳しく調べてコメントします。削除しようとしたのですが、teratailは審査が必要ということで簡単にはできないんですね。
スミマセン、今度こそちゃんとうまくいきました。
ACLのActionをBLOCKにすべきをALLOWにしていたので、リクエストがドンドン来ていました。
一時的に来ないように見えていたのは、エラーログを誤って消していたからでした。
nginxをリスタートすると、リクエストが殺到したので、WAFでACLを見直してBLOCKに設定し直しました。
WAFの統計情報を見ると、一気にグラフが下降し始めました。
AWS便利だなー。
上のコメントは削除申請してしまったので、改めてコピペします。
回答ありがとうございます！
実は、思い余ってAWSのサポートセンターに問い合わせしたのですが、教えていただいたような事情ですと、無料期間中ですので無視されるかもしれませんね。
教えていただいた方法でWAFを設定し、当該IPアドレスをブロックしました。10分ほど経ちますが、気持ち悪いぐらいエラーがなくなりました。
CIDR表記のサブネットというものを初めて設定しましたが、、とりあえず１ホストだけブロックすればいいかと思って/32を設定しました。
私は大企業（ないしAWSの大企業担当）がしくっているのではないかと思っています。なぜかというと、攻撃でもプライバシー侵害でもなく、「素」の買い注文が来ているだけだからです。
ですから、注文をリダイレクトするサーバーのDNS引きがうまくいっていず、私のサーバーにリダイレクトしているんじゃないかと思います。
と、いった状況を、問題のECサイトの問い合わせ窓口に投げてみようと思います。
無視されてもいいですし、まさか変な言いがかりをつけてきたりはしないでしょう。
もしかしたら大量の注文が宙に消えていたら消費者がかわいそうだからです。
ありがとうございます！
> 無料期間中ですので無視されるかも
勘違いされているようですが、AWSに無料期間というものは特にありません。
無料枠に期限付きのものがあるだけです。
サポートに関して言うと、期間に関係なくサポートの有料プランを契約していなければ技術的な問い合わせはできなかったはずです。
セキュリティ的に危険なケースに限ってはAWSの側から連絡が来たりすることはありますけどね。
あと、申し訳ないですがせっかくのログに本来書いていないはずの文字がたくさん書いてあるとかえって読みづらいので加工していないものを貼ったほうがよかったですね。
今回でいうと、問い合わせる前にまず先方のDNSが間違った情報を登録していないかを確認したほうがいいですね。
自分のALBのパブリックIPと先方のドメインに登録されているAレコードのIP、いずれもdigで調べられると思うので、先方が誤ったIPを登録していないか確認してみてください。
ありがとうございます。
後日談というか、昨日再三コメントしたあとの状況を説明すると、AWFでは結局設定できませんでした。リージョンの設定で東アジア（東京）にしていたのが敗因だったようです。CloudFrontでグローバルにすればいいのかもしれませんが、設定がよく分からなかったのでサブネットのACLレコードではじきました。
その１つの人は弾いたのは成功したんですが、ほんっとに世界各地から有象無象の人がアクセスしてきますね、サーバー。。気にしないようにするか、開発中は自分および関係者のIPだけアクセスを許すホワイトリストにするか考え中です、
大量に注文を掛けていた人はwhoisで調べると、北欧の某国に住んでいる男性名の個人でした。
ECサイトと自分のサイトのdigは両方一応調べていたのですが、Aレコードのカブりはありません。
謎です。
AWSの問い合わせと無料枠の期間の話、よく理解できました。ありがとうございます。
ログの件は失礼しました。自分用にもともと改行して注釈を入れていたのですが、伏せ字にする箇所の特定／編集が生ログでは難しかったのと、ALBのログが世界共通の形式なのかの判断できなかったので、そのままコピペしてしまいました。
誠にお世話になりました。
> リージョンの設定で東アジア（東京）にしていたのが敗因
どういうことかわからないのですが、普通にALBと同じリージョンで設定すればいいだけのはずですよ。
ちなみに拒否をするならWAFかACLですが、逆に特定のIPだけ許可するとかならセキュリティグループだけでも十分なのでそうするといいです。WAFと違ってお金もかかりませんし。
Cognitoと合わせて認証を挟むのもいいですね。
ううん、WAFの設定についてはどうか分かりません。
自分の（ALBと同じ）東京リージョンで、正しく北欧の人のIPをIPセットに入れてBlockの指定をしたのですが、はじけませんでしたので、リージョンを東京にして北欧の人ははじけないのかと勝手に想像しました。
デフォルトの動作をブロックにしたら、当然、自分も含めて全員アクセス不能になったので、WAFが効いているとは思います。
そう、ブラックリストはWAFの他にはACLで設定するしかないですが、ホワイトリストならセキュリティグループでも良さそうですね。
Cognito初めて知りました。これも良さそうですね。試してみます。
ありがとうございます。
> リージョンを東京にして北欧の人ははじけないのかと
アクセスするクライアントのIPの地域とこちら側で設定するリージョンは関係がないので、単純に設定が誤っているか弾けなかったクライアントのIPが設定したCIDRの範囲外だったのではないでしょうか。
貼った例だとホワイトリスト運用ですが、ブラックリストにしたいならDefault ActionをAllowにしてIP SetのActionはBlockにする必要があります。
>Default ActionをAllowにしてIP SetのActionはBlockにする必要があります。
そうしたつもりでしたが、やっぱり北欧の人から怒涛の注文が入ったんです。
今はセキュリティグループを作って関係者のIPをホワイトリストにしました。
なお、ECサイトにもメールしたのですが「技術的な内容なので有償のサポート会員に入るかユーザーフォーラムで聞け」と定型文の返事が来ました。まあ、こちらはいいですね。
これからCognitoに挑戦します。ユーザー認証をどうしようかと思っていたので、楽しみです。
ありがとうございます。
あなたの回答
tips
プレビュー
