• No results found

Configuring Logging. IT 4823 Information Security Administration. How Long Must Logs Be Maintained. Determining What Should Be Logged

N/A
N/A
Protected

Academic year: 2021

Share "Configuring Logging. IT 4823 Information Security Administration. How Long Must Logs Be Maintained. Determining What Should Be Logged"

Copied!
11
0
0

Loading.... (view fulltext now)

Full text

(1)

IT 4823

Information Security Administration

Logging and Auditing

June 23

Copyright © 2007 by Bob Brown

Notice: This session is being recorded.

Configuring Logging

• To configure logging, you should be prepared

to answer the questions

• What activities/events should be logged? • How long should logs be maintained? • What events should trigger immediate

notifications to security administrators?

• Logging must be configured to the needs of

the organization

Determining What Should Be Logged

• You can’t log everything

• Unless you have a lot of time and resources • Someone must review logs

• Logging has a negative effect on system performance • Critical events may be overwritten

• A prudent approach is to strike a balance

between logging important events but not

everything

• What is an important event is defined by the

environment to some degree and should be given

careful consideration

How Long Must Logs Be Maintained

• Most operating systems allow you to overwrite

log files based on time or file size

• This choice may be determined by policy, e.g., log files might be kept for a certain amount of time

• Log files can be archived

• You may need to maintain a (semi-) permanent record of system activity

• Back up log files before they are overwritten • A common method is to alternate two (or more) log

files, backing up one file while the other is active

Configuring Alerts

• With modern operating systems, you can set

up alerts that notify administrators when

specific events occur. (Add-ons required.)

• Alert options include:

• E-mail, pagers, Short Message Service (SMS), instant messaging, pop-up windows, and cell phones

• Typically alerts can be configured differently

depending on the severity of the event and the

time of day.

Windows Logging

• Windows uses the Event Viewer as its primary

logging mechanism

(2)

Windows Security Log

• Security log

• Records security-related events • Controlled by a system administrator

• Typical information includes failed logon attempts and attempts to exceed privileges

Windows Application and System Logs

• Application log

• Records events triggered by application software • System administrators have control over what

events to store

• System log

• Contains events recorded by the operating system • The system administrator generally has no control

over this log

• Typical events include hardware/software problems

Specialized Log Files

• Directory service log

• File replication service log

• DNS server log

Windows Log Events

• Error events are created when a serious

problem occurs (corruption of a file system)

• Warning events are created to alert

administrators to potential problems (a disk

nearing capacity)

Windows Log Events

• Informational events are details of some

activity that aren’t indications of a problem

(starting or stopping a service)

• Success/failure auditing events are

administrator-defined events that can be

logged when they succeed, when they fail, or

both (unsuccessful logon attempts)

Unix Logging

The primary log facility in Unix is syslog

• Very flexible, many options for notification and

priority

• Can write to a remote log file allowing the use of dedicated syslog servers to track all activity on a network

(3)

Unix Log Levels

Syslog implements eight priority levels:

• LOG_EMERG (emergency),

• LOG_ALERT (require immediate intervention), • LOG_CRIT (critical system events),

• LOG_ERR (error),

• LOG_WARNING (warn of potential errors), • LOG_NOTICE (information, no error), • LOG_INFO (informational),

• LOG_DEBUG (developers use for debugging)

Different actions are possible based on level.

Analyzing Log Data

• Log data is used to monitor your environment

• Two main activities

• Profiling normal behavior to understand typical system behavior at different times and in different parts of your business cycle

• Detecting anomalies when system activity significantly deviates from the normal behavior you have documented

Log File Monitors

• A log file monitor (LFM) is similar to NIDS • Reviews log files generated by servers, network

devices, and even other IDSs for patterns and signatures

• Patterns that signify attack may be much easier to identify when entire network and its systems are viewed holistically

• Requires allocation of considerable resources since it will involve the collection, movement, storage, and analysis of large quantities of log data

Profiling Normal Behavior

• A “snapshot” of typical system behavior is

called a baseline

• Baselines can be obtained at the network,

system, user, and process level

• Baselines measure application of system

resources

• Baselines will vary significantly based on

time of day or business cycle

• It is the administrator’s responsibility to

determine the baseline studies appropriate for

an organization; these will change over time.

Detecting Anomalies

• Define anomalies based on thresholds

• The following questions must be answered

• How much of a deviation from the norm represents an anomaly?

• How long must the deviation occur before registering an anomaly?

• What anomalies should trigger immediate alerts?

• Anomalies can occur at any level

• For example, if a user’s behavior deviates from normal, it may indicate a serious security event

Data Reduction

• When possible, limit the scope of logging

activities to that which can reasonably be

analyzed

• However, regulations or policies may stipulate that aggressive logging is necessary

