<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>nginx on {bjørn:johansen}</title>
    <link>https://bjornjohansen.com/tag/nginx/</link>
    <description>Recent content in nginx on {bjørn:johansen}</description>
    <generator>Hugo -- 0.118.2</generator>
    <language>en-US</language>
    <lastBuildDate>Mon, 12 Feb 2018 22:38:40 +0000</lastBuildDate>
    <atom:link href="https://bjornjohansen.com/tag/nginx/feed.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>How to mitigate CVE-2018-6389 – the load-scripts.php DoS “attack” in WordPress</title>
      <link>https://bjornjohansen.com/load-scripts-php/</link>
      <pubDate>Mon, 12 Feb 2018 22:38:40 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:64653138-3531-5034-b836-633934386261</guid> 
      <description>A little sensationalist written blog post by Barak Tawily claims that WordPress is vulnerable to a DoS attack because of the load-scripts.php file which concatenates JavaScript files on the fly.</description>
    </item>
    <item>
      <title>How to do an Nginx redirect</title>
      <link>https://bjornjohansen.com/nginx-redirect/</link>
      <pubDate>Sat, 15 Oct 2016 13:45:01 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:61646133-3162-5634-a232-346265303235</guid> 
      <description>Nginx is an extremely efficient and quite flexible web server. When you want to do a redirect in Nginx, you have a few options to select from, so you can choose the one that suits you best to do an Nginx redirect.</description>
    </item>
    <item>
      <title>Let’s Encrypt for Nginx</title>
      <link>https://bjornjohansen.com/letsencrypt-nginx/</link>
      <pubDate>Thu, 31 Mar 2016 20:48:31 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:38623063-3465-5338-b964-656234343537</guid> 
      <description>Let’s install an SSL-certificate from Let’s Encrypt for Nginx.</description>
    </item>
    <item>
      <title>How to upgrade to PHP 7 on Ubuntu</title>
      <link>https://bjornjohansen.com/upgrade-to-php7/</link>
      <pubDate>Fri, 04 Dec 2015 11:31:31 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:39376630-6561-5537-a561-653133613133</guid> 
      <description>Depending on your time zone, PHP 7 was finally released on 3rd/4th of December 2015. Even though the general recommendation for production servers is to wait for a little bit and gather some experiences before upgrading, some of us want to jump right on and upgrade to PHP 7.</description>
    </item>
    <item>
      <title>Restrict allowed HTTP methods in Nginx</title>
      <link>https://bjornjohansen.com/restrict-allowed-http-methods-in-nginx/</link>
      <pubDate>Wed, 21 Oct 2015 18:22:11 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:62313264-3030-5033-b530-326262653633</guid> 
      <description>&lt;p&gt;Security vulnerabilities are often exploits of software that fails when trying to deal with unexpected input. Other times they are exploits of a misconfiguration or a service that unintentionally was open to the public.&lt;/p&gt;
