rubysecurity.org

So the default Perl installation that ships with CentOS 7 minimal install does not include Time::HiRes, which is necessary if you want to use CPAN.

Error:

Can't locate Time/HiRes.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 /root) at /usr/share/perl5/Net/Ping.pm line 313.

Fix:

yum install perl-Time-HiRes

[[email protected] varnish]# varnishd -C -f default.vcl
Message from VCC-compiler:
Expected an action, 'if', '{' or '}'
('input' Line 156 Pos 17)
erro 403 "Fuck off";
----------------####----------------

Running VCC-compiler failed, exit 1

VCL compilation failed

For quite sometime now, I've been wanting to upgrade my home network to Gigabit Ethernet. So finally the time had come to finally retired my aging Linksys WRT54GL wireless router. Flashed with DD-WRT, my WRT54GL has served me well for well over six years. For it's replacement I opted to completely geek out with a dedicated firewall and access point solutions. For my firewall I chose pfSense. Over the last few months, I heard nothing but good things regarding this FreeBSD firewall system; primarily because of it's ease of use. This is what first attracted me to it since practically all my real firewall experience is through administrating it through their respective web interface, ie Cisco Adaptive Security Device Manager for ASA firewalls. (Yes, I really should learn how to do this from the command line, but I digress.)

For pfsense, I used a barebore mini 1.86GHz (dual core) Atom computer. OEM Production 2550L2D-MxPC Intel NM10 2 x 204Pin Intel GMA 3650 Black Mini / Booksize Barebone System. For storage and memory, I had a spare of two 1GB 1066 SODIMM modules and a spare 64GB SSD drive, which is more than plenty for pfSense, if not overkill.
The install and configuration of pfSense itself is absolutely dead simple. Essentially after the install, you just need to specify which is your LAN and WAN interfaces and that's it! My WAN internet connection, is provided via DHCP and a cool thing that pfSense supports is the ability to specify a custom mac address for the new firewall machine. This is handy because it basically saved me from having to call Time Warner Cable to informed them about my new replacement networking device.

Although pfSense supports the addition of wireless card interfaces so it can also function as an accesses point. I opted to use a dedicated wireless access point for my wireless networking. I had Linksys E1000 wireless access that was given to me a few a months ago, so I flashed it with DD-WRT and used the Linksys E1000 as my new wireless access point. So far with this newer wireless access point and newer version of DD-WRT, I noticed that the wireless range of this new device extends much farther than then the old WRT54GL.

The primary reason why I chose to deploy pfSense on my network besides its strong focused on security was because it's essentially a small FreeBSD base system, which has the ability to install numerous third party packages. So far I've enabled anti-virus and intrusion detection transparent proxy solutions using HAVP and Snort (this alone is fucking awesome). As well as some really cool network statistics graphing collection daemons.

With this $130.00 investment, I essentially have the equal level of capabilites that I would've otherwise have with another really fancy commercial firewall/router solution that would've cost thousands of dollars to deploy. The beauty of open source.

To do:
VLAN wired and wireless network.

By default, the CentOS Apache configuration does not allow index directory listings. So I enabled Indexes Option's for the directory that I wanted allow this feature within my custom vhost . To my surprise after I made the Apache config update, directory listing was not working and I was still getting the default CentOS Apache welcome page.

Apache error log:

[Sat Apr 26 14:42:11 2014] [error] [client 192.168.100.1] Directory index forbidden by Options directive: /www/mysecureshit/

It turns out the default /etc/httpd/conf.d/welcome.conf file option overrides the +Indexing Options that I explicity enabled within my custom vhost.

#
# This configuration file enables the default "Welcome"
# page if there is no default index page present for
# the root URL.  To disable the Welcome page, comment
# out all the lines below.
#

    Options -Indexes
    ErrorDocument 403 /error/noindex.html

The fix was to simply disable welcome.conf.

When your Linux system has completely shit itself, and an emergency reboot needs to be made. Linux Magic System Request Keys to the rescue.

[[email protected] ~]# echo "1" > /proc/sys/kernel/sysrq
[[email protected] ~]# echo "b" > /proc/sysrq-trigger

Resources: https://www.kernel.org/doc/Documentation/sysrq.txt

So a few months back, I enabled reverse DNS on my home BIND server (https://www.rubysecurity.org/bind_rerverse-dns). One thing that I forgot to implement was the additional slave DNS reverse setup. Like many things in BIND, the slave revserse DNS setup was dead simple.

It's simply just a matter of adding the following entry to the slave's named.conf with the updated master's DNS IP specified in the masters directive and reload BIND.

zone "1.168.192.in-addr.arpa" IN {
        type slave;
        file "etc/zones/db.192.168.1.255.bak";
        allow-query { any; };
        masters { MasterDNSIP; };
};

Package is installed using OpenCSW

Install the installation source

[email protected]:~# pkgadd -d http://get.opencsw.org/now

I updated my PATH via ~/.profile

export PATH=/usr/bin:/usr/sbin:/opt/csw/bin

Install the CSWgangliaagent package

[email protected]:~# pkgutil --install CSWgangliaagent

Enable the service in SMF

[email protected]:~# svcadm enable svc:/network/cswgmond:default

Install git.

[[email protected] ~]# yum install git

Add the developers group, all git users will be part of this group.

[[email protected] ~]# groupadd developers

Create the git user which will own all the repos.

[[email protected] ~]# useradd -s /sbin/nologin -g developers git
[[email protected] ~]# passwd git
Changing password for user git.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

Update Permissions.

[[email protected] ~]# chmod 2770 /home/git/

Create an empty Git repo.

[[email protected] project1]# git init --bare --shared
Initialized empty shared Git repository in /home/git/project1/

Update file ownership and permissions.

[[email protected] project1]# chown -R git .
[[email protected] project1]# chmod 2770 /home/git/project1

Create a git user account.

[[email protected] git]# useradd -s /usr/bin/git-shell -g developers -d /home/git tony
useradd: warning: the home directory already exists.
Not copying any file from skel directory into it.
[[email protected] git]# passwd tony
Changing password for user tony.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

At this point a regular user should be able to checkout the project1 repo from the Git server.

[email protected]:~$ mkdir ~/testing_shit/git_test
[email protected]:~$ cd ~/testing_shit/git_test && git init
[email protected]:~/testing_shit/git_test$ git remote add origin [email protected]:/home/git/project1

Note:
Interestingly enough, an initial first commit has to be made onto the repo in order for any regular user to be able to push the repo, ie master branch. I received the following error when trying do so.

[email protected]:~/testing_shit/git_test$ git push origin master
[email protected]'s password:
error: src refspec master does not match any.
error: failed to push some refs to '[email protected]:/home/git/project1'

Fix:

[email protected]:~/testing_shit/git_test$ git commit -m 'Initial'
[master (root-commit) 7bb7337] Initial
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 README.txt

[email protected]:~/testing_shit/git_test$ git push origin master
[email protected]'s password:
Counting objects: 3, done.
Writing objects: 100% (3/3), 209 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To [email protected]:/home/git/project1
* [new branch] master -> master

So the primary reason why I wanted to add SSL support to www.rubyninja.org is because I want all my /wp-admin traffic to be served securely.

Configuring WordPress to force the login page and all wp-admin traffic to be served over SSL is simply just a matter of defining the FORCE_SSL_LOGIN and FORCE_SSL_ADMIN constants in wp-config.php

define( 'FORCE_SSL_LOGIN', true );
define( 'FORCE_SSL_ADMIN', true );

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 virtul 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.