• Data reduction tools are useful when more

data is collected than can be reviewed

• Often built into security tools that create log files • For example, CheckPoint’s Firewall-1 allows you

to view log files filtered by inbound TCP traffic to a specific port on a specific date

(4)

Artificial Stupidity

The opposite of “artificial intelligence,” sort-of Describe, and then filter out, those things that are not interesting.

What is left is either interesting, or should be added to the filters.

Maintaining Secure Logs

• Logs themselves must be protected from

tampering and corruption

• Common techniques to secure logs include

• Remote logging uses a centralized, highly

protected, storage location

• Printer logging creates a paper trail by immediately printing logged activity

• Cryptographic technology digitally signs log files to ensure that changes can be detected, though the files are vulnerable until they are finalized

Conducting a Security Audit

• Security professionals examine the policies and

implementation of the organization’s security

posture

• Identify deficiencies and recommend changes

• The audit team should be well trained and

knowledgeable

• The team may be multidisciplinary including accountants, managers, administrators, and technical professionals

• Choose a team based on your organization’s needs

Checklists

• Checklists provide a systematic and

consistent approach to completing various

tasks in an audit

• Audit checklists provide

• a high-level overview of the overall audit process • stepwise processes for auditing different classes of

systems

• Configuration checklists contain specific configuration settings

• Vulnerability checklists contain lists of critical vulnerabilities for each operating system in use

IP/Port Scanners

• IP/Port scanners are used by both crackers and

system administrators

• Use brute-force probing of IP addresses to identify open ports running services that may be vulnerable • Administrators can use this information to find rogue

systems and services

• Often set up by legitimate users who want to bypass the red tape of going through administration

• Rogue systems and services are usually either removed or brought under administrative control

Vulnerability Scanners

• Vulnerability scanners are software

applications that analyze systems for known

vulnerabilities and create reports and

suggestions

(5)

Vulnerability Scanners

• First vulnerability scanner was SATAN in the

early 1990s

• Newer scanners include

• SARA – a descendant of SATAN (Unix) • SAINT – a commercially supported scanner

(Unix)

• Nessus – provides a scripting language for writing and sharing security tests (Unix) • Microsoft Baseline Security Analyzer – free from

Microsoft, downloads the most recent vulnerability database (Windows)

Scanning and Analysis Tools

• Typically used to collect information that

attacker would need to launch successful

attack

• Attack protocol is series of steps or processes

used by an attacker, in a logical sequence, to

launch attack against a target system or

network

• Footprinting: the organized research of

Internet addresses owned or controlled by a

target organization

Scanning and Analysis Tools

• Fingerprinting: systematic survey of all of

target organization’s Internet addresses

collected during the footprinting phase

• Fingerprinting reveals useful information

about internal structure and operational

nature of target system or network for

anticipated attack

• These tools are valuable to network defender

since they can quickly pinpoint the parts of

the systems or network that need a prompt

repair to close the vulnerability

Port Scanners

• Tools used by both attackers and defenders to

identify computers active on a network, and

other useful information

• Can scan for specific types of computers,

protocols, or resources, or their scans can be

generic

• The more specific the scanner is, the better it

can give attackers and defenders useful

information

NMap

nmap -sS -O -F -v –v 168.28.178.212

Starting nmap 3.75 ( http://www.insecure.org/nmap/ ) at 2005-10-17 17:20 EDT

Initiating SYN Stealth Scan against webdev.SPSU.edu (168.28.178.212) [1221 ports] at 17:20

Discovered open port 80/tcp on 168.28.178.212 Discovered open port 22/tcp on 168.28.178.212 Discovered open port 443/tcp on 168.28.178.212 Discovered open port 21/tcp on 168.28.178.212 Discovered open port 23/tcp on 168.28.178.212 Discovered open port 3052/tcp on 168.28.178.212 Discovered open port 3128/tcp on 168.28.178.212

NMap

Interesting ports on webdev.SPSU.edu (168.28.178.212):

(The 1214 ports scanned but not shown below are in state: filtered)

PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 23/tcp open telnet 80/tcp open http 443/tcp open https 3052/tcp open PowerChute 3128/tcp open squid-http

(6)

Operating System Detection Tools

• Detecting a target computer’s operating

system (OS) can be very valuable to an

attacker

• There are many tools that use networking

protocols to determine a remote computer’s

OS

NMap

Device type: general purpose Running: Linux 2.6.X OS details: Linux 2.6.7 - 2.6.8 OS Fingerprint: TSeq(Class=RI%gcd=1%SI=324466%IPID=Z%TS=1000HZ) T1(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW) T2(Resp=N) T3(Resp=N) T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=) T5(Resp=N) T6(Resp=N) T7(Resp=N) PU(Resp=N)

