How does a traceroute works ?

Lets try to answer this question - How does a traceroute works ?

On the konsole we type ( for example ) :

traceroute google.com

The output will be something like :

=====================================

traceroute to google.com (209.85.171.99), 30 hops max, 40 byte packets
1  192.168.0.4 (192.168.0.4)  13.654 ms  13.722 ms  13.737 ms
2  dsl-KK-static-001.192.95.61.airtelbroadband.in (61.95.192.1)  82.682 ms  82.896 ms  83.190 ms
3  ABTS-KK-Static-173.32.166.122.airtelbroadband.in (122.166.32.173)  83.483 ms  83.689 ms  84.059 ms
4  ABTS-KK-Static-009.32.166.122.airtelbroadband.in (122.166.32.9)  84.278 ms  84.572 ms  84.785 ms
5  122.175.255.29 (122.175.255.29)  85.119 ms  85.656 ms  85.882 ms
6  125.21.167.70 (125.21.167.70)  86.347 ms * *
7  * so-4-3-2.edge2.LosAngeles1.Level3.net (4.78.205.153)  322.074 ms  323.890 ms
8  vlan99.csw4.LosAngeles1.Level3.net (4.68.20.254)  324.165 ms  326.952 ms vlan69.csw1.LosAngeles1.Level3.net (4.68.20.62)  328.199 ms
9  ae-93-93.ebr3.LosAngeles1.Level3.net (4.69.137.45)  327.240 ms ae-63-63.ebr3.LosAngeles1.Level3.net (4.69.137.33)  327.550 ms ae-73-73.ebr3.LosAngeles1.Level3.net (4.69.137.37)  327.859 ms
10  ae-2.ebr3.SanJose1.Level3.net (4.69.132.9)  328.582 ms  328.933 ms  336.521 ms
11  ae-93-93.csw4.SanJose1.Level3.net (4.69.134.238)  336.794 ms ae-63-63.csw1.SanJose1.Level3.net (4.69.134.226)  339.650 ms ae-73-73.csw2.SanJose1.Level3.net (4.69.134.230)  321.976 ms
12  ae-81-81.ebr1.SanJose1.Level3.net (4.69.134.201)  317.552 ms ae-91-91.ebr1.SanJose1.Level3.net (4.69.134.205)  315.267 ms ae-61-61.ebr1.SanJose1.Level3.net (4.69.134.193)  312.909 ms
13  ae-3.ebr1.Seattle1.Level3.net (4.69.132.50)  353.243 ms  355.277 ms  355.642 ms
14  ae-11-53.car1.Seattle1.Level3.net (4.68.105.66)  358.504 ms ae-11-51.car1.Seattle1.Level3.net (4.68.105.2)  358.818 ms ae-11-55.car1.Seattle1.Level3.net (4.68.105.130)  361.111 ms
15  GOOGLE-INC.car1.Seattle1.Level3.net (4.79.104.74)  356.893 ms  358.424 ms  355.850 ms
16  209.85.249.34 (209.85.249.34)  325.808 ms  326.099 ms 209.85.249.32 (209.85.249.32)  327.433 ms
17  66.249.95.208 (66.249.95.208)  315.869 ms 209.85.249.16 (209.85.249.16)  316.681 ms  317.411 ms
18  * * *
19   (72.14.233.37)  331.734 ms  331.891 ms 64.233.174.97 (64.233.174.97)  334.826 ms
20  209.85.251.141 (209.85.251.141)  327.847 ms 209.85.251.153 (209.85.251.153)  368.172 ms  368.482 ms
21  74.125.30.130 (74.125.30.130)  365.568 ms  363.712 ms 74.125.30.134 (74.125.30.134)  364.437 ms
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

=====================================

Lets now understand this :

1. The first line of the output gives the IP address of the google.com, which is 209.85.171.99 and the maximum number of hops traceroute will keep track of the packets before it reaches the destination and the size of the packets which is 40 bytes.

2. The second hop is always to ones ISP’s gateway as shown by the address. On the same line, followed by the IP address, there are three time values in milli seconds. There are three values because traceroute by default sends simultaneously, 3 packets of 40 bytes each. And the three time values are the time taken to send the packets and receive a ICMP TIME_EXCEEDED response from the gateway. Put another way, these three values are the round trip times of the packets. So for the three packets to reach my ISP’s gateway, and get an echo back, it takes 13.654 ms  13.722 ms  13.737 ms.

