はじめに 僕は Nginx を使用した Web アプリケーションで SSL/TLS を使用する場合は、設定ファイルで ssl_protocols を ssl_ciphers を明記しなくてはならないと思い込んでいました。そのため、いつも Mozilla SSL Configuration Generator からディレクティブをコピペしていました。しかし、これらのディレクティブを省略しても Qualys SSL LABS SSL Server Test で高スコアを出せることが分かりました。では省略した場合にはプロトコルや暗号スイートの指定はどうなるのか、調べてみました。 省略した場合の挙動 公式ドキュメント Nginx » Configuring HTTPS servers の冒頭に答えはありました。 The directives ssl_protocols and ssl_cipher

chimaira.org を載せているNginxが古いままです。 [hiyama ~]$ /usr/local/nginx/sbin/nginx -v nginx version: nginx/0.7.64 [hiyama ~]$ 2012-03-09現在の安定版は、version 1.0.13 です。入れ替えなくちゃね。Nginxはダウンタイム・ゼロで入れ替える方法があります。それを試してみることにします。 次の記事を参考にしました。 http://www.softwareprojects.com/resources/programming/t-recompileupgrade-nginx-binary-with-no-down-time-1520.html [追記]最後に追記した方法が一番簡単そうです。[/追記] 現状はどうなっている そもそもシステム環境全体が古いのですが、今回は動い

SSL証明書発行まではApacheでSSL(その勘所)と全く同じ。SSLs.comでの証明書の種類選択もApache2用で良い。 と、いうか証明書の種類にNginxという選択肢がない(2015年12月現在) SSLサーバ証明書 例えばSSLs.comで購入するとSSL証明書はComodoやGeotrustからメールで送付されて来る。そのメールにRapidSSLの場合は本文に、PositiveSSLの場合は本文(Web Server CERTIFICATE以下)と添付ファイル(ZIPファイル中の申請したホスト名orドメイン名.csrという名前のファイル)の両方にSSLサーバー証明書があるので/usr/local/etc/nginx/ssl/example/にserver.crtというファイル名で保存。(path/ファイル名は任意) SSLサーバー証明書の例 -----BEGIN CERTIF

HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki

Analytics cookies are off for visitors from the UK or EEA unless they click Accept or submit a form on nginx.com. They’re on by default for everybody else. Follow the instructions here to deactivate analytics cookies. This deactivation will work even if you later click Accept or submit a form. Check this box so we and our advertising and social media partners can use cookies on nginx.com to better

[Nginx]worker_connectionsとworker_rlimit_nofileの値は何がいいのか？nginx worker_connections を上げたいけど、どの程度上げていいのかわからない！ って事で、どこをみてどの値を設定するのがベストなのかいろいろ調べて調査したのでその調査記録になります。 現象 弊社のサービスで以下のNginxエラーが出てしまいました。 worker_connectionsが足りなくなってしまっています。 今回、ここの値を上げるに当たってworker_rlimit_nofileも上げる必要があります。 worker_rlimit_nofileの値は何にすべき？ そもそもworker_rlimit_nofileとは？ Nginxのworker_connectionsの1workerプロセスにおける、 ファイルディスクリプタ の上限値 引用） Ngi

何かのスクリプトで作成した定期バッチのログを logrotate でローテートするようにした場合、バッチが午前4時に起動して10分間実行されると実行中にログローテートされることになります。 バッチスクリプトでログファイルを開きっぱなしにしている場合、ローテートでログファイル名が「hoge.log → hoge.log.1」のように変更されたとしてもinode番号が変わらないのでローテート後の「hoge.log.1」に書き込みが継続します。 ですが logrotate で compress を指定していると、ローテート時にログが圧縮されて元のログファイルは削除されるため、バッチスクリプトでログを開きっぱなしにしているとローテートのタイミングでログの書き込み先を見失って、ローテートの時間以降に発生したログが記録されなくなります。 これを解決するため（にあるわけでは無いと思いますが）、logro

#!/usr/bin/env bash # https://superuser.com/questions/109213/how-do-i-list-the-ssl-tls-cipher-suites-a-particular-website-offers # OpenSSL requires the port number. SERVER=192.168.33.10:443 DELAY=0 ciphers=$(openssl-1.1.0f ciphers 'ALL:eNULL' | sed -e 's/:/ /g') echo Obtaining cipher list from $(openssl version). for cipher in ${ciphers[@]} do echo -n Testing $cipher... result=$(echo -n | openssl-

