Using an open source framework to catch the bad guy.pdf

(924 KB) Pobierz
USING aN oPEN SoURCE
fRaMEWoRK to CatCH tHE baD GUY
Built-in forensics, incident
response, and security with
red hat enterprise linux 6
red hat federal solutions architect team
By: norman mark st. laurent, senior solutions architect
editing and technical guidance: shawn wells, technical director
steve gruBB, red hat security lead
4
Part 1: Operational Use of the Red Hat
Enterprise Linux 6 Audit Log Management
Infrastructure
1.1 Establishing Policies and Procedures
for Log Management
1.1.1 RHEL 6 Log Storage and Rotation
1.1.1.1 Non auditd Log Files in /var/log
1.1.1.2 auditd Log Files in the Default /var/
log/audit Directory
1.1.2 RHEL 6 Remote Host Storage
1.1.2.1 Log Management with the /etc/audit/
auditd.conf File
1.1.2.1.1 Encryption over the Wire With SSH
Port Forwarding
1.1.2.2 Log Management with the /etc/
audisp/audispd.conf File
1.1.2.2.1 Log Management with the /etc/
audit/audisp-remote.conf File
27
28
34
34
35
39
40
1
.1.3 Specific RHEL 6 Log Generation
Settings
1.1.3.1 Log Management with the /etc/audit/
audit.rules File
1.2 Red Hat Enterprise Linux 6 Log
Management Operational Process
1.2.1 Defining Roles and Responsibilities
1.2.2 RHEL 6 Forensics and Incident
Response Log Analysis
Part 2: Host-based Intrusion
Detection System
Bibliography
7
8
9
10
12
12
17
20
20
www.redhat.com
Using an open source framework to catch the bad guy
abStRaCt
Every security policy provides guidance and requirements for ensuring adequate protection of information
and data, as well as high level technical and administrative security requirements for a system in a given
environment. Traditionally, providing security for a system has focused on the confidentiality
1
of the informa-
tion on it; however protecting the data integrity
2
and system and data availability
3
are just as important. For
example, for processing United States intelligence information there are three attributes that require protec-
tion: confidentiality, integrity, and availability.
In order to run on United States Government Systems, Red Hat
®
Enterprise Linux
®
6 has met the a stringent
set of technical security requirements for confidentiality, integrity, and availability to allow conformance
to be certified and accredited
4
. Red Hat Enterprise Linux has received Common Criteria certification at
Enterprise Assurance Level 4 (EAL 4+) under the Controlled Access Protection Profile (CAPP), Label Security
Protection Profile (LSPP), and the Role-Based Access Protection Profile (RBACPP).
Security for Red Hat Enterprise Linux 6 begins with a core feature known as SELinux. SELinux delivers
a strong and flexible Mandatory Access Control (MAC) framework to enforce role-based access control
and multi-level security. Security-Enhanced Linux support has been woven into all parts of the platform,
including virtualization, to provide critical guest separation regardless of the guest operating system.
Successful security uses a Defense-in-Depth strategy, so RHEL 6 includes system firewalls
5
, host base intru-
sion tools, system package and file integrity verification tools, and as discussed in PART 1 of this whitepaper,
audit capabilities for a complete security architecture that covers deployment models ranging from Internet-
facing servers to trusted computing.
Common Criteria security event auditing requirements are covered in both the CAPP and LSPP protection
profiles. CAPP was derived from the Orange Book
6
C2 criteria and defines audit to provide comprehensive
logging of security events that are reliable and robust. LSPP extends audit requiring “enhanced security
event auditing” to include Mandatory Access Control (MAC) labeling and decision information. LSPP was
derived from the Orange Book B1 criteria.
table 1: capp requirements
provides a detailed description of the
CAPP requirement for audit. Audit must be non-bypassable, and the right to add records to the audit trail
must be controlled. The requirements also note that both setting/viewing the audit configuration must be
controlled and that audit review must be controlled and assignable. It must have the ability to fail-stop the
system. The Linux
syslog
7
facility has none of these properties.
1 Confidentiality is defined as ensuring that information is accessible only to those authorized to have access.
2 Integrity is defined as quality of an IT system reflecting the logical correctness and reliability of the operating system; the logical
completeness of the hardware and software implementing the protection mechanisms; the consistency of the data structures and
occurrence of the data stored.
3 Availability is defined as timely, reliable access to data and information services for authorized users.
4
RHEL has passed the Common Criteria Process 13 times on four different hardware platforms.
5
RHEL 6 also includes Ethernet bridge frame table administration (
ebtables).This
application program is used to set up and maintain the
table of rules inside the kernel that inspects Ethernet frames. It works just like the
iptables
application, which inspects the IP protocol;
ebtables
inspects the Ethernet protocol.
6
Trusted Computer System Evaluation Criteria (TCSEC), referred to as the Orange Book, is a DOD standard that sets basic requirements for
assessing the effectiveness of computer security controls built into a computer system.
7
RHEL 6 uses
rsyslogd,
which is a reliable and extended
syslogd.
It is a system utility providing support for message logging. Local and
remote logging is supported, but it is not as granular as
auditd
and does not meet the strict requirements of CAPP and LSPP.
2
www.redhat.com
Using an open source framework to catch the bad guy
The Future Common Criteria Protection Profile: the
Operating System perspective has changed from single
isolated systems to more complex distributed and networked environments (e.g., virtualization and cloud),
thus rendering several of the original protection profiles, including LSPP, RBAC, and CAPP, less robust on
the requirements. On the horizon is a second generation certified Operating System Protection Profile
(OSPP). Red Hat is currently meeting the standards and requirements of OSPP from the networked systems
approach and will meet the functional and assurance requirements that are applicable. In addition, applica-
tions executing on operating systems depend upon a secure platform. The security assurance provided by
many modern operating systems has been raised over the last decade with EAL4 being the norm for this
technology and Red Hat raising the bar higher.
8
taBle 1: capp requirements
aUDIt toolS
Audit data generation
DEfINItIoN
The Target of Evaluation Security Functions (TSF )shall be able to generate
an audit record of the auditable events listed in column “Event” of Table
(Auditable Events). This includes all auditable events for the basic level of
audit, except FIA_UID.1’s user identity during failures.
The TSF shall record within each audit record at least the following informa-
tion: (a) date and time of the event, type of the event, subject identity, and the
outcome (success or failure) of the event; (b) additional information specified
in Table 1 .
The TSF shall be able to associate each auditable event with the identity of the
user that caused the event.
The TSF shall provide authorized administrators with the capability to read the
audit information from the audit records.
The TSF shall provide authorized administrators with the capability to read all
audit information from the audit records.
The TSF shall prohibit all users read access to the audit records, except those
users that have been granted explicit read-access.
This component specifies the behavior of the Target of Evaluation (TOE). If
the audit trail is full: either audit records are ignored, or the TOE is frozen such
that no auditable events can take place. The requirement also states that no
matter how the requirement is instantiated, the authorized user with specific
rights to this effect can continue to generate auditable events (actions).
Audit data generation
User identity association
Audit review
Audit review
Restricted audit review
Prevention of audit data loss
Federal security policies also mention that there must be an in-depth strategy that provides appropriate
degrees of protection to all computing environments, hosts, and applications. Information systems should be
monitored in order to detect, isolate, and react to intrusions, disruption of services, or other incidents that
threaten the security. Requirements and recommendations for audit should be created in alignment with the
security implications as well as the regulations and laws to which the organization are subject. A number of
laws, policies, and regulations compel organizations to store and review audit data
9
.
Security policy requirements also state that there be a way to collect and retain audit data to support foren-
sics and incident response relating to misuse, penetration, reconstruction, or other investigations. During a
forensics investigation, law enforcement and analysts will need to rely on audit logs as a source of evidence.
Along with this, there must also be proof that a malicious person has not altered those logs and that the
8
Red Hat Enterprise Linux includes the openscap-utils package. This package is the Security Content Automation Protocol (SCAP)
toolkit based on the NSA/NIST OpenSCAP library (to include the Open Vulnerability and Assessment Language (oval), the eXtensible
Configuration Checklist Description Format (xccdf) the Commone Platform Enumeration (CPE), and the Common Vulnerability Scoring
System (CVSS). For more information on Open SCAP visit:
http://www.open-scap.org/doc/
9
Laws and Regulations: Commercial - FISMA, HIPAA, GLBA, SOX, PCI DSS // Government- CNSS Directive No. 502, DoD Directive 8500
Series, NSD 32, DCID 6/3, DOD 5200.
www.redhat.com
3
Using an open source framework to catch the bad guy
logs are creditable. Logs produced by a computer are not admissible as evidence unless it can be shown that
there is no reasonable ground for believing them to be inaccurate, and the computer was operating properly
during the collection of data. The log files cannot be tampered with, or they are not admissible as evidence.
This two-part whitepaper series covers the critical areas of information protection for Red Hat Enterprise
Linux 6:
• Part 1: Using the Red Hat Enterprise Linux Audit Sub Systems
for forensics and incident response to
meet security requirement objectives and goals. This section of the white paper closely follows and maps
NIST Special Publication 800-92
Guide to Computer Security Log Management
written by Karen Kent
and Murugiah Souppaya with RHEL 6 audit specifics.
• Part 2: Integrity checking with Red Hat Enterprise Linux 6,
which involves calculating a message
digest for each file and storing the message digest securely to ensure that changes to archived logs are
detected. A message digest (also called a digital signature) uniquely identifies data and has the property
that changing a single bit in the data causes a completely different message digest to be generated.
aboUt tHE aUtHoRS
norman mark st. laurent, principal author
Norman Mark St. Laurent is a Senior Solutions Architect on the Red Hat Federal Team. Early in his 20 year
Computer Security/Forensics career, Mr. St. Laurent evaluated HPUX 10.10 as a Senior Computer Scientist for
the Trust Technology Assessment Program (TTAP) (Prelude to Common Criteria). Norman was also a Senior
Network Intrusion Analyst and Senior Information Systems Security Engineer (ISSE) for the NSA. In addition,
he was a Senior Computer Forensics Examiner (Unix/Linux Lead) for the FBI’s Computer Analysis Response
Team, having worked hundreds of computer and network forensics cases using Red Hat Linux as his primary
platform.
shawn wells, technical editor
Shawn Wells is the Technical Director for the Intelligence Community on the Red Hat Federal Team.
steve gruBB, technical editor
Steve Grubb leads Red Hat’s security technologies team,which works on security certifications and guidance
and maintains many of the security tools that you find on Linux systems, including the Audit Sub System. He
has worked on Linux security for over 10 years, mostly on flaw discovery and repair for many of the impor-
tant programs in use.
PaRt 1: oPERatIoNal USE of tHE RED Hat
ENtERPRISE lINUx 6 aUDIt
loG MaNaGEMENt INfRaStRUCtURE
The Red Hat Enterprise Linux 6
Auditing Sub System
provides kernel-resident logging of system calls and
user space tools to collect and view the logs, allowing for a means to provide both detailed and granular
forensics investigation as well as incident response. RHEL 6 allows for the capability to monitor real-time
occurrences of, or accumulation of, auditable events that may indicate an imminent violation of the security
policy.
4
www.redhat.com
Using an open source framework to catch the bad guy
In fact, the RHEL 6
Auditing Sub System is configurable to allow control over what specific information is
written to the logs. This information is useful in debugging security-related issues. The
auditd
daemon is
also used to log Security-Enhanced Linux (SELinux)
10
events. SELinux represents the culmination of nearly
40 years of operating system security research and provides a powerful, flexible, mandatory access control
mechanism to RHEL 6. SELinux generates audit messages at system initialization, policy load, and when
Boolean state are changed. These SELinux logs and the log management facility of
auditd
allow for security
relevant events to be secure, reliable, fine grained, and configurable, with a variety of uses including:
•
postmortem analysis,
•
intrusion detection, and
•
live system monitoring and debugging.
RHEL 6 audit logs are most useful for identifying or investigating suspicious activity involving a particular
host. The audit logs can be consulted to get more information on a specific activity and allow an event to be
investigated at a more granular level. Built-in audit utilities such as
aureport, ausearch,
and
aulast
enable
an organization to view the audit log information in detail for analysis. These tools are very powerful and in
combination with shell scripting and the
cron
11
facility can be very powerful as we’ll show later in this white-
paper. RHEL 6 also comes with the
audit-viewer
tool. The
audit-viewer tool is a Graphical User Interface
(GUI) for viewing and summarizing events collected by the audit subsystem (see Figure
1: The audit-
viewer GUI
and
Figure 2:The audit-viewer GUI with options shown).
The RHEL 6 Auditing Sub System also has the ability to monitor
tty
12
logging that will log all
tty
sessions
(keystrokes) via the
pam_tty_audit PAM
13
module. The
pam_tty_audit PAM
module is used to enable
or disable
tty
auditing. When
tty
auditing is enabled via this
PAM
module, it is inherited by all processes
started by that user. Daemons restarted by a user will still have this specific keystroke auditing enabled. In
the
session
section of the
/etc/pam.d/system-auth file you need to add the following line as shown
in
Table 2: /etc/pam.d/system-auth pam_tty_audit addition
to monitor all keystrokes the
root
user has entered. It is recommended to use the
disable=* as the first option so that will turn off audit tty
input
for all users except for the
root
user, whose we turn on with the
enable=root
option. Once set up, the
keystroke monitoring can be audited, and the data that was logged by the kernel can be seen by using the
aureport
command (see
Table 3:Reviewing keystroke captures with aureport).
In the
aureport
command we added the
-ts today
option to print out all keystrokes captured for the current day.
Table 2: /etc/pam.d/system-auth pam_tty_audit addition
/etc/pam.d/system-auth pam_tty_audit addition
Session
required pam_tty_audit.so disable=* enable=root
Table 3:
Reviewing keystroke captures with aureport
/etc/pam.d/system-auth pam_tty_audit addition
#aureport --tty -ts today
10
SELinux is developed by the National Security Agency (NSA), Red Hat, and the open source community.
11
The
cron
daemon is used to execute scheduled commands.
12
tty
– serial terminal lines.
13
PAM
is a system of libraries that handle the security tasks of applications on the system. The library provides a stable application
programming interface that privileged granting programs defer to for specific security tasks.
www.redhat.com
5

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin