rubysecurity.org

Cloud Architect / DevOps Engineer / SRE / Developer | /root

Home About Books Blog Portfolio Archive

Tag Cloud


Currently Reading

Certified Kubernetes Administrator (CKA) Study Guide
Certified Kubernetes Administrator (CKA) Study Guide
38 / 155 Pages


Latest Book Reviews

Latest Posts


February 15, 2014

Reverse SSL Proxy with Nginx

by Alpha01

Nginx is turning to be an awesome SSL reverse proxy server, although I can’t say I’ve really put it to real heavy duty use or how it well scale since my sites have relatively slow traffic. Thus said, a reverse SSL proxy using Nginx is working flawless in my environment!

Since all of my sites are being served within a KVM guest using NAT networking, all SSL traffic has to go through the KVM host of which Nginx is being used to proxy the requests to the guest KVM. Nginx is awesome since it supports specifying multiple server blocks (think of virtual hosts in Apache) set to listen on port 443 within the main http block. With this configuration available, it is possible to specify different reverse proxy end points.

On my server I have enabled SSL for www.rubysecurity.org and www.rubyninja.org.

First thing I needed to do is to map the sites local IPs to the KVM hosts file.

192.168.100.208 rubysecurity.org www.rubysecurity.org
192.168.100.209 rubyninja.org www.rubyninja.org

Then configure nginx.conf (sample server blocks):

server {
    listen       443;
    server_name  www.rubysecurity.org;
    ssl                 on;
    ssl_certificate     /etc/nginx/certs/www.rubysecurity.org.bundled.crt;
    ssl_certificate_key /etc/nginx/certs/www.rubysecurity.org.key;

    location / {
        proxy_pass   https://www.rubysecurity.org;

        ### Set headers ####
        proxy_set_header        Accept-Encoding   "";
        proxy_set_header        Host            $host;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;

        #proxy_set_header X-Forwarded-Proto https;##
        #This is better##
        proxy_set_header        X-Forwarded-Proto $scheme;
        add_header              Front-End-Https   on;
 
        # We expect the downsteam servers to redirect to the right hostname, so don't do any rewrites here.
        proxy_redirect     off;
    }
}

server {
    listen   443;
    server_name www.rubyninja.org;
    ssl on;
    ssl_certificate     /etc/nginx/certs/www.rubyninja.org.bundled.crt;
    ssl_certificate_key /etc/nginx/certs/www.rubyninja.org.key;

    location / {
        proxy_pass   https://www.rubyninja.org;

        ### Set headers ####
        proxy_set_header        Accept-Encoding   "";
        proxy_set_header        Host            $host;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;

        #proxy_set_header X-Forwarded-Proto https;##
        #This is better##
        proxy_set_header        X-Forwarded-Proto $scheme;
        #add_header              Front-End-Https   on;

        # We expect the downsteam servers to redirect to the right hostname, so don't do any rewrites here.
        proxy_redirect     off;
    }
}

One interesting thing in Nginx with SSL is that it doesn’t have a dedicated Certificate Authority (CA) ssl certificate directive, unlike SSLCACertificateFile in Apache. Instead the CA certificate has to be bundled with the public ssl certificate, which it’s really not a big deal given that multiple CA’s tend to bundle their intermediate CA certificates similarly.

Tags: [ security nginx ]
January 6, 2014

Problems installing Chrome on OpenSuSE 13.1

by Alpha01

Error

linux-5n99:/home/tony/Downloads # rpm -ivh google-chrome-stable_current_x86_64.rpm
warning: google-chrome-stable_current_x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 7fac5991: NOKEY
error: Failed dependencies:
  lsb >= 4.0 is needed by google-chrome-stable-31.0.1650.63-1.x86_64

Fix

linux-5n99:/home/tony/Downloads # yast --install lsb
Tags: [ opensuse ]
December 28, 2013

Password protecting single user mode

by Alpha01

I was surprise to find out how easy it was to password protect runlevel 1 aka single user mode in RHEL/CentOS.

Simply update the SINGLE variable in the file /etc/sysconfig/init

SINGLE=/sbin/sulogin

Single User mode password protected

If the root password cannot be retrieved/reset, then at this point the only option will be to boot into a rescue environment, assuming encryption hasn’t been enabled.

Tags: [ centos security ]
December 22, 2013

Password protecting GRUB in RHEL/CentOS

by Alpha01

Specifying a password to modify GRUB during the boot start-up phase can be initially set during the install, but it can also be manually added and or modified after the installation.

Using the grub-md5-crypt utility, you can generate an md5 hashed password (some security better than no security).

[root@centos6 ~]# grub-md5-crypt 
Password: 
Retype password: 
$1$/dvPV1$ngGsOO21eHj2lzEk7wg9d0

Now, is just a matter of adding the following entry in /boot/grub/grub.conf.

password --md5 $1$/dvPV1$ngGsOO21eHj2lzEk7wg9d0

Restart, and voala.

GRUB image

Tags: [ centos rhel security ]
November 28, 2013

Leaving Gmail and Google Apps: Part I

by Alpha01

Since I’m paying for essentially unmanaged dedicated hosting so I can run my mail server. I opted to consolidate my personal web applications to the same physical box. This is why I created a KVM guest that would solely be used for my web traffic. One of the main challenges I’m faced is the fact that I only have one public IP address. This means that all of my KVM guests have been configured using the default NAT networking.

For all http traffic I’m using Varnish as the proxy and caching server and for https traffic I’m using Nginx. http_architecture

First thing that broke using this different architecture on my sites are the mod_access IP restrictions that I originally had set in place previously. This is because the Apache backend see’s all requests originating from the Varnish and Nginx proxies. Luckily both Varnish and Nginx have really simple access control mechanism built in them.

For example, in Varnish I can create a list of IPs that I can use to their block or grant access to certain URLs.

acl admin {
   "localhost";
    "MyPublicIPAddress";
} 

sub vcl_recv {
  # Only allow access to the admin ACL
  if (req.url ~ "^/secureshit" && req.http.host ~ "rubysecurity.org") {
    if (client.ip ~ admin) {
      return(pass);
    } else {
      error 403 "Not allowed in admin area.";
    }
  }
}

Nginx acl

location  /secureshit {
  allow MyPublicIPAddres;
  deny all;
  proxy_pass https://www.rubysecurity.org/secureshit;
}
Tags: [ google centos kvm varnish nginx ]