SVN Most Useful Commands

Subversion is a free/open-source version control system.

A tree of files is placed into a central repository.

The repository is much like an ordinary file server, except that it remembers every change ever made to your files and directories.
This allows you to recover older versions of your code, or examine the history of how your code was changed.

SVN client program which manages local reflections of portions of that versioned data which is called as working copy.

SVN Checkout – Create working copy

Checkout command is used to download sources from SVN repository to working copy.
 
SVN checkout creates the working copy, from where you can do edit, delete, or add contents. You can checkout a file, directory, trunk or whole project.

$ svn checkout/co URL PATH

When you do a checkout, it creates hidden directory named .svn, which will have the repository details.

SVN Commit – Save changes to the repository

Whenever you do changes to the working copy, it will not reflect in SVN server. To make the changes permanent, you need to do SVN commit.

$ svn commit -m "log messages"

SVN List – Lists directory entries

svn list is useful when you want to view the content of the SVN repository, without downloading a working copy.
 
lists all the files available in the given URL in the repository.
  
$ svn list url

When you execute svn list command with –verbose option it displays the following information.

Revision number of the last commit
Author of the last commit
Size (in bytes)
Date and time of the last commit 

$ svn list --verbose https://www.ctechz.com/svn/project/trunk

 16 ctechz  28361  Apr 16 21:11 README.txt
 21 ctechz   0        Apr 18 12:22 INSTALL
 22 ctechz         Apr 18 10:17 src/

SVN Add – Add a new file to SVN repository

When you want to add a new file (or directory) to the repository you need to use SVN add command. 

The repository will have newly added file, only when you do SVN commit. Now let us add a new file called “ctechz” to our repository.

* Create a file in local working copy
touch ctechz

* Add the file into SVN repository

svn add filename will add the files into SVN repository. From working copy

$ svn add ctechz
A         ctechz

* Commit the added file
Until you commit, the added file will not be available in the repository.

$ svn commit -m "Adding file ctechz" projectURL  
  ------- if from working dir it will upload automatically
Adding         ctechz
Transmitting file data .
Committed revision 84.

SVN Delete – Removing a file from repository

SVN delete command deletes an item from the working copy (or repository). File will be deleted from the repository when you do a SVN commit.

$ svn delete URL

$ svn delete ctechz  -- it will remove the recently created file

$ svn commit -m "Deleting ctechz file" ctechz
Deleting       ctechz
Committed revision 85.

SVN Diff – Display the difference

SVN diff displays the differences between your working copy and the copy in the SVN repository. You can find the difference between two revisions and two paths etc.

$ svn diff filename
$ svn -r R1:R2 diff filename

The above example compares the filename@R1 and filename@R2.

Now the content of the file ctechz will be,

# cat ctechz
testing

now edited the content of ctechz file from testing to tester, which is shown below using the svn diff command.

$ svn diff ctechz
Index: ctechz
--------------------------------
--- ctechz   (revision 85)
+++ ctechz   (working copy)
@@ -1 +1 @@
-testing
+tester 

SVN Status – Status of the working copy

Use svn status command to get the status of the file in the working copy. 

It displays whether the working copy is modified, or its been added/deleted, or file is not under revision control, etc.

$ svn status PATH

The following example shows the status of local working copy,

$ svn status /home/ctechz/cfg
M        /home/ctechz/cfg/ftp_user.cfg
M          /home/ctechz/cfg/ctechz 

‘M’ represents that the item has been modified.  Check for “svn help status” for more options.

SVN Log – Display log message

SVN remembers every change made to your files and directories. To know all the commits made in a file or directory, use SVN log command.

$ svn log PATH

$ svn log ctechz(or project path)

SVN Move – Rename file or directory

This command moves a file from one directory to another or renames a file.

$ svn move src dest

The file will be moved on your local working copy immediately (as well as on the repository after committing).

$ svn move ctechz new-ctechz

Now the file is renamed only in the working copy, not in the repository. To make the changes permanent, you need to commit the changes. 

$ svn commit -m "Renaming ctechz to new-ctechz" new-ctechz

SVN Update – Update the working copy

svn update command brings changes from the repository into your working copy. If no revision is specified, it brings your working copy up-to-date with the HEAD revision. Otherwise, it synchronizes the working copy to the revision given in the argument.

Always before you start working in your working copy, update your working copy. So that all the changes available in repository will be available in your working copy. i.e latest changes.

$ svn update PATH

In case some other user added/deleted file in Repository, your working copy will not have those files by default, until you update your working copy.

$ svn update
A  new/user2
A  new/web1
Updated to revision 816

SVN (Subversion) trunk,branches,tags

Trunk: Main development area. This is where your next major release of the code lives, and generally has all the newest features.

Branches: Every time you release a major version, it gets a branch created. This allows you to do bug fixes and make a new release without having to release the newest - possibly unfinished or untested - features.

