Information Security, Privacy and Regulatory Compliance - System Administration

BART (Basic Audit and Reporting Tool) on Solaris 10/OpenSolaris

nospam@example.com (Keith Pachulski) — Fri, 30 Jul 2010 23:57:08 -0400

As a follow-up to a conversation regarding this; BART is one of those integrated features that is often overlooked in the Solaris 10/OpenSolaris distributions. BART at it's core function similar to other host file integrity check systems. While it is a nice tool for small shops, it is by no means well suited for large scale deployments. For mid to large scale system integrity verification and host level intrusion detection/prevention systems I`m of course still an advocate of OSSEC^[?]. For clarification, BART only performs file integrity checking and does not monitor log files or system processes etc...

Creating the BART Manifest

This would be an example of a simple manifest recording the attributes of all files within the /etc, /boot, /sbin and /usr directories and generate an md5 hash for each file.

bart create -R /etc /boot /sbin /usr > /bart/control

Included in the control file would contain single line entries for each file, link, etc

/X11/fontpath.d/misc:unscaled:pri=15 L 35 120777 - 4c50ebb0 0 0 ../../../usr/X11/lib/X11/fonts/misc
/X11/gdm/Init/Default F 2640 100755 owner@::deny,owner@:read_data/write_data/append_data/write_xattr/execute/write_attributes/write_
acl/write_owner:allow,group@:write_data/append_data:deny,group@:read_data/execute:allow,everyone@:write_data/append_data/write_xattr
/write_attributes/write_acl/write_owner:deny,everyone@:read_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow 4a0c3
e11 0 3 bf7503995330dc79b078bdba2171d657

Each line will contain a notation defining what each entry is, these are as follows:

# Format:
#fname D size mode acl dirmtime uid gid
#fname P size mode acl mtime uid gid
#fname S size mode acl mtime uid gid
#fname F size mode acl mtime uid gid contents
#fname L size mode acl lnmtime uid gid dest
#fname B size mode acl mtime uid gid devnode
#fname C size mode acl mtime uid gid devnode

- B for a block device node
- C for a character device node
- D for a directory
- F for a file
- L for a symbolic link
- P for a pipe
- S for a socket

Further available attributes are as follows:

size - File size in bytes.
mode - Octal number that represents the permissions of the file.
acl - ACL attributes for the file. For a file with ACL attributes, this contains the output from acltotext().
uid - Numerical user ID of the owner of this entry.
gid - Numerical group ID of the owner of this entry.
dirmtime - Last modification time, in seconds, since 00:00:00 UTC, January 1, 1970, for directories.
lnmtime - Last modification time, in seconds, since 00:00:00 UTC, January 1, 1970, for links.
mtime - Last modification time, in seconds, since 00:00:00 UTC January 1, 1970, for files.
contents - Checksum value of the file. This attribute is only specified for regular files. If you turn off context checking, or if checksums cannot be computed, the value of this field is –.
dest - Destination of a symbolic link.
devnode - Value of the device node. This attribute is for character device files and block device files only.

Create the diff manifest and check for changes

To verify BART is functioning correctly, we'll create a test file in the /etc directory

keithp@opensolaris:/bart# touch /etc/thisisatest

Once the test file has been created we now need to run BART again to generate the differential manifest

keithp@opensolaris:/bart# bart create -R /etc /boot /sbin /usr > /bart/control-diff

After the diff manifest has generated, we then verify that any changes that have occurred, as well as checking for the test file being created.

keithp@opensolaris:/bart# bart compare control control-diff > bart-modifications
keithp@opensolaris:/bart# more bart-modifications
/thisisatest:
add

The test file we created was detected. No other modifications were found. The downside to BART is that if any changes were discovered that were legitimate. BART does not automatically update the control file. The control-diff would now become the primary file from which future checks are performed against. To automate the BART checks, add a cronjob to perform the creation of the new differential file as well as performing the compare jobs.

