System Architecture for Scaling Virtual Environment

All traffic should have ssl certs installed for each domain at nginx level.  Nginx is configured as ssl proxy only.  Certs are provided by Let’s Encrypt unless otherwise needed for other purposes.

(non-secure) Varnish (80) –> Apache (8080) –> Redis –> MariaDB

(secure) Nginx (as ssl proxy) (443) –> Varnish (80) –> Apache (8080) –> Redis –> MariaDB

 

Add Link here to Varnish CMS / WordPress, Joomla, Drupal config

Apache / PHP-FPM –> Redis –> MariaDB

 

WordPress Special Notes:

You have to tell WordPress that you are behind SSL and it will function properly. To accomplish this, I use the following code in wp-config.php

if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
    $_SERVER['HTTPS']='on';
}

Be sure to refresh everything once you make you change:

# systemctl restart varnish; systemctl restart nginx; systemctl restart php70-php-fpm; systemctl restart httpd 

You may find yourself needing to download a WP plugin to help with any other issues.

Here are a couple to try:

  • https://mattgadient.com/remove-protocol/
  • https://wordpress.org/plugins/remove-http/

Misc Notes — Found (save) for possible varnish vcl changes




We run Varnish in between an F5 and Apache as well as use Nginx for ssl and load
> balancing in development, in conjunction with WordPress backends. You have to
> tell WordPress that you are behind SSL and it will function properly. To
> accomplish this I’d use the following code in wp-config.php
> 
> if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
>        $_SERVER['HTTPS']='on';
> }
> 
> You can then also set FORCE_SSL_ADMIN and FORCE_SSL_LOGIN however you see fit
> and it should work. I saw some updates not that long ago to support proxy
> headers but don’t believe they are fully supported yet.
> 
> Jason
> 
> 
>> On Nov 2, 2015, at 12:37 PM, Carlos M. Fernández <cfernand at sju.edu> wrote:
>> 
>> Hi, Phil,
>> 
>> We don't use Nginx but do SSL termination at a hardware load balancer,
>> with most of the work to support that setup done in the VCL, and something
>> similar could possibly apply to your scenario.
>> 
>> Our load balancer can use different backend ports depending on which
>> protocol the client requests; e.g., if the client connects to port 80 for
>> HTTP, then the load balancer proxies that to Varnish on port 80, while if
>> the client connects to 443 for HTTPS the load balancer proxies to Varnish
>> on port 8008. The choice of Varnish port numbers doesn't matter, just the
>> fact that Varnish listens on both ports and that the load balancer uses
>> one or the other based on the SSL status with the client (using the
>> command line option "-a :80,8008" in this case).
>> 
>> Then, in vcl_recv, we have the following to inform the backend when an SSL
>> request has arrived:
>> 
>> if ( std.port( server.ip ) == 8008 ) {
>>    set req.http.X-Forwarded-Proto = "https";
>> }
>> 
>> We also have the following in vcl_hash to cache HTTP and HTTPS requests
>> separately and avoid redirection loops:
>> 
>> if ( req.http.X-Forwarded-Proto ) {
>>    hash_data( req.http.X-Forwarded-Proto );
>> }
>> 
>> The backend then can look for that header and respond accordingly. For
>> example, in Apache we set the HTTPS environment variable to "on":
>> 
>> SetEnvIf X_FORWARDED_PROTO https HTTPS=on
>> 
>> I have no knowledge of Nginx, but if it can be configured to use different
>> backend ports then you should be able to use the above.
>> 
>> Best regards,
>> --
>> Carlos.

This list of rules by no means is a sure bet to secure your web services, but it will help in preventing script-kiddings from doing some basic browsing around.

MySQL injection attempts are one of the most common hacking attacks against PHP websites. If your website is hosted on a dedicated or virtual server, the best solution is to your server hardened with proper mod_security rules. However, if you’re on shared hosting, this is not an option. If you now think that it’s not possible to protect your website against various hacking methods on shared hosting, you’re wrong. Although it’s not possible to use advanced strategies to protect your website, you’re still able to protect it against hacking attempts using .htaccess rules. To implement such a protection, append your current .htaccess file with the following code, or create a new file called .htaccess, if you don’t use any yet, and place it in your website’s main folder):

Beginning of your .htaccess file to set the basics up

# Block access to the .htaccess file
<files .htaccess>
order allow,deny
deny from all
</files>

# No web server version and indexes
ServerSignature Off
Options -Indexes
Options FollowSymLinks

HTTP Headers to Help Secure Your Website

Preventing cross-site request forgery (CSRF) attacks is hard and web applications must be built to prevent CSRF vulnerabilities. The first vulnerability is cross-site scripting (XSS).

Around 70.000 web sites have been catalogued by XSSed as being vulnerable to cross-site scripting (XSS). These attacks leave your users open to cookie theft, information theft, account hijacking, clickjacking and more.

Modern web browsers have some powerful protection build in nowadays but you need to tell the browser that you want those protection mechanisms used for your website. This can be archived by setting specific HTTP headers.

X-Frame-Options

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>. This can be used to avoid clickjacking attacks, by ensuring that your content is not embedded into other sites.