Tags: Every time you release a version (final release, release candidates (RC), and betas) you make a tag for it. This gives you a point-in-time copy of the code as it was at that state, allowing you to go back and reproduce any bugs if necessary in a past version, or re-release a past version exactly as it was. Branches and tags in SVN are lightweight - on the server, it does not make a full copy of the files, just a marker saying "these files were copied at this revision" that only takes up a few bytes. With this in mind, you should never be concerned about creating a tag for any released code.

For example, let's say you start a new project, so you're working on what will be 1.0 in trunk. Once 1.0 is finished, you branch trunk into a new "1.0" branch, and create a "1.0" tag. Now work on what will eventually be 1.1 continues in trunk. 

You come across some bugs in the code, and fix them in trunk, and then merge the fixes over to the 1.0 branch. You may also get bug reports for 1.0, and fix the bugs in the 1.0 branch, and then merge them back to trunk. Sometimes a bug can only be fixed in 1.0 because it is obsolete in 1.1. It doesn't really matter, the only thing is you want to make sure that you don't release 1.1 with the same bugs that have been fixed in 1.0. Once you find enough bugs (or maybe one critical bug), you decide to do a 1.0.1 release. So you make a tag "1.0.1" from the 1.0 branch, and release the code. At this point, trunk sill contains what will be 1.1, and the "1.0" branch contains 1.0.1 code. The next time you release an update to 1.0, it would be 1.0.2.

Eventually you are almost ready to release 1.1, but you want to do a beta first. In this case, you likely do a "1.1" branch, and a "1.1beta1" tag. Now, work on what will be 1.2 (or 2.0 maybe) continues in trunk, but work on 1.1 continues in the "1.1" branch. Once you release 1.1 final, you do a "1.1" tag from the "1.1" branch.

You can also continue to maintain 1.0 if you'd like, porting bug fixes between all 3 branches (1.0, 1.1, and trunk). The important take away is that for every main version of the software you are maintaining, you have a branch that contains the latest version of code for that version.

Another use of branches is for features. This is where you branch trunk (or one of your release branches) and work on a new feature in isolation. Once the feature is completed, you merge it back in and remove the branch. The idea of this is when you're working on something disruptive (that would hold up or interfere with other people from doing their work), something experimental (that may not even make it in), or possibly just something that takes a long time (and you're afraid if it holding up a 1.2 release when you're ready to branch 1.2 from trunk), you can do it in isolation in branch. Generally you keep it up to date with trunk by merging changes into it all the time, which makes it easier to re-integrate (merge back to trunk) when you're finished.

Also note, the versioning scheme I used here is just one of many. Some teams would do bug fix/maintenance releases as 1.1, 1.2, etc, and major changes as 1.x, 2.x, etc. The usage here is the same, but you may name the branch "1" or "1.x" instead of "1.0" or "1.0.x". 

The trunk is the development line that holds the latest source code and features. It should have the latest bug fixes in it as well as the latest features added to the project.

The branches are usually used to do something away from the trunk (or other development line) that would otherwise break the build. New features are often built in a branch and then merged back into the trunk. Branches often contain code that are not necessarily approved for the development line it branched from. For example, a programmer could try an optimization on something in a branch and only merge back in the development line once the optimization is satisfactory.

The tags are snapshots of the repository at a particular time. No development should occur on these. They are most often used to take a copy of what was released to a client so that you can easily have access to what a client is using.

SVN commands Help

svn checkout file:///tmp/repos/test  ------- checking out the repository

svn add testdir --------- When adding a directory, the default behavior of svn add is to recurse

svn add --non-recursive otherdir ---- You can add a directory without adding its contents

svn add * --force ------

svn cat http://svn.red-bean.com/repos/test/readme.txt ------- If you want to view readme.txt in your repository without checking it out

svn checkout file:///tmp/repos/test mine --- Check out a working copy into a directory called mine

svn checkout file:///tmp/repos/test  file:///tmp/repos/quiz ------ Check out 2 different directories into two separate working copies

svn checkout file:///tmp/repos/test  file:///tmp/repos/quiz working-copies ---- Check out 2 different directories into two separate working copies, but place both into a directory called working-copies.

svn propset svn:mime-type image/jpeg foo.jpg ---- Set the mimetype on a file

svn propset svn:executable ON somescript  -------- On a UNIX system, if you want a file to have the executable permission set

svn propset --revprop -r 25 svn:log "Journaled about trip to New York."  ----------- If you made a mistake in a log message for a particular revision and want to change it, use --revprop and set svn:log  to the new log message.

svn delete myfile --------- Using svn to delete a file from your working copy merely schedules it to be deleted. When you commit, the file is deleted in the svn commit -m "Deleted file 'myfile'."  repository.

svn delete -m "Deleting file 'yourfile'" file:///tmp/repos/test/yourfile   ---------- Deleting a URL, however, is immediate, so you have to supply a log message     

