Chaotic Psyche

PITRA OCT 2010

2010-10-30T10:12:00.008-04:00

Pics from recent visit to McLeodganj

2009-10-27T12:26:00.008-04:00

NAGIOS: THE NETWORK MONITORING TOOL

2008-02-05T14:04:00.006-05:00

Nagios is a powerful, modular network monitoring system that can be used to monitor many network services on remote hosts. The monitoring daemon runs recurrent checks on hosts and services specified using external "plugins" which return status information to Nagios. When problems occur Nagios alerts you via email, instant message, SMS. Current status information, historical logs, and reports can all be accessed via a web browser.

A large number of plug-ins available from the Nagios Library, means you can design its capabilities to your own requirements. Amongst others, Nagios monitors services such as SMTP, POP3, HTTP, PING and resources such as disk and memory usage, log files, processor load and so on and integrates with the external programs to allow monitoring and alerting of server room and device temperature to your own parameters.

Nagios will also allow scheduling so that for instance if you planned network outage you can suppress host and service notifications. Nagios also allows users the flexibility to develop custom host and service checks. All the plug-ins are available for download from the Nagios library. It is also possible to set up a hierarchy of alerts for instance if alerts are not responded to.

In this article we will install Nagios 3.0 on RHEL 4 from source code .Installation has been tested successfully running on other versions of Redhat/fedora Operating system.

1. Nagios Configuration overview:

There are several different configuration files that you're going to need to create or edit before you start monitoring anything. Be patient! Configuring Nagios can take quite a while, especially if you're first-time user. Once you figure out how things work, it'll all be well worth your time. :-)

Main Configuration File

The main configuration file contains a number of directives that affect how the Nagios daemon operates. This config file is read by both the Nagios daemon and the CGIs. This is where you're going to want to get started in your configuration adventures.

Documentation for the main configuration file can be found here.

Resource File(s)

Resource files can be used to store user-defined macros. The main point of having resource files is to use them to store sensitive configuration information (like passwords), without making them available to the CGIs.

You can specify one or more optional resource files by using the resource_file directive in your main configuration file.

Object Definition Files

Object definition files are used to define hosts, services, hostgroups, contacts, contactgroups, commands, etc. This is where you define all the things you want monitor and how you want to monitor them.

You can specify one or more object definition files by using the cfg_file and/or cfg_dir directives in your main configuration file.

CGI Configuration File

The CGI configuration file contains a number of directives that affect the operation of the CGIs. It also contains a reference the main configuration file, so the CGIs know how you've configured Nagios and where your object definitions are stored.

Documentation for the CGI configuration file can be found here.

Figure below shows pictorial overview of Nagios Configuration

Here we will configure Nagios with NRPE checks.

INSTALLATION:

Pre-requisites:

Following are the basic softwares you require on your redhat box before you start installing Nagios.

1. root access to server

2. Apache

3. GCC compiler

4. GD development libraries

Nagios Pre-Configurations:

Perform the following steps as root.

Create a new nagios user account and give it a password.

/usr/sbin/useradd nagios

passwd nagios

Create a new nagcmd group for allowing external commands to be submitted through the web interface. Add both the nagios user and the apache user to the group.

/usr/sbin/groupadd nagcmd

/usr/sbin/usermod -G nagcmd nagios

/usr/sbin/usermod -G nagcmd apache

Download Nagios and plugins from the following links.

wget  \
http://osdn.dl.sourceforge.net/sourceforge
/nagios/nagios-3.0rc2.tar.gz

wget \
http://osdn.dl.sourceforge.net/sourceforge
/nagiosplug/nagios-plugins-1.4.11.tar.gz

Latest versions can be downloaded from Nagios website.

http://www.nagios.org/download/

Compile and install Nagios

tar xzf nagios-3.0rc2.tar.gz

cd nagios-3.0rc2

Run the Nagios configure script, passing the name of the group you created earlier like so:

./configure --with-command-group=nagcmd

Compile the Nagios source code.

make all

Install binaries, init script, sample config files and set permissions on the external command directory.

make install

make install-init

make install-config

make install-commandmode

Do not start nagios yet, as still more configurations are to be done.

Customize the Configuration

Sample configuration files have now been installed in the /usr/local/nagios/etc directory. These sample files should work fine for getting started with Nagios. You'll need to make just one change before you proceed...

Edit the /usr/local/nagios/etc/objects/contacts.cfg config file with your favorite editor and change the email address associated with the nagiosadmin contact definition to the address you'd like to use for receiving alerts.

vi /usr/local/nagios/etc/objects/contacts.cfg

Configuring the Web interface

Install the Nagios web config file in the Apache conf.d directory.

make install-webconf

Create a nagiosadmin account for logging into the Nagios web interface. Remember the password you assign to this account - you'll need it later.

htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

Restart Apache to make the new settings take effect.

service httpd restart

Configure and Install Nagios Plugin

Extract the Nagios plugins source code tarball.

cd ~/downloads

tar xzf nagios-plugins-1.4.11.tar.gz

cd nagios-plugins-1.4.11

Compile and install the plugins.

./configure --with-nagios-user=nagios --with-nagios-group=nagios

