AWS VPC Overview

What is VPC ?

A virtual private cloud (VPC) is a virtual network dedicated to your AWS account. It is logically isolated from other virtual networks in the AWS cloud. You can launch your AWS resources, such as Amazon EC2 instances, into your VPC. You can configure your VPC; you can select its IP address range, create subnets, and configure route tables, network gateways, complete auto scaling and security settings.

Benefits of VPC

• Each instance that you launch into a nondefault subnet has a private IP address, but no public IP address,unless you specifically assign one at launch These instances can communicate with each other, but can't access the Internet or other AWS products, such as Amazon Simple Storage Service (Amazon S3).

• You can enable Internet access for an instance launched into a nondefault subnet by attaching an Internet gateway to its VPC (if its VPC is not a default VPC) and associating an Elastic IP address with the instance.

• We can operate at subnet level security and evaluate trafic entering and exiting a subnet with Network ACLs. Network ACLs can be used to set both Allow and Deny rules.

• We can setup 'deny'-rules in security-groups.
• We can give multiple IP's per NIC and multiple NICs per instance.

• There are no additional charges for creating and using the VPC itself. Usage charges for other Amazon Web Services, including Amazon EC2, still apply at published rates for those resources, including data transfer charges. If you connect your VPC to your corporate datacenter using the optional Hardware VPN connection, pricing is per VPN connection-hour (the amount of time you have a VPN connection in the "available" state.) Partial hours are billed as full hours. Data transferred over VPN connections will be charged at standard AWS Data Transfer rates. ( $0.05 per VPN Connection-hour)

• If we are using VPN connection in VPC there is no need to use keypair for security. We can create an AMI with default username and password and we will use those credential with private ip for login with this opening ssh is not needed. Also we can easily communicate internally.

• We can create Separate VPC for staging, prod and testing. By default VPC’s can’t connect each other but if we need we can configure it  (VPC peering).

• All nodes are internet addressable. This doesn’t make much sense for nodes which have no reason to exist on the global internet. For example: a database node should not have any public internet hostname/IP.

• We can move NICs and internal IPs between instances.

• Managing huge number of instances with VPC is easy.

Q. Why should I use Amazon VPC?

Amazon VPC enables you to build a virtual network in the AWS cloud - no VPNs, hardware, or physical datacenters required. You can define your own network space and control how your network, and the Amazon EC2 resources inside your network, is exposed to the Internet. You can also leverage the greatly enhanced security options in Amazon VPC to provide more granular access both to and from the Amazon EC2 instances in your virtual network.

[ Read More ]

SSH login without password

The following steps can be used to ssh from one system to another without specifying a password:

1. On the client run the following commands:

$ mkdir -p $HOME/.ssh   
$ chmod 0700 $HOME/.ssh   
$ ssh-keygen -t dsa -f $HOME/.ssh/id_dsa -P ''  

This should result in two files, $HOME/.ssh/id_dsa (private key) and $HOME/.ssh/id_dsa.pub (public key).

2. Copy $HOME/.ssh/id_dsa.pub to the server.

3. On the server run the following commands:

$ cat id_dsa.pub >> $HOME/.ssh/authorized_keys2   
$ chmod 0600 $HOME/.ssh/authorized_keys2   

Depending on the version of OpenSSH the following commands may also be required:

$ cat id_dsa.pub >> $HOME/.ssh/authorized_keys   
$ chmod 0600 $HOME/.ssh/authorized_keys   

An alternative is to create a link from authorized_keys2 to authorized_keys:

$ cd $HOME/.ssh && ln -s authorized_keys2 authorized_keys

4. On the client test the results by ssh'ing to the server:

$ ssh -i $HOME/.ssh/id_dsa server

[ Read More ]

How to automatically chroot jail selected ssh user logins

1. Creating basic chroot environment

First we need to create a simple chroot environment. Our chroot environment will consist of a bash shell. To do this, first, we need to create a chroot directory:

# mkdir /var/chroot

In the next step, we need to copy the bash binary and its all shared library dependencies. You can see the bash's shared library dependencies by executing the ldd command:

# ldd /bin/bash
        linux-vdso.so.1 =>  (0x00007fff9a373000)
        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f24d57af000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f24d55ab000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f24d51eb000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f24d59f8000)

Now, we need to manually create all necessary directories and copy /bin/bash and all libraries to the new chroot directory into an appropriate location:

# cd /var/chroot/
# mkdir bin/ lib64/ lib/
# cp /lib/x86_64-linux-gnu/libtinfo.so.5 lib/
# cp /lib/x86_64-linux-gnu/libdl.so.2 lib/
# cp /lib/x86_64-linux-gnu/libc.so.6 lib/
# cp /lib64/ld-linux-x86-64.so.2 lib64/
# cp /bin/bash bin/

