Information Security, Privacy and Regulatory Compliance - Regulatory Compliance

Nikto with NMAP for Web Server Scanning

nospam@example.com (Keith Pachulski) — Sun, 20 Jun 2010 16:15:00 -0400

Nikto is a lightweight, portable, PERL based web application scanner. The only requirements for Nikto to run are PERL and NET SSLeay, NET SSLeay is only needed if you plan on auditing SSL based applications. Nikto requires you to input the targets from the command line, because of this we’ll also be using NMAP with the http-headers NSE scripts to identify and gather basic information on HTTP based services for this overview. Nikto, as a standalone package, does not include the ability to perform port/service scanning. As such, NMAP will additionally need to be installed on the system performing the audits. NMAP is not a requirement; it just makes things easier…

Required Software/Packages:

Nikto

http://cirt.net/nikto2

Net SSLeay

http://search.cpan.org/CPAN/authors/id/S/SA/SAMPO/Net_SSLeay.pm-1.25.tar.gz

NMAP

http://www.nmap.org/download

NMAP HTTP-Headers NSE

http://nmap.org/svn/scripts/http-headers.nse

NMAP with NSE to discover potential Web Applications

This section assumes you are running at minimum nmap 5.21, nmap 5.2x is required for the application awareness checking of nmap. To begin, we will be probing the targets systems to discover all services and identify what is running on them using the service aware nmap config, but also using the http-headers nse to gather interesting information about the system(s) with potential web applications. From the nmap output, we’ll be targeting those systems running some type of web application. Side Note: for those services that show up as unknown, be sure to manually probe them later. nmap --script http-headers.nse -p 1-65535 –A

I’m targeting all ports here via nmap as some people still believe security through obscurity is a valid mechanism, don’t overlook anything. There are several other options for service level probing you may want to investigate, but for this I’m doing the quick and dirty.

Once nmap has completed its run, it will spit out everything it found to the console, from that list we will target the services to be audited with Nikto.

$ nmap --script http-headers.nse 192.168.0.1 -A

Starting Nmap 5.21 ( http://nmap.org )
NSE: Script Scanning completed.
Nmap scan report for 192.168.0.1
Host is up (0.0012s latency).
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.2.3 ((CentOS) mod_python/3.2.8 Python/2.4.3 mod_ssl/2.2.3 OpenSSL/0.9.8e-fips-rhel5 mod_perl/2.0.4 Perl/v5.8.8)
443/tcp open ssl/http Apache httpd 2.2.3 ((CentOS) mod_python/3.2.8 Python/2.4.3 mod_ssl/2.2.3 OpenSSL/0.9.8e-fips-rhel5 mod_perl/2.0.4 Perl/v5.8.8)

Installing Nikto and targeting the discovered web applications

Obtain the Nikto package and the NET SSLeay packages from the following locations:

Install NET SSLeay then untar the nikto package to your home directory, update Nikto

./nikto.pl –update

From the nessus NSE scan above, we found the following services in operation that are of interest:

80/tcp open http Apache httpd 2.2.3
5801/tcp open vnc-http RealVNC 4.0
3000/tcp open http WEBrick httpd 1.3.1
443/tcp open ssl/http Apache httpd 2.2.3

At the command line, we target these web applications specifically with Nikto by using the following type of command:

./nikto –h 'target' -p 80,443,5801,3000 –ssl –output report.html

As Nikto is performing the targeted assessment, any potential issues will be displayed to the console. As the scan is occuring, all results are output to the html file with the details of the scan along with the corresponding OSVDB^[?] identifiers broken down by service port tested.

The export format may additionally be set to either csv or XML as needed: report.csv, report.xml

Executing nmap and passing the results directly to nikto

This is useful when you want/need to check all active web servers in the target subnet(s). The following executes the nmap scan of the target subnet then pipes the discovered hosts to nikto.

nmap 192.168.0.0/24 -oG - | ./nikto.pl -output subnet.html -h -

Closing

Nikto standalone, I wasn't overly thrilled with. But again, in a pinch it is a nice tool to keep in the box. In testing nikto, some scans were needed to be run several times for nikto to actually do what it had been configured to do via the command line. The reporting isn't that clean, still leaves a lot of room for interpretation and understanding of common issues.

Whole Disk Encryption (WDE) – And Comparison of PGP vs TrueCrypt for WDE

nospam@example.com (Keith Pachulski) — Thu, 03 Jun 2010 20:40:37 -0400

Whole Disk Encryption (WDE^[?]) – And Comparison of PGP vs TrueCrypt for WDE

In this day and age there is absolutely no reason for any business with laptops being used for business or personal reasons that contain sensitive information to not be encrypted.

Whole Disk Encryption, also known as Full Disk Encryption, is what it says; it encrypts all information contained on the specified disk or partition. WDE should not however not to be confused with file system encryption. With WDE one key is used to encrypt the entire disk. Should the key become compromised, the entire disk is thereby compromised. For those individuals needing or who are required to transmit sensitive information on their laptops, I would strongly recommend using WDE in conjunction with file system encryption.

File system encryption is often known as folder or file encryption because it was designed, from a high level, to encrypt specific targets within the system whereas WDE deals with the entire disk.

File System encryption examples can be found in a previous blog post on TrueCrypt Containers for examples.

TrueCrypt vs PGP	TrueCrypt	PGP
Cost	Free	$149.00
Encrypt internal, external and removable media	yes	yes
Encrypt all user data, applications, boot sector and swap files	yes	yes
Shred/Wipe Function	no	yes
Encrypt Email	no	option $$
Encrypt IM	no	option $$

TrueCrypt Whole Disk Encryption on Windows - Step by Step

Select Create Volume

Encrypt the system partition or entire system drive

Type of System Encryption - Normal

Area to Encrypt – Encrypt the whole drive

Encryption of the Host Protected Area – If you know there are utilities in the Host Protected Area (HPA) you do not want encrypted, select No – Otherwise encrypted the HPA as well

Number of Operating Systems – Select the appropriate response, typically this will be 1

Encryption Options – Select the Preferred Encryption and hashing Algorithms – for NIST^[?] compliance select AES^[?]

Notes:
Unlike PGP below where you generate your public/private keypair that can be used for other PGP plug-in applications, the keys for TrueCrypt are generated based on the movement of your mouse and are only used for drive encrypt/decrypt functions
If you are overly paranoid, you can select a cascading algorithm here such as AES+TwoFish to increase the strength

Password – enter the password, this will be used to access the system once the entire disk has been encrypted

Rescue Disk – The iso image created must be copied off the system and it is recommended it be burnt to a CD. This will be required if the password is forgotten or any portion of the loader becomes corrupted. Once the image has been burnt, eject and reinsert the CD and click next to allow Truecrypt to verify the image. Once it has completed, it will ask you to reboot, select yes for the encryption Pretest.

At the boot prompt, enter the password you had entered earlier.

Once Windows boots, you'll be presented with the Pretest screen and the option to begin the encryption process, select Encrypt, go for a coke...

The encryption status window will appear, once the disk encryption has completed a notification window will appear.

That’s about all that you need to do.

If for whatever reason you want to permanently decrypt the drive, open the TrueCrypt application, select System then “Permanently decrypt system partition/drive”.

PGP (Pretty Good Privacy) WDE on Windows - Quasi Step by Step

The setup is pretty straightforward and almost identical to the TrueCrypt setup; install the application from the exe. Once it finished open the PGP Desktop application from the system tray and click on PGP Disk then Encrypt Whole Disk.

During the installation you`ll be prompted to create a key pair. These keys will be used for encrypting and decrypting the drive(s). These are also the keys you`ll use if you buy the extra PGP addons such as email. Make sure you use your legitimate email address during creation.

It is recommended you create a recovery disk, same as a above.

Select the disk to encrypt then select the keys you created during installation by selecting Add User Key.

Click Encrypt, go for a coke..

By default PGP uses AES-256 for encryption and SHA-1 for hashing. As far as I am aware there is no possible customization to either the encryption or hashing algorithms.

Soap Box

While I am a huge fan of TrueCrypt for only WDE or file system encryption, it does not scale well in large deployments like PGP offers with the Universal Server. With the PGP Universal Server, enrollments and encryption policies can be controlled and deployed from a central server. The PGP server can generate "reports" from the server on demand. I put the quotes around the word report because the export is simply a csv export of the entire database structure, which is severely lacking in the ability to perform decent reporting and database maintenance.

Seriously though, with whatever solution you choose..choose one. The 30 minutes of your time it takes to install and configure the software will pale in comparison to being immortalized on the Internet as yet another failure to protect sensitive information...

Vulnerability & Patch Management - My Two Cents and recommendations

nospam@example.com (Keith Pachulski) — Sat, 29 May 2010 11:00:57 -0400

I’m on a vulnerability^[?] management and patch management tangent. No real reason why other than I was listening to a podcast and a comment irked me so I decided to write this up. This is a high level overview of my recommendations on implementing a program. As always if you have any questions on this feel free to ping me.

Identification of Assets

For whatever reason, I find this to be one portion of any vulnerability management process that continues to fail whether it is private or public sector. Network and Systems people love to turn up new technology but they typically do not want to generate any documentation on what the system is, who is responsible for it, what applications are installed onto the system and if some other person is responsible for those installed applications. This is a critical step to being capable of performing any type of vulnerability management.

Vulnerability^[?] Identification & Tracking

Vulnerability identification can be discovered from many sources including risk assessments, vendor notifications, open sources of information (exploit-db, securitytracker, packetstorm, etc) or vulnerability assessments through automated tools (Nexpose) or manual assessments (Penetration Testing, Risk Assessments).

Vulnerability, in itself, is a broad term. Vulnerabilities can be initially discovered pre-production through system or application configurations such as running an outdated version of MySQL or allowing connections from public facing systems to protected internal resources. These types of pre-production vulnerabilities must be documented in the Identification of Assets phase.

Vulnerabilities discovery through commercial sources or clearing houses are typically assigned a criticality grade or score (CVE^[?], CVSS^[?], Critical, Medium, etc). Those vulnerabilities that have been discovered from open sources, to which commercial or clearing houses have not process, you must review and assign a grade to the vulnerability. Based on the grade or score, coupled with the criticality of the systems that may be affected along with the probability of exploitation, we can then properly gauge the response to remediation.

If you are unsure of how to perform the grading on your own, or just want a quick and dirty, the DHS^[?] has made available a CVSS v2 Calculator available at the following URL:

• http://nvd.nist.gov/cvss.cfm?calculator&version=2

Vulnerabilities discovered after deployment must be tracked from discovery to remediation. This is heavily reliant on some type of internal tracking system, personally I use redmine, to track the lifecycle of the vulnerability from the time it is discovered, the entire internal review and assessment, recommended corrective actions, implementation of remediation action to verification and finally the lessons learned or RCA^[?] (root cause analysis). On a side note, any remediation actions must be included in the system documentation. This will assist in not on the vulnerability/patch management process, but will also greatly improve incident response timelines when necessary.

Response Planning

When new vulnerabilities are discovered, a response planning process should be engaged. As part of the response planning, the focus should be on the specific vulnerability as well any risks identified during the internal review and assessment. Once a new vulnerability has been discovered, there is of course a greater chance of exploitation of the vulnerability. The planning process should of course involve the incident response team but must also include the system/applications owner(s) as well as the applicable operational group (i.e networking, systems administration).
Vulnerability Remediation

At this point in the lifecycle, we’ve identified the vulnerability, identified the vulnerable systems, developed a remediation plan, engaged the incident response capability and are ready to implement the chosen solution. Prior to actually correcting the vulnerability, ensure the system/application owner(s) have been properly notified. Included within the notification must be the projected time frame to begin as well as conclude the corrective actions. Make sure the notification includes all applicable individuals so no one feels left out, this has come back to bite more than one handler.

• You’ve also created your back-out plan and you’ve also run the entire corrective and back-out past the system/application owners right? =)

