Patch Release Timing for Red Hat and Microsoft

Both vendors have adopted a policy of releasing patches. Microsoft’s policy groups patches on a monthly cycle, whereas Red Hat bundles “errata” together when possible but often releases security patches as needed.

Specifically, Microsoft’s policy is to release patches on the first calendar Tuesday of every month; although Red Hat states that there is a grouped release of patches there is no indication of any static date or release cycle allowing system administrators to schedule patch management cycles.

Monitoring

MIS need to monitor security mailing lists, review vendor notifications and Web sites, and research specific public Web sites for the release of new patches. Monitoring will include, but not be limited to, the following:
• Scanning network to identify known vulnerabilities.
• Identifying and communicating identified vulnerabilities and/or security breaches to chief information security officer (CISO) and CIO.
• Monitoring CERT/Microsoft/Symantec/cybersecurity, notifications, and Web sites of all vendors that have hardware or software operating on network.
Review and evaluation
Once alerted to a new patch, MIS will download and review the new patch within four hours of its release. MIS will categorize the criticality of the patch according to the following:
• Emergency -- an imminent threat to network
• Critical -- targets a security vulnerability
• Not Critical -- a standard patch release update
• Not applicable environment
Regardless of platform or criticality, all patch releases will follow a defined process for patch deployment that includes assessing the risk, testing, scheduling, installing, and verifying.
Risk assessment and testing
MIS will assess the effect of a patch to the corporate infrastructure prior to its deployment. The department will also assess the affected patch for criticality relevant to each platform (e.g., servers, desktops, printers, etc.).
If MIS categorizes a patch as an Emergency, the department considers it an imminent threat to network / system. Therefore, assumes greater risk by not implementing the patch than waiting to test it before implementing.
Patches deemed Critical or Not Critical will undergo testing for each affected platform before release for implementation. MIS will expedite testing for critical patches. The department must complete validation against all images (e.g., Windows, UNIX, etc.) prior to implementation.
Notification and scheduling
MIS' management must approve the schedule prior to implementation. Regardless of criticality, each patch release requires the creation and approval of a request for technical change (RTC) prior to releasing the patch. CISO will decide when notifying staff is necessary.
Implementation MIS will deploy Emergency patches within eight hours of availability. As Emergency patches pose an imminent threat to the network, the release may proceed testing. In all instances, the department will perform testing (either pre- or post-implementation) and document it for auditing and tracking purposes.
For new network devices, each platform will follow established hardening procedures to ensure the installation of the most recent patches.
Auditing, assessment, and verification
Following the release of all patches, MIS staff will verify the successful installation of the patch and that there have been no adverse effects.
User responsibilities and practices
It is the responsibility of each user -- both individually and within the organization -- to ensure prudent and responsible use of computing and network resources.

A Secure Nagios Server

Nagios is a monitoring software designed to let you know about problems on your hosts and networks quickly. You can configure it to be used on any network. Setting up a Nagios server on any Linux distribution is a very quick process however to make it a secure setup it takes some work. This article will not show you how to install Nagios since there are tons of them out there but it will show you in detail ways to improve your Nagios

Introduction

Nagios is a monitoring software designed to let you know about problems on your hosts and networks quickly. You can configure it to be used on any network. Setting up a Nagios server on any Linux distribution is a very quick process however to make it a secure setup it takes some work. This article will not show you how to install Nagios since there are tons of them out there but it will show you in detail ways to improve your Nagios security.
You may be wondering why should I need to think about securing my Nagios server? Well, think about the amount of information the attacker can get if they compromise it.

All the examples below assumes you are using Ubuntu. However these examples will help any user running a Nagios server to make it more secure since the concepts will still apply.

Web interface

If you installed Nagios with one of the quick start guides out there, chances are that you setup the web interface. Since Nagios uses Apache to display it there are many security options.
Below is an example of apache configuration for a Nagios web interface:


