タグ

nginxに関するmasa0x80のブックマーク (15)

  • ひとつのポートで異なる通信プロトコルを nginx の nginScript で振り分ける - OPTiM TECH BLOG

    インダストリー事業部のイチノです。リモート製品 (Optimal Remote, Optimal Second Sight, ポケットドクターなど遠隔地とコミュニケーションするための製品) で使われるコア技術をまとめた Communication SDK を担当しています。 記事では、ひとつのポートで異なる通信プロトコルを、 nginx で振り分けたい場合に、役立つ方法を紹介します。 80 ポートや 443 ポートのみ許可しているセキュアなネットワーク環境へ、複数のプロトコルを持ったサービスを提供するといった場合に使える方法です。 nginx によるリバースプロキシの振り分け方法として、以下の6つが存在します。 IP アドレスでの振り分け ポート番号での振り分け SSL/TLS の SNI による振り分け HTTP のパスによる振り分け HTTP の Host ヘッダーによる振り分け

    ひとつのポートで異なる通信プロトコルを nginx の nginScript で振り分ける - OPTiM TECH BLOG
  • nginxの設定ミスで起こるパス トラバーサル - Qiita

    はじめに この記事は下記リンクの日語翻訳記事です 翻訳が誤っている場合はコメントか@no1zy_secまでお知らせいただけると幸いです。 [alias_traversal] Path traversal via misconfigured alias aliasディレクティブは指定されたlocationのパスのreplaceに使用されます。 例えば以下の設定:

    nginxの設定ミスで起こるパス トラバーサル - Qiita
  • nginxの設定ミスで起こるHTTP Splitting - Qiita

    はじめに この記事は下記リンクの日語翻訳記事です 翻訳が誤っている場合はコメントか@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 または

    nginxの設定ミスで起こるHTTP Splitting - Qiita
  • nginxの設定ミスで起こるSSRF - Qiita

    攻撃者はプロキシされたアドレスを完全に制御できるため、Nginxの代わりにリクエストを送信することが可能になります。 安全でない内部リダイレクト サーバー設定に internal locationがあり、そのlocationがプロキシされたサーバーのアドレスとしていずれかのリクエストデータを使用しているとします。 例: location ~* ^/internal-proxy/(?<proxy_proto>https?)/(?<proxy_host>.*?)/(?<proxy_path>.*)$ { internal; proxy_pass $proxy_proto://$proxy_host/$proxy_path ; proxy_set_header Host $proxy_host; } Nginxのドキュメントによると、内部リクエストは下記のようにあります。 requests re

    nginxの設定ミスで起こるSSRF - Qiita
  • Nginxで、リクエストを複製するmirrorモジュールが標準搭載された - ASnoKaze blog

    [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宛にリクエストを

    Nginxで、リクエストを複製するmirrorモジュールが標準搭載された - ASnoKaze blog
  • Gixy - nginxの設定ファイルを静的解析して改善提案

    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

    Gixy - nginxの設定ファイルを静的解析して改善提案
  • nginxのworkerプロセス数をCPUコア数の倍数で自動的に設定できるモジュールを書いた - 人間とウェブの未来

    nginxはworkerプロセスの数をCPUコア(スレッド)数で決定するworker_processes autoという便利設定があります。 これが多用されているのは、nginxがノンブロッキングでリクエスト処理を行うため、コンテキストスイッチなどを考慮した場合に、コア数で立ち上げておけば効率よくCPUを使い切れるという前提があるからです。 一方で、例えば僕の用途では、現在画像の処理だったりとか、ngx_mrubyのようにリクエストの過程で一部ブロッキングされるような処理も増えてきているため、コア数以上の値に設定しておいた方が性能を発揮できるような状況も増えてきています。 そうなると、現状、非常に便利な設定であるauto設定を使えずに静的に数字を設定する必要があり、例えばサーバリプレース時には古いコア数を考慮した値になっていたりして、リプレース後にCPUのコア設定がそのままで性能が出せてい

    nginxのworkerプロセス数をCPUコア数の倍数で自動的に設定できるモジュールを書いた - 人間とウェブの未来
  • nginxでproxy_hide_header, proxy_set_header, add_headerを書く時にはまりがちな罠 - でこてっくろぐ ねお

    reverse proxyサーバとしてよく使われているnginxですが、意外にハマりやすい罠があったりします。 今回は、proxy_hide_header, proxy_set_header, add_header等で設定内容を複数コンテキストに分割する際にはまりがちな点を紹介します。 概要 どのようなときにハマるのかストーリー 同様の動きをする他のヘッダ達 ドキュメント上ではどのように扱われているのか more_set_headersはまた違う動きをする あるディレクティブがそのように動くかどうかどのように調べればいいか あとがき この記事によって今後書きたくなった記事 概要 上記3つのディレクティブについては、基的には現在のコンテキストにそのディレクティブがない時に限って上位のコンテキストで設定された値が継承される 他にもaccess_logディレクティブなどでも同様の動きをするよう

    nginxでproxy_hide_header, proxy_set_header, add_headerを書く時にはまりがちな罠 - でこてっくろぐ ねお
  • SSLセッションキャッシュを共有したいだけの人生だった

    @nojima (Cybozu, Inc) nginx tech talks 2016-02-08 http://eventdots.jp/event/578421

    SSLセッションキャッシュを共有したいだけの人生だった
  • nginx cache のディスク溢れ対策 - Qiita

    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 のソース キャッシュを消すタイミング タイマーで回してます。ただし消え具合によって間隔を

    nginx cache のディスク溢れ対策 - Qiita
  • ngx_mrubyでつくる簡単な動的サムネイル生成サーバー - スペクトラム

    動的サムネイル生成 サムネイルは、ユーザアップロード画像を扱うアプリではほぼ間違いなく使われると思う。 サムネイルの生成には、先に作っとくか、後で作るかの2つの方式があるように思う。(気が向いた時とかナシとすると) 先に作っとく サムネイルを先に作る。 つまりは画像アップロードをキータイミングとして画像処理をかけ、 参照するときには静的な画像を見る方法。 メリットは参照に処理を挟まないので高速に動作することが期待できること。 しかしデメリットとして後から画像サイズを変更しようとすると、画像処理が全部やり直しになる。 また、近年ではCDNを使えば静的画像の参照が早かろうがあまり効果が無いことが多い。 後で作る そこで参照側からパラメーターを与えて、リクエストが来た時に画像処理をかける方法をみてみる。 一見参照するたびに画像生成するのは効率が悪すぎる印象があるけど、 その分ちょくちょくサムネイ

    ngx_mrubyでつくる簡単な動的サムネイル生成サーバー - スペクトラム
  • NginxでのModuleの作り方 - よねのはてな

    Apacheモジュール作成は以前のエントリの通り手軽に出来ます。 Apacheモジュールの作成とgdbloggerでのデバッグ方法 - よねのはてな 今回は、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でのModuleの作り方 - よねのはてな
  • NGINX、WebサーバNGINX上で利用できるJavaScript「nginScript」を公開

    NGINXは、同社が開発するWebサーバNGINX上で動作するJavaScript仮想マシン「nginScript」の最初のプレビュー版を、サンフランシスコで開催中のNGINXの開発者向けカンファレンス「nginx.conf 2015」において9月23日(現地時間)に公開した。 nginScriptは、NGINXの設定に役立つ機能を追加したJavaScriptの実装で、NGINXの設定を簡単に修正または作成でき、アプリケーションレベルで動作するため既存アプリケーションの安定性やセキュリティ、拡張性を保ったままでのリファクタリングを可能にする。 全体的には、仮想マシンとバイトコード・コンパイラ、および組み込み向けの文法を備えたJavaScriptで構成されている。また、仮想マシンはWebブラウザ経由での使用に最適化されており、リクエストごとに個々の仮想マシンが動作するためガベージコレクショ

    NGINX、WebサーバNGINX上で利用できるJavaScript「nginScript」を公開
  • nginx最大パフォーマンスを出すための基本設定 | Node.js技術

    解説 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

  • nginxでリバースプロキシ時のエラーページを設定する - Qiita

    nginxでproxy_passを使った時、通常はerror_page指定を無視してそのままのレスポンスを返す。 server { listen 80; server_name somewhere; error_page 404 /notfound.html; # 見に行かない location /app/ { proxy_pass http://internal/app/; } } server { listen 80; server_name somewhere; error_page 404 /notfound.html; # 404の場合参照される。 error_page 403 =404 /notfound.html; # 403の場合404に変換される。 location /app/ { proxy_pass http://internal/app/; proxy_interc

    nginxでリバースプロキシ時のエラーページを設定する - Qiita
  • 1