Keep in mind that the chosen remediation method must follow the documented process previously defined and agreed upon. This process must be adhered to by all involved parties. Any deviation from the process must be authorized, if for some reason the deviation does not allow for authorization at the time, the reasoning for the deviation must be documented and the affected parties later informed of the deviation in totality.

Remediation Methods Overview

Remediation methods are typically classified into the following three:
• Installation of a security patch
o Application of security patches may replace specific portions of the application code that have been determined to expose a vulnerability

• Modification of a system or application configuration parameter
o Modifying the configuration of how the application, or a portion of the operating system, functions that has been determined to expose a vulnerability

• Removal of the affected application or service
o If, after thorough review, it is determined the vulnerable piece of software, or portion of the underlying operating system, is not a functional necessity of the system, the software or service should be removed.

Remediation Methods

1. Installation of the Software Patch
a. All software patch testing should be performed on non-production systems.
b. Verification should be performed to ensure installation of the most recent security patch does not inadvertently remove previous security patches.
c. If multiple patches were published, verify there is not a specific installation sequence.
d. Prior to installation of the patch, ensure that any applications that may rely on the portion of the application, or operating system, have been fully tested to ensure continued operability post patching.
e. The length of time to properly verify a patch or subset of patches is variable based on the scope of the patch and whether the patch will interact with subsets of the operating system or other applications. The exact time frame of patch testing must be defined by the parties responsible to the systems/applications to be patched as well as the group performing the testing.
i. Security patch installations should additionally be implemented into baseline operating system installation procedures.
f. Manual verification of the security patch should be performed through the use of an automated vulnerability assessment tool (Nexpose) or manual verification.
g. Once testing of the security patch has been completed, the patch(es) are to be introduced into the patch distribution system (i.e. SCCM) for dissemination into the environment.

2. Modification of System or Application Configuration Parameters
a. Modification of configuration parameters has traditionally been a “from the hip” response to a vulnerability, as such they typically do not receive thorough testing as security patches.
b. Configuration modifications should first be performed on non-production systems. Configuration modifications may impact operational privileges and in some cases functional stability. As such, post implementation of configuration changes should include monitoring the system/application for proper functionality and stability.
c. Manual verification of the security patch should be performed through the use of an automated vulnerability assessment tool or manual verification.
i. Configuration modifications, when permanent, should be implemented into the baseline operating system and/or application installation procedures.

3. Removal of the Affected Application or Service
a. Removal of the vulnerable application or service effectively eliminates the vulnerability. Prior to removal of the application or service however, a thorough analysis of the system and applications in operation must be performed to ensure that removal does not impact the operational requirements of the system.
i. Just because you think java is not needed on that server running Oracle 11gr2, from your perspective; realize that in doing so you may make that Oracle Enterprise Manager or Grid Control application stop functioning completely.
b. Removal of applications or services, as with patching, should be performed on test systems. A pre-defined period of time should be stated for review of the operational integrity of the system post removal.
c. Manual verification of the security patch should be performed through the use of the Vulnerability Assessment tool.

A final option, typically utilized by Governmental agencies, would be the issuance of a RAF^[?] (Risk Acceptance Form). The RAF neither mitigates nor eliminates the vulnerability, but indicates that the system/application owner recognizes that a potential vulnerability exists, acknowledges that no changes to the system will occur and accepts the potential risk. In my personal opinion, this is an option that should rarely, if ever, be utilized.

• Something else to bear in mind, the entire remediation process should follow your organization change management process..you do have a change management process right?

Remediation Verification

Upon completion of the selected remediation effort, verification must be performed through manual review of configuration files or patch installation logs and vulnerability assessments. It is my personal recommendation that systems/applications which have had some corrective measures made against them be monitored for at minimum one week to ensure system/application integrity and availability.

OSSEC - Part 2 - The OSSEC Configuration (ossec.conf)