At this point all is ready and we can chroot

# chroot /vat/chroot
bash-4.2# ls /  
bash: ls: command not found

From the above you can see that bash is ready but there is not much to do as not even ls command is available. Rather then manually copy all commands and required libraries I have created a simple bash script to aid with this purpose. Create a script with the following content:

#!/bin/bash
# This script can be used to create simple chroot environment
# Written by LinuxCareer.com 
# (c) 2013 LinuxCareer under GNU GPL v3.0+

#!/bin/bash

CHROOT='/var/chroot'
mkdir $CHROOT

for i in $( ldd $* | grep -v dynamic | cut -d " " -f 3 | sed 's/://' | sort | uniq )
  do
    cp --parents $i $CHROOT
  done

# ARCH amd64
if [ -f /lib64/ld-linux-x86-64.so.2 ]; then
   cp --parents /lib64/ld-linux-x86-64.so.2 /$CHROOT
fi

# ARCH i386
if [ -f  /lib/ld-linux.so.2 ]; then
   cp --parents /lib/ld-linux.so.2 /$CHROOT
fi

echo "Chroot jail is ready. To access it execute: chroot $CHROOT"

By default the above script will create chroot in /var/chroot as defined by the $CHROOT variable. Feel free to change this variable according to your needs. When ready, make the script executable and run it with the file full path to your executables and files you wish to include. For example, if you need: ls, cat, echo, rm, bash, vi then use the which command to get a full path and supply it as an argument to the above chroot.sh script:

# ./chroot.sh /bin/{ls,cat,echo,rm,bash} /usr/bin/vi /etc/hosts
Chroot jail is ready. To access it execute: chroot /var/chroot

Now, you can access your new chroot jail with:

# chroot /var/chroot
bash-4.2# echo linuxcareer.com > file
bash-4.2# cat file
linuxcareer.com
bash-4.2# rm file
bash-4.2# vi --version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled May  4 2012 04:25:35)

2. Create chroot usergroup

A this point, we need to create a separate usergourp, which will be used by sshd to redirect all users belonging to this usergroup to the chroot jail.

$ sudo groupadd chrootjail

Now, add any existing users to this group. For example, to add user tester we will execute:

$ sudo adduser tester chrootjail
Adding user `tester' to group `chrootjail' ...
Adding user tester to group chrootjail
Done.

3. Configure sshd for chroot jail

All what remains is to configure sshd to automaticaly redirect all users from the chrootjail usergroup to the chroot jail at /var/chroot. This can be easily done be editing the sshd configuration file /etc/ssh/sshd_config. Add the following to /etc/ssh/sshd_config:

Match group chrootjail
            ChrootDirectory /var/chroot/

and restarting ssh:

$ sudo service ssh restart
ssh stop/waiting
ssh start/running, process 17175

4. Login to chroot jail using ssh

At this point you can test your settings by log in to you server with configured sshd:

$ ssh tester@localhost
tester@localhost's password: 
-bash-4.2$ ls
bin  lib  lib64  usr
-bash-4.2$

[ Read More ]

Apache Installation and Configuration through source code

In this example we extract the source code to a directory under /usr/local/src/

cp httpd-2.0.46.tar.gz /usr/local/src

 cd /usr/local/src

 gunzip httpd-2.0.46.tar.gz

 tar -xvf httpd-2.0.46.tar

 rm -f httpd-2.0.46.tar

 cd httpd-2.0.46

You will see quite a few options there, we will set the prefix (the directory to install apache, we picked /usr/local/apache2) and also tell it which modules to compile and install. We will tell configure to compile and install all modules as shared DSO libraries, that way we can easily enable and disable them in the httpd.conf file. Here's how we ran configure:

 ./configure --prefix=/usr/local/apache2 --enable-mods-shared=all

Compile Apache Now to compile apache we run make this compiles the source code into executable binaries.

 make

Installing Apache The next step copies the binaries into the install directory, and sets up the modules.

make install

Starting/Stopping/Restarting Apache Now to start/stop apache use apachectl in the bin directory of your install dir.

 cd /usr/local/apache2/bin
 
 ./apachectl start
 
 ./apachectl stop
 
 ./apachectl restart

A script for init.d (optional) Here's a script you can save to /etc/init.d/httpd it is a modified version of the one that came in the rpm for Apache 2.0.40

#!/bin/bash
#
# Startup script for the Apache Web Server
#
# chkconfig: - 85 15
# description: Apache is a World Wide Web server.  It is used to serve \
#              HTML files and CGI.
# processname: httpd
# pidfile: /usr/local/apache2/logs/httpd.pid
# config: /usr/local/apache2/conf/httpd.conf

# Source function library.
. /etc/rc.d/init.d/functions

if [ -f /etc/sysconfig/httpd ]; then
        . /etc/sysconfig/httpd