make

make install

Start Nagios Service:

Add Nagios to the list of system services and have it automatically start when the system boots.

chkconfig --add nagios

chkconfig nagios on

Verify the sample Nagios configuration files.

/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

If there are no errors, start Nagios.

service nagios start

Login to Web Interface:

You should now be able to access the Nagios web interface at the URL below. You'll be prompted for the username (nagiosadmin) and password you specified earlier.

http://your-server-hostname/nagios/

Click on the "Service Detail" link to see details of what's being monitored on your local machine. It will take a few minutes for Nagios to check all the services associated with your machine, as the checks are spread out over time.

Nagios Installation is completed now.

Next… we will configure the remote machines which we want to put under monitor. Hence mentioned earlier, we will enable those with NRPE.

2. Introduction to NRPE:

The NRPE addon is designed to allow you to execute Nagios plugins on remote Linux/Unix machines. The main reason for doing this is to allow Nagios to monitor "local" resources (like CPU load, memory usage, etc.) on remote machines. Since these public resources are not usually exposed to external machines, an agent like NRPE must be installed on the remote Linux/Unix machines.

The NRPE addon consists of two pieces:

– The check_nrpe plugin, which resides on the local monitoring machine

– The NRPE daemon, which runs on the remote Linux/Unix machine

When Nagios needs to monitor a resource of service from a remote Linux/Unix machine:

– Nagios will execute the check_nrpe plugin and tell it what service needs to be checked

– The check_nrpe plugin contacts the NRPE daemon on the remote host over an (optionally) SSL-protected connection

– The NRPE daemon runs the appropriate Nagios plugin to check the service or resource

– The results from the service check are passed from the NRPE daemon back to the check_nrpe plugin, which

then returns the check results to the Nagios process.

Note: The NRPE daemon requires that Nagios plugins be installed on the remote Linux/Unix host. Without these, the daemon wouldn't be able to monitor anything.

NRPE is an addon that allows you to execute plugins on remote Linux/Unix hosts. This is useful if you need to monitor local resources/attributes like disk usage, CPU load, memory usage, etc. on a remote host. Similar functionality can be accomplished by using the check_by_ssh plugin, although it can impose a higher CPU load on the monitoring machine - especially if you are monitoring hundreds or thousands of hosts.

Here is the figure below to show how NRPE works.

INSTALLATION:

Install NRPE in Nagios Clients:

Enabling Nagios in client machines require two steps

1. Installing NRPE daemon.

2. Install nagios plugin

Configuring and installing nrpe:

useradd nagios

mkdir -p ~/downloads

cd ~/downloads

download nrpe source from following link

wget http://downloads.sourceforge.net/nagios
/nrpe-2.9.tar.gz?modtime=1187025484&big_
mirror=0

download nagios plugin from the following link

wget http://downloads.sourceforge.net
/nagiosplug/nagios-plugins-1.4.10.tar.gz
?modtime=1191032290&big_mirror=0

Install nagios plugins:

tar zxvf nagios-plugins-1.4.10.tar.gz

cd nagios-plugins-1.4.10

./configure

make

make install

nagios plugins are installed now.

Install NRPE daemon:

cd ~/downloads

tar zxvf nrpe-2.9.tar.gz

cd nrpe-2.9

./configure --enable-command-args

make all

make install-plugin

make install-daemon

make install-daemon-config

make install-xinetd

Now append the following line in /etc/services file

echo "nrpe 5666/tcp #nrpe" >> /etc/services

Add nagios server ip in /etc/xinedt.d/nrpe so client can communicate to Nagios server.

perl -pi -e 's/127.0.0.1/127.0.0.1 10.0.2.180/g' /etc/xinetd.d/nrpe

nrpe installation is completed now and client is now enabled with nrpe daemon.

Test the NRPE daemon locally

Its time to see if things are working properly...

Make sure the nrpe daemon is running under xinetd.

netstat -at | grep nrpe

The output out this command should show something like this:

tcp 0 0 *:nrpe *:* LISTEN

If it does, great! If it doesn't, make sure of the following:

– You added the nrpe entry to your /etc/services file

– The only_from directive in the /etc/xinetd.d/nrpe file contains an entry for "127.0.0.1"

– xinetd is installed and started

– Check the system log files for references about xinetd or nrpe and fix any problems that are reported

Next, check to make sure the NRPE daemon is functioning properly. To do this, run the check_nrpe plugin that was installed for testing purposes.

/usr/local/nagios/libexec/check_nrpe -H localhost

You should get a string back that tells you what version of NRPE is installed, like this:

NRPE v2.9

Install NRPE plugin in Nagios Server:

Install nagios plugin:

Create a directory for storing the downloads.

mkdir ~/downloads

cd ~/downloads