svn status wc ------- This is the easiest way to find out what changes you have made to your working copy

svn status --show-updates wc -------- if you want to find out what files in your working copy are out-of-date, pass the --show-updates switch.

svn status --show-updates --verbose wc

svn update ------- Pick up repository changes that have happened since your last update

svn update -r30 ---------- You can also update your working copy to an older revision.

svn commit -m "added howto section." ------- Commit a simple modification to a file with the commit message on the command line and an implicit target of your current directory.

svn commit -F msg foo.c ----- Commit a modification to the file foo.c with the commit message in a file named msg

svn commit -m "removed file 'c'." ----- To commit a file scheduled for deletion

svn move foo.c bar.c  ---------- Move a file in your working copy

svnadmin dump /usr/local/svn/repos ---- Dump your whole repository.

svnadmin dump /usr/local/svn/repos -r 21 --incremental ----- Incrementally dump a single transaction from your repository

svnadmin recover ---- Recover a hung repository, Bring a repository database back into a consistent state.

svnadmin dump /path/to/reponame > /tmp/reponame.dump ; scp -rp /tmp/reponame.dump user@server.domain.com:/tmp/  ------- dump

svnadmin load /path/to/reponame < /tmp/repo1.dump  ------------ restoring svn repository from dump 

 SVN Dump 

# svnadmin dump /usr/local/svn/repos > full.dump ---- Dump your whole repository.

# svnadmin dump /usr/local/svn/repos -r 21 --incremental > incr.dump ---- Incrementally dump a single transaction from your repository.

# svnadmin recover --------- Recover a hung repository, Bring a repository database back into a consistent state.

# svnadmin dump /path/to/reponame > /tmp/reponame.dump ; scp -rp /tmp/reponame.dump user@server.domain.com:/tmp/ ------- dump.

# svnadmin load /path/to/reponame < /tmp/repo1.dump --- restoring svn repository from dump.

# cd /var/www/svn/
# svnadmin create test2
# svnadmin load /var/www/svn/test2 < svn.dump (dump of script repo)

To Restore Svn Dump

# svnadmin create /var/www/SVN/Project
# svnadmin load /var/www/SVN/project < project4.dump
# svnadmin load /var/www/SVN/project < project4_trunk.dump ----> If need to restore only the trunk. 

Importing from remote machine

svn import --username ctechz workingDir http://192.168.0.54/projectName/trunk -m "prodmlserver"
if u are committing files for the first time do this much.

if any changes are made by developers by checkout it and we want to add it into the server use the 'svn add' cmd

if we modify any changes in checkout file, just specify # svn update --- so that the updation will get for all the users if add and folders or touched any files give # svn add before committing them 
# svn ci

Renaming an SVN(Subversion) Repository 

SVN is document versioning software commonly used by software developers as a repository for source code.

Issue: Renaming a Repository
Here's the scenario: We have an SVN repository and we want to change it's name.

The solution: svnadmin dump & svnadmin load

The correct way to do this is to actually create a repository with the new name, and then import all revisions from the old repository into the newly created one. This way, all the revision history will be preserved

So, first we create a repository with the new name. Assuming /path/to/new/repository/ is the path where you want the new repository to be created, and <new-repo-name> is the new name, the command would look like this..

# svnadmin create /path/to/new/repository/<new-repo-name>

Then we dump all the data from the old respository into a file called old-repo.dump. We will assume /the/path/to/old/repository/ is the path to the repository and that the old repository was called old-repo-name.

# svnadmin dump /the/path/to/old/repository/<old-repo-name> > old-repo.dump
 
Now, we can import the dump file into the newly created repository. In order to to that we use the SVN load command.

# svnadmin load /the/path/to/new/repository/<new-repo-name> < old-repo.dump
NOTE: One thing to note is that for this method to be successful, the newly created repository has to be empty. Otherwise you may get all sorts of errors and/or funny results.

The other observation that I would make is that in case of a large project, this process may take a while and the resulting dump file and new repository may be rather large.

To remove a directory from svn 

# svn remove dir
# svn list file:///var/www/svn/script/trunk/
# svn ci -m "commit"
# svn list file:///var/www/svn/script/trunk/

To re-name a directory in svn 

# svn ren sqlbkp.sh sqlbkp1.sh
# svn list file:///var/www/svn/script/trunk/
# svn ci -m "commit"
# svn list file:///var/www/svn/script/trunk/

To backup only your latest revision

First you need to find out the latest revision number from your repository. To do that just run below command:

# svnadmin verify [REPO_PATH]
 
It will list out the revision number and the most bottom will be your latest revision number. That will be referenced by [LATEST_REVISION_NUM] from now on.

Run below command to backup only the latest revision from [REPO_PATH].
 