nospam@example.com (Keith Pachulski) — Mon, 24 May 2010 20:16:00 -0400

In previous posts we've reviewed the basic server and client configuration as well as how to, using the external parser, insert the alerts into BASE. At this point we're going to delve a bit deeper into the server side configuration.

Email Alerting

This is really personal preference, if you like receiving a ton of email with events that are also being inserted into the database, feel free to make use of this.

At the top of the ossec^[?] configuration file located in /var/ossec/etc/ossec.conf, the first container specifies what types of alerts you want to receive as well as where the you want the specified alerts being sent to. This container may already be populated if you enabled email notification during setup.

<global>
<email_notification>yes</email_notification>
<email_to>you@yourdomain.com</email_to>
<smtp_server>someserverhere</smtp_server>
<email_from>ossecm@yourdomain.com</email_from>
</global>

While this is the base configuration, there are a few additional options you may want to use here.

Enable throttling, this is highly recommended. If the systems you are monitoring become targeted by a high rate attack and ossec is configured to generate an email on every alarm. You can effectively cause a denial of service condition on your own systems. This is set with the following:

- <email_maxperhour>X</email_maxperhour>

X would be the maximum number of emails that ossec will generate in a given hour. Keep in mind, by setting this option, if you are relying on email alerts you may miss events with the high level threshold you set. The events are queued however once they reach the X limit you set, the queue is cleared 20 alerts at a time until cleared.

In addition to the global email alerting, we can also create targeted email groups based on server names, as they have been named when the client was configured when using ./manage_agents

<email_alerts>
<email_to>null@protectors.cc</email_to>
<event_location>servers1|server2</event_location>
</email_alerts>

Tweaking the email alerts

The default email alert configuration within OSSEC^[?] is as follows:

<alerts>
<log_alert_level>1</log_alert_level>
<email_alert_level>7</email_alert_level>
</alerts>

The alert levels are based on severity of the events ranging from 0 to 15. With 0 being information and 15 being high severity. The alert levels themselves are defined within the ossec rule files located in /var/ossec/rules. When modifying this log and email alert levels, ensure events you deem as important are not going to be missed during this tuning process. An example of the alert level in an ossec definition would be as follows:

<rule id="12109" <strong>level="12"</strong>>
<if_sid>12100</if_sid>
<match>exiting (due to fatal error)</match>
<description>Named fatal error. DNS service going down.</description>
<group>service_availability,</group>
</rule>

In this example, OSSEC will log all events level 1 and higher. Level 0 alerts are those that we have defined that we are not interested in being reported on. In the above example of email_alert_level, only events level 7 or higher would generate email alerts. This is only applicable if you have enabled email alerting that is.

Receiving and Processing Alerts from Remote System/Devices

With this portion, we are concerned with the receipt and processing of events from remote systems. We will receive these events in one of two manners. The first is syslog being configured on the remote device to send events to the OSSEC server, these will typically be networking devices or servers with syslog support. The second method is using the ossec agent on a remote system to send log events via a secure channel to the ossec server.

Configuring Standard Syslog and OSSEC to Monitor

In this example, we have our OSSEC server also running as a central log collector. All events received from remote system are received on Local6.info and are inserted into /var/log/messages.

The typical syslog configuration will appear as follows in /etc/syslog.conf

local6.* /var/log/messages

For the OSSEC configuration on the server, we define the following:

<localfile>
<log_format>syslog</log_format>
<location>/var/log/messages</location>
</localfile>

Now, on networking equipment such as switches and routers, we need to define the logging facility and host to log events to. The following would be an example for a Cisco Router:

logging facility local6
logging source-interface <interface facing the ossec server>
logging <ip address of the ossec server>
do wr
exit

As long as syslog is correctly configured on the server, messages from the device will begin to populate the /var/log/messages file. To start OSSEC processing the events, restart ossec after adding the above (note: /var/log/messages is typically added to most configuration by default on linux based systems).

OSSEC has the ability to monitor several including syslog, snort, squid, IIS, Windows event logs, mysql, postgresql and apache. However, the important thing to to remember with OSSEC is that the log formatting is completely customizable and can support nearly any type of logging.

Syscheck Configuration Options

My typical Linux syscheck template is along these lines depending on the installation and the purpose of the server:

<syscheck>
<frequency>14400</frequency>
<directories realtime="yes" >/var/www</directories>
<directories check_all="yes">/opt,/bin,/usr/bin,/usr/local/bin,/usr/local/sbin,/sbin,/boot,/etc,/home</directories>

<alert_new_files>yes</alert_new_files>
<scan_on_start>no</scan_on_start>
<auto_ignore>no</auto_ignore>


<ignore>/etc/mtab</ignore>
<ignore>/etc/mnttab</ignore>
<ignore>/etc/hosts.deny</ignore>
<ignore>/etc/mail/statistics</ignore>
<ignore>/etc/random-seed</ignore>
<ignore>/etc/adjtime</ignore>
<ignore>/etc/httpd/logs</ignore>
<ignore>/etc/utmpx</ignore>
<ignore>/etc/wtmpx</ignore>
<ignore>/etc/cups/certs</ignore>
<ignore>/etc/dumpdates</ignore>
<ignore>/etc/svc/volatile</ignore>
</syscheck>

Breaking this down piece by piece; when we specify the directory to monitor we have the following options available to us:

- realtime - provides realtime monitoring of the specified directories
- check_all - performs all of the below checks on the specified directories
- check_sum - checks for changes to the md5/sha1 hash of the files
- check_size - checks for changes to the sizes of the files
- check_owner - check for changes to the owner of the files
- check_group - check for changes to the group ownership
- check_perm - check for changes to the permissions

It would be my recommendation that either check_all by the default with realtime as the alternate option for those highly critical directories.

Frequency defines the amount of time, in seconds, that OSSEC will fire to perform the checks on the specified directories. Makes sure to tune this to an acceptable level. While 100 seconds may seem sexy, it's not realistic and may end up crushing your servers.

Alert_new_files - by default this is not in the configuration. I strongly recommend this be added and set to yes. When ossec makes its run, anything new it finds it will generate an alarm on, otherwise you`ll never know when someone uploads the c99.php file if you're not doing realtime checking of /var/www/html

Scan_on_start - by default this is set to yes, I would recommend this be set to no and let it run on against the frequency setting. I`m not sure if its a feature of a bug but on some rare occasions when I've restarted ossec it's caused scans an hosts to restart and when making several changes to the local_rules and restarting several times..it brought a system to a dead halt for a short time period.

auto_ignore - by default this is set to yes, this meaning after the 3rd time the file has changed in some way and you have not acknowledged the change it will simply ignore it. Not the best approach in my opinion for a noisy system that requires monitoring.

As for the ignores, those are some general noisy files, feel free to add more to the list as you see fit.

Additional options include scanning specific directories on certain days or at specific times if you do not want to rely on the general frequency directive.

scan_day - specifies the day or days you want the scan to run (scan_day sunday, wednesday, friday)

scan_time - specifies the time of the day you want the scan to run ( scan_time 12pm)

Ignoring sub-directories with syscheck

There may be on occasion you want to monitor for example /var/www/html and all directories contained with it, but you do not want to monitor sarg/

<directories check_all="yes">/var/www/html<directories>
<ignore>/var/www/html/sarg</ignore>

This will effectively ignore all files and directories contained within the /var/www/html/sarg directory.

Rootcheck Configuration Options

Again, my typical linux template..feel free to customize it as you see fit Something to bear in mind though, the rootcheck portion can be very resource intensive. This module will scan the entire operating system by default looking for both rootkits as well as common system configuration issues. While I personally let it scan the entire system, it can be disabled with the scanall no option.

<rootcheck>
<frequency>86400</frequency>
<rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
<rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
<system_audit>/var/ossec/etc/shared/system_audit_rcl.txt</system_audit>
<system_audit>/var/ossec/etc/shared/cis_rhel5_linux_rcl.txt</system_audit>
</rootcheck>

