インダストリー事業本部のイチノです。リモート製品 (Optimal Remote, Optimal Second Sight, ポケットドクターなど遠隔地とコミュニケーションするための製品) で使われるコア技術をまとめた Communication SDK を担当しています。 本記事では、ひとつのポートで異なる通信プロトコルを、 nginx で振り分けたい場合に、役立つ方法を紹介します。 80 ポートや 443 ポートのみ許可しているセキュアなネットワーク環境へ、複数のプロトコルを持ったサービスを提供するといった場合に使える方法です。 nginx によるリバースプロキシの振り分け方法として、以下の6つが存在します。 IP アドレスでの振り分け ポート番号での振り分け SSL/TLS の SNI による振り分け HTTP のパスによる振り分け HTTP の Host ヘッダーによる振り分け
はじめに この記事は下記リンクの日本語翻訳記事です 翻訳が誤っている場合はコメントか@no1zy_secまでお知らせいただけると幸いです。 [http_splitting] HTTP Splitting HTTP Splitting は 不適切なバリデーションを使用する攻撃です。通常、Nginx (HTTP Request Splitting) やそのユーザー (HTTP Response Splitting) の背後にあるwebアプリケーションを対象としています。 攻撃者がNginxによって作成されたリクエストやレスポンスの中にnewline character(\nや\r)を挿入できるときに脆弱性になります。 どうやって見つけるか リクエストの作成を担当する変数がディレクティブ内で使用されています。例: rewrite, add_header, proxy_set_header または
はじめに この記事は下記リンクの日本語翻訳記事です 翻訳が誤っている場合はコメントか@no1zy_secまでお知らせいただけると幸いです。 [SSRF] Server Side Request Forgery Server Side Request Forgeryはサーバーに任意のリクエストの実行を強制する攻撃です。例えばnginxの場合、proxy_passディレクティブの第2引数を攻撃者が指定できる場合に攻撃が可能になります。 どうやって見つけるか ここにサーバーを脆弱にする2種類のエラーがあります。 internalディレクティブの欠如。 これは内部リクエストにのみ使うことができることを示すために使用されます 安全でない内部リダイレクト internalディレクティブの欠如 internalディレクティブの欠如でSSRFをすることができる典型的な設定ミスです。
[20170809追記] nginx-1.13.4に ngx_http_mirror_module は含まれました Nginxで、リクエストを複製するmirrorモジュールがコミットされ、何もせずとも使用できるようになりそうです(現状最新コミットをビルドする必要あり)。 例えば本番環境のproxyからリクエストを複製して開発環境に流すような事も出来ます。もちろん複製処理は本来のリクエスト処理をブロックしません。 例えば以下のように、mirrorに来たリクエストを複製してバックエンドサーバに投げるようにしてみます conf server { listen 80 ; server_name localhost; mirror_request_body on; log_subrequest on; location /mirror { mirror /proxy; #/proxy宛にリクエストを
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました HTTPサーバとしてnginxを使っているケースは多いかと思います。しかし設定に関する情報はまだまだ多くはなく、動くように設定はしても、それがベストなのかどうか判断できない方も多いのではないでしょうか。 そんな方にお勧めなのがGixyです。nginxの設定ファイルを解析して改善案を提示してくれます。 Gixyの使い方 Gixyのインストールは pip でできます。 pip install gixy 後はnginxの設定ファイルを指定するだけです。 $ gixy /path/to/nginx.conf ==================== Results =================== Problem: [host_spoofing] The proxied Host h
nginxはworkerプロセスの数をCPUコア（スレッド）数で決定するworker_processes autoという便利設定があります。 これが多用されているのは、nginxがノンブロッキングでリクエスト処理を行うため、コンテキストスイッチなどを考慮した場合に、コア数で立ち上げておけば効率よくCPUを使い切れるという前提があるからです。 一方で、例えば僕の用途では、現在画像の処理だったりとか、ngx_mrubyのようにリクエストの過程で一部ブロッキングされるような処理も増えてきているため、コア数以上の値に設定しておいた方が性能を発揮できるような状況も増えてきています。 そうなると、現状、非常に便利な設定であるauto設定を使えずに静的に数字を設定する必要があり、例えばサーバリプレース時には古いコア数を考慮した値になっていたりして、リプレース後にCPUのコア設定がそのままで性能が出せてい
reverse proxyサーバとしてよく使われているnginxですが、意外にハマりやすい罠があったりします。 今回は、proxy_hide_header, proxy_set_header, add_header等で設定内容を複数コンテキストに分割する際にはまりがちな点を紹介します。 概要 どのようなときにハマるのかストーリー 同様の動きをする他のヘッダ達 ドキュメント上ではどのように扱われているのか more_set_headersはまた違う動きをする あるディレクティブがそのように動くかどうかどのように調べればいいか あとがき この記事によって今後書きたくなった記事 概要 上記3つのディレクティブについては、基本的には現在のコンテキストにそのディレクティブがない時に限って上位のコンテキストで設定された値が継承される 他にもaccess_logディレクティブなどでも同様の動きをするよう
nginx Advent Calendar 2015 の6日目です。 http://qiita.com/advent-calendar/2015/nginx はじめに nginx の cache でディスクが溢れては大変ですので、データ使用量の制限の仕方が気になりますよね。 http://www.slideshare.net/Nginx/nginx-highperformance-caching/19 この資料によると、以下のように消えるそうです。 期限の切れたキャッシュを消す (例では10分) max_size から溢れる場合は LRU で消す 疑問 どういうタイミングで消すんだろう 具体的にどうやって消してるんだろう といった所が気になるので、対応するソースを貼り付けます。 nginx-1.9.1 のソース キャッシュを消すタイミング タイマーで回してます。ただし消え具合によって間隔を
動的サムネイル生成 サムネイルは、ユーザアップロード画像を扱うアプリではほぼ間違いなく使われると思う。 サムネイルの生成には、先に作っとくか、後で作るかの2つの方式があるように思う。(気が向いた時とかナシとすると) 先に作っとく サムネイルを先に作る。 つまりは画像アップロードをキータイミングとして画像処理をかけ、 参照するときには静的な画像を見る方法。 メリットは参照に処理を挟まないので高速に動作することが期待できること。 しかしデメリットとして後から画像サイズを変更しようとすると、画像処理が全部やり直しになる。 また、近年ではCDNを使えば静的画像の参照が早かろうがあまり効果が無いことが多い。 後で作る そこで参照側からパラメーターを与えて、リクエストが来た時に画像処理をかける方法をみてみる。 一見参照するたびに画像生成するのは効率が悪すぎる印象があるけど、 その分ちょくちょくサムネイ
Apacheモジュール作成は以前のエントリの通り手軽に出来ます。 Apacheモジュールの作成とgdbとloggerでのデバッグ方法 - よねのはてな 今回は、Nginxでモジュール作成してみたいという人向けです。 Nginxにおける処理の流れと押さえておきたい構造体、モジュール作成方法をのせておきます。 Nginx http://nginx.net/ そもそもNginxってなんだ？という人は軽量超高速なHTTPサーバという理解でOKです。 実際にはReverse Proxy、Mail Proxyとしても使用可能で、ライセンスはNSD系。 Nginxについては以下を参照下さい。 パフォーマンス比較 http://www.joeandmotorboat.com/2008/02/28/apache-vs-nginx-web-server-performance-deathmatch/ Ngin
米NGINXは、同社が開発するWebサーバNGINX上で動作するJavaScript仮想マシン「nginScript」の最初のプレビュー版を、サンフランシスコで開催中のNGINXの開発者向けカンファレンス「nginx.conf 2015」において9月23日（現地時間）に公開した。 nginScriptは、NGINXの設定に役立つ機能を追加したJavaScriptの実装で、NGINXの設定を簡単に修正または作成でき、アプリケーションレベルで動作するため既存アプリケーションの安定性やセキュリティ、拡張性を保ったままでのリファクタリングを可能にする。 全体的には、仮想マシンとバイトコード・コンパイラ、および組み込み向けの文法を備えたJavaScriptで構成されている。また、仮想マシンはWebブラウザ経由での使用に最適化されており、リクエストごとに個々の仮想マシンが動作するためガベージコレクショ
解説 worker_processes auto; - Nginx本体のプロセス数、autoにしてnginx内部判定に任せるのは賢明 worker_rlimit_nofile 100000; - workerプロセスが最大に開けるファイル数の制限。このように設定したら、ulimit -a以上のファイル数を処理できるようになり、too many open files問題を回避できる worker_connections 2048; - 一つのworkerプロセグが開ける最大コネクション数 multi_accept on; - できるだけクライアントからのリクエストを受け取る use epoll; - Linuxカーネル2.6以上の場合はepoll、BSDの場合kqueue server_tokens off; - セキュリティ対策です、エラー画面のnginxバージョン番号を非表示 sendf
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
