Monday, July 28, 2014

Blocking Access to an Apache Web Server behind and ELB using mod_rewrite

If you want to block access to an Apache server which is sitting behind an ELB and if you are using EC2 classic instead of a VPC , then you can use the following configuration in your Apache web server :

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-For} !^1\.1\.1\.1
RewriteCond %{HTTP:X-Forwarded-For} !^2\.2\.2\.2
RewriteCond %{HTTP:X-Forwarded-For} !^3\.3\.3\.3
RewriteRule ^(.*)$ - [F,L]

Basically the above configuration allow access only  to , and and blocks access from every other IP address.  For the above configuration to work you must enable mod_rewrite.

However, if you want to block access from above IP addresses then you can use the following configuration:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-For} ^1\.1\.1\.1 [OR]
RewriteCond %{HTTP:X-Forwarded-For} ^2\.2\.2\.2 [OR]
RewriteCond %{HTTP:X-Forwarded-For} ^3\.3\.3\.3 
RewriteRule ^(.*)$ - [F,L]

Basically the above configuration blocks access from, and and allows access to every other IP address.

N.B: If you are not behind an ELB or HTTP proxy then just replace %{HTTP:X-Forwarded-For} with   %{REMOTE_ADDR}

Monday, July 29, 2013

Installation and configuration of VSFTPD in CentOS with FTPS support and SELinux

The goal of this article is to provide a step by step guide for installation of a Secure VSFTPD server on a CentOS machine. VSFTPD will be configured to support  FTPS protocol ( explicit FTP over SSL) which allows secure FTP login to be carried over port 21. In this configuration each user will be chrooted to his/her home directory. The VSFTPD will enforce secure login over TLS and will reject plain text authentication. 

Steps  :

[1] Check SELinux Status and make sure that its turned on :

[root@localhost ~]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                    24

Policy from config file:        targeted

[2] Install VSFTPD server using YUM : 

[root@localhost ~]# yum -y install vsftpd
[root@localhost ~]# chkconfig vsftpd on 

[3] Generate SSL certificates to be used by the VSFTPD daemon :

[root@localhost ~]# mkdir -p /etc/ssl/private
[root@localhost ~]# chmod 700 /etc/ssl/private/
[root@localhost ~]# openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem

Generating a 1024 bit RSA private key
writing new private key to '/etc/ssl/private/vsftpd.pem'
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [XX]:UK
State or Province Name (full name) []:BEDFORDSHIRE
Locality Name (eg, city) [Default City]:LUTON
Organization Name (eg, company) [Default Company Ltd]: EXAMPLE PVT. LTD.
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address []

[4] For security reasons , it is a good idea to have  /home as a separate partition and mounted as rw,noexec,nosuid,nodev. 

[5] The working configuraiton file for the VSFTPD daemon is as follows :

[root@localhost ~]# egrep -vi '^#|^$' /etc/vsftpd/vsftpd.conf


force_local_data_ssl and force_local_logins_ssl enforces TLS protocol to be used for login as well as data transfer.

[6] Add a user on the system called test  : 

[root@localhost ~]# useradd test
[root@localhost ~]# passwd test
Changing password for user test.
New password:
Retype new password:

passwd: all authentication tokens updated successfully.

[root@localhost ~]# chsh -s /sbin/nologin test

When I tried to log on using the test user , there were some SELinux related errors and VSFTPD was not working :

[root@localhost ~]# grep -i vsftpd /var/log/messages

Jul 27 17:50:34 localhost yum[1912]: Installed: vsftpd-2.2.2-11.el6_4.1.x86_64

Jul 28 07:05:45 localhost setroubleshoot: SELinux is preventing /usr/sbin/vsftpd from search access on the directory home. For complete SELinux messages. run sealert -l 1b2fe796-1d8c-4924-ad31-c6dbaefbfcf4

root@localhost ~]# sealert -l 1b2fe796-1d8c-4924-ad31-c6dbaefbfcf4
SELinux is preventing /usr/sbin/vsftpd from search access on the directory home.

*****  Plugin catchall_boolean (47.5 confidence) suggests  *******************

If you want to allow ftp servers to login to local users and read/write all files on the system, governed by DAC.
Then you must tell SELinux about this by enabling the 'allow_ftpd_full_access'boolean.

setsebool -P allow_ftpd_full_access 1

*****  Plugin catchall_boolean (47.5 confidence) suggests  *******************

If you want to allow ftp to read and write files in the user home directories
Then you must tell SELinux about this by enabling the 'ftp_home_dir'boolean.
setsebool -P ftp_home_dir 1

*****  Plugin catchall (6.38 confidence) suggests  ***************************

If you believe that vsftpd should be allowed search access on the home directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
allow this access for now by executing:
# grep vsftpd /var/log/audit/audit.log | audit2allow -M mypol

# semodule -i mypol.pp


As suggested by the setroubleshoot , to enable VSFTPD to read and write  files in the user's home directories the SELinux boolean ftp_home_dir needs to be turned on. This was done using the following command :