Frequency I define as daily, and as I use CentOS5 I leave in the rhel5 file and remove the cis_rhel_linux_rcl.txt. If you are running a non 5 release, feel free to add or replace cis_rhel_linux_rcl.txt as needed.

While most of this specifically addresses the server side configuration, the syscheck, rootcheck, and localfile parameters are portable to the client side ossec.conf configuration files.

Going to wrap it up with this, next section will likely be on OSSEC Reporting as I'm on a reporting and metrics kick as of late..

Any questions feel free to shoot me an email..

Disk Encryption - The OpenSource Solution - TrueCrypt

nospam@example.com (Keith Pachulski) — Sat, 17 Apr 2010 12:22:41 -0400

My "secure" USB drive and a toilet bowel had a duel and the toilet bowl won. With that, I was torn between buying a new "secure" USB drive for $70-100 or buying a base plain USB drive and finding some disk encryption software. Of course in the back of my mind was a task of encrypting the entire disk on my laptop. With that I set out to find a free and moderately easy to use disk encryption software package. My requirements for the software package were the following:

- Must work on all the different operating systems I commonly use (Windows & Linux)
- Must be portable, if needed to be accessed on a different system it must work with at most installing the application
- Must be able to encrypt the entire file system
- Must be able to create virtual encrypted volumes (volume must not be overtly visible)
- Must be able to create an encrypted file system on removable media (SD or USB & volume must not be overtly visible)
- Must allow for auto-mounting of the encrypted file system, either virtual or removable media
- Must automatically unmount the drive when system is shut down or idle for a predefined time period
- Must lock/wipe the device on a predefined numbers of authentication failures
- Must use NIST^[?] approved encryption and hashing algorithms

After tinkering with 12-13 different software packages I decided on TrueCrypt, it met all my requirements except the lock/wipe the device on authentication failures. I could live without that one.

In creating the volumes, you are offered standard encryption algorithms or cascading algorithms. Cascading meaning you can implement multiple types of encryption algorithms built atop each other. Supported direct and cascaded algorithms include the following:

- AES^[?] in XTS Mode (NIST Approved)
- TwoFish
- Serpent

Cascading algorithms include the following:

- AES-TwoFish
- Serpent-AES
- Serpent-TwoFish-AES
- AES-TwoFish-Serpent

Speed wise, the direct algorithm is the preferred choice. AES will be the fastest of the available algorithm selections. If you are more concerned with security of the data at rest, the AES-TwoFish-Serpent cascade algorithm is recommended. bearing in mind, using the cascade algorithms will significantly slow the overall encrypt/decrypt throughput.

Hashing algorithms supported include the following:

- RIPEMD160
- SHA512 (NIST Approved)
- Whirlpool

Quick Volume Setup Guide for Removable Media for the Windows Operating System

Insert the USB or SD card into the reader or USB slot, open TrueCrypt and click on Create Volume.

- Select Encrypt a non-system partition/drive
- Volume Type - Standard TrueCrypt volume
- Select the USB drive (IMPORTANT NOTE: Make sure you select the USB drive and not your primary hard disk)
-- you'll get an error asking you to confirm that you want to encrypt the device, select yes

- Volume Creation Mode
-- Create encrypted volume and format it

- Encryption Options (select what you want here)
-- Encryption Select AES
-- Hashing Select SHA512

Volume Size - Select next as you're encrypting the entire file space

Volume Password - Enter the password you want to use to access the encrypted volume here

Volume Format - select NTFS for the filesystem type - do not select Quick Format, select Format

Once the device has been wiped and encrypted, remove the USB device and reinsert it into the system.

Quick Setup Guide for Creating Encrypted File Containers

Create a dummy file someone on your primary harddisk, for simplicity I used c:\temp\TrueCryptVolume

From the TrueCrypt application, click on Create Volume

- Select Create an encrypted file container
- Standard TrueCrypt Volume
- Click on Select file and navigate to where your container file is located - when prompted if you want to replace it select Yes
- Choose the encryption and hashing algorithm of your preference
- Designate the desired size of the encrypted volume
- Set the volume password
- Select NTFS for the filesystem and click on format - click yes to the warning to confirm creating the container
- Mount the container by clicking on Select File, navigate to the container file, select an unused drive letter, then click on mount

Enabling Automount for TrueCrypt Volumes

From the TrueCrypt application select Settings -> Prefereces - Checks the boxes next to the following options:

- TrueCrypt Background Task Enable
- Start TrueCrypt Background Task
- Mount all device-hosted TrueCrypt Volumes
- Mount Favorite Volumes

If you want the drives, after being idle for a predefined time period, to automatically dismount, select the "auto dismount volume after no data has been read/written to it for" and enter your time limit.

Click OK - Click Auto-Mount Devices, you will be prompted for the volume password.

Important Notes

Be aware that all disk encryption programs only protect the information "physically" written to the encrypted media be it virtual or physical. Any information you access is temporarily stored in system memory. If a computer system is not:

- shut down properly
- suffers from a power failure
- the removable media is removed without being unmounted
- as well as slew of other issues that may cause an unclean memory purge

May result in sensitive information being inadvertently left in temporary file space on the hardrdrive of the computer. If the entire system harddisk, as well as removable media, is encrypted, this is not an issue.

if you are encrypting the entire system harddrive, there have been some freak occurrences of on improper shutdown, the boot record becoming corrupted; Thereby turning your computer into a doorstop. However, full disk encryption is the recommended path if the information on your laptop for example is sensitive and may cause some severe impact to you if it were say stolen..not that laptop theft ever occurs right =)

Integrating OSSEC into BASE

nospam@example.com (Keith Pachulski) — Thu, 25 Feb 2010 22:21:00 -0500

This is the quick and dirty for integrating OSSEC^[?] alerting into BASE so you can have your snort and OSSEC alerts alarms residing in the same interface.

Install snort and BASE, if you`re not sure how to do this refer to the previous posting on this topic found here.

Once you have snort and base installed, have imported the sql schema's for both snort and acid, import the OSSEC schema into the snort and snort_archive databases; the mysql schema files for ossec^[?] can be found in the contrib directory:

# mysql -u snort < ossec2mysql.sql snort
# mysql -u snort < ossec2mysql.sql snort_archive

Move the following three files from the contrib directory to /usr/local/bin/

# mv ossec2mysql.pl /usr/local/bin/
# mv ossec2mysqld.pl /usr/local/bin/
# mv compile_alerts.pl /usr/local/bin/

Modify ossec2mysql.conf adding the correct database information, chmod the file 600, chown the file root.root then move it to /etc/

If you do not already have a signatures directory under BASE, create it now (I`ll be bringing this up again during the initial snort/BASE install for those who do not have it yet).

# mkdir /var/www/html/secure/base/signatures && chown apache.apache /var/www/html/secure/base/signatures

At this point you want to import all current OSSEC alarms into the snort database which BASE is querying from:

# zcat /var/ossec/logs/alerts/2010/Feb/ossec-alerts-*.gz | /usr/local/bin/ossec2mysql.pl --conf /etc/ossec2mysql.conf --interface manualfeed

After you've imported all the current events manually into the snort database, launch the ossec process to continuously monitor and import OSSEC events into the snort database:

# /usr/local/bin/ossec2mysqld.pl --conf /etc/ossec2mysql.conf -d

Now log into BASE and you should have all your archived OSSEC alerts, as well as all future alarms being inserted into BASE.

Introduction to OSSEC - Server/Client and OSSEC WUI

nospam@example.com (Keith Pachulski) — Fri, 19 Feb 2010 22:35:28 -0500

In this episode we'll be reviewing the OSSEC^[?] Host Intrusion Detection System (HIDS^[?]). We will cover the basic steps to installing and configuring both the server and client applications. Additionally, we'll be covering installing and configuring the OSSEC Web User Interface (WUI). We will not be covering how to integrate OSSEC into the BASE management console. That will be addressed in another blog post, to be released shortly.