3. Lets look at the 6th and 7th hops in the output above. If you compare the times, you will find a drastic increase in the times ( from 6th to 7th hop ). This is because up till the sixth hop, the gateway servers were within the Indian sub-continent itself. The 7th hops went to Los Angeles and so it takes that much more time to get a reply. Generally, smaller numbers mean better connections.

4. And from 22nd hop I get a series of time outs as shown by the asterisks. So my trace of the www.google.com domain resulted in a series of time outs and did not complete. The problems could be one of the following:
a.) The network connection between the server on the 21th hop and that on 22th hop is broken.
b.) The server on the 22th hop is down.
c.) Or there is some problem with the way in which the server on the 22th hop has been setup.

This is how we analize the traceroute result.

Now proceeding with the discussion further , lets talk about TCP/IP. The TCP/IP packets can be divided into two types :

1. IP ( Internet Protocol ) packets

2. ICMP ( Internet Control Message Protocol ) packets

Each of these packets has a Header and  Data part. The header contains information about sender, the target , TTL and other information necessary to take the packet to the destination.

There are nearly 13 types of ICMP packets ( ICMP is used for errors ) . One of them ( which is our concern here ) is ICMP_ECHO_REQUEST. This packet is used for pinging.

For a IP packet, it contains TCP and UDP as data parts. Also IP packets have TTL as one of the headers. This TTL value serves a great role in killing the mis-routed packets. If the network has some problem and these packets get mis-routed , they need to be timed out or else they will increase the bandwidth. Therefore we specify a TTL value.

This TTL value is decreased every time it crosess a router. If the packets goes through too many hops the packet gets killed and an ICMP error is sent back to the sender.

Now here is how traceroute works :

1.  First it sends packets with TTL= 1, the packet goes through the first hop and dies.
2.  That router sends back an ICMP error and that way we can determine its IP/ Hostname.
3. Then traceroute send packets with TTL=2 , it passes the first router and loses the TTL value by 1 , and  then goes to the second router and dies. Thus we get the IP/ Hostname of the second router.
4. This continues until the packet reaches its destination.

This is How a Traceroute works .

Remote access for Mysql ( In Cpanel servers )

To allow a remote mysql connection to a mysql database in a cPanel server, we need to allow the IP as :

cPanel > Remote Mysql > Add Access Host

When we add a IP suppose ” 97.89.191.105 ” , then this IP gets added inside the Iptables in the server as :

ACCEPT     all  –  97-89-191-105.dhcp.gnvl.sc.charter.com  anywhere

We can add the IP from the command line as :

1. Login to the mysql as :

mysql database name ;

Let us assume that you are always making connection from remote IP called 97.89.191.105 for database called webdb for user webadmin, To grant access to this IP address type the following command At mysql> prompt for existing database:

mysql> update db set Host=’97.89.191.105′ where Db=’webdb’;
mysql> update user set Host=’97.89.191.105′ where user=’webadmin’;

This will add the Iptables as :

ACCEPT     all  –  97-89-191-105.dhcp.gnvl.sc.charter.com  anywhere

Zombie Process

What is a Zombie process ?

On Unix operating systems, a zombie process or defunct process is a process that has completed execution but still has an entry in the process table, allowing the process that started it to read its exit status. In the term’s colorful metaphor, the child process has died but has not yet been reaped.

So the question comes – How to kill these Zombies ?

Zombie process is a process which is already dead. A usual notion regarding Zombie process was that they cannot be killed. They are removed when we reboot the server/system. But is there any other way to kill these dead processes.

The answer is Yes!. Here is how we can do this -

1. First we will find out the Zombie processes running on the server :

ps aux | awk ‘{ print $8 ” ” $2 }’ | grep -w Z

With a normal ps -el command you see an output with in the second colum the state of the process. Here are some states:
S : sleeping
R : running
D : waiting (over het algemeen voor IO)
T : gestopt (suspended) of getrasseerd
Z : zombie (defunct)

ps -el | grep ‘Z’

Also we can use the following command :

ps -A -ostat,ppid,pid,cmd | grep -e ‘^[Zz]‘ | awk ‘{print $2}’

2. Now we have found out the Zombie process. Its the time to kill them :

kill -9 `ps -A -ostat,ppid,pid,cmd | grep -e ‘^[Zz]‘ | awk ‘{print $2}’`
kill -HUP `ps -A -ostat,ppid,pid,cmd | grep -e ‘^[Zz]‘ | awk ‘{print $2}’`