&lt;p&gt;For the above reasons, we should limit as much as possible what services are exposed to the public and limit as much as possible what they do and accept from the visitors. To follow those security principles, we should only allow the HTTP methods for which we, in fact, provide services. Under all normal circumstances, that would be the methods &lt;code&gt;GET&lt;/code&gt;, &lt;code&gt;POST&lt;/code&gt; and &lt;code&gt;HEAD&lt;/code&gt;.&lt;/p&gt;
</description>
    </item>
    <item>
      <title>Block access to PHP files on your WordPress site with Nginx</title>
      <link>https://bjornjohansen.com/block-access-to-php-files-with-nginx/</link>
      <pubDate>Mon, 19 Oct 2015 20:43:56 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:64396231-3165-5362-a165-633364313838</guid> 
      <description>In your WordPress site, there are directories that include PHP files that visitors should never be able to access directly. They are only there for WordPress to function as an application that runs on your server. But because of WordPress’ directory and file structure, they are kind of accessible to the public. All of them are meant to be part of a larger application – WordPress, that is – and should not cause any harm if called directly – that we know. Some of the files execute some code even when ran standalone. An attacker might know of a clever way to make that code run in an unexpected manner, causing harm. To be on the safe side, we should deny access to all these PHP files from the outside world. Since we block access to them in our Nginx configuration, PHP will still run them as usual and WordPress will work just fine.</description>
    </item>
    <item>
      <title>Restrict access to the WordPress dashboard by IP address in Nginx</title>
      <link>https://bjornjohansen.com/access-wordpress-by-ip-in-nginx/</link>
      <pubDate>Sat, 17 Oct 2015 13:28:16 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:61386432-6365-5433-a537-643632316230</guid> 
      <description>If you have a static IP address, like from your office, or &lt;a href=&#34;https://www.bjornjohansen.com/setting-up-your-own-pptp-vpn&#34;&gt;your own private VPN&lt;/a&gt;, you can increase your security tremendously by restricting all logins to that IP address. The effect is that even if an attacker knows your login credentials, they will not be able to log in or access any part of the WordPress Dashboard.</description>
    </item>
    <item>
      <title>Redirect all HTTP requests to HTTPS with Nginx</title>
      <link>https://bjornjohansen.com/redirect-to-https-with-nginx/</link>
      <pubDate>Thu, 15 Oct 2015 19:15:43 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:65646238-3538-5639-b735-303636353639</guid> 
      <description>All login credentials transferred over plain HTTP can easily be sniffed by an MITM attacker, but is is not enough to encrypt the login forms. If you are visiting plain HTTP pages while logged in, your session can be hijacked, and not even &lt;a href=&#34;https://www.bjornjohansen.com/two-factor-authentication-for-wordpress&#34;&gt;two-factor authentication&lt;/a&gt; will protect you. To protect all info sent between your visitors – which includes you – and your web server, we will redirect all requests that are coming over plain HTTP to the HTTPS equivalent.</description>
    </item>
    <item>
      <title>Exclude certain requests from the Nginx access log</title>
      <link>https://bjornjohansen.com/exclude-requests-from-nginx-access-log/</link>
      <pubDate>Sun, 11 Oct 2015 14:33:03 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:32653466-6236-5261-b834-346164313439</guid> 
      <description>Logs are nice and all that, but sometimes certain entries are there just to fill up the logs or are cluttering them. Here’s a few ways to exclude requests – by URL or visitor IP – from the Nginx access log.</description>
    </item>
    <item>
      <title>Enable HTTP/2 on Nginx</title>
      <link>https://bjornjohansen.com/enable-http2-on-nginx/</link>
      <pubDate>Tue, 22 Sep 2015 19:26:43 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:31623638-3132-5266-b361-323766666534</guid> 
      <description>Experimental support for HTTP/2 became available in Nginx version 1.9.5 (mainline). It is really easy to enable, and I’ll show you how.</description>
    </item>
    <item>
      <title>HTTP Public Key Pinning (HPKP)</title>
      <link>https://bjornjohansen.com/public-key-pinning/</link>
      <pubDate>Thu, 16 Jul 2015 11:39:19 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:36656436-3236-5036-a238-646136336161</guid> 
      <description>&lt;a href=&#34;https://www.bjornjohansen.com/securing-nginx-ssl&#34;&gt;Using HTTPS&lt;/a&gt; helps preventing someone from snooping your username/password or hijacking your sessions. &lt;a href=&#34;https://www.bjornjohansen.com/optimizing-https-nginx&#34;&gt;Using HSTS&lt;/a&gt; makes sure the connection stays on HTTPS, even if a MITM tries to redirect you to the plain HTTP version of a web site. But it is easier than you might think for a MITM to use a rogue certificate, making you believe everything is fine. HTTP Public Key Pinning (HPKP) helps the browser check that everything actually is fine.</description>
    </item>
    <item>
      <title>Running HHVM with fallback to PHP-FPM</title>
      <link>https://bjornjohansen.com/hhvm-with-fallback-to-php/</link>
      <pubDate>Wed, 03 Dec 2014 21:57:29 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:37333362-6639-5337-a638-343161393433</guid> 
      <description>HHVM can really speed up your PHP-based web site. Most reports are somewhere in the range of 2–4x faster. Unfortunately, HHVM isn’t very stable and will suddenly die, just of the blue, from time to another. Fortunately, if you’re running Nginx it’s really easy to set up PHP-FPM as a fallback.</description>
    </item>
    <item>
      <title>Running HHVM instead of PHP with Nginx on Ubuntu</title>
      <link>https://bjornjohansen.com/running-hhvm-instead-php-nginx-ubuntu/</link>
      <pubDate>Mon, 12 May 2014 20:34:25 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:36663237-3735-5634-b439-663263646166</guid> 
      <description>Since version 3.9, WordPress have been 100% compatible with &lt;a href=&#34;http://hhvm.com/&#34; title=&#34;HipHop Virtual Machine&#34;&gt;HHVM&lt;/a&gt; and I have begun replacing PHP with it on a few of my servers to experiment.</description>
    </item>
    <item>
      <title>Optimizing HTTPS on Nginx</title>
      <link>https://bjornjohansen.com/optimizing-https-nginx/</link>
      <pubDate>Sat, 18 Jan 2014 23:49:30 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:64373039-3439-5939-a565-376661666535</guid> 
      <description>Now that you have secured &lt;a href=&#34;https://www.bjornjohansen.com/securing-nginx-ssl&#34;&gt;Nginx with HTTPS&lt;/a&gt; and &lt;a href=&#34;https://www.bjornjohansen.com/enabling-spdy-nginx&#34;&gt;enabled SPDY&lt;/a&gt; &lt;a href=&#34;https://www.bjornjohansen.com/enable-http2-on-nginx&#34;&gt;enabled HTTP/2&lt;/a&gt;, it&amp;rsquo;s time to improve both the security and the performance of the server.</description>
    </item>
    <item>
      <title>Enabling SPDY with Nginx</title>
      <link>https://bjornjohansen.com/enabling-spdy-nginx/</link>
      <pubDate>Thu, 22 Aug 2013 20:50:20 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:63636230-3464-5563-a661-656165636538</guid> 
      <description>SPDY is this new, cool, fast protocol created by Google that &amp;ldquo;replaces&amp;rdquo; HTTP (the first draft of HTTP 2.0 is using SPDY as the working base). It is &lt;a href=&#34;http://caniuse.com/spdy&#34; title=&#34;Compatibility table for support of SPDY networking protocol in desktop and mobile browsers.&#34;&gt;supported in all the major browsers&lt;/a&gt; – yes, even Internet Explorer – with the exception of Apple&amp;rsquo;s Safari.</description>
    </item>
    <item>
      <title>Securing Nginx with HTTPS</title>
      <link>https://bjornjohansen.com/securing-nginx-ssl/</link>
      <pubDate>Thu, 22 Aug 2013 19:53:15 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:31313436-3262-5866-b731-393965366633</guid> 
      <description>&lt;img src=&#34;https://www.bjornjohansen.com/content/uploads/2013/08/origin_4146023669-150x150.jpg&#34; alt=&#34;SSL&#34;
     loading=&#34;lazy&#34; decoding=&#34;async&#34;&gt;