OSSEC, for those of you who aren't aware of what it is exactly, is a software based system that monitors the host operating system. Like traditional integrity check based systems (tripwire, aide, osiris), ossec^[?] performs file and user/group monitoring. One of the major differences between OSSEC and other traditional systems, is that OSSEC can perform the monitoring in real time on designated files and directories. In addition to the file monitoring capabilities, OSSEC has the ability to monitor the registry on Windows systems for alteration to registry keys.

OSSEC also monitors log files in real time, this functionality is typically referred to as a Log Based Intrusion Detection (LIDS^[?]) system. The LIDS portion of the application is enabled by default as part of the basic server and client installation. OSSEC exports the client system logs to the central OSSEC server via a secure channel. The server OSSEC then analyzes all entries for questionable entries or known designated "bad" entries. This includes Windows Security, Event and Application logs, IIS logs, database logs, Apache, SQUID, firewalls, routers, switches, snort as well as a slew of others. For a complete list of all supported log files please see the OSSEC list, bearing in mind however that you can use the generic module to inspect log files or create your own to monitor custom log files. In addition to monitoring for known and questionable "bad" traffic, it will also generate alarms for anything it does not understand or underlying operating system errors such as process failures, disk full errors, raid failures to name but a few.

But wait...there's more..

In the typical OSSEC installation, as with most traditional file integrity check based systems, you need to install some type of agent on the client systems. OSSEC has a very useful feature for those systems which may not support a client to be installed. For these you can utilize the agentless configuration for monitoring virtually any type of system, be it a Cisco ASA firewall or an OS/400 system.

The entire OSSEC system is extremely flexible.

In all examples from this point forward, I am basing the installation of both the client and server on the CentOS 5 operating system. The basic setup and design however is generally the same on all *nix based systems. I am also basing the installation on the current version of OSSEC which is v2.3 as of the time I'm writing this. When doing the installation yourself, you may want to refer to the ossec.net website if you are unable to retrieve the packages using the links I've provided.

Log Samples for various OSSEC Alerts

New User logging into the system

** Alert 1267052622.246237: mail - syslog,fts,authentication_success
2010 Feb 24 18:03:42 keithpachulski -> /var/log/secure
Rule: 10100 (level 4) -> 'First time user logged in.'
Src IP: (71.185.192.3)
User: bernie
Feb 24 18:03:41 keithpachulski sshd[9304]: Accepted password for
bernie from 71.185.192.3 port 57905 ssh2

Yum updates on the system

** Alert 1266983791.268245: mail - syslog,yum,config_changed,
2010 Feb 23 22:56:31 keithpachulski -> /var/log/messages
Rule: 2933 (level 7) -> 'Yum package updated.'
Src IP: (0.0.0.0)
User: (none)
Feb 23 22:56:31 keithpachulski yum: Updated:
systemtap-runtime-0.9.7-5.el5_4.1.i386

Douchebags attempting directory traversal attacks on my server and failing

** Alert 1267064964.272533: - web,accesslog,attack,
2010 Feb 24 21:29:24 keithpachulski -> /var/log/httpd/access_log
Rule: 31104 (level 6) -> 'Common web attack.'
Src IP: (195.93.200.219)
User: (none)
195.93.200.219 - - [24/Feb/2010:21:29:23 -0500] "GET
/%22%20%20target=%22_blank/index.php?option=com_communitypolls&controller=./../../../../../../../../proc/self/environ%00
HTTP/1.1" 404 235 "-" "-"

Obtain the OSSEC application and the OSSEC WUI

$ wget http://www.ossec.net/files/ossec-hids-2.3.tar.gz
$ wget http://www.ossec.net/files/ui/ossec-wui-0.3.tar.gz

Untar both the ossec-hids and ossec-wui packages

$ tar zxvf ossec-wui-0.3.tar.gz && tar -zxvf ossec-hids-2.3.tar.gz

Install the OSSEC HIDS application

$ cd ossec-hids-2.3
$ su or sudo ./install.sh
$ Select [en] as the default language

Hit -Enter- after the install script displays the host information

1- What kind of installation do you want (server, agent, local or help)?

Enter "server"

2- Setting up the installation environment.

- Choose where to install the OSSEC HIDS [/var/ossec]:

Leave it as the default /var/ossec by selecting [Enter]

3- Configuring the OSSEC HIDS.

3.1- Do you want e-mail notification? (y/n) [y]:

If you want OSSEC to send you emails on alert, select y - if you do not want it to send you emails on alerts select n

If you select yes, you'll be prompted for your email server information.

3.2- Do you want to run the integrity check daemon? (y/n) [y]:

Select y as the default as we want the server and agent processes to perform file integrity checking.

3.3- Do you want to run the rootkit detection engine? (y/n) [y]:

Select y as the default as we want the server and agent processes to check for known malicious software and perform basic checks on our application installations.

3.4- Active response allows you to execute a specific
command based on the events received. For example,
you can block an IP address or disable access for
a specific user.
More information at:
http://www.ossec.net/en/manual.html#active-response

- Do you want to enable active response? (y/n) [y]:

If you want the OSSEC software to actively respond to suspected intrusion, enable this. Otherwise select n for it to operate in a passive monitoring and reporting mode.

3.5- Do you want to enable remote syslog (port 514 udp)? (y/n) [y]:

Enter n here (entering n assumes you already have syslog listening for remote entries - check your syslog conf to be sure), later on in the configuration we'll be specifying the syslog files we want OSSEC to monitor on both the server and client installations.

After entering y or n on the last entry, OSSEC will scan all default log locations for all system log files and automagically begin tailing those files. While OSSEC tails the files, it will be comparing all entries against known malicious or questionable traffic patterns being entered into the logs.

If there are additional logs you want monitored, simply modify the ossec.conf file after the installation has completed. We'll cover this more later.

Once the installation has completed, you'll need to modify the default configuration file to reflect your system configuration and remove some unnecessary lines from the configuration.

If you installed OSSEC to the default location, the configuration file can be found in /var/ossec/etc

To view my sample server configuration template for OSSEC running on CentOS5 or RHEL5, go here

The above configuration will enable the following options:
- file integrity checks to be performed on the server every 14400 seconds
- file integrity checks for all files located in the following location:
-- <directories check_all="yes">/bin,/usr/bin,/usr/local/bin,/usr/local/sbin,/sbin,/boot,/etc,/home</directories>

The check_all options tells OSSEC to watch all attributes of the file including permission, owner, group etc. There is an additional option to continuously, in real-time, monitor the specific file or directory by using the "realtime" option.

-- <directories realtime="yes" check_all="yes">/bin,/usr/bin,/usr/local/bin,/usr/local/sbin,/sbin,/boot,/etc,/home</directories>

Other optional fields that are recommended to add are as follows:

- alert_new_files: This is not a default option and designates that when new files are created, OSSEC will generate alerts for each new file created. This option should be set to "yes".

- scan_on_start: This option should be disabled. It can be disabled by setting the field to "no". If this option is not disabled, each time OSSEC is restarted on the system, OSSEC will rescan the entire file system.

- auto_ignore: By default OSSEC will auto-ignore files that change often and are not acknowledged. In certain environments, this type of behavior is not acceptable and this should be disabled. Disabling this option is accomplished by setting the field to "no".

Rootkit checks and system audits, I perform every 86400 seconds. This can be tuned to whatever value you are comfortable with. Bear in mind however that the rootkit and system level audit checks can be resource intensive.

Once the server configuration has been completed, start the OSSEC process: /var/ossec/bin/ossec-control start

With the OSSEC server portion operating, we will configure the OSSEC WUI before moving onto installing, configuring and integrating a client into the OSSEC syste,

Installing and Configuring the OSSEC WUI

As root, move, rename and change the owner/group of the ossec-wui-0.3 directory as follows:

# mv ossec-wui-0.3 /var/www/html/ossec && chown -R ossec.ossec /var/www/html/ossec
#cd /var/www/html/ossec