TCP Sequence Prediction: Class=random positive increments

Difficulty=3294310 (Good luck!)

Firewall Analysis Tools

• Several tools automate remote discovery of

firewall rules and assist the administrator in

analyzing the rules

• NMap • Firewalk • NEWT

Firewall Analysis Tools

• Administrators who feel wary of using same

tools that attackers use should remember:

• It is intent of user that will dictate how information gathered will be used

• In order to defend a computer or network well, necessary to understand ways it can be attacked

• A tool that can help close up an open or

poorly configured firewall will help network

defender minimize risk from attack

Vulnerability Scanners

• Active vulnerability scanners scan networks

for highly detailed information; initiate traffic

to determine holes

• Passive vulnerability scanners listen in on

network and determines vulnerable versions

of both server and client software

• Passive vulnerability scanners have ability to

find client-side vulnerabilities typically not

found in active scanners

(7)

Packet Sniffers

• Network tool that collects copies of packets

from network and analyzes them

• Can provide network administrator with

valuable information for diagnosing and

resolving networking issues

Packet Sniffers

• In the wrong hands, a sniffer can be used to

eavesdrop on network traffic

• To use a packet sniffer legally, administrator

must be on a network that the organization

owns, be under direct authorization of owners

of network, and have knowledge and consent

of the content creators

Wireless Security Tools

• Organization that spends its time securing

wired network and leaves wireless networks

to operate in any manner is opening itself up

for security breach

• Security professional must assess risk of

wireless networks

• A wireless security toolkit should include the

ability to sniff wireless traffic, scan wireless

hosts, and assess level of privacy or

confidentiality afforded on the wireless

network

Wireless Security Considerations

• Should be easy to reach for users

• Potentially accessible to outsiders

• Consider a separate firewall

• Consider VPN

• Identification and authentication

• MAC address

• RADIUS/TACACS • VPN

Integrity Checking

• Integrity checking

• Maintains cryptographic signatures of all protected files to catch tampering • Tripwire is the most common tool for file

integrity assurance

• Typically used to protect static Web sites and other systems that store critical data that is infrequently changed

Penetration Testing

• Penetration testing is a proactive approach

used by security auditors

• The auditor tries to break in to the system to

find vulnerabilities

• Many security teams bring in professionals to

conduct penetration testing

• Called “white hat” hackers

• Malicious hackers are called “black hat” hackers

• Be sure you have proper permission before

(8)

Penetration Testing

• Testing to verify that a system satisfies certain constraints

• Hypothesis stating system characteristics, environment, and state relevant to vulnerability • Result may be a compromised system state • Apply tests to try to move system from state in

hypothesis to compromised system state

Note Well!

• Penetration testing is a testing technique, not a verification technique

• It can prove the presence of vulnerabilities, but not the

absence of vulnerabilities

• For formal verification to prove absence, proof and preconditions must include all external factors • Realistically, formal verification proves absence of

flaws within a particular program, design, or environment and not the absence of flaws in a computer system (think incorrect configurations, etc.)

Penetration Studies

• Test for evaluating the strengths and effectiveness of all security controls on system

• Also called tiger team attack or red team attack • Goal: violate site security policy

• Not a replacement for careful design, implementation, and structured testing • Tests system in toto, once it is in place

• Includes procedural, operational controls as well as technological ones

Goals

• Attempt to violate specific constraints in security and/or integrity policy

• Implies metric for determining success • Must be well-defined

• Example: subsystem designed to allow owner to require others to give password before accessing file (i.e., password protect files)

• Goal: test this control

• Metric: did testers get access either without a password or by gaining unauthorized access to a password?

Goals

• Find some number of vulnerabilities, or vulnerabilities within a period of time

• If the vulnerabilities are categorized and studied, can draw conclusions about care taken in design, implementation, and operation

• Otherwise, the list is helpful in closing holes but not more

Layering of Tests

1. External attacker with no knowledge of system • Locate system, learn enough to be able to access it 2. External attacker with access to system

• Can log in, or access network servers • Often tries to expand level of access 3. Internal attacker with access to system

• Testers are authorized users with restricted accounts (like ordinary users)

(9)

Flaw Hypothesis Methodology

1. Information gathering

• Become familiar with system’s functioning 2. Flaw hypothesis

• Draw on knowledge to hypothesize vulnerabilities 3. Flaw testing

• Test them out 4. Flaw generalization

• Generalize vulnerability to find others like it 5. (maybe) Flaw elimination

• Testers eliminate the flaw (usually not included)

Information Gathering

• Devise model of system and/or components

• Look for discrepancies in components • Consider interfaces among components

• Need to know system well (or learn quickly!)

• Design documents, manuals help