Download the source code tarball of the Nagios plugins (visit http://www.nagios.org/download/ for links to the latest versions).

wget http://osdn.dl.sourceforge.net
/sourceforge/nagiosplug/nagios-
plugins-1.4.6.tar.gz

Extract the Nagios plugins source code tarball.

tar xzf nagios-plugins-1.4.6.tar.gz

cd nagios-plugins-1.4.6

Compile and install the plugins.

./configure

make

make install

The permissions on the plugin directory and the plugins will need to be fixed at this point, so run the following commands.

chown nagios.nagios /usr/local/nagios

chown -R nagios.nagios /usr/local/nagios/libexec

Install NRPE daemon:

Download the source code tarball of the NRPE addon (visit http://www.nagios.org/download/ for links to the latest versions).

cd ~/downloads

wget http://downloads.sourceforge.net/nagios
/nrpe-2.9.tar.gz?modtime=1187025484
&big_mirror=0

Extract the NRPE source code tarball.

tar zxvf nrpe-2.9.tar.gz

cd nrpe-2.9

./configure --enable-command-args

make all

make install-plugin

make install-daemon

make install-daemon-config

make install-xinetd

Edit the /etc/xinetd.d/nrpe file and add the IP address of the monitoring server to the only_from directive.

only_from = 127.0.0.1

Add the following entry for the NRPE daemon to the /etc/services file.

nrpe 5666/tcp # NRPE

Restart the xinetd service.

service xinetd restart

Test the NRPE daemon locally

Its time to see if things are working properly...

Make sure the nrpe daemon is running under xinetd.

netstat -at | grep nrpe

The output out this command should show something like this:

tcp 0 0 *:nrpe *:* LISTEN

If it does, great! If it doesn't, make sure of the following:

– You added the nrpe entry to your /etc/services file

– The only_from directive in the /etc/xinetd.d/nrpe file contains an entry for "127.0.0.1"

– xinetd is installed and started

– Check the system log files for references about xinetd or nrpe and fix any problems that are reported

Next, check to make sure the NRPE daemon is functioning properly. To do this, run the check_nrpe plugin that was installed for testing purposes.

/usr/local/nagios/libexec/check_nrpe -H localhost

You should get a string back that tells you what version of NRPE is installed, like this:

NRPE v2.9

Open firewall rules

Make sure that the local firewall on the machine will allow the NRPE daemon to be accessed from remote servers.

To do this, run the following iptables command. Note that the RH-Firewall-1-INPUT chain name is Fedoraspecific, so it will be different on other Linux distributions.

iptables -I RH-Firewall-1-INPUT -p tcp -m tcp –dport 5666 -j ACCEPT

Save the new iptables rule so it will survive machine reboots.

service iptables save

Test communication with the NRPE daemon

Make sure the check_nrpe plugin can talk to the NRPE daemon on the remote host. Replace "10.0.2.160" in the command below with the IP address of the remote host that has NRPE installed.

/usr/local/nagios/libexec/check_nrpe -H 10.0.2.160

You should get a string back that tells you what version of NRPE is installed on the remote host, like this:

NRPE v2.9

If the plugin returns a timeout error, check the following:

– Make sure there isn't a firewall between the remote host and the monitoring server that is blocking communication

– Make sure that the NRPE daemon is installed properly under xinetd

– Make sure the remote host doesn't have local (iptables) firewall rules that prevent the monitoring server from talking to the NRPE daemon

If everything goes fine, you are good to go for adding hosts/devices on your server.

Create a command definition

You'll need to create a command definition in one of your Nagios object configuration files in order to use the check_nrpe plugin. Open the sample commands.cfg file for editing...

vi /usr/local/nagios/etc/commands.cfg

and add the following definition to the file:

define command{

command_name check_nrpe

command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$

}

You are now ready to start adding services that should be monitored on the remote machine to the Nagios configuration...

Create host and service definitions

You'll need to create some object definitions in order to monitor the remote Linux/Unix machine. These definitions can be placed in their own file or added to an already exiting object configuration file.

First, its best practice to create a new template for each different type of host you'll be monitoring. Let's create a new template for linux boxes.

define host{

name linux-box ; Name of this template

use generic-host ; Inherit default values

check_period 24x7

check_interval 5

retry_interval 1

max_check_attempts 10

check_command check-host-alive

notification_period 24x7

notification_interval 30

notification_options d,r

contact_groups admins

}

Notice that the linux-box template definition is inheriting default values from the generic-host template.

Next, define a new host for the remote Linux/Unix box that references the newly created linux-box host template.

define host{

use linux-box ; Inherit default values from a template

host_name remotehost ; The name we're giving to this server

alias Fedora Core 6 ; A longer name for the server

address 10.0.2.160 ; IP address of the server

}

Next, define some services for monitoring the remote Linux/Unix box. These example service definitions will use the sample commands that have been defined in the nrpe.cfg file on the remote host.

The following service will monitor the CPU load on the remote host. The "check_load" argument that is passed to the check_nrpe command definition tells the NRPE daemon to run the "check_load" command as defined in the nrpe.cfg file.

define service{

use generic-service

host_name remotehost

service_description CPU Load

check_command check_nrpe!check_load

}

The following service will monitor the the number of currently logged in users on the remote host.

define service{

use generic-service

host_name remotehost

service_description Current Users

check_command check_nrpe!check_users

}

The following service will monitor the free drive space on /dev/hda1 on the remote host.

define service{

use generic-service

host_name remotehost

service_description /dev/hda1 Free Space

check_command check_nrpe!check_hda1

Those are the basic service definitions for monitoring the remote host. If you would like to add additional services to be monitored, then you need to edit nrpe.cfg file in the client machine, which we will discuss later.

Restart Nagios

At this point you've installed the check_nrpe plugin and addon host and service definitions for monitoring the remote Linux/Unix machine. Now its time to make those changes live...

Verify your Nagios configuration files.

/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

If there are errors, fix them. If everything is fine, restart Nagios.

service nagios restart

That's it! You should see the host and service definitions you created in the Nagios web interface. In a few minutes Nagios should have the current status information for the remote Linux/Unix machine.

Adding custom monitor:

After adding the default monitors you might be interested in adding more monitors through NRPE.

Anytime you want to monitor a new service on a remote host using the NRPE addon, you have to do three things:

1. Add a new command definition to the nrpe.cfg file on the remote host

2. Add a new service definition to your Nagios configuration on the monitoring host

3. Remote machine must be compiled with command-arg option while installing NRPE daemon.

Remote Host Configuration

You can use the check_swap plugin to monitor swap usage on the machine. Assuming you followed the installation instructions in this document, the check_swap plugin should already be installed in /usr/local/nagios/libexec.

Run the check_swap plugin manually and tweak the command line options to specify the desired warning and critical free swap space thresholds. Make sure the full command line returns the expected output you want from the plugin. For this example, let's say you want a critical alert if swap free space is less than 10% and a warning if free space is less than 20%. Here's the command line that would accomplish that:

/usr/local/nagios/libexec/check_swap -w 20% -c 10%

Now that you know the command line that should be execute, open the NRPE configuration file.

vi /usr/local/nagios/etc/nrpe.cfg

Add a new check_swap command definition that uses the command line from above and save the file.

command[check_swap]=/usr/local/nagios/libexec/check_swap -w 20% -c 10%

If you're running the NRPE daemon as a standalone daemon you'll need to restart it. If you're running it under the inetd/xinetd superserver you don't need to do anything more.

Monitoring Host Configuration

On the monitoring host, you need to define a new service for monitoring the swap usage on the remote host. Add the following entry to one of your object configuration files.

define service{

use generic-service

host_name remotehost

service_description Swap Usage

check_command check_nrpe!check_swap

}

Notice that the check commands is passing "check_swap" to the check_nrpe command definition. This will cause the NRPE daemon to run the check_swap command that was defined in the nrpe.cfg file on the remote host in theprevious step.

Next, verify your Nagios configuration files and restart Nagios.

/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

service nagios restart

That's it! You are now monitoring a new service on the remote host using the NRPE addon.

CVS In Linux : LDAP Authentication

2007-11-26T17:46:00.010-05:00

CVS as Central Repository Server

Installation of CVS:

1. Download the latest version of CVS from http://www.cvshome.com.

2. tar -xzvf cvs-1.xx.tar.gz

Decompress and untar the source files. This should create a new directory with a name similar to that of the distribution file containing all the CVS source files.You should briefly review the files “README” and “INSTALL” in the new directory for detailed instructions on configuring and installing CVS.

3. cd cvs-1.xx

Change to the new CVS source directory.

4. ./configure

Configure the CVS source for installation. This creates a “make” file to compile the source and install it.

5. make

Compile the CVS binaries.

6. make install

Install the binaries and documentation on the system.

7. Create user and group for cvs ownership.

groupadd cvs

useradd –g cvs cvs

8.Now, set permissions for CVSROOT directory to “cvs” user and assign appropriate permissions.You must set the permissions on the repository root to be group writable and set the “set gid flag” so that any files that are added to the repository belong to the “cvs” group. This ensures that users belonging to the “cvs” group will have access to these files.

su cvs

chmod -R 770 /usr/local/cvsroot

chmod -R g+s /usr/local/cvsroot

9.service for CVS.Create a file called /etc/xinetd.d/cvspserver containing the following

# default: off

# description: cvspserver

service cvspserver

{

id = cvspserver

socket_type = stream

protocol = tcp

user = root

wait = no

disable = no

server = /usr/bin/cvs

Port = 2401

passenv =

server_args = --allow-root=/usr/local/cvsroot -f pserver

env = HOME=/usr/local/cvsroot

log = /var/log/cvslog

}

10.Now restart xinetd service to start cvs.

11. Setting up authentication scheme for CVS:

Because the client stores and transmits passwords in cleartext (almost—see Password authentication security,for details), a separate cvs password file is generally used, so people don't compromise their regular passwords when they access the repository. This file is $CVSROOT/CVSROOT/passwd (see Intro administrative files).

It uses a colon-separated format, similar to /etc/passwd on Unix systems, except that it has fewer fields:

cvs username, optional password, and an optional system username for cvs to run as if authentication succeeds.

Here is an example passwd file with five entries:

anonymous:

bach:ULtgRLXo7NRxs

spwang:1sOp854gDF3DY

melissa:tGX1fS8sun6rY:pubcvs

qproj:XR4EZcEs0szik:pubcvs

(The passwords are encrypted according to the standard Unix crypt() function, so it is possible to paste in

passwords directly from regular Unix /etc/passwd files.)

The first line in the example will grant access to any cvs client attempting to authenticate as user anonymous,

no matter what password they use, including an empty password. (This is typical for sites granting

anonymous read-only access; for information on how to do the "read-only" part, see Read-only access.)

The second and third lines will grant access to bach and spwang if they supply their respective plaintext

passwords.

The fourth line will grant access to melissa, if she supplies the correct password, but her cvs operations will

actually run on the server side under the system user pubcvs. Thus, there need not be any system user named

melissa, but there must be one named pubcvs.

The fifth line shows that system user identities can be shared: any client who successfully authenticates as

qproj will actually run as pubcvs, just as melissa does. That way you could create a single, shared system user

for each project in your repository, and give each developer their own line in the

$CVSROOT/CVSROOT/passwd file. The cvs username on each line would be different, but the system

username would be the same. The reason to have different cvs usernames is that cvs will log their actions

under those names: when melissa commits a change to a project, the checkin is recorded in the project's

history under the name melissa, not pubcvs. And the reason to have them share a system username is so that

you can arrange permissions in the relevant area of the repository such that only that account has

write-permission there.

If the system-user field is present, all password-authenticated cvs commands run as that user; if no system

user is specified, cvs simply takes the cvs username as the system username and runs commands as that user.

In either case, if there is no such user on the system, then the cvs operation will fail (regardless of whether the client supplied a valid password).

The password and system-user fields can both be omitted (and if the system-user field is omitted, then also

omit the colon that would have separated it from the encrypted password). For example, this would be a valid

$CVSROOT/CVSROOT/passwd file:

anonymous::pubcvs

fish:rKa5jzULzmhOo:kfogel

sussman:1sOp854gDF3DY

When the password field is omitted or empty, then the client's authentication attempt will succeed with any

password, including the empty string. However, the colon after the cvs username is always necessary, even if

the password is empty.

***** Here we will use Fallback mechanism of CVS to authenticate CVS user through ldap server.

cvs can also fall back to use system authentication. When authenticating a password, the server first checks for

the user in the $CVSROOT/CVSROOT/passwd file. If it finds the user, it will use that entry for authentication as

described above. But if it does not find the user, or if the cvs passwd file does not exist, then the server can try

to authenticate the username and password using the operating system's user-lookup routines (this "fallback"

behavior can be disabled by setting SystemAuth=no in the cvs config file, see config).

The default fallback behavior is to look in /etc/passwd for this system user unless your system has PAM

(Pluggable Authentication Modules) and your cvs server executable was configured to use it at compile time

(using ./configure --enable-pam - see the INSTALL file for more). In this case, PAM will be consulted instead.

This means that cvs can be configured to use any password authentication source PAM can be configured to

use (possibilities include a simple UNIX password, NIS, LDAP, and others) in its global configuration file

(usually /etc/pam.conf or possibly /etc/pam.d/cvs). See your PAM documentation for more details on PAM

configuration.

12. We can enable ldap in this machine and make it as a part of ldap server by editing /etc/ldap.conf

(file locations varies with different version) file, as as this server becomes ldap client.

13. After making this as ldap client, use the fall back mechanism to authenticate ldap user to use CVS server.

Some Highlights on Squid as proxy server......

2007-09-04T10:13:00.000-04:00

At the starting of last year I got a project assigned to me, to work on Squid(Version 2.5.STABLE12) and implement it for my company Globallogic.Although I already completed that project in a week or so, but around last week I thouhgt I should use some space of blogger.com to pen it down, as I have a great quality to forget the things easily.alright.. lets come to the point, I was advised to implement Squid in transparent mode and integrate some Ad blocker with it.Initally I thought implementing squid in transparent mode would be the toughest thing in this project, then I realized, integrating squid with Iptables would be ideal solution.
Iptables can be integrated with squid, so when any http request comes from clients to firewall(running iptables), will be redirected to squid. Squid then process those requests and decides what to do by looking into the acls applied in squids configuration file (generaly squid.conf).
Iptables should be configured to allow request coming to squid (default port 3128) in its INPUT chain...

$IPTABLES -A INPUT -p tcp -s 172.16.0.0/16 --dport 3128 -j ACCEPT \
-m comment --comment "NULL:NEVER:Transparent Proxy Connection from Project VLAN"
$IPTABLES -A INPUT -p tcp -s 192.168.0.0/21 --dport 3128 -j ACCEPT \
-m comment --comment "NULL:NEVER:Transparent Proxy Connection from VLAN 1"
$IPTABLES -A INPUT -p tcp -s 192.168.75.0/24 --dport 3128 -j ACCEPT \
-m comment --comment "NULL:NEVER:Transparent Proxy Connection from VLAN 2"
$IPTABLES -A INPUT -p tcp -s 10.10.75.0/24 --dport 3128 -j ACCEPT \
-m comment --comment "NULL:NEVER:Transparent Proxy Connection from VLAN 3"

Then In the PREROUTING Section I added the redirection rule...

$IPTABLES -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128 \
-m comment --comment "N:STATIC_CORP:NULL:NULL:NEVER:IT:Rule for HTTP Proxy"

Squid Configuration file(squid.conf) itself , really explain aboute its usage etc....

Well lets have a look at the acls I have implemented in my company and what actually those acl does....

we have multiple Vlans in my network, so though it would be better idea to put allow acces according to Vlans/Subnets.

####Allow Squid To listen on port 3128#####
http_port 3128

#######Acl for squid not to cache sites####
acl cacheblock dstdomain .com
no_cache deny cacheblock

#cache_dir ufs /var/spool/squid 100 16 256
cache_dir null /dev/null

#cache_access_log /var/log/squid/access.log
cache_access_log /dev/null

cache_log /var/log/squid/cache.log
#cache_log /dev/null

#############Vlan Based Acl to allow HTTP access#####
acl indus src 192.168.0.0/21
acl indus src 172.16.0.0/16
acl indus src 10.10.75.0/24
acl indus src 192.168.75.0/24
acl indus src 192.168.30.0/24
acl indus src 192.168.20.0/24
acl indus src 192.168.40.0/24

######## Globallogic Acls #########

#########Rules On Request#############
acl it25494 dstdomain "/etc/squid/it25494.txt"
acl apps src 172.16.14.40/32
acl apps src 172.16.14.21/32
acl apps src 172.16.14.31/32
acl apps src 172.16.14.12/32
acl apps src 172.16.45.138/32
http_access allow apps it25494

#############Rules For HR ############
acl hrrules dstdomain "/etc/squid/hrsites.txt"
acl hr src 172.16.11.0/24
#acl hr src 172.16.45.118/32
acl hr src 172.16.5.0/24
http_access allow hr hrrules

#############Rules For IT ###############
acl ITrules dstdomain "/etc/squid/itsites.txt"
acl IT src 172.16.4.0/24
http_access allow IT ITrules

##########Rules For Managemanet Team ################
acl ManageMent dstdomain "/etc/squid/management.txt"
acl Manage src 172.16.5.0/24
acl Manage src 172.16.42.106/32
http_access allow Manage ManageMent

####Rules For IT-25499---To be removed on 27-08-07 ####
acl kaboodlenetwork dstdomain "/etc/squid/kaboodle.txt"
acl kaboodle src 172.16.42.0/24
http_access allow kaboodle kaboodlenetwork

#########Rules To Block Free Web Proxies ##########
acl webproxy dstdom_regex -i proxy.*\.com$ proxy.*\.ph$ proxy.*\.net$ proxy.*\.org$ proxy.*\.php$ proxy.*\.cgi$ proxy.*\.ru$ orkut.*\.com$ images.orkut.*\.com$ images3.orkut.*\.com$ kproxy.*\.com$
acl WorkingHours time D 10:00-20:00
http_access deny WorkingHours webproxy

#########Rule to block anonymous proxy########
acl webproxy1 dstdom_regex -i anonymouse.*\.com$ anonymouse.*\.ph$ anonymouse.*\.net$ anonymouse.*\.org$
acl WorkingHours time D 10:00-20:00
http_access deny WorkingHours webproxy1

acl webproxy2 dstdom_regex -i proxy.*$
acl WorkingHours time D 10:00-20:00
http_access deny WorkingHours webproxy2

#######Rules To Block Personal Interest Sites ######
acl blocked_sites url_regex "/etc/squid/badsites.txt"
acl WorkingHours time D 10:00-20:00
http_access deny WorkingHours blocked_sites

#######Rules To Block Personal Interest Sites1 #######
acl baddst dstdomain "/etc/squid/baddst.txt"
acl WorkingHours time D 10:00-20:00
http_access deny WorkingHours baddst

###Rules To Block Streaming Video ###############
acl streaming rep_mime_type ^video/x-ms-asf ^video/x-ms-sf ^audio/mpeg ^audio/x-mpeg ^audio/x-pn-realaudio ^application/x-mms-framed ^application/vnd.ms.wms-hdr.asfv1
acl block_stream urlpath_regex \.(ra?m|mpeg|mpg|mov|m3u|pls|ivf|asf|asx|avi|wax|wma|wmv|wvx|wmp|wmx|m1v|mp2|mp3|mpa|mpe|mpv2)($|\?)
acl block_stream urlpath_regex \.(ra?m|mpeg|mpg|mov|m3u|pls|ivf|asf|asx|avi|wax|wma|wmv|wvx|wmp|wmx|m1v|mp2|mp3|mpa|mpe|mpv2)($|\?)
http_reply_access deny WorkingHours block_stream
http_reply_access deny WorkingHours streaming

#######Rule To Block Music Download ############

acl download urlpath_regex \.mp3
http_access deny WorkingHours download

#########Restrict File Upload Limit Up To 5 Mb######
acl UPLIMIT req_header Content-Length [5-9][0-9]{6,}
#acl UPLIMIT req_header Content-Length [5-9][0-9]{5,}
acl UPMETH method post
http_access deny indus UPMETH UPLIMIT

#########Restrict download for all to 35 mb #######
reply_body_max_size 35000000 allow all

##########Rules To Allow Internet For Globallogic ###########

http_access allow indus

####And finally deny all other access to this proxy#####
http_access allow localhost
http_access deny all

####Set filedesciptors#####
max_filedesc 4096

####Rule to close idle connections#####
client_persistent_connections off
server_persistent_connections off

#########AD BLOCKING RULE FOR INTERNET###########
redirect_program /etc/squid/adzap/scripts/wrapzap

####Limit child process numbers######
redirect_children 100

##Transparent proxy Rules (not in use after squid 2.5)####

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

####Allowing WEBDAV extention to allow OWA,SVN ###

extension_methods SEARCH PROPFIND PROPPATCH MKCOL MOVE BMOVE DELETE BDELETE REPORT MERGE MKACTIVITY CHECKOUT

Reset Mysql Password

2007-06-14T02:36:00.000-04:00

Following steps can be used to reset MySQL root password sometimes

1. Stop MySQL servive

[root@RITESH-LT ~]# /etc/init.d/mysqld stop
Stopping MySQL: [ OK ]

2. start MySQL service without pw

[root@RITESH-LT ~]# mysqld_safe --skip-grant-tables &
[1] 4876
[root@RITESH-LT ~]# Starting mysqld daemon with databases from /var/lib/mysql

[root@RITESH-LT ~]#

3. Connect MySQL server using client

[root@RITESH-LT ~]# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.0.27

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql>

4.Set new password for MySQL server

mysql> use mysql;
mysql> update user set password=PASSWORD("NEW-ROOT-PASSWORD") where User='root';
mysql> flush privileges;
mysql> quit

5. stop MySQL server

[root@RITESH-LT ~]# /etc/init.d/mysqld stop
STOPPING server from pid file /var/run/mysqld/mysqld.pid
070614 12:25:51 mysqld ended

Stopping MySQL: [ OK ]
[1]+ Done mysqld_safe --skip-grant-tables
[root@RITESH-LT ~]#

6.Start mysql server and test it now

Stopping MySQL: [ OK ]
[1]+ Done mysqld_safe --skip-grant-tables
[root@RITESH-LT ~]# /etc/init.d/mysqld start
Starting MySQL: [ OK ]
[root@RITESH-LT ~]# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 5 to server version: 5.0.27

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql>
mysql>
mysql>

** The command given below also works in most unix/Linux systems systems ....check it out .....

cat /root/.mysql_history | more

happy mysqling ......

Chrooted sftp in Linux

2007-05-25T03:39:00.000-04:00

This was out of urgent requirement that I had to configure and deploy sftp in my organization.The sftp file transfer program,which comes with OpenSSH server,provide the functionality of FTP but in encrypted manner.
configuring sftp server require a chrooted environment, which in turn put the system in maximum security zone.OpenSSH program needs to be patched with chroot patch in order to make it successful.

Following Steps can be performed on a Linux box (successfully implemented on Fedora 6).

1. Installing OpenSSH with chrootssh Patch.

Download latest OpenSSH from ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/ , and the chrootssh patch from http://chrootssh.sourceforge.net/download/ . Then untar the openssh sources and apply the patch.

[root@RITESH-LT ritesh.majumdar]# tar zxvf openssh-4.5p1.tar.gz
[root@RITESH-LT ritesh.majumdar]# cd openssh-4.5p1
[root@RITESH-LT openssh-4.5p1]# patch -p1 < /home/ritesh.majumdar/osshChroot-4.5p1.diff
patching file session.c

The message above shows that it has been patched up successfully.
[root@RITESH-LT openssh-4.5p1]# ./configure --with-md5-password
[root@RITESH-LT openssh-4.5p1]# make
[root@RITESH-LT openssh-4.5p1]# make install
Now, Stop old sshd and start the new one. In my case, it was the default location, where Red Hat installs it. In order to keep the service script working, either change the path to sshd in your sshd rc script,(/etc/init.d/sshd) or can create a link to new sshd.

[root@RITESH-LT ritesh.majumdar]# mv /usr/sbin/sshd /usr/sbin/sshd~
[root@RITESH-LT ritesh.majumdar]# ln -s /usr/local/sbin/sshd /usr/sbin/sshd
[root@RITESH-LT ritesh.majumdar]# service sshd stop
[root@RITESH-LT ritesh.majumdar]# service sshd start

Now check If ssh is working fine , by connecting from some remote machine.if SSH is successful then move to next section.

2. Building CHROOT environment (so called Jail).

The chroot environment must have all utilities to perform sftp.those includes libraries, a home directory and a few device files.this will restrict user to limimed access and commands. Steps given below can followed to create Chroot Jail.

[root@RITESH-LT ritesh.majumdar]# mkdir /SFTP
[root@RITESH-LT ritesh.majumdar]# cd /SFTP
[root@RITESH-LT SFTP]# mkdir bin dev home lib usr
[root@RITESH-LT SFTP]# cd bin
Now you need to copy the required binaries...

[root@RITESH-LT bin]# cp /bin/bash /bin/cp /bin/ls
/bin/mkdir /bin/mv /bin/rm .
[root@RITESH-LT bin]# cd ../lib
[root@RITESH-LT lib]# ldd ../bin/bash
linux-gate.so.1 => (0x00bc2000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0x061f7000)
libdl.so.2 => /lib/libdl.so.2 (0x00931000)
libc.so.6 => /lib/libc.so.6 (0x0058d000)
/lib/ld-linux.so.2 (0x00570000)
[root@RITESH-LT lib]# cp /lib/libtermcap.so.2 .
[root@RITESH-LT lib]# cp /lib/libdl.so.2 .
[root@RITESH-LT lib]# cp /lib/libc.so.6 .
[root@RITESH-LT lib]#
[root@RITESH-LT lib]# ldd ../bin/cp
linux-gate.so.1 => (0x004f8000)
libacl.so.1 => /lib/libacl.so.1 (0x00cfc000)
libselinux.so.1 => /lib/libselinux.so.1 (0x00913000)
libc.so.6 => /lib/libc.so.6 (0x0058d000)
libattr.so.1 => /lib/libattr.so.1 (0x00df0000)
libdl.so.2 => /lib/libdl.so.2 (0x00931000)
libsepol.so.1 => /lib/libsepol.so.1 (0x00843000)
/lib/ld-linux.so.2 (0x00570000)
[root@RITESH-LT lib]#

you have to follow above steps of copying the libraries into lib directory in order to create create the structure of root directory.
Now copy the libraries of sftp.

[root@RITESH-LT SFTP]# cd usr
[root@RITESH-LT usr]# mkdir lib
[root@RITESH-LT usr]# mkdir -p local/libexec
[root@RITESH-LT usr]# cp /usr/local/libexec/sftp-server local/libexec/
[root@RITESH-LT usr]# ldd local/libexec/sftp-server
linux-gate.so.1 => (0x00ab1000)
libutil.so.1 => /lib/libutil.so.1 (0x00544000)
libz.so.1 => /usr/lib/libz.so.1 (0x00937000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00815000)
libcrypto.so.6 => /lib/libcrypto.so.6 (0x05d09000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x06cf1000)
libc.so.6 => /lib/libc.so.6 (0x0058d000)
libdl.so.2 => /lib/libdl.so.2 (0x00931000)
/lib/ld-linux.so.2 (0x00570000)
[root@RITESH-LT usr]# cp /lib/libutil.so.1 ../lib/
[root@RITESH-LT usr]# cp /usr/lib/libz.so.1 ../lib/

and so on ....

after copying the libraries, sftp should work fine.Then create few device files, dev/null and /dev/zero.

[root@RITESH-LT usr]# cd ../dev
[root@RITESH-LT dev]# ls -l /dev/null /dev/zero
crw-rw-rw- 1 root root 1, 3 May 25 11:08 /dev/null
crw-rw-rw- 1 root root 1, 5 May 25 11:08 /dev/zero
[root@RITESH-LT dev]# mknod null c 1 3
[root@RITESH-LT dev]# mknod zero c 1 5
[root@RITESH-LT dev]# ls -l
total 0
crw-r--r-- 1 root root 1, 3 May 23 11:59 null
crw-r--r-- 1 root root 1, 5 May 23 11:59 zero

Now lets check if Chroot works.

[root@RITESH-LT dev]# chroot /SFTP /bin/bash
bash-3.1# pwd
/
bash-3.1# ls
bin dev home lib usr
bash-3.1#

Chroot is working successfully now.But here you can see the limited functionality.

3. Setting up users for SFTP ...

Let's add a user whose home directory is chrooted and test the chroot functionality of ssh.

[root@RITESH-LT SFTP]# useradd -d /SFTP/./home/usr1 usr1
[root@RITESH-LT SFTP]#passwd usr1
Changing password for user usr1.
New password:
Retype new password:
passwd: all authentication tokens updated successfully
[root@RITESH-LT SFTP]# ssh ritesh@192.168.0.45
The authenticity of host '192.168.0.45 (192.168.0.45)' can't be established.
RSA key fingerprint is ee:12:1f:8b:9c:dd:09:27:bb:a7:40:0c:d2:63:eb:c8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.45' (RSA) to the list of known hosts.
ritesh@192.168.0.45's password:
Last login: Wed May 23 11:54:47 2007 from 172.16.4.148
[ritesh@ritesh ~]$ ssh usr1@RITESH-LT
usr1@RITESH-LT's password:
bash-3.1$ pwd
/home/usr1
bash-3.1$ cd ../..
bash-3.1$ ls
bin dev home lib usr

Now, we are in our jail. But we are going to put in some more restrictions:

We are going to lock down usr1's shell , so only sftp is allowed.We are not allowing interactive logins.The easiest way to dothis is to use sftp-server as the shell. It's a little ugly, but it works.

Now finally we will do SFTP ...
[ritesh@ritesh ~]$ sftp usr1@RITESH-LT
Connecting to RITESH-LT...
usr1@RITESH-LT's password:
sftp>
sftp> pwd
Remote working directory: /home/usr1

Now you can proceed uploading/downloading files...

The ugly part (only for ssh restrictions) is that the session just hangs until interrupted when interactive login is attempted. You can always write a wrapper, but remember it must work within your chroot environment.

Sftp with Chroot is implemented sucessfully.