Run the setup script in the ossec directory:

# ./setup.sh

Afer entering the requested information during the setup.sh script execution, add the "user" apache runs as to the ossec group

#usermod -G ossec apache

Modify the permission on the tmp/ directory in the ossec directory to allow apache to access the contents of tmp

# chmod 770 /var/www/html/ossec/tmp && chgrp apache /var/www/html/ossec/tmp

Restart Apache

By default, OSSEC will authenticate access to the OSSEC directory using Basic htaccess authentication. If you have BASE installed and want to use MySQL authentication from the BASE system, modify the .htaccess directory to use the following:

AuthName "Access Restricted to Authorized Users Only"
AuthType Basic
AuthMySQLEnable on
AuthMySQLHost localhost
AuthMySQLUser snort
AuthMySQLPassword (yoursnortMySQLpasswordhere)
AuthMySQLDB snort
AuthMySQLUserTable base_users
AuthMySQLNameField usr_login
AuthMySQLPasswordField usr_pwd
AuthMySQLPwEncryption md5
require valid-user

Authenticating users from the BASE MySQL table will allow you to permit access to everyone who has access to the BASE console access to OSSEC, without the need for continuously modifying the .htpasswd file each time you want to add a new user.

The OSSEC WUI configuration is now completed, you should now be able to access it via your web broswer by going to https://ipofserver/ossec

-- Note: If you don't have this running under HTTPS, it would be in your best interest to do so.

At this point, you should have the OSSEC server operating as well as the OSSEC WUI, we will now add our first client to the system.

Installing the client is exactly the same except that instead of installing it as a server, we'll be installing it as an agent.

Installing the OSSEC Client

$ tar -zxvf ossec-hids-2.3.tar.gz
$ cd ossec-hids-2.3

su to root to install the software and modify the configuration

# ./install.sh

Select en as the default language and enter agent for the install type.

Once you enter agent, take the default installation location which will be /var/ossec

You will then be asked for the IP address of the OSSEC HIDS Server, enter it and hit enter

3- Configuring the OSSEC HIDS.

3.1- What's the IP Address of the OSSEC HIDS server?:

3.2- Do you want to run the integrity check daemon? (y/n) [y]:

Accept the default of "y" here

3.3- Do you want to run the rootkit detection engine? (y/n) [y]:

Accept the default of "y" here

3.4 - Do you want to enable active response? (y/n) [y]:

Select "n" here, at this point OSSEC will now install the agent application on the system.

As with the server side installation, the ossec configuration file needs to be modified. I have made a template available for *nix based systems available by clicking here

Once you've completed the client side configuration we now need to add the client to the server configuration.

Introducing the Client to the Server

All communications between the client and server are encrypted. If for whatever reason the communication path between the client and server becomes interrupted, the client side will queue messages until the server becomes reachable again. At which time it will export all queued messages to the server.

On the server we first need to add the client system, export the encryption key for the client, then restart the ossec process. This all needs to be performed as root or via sudo, whichever method you typically use.

# cd /var/ossec/bin
# ./manage_agents

Select "A" to add an agent
- enter the name of the agent
- enter the ip of the agent
- accept the default value for the ID

Select "E" to extract the key
- enter the ID of the system

Copy the entire key, if any portion of the key is missing, the client will not be able to connect to the server.

Exit from the manage_agents application and restart OSSEC

# /var/ossec/bin/ossec-control restart

On the client, run the manage_agents application. Unlike the server, you will only have the option to import a key via "I" on the client.

Once you enter the IP and paste in the key, exit from the manage_agents application and start the ossec application:

# /var/ossec/bin/ossec-control start

As long as the agent and the server have a clear communication path, the client will begin its first operating system integrity, audit and rootkit checks as well as beginning to export all system logs designated in the client OSSEC configuration file to the server.

To add more systems, simply repeat the "Installing the OSSEC Client" and "Introducing the Client to the Server" steps.

That's all for now folks...check back soon for "How to Integrate OSSEC into BASE"

Quick Reference Guide: Snort and BASE Installation and Setup

nospam@example.com (Keith Pachulski) — Mon, 15 Feb 2010 17:05:20 -0500

This is the quick and dirty guide to compiling, configuring and installing snort to log to a mysql database, then installing BASE to view those alerts. We`ll be using this basic setup again later as we integrate OSSEC^[?] into BASE for centralized reporting of all network and host based intrusion alarms.

For snort you'll need to obtain the following for this install:

PCRE
libpcap
snort

Compiling and Installing PCRE

$ tar zxvf pcre-8.01.tar.gz
$ ./configure && make

su to root and install: make install

Compiling and Installing libpcap
$ tar zxvf libpcap-1.0.0.tar.gz
$ ./configure && make

su to root and install: make install

Compiling and Installing Snort

If possible, do not have the MySQL server running on the snort sensor server, the two functions should be seperated.

$ tar zxvf snort-2.8.5.2.tar.gz
$ ./configure --with-mysql --enable-perfprofiling --enable-reload

su to root and install: make install

Create a new user for snort to run under, snort should NOT be run as root

# useradd -c "snort nids" -s /sbin/nologin snort

Create the directory to store the snort signature files

# mkdir /home/snort/sigs

Move the preprocessor rules to the snort directory

[root@cent snort-2.8.5.2]# mv preproc_rules/ /home/snort/sigs/

Move the snort init script and logrotate scripts to their correct locations

# mv rpm/snortd /etc/rc.d/init.d/
# ln -s /etc/rc.d/init.d/snortd /etc/rc3.d/S99snort
# chmod 755 /etc/rc.d/init.d/snortd
# mv rpm/snort.logrotate /etc/logrotate.d/snort
# mv rpm/snort.sysconfig /etc/sysconfig/snort
# mv etc/snort.conf /home/snort/
# mv etc/ /home/snort/sigs/

Add the snort libraries to the ld.so.conf file and run ldconfig

# echo /usr/local/lib/snort_dynamicrules >> /etc/ld.so.conf
# /usr/bin/ldconfig

We'll come back configuring the rest of snort once we have BASE running

Create the MySQL database to be used by snort for event logging, to be used later by BASE

mysqladmin create snort
mysqladmin create snort_archive

From the schema directory, execute the following:

mysql -u root -p < create_mysql snort
mysql -u root -p < create_mysql snort_archive

Create the snort user and grant permissions on the snort. and snort_archive. databases

$ mysql -u root -p
mysql> create user 'snort'@'localhost' identified by 'password_goes_here';
mysql> create user 'snort'@'ip_of_the_remote_snort_sensor' identified by 'password_goes_here';
mysql> grant CREATE,INSERT,SELECT,DELETE,UPDATE on snort. to 'snort'@'localhost';
mysql> grant CREATE,INSERT,SELECT,UPDATE on snort. to 'snort'@'ip_of_the_remote_snort_sensor';
mysql> flush privileges;

Installing and Configuring BASE

Upgrade pear and all installed pear packages, this will be needed for some of the BASE modules

If php-gd is not installed, install it now

yum install php-gd

pear upgrade PEAR-1.x.x (whatever the most recent is)
pear install Image_Color
pear install --alldeps --force Log
pear install Numbers_Roman
pear install --alldeps --force Image_Graph-0.7.2
pear install --alldeps mail
pear upgrade-all

Download and install adodb

$ tar zxvf adodb510.tgz

su to root, change the owner and group then move to /var/www/

# chown -R apache.apache adodb5/ && mv adodb5/ /var/www/

Download and install BASE

$ tar zxvf base-1.4.4.tar.gz

su to root, change the owner and group then move to /var/www/html/

# chown -R apache.apache base-1.4.4/ && mv base-1.4.4/ /var/www/html/base

Modify php.ini to not expose php and set the error logging to the recommended level

expose_php = Off

error_reporting = E_ALL & ~E_NOTICE

Modify the BASE configuration file to reflect the username, password and adodb location

# cd /var/www/html/base
# cp base_conf.php.dist base_conf.php && chown apache.apache base_conf.php

$BASE_urlpath = '/base';
$DBlib_path = '/var/www/adodb5';
$alert_dbname = 'snort';
$alert_host = 'localhost';
$alert_port = '';
$alert_user = 'snort';
$alert_password = 'mypassword';
$archive_exists = 1;
$archive_dbname = 'snort_archive';
$archive_host = 'localhost';
$archive_port = '';
$archive_user = 'snort';
$archive_password = 'mypassword';
$refresh_all_pages = 1;
$show_previous_alert = 1;
$refresh_all_pages = 1;
$show_expanded_query = 1;
$colored_alerts = 1;
$IP2CC = "/usr/bin/ip2cc";

Make sure to set all the correct information in the SMTP portion of the configuration so you can email yourself or others copies of the alerts from BASE.

Install the Geography:Countries Perl module for map generation

tar zxvf Geography-Countries-2009041301.tar.gz && cd Geography-Countries-2009041301
perl Makefile.PL && make

su to root and install the perl module: make install

Install the IP-Country Perl module for map generation

tar zxvf IP-Country-2.27.tar.gz && cd IP-Country-2.27
perl Makefile.PL && make

Start apache:

/etc/rc.d/init.d/httpd start

Open your web browser and navigate to the BASE URL:

http://ip.address.here/base

If you've modified all fields correctly, you'll be presented with a page saying:

"The underlying database snort@localhost appears to be incomplete/invalid. "

Click the "setup page" link then click the Create BASE AG button.

Click on the "Main page" link, click on the "Use Archive Database" link

Click the "setup page" link then click the Create BASE AG button.

Return to the primary database by clicking the "Use Alert Database" link.

Now that snort is installed, the mysql schema for snort has been loaded and the ACID AG schema for base has been loaded, we return to the final portion of this which is finalizing the actual snort configuration file, loading the signatures and starting snort while logging alerts to the mysql database.

Download the most recent signature file from snort.org, you`ll need to generate an account to get the file.