Disclaimer 私はネットワークの勉強もちゃんとしたことないし、Linux のソース読むのもはじめてな素人です。 何かおかしなところなどあれば、遠慮なくコメント欄でまさかりをお願いいたします。 ソースコードの引用に関して 本文中で Linux のコード／ドキュメントを引用している箇所がありますが、すべてタグ v4.11 のものです。また、日本語のコメント・翻訳文は筆者が入れたものです。 TL; DR Linux のカーネルパラメータ net.ipv4.tcp_tw_recycle は、バージョン4.12から廃止されました。 今後はこの設定は行わないようにしましょう（というかできません）。 一方、net.ipv4.tcp_tw_reuse は安全であり、引き続き利用できます。 …というだけの話なのですが、自分用にメモがてら経緯・背景などを記録しておきます。 なんで気がついたか このパラ

Clone via HTTPS Clone with Git or checkout with SVN using the repository’s web address. # 共有メモリの最大サイズ。サーバーの搭載メモリ(1GB)に合わせて変更 kernel.shmmax = 1073741824 # システム全体の共有メモリ・ページの最大数 kernel.shmall = 262144 # システム全体のプロセス数の上限 kernel.threads-max = 1060863 # システム全体のファイルディスクリプタの上限 fs.file-max = 5242880 # RFC1323のTCPウィンドウ スケーリングを有効にする。 # 64K以上のTCP windowを使えるようになる。 # 巨大なファイルを転送する時に問題になった場合は無効にすると解決されることもある。 net.

Railsアプリケーションをデプロイしようとするとさまざまな問題が生じるため、Railsアプリケーションの開発は好きだけれどもデプロイは嫌いという技術者は少なくありません。本書はアプリケーションのデプロイ時に技術者が直面するさまざまな問題の解決策を体系的にまとめたRailsデプロイガイドです。本書ではまずRailsアプリケーションのデプロイを家探しにたとえて解説します。そして、一連のデプロイ処理の中で、Railsアプリケーションのホスティング方式の選択、デプロイの自動化、サーバ管理、クラスタリング手法といった高度なトピックについて詳しく解説します。 サンプルPDF ・監訳者まえがき、賞賛の声、まえがき ・6章 ・8章 監訳者まえがき 賞賛の声 まえがき 1章　実運用環境に適したアプリケーション 1.1　背景 1.2　ソースコード管理 1.2.1　RailsとSubversion 1.2.2

Firewallなどでちょいちょい出てくるDropとReject。 "拒否"という意味では同じだが、動作に明確な違いがある。 よくごっちゃになってしまうので、今更ながらメモしておこうと思う。

Webアプリケーションの脆弱性を悪用する攻撃からWebサイトを保護するソリューションとして、WAFの導入が進んでいます。 本稿では、オープンソースのWAFであるModSecurity のCore Rule Set（CRS）から「WAFのルール」について解説します。 WAF（Web Application Firewall）とは WAF（ワフ：Webアプリケーションファイアウォール）は、Webアプリケーションの脆弱性を悪用した「個人情報の窃取」や「Webサイト改ざん」などのサイバー攻撃からWebサイトを保護するツールです。 Webアプリケーションを利用するユーザーは、HTTP通信によって情報をやり取りします。ユーザーが書き込みや参照などの操作をすると、要求（リクエスト）がWebサイトに送られ、その結果（レスポンス）をユーザーに返します。このとき、データベースを不正に操作するような通信が紛れて

ここで「ゾーン」はリクエスト中で検査対象となった部分を示しており、「ARGS」ならURLに与えられた引数（GETリクエストの引数）を示している（詳しいドキュメント）。また、この例ではidが1000、cscore0がSQL、score0が8となっていることから、IDが「1000」という検出ルールによって「SQL」というスコアが8に設定され、それによってブロックが行われていることが分かる。 NAXSIに対しWAF Testing Frameworkによるテストを実行する さて、続いてはデフォルト設定のNAXSIに対しWAF Testing Frameworkによるテストを実行してみよう。手順としてはnginx＋ModSecuriy構成の場合とほぼ同様で、nginx.confにリバースプロクシ設定（「proxy_pass http://localhost:8080/;」）を追加してnginx経由