# svnadmin dump -r [LATEST_REVISION_NUM] [REPO_PATH] > [DUMP_FILE_PATH] 

The version number is just a shortcut to the date at which the project is stamped. Let's now get a copy of the previous version(assuming the revision number is 4)
 
cd /tmp/
$ svn checkout -r 3 file:///home/user/svn project
U project/project/trunk/src/main.cpp
U project/project/trunk/src/Makefile
D project/project/trunk/src/class.cpp
D project/project/trunk/src/class.h
Checked out revision 3.

Have a closer look at the output. It shows how clever svn is. We asked for version 3 but because of our previous command, the version 4 is already in /tmp.

No problem, svn does all the necessary things and indicate them : the main.cpp and Makefile are updated and the class.{h,cpp} files are deleted.

How to setup an SVN Repository

# yum install httpd subversion mod_authz_ldap mod_dav_svn
 
# mkdir /var/www/svn
# cd /var/www/svn
 
# svnadmin create Project1
# ls Project1/
# cd /tmp/
 
# mkdir Project1
# cd Project1/
 
# mkdir branches tags trunk
# cd ..
 
# svn import Project1/ file:///var/www/svn/Project1 -m "Importing new project"
 
# svn list file:///var/www/svn/Project1/
# rm -rf Project1
# cd /var/www/svn/
 
# chown apache. -R *
# cd ..

# vim /etc/httpd/conf.d/subversion.conf
[
Location /Project1
DAV svn
SVNPath /var/www/svn/Project1

# Limit write permission to list of valid users.
# Require SSL connection for password protection.
# SSLRequireSSL

AuthType Basic
AuthzSVNAccessFile /etc/httpd/password/svnauthz.conf
AuthName "LDAP AUTHENTICATION"
AuthBasicProvider ldap
AuthLDAPURL ldap://192.168.0.20:389/ou=People,dc=my-domain,dc=com?uid?sub?(objectClass=*)
# AuthUserFile /path/to/passwdfile
Require valid-user
order allow,deny
Allow from all

Location
]

# mkdir /etc/httpd/password

# vim /etc/httpd/password/svnauthz.conf

[
[groups]
others = rick
linux = ctechz, btechz

[Project1:/]
@systemsteam = rw
@others = r

]

# service httpd restart

 SVN Client

tortoisesvn ------ for windows
smartsvn ------- for linux

# svn co http://192.168.0.20/Project1/trunk/
 
# cd trunk
# cp bin trunk
# svn add bin
 
# svn ci bin m "Adding project"
# svn ci test/ http://192.168.0.19/Project1/trunk/ -m "Adding project"
 
# cd
# svn import --username aby test/ http://192.168.0.19/Project1/trunk/ -m "Adding Project" ------ import to add a new project
 
# svn list http://192.168.0.19/Project1/trunk/

Setting UP a new SVN Project 

# cd /var/www/test
# ls
 
# svnadmin create PG_Script
 
# cd /tmp/
# mkdir PG_Script
# cd PG_Script/
 
# mkdir trunk branches tags
 
# ls
# cd
# cd /tmp/
 
# svn import PFG_Script/ file:///var/www/test/PG_Script/ -m "Importing Script"
 
# rm -rf PG_Script/
# cd /var/www/test
# ll
 
# chown apache.apache PFG_Script -R
 
# ll
# cd
 
# vim /etc/httpd/conf/httpd.conf
 
# vim /etc/httpd/passwd/svnauthz.conf
 
# /etc/init.d/httpd reload

# svn import --username aby test/ http://192.168.0.19/Project1/trunk/ -m "Adding Project" ------ import to add a new project

SVN check-out and check-in 

# svn co file:///var/www/svn/script/trunk/
# cp sqlbkp.sh /root/trunk/
# cd trunk/
 
# svn add sqlbkp.sh
# svn ci -m "import"

 Make a New dir

# mkdir dir
# cd dir/
# touch 1 2 3
# mkdir g t r
# cd .. 

# svn add dir
# svn ci -m "import"
# svn list file:///var/www/svn/script/trunk/

How to Examining Local Network Activities in a system

Problem: Want to examine network use occurring on your local machine.

Solution: To print a summary of network use,

# netstat --inet             connected sockets
# netstat --inet --listening  Server sockets
# netstat --inet --all        Both
 
To assign dynamically assigned ports for RPC processes,

# rpcinfo -p [host]

To list network connections for all processes:

# lsof -i[tcp][udp][@host][:port]

To list all open files for specific processes:

# lsof -p pid
# lsof -c command
# lsof -u username

To list all open files for all processes

# lsof

You can also select processes by ID (-p), command name (-c), or username (-u)
# lsof -a -c myprog -u tony

Note: Programs like ps, netstat, and lsof obtain information from the linux kernel via the /proc filesystem.
      
The most important files for networking are /proc/net/tcp and /proc/net/udp, both consulted by netstat. Kernel parameters related to networking can be found in the /proc/sys/net directory.