mkdir temp
mv snortrules-snapshot-2.8.tar.gz temp/ && cd temp/
tar zxvf snortrules-snapshot-2.8.tar.gz

Move the plain text signature descriptors to the BASE directory, this must be done as root as the BASE directory is owned by apache

# mv doc/signatures /var/www/html/base/ && chown -R apache.apache /var/www/html/base/signatures

Move the signature files to the snort sigs directory which we created earlier:

# mv rules/ /home/snort/sigs/ && chown -R snort.snort /home/snort/sigs/

Modify the snort.conf file to reflect the network to be monitored, the variables noted are ones that should be modified, feel free to experiement though:

$ cd /home/snort
$ vi snort.conf

var HOME_NET 192.168.0.0/8 (enter the correct network with mask here of the network you are monitoring)
var DNS_SERVERS [192.168.0.1,192.168.0.2] (enter your actual DNS servers here)

same follows with all the variables, if you can define it please do so..the more specific you are the better the results

var RULE_PATH /home/snort/sigs
var PREPROC_RULE_PATH /home/snort/sigs/preproc_rules

The snort decoders you'll have to experiment with, personally I find them very noisy and typically disable them on all installations.

Locate the line containing the following:

iis_unicode_map unicode.map 1252

and change it to:

iis_unicode_map /home/snort/sigs/unicode.map 1252

The ftp_telnet preprocessor works well in some area's, horrible in others..it requires some heavy tuning outside the scope of this blog post.

Locate the following string, uncomment it and correct the information with your actual database information:

output database: log, mysql, user=snort password= dbname=snort host= sensor_name=

Locate the following two lines and modify them to appear as follows:

include classification.config
include reference.config

include $RULE_PATH/classification.config
include $RULE_PATH/reference.config

Once you`ve modified all the needed fields, test the config with the following string:

# snort -c /home/snort/snort.conf -i eth0 -T

If everything is correct and snort can connect to the database, you`ll be presented with the following:

Snort successfully loaded all rules and checked all rule chains!
database: Closing connection to database "snort"
Snort exiting

Now for the final part, modifying the snort sysconfig file so we can actually start/stop/restart/stats the snort process. Modify the following lines as needed:

vi /etc/sysconfig/snort
CONF=/home/snort/snort.conf
INTERFACE=eth0 (set the correct interface name of set ALL for snort to listen on all interfaces)
PRINT_INTERFACE=1
#PASS_FIRST=) (comment this out, the option no longer exists, the default behavior is pass first now)
BINARY_LOG=1 (by default snort will generate pcap dumps of all alerts, this will require much disk space and manual/scripted removal of the files as it will chew up disk space, set it to 0 if you do not want pcap generated files of alerts)

Modify the snort init script to remove an option that no longer exists but for whatever reason in 2.8.5.1 the init still references it:

#if [ "$PASS_FIRST"X = "1X" ]; then
# PASS_FIRST="-o"
#else
# PASS_FIRST=""
#fi

Create a symlink to snort for the location in the snort init script or edit the snort init script to reflect the actual location:

# ln -s /usr/local/bin/snort /usr/sbin/snort

Now just start snort up:

# /etc/rc.d/init.d/snortd start

Enjoy...

Nmap 5 UDP Application Recognition

nospam@example.com (Keith Pachulski) — Sat, 06 Feb 2010 10:20:00 -0500

In prior versions of nmap, the UDP scanning portion was essentially useless. It was not a flaw in the nmap program, but in how UDP as a transport behaves. With the new version of nmap, they've began to build application awareness of UDP services into nmap with some limitations.

Typically when scanning for UDP services, there were generally two expected response types. The first would be the receipt of some type of ICMP error message indicating that the UDP port was not open through an ICMP port or the host was unreachable via an ICMP host unreachable. The second expected "response" would be no response which would indicate that either there was some type of firewall in the path of the target that was configured to not generate ICMP error messages or that there was an actual service listening on the destination port. This of course made service discovery gernally useless from the point of UDP services.

If a port was closed, verified by the icmp port unreachable error, nmap will report the port as closed.
If the nmap host received an ICMP error code 1, 2, 9, 10, or 13, nmap will report the port as filtered.
In the destination port generates some type of response traffic, nmap will report the port as open.
If nmap receives no responose whatsoever, nmap will report the port as open|filtered.

That is until nmap, with this new version, begin to become application aware and being able to "speak" to certain UDP services. In doing this it would know how to issue expected responses to UDP services in order to verify there is an actual service listening.

To use the new UDP service, you would run the scans with the -sU. This flag option is only available as root, which won't affect most of the people who are actually reading this:

e.g.: nmap -sU -sT -A -p 1-65535 target

[root@keithpachulski keithp]# nmap -sU -p 123,500 192.168.10.254