HTTP ガイド リソースと URI ウェブ上のリソースの識別 データ URL MIME タイプ入門 よくある MIME タイプ www 付きと www なしの URL の選択 HTTP ガイド HTTP の基本 HTTP の概要 HTTP の進化 HTTP メッセージ 典型的な HTTP セッション HTTP/1.x のコネクション管理 プロトコルのアップグレードの仕組み HTTP セキュリティ Content Security Policy (CSP) HTTP Strict Transport Security (HSTS) X-Content-Type-Options X-Frame-Options X-XSS-Protection Mozilla web security guidelines Mozilla Observatory HTTP アクセス制御 (CORS) HTTP

概要 Apacheセキュリティ設定と同等程度の設定を目指します。 Apacheとの対比のために、Nginx上設定が不要な項目も設定不要として記載します。 SSLの設定はここでは記載していません。 想定環境 NginxのMainlineの最新版を使います。 現時点(2016/1/27)の最新版は1.9.10なのでそれを使います。 Stableではなく、Mainlineを利用します。 StableとMainlineの違いはnginx開発者コメント：nginx 1.8およびnginx 1.9リリースについてには以下のようにあります。 ステーブルラインとメインラインの重要な違いは、メインラインはインフラストラクチャ操作に影響を与える可能性があり、開発APIの変更がある場合があるため、nginxのサードパーティ製モジュールや拡張機能に影響を及ぼす場合があります。それ以外は、安全にご利用いただけます。