Information for individual processes is located in /proc/<pid> directories, where <pid> is the process id, for example, the file
 /proc/12345/cmdline contains the orginal command line that invoked the (current running) process 12345.

How to check for Suspecious Account Use

Problem: Want to find out unusual or dangerous usage of accounts on your system: dormant user accounts, recent logins to system accounts etc. 

Solutions:
 
1. To print information about the last login for each uesr:
    # lastlog -u username

# lastlog -u root
Username   Port     From             Latest
root          pts/2    192.168.1.3  Wed Aug 14 21:43:11 -0700 2013

# lastlog -u ctechz
Username         Port     From             Latest
ctechz                                     **Never logged in**

2. To print entire login history:
    # last username

[root@localhost ~]# last ctechz
ctechz   pts/3      192.168.0.30   Thu Jun 27 05:32 - 05:32  (00:00)   
ctechz   pts/3      192.168.0.30   Thu Jun 27 05:31 - 05:31  (00:00)   
ctechz   pts/2      192.168.0.30   Tue Jun 25 04:38 - 04:39  (00:01)   
ctechz   pts/2      192.168.0.30   Tue Jun 25 04:18 - down   (00:04)
 
3. To print failed login attempts:
    # lastb username

# lastb ctechz
ctechz  ssh:notty  192.168.0.30  Tue Jun 25 04:38 - 04:38 (00:00)   
ctechz  ssh:notty  192.168.0.30  Tue Jun 25 04:18 - 04:18 (00:00)   
ctechz  ssh:notty  192.168.0.30  Mon Jun 24 22:42 - 22:42 (00:00)    
  
To enable recording of bad logins:
  # touch /var/log/btmp
 # chown --reference=/var/log/wtmp /var/log/btmp
 # chmod --reference=/var/log/wtmp /var/log/btmp

Note:-
Attackers look for inactive accounts that are still enables, in the hope that intrusions will escape detection for long periods of time.

  Linux systems record each user's last login time in the database /var/log/lastlog. The terminal and remote system name, if any are also noted.

The /var/log/lastlog is a database not a log file.

In contrast, the btmp log file will grow slowly (unless you are under attack) but it should be rotated like other log file.
 You can either add btmp to the wtmp entry in /etc/logrotate.conf or add a similar entry in a separate file in the /etc/logrotate.d dir

A history of all logins and logouts is recorded in the log file /var/log/wtmp. The "last" command scans this log file to produce a report of all login sessions,in reverse chronological order, sorted by login time.

Failed login attempts can also be recorded in the log file /var/log/btmp, but this is not done by default. To enable recording of bad logins, create the btmp file manually, using the same owner, group, and permissions as for the wtmp file. The "lastb" command prints the history of bad logins.

In Linux/Unix operating systems everything is logged some where.
Most of the system logs are logged in to /var/log folder. This folder contains logs related to different services and applications.
In this folder we have some files such as utmp, wtmp and btmp.
These files contains all the details about login’s and logout’s which are from local as well as from remote systems and system status such as uptime etc.

utmp will give you complete picture of users logins at which terminals, logouts, system events and current status of the system, system boot time etc.

wtmp gives historical data of utmp.
btmp records only failed login attempts.

Normally when we try to view these files using cat command or vi editor they used to throw some junk characters and garbage values or in encrypted form or hex values. The output of these files when open with vi or cat command are shown below to show how wtmp file look when opened with vi.

We can read this file with only last command.

"last" command is one of the important command which will give you how logged in, when they logged in and when they logged out etc info on the screen.
# last
This last command display many details about user login/logout activity. The same command can be used to view wtmp, utmp and btmp files.

To open wtmp file and view its content use below command 
# last -f /var/log/wtmp

jeffin   pts/2    192.168.0.30  Tue Jun 25 01:59 - down   (00:23)   
root     pts/1        :0.0           Tue Jun 25 01:59 - down   (00:24)   
root     :0                             Tue Jun 25 01:59 - down   (00:24)   
root     :0                             Tue Jun 25 01:59 - 01:59  (00:00)   
reboot   system boot  2.6.18-194.el5   Tue Jun 25 01:57 (00:26)   
jeffin   pts/2    192.168.0.30  Tue Jun 25 01:43 - down   (00:11)   
jeffin   pts/2    192.168.0.30  Tue Jun 25 01:41 - 01:43  (00:01)   
ctechz  pts/3   192.168.0.30  Mon Jun 24 23:38 - 23:38  (00:00)   
ctechz  pts/3   192.168.0.30  Mon Jun 24 23:31 - 23:31  (00:00) 

To see still logged in users view utmp file use last command
# last -f /var/run/utmp

To view btmp file use same command
# last -f /var/log/btmp
                                                         gone - no logout