Starting Nmap 5.21 ( http://nmap.org ) at 2010-02-06 10:08 EST
Nmap scan report for 192.168.10.254
Host is up (0.0016s latency).
PORT STATE SERVICE
123/udp open ntp
500/udp open isakmp
MAC Address: 00:1B:8F:D3:4C:62 (Cisco Systems)

Nmap done: 1 IP address (1 host up) scanned in 0.22 seconds

The same of course can also be performed directly through metasploit when logged into the msfconsole as root:

msf > db_connect
[*] Successfully connected to the database
[*] File: /root/.msf3/sqlite3.db
msf > db_nmap -sU -p 123,500 192.168.10.254

Starting Nmap 5.21 ( http://nmap.org ) at 2010-02-06 10:09 EST
Nmap scan report for 192.168.10.254
Host is up (0.0050s latency).
PORT STATE SERVICE
123/udp open ntp
500/udp open isakmp
MAC Address: 00:1B:8F:D3:4C:62 (Cisco Systems)

Nmap done: 1 IP address (1 host up) scanned in 0.17 seconds

At this time, only the following UDP services are supported though I`m sure this list will quickly be expanded upon:

udp/7 echo
udp/53 domain
udp/111 rpcbind
udp/123 ntp
udp/137 netbios-ns
udp/161 SNMP
udp/177 xdmcp
udp/500 ISAKMP
udp/520 route
udp/1645 RADUIS
udp/1812 RADIUS
udp/2049 NFS
udp/5353 zeroconf
udp/10080 amanda

Something to keep in mind though when using the UDP scanner portion of nmap. A full UDP port scan of all 65535 ports, which is required by some regulatory bodies such as the PCI^[?]-DSS, can take upwards of 18 hours to complete. This can be minimized by using the --host-timeout option and designated what time in seconds you want to give each host to respond to the UDP query:

nmap -sU -p 123,500 192.168.10.254 --host-timeout 10s

In specifying the host-timeout, you have the option to designate the value as 's' for seconds, 'm' for minutes and 'h' for hours.

Metasploit/NeXpose integration from the webconsole on CentOS

nospam@example.com (Keith Pachulski) — Sat, 30 Jan 2010 10:25:00 -0500

In integrating the use of the two products, this will walk you through the step by step setup and use for this to work with success.

Download the latest copy of ruby, currently 1.9.1 - ruby 1.9.1

Configure ruby as follows:

cd ruby-x
./configure --prefix=/opt/msf3 --enable-pthread --enable-shared
make && make install

Add ruby to your PATH: export PATH=/opt/metasploit3/bin:$PATH

After installing ruby, download and install the latest rubygems

- untar the ball, enter into the directory and execute ruby setup.rb

Install libpcap-devel via yum: yum search libpcap-devel

- cd /opt/msf3/external/pcaprub/
- ruby extconf.rb
- make && make install

After you have ruby and rubygems installed, downloaded the most recent version of metasploit or update it via svn

- svn checkout https://www.metasploit.com/svn/framework3/trunk /opt/msf3/

Install the database driver, choose one or both:
- gem install sqlite3-ruby
- gem install mysql
- gem install postgres-pr

Download and install NeXpose if you haven't done so already. Don't go any further until NeXpose is installed and operational.

Start the metasploit console: ./msfconsole

Create the database: db_create
- [*] Creating a new database instance...
- [*] Successfully connected to the database

After the database has been created, load the nexpose plugin: load nexpose
- [*] NeXpose integration has been activated
- [*] Successfully loaded plugin: nexpose

Connect to the NeXpose instance: nexpose_connect "username" "password" 127.0.0.1 3780 ok

Launch your first scan and automatically pass results to metasploit for processing

- nexpose_scan -x -t full-audit

To see the full list of nexpose_connect options, execute the following: nexpose_connect -h

If there are any successful exploitations as a result of the scan, you will be presented with the following:

- [*] Command shell session 1 opened

To view the active sessions, execute the following: sessions -l -v

Full results from the audit can be viewed by logging into the NeXpose web console.

Disconnect from NeXpose via the metasploit msfconsole or weird things happen: nexpose_disconnect

Suggestion, once this is all working correctly and you`re happy; Setup metasploit to update daily or however often you prefer via cron

* svn update /opt/msf3/

When attempting to execute future metasploit/nexpose session, be sure to reconnect to the database before connecting to nexpose:

- ./msfconsole
- db_connect
- nexpose_connect "same stuff as above"

And you`re done...go have some fun now..

Product Comparison - Nessus 4.2.0 vs. Rapid7 NeXpose

nospam@example.com (Keith Pachulski) — Tue, 12 Jan 2010 11:15:00 -0500

I've been a Nessus user for quite some time now, likely as far back as version 1. I've liked the product up till the most recent release of 4.2.0. I began having all sorts of problems. Audits not completing, when they did complete the report either would not generate or if it did generate it would present large black boxes sporadically throughout the report, the console would crash or restart without warning...

After contacting Tenable support, I was told some of the most outrageous excuses such as "We don't support scans through firewall", "We don't support scanning that large of a network segment", "You report is to large, you need to add this filter to remove some of the entries to have the report generate".

With that said, Tenable all I can offer you is this. Before your next product release, I suggest you download NeXpose from Rapid7 and seriously reconsider how your product functions and what the end-user security community actually needs.

Installation and Setup

Both products were easy to install, Nessus required no dependencies and installed after about 5 minutes. NeXpose required one dependency which took approximately 2 minutes to locate and install. After which the install process was approximately 5 minutes.

Functionality

If you download Nessus, you're restricted to only auditing for Windows vulnerabilities. If you want more, you need to buy the professional feed for $1200.00 a year.

NeXpose is fully functional with the only restriction on the "Community" version being that you cannot have more tha 32 IP's in the UI at a given time and regulatory audits are disabled. NeXpose also integrated directly with Metasploit. This makes the actual testing portion of the audit process far easier as you can just hop down to the console and test for the reported vulnerabilities rather than hunting for the source to actually verify a reported issue.

Front-End

Nessus has the very sexy front-end UI, while NeXpose has the php front-end. I honestly prefer the php front end, it loads faster and doesn't chew up a large chunk of memory. If you like flashy stuff though, the Nessus UI would likely hook you.

Audit Policies

Nessus comes with no pre-configured audit policies and while there is some user documentation, once you configure your first policy and it fails you`ll learn most of the options they`ve described in the User Guide are neither support or recommended by Tenable.

NeXpose - comes with several preconfigured policies to test for not only regulatory regulations such as PCI^[?], SARBOX, HIPAA^[?], web application audit, "full" and "exhaustive" audits or a full blown penetration test.

This of course makes the auditors jobs much easier as they do not need to spend 20 minutes trying to develop a working audit policy, run it then work out the bugs by reconfiguring the policy as with Nessus.

Audit Function and Reporting

With Nessus, after you've created your policy and finally executed the scan, you are offered a single technical report. Within the report provided by Tenable you'll have cursory overviews of the detected vulnerabilities along with the occasional CVSS^[?] score assigned to a vulnerability^[?]. From there, you have no other option but to generate your report and start the process or going to your external vulnerability management system, adding all the issues, then beginning the process of addressing the individual vulnerabilities. The actual report are only available to be generated in HTML or the Nessus specific file formats. Nessus used to have a PDF option but they removed it with version 4.x.x.

With Nessus; if you want to re-audit the system(s), you need to repeat the processing of entering the IP or netblock to rescan and assign the policy. Time consuming and slightly annoying.

NeXpose on the other hand, once you enter the IP or netblock information into the UI. The information is stored and you can setup an automated schedule process. With this you can say every 3 months for example, for those PCI-DSS folks out there, re-audit this specific asset. Yes, with NeXpose you can create an asset object.

Once the audit has been completed, the NeXpose console will list out all vulnerabilities discovered. It will also provide you with an overall CVSS score for the entire asset as well as Risk score per system within the asset group. Unlike Nessus you have two reporting options, Technical and Executive. The Executive report offer the high level overview along with graphs, charts and risk levels. The technical reports provides a complete list of all discovered issues, how the issues were discovered along with a step by step on how to resolve the issues.

NeXpose reports are also able ot be customized to the type of vulnerabilities you wish to report, such as "All Vulnerabilities", "Critical Vulnerabilities" or "Critical and Severe Vulnerabilities". Reports are able to be generated in PDF, XML or HTML.

In additional to the exhaustive reporting NeXpose provides, it also gives you the ability to track the issue directly through the NeXpose console. Once an issue has been resolved, you click on the "exclude" image and you are requested to enter why you are excluding the vulnerability. This integrated vulnerability management system makes the analysts life easier as all of the information he/she needs it contained within the single system. The entire life cycle from discovery, verification and resolution all resides on a single webpage.

The other added bonus, NeXpose runs off an integrated postgresql database. If an analyst should so desire, custom reporting can be retrieved from the database as needed.

In closing, if you are a Nessus user. I would strongly urge you to go to the rapid7 website and download NeXpose..kick the wheels and give it a spin. I promise you that you will not be disappointed.

NeXpose
Nessus