This will kill a Zombie process.

Mailing List Using Mailman

How to fix this error in Mailing list ?  –  Bug in Mailman version 2.1.9.cp2

The Solution is :

If you are the server administrator, proceed with the following steps:

1. Go to /usr/local/cpanel/3rdparty/mailman
cd /usr/local/cpanel/3rdparty/mailman

2. ls -al

3. chmod -R 2775 ./*

Check if this has fixed the issue.
If not run the fixmailman script.

4. /scripts/fixmailman
This will fix the bug.

There are different mailman related binaries installed in a cpanel server
at /usr/local/cpanel/3rdparty/mailman/bin/ folder.

The binaries  config_list , list_members and  add_members can be used
for this purpose.

First go to the /usr/local/cpanel/3rdparty/mailman/  folder and find the name
of the mailing list being dealt with
under  /usr/local/cpanel/3rdparty/mailman/lists folder , it is like
listname_domainname
use the following command to get the list of subscribers in that list
list_members -o <outputfile> <listname>

example —

1.        /usr/local/cpanel/3rdparty/mailman/bin/list_members -o test fotball_kanligadet.com

check the test file for the list of members

get the configuration of the list using
config_list -o <outputfile> <listname>

example —-

2.       /usr/local/cpanel/3rdparty/mailman/bin/config_list -o test1 fotball_kanligadet.com
check the test1 file for the configuration setting

Now create the mailing list in the destination server and then import the list
of users using

add_members -r  <outputfile> <listname>
example —

1.       /usr/local/cpanel/3rdparty/mailman/bin/add_members -d test fotball_kanligadet.com
2.       /usr/local/cpanel/3rdparty/mailman/bin/add_members -r test fotball_kanligadet.com

and import the configuration of the previous mailing list using
config_list  -i  <outputfile> <listname>

example —

1.        /usr/local/cpanel/3rdparty/mailman/bin/config_list  -i test1 fotball_kanligadet.com

Here <outputfile> is the file to which either of list of members or
configuration has been dumped using list_members or config_list

For all the binaries of mailman list of options can be found using
/usr/local/cpanel/3rdparty/mailman/<binaryname> –help

OpenSSH Installation

Building / Installation
--------------------------

To install OpenSSH with default options:

./configure
make
make install

This will install the OpenSSH binaries in /usr/local/bin, configuration files
in /usr/local/etc, the server in /usr/local/sbin, etc. 

To specify a different
installation prefix, use the --prefix option to configure:

./configure --prefix=/opt
make
make install

Will install OpenSSH in /opt/{bin,etc,lib,sbin}.

We can also override
specific paths, for example:

./configure --prefix=/opt --sysconfdir=/etc/ssh
make
make install

This will install the binaries in /opt/{bin,lib,sbin}, but will place the
configuration files in /etc/ssh.

There are a few other options to the configure script:

--with-audit=[module] enable additional auditing via the specified module.
Currently, drivers for "debug" (additional info via syslog) and "bsm"
(Sun's Basic Security Module) are supported.

--with-pam enables PAM support. If PAM support is compiled in, it must
also be enabled in sshd_config (refer to the UsePAM directive).

--with-prngd-socket=/some/file allows you to enable EGD or PRNGD
support and to specify a PRNGd socket. Use this if your Unix lacks
/dev/random and you don't want to use OpenSSH's builtin entropy
collection support.

--with-prngd-port=portnum allows you to enable EGD or PRNGD support
and to specify a EGD localhost TCP port. Use this if your Unix lacks
/dev/random and you don't want to use OpenSSH's builtin entropy
collection support.

--with-lastlog=FILE will specify the location of the lastlog file.
./configure searches a few locations for lastlog, but may not find
it if lastlog is installed in a different place.

--without-lastlog will disable lastlog support entirely.

--with-osfsia, --without-osfsia will enable or disable OSF1's Security
Integration Architecture.  The default for OSF1 machines is enable.

--with-skey=PATH will enable S/Key one time password support. You will
need the S/Key libraries and header files installed for this to work.

--with-tcp-wrappers will enable TCP Wrappers (/etc/hosts.allow|deny)
support.

--with-md5-passwords will enable the use of MD5 passwords. Enable this
if your operating system uses MD5 passwords and the system crypt() does
not support them directly (see the crypt(3/3c) man page). If enabled, the
resulting binary will support both MD5 and traditional crypt passwords.

--with-utmpx enables utmpx support. utmpx support is automatic for
some platforms.

--without-shadow disables shadow password support.

--with-ipaddr-display forces the use of a numeric IP address in the
$DISPLAY environment variable. Some broken systems need this.

--with-default-path=PATH allows you to specify a default $PATH for sessions
started by sshd. This replaces the standard path entirely.

--with-pid-dir=PATH specifies the directory in which the sshd.pid file is
created.

--with-xauth=PATH specifies the location of the xauth binary

--with-ssl-dir=DIR allows you to specify where your OpenSSL libraries
are installed.

--with-ssl-engine enables OpenSSL's (hardware) ENGINE support

--with-4in6 Check for IPv4 in IPv6 mapped addresses and convert them to
real (AF_INET) IPv4 addresses. Works around some quirks on Linux.

--with-opensc=DIR
--with-sectok=DIR allows for OpenSC or sectok smartcard libraries to
be used with OpenSSH.  See 'README.smartcard' for more details.

Configuration
----------------

The runtime configuration files are installed by in ${prefix}/etc or
whatever you specified as your --sysconfdir (/usr/local/etc by default).

The default configuration should be instantly usable, though you should
review it to ensure that it matches your security requirements.

To generate a host key, run "make host-key". Alternately you can do so
manually using the following commands:

    ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N ""
    ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ""
    ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ""

Replacing /etc/ssh with the correct path to the configuration directory.
(${prefix}/etc or whatever you specified with --sysconfdir during
configuration)

TCP Wrappers

In order to secure the service in Linux, we use the concept of TCP Wrappers.

TCP Wrappers Configuration Files

To determine if a client machine is allowed to connect to a service, TCP wrappers reference the following two files, which are commonly referred to as hosts access files:

• /etc/hosts.allow
• /etc/hosts.deny

When a client request is received by a TCP wrapped service, it takes the following basic steps:

1. The service references /etc/hosts.allow. — The TCP wrapped service sequentially parses the /etc/hosts.allow file and applies the first rule specified for that service. If it finds a matching rule, it allows the connection. If not, it moves on to step 2.
2. The service references /etc/hosts.deny. — The TCP wrapped service sequentially parses the /etc/hosts.deny file. If it finds a matching rule is denies the connection. If not, access to the service is granted.

The following are important points to consider when using TCP wrappers to protect network services:

• Because access rules in hosts.allow are applied first, they take precedence over rules specified in hosts.deny. Therefore, if access to a service is allowed in hosts.allow, a rule denying access to that same service in hosts.deny is ignored.
• Since the rules in each file are read from the top down and the first matching rule for a given service is the only one applied, the order of the rules is extremely important.
• If no rules for the service are found in either file, or if neither file exists, access to the service is granted.
• TCP wrapped services do not cache the rules from the hosts access files, so any changes to hosts.allow or hosts.deny take effect immediately without restarting network services.

Expansions

Expansions, when used in conjunction with the spawn and twist directives provide information about the client, server, and processes involved.

Below is a list of supported expansions:

• %a — The client’s IP address.
• %A — The server’s IP address.
• %c — Supplies a variety of client information, such as the username and hostname, or the username and IP address.
• %d — The daemon process name.
• %h — The client’s hostname (or IP address, if the hostname is unavailable).
• %H — The server’s hostname (or IP address, if the hostname is unavailable).
• %n — The client’s hostname. If unavailable, unknown is printed. If the client’s hostname and host address do not match, paranoid is printed.
• %N — The server’s hostname. If unavailable, unknown is printed. If the server’s hostname and host address do not match, paranoid is printed.
• %p — The daemon process ID.
• %s — Various types of server information, such as the daemon process and the host or IP address of the server.
• %u — The client’s username. If unavailable, unknown is printed.

Securing The Compilers in Linux

Why should compilers be disabled ?

When the compiler is disabled, the hacker is not able to compile and make the exploit. This step will prevent “The ability to compile the file in the system”. Most of the hacking guides that is found in the net suggest of compiling the exploit in the system, and seldom a pre-compiled binary is distributed. Thus, either via shell access or daemon exploit or via cgi/php abuse, they will try to get hold of your compiler and compile the exploit. Normally, your users do not need access to the compiler, so it is safe to restrict/disable compilers

How to disable compliers  ?

To disable compilers for users, login as root in the system and give the following command:

cd /usr/bin/
chmod 000 perlcc byacc yacc bcc kgcc cc gcc i386*cc
chmod 000 *c++ *g++
chmod 000 /usr/lib/bcc /usr/lib/bcc/bcc-cc1

if exists,

chmod 000 /usr/i386-glibc21-linux/lib/gcc-lib/i386-redhat-linux/2.96/cc1

That will disable compiler access for all users.
Before upgrading apache or php; or if you need to install a program, enter the following command to enable compiler access for the root user.

chmod 700 /usr/bin/cc
chmod 700 /usr/bin/gcc

On CPanel systems, You need access to the compiler when upgrading apache or installing vps/jsp, apache etc.

after upgrading apache via /scripts/easyapache, disable the compiler again.

chmod 000 /usr/bin/cc
chmod 000 /usr/bin/gcc

It indeed is a matter of preference of individual admins regarding the chmod 700 or chmod 000 of the compilers. It is your system, your decision. The recommended is however to chmod 000.

Mysql Istallation and Configuration In Linux

Link to Download Mysql :

http://www.linuxfromscratch.org/blfs/view/stable/server/mysql.html

Steps To Install :

1. wget http://anduin.linuxfromscratch.org/sources/BLFS/6.3/m/mysql-5.0.41.tar.gz

2. ./configure –prefix=/var/lib/mysql/ –localstatedir=/var/lib/mysql/data/ –disable-maintainer-mode –with-mysqld-user=mysql –libexecdir=/usr/sbin –sysconfdir=/etc –enable-thread-safe-client –enable-local-infile –enable-assembler –with-unix-socket-path=/var/run/mysql/mysql.sock –without-debug –without-bench –without-readline–with-berkeley-db –with-extra-charsets=all

or

./configure –prefix=/usr/local/mysql –localstatedir=/usr/local/mysql/data –disable-maintainer-mode –with-mysqld-user=mysql –enable-large-files-without-debug
3. Sit back and wait for a while while configure does its thing, once the system returns the prompt to you issue the following command;

#make

4.

#make install

5.

MySQL is installed, there are only a couple things left to do to get it working, first we need to create a group for MySQL as follows;

#/usr/sbin/groupadd mysql (enter)

Then we create a user called mysql which belongs to the mysql group;

#/usr/sbin/useradd -g mysql mysql (enter)

Now we install the database files as follows;

#./scripts/mysql_install_db (enter)

Then we make a couple minor ownership changes;

# chown -R root:mysql /usr/local/mysql (enter)

# chown -R mysql:mysql /usr/local/mysql/data (enter)

Last but not least, we use vi to add a line the ld.so.conf file as follows;

#vi /etc/ld.so.conf

And we add the following line;

/usr/local/mysql/lib/mysql

Thats it, MySQL is installed, you can run it by issuing the following command;

#/usr/local/mysql/bin/mysqld_safe –user=mysql &

And as long as we’re here we might as well set a root password for MySQL as follows;

#/usr/local/mysql/bin/mysqladmin -u root password new_password

Where new_password is the password you want to use.

Command Explanations

–libexecdir=/usr/sbin: This switch installs the mysqld daemon and the mysqlmanager program in an appropriate location.

–localstatedir=/srv/mysql: This switch forces MySQL to use /srv/mysql for database files and other variable data.

–enable-thread-safe-client: This switch compiles a thread-safe MySQL client library.

–enable-assembler: This switch allows using assembler versions of some string functions.

–enable-local-infile: This switch enables the “LOAD DATA INFILE” SQL statement.

–with-unix-socket-path=/var/run/mysql: This switch puts the unix-domain socket into the /var/run/mysql directory instead of the default /tmp.

–without-bench: This switch skips building the benchmark suite.

–without-readline: This switch forces the build to use the system copy of readline instead of the bundled copy.

–with-berkeley-db: This switch enables using Berkeley DB tables as a back end.

–with-extra-charsets=all: This switch enables international character sets within the suite.

make testdir=…: This installs the test suite in /tmp/mysql. The test suite is not required, nor does it function properly on an installed version of MySQL, so it is removed in the next step.

ln -v -sf mysql/libmysqlclient{,_r}.so* .: This command makes the MySQL shared libraries available to other packages at run-time.

–with-openssl: This switch adds OpenSSL support to MySQL.

–with-libwrap: This switch adds tcpwrappers support to MySQL.