root     ssh:notty  192.168.0.30 Tue Jun 25 03:49 - 04:18 (00:28)   
root     ssh:notty  192.168.0.30 Tue Jun 25 03:37 - 03:49 (00:12)   
cteechz  ssh:notty 192.168.0.30 Mon Jun 24 23:37-03:37 (04:00)   
cteechz  ssh:notty 192.168.0.30 Mon Jun 24 23:37 - 23:37 (00:00)

How to install chkrootkit on centos

Checking for Rootkits in a system
 
chkrootkit is a collection of tools to detect the presence of rootkits.  chkrootkit uses C and shell scripts to perform a detailed process check, and scans systems binaries to detect kit signatures. Upon detection, in most cases, it can remove rootkits too.
 
The following lists the chkrootkit internal programs and what each of them do.


chkrootkit-Program         Purpose

chkrootkit          Main script to check for tampered
                     system files

strings.c           Detects and performs string replacement

ifpromisc.c         Checks network interface 
                     for promiscuous mode

chklastlog.c,chkwtmp.c  Checks if lastlog and wtmp
                           entries are deleted

chkproc.c,chkdirs.c  Checks for Linux kernel 
                         module-based Trojans

# md5sum chkrootkit.tat.gz

# tar -xvjf chkrootkit.tat.gz

# cd chkrootkit-*
# make sense
# ./chkrootkit

# ./chkrootkit -p /mnt/cdroam OR
# ./chkrootkit

chkrootkit tessts for the presence of certain rootkits,worms and trojans on your system. if you have been hacked it is a good first step to diagnosis.

Crond run chkrootkit hourly shoot in the mail administrator is ctechz@ctechz.com
 
# vi /etc/cron.hourly/chkrootkit.sh

#!/bin/bash
chkrootkit | mail -s “Hour chkrootkit from Servername” ctechz@ctechz.com
# chmod +x /etc/cron.hourly/chkrootkit.sh

How to install Rkhunter (Rootkit Hunter) in centos

Rkhunter (Rootkit Hunter)  that scans backdoors, rootkits and local exploits on your systems. It scans hidden files, wrong permissions set on binaries, suspicious strings in kernel etc.

Download the package

# cd /opt/hunter
# wget http://ncu.dl.sourceforge.net/project/rkhunter/rkhunter/1.4.0/rkhunter-1.4.0.tar.gz

Run the following commands as root

# tar -xvf rkhunter-1.4.0.tar.gz
# cd rkhunter-1.4.0
# ./installer.sh --layout default --install

Fill up the database properties

# /usr/local/bin/rkhunter --update
# /usr/local/bin/rkhunter --propupd

Setup cronjob and Email alert for daily

Create a file called rkhunter.sh under /etc/cron.daily/ which scans your system daily

# vi /etc/cron.daily/rkhunter.sh

replace “ServerNameHere” with "YourServerName” and “your@email.com” with your “Email Id“.

#!/bin/sh
(
/usr/local/bin/rkhunter --versioncheck
/usr/local/bin/rkhunter --update
/usr/local/bin/rkhunter --cronjob --report-warnings-only
) | /bin/mail -s 'rkhunter Daily Run (PutYourServerNameHere)' your@email.com

# chmod 644 /etc/cron.daily/rkhunter.sh

Manual Scanning and usage

To scan the entire file system, run the Rkhunter as a root user.
# rkhunter --check

The above command generates log file under /var/log/rkhunter.log with the checks results made by Rkhunter.

For more information and options please run the following command.
# rkhunter --help

How to test for open ports in a system

Problem: Want a listing of open network ports on your system
 
Solution: Probe your ports from a remote system.

Test a Specific TCP port(ssh):-
# telnet target.example.com ssh
# nc -v -z target.example.com ssh

To scan most of the interesting TCP ports:-
# nmap -v target.example.com

To test a specific UDP port (1024)
# nc -v -z -u target.example.com 1024

To scan most of the interesting UDP ports (slowly!)
# nmap -v -sU target.example.com

To do host discovery (only) for a range of address, without port scanning
# nmap -v -sP 10.12.104.200-222

To do OS fingerprinting
# nmap -v -O target.example.com

 Namp command is a powerful and widely used tool for network security testing. It gathers information about target systems in three distinct phace:-

1. Host Discovery: 
Initial probes to determine which machines are responding within an address range.

2. Port Scanning: 
Test to find open ports that are not protected by firewalls, and are accepting connections

3. OS fingerprinting: Will get more details about the targets

To probe a single target, host name or address:
# nmap -v target.example.com
# nmap -v 10.12.200.115

-v option give more info, also can use -v -v option for more details

You can also scan a range of address:-
# nmap -v target.example.com/24
# nmap -v 10.12.200.115/24
# nmap -v 10.12.200.0-255
# nmap -v "10.12.200.*"

nmapfe is a graphical front end that run nmap with an appropriate command line.