fi

# This will prevent initlog from swallowing up a pass-phrase prompt if
# mod_ssl needs a pass-phrase from the user.
INITLOG_ARGS=""

# Path to the apachectl script, server binary, and short-form for messages.
apachectl=/usr/local/apache2/bin/apachectl
httpd=/usr/local/apache2/bin/httpd
pid=$httpd/logs/httpd.pid
prog=httpd
RETVAL=0


# The semantics of these two functions differ from the way apachectl does
# things -- attempting to start while running is a failure, and shutdown
# when not running is also a failure.  So we just do it the way init scripts
# are expected to behave here.
start() {
        echo -n $"Starting $prog: "
        daemon $httpd $OPTIONS
        RETVAL=$?
        echo
        [ $RETVAL = 0 ] && touch /var/lock/subsys/httpd
        return $RETVAL
}
stop() {
        echo -n $"Stopping $prog: "
        killproc $httpd
        RETVAL=$?
        echo
        [ $RETVAL = 0 ] && rm -f /var/lock/subsys/httpd $pid
}
reload() {
        echo -n $"Reloading $prog: "
        killproc $httpd -HUP
        RETVAL=$?
        echo
}

# See how we were called.
case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  status)
        status $httpd
        RETVAL=$?
        ;;
  restart)
        stop
        start
        ;;
  condrestart)
        if [ -f $pid ] ; then
                stop
                start
        fi
        ;;
  reload)
        reload
        ;;
  graceful|help|configtest|fullstatus)
        $apachectl $@
        RETVAL=$?
        ;;
  *)
        echo $"Usage: $prog {start|stop|restart|condrestart|reload|status"
  echo $"|fullstatus|graceful|help|configtest}"
        exit 1
esac

exit $RETVAL

Next run chkconfig to setup runlevels for which httpd will run:

chkconfig --add httpd
 
 chkconfig --level 2345 httpd on
 
 chkconfig --list
 

[ Read More ]

Tcpdump command with some examples

To print all packets arriving at or departing from sundown:

tcpdump host sundown

To print traffic between helios and either hot or ace:

tcpdump host helios and \( hot or ace \)

To print all IP packets between ace and any host except helios:

tcpdump ip host ace and not helios

To print all traffic between local hosts and hosts at Berkeley:

tcpdump net ucb-ether

To print all ftp traffic through internet gateway snup: (note that the expression is quoted to prevent the shell from (mis-)interpreting the parentheses):

tcpdump 'gateway snup and (port ftp or ftp-data)'

To print traffic neither sourced from nor destined for local hosts (if you gateway to one other net, this stuff should never make it onto your local net).

tcpdump ip and not net localnet

To print the start and end packets (the SYN and FIN packets) of each TCP conversation that involves a non-local host.

tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet'

To print all IPv4 HTTP packets to and from port 80, i.e. print only packets that contain data, not, for example, SYN and FIN packets and ACK-only packets. (IPv6 is left as an exercise for the reader.)

tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

To print IP packets longer than 576 bytes sent through gateway snup:

tcpdump 'gateway snup and ip[2:2] > 576'

To print IP broadcast or multicast packets that were not sent via Ethernet broadcast or multicast:

tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'

To print all ICMP packets that are not echo requests/replies (i.e., not ping packets):

tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'

[ Read More ]

History of MINIX 3

MINIX has a long history. It goes back to 1987 when the first edition of the book Operating Systems: Design and Implementation by Andrew S. Tanenbaum was published. The first version of MINIX was intended for teaching and it became very popular very quickly. One of the early users was a Finnish student, Linus Torvalds, who learned all about operating systems from reading the book and modifying the system. Eventually he went on to write his own operating system, Linux. In 2004, a man named Ken Brown accused Torvalds of copying MINIX verbatim, but that was quickly refuted in a statement published 20 May 2004 by Andrew Tanenbaum. A second edition of MINIX (and a second edition of the book, coauthored by Albert S. Woodhull) was released in 1997. This version was greatly improved from the first version but was still aimed at teaching operating systems to a large extent. It was only with the third version, MINIX 3, and the third version of the book, published in 2006, that the emphasis changed from teaching to a serious research and production system, especially for embedded systems. A few of the many differences between MINIX 2 and MINIX 3 are given here. Going forward, we are making a serious effort to turn MINIX 3 in an industrial-grade system with a focus on the embedded market, especially for those applications that need high reliability and availability.

[ Read More ]

Apache Configuration File Security Option

you’ll examine the security options available in the main Apache configuration file, httpd.conf. That file can be modified to secure the entire server or to configure security on a directory-by-directory basis. Directory controls secure access by the server, as well as users who connect to the web sites on the server. To explore the basics of Apache security, start with the first default active line in httpd.conf:

ServerTokens OS

