Thursday, June 19, 2014

Nagios Core : Monitoring Windows Machines

Overview
Monitoring a Windows Machine Monitoring private services or attributes of a Windows machine requires that you install an agent on it. This agent acts as a proxy between the Nagios plugin that does the monitoring and the actual service or attribute of the Windows machine. Without installing an agent on the Windows box, Nagios would be unable to monitor private services or attributes of the Windows box.
For this example, we will be installing the NSClient++ addon on the Windows machine and using the check_nt plugin to communicate with the NSClient++ addon. The check_nt plugin should already be installed on the Nagios server if you followed the quickstart guide.
Other Windows agents (like NC_Net) could be used instead of NSClient++ if you wish - provided you change command and service definitions, etc. a bit. For the sake of simplicity I will only cover using the NSClient++ addon in these instructions.
Steps
There are several steps you'll need to follow in order to monitor a new Windows machine. They are:
  1. Perform first-time prerequisites
  2. Install a monitoring agent on the Windows machine
  3. Create new host and service definitions for monitoring the Windows machine
  4. Restart the Nagios daemon
What's Already Done For You
To make your life a bit easier, a few configuration tasks have already been done for you:
  • A check_nt command definition has been added to the commands.cfg file. This allows you to use the check_nt plugin to monitor Window services.
  • A Windows server host template (called windows-server) has already been created in the templates.cfg file. This allows you to add new Windows host definitions in a simple manner.
The above-mentioned config files can be found in the /usr/local/nagios/etc/objects/ directory. You can modify the definitions in these and other definitions to suit your needs better if you'd like. However, I'd recommend waiting until you're more familiar with configuring Nagios before doing so. For the time being, just follow the directions outlined below and you'll be monitoring your Windows boxes in no time.
Prerequisites
The first time you configure Nagios to monitor a Windows machine, you'll need to do a bit of extra work. Remember, you only need to do this for the *first* Windows machine you monitor.
Edit the main Nagios config file.
vi /usr/local/nagios/etc/nagios.cfg

