NginxからCaddyに変更した際の作業手順、デザイナーにもお勧めの簡単で高性能なWebサーバー
WebサーバーをNginxから、高性能で簡単に構築できるCaddyに変更した際の作業手順を紹介します。 Caddyはクラス最高のセキュリティを誇る、HTTPSを自動的にデフォルトで使用する唯一のサーバーです。証明書の自動更新やTLSクライアント認証なども備えており、Webサーバーとしてもファイルサーバーとしても利用できます。LinuxやBSDをはじめ、WindowsやmacOSでも動作します。 Goodbye Nginx, hello Caddy by Hanna はじめに Webサーバーの準備 Caddyの構成 Systemdの構成 終わりに はじめに 私は最近、私の個人サイトをNginxからCaddyに変更しました。Caddyについて調べてみたところ、さまざまな恩恵が得られるので試してみたいと思っており、以前から計画してきました。 この記事では、Caddyのセットアップ方法、良くなった
nginx でリクエストを複製できるモジュール「ngx_http_mirror_module」 - kakakakakku blog
nginx でリクエストを複製できるモジュール「ngx_http_mirror_module」を使うと，簡易的な「Shadow Proxy」を構築することができる．例えば，本番環境のリクエストの一部を開発環境に流せるようになる．この「ngx_http_mirror_module」は nginx 1.13.4 で実装された機能で，2017年8月リリースなので，最近のバージョンだとデフォルトで使えるようになっている．今回は「リクエストの複製」を試すため，Docker Compose を使って検証環境を構築した． nginx.org 検証環境 今回 Docker Compose を使って，nginx と Sinatra を起動する検証環境を構築した．コンテナは計3種類で，以下の構成図にまとめた．基本は Frontend と Backend でリクエストを処理し，今回は Mirror にもリクエス
Basic認証とIP制限を設定して、Nginxサーバーのセキュリティを高める - Qiita
$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.4 LTS" $ nginx -v nginx version: nginx/1.14.0 Basic認証の設定 Basic認証はもっとも簡単なパスワード認証の一つです。ほぼ全てのブラウザに対応しており、認証用画面を作成することなくパスワード認証を行うことができます。nginxでは、デフォルトで組み込まれているngx_http_auth_basic_moduleを使用してBasic認証を利用できます。 Appacheに付属しているhtpasswdコマンドを使ってパスワードファイルを生成します。 sudo apt install apache2-util
Nginx でIPアドレスによるアクセス制御を行う | DevelopersIO
前回は、Nginx をインストールして、Basic認証 をかけてみました。今回は、IPアドレスでのアクセス制限をしてみます。 EC2の場合、セキュリティグループでもアクセス制限が出来ますが、今回は Nginx の機能を使います。 そのため、セキュリティーグループで、80ポートに対して 0.0.0.0/0 を許可をしておきます。 nginx.conf の構成 具体的な設定を記述する前に、nginx.conf の構成について少し見てみます。 nginx.conf の設定は以下のようなディレクティブの集まりで出来ています。 worker_processes 1; ディレクティブは Nginx の各モジュールによって導入されていて、 モジュールを有効にすることによって、そのモジュールで提供しているディレクティブが利用可能になります。 ディレクティブは各モジュールに対するブロックの中に記述します。
Nginx で Basic 認証 - Qiita
パッケージインストール htpasswd コマンドを利用するため、下記のパッケージをインストール。 Debian 系
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の設定ミスで起こる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の設定ミスで起こるパス トラバーサル - Qiita
はじめに この記事は下記リンクの日本語翻訳記事です 翻訳が誤っている場合はコメントか@no1zy_secまでお知らせいただけると幸いです。 [alias_traversal] Path traversal via misconfigured alias aliasディレクティブは指定されたlocationのパスのreplaceに使用されます。 例えば以下の設定:
Nginxのupstreamに安易にlocalhostと書くと嵌まる罠、またはドメイン名解決の挙動 - Qiita
Nginxで、アクセスしたらちゃんと返ってきているのにログを見ると connect() failed (111:Connection refused) が頻発に発生している謎を調査したら、 いままで知らなかったNginxの挙動にたどり着いたのでメモ。 （ただしよく見るとドキュメントにちゃんと書いてあったというオチ） 問題 [error] 11#11: *21735 connect() failed (111: Connection refused) while connecting to upstream, client: xx.xx.x.x, server: example.com, request: "GET /hogehoge HTTP/2.0", upstream: "http://[::1]:3000/hogehoge", host: "xx.xx.x.x", referrer:
Let's encrypt で 一時ファイルが作成できない時の対策 - Qiita
Webroot プラグインは ${webroot-path}/.well-known/acme-challenge に一時ファイル（ワンタイムトークン） を作成し、Let's Encrypt の認証サーバから HTTP リクエスト（名前解決には DNS のAレコードを使用） で取得することにより、認証を行います。 もし、ウェブサーバの設定によって /.well-known に対して特別な扱いがされている場合には、 /.well-known/acme-challenge 内のファイルに外部からアクセス可能にするために 設定を変更する必要があるかもしれません。
Let's Encrypt で Nginx にSSLを設定する - Qiita
Let's Encrypt で取得したサーバ証明書を Nginxに設定するための手順。 確認した環境は次の通り。 OS: CentOS 7.2 Nginx 1.11 Let's Encrypt 導入の事前準備 証明書を取得したいドメインでアクセスできるサーバを立てておく。 アプリケーションやHTTPサーバのインストールは必ずしも必要ないが、次の2点が必要。 取得したいドメインがDNSで名前解決できる 80番ポートでアクセスできる 以下の操作はそのサーバ上で行う。 certbot のインストール まず、Let's Encrypt のクライアントcertbotをインストール。 インストールと言っても、git で cloneするだけ。 以下の例では、/usr/local にインストールしているが、場所はどこでもよい。 $ cd /usr/local $ git clone https://git
Let’s Encrypt で証明書を発行して運用するための nginx の設定 – ymyzk’s blog
この記事では Let’s Encrypt で証明書を発行し, nginx で利用するための設定を紹介します. Nginx をアプリケーションサーバーのためのプロキシとして利用している場合を想定して, Let’s Encrypt のための webroot を別に設定しています. 概要 Let’s Encrypt では様々な方法での認証・証明書のインストール方法がプラグインとして提供されています. Nginx 用のプラグインも開発されていますが, 現時点で experimental となっているようなので, webroot プラグインを利用するのが一般的なようです. この記事では /var/www/letsencrypt に Let’s Encrypt の webroot プラグインによる認証のためのディレクトリを作成し, 以下のようなコマンドで証明書の発行を行えるようにすることを目標とします
Nginxへの変更に伴うリバースプロキシのテストの改善 - クックパッド開発者ブログ
Nginxへの変更に伴うリバースプロキシのテストの改善 SREグループの菅原です。 クックパッドではブラウザ用Webサイトのリバースプロキシ用のWebサーバとして長らくApacheを使っていたのですが、最近、Nginxへと変更しました。 Nginxへの変更に当たって、構成管理の変更やテストの改善を行ったので、それらについて書きたいと思います。 リバースプロキシのリニューアルについて まず、ブラウザ用Webサイトの基本的なサーバ構成は以下のようになります。 リバースプロキシはELB経由でリクエストを受けて、静的ファイルの配信やキャッシュサーバ・Appサーバへの振り分けを行います。 リバースプロキシとして利用されているApacheは、長年の改修により設定が煩雑なものとなっており、設定の追加や変更にコストがかかる状態になっていました。 また、Apacheの設定ファイルはItamaeでは管理されて
NginxがHTTP2サーバプッシュに対応したので試す - ASnoKaze blog
追記 [nginx-announce] nginx-1.13.9 http://mailman.nginx.org/pipermail/nginx-announce/2018/000207.html 1.13.9でサーバプッシュがサポートされました 先程、Nginxでサーバプッシュをサポートするコミットが入ったので試す。 HTTP/2: server push. http://hg.nginx.org/nginx/rev/641306096f5b ビルド $ git clone https://github.com/nginx/nginx.git $ cd ./nginx $ ./auto/configure --with-http_ssl_module --with-http_v2_module $ make $ sudo make install #一旦インストールしてしまう 設定 一
nginxで"client intended to send too large body"が発生した時の対策方法 - Qiita
nginx が稼働しているWebページで、フォームからファイルをアップロードしようとしたら、 "1 client intended to send too large body: 1367171 bytes" というエラーが発生しました。 これは、nginx が POST の最大サイズを超えるデータが送られてきた場合に発生するエラーのようです。 http://wiki.nginx.org/HttpCoreModule#client_max_body_size によると、nginx ではデフォルトで1MBまでのデータしか受け付けないようです。 nginx が1MBより大きなデータを受け取れるようにするには、nginx.conf で client_max_body_size ディレクティブを設定します。 client_max_body_size は http, server, location
nginxで特定ホスト以外からのアクセスをメンテナンス画面にする方法 - 酒日記 はてな支店
Apacheで特定ホスト以外からのアクセスをメンテナンス画面にする方法 - 元RX-7乗りの適当な日々 の nginx 版。 nginx.conf でこんな感じですかね。 http { server { listen 80; root /tmp; error_page 503 /503.html; location / { if ($remote_addr ~ ^127\.0\.0\.1$ ) { break; } if (-f "/tmp/503") { return 503; } } location /503.html { } } } 127.0.0.1 からのアクセスはなにもしない (break で残りの rewrite をキャンセル) /tmp/503 というファイルが存在する場合のみ status code 503 を返す 最後の location /503.html がないと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
システム会社の一台のWebサーバー（Nginx）でのSSL証明書の更新作業の見積もりが20万円でした。ファイルをアップロードして再起動するだけですよね？ぼったくりだと思いますか？
Nginxの脆弱性を悪用する攻撃準備中か、ダークウェブの観察で判明（Antuit） | ScanNetSecurity
nginxでのメンテナンス画面表示 - Qiita
Permission denied - nginx and uwsgi socket