Adding a certificate and using the HTTPS protocol is a good improvement to the security in the communication between the browser and the server, and should be in place on all sites that have a user login. Contrary to what many (older) guides say, it doesn&amp;rsquo;t add much load on your server and is fairy easy and cheap to set up right.</description>
    </item>
    <item>
      <title>Install latest version of Nginx on Ubuntu</title>
      <link>https://bjornjohansen.com/install-latest-version-of-nginx-on-ubuntu/</link>
      <pubDate>Fri, 16 Aug 2013 16:29:31 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:32656631-6565-5564-b933-633863303366</guid> 
      <description>&lt;img src=&#34;https://www.bjornjohansen.com/content/uploads/2013/08/nginx-300x64.png&#34; alt=&#34;Nginx&#34;
     loading=&#34;lazy&#34; decoding=&#34;async&#34;&gt;
I always run the latest LTS version of Ubuntu on all my servers. Unfortunately, the Nginx versions tend to be quite the bit behind the current release. So how do you get an updated, current version of without resorting to having to maintain the packages yourself? Luckily, the Nginx team have their own Ubuntu apt repository so it’s easy to keep current with the latest version of Nginx.</description>
    </item>
    <item>
      <title>Restricting access to WordPress login by IP address</title>
      <link>https://bjornjohansen.com/restricting-access-to-wordpress-login-by-ip-address/</link>
      <pubDate>Sat, 20 Apr 2013 20:15:34 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:33306539-3032-5330-b562-623835343236</guid> 
      <description>If you have a static IP address, like from &lt;a href=&#34;https://www.bjornjohansen.com/setting-up-your-own-pptp-vpn&#34;&gt;your own VPN&lt;/a&gt;, it is very easy to increase your security tremendously. Simply restrict all logins to that IP address.</description>
    </item>
    <item>
      <title>Caching: Varnish or Nginx?</title>
      <link>https://bjornjohansen.com/caching-varnish-or-nginx/</link>
      <pubDate>Fri, 12 Apr 2013 20:37:57 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:63636330-6461-5163-b365-333638366266</guid> 
      <description>TL;DR: Varnish lacks support for SSL and SPDY. Nginx handles it just fine, and has very fast cache with either memcache or disk storage (ramdisk). Both can serve stale cache if your backend is down. But Nginx can not write to the memcache storage directly, it has to be done by the application. Also, Nginx can not purge the cache itself, without you compiling your own package.</description>
    </item>
  </channel>
</rss>
