テックブログ

X-Forwarded-Forを利用した送信元IPの偽装について

こんにちは。技術部の DI です。
今回は、ロードバランサなどを経由してアクセスされるサーバで、アクセスログ調査を実施する際に重要になる X-Forwarded-For について簡単ではありますがご紹介します。
便利な機能でありながら、アタックを仕掛けてくる攻撃者にも利用されてしまう側面もあるので、注意が必要です。
まずは、X-Forwarded-Forの概要から見ていきましょう。

X-Forwarded-Forとは

X-Forwarded-For(以降XFF)とは、ロードバランサやプロキシ等を経由してサーバに接続する際、接続元IPを特定するために利用されるHTTPヘッダーです。
通常ロードバランサ等を経由した場合、サーバ上で確認するとロードバランサのIPが記録されます。
これでは、アクセス数が急激に増えてサーバへの負荷が上昇した際にアクセスログを調査しても、正常なアクセスなのか同一IPからのアタックによるものか判断できません。
ですが、XFFを利用することで、接続元IPの特定ができるようになります。
アラートが発報された際にログ調査+原因究明の対応をする私たちにとって、非常にありがたい機能です。

XFFヘッダの構成

基本的に、XFFは機器を中継するたびに前の機器のIPをカンマで区切りながら追記していきます。
そのため、接続元IPは一番左に記述されることになります。
RemoteIPHeaderでXFFを指定してあげることで、ログ上のリモートIPを一番左のIPに書き換えてくれます。

XFFの偽装

ログ調査等が必要になるサーバには設定しておきたい便利な機能ですが、残念ながら簡単に偽装できるというデメリットも存在します。
HTTPのヘッダ情報は簡単に指定、書き換えができてしまいます。
そのため、XFFを指定してリクエストを送信することで、送信元IPを偽装されてしまう可能性があります。

今回はアクセスの流れを下記と想定して話を進めます。

このようなアクセスの場合、通常であればロードバランサを経由した時にXFFヘッダにクライアントIPが追加されHTTPヘッダとして付与されます。
X-Forwarded-For: x.x.x.x

しかし、悪意のあるユーザがリクエストを送る時点で、XFFに任意のIPを指定すると、サーバが受け取る情報は下記となります。
X-Forwarded-For: ユーザ任意のIP, x.x.x.x

この場合、ログフォーマットの設定にもよりますが、基本的に一番左にあるIPが接続元IPとしてログに記録されます。
そのため、IPアドレスでアクセス制御をしている場合、外部アクセスを許してしまう可能性もあります。

実際にIPを書き換えてみる

ここからは、実際にXFFをヘッダに付与してログのIPを任意のIPに書き換えてみたいと思います。
まずは、通常アクセスを想定して、簡単なHTTPリクエストを投げてログを確認してみます。

$ telnet kensyo-01alb-765122235.ap-northeast-1.elb.amazonaws.com 80
Trying y.y.y.y...
Connected to kensyo-01alb-765122235.ap-northeast-1.elb.amazonaws.com.
Escape character is '^]'.
GET / HTTP/1.1
Host:kensyo-01alb-765122235.ap-northeast-1.elb.amazonaws.com

ログを確認してみると、リクエストを送信したサーバのIP(x.x.x.x)が表示されました。

# tail -f /var/log/httpd/access_log
x.x.x.x - - [13/Feb/2025:23:50:49 +0000] "GET / HTTP/1.1" 200 58 "-" "-"

次は、XFFに「1.1.1.1」と指定してリクエストを投げてみます。

$ telnet kensyo-01alb-765122235.ap-northeast-1.elb.amazonaws.com 80
Trying y.y.y.y...
Connected to kensyo-01alb-765122235.ap-northeast-1.elb.amazonaws.com.
Escape character is '^]'.
GET / HTTP/1.1
Host:kensyo-01alb-765122235.ap-northeast-1.elb.amazonaws.com
X-Forwarded-For:1.1.1.1
# tail -f /var/log/httpd/access_log
1.1.1.1 - - [14/Feb/2025:00:02:23 +0000] "GET / HTTP/1.1" 200 58 "-" "-"

XFFヘッダに設定した「1.1.1.1」が接続元IPとしてログに記録されました。

このように、XFFを利用して送信元IPアドレスを出力する設定をしている場合、
IPアドレスを偽装されてしまう可能性があります。

対策

このような場合、安定したサービス提供のためにも対策が必要です。
対策としては、RemoteIPTrustedProxy などの利用が挙げられます。
経由してくるロードバランサやプロキシのIP一覧を事前に定義することで、アクセスを制御します。
定義された想定している経路で接続が来ているか照らし合わせ、異なるようであれば制御というイメージです。
今回詳細は触れませんが、気になる方はぜひ調べてみてください。

まとめ

今回のように一見便利な機能でも、場合によっては悪意のある攻撃者に利用されてしまうケースがあります。
何事も、デメリットや仕様を十分に理解した上で運用していく必要があります。
また、昨今のセキュリティにおいては、レイヤーごとで提供されるサービスが異なるなど、多層防御の考え方も重要です。
弊社ではサーバの運用保守に加え、セキュリティサービスの取り扱いもございますので、お気軽にお問い合わせください。
それではまた。

この記事をシェアする

  • facebook
  • twitter
  • hatena
  • line
URLとタイトルをコピーする

実績数30,000件!
サーバーやネットワークなど
ITインフラのことならネットアシストへ、
お気軽にご相談ください