Use nmap -P option if your tcp or icmp ping is blocked.

The goal of host discovery is to avoid wasting time performing port scanning for unused addresses.If you know your targets are up you can disable host discovery with the -P0(zero) option.

The simplest way to test a tcp port is to try to connect with telnet. 

The port might be open,
# telnet target.example.com ssh
  trying target.example.com.....
   connecting to target.example.com.
   Escape character is '^]'.
  
or closed(ie, passed by the firewall, but having no server accepting connections on the target)

# telnet target.example.com 33333
  trying target.example.com.....
  telnet: connection to address 10.12.19.99: connection refused
or blocked(filtered by firewall):
 
# telnet target.example.com 137
  trying target.example.com.....
  telnet: connection to address 10.12.19.99: connection timed out 

The nc command is an even better way to probe ports:

# nc -z -vv target.example.com ssh 33333 137
target.example.com [10.12.19.99] 22 (ssh) open
target.example.com [10.12.19.99] 33333 (?):Connection refused
target.example.com [10.12.19.99] 137 (netbios-ns):Connection timed out 

The -z option requests a probe, without transferring any data.

UDP ports are harder to probe than TCP ports, because packet delivery is not guaranteed.

How to find passwordless Accounts in a system

 Finding Accounts with no Passwords

awk -F":" '($2 == "!" || $2 == "*" || $2 == "!!" || $2 == "" ) {print $1 ": has no password at all"}' /etc/shadow

How to find Super User accounts in a system

  Find super user accounts

#  awk -F":" '($3 == "0") {print $1 ": is a root Account"}' /etc/passwd

Server Testing And Monitoring

Logins and Passwords: Testing password strength, 
 locating accounts with no passwords, tracking suspicious login activity.

FileSystems: Searching them for weak security, 
 and looking for rootkits.

Networking: Looking for open ports, Observing local 
 network use, packet-sniffing, tracing network processes,
and Detecting intrusions.

Logging: Reading your system logs, configure syslog, 
rotating log files.
   

 Testing Login Passwords(John the Ripper)

Problem: You want to check that all login passwords in your system password databases are strong

Solution: Use the John the Ripper, a password-cracking utility. After the software installed run,

###export PATH=/opt/john/run/ ----- export to the path
### cd /var/lib/john  --- depends on installation
un-tar the package
# cd /opt/john
# umask 077
# cd /run/
# unshadow /etc/passwd /etc/shadow > mypasswords
# john mypasswords

Cracked passwords will be written into the file john.pot, Cracked username/password pairs can be shown after the fact with the -show option

# john -show mypasswords

You can instruct john to crack the passwords of only only certain users or groups with the option -users:u1,u2... or -groups:g1,g2.....

# john -users:smith,jones,jeff mypasswords

Running John with no options will print usage information.

By Default, Redhat 8 uses MD5-hashed passwords stored in /etc/shadow, rather than the traditional DES-based crypt() hashes stored in /etc/passwd, this is effected by the md5 and shadow directives in /etc/pam.d/system-auth:

The unshadow command gathers the account and hash information together again for cracking. If your passwords change you will have to re-run the unshadow command to build an up-to-date password file for cracking.

In general cracking pgms use dictionaries of common words when attempting to crack a password, trying not only the words but also permutations, misspellings, caps etc. The default dic(/var/lib/john/password.lst) is small, so obtain larger once for effective cracking. Also add words appropriate to your environment etc

Some available dictionaries are:
ftp://ftp.cerias.purdue.edu/pub/dict/wordlists
ftp://ftp.ox.ac.uk/pub/wordlists/ 

concatenate your desired word lists into a single file, and point to it with the wordlist directive in /var/lib/john/john.ini

The supported options are as follows, square brackets denote optional arguments:

--single              "single crack" mode
Enables the "single crack" mode, using rules from the configuration file section [List.Rules:Single].

--wordlist=FILE      wordlist mode, read words from FILE,
--stdin              or from stdin

These are used to enable the wordlist mode.

Protecting Files and Directories

  
 Restrict users from accessing Files
 

Problem: You want to prevent other users on your machine from reading your files,

Solution: To protect existing files and directories,
# chmod 600 file_name
# chmod 700 directory_name

To protect future files and directories
# umask 077

Prohibiting Directory Listing

Problem: You want to prohibit directory listing for a particular directory, yet still permit the file within to be accessed by name,
 
Solution: Use a directory that has read permission disabled, but execute permission enabled,

# mkdir dir
# chmod 0111 dir
# ls -ld dir
# ls dir
/bin/ls : dir: permission denied

To permit only yourself to list a directory owned by you
# chmod 0711 dir
# ls -ld dir

SSH-Tunneling

 Tunneling Another TCP Session Through SSH

Problem: You want to secure a client/server TCP connection such as pop,imap,nntp,irc,vnc etc. both the client and server must reside on computers that run ssh.
 
