面倒くさいから nginx の LDAP 認証モジュール公開したよ | IIJ Engineers Blog
2021年11月にセキュリティ情報統括室に所属。頑固なので、ニックネームだけでもやわらかくひらがなにしてみました。普段はハニーポットで収集したDDoSの発生源であるマルウェアを対象に分析しています。 おはようございます。こんにちは。こんばんは。ふぇにっくちゅん です。 今回紹介するのは nginx で利用できる LDAP 認証モジュール（ngx_auth_mod）です。 nginx は Web サーバやリバースプロキシなどを構築でき、オープンソースとして公開されています。 nginx の詳細はこちらに記載されています。 本記事で紹介する ngx_auth_mod は CATSHAND と呼ぶ情報共有システムのモジュールとして開発したものです。 情報共有についての記事「情報を流れに乗せよう：セキュリティ調査の共有方法」も併せて一読ください。 CATSHAND のシステムは Web サーバとし
nginxの設定ファイル nginx.conf の読み方 超入門 - 或る阿呆の記
設定ファイルの最初の状態 nginxの設定ファイルは、/etc/nginx/nginx.confです。Version 1.6.3においては、最初は以下の状態になっています。 user nginx; worker_processes auto; error_log /var/log/nginx/error.log; pid /run/nginx.pid; events { worker_connections 1024; } http { log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/l
nginx - 基本ディレクティブ(その他)
workerプロセスのユーザーとグループは以下の状況で確定します。 nginx.conf内でuserディレクティブを指定されている場合には、その値を利用されます。 nginx.conf内でuserディレクティブを未指定、かつnginxインストール時のオプション--user=ユーザ名 --group=グループ名で指定時には、 --user及び--groupオプションで指定されたユーザ名とグループ名が利用されます。 nginx.conf内でuserディレクティブを未指定、かつnginxインストール時のオプション--user=ユーザ名 --group=グループ名を未指定時には、 nobodyユーザ、nobodyグループが指定されます。 私の環境は、Ubnutu16.04LTSにapt-getでnginx1.12.0をインストールしました。 apt-getインストール時には、--user=ngin
APIサーバを立てるためのCORS設定決定版 - Qiita
タイトルは釣り、かつ、自分のための備忘録です。 マイクロサービスアーキテクチャでサービスを構築すると、APIサーバをサービスごとに立てるわけですが、 ブラウザ上のJSエンジンからAPIサーバを叩く時に避けて通れないのが、Same-Origin Policy（同一生成元ポリシー）によるCORS (Cross-Origin Resource Sharing)制限です。 これを回避するには、APIサーバ側でAccess-Control-*ヘッダを適切に返す必要がありますが、どう設定するべきかの情報が意外と少ないので（自分的）これが決定版！ という設定を考えてみました。 結論 nginxの場合の設定例です。 server { listen 80; server_name site.localhost; charset utf-8; root /var/www/app/public; locatio
nginxのステータスコード444 · yuuki/yuuki
nginxのステータスコード444 nginx独自のステータスコード444は、レスポンスヘッダを返さずにコネクションを切断できる。レスポンスヘッダを返さないので、ステータスコード444をクライアントが受け取ることはない。 http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#return The non-standard code 444 closes a connection without sending a response header. DoS攻撃など、特定条件のアクセスをBANするときに、なるべく計算機リソース消費を抑えたいときに使えるはず。 403を返すときなどと比べて、レスポンス送信のためのCPUコストを節約 403を返すときなどと比べて、レスポンスヘッダ分のネットワーク帯域を節約 HTTP Keepalive
NGINXのパフォーマンスをスレッドプールで9倍にする
はじめに NGINXが接続処理に非同期かつイベント駆動のアプローチを用いていることは、よく知られています。つまり（従来型アーキテクチャのサーバのように）、専用プロセスやリクエストごとのスレッドを他に作ることなく、一つのワーカープロセスで複数の接続とリクエストを処理できるということです。これを実現するために、NGINXはソケットをノンブロッキングモードで実行し、epollやkqueueといった効率的なメソッドを用いています。 全負荷のかかるプロセスは少なく（通常1CPUコアごとに1つのみ）一定のため、消費されるメモリは少なく済み、タスク切り替えのためにCPUサイクルが無駄遣いされることもありません。このアプローチのメリットは、NGINXの実例を通してよく知られています。NGINXは、何百万もの同時リクエストやスケールを非常にうまく処理します。 各プロセスが追加メモリを消費する。また、プロセス
軽量高速Webサーバのnginxで静的コンテンツ配信とキャッシュコントロール
nginxとは？ nginxはロシアで開発されている軽量で高速なWebサーバです。 現在シェアは 7% 近くあるようです。もちろんApacheに比べれば少ないですが、Apache 55%、IIS 25%, nginx 7%で3番目に使われているWebサーバになります。 昔は、Pound+Lighttpd+Apacheの組み合わせをよく使っていましたが、ここ数年はnginx+Apacheとかになりました。 主に、静的コンテンツをnginxが受け持ち、PHPなどの動的コンテンツはApacheに渡す形になります。Railsを使う場合は、nginx+Unicornの組み合わせが多いです。 いまさらな感じもありますが、インフラ周りの見直しも含めて紹介したいと思います。 静的コンテンツをnginxに任せる nginx+Apacheの場合の設定は次のようになります。（nginxがport 80、Apac
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Top IaC,Kubernetes,CI/CD,SecOps Services by DevOpsHarbor
Nginxリバースプロキシ+ URL書き換え
anopara
http://nginx.org/en/CHANGES
leaseweb