0 7,14,21 bart create -R /etc /boot /sbin /usr > /bart/control-diff
30 7,14,21 bart compare control control-diff > bart-modifications

Centralized BART Monitoring

With some creativity, through the NFS/automount, you can create a hub and spoke type design where the spoke systems individually create the control and diff files. The control files can be moved to the central server and the diff files remain on the spoke systems. Additional cronjobs would be created that would compare the manifest on the central server to the diff manifest located on the spoke systems. Bearing in mind of course that NFS is not encrypted by default but with some simple tweaks you can implement service level encryption to secure the NFS traffic between the central and spoke systems. But again, why recreate the wheel?

Again, it's nice to tinker with or act as a second line of auditing. But I would strongly urge a system like OSSEC be implemented to perform the centralized monitoring and reporting.

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.

Hardening the base PHP Installation to prevent common exploits

nospam@example.com (Keith Pachulski) — Wed, 31 Mar 2010 22:01:00 -0400

PHP "out-of-the-box" allows for an extremely broad set of access permissions, which of course isn't surprising. What we're going to cover here are the basic options that I would recommend be changed prior to any server entering into the production environment offering PHP based web applications to the Internet user base.

There are a handful of configuration options that should be modified, all of these are contained in the php.ini file. Before en-masse changing everything here, I strongly urge you to evaluate the needs of those who may be utilizing the server. Some of the options that are going to be noted here as "to be changed" or disabled, may impact the functionality of custom or 3rd party PHP packages. These are however graded as critical items that if not addressed may result in compromise of your system.

Default PHP Configuration

An overview of PHP Configuration change options can be found here

expose_php: By default this is enabled, this will allow an outsider the ability to determine that you are running PHP and what version of PHP is installed, it is recommended this be disabled. This will also cut down on the noise some web scanners generate that grab the banner searching for PHP installations.

expose_php = Off

Base Directory: by default this is not set and allows for a php script to potentially access any file on the server, modify this to the base web directory

open_basedir = /var/www/html

allow_url_fopen: This allows external URLs to be remotely included in php queries. This should be disabled to prevent your scripts from being forced to call external resources

allow_url_fopen = Off

file_uploads: This allows for files to be uploaded to the server via PHP. Unless this is absolutely needed for operations, it is recommended this be disabled:

file_uploads = Off

Default Insecure Functions

With the base install, the following insecure functions are enabled by default. To disable these insecure functions you would use the disable_functions option in php.ini - The disable_functions options is a comma separated in the php.ini file it would be entered as such:

disable_functions = proc_nice, proc_terminate, proc_close

apache_note - this is used to pass PHP strings between apache modules, such as passing PHP variables to Perl
apache_setenv - passes PHP variables to Apache subprocesses
dl - loads a PHP extension, this is known to cause stability issues
escapeshellcmd - escapes characters in a string to trick a shell command into executing arbitrary commands
exec - executes an external program
passthru - executes and external program and displays the raw output
popen - opens a process file pointer
proc_close - terminates a process started by proc_open
proc_open - starts a process
proc_nice - changes the priority of a running process
proc_get_status - fetches the status of a process
proc_terminate - allows the termination of system processes
putenv - sets an environmental variable for the active session, once the session is complete the variable is removed - bad idea, disable it
shell_exec - executes a command via the shell and returns the complete output as a string - bad..
system - executes an external program and displays the output - do I really need to explain this one?
virtual - performs apache subrequests, not the recommended method. Use include() or require() instead.

Default Insecure Classes

There is one class that should be disabled, which is enable upon installation. As with the previous, this is set in the php.ini file.

splFileObject allows for an object oriented interface to a given file. Unless this functionality is absolutely needed it should be disabled.

disable_class = splFileObject

Once these modifications are made, the system should be relatively safe from a large percentage of the automated attacks directed against PHP. I make no promises for sloppy PHP coding though =)

Enjoy..