Solution: Tunnel(forward) the TCP connection through SSH. To secure port 119, the NNTP protocol for usenet news, which you read remotely from news.example.com

# ssh -f -N -L12345:localhost:119 news.example.com

While this tunnel is open, read news via local port 12345,

# export NNTPSERVER=localhost
# tin -r -p 12345
Tunneling or port forwarding uses ssh to secure another tcp/ip connection, such as an NNTP or IMAP connection. you first create a tunnel, a secure connection between an ssh client and server. Then you make your tcp/ip applications communicate over the tunnel.

ssh -f -N -L12345:localhost:119 news.example.com

 It establishes a tunnel between localhost and news.example.com. The tunnel has three segments,

1. The news reader on your local machine sends data to local port 12345. This occurs entirely on your local machine, not over the network

2. The local SSH client reads port 12345, encrypts the data, and sends it through the tunnel to the remote ssh server on news.example.com

3. The remote ssh server on news.example.com decrypts the data and passes it to the news server running on port 119. This runs entirely on news.example.com not over the network.
   
there for when your local news client connect to local port 12345,
# tin -r -p 12345

the connection operates through the tunnel to the remote news server on news.example.com. Data is sent back from the news server to the news client by the same process in reverse.

The general syntax is:

ssh -f -N -Llocal_port_number:localhost:remote_port_number remote_host

How to protect Outgoing Network Connections - ssh

ssh - performs remote logins and remote command execution
 
scp - copies files between computers
 
sftp - copies files between computers, with an interactive, ftp-like user interface

sshd - server daemon

ssh-keygen - create and modifies public and private keys

ssh-agent  - caches ssh private keys to avoid typing pass-phrases
 
ssh-add    - Manipulates the key cache of ssh-agent

~/.ssh  - Directory(per user) for keys and configuration files
 
/etc/ssh - Directory(system wide) for keys and configuration files
 
~/.ssh/config - Client config file(per user)
 
/etc/ssh/sshd_config - client configuration file(system wide)

To invoke a remote command

# ssh -l remoteUser remotehost uptime

Authenticating by public key(OpenSSH)

Problem: you want to set up public-key authentication between an OpenSSH client and an OpenSSH server.

Solution:

 Public Key Authentication:-

Public key authentication let's you prove your identity to a remote host using a cryptographic key instead of a login password.

1. Generate a key if necessary:
  # mkdir -p ~/.ssh         ---- if it doen't already exist
  # chmod 700 ~/.ssh
  # cd ~/.ssh
  # ssh-keygen -t dsa
 
2. Copy the public key to the remote host:
  # scp -p id_dsa.pub remoteuser@remotehost:
    passwd: ****

3. Log into the remote host and install the public key:    
# ssh -l remoteUser remotehost
Password: *****
# mkdir -p ~/.ssh         ---- if it doen't already exist
# chmod 700 ~/.ssh
# cat id_dsa.pub >> ~/.ssh/authorized_keys   (appending)
# chmod 600 ~/.ssh/authorized_keys
# mv id_dsa.pub ~/.ssh    optional
# logout

4. Log back in via public-key authentication:

# ssh -l remoteUser remotehost
Enter passphrase for key '/home/smith//.ssh/id_dsa': ***

Note: SSH keys are more secure than passwords because keys are never transmitted over the network, where as passwords are.

An SSH "key" is actually a matched pair of keys stored in two files. The private or secret key remains on the client machine, encrypted with a passphrase. The public key is copied to the remote(server)machine.
When establishing a connection the SSH client and server perform a complex negotiation based on the private and public key and if they match, your identity is proven and the connection succeeds.

The SSH server must be configured to permit public-key authentication, which is the default

/etc/ssh/sshd_config
publickeyAuthentication yes   ---- if no, change it and restart sshd

Public-Key authentication lets allow you prove your identity to a remote host using a sryptographic key instead of a login password.

Getting users passwords in a system

#!/bin/bash
#Author: CtechZ
#Organization: ctechz.blogspot.com OR ctechz.com
#Date: 30-07-2013
#Purpose: Get passwords of all users and store it in a seperate file called "pass", also check this file "pass"
# is already their in that location or not, if yes not create any file else appent the passwords into it,if file is not their create a file
# called "pass" and add into it. It will only print root user's and normal users passwod, will not print any system user's

file=/etc/shadow
location=/Results/
file2=pass

:> $location/$file2
 
# Checking the pass file is their in location or not

if [ -f $location/$file2 ]
 then
cut -f2 -d: $file > $location/$file2 else    
touch $location/$file2 | cut -f2 -d: $file > $location/$file2
fi       

# Remove the system users password from the file "pass", Only need root user and normal users passwords
     
sed -i '/^*/d' $location/$file2 &&  sed -i '/^!!/d' $location/$file2

#EOF