こんばんは、X-Forwarded-For警察です - エムスリーテックブログ

エムスリーエンジニアリンググループ製薬企業向けプラットフォームチームの三浦 (@yuba)です。普段はサービス開発やバッチ処理開発をメインにやっておりますが、チームSREに参加してからはこれに加えて担当サービスのインフラ管理、そしてクラウド移行に携わっています。 今回はそのクラウド移行の話そのものではないのですが、それと必ず絡んでくるインフラ設定に関してです。 アクセス元IPアドレスを知りたい Webアプリケーションがアクセス元IPアドレスを知りたいシーンというのは、大まかに二つかと思います。ログ記録用と、アクセス制限ですね。どちらもアプリケーションそのものではなく手前のWebサーバの責務のようにも思えますが、そうとも言い切れません。動作ログ、特に異常リクエストをはじいた記録なんかにセットでIPアドレスを付けたいとなるとアプリケーション要件ですし、アクセス制限についてもマルチテナントサービ

[Sampo]

id:tmatsuu 登場人物がすべて信頼外IPの場合、実ソースIPつまり最末尾を取りたいのだから2がそのまま有効です。3はエッジケース対策でして、プロキシサーバ上のシェルからcurlされているような場合への考慮です。

[ymm1x]

“アプリケーションコード中では、なるべくX-Forwarded-Forを自力で解釈するコードを書くことは避けたいです。”

[Songmu]

ALBがそういうことやってくれないからGoのアプリ内でやってくれるミドルウェアを作ってしまったのがこれです… https://songmu.jp/riji/entry/2020-04-24-realip.html

[umai_bow]

これのせいでCloudfront挟むのが（IPぜんぶ登録するのが）めんどくさいんですがどうすればいいのか教えてください

[uunfo]

apacheとngunxに専用のモジュールがあったとは／アクセス制御はロードバランサーでやるべきでは

[fashi]

手前サーバ前提ならそうなんかもしれんが共有サーバでの稼動だったりそもそもクライアントが変な串使ってるけどリアルIP漏れてるマヌケは記録しとこってケースもあるので信頼されたIPなんか知らんがなって実装するわ

[raimon49]

信頼できる中継元IPアドレスが指定できる。Apache/nginxの例。

[ikkitang1211]

読んだ

[sabotem]

覚えておく

[manhole]

“インフラ構成に起因する複雑さをなるべくインフラ設定側に押し出すことでアプリケーションに不必要な複雑さを持ち込ませない形にするのがよいと考えます” RemoteIPTrustedProxyを使う

[naglfar]

アプリケーションサーバに適切な設定を行えばアプリは remote_addr を取得するだけで済むんだ。すてき。

[pmakino]

XFF を適切に解釈しつつ詐称を防ぐには信頼できるIPアドレスを列挙する必要があり面倒という知見を得た

[diveintounlimit]

んーまぁふつー。。。

[rryu]

クライアントが多段を偽装したX-Forwarded-Forを送ってきてそれを受け入れてしまう場合は最初のアドレスが本物とは限らないという話。

[rawwell]

"上記解釈設定を入れたWebサーバをフロントに立てアプリケーションサーバとはAJPでつなぐことで、アプリケーションコード中では無邪気に getRemoteAddr() するだけでクライアントIPアドレスが取得できるようになる"

[hiroaki256]

x-forwarded-for

[teckl]

その昔アプリケーション側でX-Forwarded-Forを取得するようにしていて、また別の箇所ではREMOTE_ADDRを使ってしまっていて痛い目にあった淡い思い出…こういうのはリバプロの責務だよなぁ。。

[katzchang]

大変じゃわい

[kasuke18]

“例えばJava Tomcat開発であればAJPがremote_addrを伝達してくれます”

[koroharo]

あぁ、信頼できないIPは末尾を取るってことか。でも、国外IPが国内プロキシを経由した場合、国内IPが採用されてしまうけど、それはよいのか？

[ryuichi1208]

real_ip_headerみたいなのfromIPが固定じゃ無いケースで使えないから辛い気が

[estragon]

“西に「最初のものを取る」コードを見つければ修正チケットを立て、東に「X-Forwarded-ForだとソースIP偽装が心配だよね」という議論があればプロキシ設定次第で回避可能ですよと伝えに行き、としているうちに”

[wata88]

googleのデータセーバーとかいうやつのせいでViaを考慮してXFF解かなきゃいけなくて実装する羽目になった

[akibare]

ログ解析で苦労するやつ

[kubecorn]

いい記事。このあたりは手段も多いし良し悪しも様々なので正しい知見が多いに越したことはない。

[ko-ya-ma]

“なるべくX-Forwarded-Forを自力で解釈するコードを書くことは避けたいです”

[spark7]

mod_remoteipとRemoteIPTrustedProxyで生のX-Forwarded-Forを扱わなくて済むし偽装も防げると

[miron_mikan]

でもこれ悪意あるプロキシの存在は無視してる気がするんだけど、それは仕方ないと判断するんかな

[likk]

Perl で Plack を使っているなら`Plack::Middleware::XForwardedFor` を使うと良さそう。同梱のテストの書き方も参考になる。

[yujiorama]

偽装の可能性があるので確実なリモートIPは取得できないやつ

[tettekete37564]

世の中的にはロードバランサやリバプロがヘッダに付与する ID とログから突き合わせてるのかなと思ってたが、これも違う気がする。NW 構成に依存する設計思想を実装に埋め込むとブラックボックス化しやすく保守難

[rrringress]

転送元の信頼性について。SMTP には SPF のような仕組みがあるけど HTTP には無いな。ページ内での origin とかとも違うし

[ya--mada]

🤔そうなのよねー、偽装というか内部のプロキシが変なヘッダー付けて外に出してくるとかなー