This directive is pretty similar to the frame buster code explained in “Double Trouble on Google Images” except that it is only supported in the following browsers:

  • Internet Explorer 8+
  • Opera 10.50+
  • Safari 4+
  • Chrome 4.1.249.1042+
  • Firefox 3.6.9+ (or earlier with NoScript)

There are three possible values for this header:

  1. DENY – This setting prevents any pages served from being placed in a frame even if it is on the same website it originates from. should be used if you never intend for your pages to be used inside of a frame.
  2. SAMEORIGIN – This setting allows pages to be served in a frame of a page on the same website. If an external site attempts to load the page in a frame the request will be denied.
  3. ALLOW-FROM origin – If the value contains the token ALLOW-FROM origin, the browser will block rendering only if the origin of the top-level browsing context is different than the origin value supplied with the Allow-From directive.

The code below sets the directive to DENY, preventing our pages from being served in any frames, even from our own website.

# drop Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
#CustomLog insert-path-and-name-of-log common env=bad-range

# Don't allow any pages to be framed - Defends against CSRF
Header set X-Frame-Options DENY

# prevent mime based attacks
Header set X-Content-Type-Options "nosniff"

# Only allow JavaScript from the same domain to be run.
# Don't allow inline JavaScript to run.
Header set X-Content-Security-Policy "allow 'self';"

# Turn on IE8-IE9 XSS prevention tools
Header set X-XSS-Protection "1; mode=block"

MySQL Injection Prevention:

MySQL injection attempts are one of the most common hacking attacks against PHP websites. If your website is hosted on a dedicated or virtual server, the best solution is to your server hardened with proper mod_security rules. However, if you’re on shared hosting, this is not an option. If you now think that it’s not possible to protect your website against various hacking methods on shared hosting, you’re wrong. Although it’s not possible to use advanced strategies to protect your website, you’re still able to protect it against hacking attempts using .htaccess rules. To implement such a protection, append your current .htaccess file with the following code, or create a new file called .htaccess, if you don’t use any yet, and place it in your website’s main folder):

<IfModule mod_rewrite.c>
# Enable rewrite engine
RewriteEngine On

# Block suspicious request methods
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK|DEBUG) [NC]
RewriteRule ^(.*)$ - [F,L]

# Block WP timthumb hack
RewriteCond %{REQUEST_URI} (timthumb\.php|phpthumb\.php|thumb\.php|thumbs\.php) [NC]
RewriteRule . - [S=1]

# Block suspicious user agents and requests
RewriteCond %{HTTP_USER_AGENT} (libwww-perl|wget|python|nikto|curl|scan|java|winhttp|clshttp|loader) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (;|<|>|'|"|\)|\(|%0A|%0D|%22|%27|%28|%3C|%3E|%00).*(libwww-perl|wget|python|nikto|curl|scan|java|winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner) [NC,OR]
RewriteCond %{THE_REQUEST} \?\ HTTP/ [NC,OR]
RewriteCond %{THE_REQUEST} \/\*\ HTTP/ [NC,OR]
RewriteCond %{THE_REQUEST} etc/passwd [NC,OR]
RewriteCond %{THE_REQUEST} cgi-bin [NC,OR]
RewriteCond %{THE_REQUEST} (%0A|%0D) [NC,OR]

# Block MySQL injections, RFI, base64, etc.
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=http:// [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=http%3A%2F%2F [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=(\.\.//?)+ [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=/([a-z0-9_.]//?)+ [NC,OR]
RewriteCond %{QUERY_STRING} \=PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} [NC,OR]
RewriteCond %{QUERY_STRING} (\.\./|\.\.) [OR]
RewriteCond %{QUERY_STRING} ftp\: [NC,OR]
RewriteCond %{QUERY_STRING} http\: [NC,OR]
RewriteCond %{QUERY_STRING} https\: [NC,OR]
RewriteCond %{QUERY_STRING} \=\|w\| [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)/self/(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)cPath=http://(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*iframe.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^i]*i)+frame.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} base64_(en|de)code[^(]*\([^)]*\) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>).* [NC,OR]
RewriteCond %{QUERY_STRING} (NULL|OUTFILE|LOAD_FILE) [OR]
RewriteCond %{QUERY_STRING} (\./|\../|\.../)+(motd|etc|bin) [NC,OR]
RewriteCond %{QUERY_STRING} (localhost|loopback|127\.0\.0\.1) [NC,OR]
RewriteCond %{QUERY_STRING} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{QUERY_STRING} concat[^\(]*\( [NC,OR]
RewriteCond %{QUERY_STRING} union([^s]*s)+elect [NC,OR]
RewriteCond %{QUERY_STRING} union([^a]*a)+ll([^s]*s)+elect [NC,OR]
RewriteCond %{QUERY_STRING} (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC,OR]

# PHP-CGI Vulnerability
RewriteCond %{QUERY_STRING} ^(%2d|\-)[^=]+$ [NC,OR]

#proc/self/environ? no way!
RewriteCond %{QUERY_STRING} proc\/self\/environ [NC,OR]

RewriteCond %{QUERY_STRING} (sp_executesql) [NC]
RewriteRule ^(.*)$ - [F,L]

</IfModule>