Remove the leading pound (#) sign from the following line in the main configuration file:
#cfg_file=/usr/local/nagios/etc/objects/windows.cfg

Save the file and exit.
What did you just do? You told Nagios to look to the /usr/local/nagios/etc/objects/windows.cfg to find additional object definitions. That's where you'll be adding Windows host and service definitions. That configuration file already contains some sample host, hostgroup, and service definitions. For the *first* Windows machine you monitor, you can simply modify the sample host and service definitions in that file, rather than creating new ones.
Installing the Windows Agent
Before you can begin monitoring private services and attributes of Windows machines, you'll need to install an agent on those machines. I recommend using the NSClient++ addon, which can be found at http://sourceforge.net/projects/nscplus. These instructions will take you through a basic installation of the NSClient++ addon, as well as the configuration of Nagios for monitoring the Windows machine.
1. Download the latest stable version of the NSClient++ addon from http://sourceforge.net/projects/nscplus
2. Unzip the NSClient++ files into a new C:\NSClient++ directory
3. Open a command prompt and change to the C:\NSClient++ directory
4. Register the NSClient++ system service with the following command:
 nsclient++ /install

5. Install the NSClient++ systray with the following command ('SysTray' is case-sensitive):
 nsclient++ SysTray

6. Open the services manager and make sure the NSClientpp service is allowed to interact with the desktop (see the 'Log On' tab of the services manager). If it isn't already allowed to interact with the desktop, check the box to allow it to.
NSClientpp
7. Edit the NSC.INI file (located in the C:\NSClient++ directory) and make the following changes:
  • Uncomment all the modules listed in the [modules] section, except for CheckWMI.dll and RemoteConfiguration.dll
  • Optionally require a password for clients by changing the 'password' option in the [Settings] section.
  • Uncomment the 'allowed_hosts' option in the [Settings] section. Add the IP address of the Nagios server to this line, or leave it blank to allow all hosts to connect.
  • Make sure the 'port' option in the [NSClient] section is uncommented and set to '12489' (the default port).
8. Start the NSClient++ service with the following command:
 nsclient++ /start

9. If installed properly, a new icon should appear in your system tray. It will be a yellow circle with a black 'M' inside.
10. Success! The Windows server can now be added to the Nagios monitoring configuration...
Configuring Nagios
Now it's time to define some object definitions in your Nagios configuration files in order to monitor the new Windows machine.
Open the windows.cfg file for editing.
vi /usr/local/nagios/etc/objects/windows.cfg

Add a new host definition for the Windows machine that you're going to monitor. If this is the *first* Windows machine you're monitoring, you can simply modify the sample host definition in windows.cfg. Change the host_name, alias, and address fields to appropriate values for the Windows box.
define host{

 use  windows-server ; Inherit default values from a Windows server template (make sure you keep this line!)

 host_name  winserver

 alias  My Windows Server

 address  192.168.1.2

 }

Good. Now you can add some service definitions (to the same configuration file) in order to tell Nagios to monitor different aspects of the Windows machine. If this is the *first* Windows machine you're monitoring, you can simply modify the sample service definitions in windows.cfg.
Note Note: Replace "winserver" in the example definitions below with the name you specified in the host_name directive of the host definition you just added.
Add the following service definition to monitor the version of the NSClient++ addon that is running on the Windows server. This is useful when it comes time to upgrade your Windows servers to a newer version of the addon, as you'll be able to tell which Windows machines still need to be upgraded to the latest version of NSClient++.
define service{

 use   generic-service

 host_name   winserver

 service_description NSClient++ Version

 check_command  check_nt!CLIENTVERSION

 }

Add the following service definition to monitor the uptime of the Windows server.
define service{

 use   generic-service

 host_name   winserver

 service_description Uptime

 check_command  check_nt!UPTIME

 }

Add the following service definition to monitor the CPU utilization on the Windows server and generate a CRITICAL alert if the 5-minute CPU load is 90% or more or a WARNING alert if the 5-minute load is 80% or greater.
define service{

 use   generic-service

 host_name   winserver

 service_description CPU Load

 check_command  check_nt!CPULOAD!-l 5,80,90

 }

Add the following service definition to monitor memory usage on the Windows server and generate a CRITICAL alert if memory usage is 90% or more or a WARNING alert if memory usage is 80% or greater.
define service{

 use   generic-service

 host_name   winserver

 service_description Memory Usage

 check_command  check_nt!MEMUSE!-w 80 -c 90

 }

Add the following service definition to monitor usage of the C:\ drive on the Windows server and generate a CRITICAL alert if disk usage is 90% or more or a WARNING alert if disk usage is 80% or greater.
define service{

 use   generic-service

 host_name   winserver

 service_description C:\ Drive Space

 check_command  check_nt!USEDDISKSPACE!-l c -w 80 -c 90

 }

Add the following service definition to monitor the W3SVC service state on the Windows machine and generate a CRITICAL alert if the service is stopped.
define service{

 use   generic-service

 host_name   winserver

 service_description W3SVC

 check_command  check_nt!SERVICESTATE!-d SHOWALL -l W3SVC

 }

Add the following service definition to monitor the Explorer.exe process on the Windows machine and generate a CRITICAL alert if the process is not running.
define service{

 use   generic-service

 host_name   winserver

 service_description Explorer

 check_command  check_nt!PROCSTATE!-d SHOWALL -l Explorer.exe

 }

That's it for now. You've added some basic services that should be monitored on the Windows box. Save the configuration file.
Password Protection
If you specified a password in the NSClient++ configuration file on the Windows machine, you'll need to modify the check_nt command definition to include the password. Open the commands.cfg file for editing.
vi /usr/local/nagios/etc/objects/commands.cfg

Change the definition of the check_nt command to include the "-s <PASSWORD>" argument (where PASSWORD is the password you specified on the Windows machine) like this:
define command{

 command_name check_nt

 command_line $USER1$/check_nt -H $HOSTADDRESS$ -p 12489 -s PASSWORD -v $ARG1$ $ARG2$

 }

Save the file.
Restarting Nagios

Friday, June 13, 2014

Bind : Reverse DNS

Used Environment : RHEL 6

Steps followed :

1. Add following lines in /etc/named.conf :

---------
zone "0.168.192.in-addr.arpa" IN {
type master;
file "0.168.192.in-addr.arpa";
allow-update { none; };
};
---------

2. Create zone for this reverse record :

-------------------
$cat /var/named/0.168.192.in-addr.arpa

$TTL 600
@ IN SOA ns1.example.com. host.example.com. (
2014063001 ;Serial Number
86400 ;refresh
7200 ;retry
3600000 ;expire
86400 ;minimum

)

0.168.192.in-addr.arpa. IN NS ns1.example.com.
0.168.192.in-addr.arpa. IN NS ns2.example.com.
201 IN PTR example.com.
------------------

Testing :

-----------------------
$dig -x 192.168.0.201 @localhost

; <<>> DiG 9.7.3-P3-RedHat-9.7.3-8.P3.el6_2.2 <<>> -x 192.168.0.201 @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17992
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;201.0.168.192.in-addr.arpa. IN PTR

;; ANSWER SECTION:
201.0.168.192.in-addr.arpa. 600 IN PTR example.com.

;; AUTHORITY SECTION:
0.168.192.in-addr.arpa. 600 IN NS ns2.example.com.
0.168.192.in-addr.arpa. 600 IN NS ns1.example.com.

;; ADDITIONAL SECTION:
ns1.example.com. 86400 IN A 192.168.0.201
ns2.example.com. 86400 IN A 192.168.40.34

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Feb 22 15:00:32 2012
;; MSG SIZE rcvd: 137
---------------------------

DB of the zone example.com looks like :

--------------
$cat example.com
$TTL 24h

;
; zone data file
; comments can appear on any line after a semi-colon
;
example.com. IN SOA ns1.example.com. root.mail.example.com. (
2012013001 ; last updated January 30th,2012, once
24h
2h
4w
4d )

example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
example.com. IN A 192.168.0.201
mail.example.com. IN A 192.168.0.201
ns1.example.com. IN A 192.168.0.201
ns2.example.com. IN A 192.168.40.34
www.example.com. IN CNAME example.com.
wwww.example.com. IN CNAME example.com.
ww.example.com. IN CNAME example.com.
example.com. IN MX 0 mail.example.com.

Sunday, June 8, 2014

Spamassassin on CentOS

Installation

The first thing we will want to do is run an update on our CentOS distribution if we haven’t already.
sudo yum update
Once the distribution has been updated, we will want to install SpamAssassin using yum.
sudo yum install spamassassin
Now that we have installed SpamAssassin onto our mail server we will need to configure the SpamAssassin rules within the local.cf file to set filter preferences.
Each item of email sent to your domain is given a score by SpamAssassin.  This score depends on characteristics of the email like keywords and attachments. As with any anti-spam engine, SpamAssassin will need training to become a more accurate filter to cater to your needs.

Configuration

Let’s take a look at the default configuration for the local.cf file within SpamAssassin.  To do this we will need to open the file and make some changes.  Please use your favoured text editor; in this example we will use nano.
sudo nano /etc/mail/spamassassin/local.cf
We will need to uncomment the following lines and append the score:
required_hits 5.0 report_safe 0 required_score 5 rewrite_header Subject ***SPAM***
To explain what we are doing and why we are doing this, we will need a short run-down on the above lines.
Required_hits: This determines the filter balance; the lower the score the more aggressive the filter. A setting of 5.0 is generally effective for a small organisation or a single user. Adjust the strictness score to your organization's needs - a large medical organisation might want  to let email items through that are trying to sell pharmaceuticals, so we might increase the level to a more modest 8.0.
Report_safe:  This line determines whether to delete the item or to move the item to the inbox whilst appending a spam notice to the subject line. The levels for this line are set to either a 1 or 0. A score of 1 will delete the spam item, whereas a score of 0 will send the item to the inbox and rewrite the subject line.  For this guide we shall use 0 as the score.
Required_score: This line sets the spam score for all email alllowed through to your domain, with levels of certainty set from 0 to 5. Zero would be classified as a legitimate email item, whereas 5 would be an definite ‘SPAM’ item.  If we set the score to 3 we would catch a lot of unsolicited emails but quite a few false positives would still get through. For our example email server we will use the score of 5, but you can of course set this value according to your preference.
Rewrite_header: This line does exactly what it implies, that is, any message caught as ‘SPAM’ will have the subject line rewritten to include this header. For this guide we will use the default subject header of ***SPAM***.
Now that we have the spam variables set up we will now move on to creating the spamd function.

Spamd Setup

Before we jump in and start configuring spamd, here is a brief understanding of spamd and why it is needed.
Spamd and spamc are two functions that are necessary for SpamAssassin to work correctly. Spamd is the more proactive of the two functions; it lays in wait for incoming requests, acting as a daemon to intercept and process emails.  Once spamd receives a connection it will spawn a spawnc child to read the email item from the network socket. This child will pass the message back to spamd when it reaches an end of file (EOF), which will rewrite the message (if you have SpamAssassin setting the subject header for spam).  This email message will then be passed back to the socket it originally arrived on using the child process it spawned at the start. The child process will then end and your regular mail server will process the message.
In briefer terms: The spamd process and its children intercept all incoming messages and process them before your regular mail server ever sees them.
Because of the nature of spamd we will need to create a unique user and group for it so we can integrate Postfix with SpamAssassin. This can be done using commands in BASH:
sudo groupadd spamd sudo useradd -g spamd -s /bin/false -d /var/log/spamassassin spamd sudo chown spamd:spamd /var/log/spamassassin
Right, so now that we have the SpamAssasin local.cf file configured along with spamd we will need to configure the Postfix master.cf file to use the SpamAssassin scripts and the set scores we have just applied.

Postfix

We now need to access the Postfix master.cf file with a text editor.
sudo nano /etc/postfix/master.cf
We should now change the master.cf file to look as follows:
# ==================================================================== # service type  private unpriv  chroot  wakeup  maxproc command + args #                      (yes)   (yes)     (yes)    (never)   (100) # ==================================================================== smtp        inet   n           -           n          -             -              smtpd -o content_filter=spamassassin
At the bottom of this file we should add the following line:
spamassassin unix - n n - - pipe flags=R user=spamd argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
Before initially starting the SpamAssassin service run sa-update from a cronjob to update the spamd with the latest rules.
sa-update && /etc/init.d/spamassassin reload
We should now start the SpamAssassin service and reload the Postfix service, to do this we can run the following commands:
sudo /etc/init.d/postfix reload sudo /etc/init.d/spamassassin reload
To check the spam service is operating correctly we can try running a test.

The Test

Create an email from an email address and service outside of your domain, e.g. Hotmail or Gmail.  Address the email to an email address on the newly-configured mail server, then within the subject line we can use the following test string:
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
Once this email has been fired off, and if all the settings have been entered correctly, we should be able to see the following message in our inbox:
****SPAM****XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
Success! We have now set up our server to use SpamassAssin to filter our inbound emails!