location ~ files.*\.(gif|jpe?g|png|avi|flv|mov)$ { valid_referers none server_names example.com; if ($invalid_referer) { #rewrite ^(.*)$ ; return 403; } } location ディレクティブで設定してみました。 files/ 以下の画像や動画ファイルの拡張子へのアクセス時に、リファラが空もしくは example.com にマッチしない場合は 403 を返します。 また、少し前に流行った(?)画像の置き換えをしたければ、rewrite で別の画像へ飛ばしてあげてください。 ドメインやパスは適宜書き換えてお使いください。

Cross-Site Tracing(XST)という化石のような攻撃手法があります。「化石」と書いたように、既に現実的な危険性はないのですが、XSTに関連して「TRACEメソッドは危険」というコメントを今でも見ることがあります。 このエントリでは、XSTという攻撃手法について説明し、XSTおよびTRACEメソッドについてどう考えればよいかを紹介します。 TRACEメソッドとは HTTP 1.1(RFC2616)では、8種類のメソッドが定義されています。GET、POST、HEADなどはおなじみのものですが、それ以外にPUT、DELETE、OPTIONS、TRACE、CONNECTの5種があります。 このうち、TRACEメソッドは、HTTPリクエストを「オウム返しに」HTTPレスポンスとして返すもので、以下のようにGET等の代わりにTRACEとしてWebサーバーにリクエストします。 TRACE

railsにnginxのproxy cacheをしたくなったので、「rails nginx proxy cache」とググって以下のサイトを参考にしたが、どうしてもキャッシュができなかったので記載する [ バージョン情報 ] nginx: 1.10.2 rails: 4.2.6 [ 参考サイト] https://mattbrictson.com/nginx-reverse-proxy-cache http://www.mk-mode.com/octopress/2014/04/23/nginx-proxy-cache-setting/ nginxでproxy cacheを設定する 先に正解を掲載。 後に掲載する参考サイトとの差分は 1. proxy_ignore_headers "Set-Cookie" "Cache-Control"; でSet-Cookieヘッダーも無視している 2.

http { # proxy_cache_pathとproxy_temp_pathは同じファイルシステム上に配置するのがパフォーマンス上よい # keys_zoneの1mは共有メモリのサイズ。1MiBあたり約8000個のキーを保持できるので、それほど大きくなくて良い # max_sizeは全キャッシュファイルのサイズ合計の上限 # inactiveで指定した期間内にアクセスされなかったキャッシュファイルは、その有効期間に関わらず削除される（デフォルトで10分） proxy_cache_path /var/cache/nginx keys_zone=zone1:1m max_size=1g inactive=24h; proxy_temp_path /var/cache/nginx_tmp; # オリジンから来るCache-Controlを無視する #proxy_ignore_headers

Keep-Alive　について Keep-Aliveは、WEBサーバーとクライアント（ウェブブラウザ）の通信時にHTTP通信を切断せずに、HTTP通信を送受信する仕組みです。WEBサーバーでは同一サーバーに画像、Javaスクリプトファイル、CSSがあり、HTTP通信があるたびにTCP接続を確立・切断を繰り返すと転送率が悪くなるので、Keep-Aliveの設定を有効にすると設定した時間まではTCP接続をタイムアウトしないようにします Nginx の KeepAliveについて Nginx にkeepaliveの設定は、「keepalive_timeout」と「keepalive_requests」があります。 keepalive_timeout 75; keepalive_requests 100; keepalive_timeout は、HTTP通信をタイムアウトせずに待つ秒数となります。

HTTP ガイド リソースと URI ウェブ上のリソースの識別 データ URL MIME タイプ入門 よくある MIME タイプ www 付きと www なしの URL の選択 HTTP ガイド HTTP の基本 HTTP の概要 HTTP の進化 HTTP メッセージ 典型的な HTTP セッション HTTP/1.x のコネクション管理 プロトコルのアップグレードの仕組み HTTP セキュリティ Content Security Policy (CSP) HTTP Strict Transport Security (HSTS) X-Content-Type-Options X-Frame-Options X-XSS-Protection Mozilla web security guidelines Mozilla Observatory HTTP アクセス制御 (CORS) HTTP

本ガイドでは、キャッシュを導入してRailsアプリケーションを高速化する方法を解説します。 「キャッシュ（caching）」とは、リクエスト・レスポンスのサイクルの中で生成されたコンテンツを保存しておき、次回同じようなリクエストが発生したときのレスポンスでそのコンテンツを再利用することを指します。 多くの場合、キャッシュはアプリケーションのパフォーマンスを効果的に増大するのに最適な方法です。キャッシュを導入することで、単一サーバーや単一データベースのWebサイトでも、数千ユーザーの同時接続による負荷に耐えられるようになります。 Railsには、すぐ利用できるキャッシュ機能がいくつも用意されています。本ガイドでは、それぞれの機能について目的を解説します。Railsのキャッシュ機能を使いこなすことで、応答時間の低下や高額なサーバー使用料に悩まされずに、Railsアプリケーションが数百万ビューを

[追記１] 最後で説明しているproxy cacheの設定を修正しました。 [追記２] nginx proxy cacheでキャッシュしない場合の処理を変更しました。 [追記３] スマートフォンや携帯で閲覧した時にキャッシュしない設定を追加しました。 はじめに 大げさな題名ですが、今回はWordPress単体を速くするのではなく、データベースやWebサーバなどの調整、またnginxのproxy cache機能を使って速くする話になります。 サイトの構成によっては、proxy cacheは使えないかもしれませんが、使わなくても5倍程度速くすることはできましたので、参考にしていただければと思います。 今回行うチューニング一覧 DBを最適化するプラグインを導入する APCを導入してPHPを速くする MySQLを速くする 重いWordPressプラグインを外す nginx+FastCGIにする W

ディレクティブはこのモジュールのカテゴリ毎に記述します。ただし、coreモジュールに関してはmainコンテキスト、すなわち、設定ファイル内の最上位の階層に記述します。設定ファイルの構成は次のようになります。 coreモジュールの設定 events { eventモジュールの設定 } http { httpモジュールの設定 } mail { mailモジュールの設定 } httpコンテキストはさらに、バーチャルサーバ（バーチャルドメイン）毎の設定を行うserverディレクティブ、さらにURI毎の設定を行うlocaltionディレクティブにより階層化されます。次のような構成になります。 http { httpモジュールの設定 server { サーバ毎の設定 location PATH { URI毎の設定 } location PATH { URI毎の設定 } ... } server { .

nginxのconfですが、includeとか大量にしていると、うっかり上書きされててハマったことないですか？ 自分は最近ドハマりして、イラッとして、confをdumpできるようにならなかと調べてみました。 で、最新のnginxのソースcloneして読んでたらもうあるじゃんと思ったのですが、 自分のマシンに入ってたnginx(1.6.2)にないので、調べてみたら20150/05/15に入った変更だったのですね。。。 github.com で、1.9.3を手元でコンパイルして試してみました。 nginxのコマンドオプションに-Tが追加されて、これを使うと、confファイルが吐出されるようになります。 # /foo/bar/nginx-1.9.3/objs/nginx -h nginx version: nginx/1.9.3 Usage: nginx [-?hvVtTq] [-s signa

Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

図2●KDDIのシステムでは1月10日を境に、料金算出に使う時刻が過去の日時になった KDDIのシステムは0.5秒単位で経過時間を取得しているため、1970年と2038年の真ん中に当たる1月10日に桁あふれを起こした 今年1月10日は、UNIXの内部時間がスタートする1970年1月1日と、コンピュータの「西暦2038年問題」が起こる2038年1月19日のちょうど中間の日付に当たる（図1[拡大表示]）。1月10日には、KDDIなどさまざまな企業で西暦2038年問題に起因するプログラムの不具合や、その“亜種”とも言うべきトラブルが続発した。表にあるように、不具合が判明した事例だけで六つある。 西暦2038年問題とは、UNIX環境などで協定世界時（UTC）の2038年1月19日3時14分8秒を過ぎると、システムが正しく時刻を認識できなくなることを指す。2038年1月19日になって、1970年1月

はじめに URLには日本語を指定することも可能です。 例えば、はてなブログでもURLのデフォルトを以下のように設定できます。 /entry/2011/11/07/週末は川に行きました　（/entry/日付/タイトル名） 一方、ブラウザでは見える日本語URLをそのままツイッターやメモ帳にペーストすると「%XX%XX...」という謎の変換が行われます。 URLの実体は変換後であるため、例えば日本語URLをプログラムからツイートしようとすると日本語URLでは該当ページに遷移しません。明示的に変換を行う必要があります。 本記事では、日本語URLをnkfで変換し、そのままURLとして添付できるようにする術を補足情報を交えながら紹介します。 日本語URLの変換 UNIX系環境では利用可能な「nkf」コマンドは文字コードの変換に便利です。 # which nkf /usr/bin/nkf日本語URLは「

VPSでRailsアプリを動かすまでの全手順【Rails6, Capistrano, Puma, Nginx, MySQL, HTTPS】RailsnginxCentOSCapistranoSSH VPSを契約してRailsアプリを動かすまでの手順をまとめました。 似たような記事はいくつかありますが、本記事には以下のような特長があります。 ツールのバージョンが比較的新しい Ruby2.7系、Rails6系、MySQL8系、CentOS7系 アプリケーションサーバーにPumaを使用 GitHubのプライベートリポジトリで管理されているアプリでもデプロイできる 独自ドメインに対応 HTTPSに対応 Railsアプリの開発環境をDockerで作成 以下、設定方法です。 OSインストール VPSサービスのコンパネからCentoOS7をインストールします。(以下はさくらのVPSの場合のキャプチャです

Railsアプリの場所を確認まずは、Railsアプリが置いてある場所を確認してみましょう。 「Railsの環境構築」を読みながらRailsアプリを作った方は、以下のようにホームディレクトリの下にRailsアプリがあると思います。 「/home/vagrant/training/training_app」 まずは、この「training_app」を「/opt」の下に移動、またはコピーしましょう。 なぜなら、公開するアプリを置いておく場所として、ホームディレクトリは適切ではないからです。 また、「/home/vagrant」にアクセスできるのは「vagrantユーザー」だけですが、今回は「nginxユーザー」がRailsアプリのディレクトリにアクセスする予定なので、ホームにあると都合が悪いのもあります。 Linuxのディレクトリ構成（構造）とは？Windowsフォルダとの違いを覚える！ Rai

パッケージインストール htpasswd コマンドを利用するため、下記のパッケージをインストール。 Debian 系

Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜Problemが10分で解決するチャットを作ろう〜 開発プロジェクトを進めていくと、チームは様々な課題に直面する。こうした課題は、週次のミーティングや日報で共有して解決していくことが多い。 課題は大小様々だが、特に数時間で解決できるような小さな課題をいかにリアルタイムで解決していくかで、チームのスピード感が大きく変わってくる。 僕のチームでは、リアルタイムの課題解決の為に、社内チャットSlackを社内Twitterのようにする邪道な使い方「分報」という取り組みを実践している。 > 日報の弱点日報の弱点 日報は一日の業務の報告書で、一般的に「進捗状況」「体験」「学習」「課題」が記載される。これらをチームで共有することで暗黙知を減らし、個人とチームを成長されることが目的だ。報告方法はチームによって様々だが、メールをはじめ、

systemctlコマンドでインスタンスを使用して引数を渡す方法を紹介します。 環境 OS：CentOS Linux release 7.7.1908 1. Unit定義ファイルを作成 以下のUnit定義ファイルを作成する。 サービス名（ここではtest） + @ + .serviceとする。 %iを使用する。