This line looks deceptively simple; it limits the information displayed about a web server you navigate to a nonexistent page to the following message:

Apache/2.2.15 (Red Hat) Server at localhost Port 80

Contrast that output with what happens with a ServerTokens Full line:

Apache/2.2.15 (Red Hat) DAV/2 mod_ssl/2.2.15 OpenSSL/1.0.0-fips mod_wsgi/3.2

Python/2.6.5 mod_perl/2.0.4 Perl/v5.10.1 Server at localhost Port 80

In other words, with one option, outsiders can see whether modules such as Perl, Python, and PHP have been loaded, along with their version numbers. As not everyone updates their software in a perfectly timely manner, what happens when a cracker sees a version that has been compromised, your servers will face additional risks. Next, you can restrict access to the directory defined by the ServerRoot directive as shown here:

<Directory />

Options FollowSymLinks

AllowOverride None

</Directory>

This configures a very restrictive set of permissions. The Options FollowSymLinks line supports the use of symbolic links for web pages. The AllowOverride None line disables any .htaccess files. The ServerRoot directive points to /etc/httpd, which contains Apache configuration files. Without the AllowOverride None line, a cracker who inserts a malicious .htaccess file can configure permissions that allows any user to change such configuration files. However, there’s an appropriate use for .htaccess files. For example, when placed in a subdirectory such as /www/html/project, then it can be used to permit access to a group, and such changes would apply only to that directory. You can improve this by limiting access to all but explicitly allowed users, by adding the following commands to the desired <Directory> container:

Order deny,allow

Deny from all

The next <Directory> container example limits access to /var/www/html, which corresponds to the default DocumentRoot directive (while these directives are divided by numerous comments, they are all in the same stanza):

<Directory /var/www/html>

Options Indexes FollowSymLinks

AllowOverride None

Order allow,deny

Allow from all

</Directory>

The Options directive is different; the Indexes setting allows readers to see a list of files on the web server if no index.html file is present in the specified directory. The Order and Allow lines allow all users to access the web pages on this server. Finally, the Listen directive defines the IP address and TCP/IP port for this server. For example, the default shown next means that this server will work with every computer that requests a web page from any of the IP addresses for your computer on the standard TCP/IP port, 80:

Listen 80

If more than one IP address is available on the local system, the Listen directive can be uses to limit access to one specific IP address. For example, if a system has two network cards with IP addresses 192.168.0.200 and 192.168.122.1, the following directive can help limit access to systems on the 192.168.122.0 network:

Listen 192.168.122.1:80

[ Read More ]

Apache and SELinux File Labels

Take a look at the SELinux settings associated with Apache. To review, SELinux settings, as they relate to a service, mostly fall into two categories: boolean settings and file labels. Start with the file labels.

Apache and SELinux File Labels

The default file labels for Apache configuration files are consistent, as shown in the output to the ls -Z /etc/httpd and ls -Z /var/www commands. Individual files use the same contexts as their directory. For web sites where scripts read and or append data to web forms, you’d consider the last two contexts, which support read/write (rw) and read/append (ra) access.

Create a Special Web Directory

In many cases, you’ll create dedicated directories for each virtual web site. It’s better to segregate the files for each web site in its own directory tree. But with SELinux, you can’t just create a special web directory. You’ll want to make sure that new directory at least matches the SELinux contexts of the default /var/www directory. Run the ls -Z /var/www command. Note the SELinux contexts. For most directories, the user context is system_u and the type is http_sys_content_t. For a newly created /www directory, you could just change the SELinux contexts with the following commands. The -R applies the changes recursively, so the new contexts are applied to files and subdirectories.

# chcon -R -u system_u /www/

# chcon -R -t httpd_sys_content_t /www/

Of course, if scripts are required for the associated web site, you’ll want to run the following command to make sure the SELinux changes survive a relabel:

# semanage fcontext -a -s system_u -t httpd_sys_content_t /www/

This command creates a file_contexts.local file in the /etc/selinux/targeted/ contexts/files directory. If there’s also a cgi-bin/ subdirectory, you’ll want to set up appropriate contexts for that subdirectory as well with the following command:

# semanage fcontext -a -s system_u -t httpd_sys_script_exec_t  /www/cgi-bin/

The differences in the file contexts are shown in Table

Directory	SELinux Context Type
/etc/httpd, /etc/httpd/conf, /etc/httpd/conf.d, /var/run/httpd	httpd_config_t
/usr/lib64/httpd/modules	httpd_modules_t
/var/log/httpd	httpd_log_t
/var/www, /var/www/error, /var/www/html, /var/www/icons, /var/www/manual, /var/www/usage	httpd_sys_content_t
/var/www/cgi-bin	httpd_sys_script_exec_t
n/a	httpd_sys_content_rw_t
n/a	httpd_sys_content_ra_t

[ Read More ]