[root@localhost ~]# setsebool -P ftp_home_dir 1

Once the above command was issued, there were no SELinux related errors reported. However, VSFTPD  rejected plain-text logins : 

Hence, To test FTPS , filezilla was used. As I am using self signed certificate I get a warning related to the certificate.

Saturday, July 6, 2013

Installing Slackware 14 on a Linux Software RAID 1 (MIRRORING)

This  is beginners guide on how to install Slackware Linux 14 on a RAID 1 (mirrored) drive.

Boot the system with Slackware 14 ISO and then when prompted, choose the appropriate keyboard type. To login type root and press enter. The details related to the disks that are present in the machine can printed using the following command:

# fdisk –l 

In my system there are two identical SCSI disk, each of size 7516 MB. Two identical disks are needed for RAID 1 (mirroring) or else the size of the smallest disk will become the size of the final RAID array. The plan is to create two Linux software RAID 1 arrays. The first one will be used as the / (root) partition and the next one will be used as swap partition. The root partition on the first raid array will have the size of 7000 MB and the next RAID array which will be used as swap will be allocated the remaining Space. To achieve this we partition the first drive /dev/sda using the cfdisk utility. The steps are as follows :

[1] Type cfdisk /dev/sda and press enter
[2] Chose the Pri/Log Fress Space and chose [New] and press enter
[3] Chose [Primary] and press enter
[4] Enter the Size as 7000 MB (or whatever you think is suitable in your layout)
[5] Chose Beginning and Press enter
[6] Chose [Bootable] and press enter
[7] Select [Type] while the new partition is highlighted and then press enter
Enter the filesystem Type as FD ( Linux Raid AutoDetect) and press Enter

Now you will have something like this:

[8] Now use the down arrow key to select the Free Space and make sure that [New] is highlighted and then press enter

[9] Select [Primary] and press enter 
[10] Accept the default size (in my case 516.48 MB) by pressing Enter
[11] As before , change the type of this partition into FD (Linux Raid AutoDetect) {Similar to step 7 above }
[12] Finally write the partition table onto the disk by selecting [Write] and by pressing enter
[13] Type ‘yes’ and the press enter
[14] Select [Quit] and press Enter to quit the cfdisk utility

We can verify that the partition table of /dev/sda is written correctly by using the fdisk –l command.

The next step is to copy the partition table of /dev/sda into /dev/sdb by using the sfdisk utility. This can be done using the following command :

# sfdisk -d /dev/sda | sfdisk --force /dev/sdb

Now both the disk sda and sdb have identical partition table, which can be verified by using the following commands :

# fdisk –l /dev/sda 

# fdisk –l /dev/sdb 

The cat /proc/mdstat command will show us that there are  currently no RAID arrays present in the system :

The next step is to create the raid arrays using the mdadm utility. To create the first RAID array that will be used as / (root) partition we can use the following command :

# mdadm --create  /dev/md0 --level=1 –raid-devices=2 /dev/sda1 /dev/sdb1 

We can view the status of the newly created RAID device using the cat /proc/mdstat command:

Similarly, we can create the RAID device /dev/md1 which will be used as our swap partition using the following command:

# mdadm --create  /dev/md1 --level=1 –raid-devices=2 /dev/sda2 /dev/sdb2

As we can see from the above output /dev/md0 is fine and /dev/md1 is being synced.  Now our raid arrays are in place. Before we being the installation of the Slackware using the setup command, we will format /dev/md1 as the swap partition.

# mkswap /dev/md1 

Now we can begin the installation of the Slackware Linux using the setup command:

# setup 

The steps are as follows :

[1] Choose the ADDSWAP option and press Enter.  The /dev/md1 partition will be detected as swap. When prompted for “Check SWAP Partitions for BAD Blocks” , chose NO. Then the swap space will be added into the /etc/fstab file.

[2] In the next step we will chose /dev/md0 as the / (root) partition.  We will choose to Format it and the EXT4  file system is chosen. After the formatting is complete the /etc/fstab file will be updated.

[3] Choose install Slackware from  CD or DVD
[4] Choose the packages and then begin the installation

[5] Supply root password and complete the Setup by installing Lilo bootloader.

After the installation is finished we drop to the install shell and then chroot to the newly installed Linux partition by using the following command:

# chroot /mnt/ /bin/bash

We then backup the original lilo.conf file and replace it with the following :

# mv /etc/lilo.conf   /etc/lilo.conf.ori
# vi /etc/lilo.conf

append=" vt.default_utf8=0"
boot = /dev/md0
bitmap = /boot/slack.bmp
bmp-colors = 255,0,255,0,255,0
bmp-table = 60,6,1,16
bmp-timer = 65,27,0,255
timeout = 1200
vga = normal
image = /boot/vmlinuz
  root = /dev/md0
  label = Linux

Finally we , reinstall Lilo using the following command :

# lilo –v 

Now, the installation is complete , we can reboot the system using the following command :

# reboot

After we have booted into the freshly installed Slackware, we can check the status of the raid array using the following commands:

root@slack-box:~#  mdadm --detail /dev/md0

root@slack-box:~#  mdadm --detail /dev/md1

It is a good idea to generate the mdadm.conf file. We can do this by using the following command :

root@slack-box:~#  mdadm --detail --scan > /etc/mdadm.conf

Wednesday, June 26, 2013


During a penetration test , once you have compromised a machine on the internal network, the next step generally is to pivot and then scan, fingerprint exploit and compromise other hosts in the same internal network. Sometimes, it might be useful to tunnel all the TCP communications via a meterpreter session, and not just a single port or a group of ports. This can be achieved in Metasploit using the socks proxy auxiliary module, which allows a pen-tester to tunnel TCP traffic generated by external programs like Nessus  and Nmap to be tunneled via the socks proxy, which in-turn forwards the traffic via the meterpreter session , to the internal network that is not directly accessible. To force external programs to use the socks proxy, the pen-tester can use proxychains utility. Let’s, take an example:

In the above diagram the attacker has compromised HOST1 and has a meterpreter session number 1. First, to route the traffic destined to network via this session he needs to issue the following command:

msf> route add 1

The next step is to start the socks proxy form the metasploit and bind it to local loopback adapter on port 1080 (default port):

msf > use auxiliary/server/socks4a
msf auxiliary(socks4a) > set SRVHOST
msf auxiliary(socks4a) > set SRVPORT 1080
msf auxiliary(socks4a) > run
[*] Auxiliary module execution completed
[*] Starting the socks4a proxy server

Now, the socks proxy server is listening on the loopback adapter on port 1080. The next step is to configure external tools and software like Firefox, nmap ,nessus etc. to use the proxy service configured.
In case of Firefox this can be done easily by clicking tools, options , network then settings. On the Connection setting tab one needs to choose Manual proxy configuration and Socks Host and Port should be set to and 1080 respectively. The socks protocol should be set to SOCKSv4 as metasploit socks proxy only supports socks v4.

To tunnel nmap and nessus traffic via the metasploit socks proxy, the pen-tester needs to use a tool called proxychains. First, step is to configure proxychains to forwards the TCP traffic via the socks proxy setup earlier. This can be achieved by editing the /etc/proxychains.conf file and by adding the following lines :

socks4 1080

Finally, we can invoke/execute nessus like the following :

# killall -9 nessusd
# proxychains nessus-service –D

Now we can open a browser and point it to and start the nessus scan. One important point to note here is that it is not possible to tunnel ICMP and UDP traffic via the socks proxy and hence ping packets and UDP scans should be omitted from the nessus scan list.

Similarly, it is possible to perform nmap scan via the socks proxy using the following command:

# proxychains nmap –n –sT -sV -PN -p 80,22,443,445

As we can see the metasploit socks proxy auxillayr module is really handy and canhelp a lot during pivoting.

References :

Tuesday, August 28, 2012

Clone/Duplicate a Xen Virtual Machine

[1] Install virt-clone utility :

# apt-get install virtinst libvirt-bin  

[2] Shutdown the virtual machine that you want to clone using one of the following commands :

# xm shutdown


# virsh -c xen:///
virsh # shutdown

[3]   Use the virt-clone command to create the clone and follow the questions:

# virt-clone --connect xen:/// --prompt

What is the name of the original virtual machine?
What is the name for the cloned virtual machine?
What would you like to use as the cloned disk (file path) for '/home/virtual-images/zimbra_ubuntu.img'?
Cloning zimbra_ubuntu.img                                                                                     | 117 GB     09:19

Clone 'zimbra_clone1' created successfully.

[4] List the  newly cloned domU image :

# xm list

Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  9844     8     r----- 124053.5
centos                                       4  1996     1     -b----   1360.4
debian                                          1587     1                 0.0
freebsd9                                     3  1024     1     -b----    813.4
godavari                                     1  1024     1     -b----    121.3
server2008                                   2  4142     1     -b----   1403.5
zimbra                                          2048     1              8729.8
zimbra_clone1                              2048     2                 0.0

[4] Boot the new cloned VM and make changes to its networking settings

[5] Start both the old and the new VM

Thursday, December 22, 2011



/sbin/iptables -t filter -A INPUT -p TCP -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -t filter -A INPUT -p UDP -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -t filter -A INPUT -p ICMP -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -t filter -A INPUT -m state --state INVALID -j DROP

Saturday, October 29, 2011

W3AF Command Injection and Web Application Payloads

W3AF [ Web Application Attack and Audit Framework]  is an open source web application penetration testing framework written in python. Today I will be exploiting command injection vulnerability using  W3AF's osCommanding injection module. I will also show you how one can use some of the web application payloads that comes with W3AF. The beauty of "web application payloads" is that one can use any  payload with any exploit inside of W3AF. This is similar to Metasploit Framework.

First lets view a very simple vulnerable PHP code :

root@test-box:/srv/test# cat index.php
        if (isset($cmd))
           print 'Command Injection Example for W3AF Test';
           print 'Example : http://site/index.php?command=ls ';