• Unclear specifications often misinterpreted, or interpreted differently by different people • Look at how system manages privileged users

Flaw Hypothesizing

• Examine policies, procedures • May be inconsistencies to exploit

• May be consistent, but inconsistent with design or implementation

• May not be followed • Examine implementations

• Use models of vulnerabilities to help locate potential problems

• Use manuals; try exceeding limits and restrictions; try omitting steps in procedures

Flaw Hypothesizing

• Identify structures, mechanisms controlling system • These are what attackers will use

• Environment in which they work, and were built, may have introduced errors

• Throughout, draw on knowledge of other systems with similarities

• Which means they may have similar vulnerabilities • Result is list of possible flaws

Flaw Testing

• Figure out order to test potential flaws • Priority is function of goals

• Example: to find major design or implementation problems, focus on potential system critical flaws • Example: to find vulnerability to outside attackers, focus

on external access protocols and programs • Figure out how to test potential flaws

• Best way: demonstrate from the analysis

• Common when flaw arises from faulty spec, design, or operation

• Otherwise, must try to exploit it

Flaw Testing

• Design test to be as little intrusive as possible • Must understand exactly why flaw might arise • Procedure

• Back up system

• Verify system configured to allow exploit

• Take notes of requirements for detecting flaw

• Verify existence of flaw

• May or may not require exploiting the flaw

• Make test as simple as possible, but success must be convincing

(10)

Flaw Generalization

• As tests succeed, classes of flaws emerge • Example: programs read input into buffer on stack,

leading to buffer overflow attack; others copy command line arguments into buffer on stack ⇒ these are vulnerable too

• Sometimes two different flaws may combine for devastating attack

• Example: flaw 1 gives external attacker access to unprivileged account on system; second flaw allows any user on that system to gain full privileges ⇒ any external attacker can get full privileges

Output of Network Scan

ftp 21/tcp File Transfer

telnet 23/tcp Telnet

smtp 25/tcp Simple Mail Transfer finger 79/tcp Finger

sunrpc 111/tcp SUN Remote Procedure Call exec 512/tcp remote process execution (rexecd) login 513/tcp remote login (rlogind)

shell 514/tcp rlogin style exec (rshd) printer 515/tcp spooler (lpd)

uucp 540/tcp uucpd

nfs 2049/tcp networked file system xterm 6000/tcp x-windows server

Output of sendmail

220 zzz.com sendmail 3.1/zzz.3.9, Dallas, Texas, ready at Wed, 2 Apr 97 22:07:31 CST

Version 3.1 has the “wiz” vulnerability that recognizes the “shell” command … so let’s try it

Start off by identifying yourself

helo xxx.org

250 zzz.com Hello xxx.org, pleased to meet you

Now see if the “wiz” command works … if it says “command unrecognized”, we’re out of luck

wiz

250 Enter, O mighty wizard!

It does! And we didn’t need a password … so get a shell

shell #

And we have full privileges as the superuser, root

Debate

• How valid are these tests?

• Not a substitute for good, thorough specification, rigorous design, careful and correct implementation, meticulous testing

• Very valuable a posteriori testing technique

• Ideally unnecessary, but in practice very necessary

• Finds errors introduced due to interactions with users, environment

• Especially errors from incorrect maintenance and operation

• Examines system, site through eyes of attacker

Problems

• Flaw Hypothesis Methodology depends on

caliber of testers to hypothesize and

generalize flaws

• Flaw Hypothesis Methodology does not

provide a way to examine system

systematically

• Vulnerability classification schemes help here

Vulnerability Classification

• Describe flaws from differing perspectives • Exploit-oriented

• Hardware, software, interface-oriented • Goals vary; common ones are:

• Specify, design, implement computer system without vulnerabilities

• Analyze computer system to detect vulnerabilities

• Address any vulnerabilities introduced during system operation

(11)

RISOS Classification Scheme

• Incomplete parameter validation • Inconsistent parameter validation

• Implicit sharing of privileged/confidential data • Asynchronous validation/inadequate serialization • Inadequate identification / authentication /

authorization

• Violable prohibition/limit • Exploitable logic error

Legacy of RISOS

• First funded project examining vulnerabilities • Valuable insight into nature of flaws

• Security is a function of site requirements and threats

• Small number of fundamental flaws recurring in many contexts

• OS security not critical factor in design of OSes • Spurred additional research efforts into detection,

repair of vulnerabilities

Audit Results

• The job doesn’t end with the audit

• Common post-audit tasks include

• Reporting results

• Prioritizing deficiencies that were found • Developing action plans for deficiencies • Implementing action plans based on priority and

complexity

• Conducting ongoing monitoring • Repeating the audit on a periodic basis

Break

References

Related documents