Options ExecCGI
AllowOverride None
Order allow,deny
Allow from all
AuthName "Nagios Access"
AuthType Basic
AuthUserFile /usr/local/nagios/etc/htpasswd.users
Require valid-user


The 'Allow from' option is used to provide access to only a certain IP address and/or network. The above example allows any IP address to access the web interface. The other security options are used for authentication. 'AuthType' defines the type of authentication being used. There are two types you can choose from Basic or Digest. Basic authentication will transmit your passwords and username as clear text. However using Digest the passwords are transmitted as MD5 digests which is more secure then in clear text.

After making some security improvement we get the below.


Options ExecCGI
AllowOverride None
Order allow,deny
Allow from 192.168.4.
AuthName "Nagios Access"
AuthType Digest
AuthDigestFile /usr/local/nagios/etc/htpasswd.users
Require valid-user


Now only computers on the 192.168.4.0 network can have access to the web interface. Also we are now using Digest authentication instead of the insecure method of Basic authentication.

Now we need to add users and passwords to allow accesses to the web interface. To add a new user using digest authentication use the below command:

# htdigest -c /usr/local/nagios/etc/htpasswd.users realm username

Digest is more secure then Basic authentication but the best way keep your username and passwords safe is to use SSL.

Make sure that you restart apache if you make any configuration changes.

# /etc/init.d/apache2 restart

Best Practices
This sections lists some of the best security practices when setting up an Nagios server.

Don't Run Nagios As Root There should be an normal user called nagios. If Nagios is running as root then if Nagios gets compromised then the attacker can do anything they want to your system.
Lock Down The Check Result Directory Make sure that only nagios has read/write access to the check result directory otherwise an attacker can send fake host and service checks. This directory is normal at /usr/local/nagios/var/spool/checkresults
Use Full Paths In Command Definitions When defining commands, make sure to specify the full path and not the relative one to any scripts or binaries you’re executing.
Secure Remote Agents Some example are NRPE, NSClient, and SNMP. Below we will look at steps to secure the NRPE remote agent.


Secure Remote agents
This sections we will look at ways you can make NRPE more secure. This remote agent is used to execute programs on an remote host for doing checks like the load or disk usage. Since we don't want any programs or users being able to execute commands on our remote machines it's important to spend some time to make NRPE more secure.

Since NRPE come with support for TCP wrappers we can define which hosts have access to it.

Example /etc/hosts.allow

nrpe:192.168.1.91

This will allow only 192.168.1.91 to be able to use this remote agent on this host. You should replace this with the IP address of your Nagios client. Note this should be used on both your Nagios server and client.

NRPE should never run as root or any other superusers it should only be run as a nagios user in the group nagios. In /etc/nagios/nrpe.cfg you can check weather or not it's running as nagios.

Example part of /etc/nagios/nrpe.cfg

nrpe_user=nagios
nrpe_group=nagios

Another part of NRPE that can be a security hole is allowing command arguments. We don't want attacks to send malicious arguments that can compromise our system. Some times we need to allow Nagios to send command arguments but if you don't need it to be enable which most times they are not needed then you should definitely disable them.

To disable them edit /etc/nagios/nrpe.cfg and make sure that you have the below line:

dont_blame_nrpe=0

Make user you restart nrpe to if you make any changes to nrpe.cfg. For more information on how to secure NRPE please read the file called SECURITY in the packages source file.

Secure Communication channels
Any time you communicate over a network you should be thinking about how can I make this more secure. This is where SSL is needed.

NRPE allows you to enable it to use SSL but your package must have configured it with the –enable-ssl option. If NRPE is configured to use SSL note, both the client and the server instance must have it enabled to work.

Next we should also configure SSL so that we don't send our web interfaces passwords in clear text.

# openssl genrsa -des3 -out server.3des-key 1024
# openssl rsa -in server.3des-key -out server.key
# openssl req -new -key server.key -x509 -out server.crt -days 365
# chmod 600 server.key
# rm server.3des-key
# mv server.crt /etc/ssl/
# mv server.key /etc/ssl/private/

Now that we have generated our certificate we need to tell Apache to use them.


In your Apache configuration you will need to add the SSLRequireSSL options for example:


SSLRequireSSL
Options ExecCGI
AllowOverride None
Order allow,deny
Allow from 192.168.4.
AuthName "Nagios Access"
AuthType Digest
AuthDigestFile /usr/local/nagios/etc/htpasswd.users
Require valid-user


Remember to restart Apache.

# /etc/init.d/apache2 restart

Where to go from here?

Now you should feel confident that your Nagios server is more secure from attack. The next step is to just install security updates when they are released.

The growth of keyloggers

Enterprise security has traditionally been centered around gateway protection, preventing unauthorized access from the outside and securing access to the Internet from inside the company. The last few years have seen the industry's attention extending to include endpoint security, which shares some of the same security threats as the gateway, but also presents new concerns.

Enforcing endpoint security is made more difficult due to attackers having physical access to the target machines. Beside negligent or disgruntled employees, an organization's computers can be completely accessible to outsiders. For example, bank PCs are often positioned on a teller's desk, with the computer's backside and wiring exposed to customers. Even PCs inside locked offices are accessible to outsiders during off hours.

Employees may also snoop around in corporate data which they shouldn't have access to, such as other employees' e-mails or financial records. Common methods include connecting USB flash drives and copying data or adding network access points (a practice known as ‘bridging,' where new connection points are opened into a previously isolated network). A subtler but more powerful attack entails leaving behind keyboard eavesdropping modules, known as keyloggers.


Keyloggers are software or hardware modules primarily meant to steal passwords and other sensitive inputs as they are typed into a terminal. They have evolved from easy to detect resident programs, to more powerful rootkit-style kernel components, and finally to small hardware plugs, which are undetectable to the target system. Their use as a tool for industrial espionage is described in the Joseph Finder novel "Paranoia" in which an attacker installs a keylogger on the target computer and collects them days or weeks later, with megabytes of sensitive data logged inside their flash memories.

Commercially available keyloggers may plug into USB or PS/2 keyboard ports which look similar to a keyboard adapter and go unnoticed unless the user searches for them. Installing them is extremely simple, requiring the same amount of technical knowledge as plugging in a keyboard. Other form factors allow surreptitiously installing keyloggers on the inside of a keyboard, or inside the body of a laptop.

Keyloggers are hard to detect and lead to embarrassing break-ins and because of these considerations most incidents go unreported. The incidents which do become public show that passwords stolen using keyloggers lead to large-scale attacks with huge losses.

Beside keyboard inputs, keyloggers can target credit card swipes, which usually share the same interfaces as keyboards. Once a magnetic card such as a credit card or an access card is swiped, a keylogger will record that data. A keylogger on a bank PC will obtain passwords entered using access cards and a keylogger installed on a cashier's machine can gather thousands of valid credit card numbers per day. Cybercrime networks are willing to buy these records for hard cash, using them for unattended purchases over the Internet and telephone, or creating replicate credit and access cards. Until commercial organizations harden their requirements to include endpoint security, this threat will remain prevalent. Government and corporate regulation bodies like the Payment Card Industry Security Standards need to address the issue by mandating a higher level of endpoint security.

Once a keylogger is logged in, it can run applications such as an Internet browser or an IM session, or it can run queries on a database. It can even mount itself as a flash drive and copy data from local and network storage to internal memory, or it can install malware, spreading infection the internal network. Finally, the device can wait until the attacker collects it. As flash drive capacities increase every year, attackers can walk away with many gigabytes of sensitive information.


To summarize, keyloggers and other similar devices have not yet become the focus of attention for the security industry, but they have already caused severe security miscues with great costs and strong ramifications in the areas of retail and banking. Any industry which stores sensitive data on corporate networks - and today that's every industry - will eventually be forced to upgrade its infrastructure to defend against attacks on its endpoints.