Tài liệu Windows Auditing docx

Trang 1

Windows Auditing

Security Essentials The SANS Institute

Greetings! This section of the course covers auditing Windows as a method of verifying that your computer systems remain secure One of the key concepts that we have emphasized throughout this course is in order to have a secure system you must know your system If you do not understand what is running on your system, how will you be able to secure it? In this module, we give you the information and tools you need to “know thy systems” and therefore secure them

Trang 2

4 - 2

Are Cheap Audit Tools a

• Can be an effective way to better

understand your environment

So why have a class on using cheap/free tools to audit a Windows system when there are so many commercial products available? Not all of us work for organizations that can afford the expensive license fees that typically go along with commercial auditing products While a $200-$1200 license fee may be feasible when you are talking about a few servers, what if you have hundreds of

workstations you need to audit as well?

The trade off with using cheap tools is that you usually end up with a more labor-intensive auditing process Instead of a single GUI interface that generates pretty management pie charts, you end up using multiple tools to collect raw data and then end up parsing it yourself We’ll address this point

at the end of the course when we talk about scripting and automating the audit process There are some tricks you can use to save some time Ultimately, however, you will end up having to manually review some portion of the audit data you have generated

This is not necessarily a bad thing One of the problems with a commercial auditing tool is they tend

to hide exactly what is going on in the background By performing a more hands-on audit you will ultimately gain a better understanding of how your systems operate

Trang 3

What You Will Need

• Windows NT 4.0 or 2000

• Copy of the Windows Resource Kit

– carried by most major book stores – subset of tools available for download – www.microsoft.com/windows/default.asp

• Set of free tools from NTObjectives (now

Trang 4

4 - 4

List of Resource Kit Tools

–dumpel.exe –netsvc.exe –adduser.exe –sysdiff.exe –regdmp.exe –xcacls.exe –perms.exe

Many of the tools covered in this class are part of the Windows Resource Kit This slide shows a list

of the files you will want to retrieve from the Resource Kit CD-ROM In fact, many of them have been updated since the Resource Kit’s release, so it’s a good idea to check the Microsoft FTP site (ftp://ftp.microsoft.com/reskit/) to see if updates are available

When using these tools on your own system, you may wish to copy these files into a directory that is already in your path Or, if you install the full Resource Kit, you may wish to include the install directory in your path statement This way you do not have to go digging for the files later

However, be sure to set appropriate NTFS permissions on your Resource Kit files and directories so that only authorized users can access them The Windows Resource Kit has also earned the nickname

“Windows Root Kit” because some of these tools can also be useful to attackers

Trang 5

List of Freeware Tools

• NT Objectives (now Foundstone):

–NTLast –afind.exe (from Forensic Toolkit) –sfind.exe (from Forensic Toolkit) –hfind.exe (from Forensic Toolkit)

Trang 6

4 - 6

What is an Audit?

• Verification of system integrity

• Augment other security precautions

– Security is not one stop shopping!

• Does not prevent intrusions!

– Provide clues when it occurs – Help raise security awareness

• Last line of defense

An audit, simply put, is the verification of the integrity of a system When you perform an audit, you are ensuring that only authorized access has taken place and that all changes made to the system are

in accordance with your security policy

Auditing should not be considered a replacement for the other security precautions you currently enforce on your network For example, don’t throw away your password policy just because you are performing regular audits The old analogy is that security should be like an onion with your data tucked safely away at the center Think of your security measures as being the different layers of the onion The more layers you have in place, the safer your data will be Auditing is simply one of these layers

Its important to keep in mind that auditing does not directly prevent people from attacking your system It is more of a last line of defense when all other security precautions fail What this means

is that auditing itself will not keep an attacker from entering your system, but it will surely help you find clues to help discover when, how, where, and perhaps who has penetrated your defenses and gained unauthorized access For example, a strong password policy may help keep an intruder out But if an intruder is able to get into your system despite your strong password policy, auditing will help you to detect that fact

Auditing is also a very good way of becoming aware of what is “normal” activity for your systems For example, try the exercise shown in the next slide

Trang 7

How Well do you Know your

own System?

• Open a command prompt

• Type: netstat -a |more

• Look for lines marked “listening”

• These are open service ports

• Can you identify them all?

In this exercise I want you to open a command prompt on the computer you are currently using To open a command prompt, go to Start → Run and type cmd.exe At the command prompt, type the command:

netstat –a | more

and then press the “Enter” key

Now, take a good look at the output being reported This is the current connection table for your system The local address column will show the communication port your system is using, while the foreign address column will identify the name of the remote system as well as the communication port that system is using If you look at the state column, any connections listed as “established” are active connections You may also see a few “time wait” or “syn sent” entries

The real interesting entries are the ones labeled “listening” These are open service ports on your system which are waiting for a remote system to connect to your machine In other words, there is some active process running on your system that is offering services to any system on the network that tickles this port The $64,000 question is, “Can you identify each of the processes running on your machine that have opened each of the listed listening ports?”

Trang 8

4 - 8

Why is TCP/2251 Open?

Auditing forces you to figure out what’s going on

If you take a look at the slide, you’ll see a screen capture from one of my systems This computer has four ports listed as “listening” The last three are used by Windows for file and print sharing but the first entry is an odd ball I am unaware of any process running on this system that should be listening on TCP port 2251 So why is this port open? Obviously I need to do some investigative work to find out exactly what is running on this machine

A great way to investigate is to go the IANA port assignments link and investigate what ports you are unfamiliar with:

listening on a few ports like 137, 138, and 139 This is how an attacker could find out that you had file sharing enabled on your PC or worse, your network server on a DMZ What better way to figure out all of the nuances of how your system functions and learn how to protect it better?

Trang 9

Why Perform Audits?

• Identify when an intrusion occurs

• Identify extent of the compromise

• Useful when all other security

measures fail

– Damage control – Document for corrective action and/or legal action

So, why perform audits? We perform audits to identify when an intrusion occurs If an intrusion is detected, our audit is used to then determine what portions of the system have been compromised For example, did the attacker load up a back door which is now waiting for them to come back in? Did the attacker change or access critical system or data files? In short, our audit should tell use the amount of damage control we need to perform

Trang 10

4 - 10

But I Have a Firewall!!!

• Most intrusions occur from within

• A strong security posture is layered

– Single point of failure is “a bad thing”

– Backup tapes are a form of layering

• FW-1 DNS hole

– www.securityfocus.com/archive/1/10972 – What about other products?

A common query that I hear is, “But I have a firewall Why do I need to perform audits?” To start, there have been quite a few studies that have looked at where attacks originate from; within the compromised network itself or from an outside location such as the Internet While the statistics vary from study to study, one common thread is that many attacks originate from inside the network perimeter From a statistical point of view, this means that your firewall has less than a 50% chance

of protecting you from possible attack Further, insider attacks have a higher rate of success because they are carried out by people with inside knowledge about (and often some level of existing access to) your systems, networks, and data

A good security posture is layered; this is also called “defense in depth”, which is learned early on

in the security process This is why we have a firewall, perform auditing, and perform, maintain, and test backups Firewalls are our first line of defense, auditing could be our next line of defense, and if damage is done and it cannot be fixed, then we can use our backups to restore the system to its original state We can also use backups to preserve the data for the incident handling team

With backups, it’s not that we need to keep track of yet another copy of our data Instead we are hedging our bets against hard disk failure, end user mistakes or carelessness, as well as a host of other potentially lethal situations So, by auditing and performing backups, we are “backing up” the other security measures we have put into place, including the firewall Again, remember this as being

a “defense in depth” situation

One last point on why layered security is important before we move on Go to the URL indicated in the slide that discusses the Checkpoint Firewall-1 “Invisible Traffic Due to Default Properties Setting” vulnerability This page documents a security hole with Firewall-1 which showed up in version two and still exists in version four In short, the default settings of the firewall allow an attacker to pass traffic to internal systems and not have any of the traffic show up in the logs

Trang 11

Hits Behind the Firewall

The Security Logging

tab of Windows XP’s

firewall allows you to

log hits.

What does it mean if

your system gets hit

behind your firewall?

Though personal firewalls have been covered in another section of Security Essentials, it wouldn’t hurt to consider what it means from an audit perspective if you find that a system behind the firewall

is showing signs of attack In this case, we see the default screen for the Windows XP personal firewall Note that the default behavior of the firewall is to deny and that you get to choose to select access On the next slide, titled Audit XP Firewall Logs, we will see the log format of this firewall

Trang 12

4 - 12

Audit XP Firewall logs

These are pretty standard fields for firewall logs The first two packets are ICMP type 8, code 0, this

is known as an echo request or more commonly, a ping packet Then we see TCP packets for port

445 This is standard Windows2000/Windows XP behavior (port 445 TCP and UDP, in addition to the standard ports 137 – 139, are used as part of NetBIOS in Win2K and WinXP) With these operating systems, Server Message Block (SMB) runs directly over TCP From an auditing

perspective then, this firewall gives us a lot of information about the packets that are hitting this computer’s network interface

Trang 13

What’s Makes a Good Audit?

You want to collect as much data as possible As an example, think about successful logons Logic tells us that if a potential intruder starts whacking away at the system with a dictionary attack, they are going to generate failed logon attempts So why not simply log failed logons instead of having to sort though all of the successful logons as well? As an example, let’s say you look at your log and see that someone has been beating up on Bob’s logon account There are quite a few failed logons that show up in the logs but these eventually stop If you are not tracking successful logon attempts

as well, you have no way of knowing if the attacker actually got in or decided to go play elsewhere

In other words, you know you’ve been attacked but you can’t say for sure whether the attacker actually got in

One thing to keep in mind when determining what information should be included in your baseline

is, how accurately can you verify the data? For example, file date and time stamps can easily be changed Log entries which are stored on a compromised system can also be changed This means that any information you derive from these sources should be considered questionable and verified through some other means

Trang 14

4 - 14

What Makes a Good Audit? (2)

• A written procedure

– scope, frequency, responsibility – What is considered “normal” data – What to do when intrusions are found – Detailed disaster recovery plan

– Could your boss follow the procedure and perform a good audit?

One component of a good audit is a well-documented procedure A procedure ensures that audits are performed in a consistent manner For example, you don’t want to find out later that Admin Mary takes the time to look at open/listening ports while Admin Bob does not bother Your procedure should clearly indicate what should be checked, how it should be checked, and how often Your written procedure should cover the following topics and ask the following questions:

Scope, Frequency, Responsibility: What is the scope of the auditing procedure? What should be

audited and when? Who has ultimate responsibility for the audit? Do you have a backup person who can perform the same audit?

What is Considered “Normal” Data: In order to know whether anything on your system has changed,

you need to know what the existing or “normal” state of your system is This may involve creating snapshots or baselines of different information about your system, and then re-baselining your system over time to see what may have changed

What to do When Intrusions are Found: The point in time when you find a problem is not the time

to decide what to do about it Make sure your policy states clearly what actions need to take place, and

in what order, including who to call, what to do, and what not to do.

Detailed Disaster Recovery Plan: If the worst happens and you have to rebuild from scratch, you need

to know how to do it This part of your document should contain detailed system configuration

information, a list of installed software, and any special instructions regarding configuration, load order,

or special procedures to restore from backup The specifics will vary based on your policies, the role of the server, etc., but the more detail the better The time when you’re really depending on your recovery

process is not the time to find out you don’t know how to do it, or that it doesn’t work.

Could Your Boss Follow the Procedure and Perform a Good Audit? The mark of any good written

procedure is that it is easy to follow If you can hand your audit procedure over to your boss and they can perform a successful audit, you know you are on the right track

Armed with this plan, you are well on your way to performing great auditing

Trang 15

What’s Included in a Good

Audit?

• As few clues as possible that

regular audits are performed

– Don’t leave tools on the system!

• Burn your tools to a CD

– Use a secured system for data review – Vary the times an audit is performed – Let your foe underestimate you

A good audit should leave as few clues as possible that a regular audit is being performed Armed with the knowledge of what you audit and how, a potential attacker will take steps to try to cover their tracks Obviously this is a bit of “security through obscurity” but the less information your attacker has, the more likely they will trip up and you will catch them

Also, make sure you secure the tools you use when performing your audits I personally like to burn

a CD-ROM which includes a copy of all my tools as well as the baseline for each of my machines This insures that I do not have to worry about an attacker replacing them with tools or data that will help to cover their tracks

Trang 16

4 - 16

What’s Included in a Good

Audit? (2)

• Who has accessed the system?

– Share access, Web, FTP, DNS, etc.

• What ports are being serviced?

• Additional services, drivers, or tasks

running on the machine?

• User/group or permission changes?

• Unexpected files/registry changes?

These are some of the types of information you may wish to include in your audit Obviously one of the first things you want to check is your access logs Don’t limit the scope to just your Windows Event Viewer logs Make sure you include the logs for any active service or application running on the machine; some of these will generate their own logs outside of Event Viewer (Internet

Information Server is a notable example) Remember that network services leave listening ports open, so any of these could be a potential portal into your machine

Trang 17

Working With Event Viewer

• Part of Administrative Tools group

• Central logging utility for Windows

– Not all applications use Event Viewer

• IIS logs to WINNT\system32\LogFiles

• Proxy logs to WINNT\system32\msplogs

• Windows does minimal logging by

default and saves minimal data

It is now time to get into the nitty-gritty of performing our audit by looking at the Windows Event Viewer utility Event Viewer can be found in the Administrative Tools group of your Windows system (Start → Programs → Administrative Tools → Event Viewer) It is an MMC snap-in under Windows 2000, and a stand-alone utility in Windows NT Event Viewer is the central logging utility

of any Windows system Most applications, including the operating system itself, log events to one

of Event Viewer’s three default logs These logs are System, Security, and Application Obviously

most of the information we will be working with shows up in the security log Windows 2000 Server

systems add specific logs for DNS (if installed) and Directory Services (if installed), but for our

purposes we’ll focus on the first three

One of the problems with Windows is that the default log settings are pretty poor The Security log

is not even enabled by default In addition, the default log size and log behavior are set to record only a minimal amount of data The default log size is only 512KB, and the default behavior is for Windows to overwrite log data that is more than seven days old if the logs are not cleared

You will want to adjust these settings based on the amount of data you log on a regular basis (log size) and how frequently you archive the log files (overwrite behavior) If you find the default settings are inappropriate for your environment, then from the Event Viewer select the log you want

to modify, and select Action, Properties from the menu (File, Properties in Windows NT) This will produce a dialog box similar to the one shown in the next slide

Trang 18

4 - 18

Windows 2000 Log Properties

One of the first things I like to do is bump up the maximum size of each of the logs to 8 MB Disk space is cheap What better way to use it than to keep track of your system’s health? Note that when you change the log size it only effects a single log With NT this will be whichever log is shown in the “Change settings for” display With Windows 2000, it will be whichever log you had

highlighted prior to selecting Properties

Now take a look at event log wrapping By default, Windows will overwrite events older than seven days if the maximum log size is reached The “as needed” option will let Windows overwrite entries

as needed, regardless of how recent the log data is The last setting never overwrites entries and requires you to clear the log manually Which setting to use is a judgment call on your part

Obviously from a security perspective the “do not overwrite” setting is best

In Windows 2000, you can also set these parameters through the Domain Security Policy Group Policy Object

Trang 19

Windows NT Log Properties

The Windows NT log file settings dialog box has the same options as Windows 2000, though presented in a different format

Trang 20

4 - 20

How do you Enable Auditing?

Once you have your log settings tweaked, you will want to enable auditing Before you implement auditing, you should decide on an auditing policy that specifies the categories of security-related events that you wish to audit When Windows is first installed, all auditing categories are turned off

By turning on various auditing event categories, you can implement an auditing policy that suits the security needs of your organization With Windows 2000, you can also use the built-in security templates that are included as part of the Security Configuration and Analysis snap-in to the MMC Some of these templates include pre-configured audit settings

In Windows 2000, you configure auditing through the Local Security Policy (on a single system) or Group Policy (for multiple systems) (On Windows NT, go to User Manager and select Policies →Audit.) Once you are there, select the category of events that you would like to audit, and right click

it Select Security and a new dialog box will open with options to audit “success” and “failure” attempts on whatever you selected This is very similar to the NT version but again, it is located within the MMC and is much easier to manage

At a minimum, you will probably want to track logons and policy changes for both success and failure events

If you choose to audit object access as part of your audit policy, you must turn on either the “Audit directory service access” category (for auditing objects in Active Directory), or the “Audit object access” category (for auditing files, printers, registry keys) Once you have enabled the correct category, you must use each individual object's Properties to specify what type of access should be audited (read, write, delete, change permissions…), which users and groups should be audited, and whether to audit success or failure events, or both

Trang 21

Auditing Object Access

Once you have enabled auditing of object access, you must still configure the individual objects (files, folders, printers, etc.) to be audited This can be done for individual objects using Windows Explorer For configuring “bulk” audit settings for numerous files or folders on a single machine or across multiple machines, you may wish to use the Security Configuration and Analysis snap-in or the Group Policy tool to configure a template of your audit settings

To configure auditing of an individual object, do the following:

• Open Windows Explorer, and then locate the file or folder you want to audit

• Right-click the file or folder, click Properties, and then click the Security tab In Windows 2000, the default permissions (if any) for the object will be shown

• Click Advanced, and then click the Auditing tab (shown above) (For Windows NT, click the

“Audit” button on the Security tab to display audit settings.)

• To set up auditing for a new group or user, click Add

• Select the user or group that you wish to audit from the list, or type the name of the user or group

in the “Name” box Click OK to automatically open the Auditing Entry dialog box

• Use the Auditing Entry dialog box to specify the actions that you want to audit, and whether you want to audit successful access, failed access, or both Click OK when you are done

• Click Apply to save your settings

• To view or change auditing for an existing group or user, click the name, and then click View/Edit

• To remove auditing for an existing group or user, click the name, and then click Remove

Trang 22

4 - 22

Sample Event Viewer Security Log

Log events for an hour or more and you will quickly realize that Event Viewer is pretty, but not very functional It would be time consuming at best to attempt to track when people logon and logoff of the system, let alone ensure that you do not scan a record so quickly that you miss the fact that something nasty took place With this in mind, we need another method of viewing Event Viewer entries

Trang 23

Sample Output From ntlast

This slide shows a screen shot of NT Objectives’ (now Foundstone’s) NTLast being used to extract logon information from a Windows Server The first command (ntlast –r –not CBRENTON)

queries the system to find all remote logons (the -r switch) that were not performed using the

account cbrenton From left to right the columns are: logon name, the server the user connected

to, the system used to perform the logon, and the date/time the logon took place

The second command (ntlast –f) queries the local system for the last ten failed logon attempts Notice that we have one user (BADGUY) who has made a number of failed logon attempts to log in

to the system BABYLON from the system named HELLSFARR If we do not recognize this logon name as valid, we would then want to track down the system HELLSFARR to see who was using it

at midnight on the morning of March 8, 1999

Trang 24

4 - 24

Which Switches to Use

ntlast -m SERVER -f -n 500 > fail.txt ntlast -m SERVER -i -n 500 > con.txt ntlast -m SERVER -s -n 5000 > pas.txt

So, the first thing we will want to extract out of our logs is any failed logon attempts This is shown

in the first command The -m switch allows us to specify a remote server to query, while -f tells ntlast that we are interested in failed logon attempts The -n switch states that the tools should show the last 500 failed logons Unfortunately, there is not an “all” switch, so make sure you specify

a fairly high number Finally, we are piping the output from this command into a file named

fail.txt

In the second command we are extracting console or “interactive” logons and in the third command

we are grabbing successful logons Note that we are exporting the output to three different files so the data will be easier to review If we are querying multiple servers, we have two options We can create a different set of files for each server and name the files accordingly For example when recording failed logon attempts when we query the server FS1 we could name the file fs1-

fail.txt Another option is to simply log all failures to the same file If we do this the command should appear as follows:

ntlast -m SERVER -f -n 500 >> fail.txt

Note the double “greater than” signs This tells the system to append the output to the file

fail.txt If you use a single “greater than” sign, the file will be overwritten

Trang 25

Export the Logs to ASCII

• Use dumpel.exe or Somarsoft’s

DumpEvt to export the logs in

ASCII format

• This data can then be imported into

a spreadsheet or database for easy

sorting

dumpel -L security -f logon.txt -s SERVER -c

So now that we’ve extracted the logon information, we should get a full ASCII copy of the security log so that we can check it for other events We may even wish to correlate logoff information with some of the logons reported by NTLast in the last examples

The Windows Resource Kit includes a utility called dumpel.exe This utility can be used to export the contents of Event Viewer to an ASCII file Once we have exported the data, we can then import it into our favorite spreadsheet or database program From there, we can sort the data looking for interesting traffic or create pretty graphs for upper management

The bottom of the slide shows the syntax for using dumpel.exe The –L switch allows you to define which log you want to export The –f switch sets the name of the export file The –s switch defines the name of the remote system to query The –s switch is important because it allows you to use a batch file to quickly export the security logs from multiple systems on your network from a single location

Somarsoft’s DumpEvt utility (available free from SystemTools – www.systemtools.com/somarsoft) can also be used to export Event Viewer files into ASCII format for later import It provides greater flexibility than dumpel.exe during the export process, which may make it easier to import the files into an Access or SQL database for analysis It will also keep track of the last event exported, so you

do not export duplicate records

One limitation of both dumpel and DumpEvt is that they are unable to clear the logs once they have been exported For that we will need to use the tool NTOLog, which we will cover a bit later

Trang 26

4 - 26

Finding Data in the Logs

• Sort “reason” to look for failed

logon attempts

• Sort “workstation name” to look for

odd sources of logon

• Sort “Logon ID” to track sessions

• Hide acceptable entries to better

hone in on the good stuff

So now that we have exported our security log, let’s talk about a few tricks you can use to find interesting entries The first thing you can do is sort on the “reason” column This will allow you to quickly identify failed logon attempts A secondary sort on date/time will allow you to home in on brute force logon attacks

Since the security log can become quite large, a slick trick is to first go through looking for “normal” traffic and then hide it “Normal” is defined as entries you can easily identify which meet your

security policy For example the user khick logging on every morning at 8:00 AM and then logging off at 6:00 PM would be defined as normal if you know khick is a valid user account for a person

who works first shift You can then hide these entries in order to reduce the number of entries you must manually check for problems Note that I did not say ‘delete’ as you may find that you actually need these entries for further investigation You simply want to get these entries out of sight while you review the rest of your log

Trang 27

Reading the Logs

• Stock authentication package is

MICROSOFT_AUTHENTICATION_PACKAGE_V1_0

• Each session is tracked using a

unique Logon ID

– can be used to match logon/logoff

• See auditcat.hlp for more EV info

So what type of information should we be checking for in our Event Viewer logs? One of the first things you should check is the authentication package Unless you have changed it, this should read MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 If you see a different package, you need

to investigate

As mentioned in the last slide, you also want to keep an eye on the logon IDs When a user connects

to a Windows system, they are assigned a unique logon ID So while you may see 20 logon/logoff

records for the user gshaw, each set of two will use a unique logon ID to identify each time the user

logged on and then off of the system This can be extremely useful if you are trying to find a logoff time to correlate with the logon time reported by ntlast For example let’s say ntlast reported

that bsmith logged on the system at 1:15 AM and you want to find out when they logged off Simply

search the ASCII data for the logon date and time reported by ntlast When you locate the logon record, you can find out the assigned logon ID You can now search on the logon ID to find the

record for when bsmith logged off of the system.

In the next slide we’re going to talk about logon types, but I just wanted to mention before moving

on that the Resource Kit includes a file named auditcat.hlp which has a lot of really useful information regarding the data you will find in the Event Viewer logs

Trang 28

• 4 - Started by batch process

• 5 - Started by running service

• 6 - Proxy logon

• 7 - Unlock console (screen saver)

Every time a user logs on to the system, their connection will be identified with a logon type This

ID tells you what kind of connection the user made to the system For example, if you see a logon type of 2, this means the user logged on to the server from the system console A logon type of 7 tells you that the user logged on at the console, but the system was locked via a screen saver

password

The only logon type that I do not have a good description listed for is logon type 6, proxy logon This is because there appears to be zero information on this logon type It sounds like it would log connections via a proxy server, but I’ve tested this theory with Microsoft Proxy server only to find that connections through the proxy generate a logon type of 3, a standard network logon I have had one student tell me they have seen logon type 6 reported with MS Proxy, but I have not been able to duplicate these results

Trang 29

Clearing the Log

• NTOLog can be used to backup and

clear the Event Viewer log files

• Works with WinNT and Win2K

So we’ve extracted logon information and even saved a complete ASCII copy of the log file The only piece missing is to clear the log so that our next audit does not end up processing the same information For this task we can use the NTObjectives utility named ntolog Ntolog has disappeared from Foundstone’s web site, but can still be downloaded from Packetstorm

(www.packetstorm.securify.com)

ntolog is a log archiving utility Its designed to make a backup copy of the Event Viewer logs There are a couple of missing features that make this tool difficult to use for auditing purposes To start, it saves the log files in native EVT format This means that we can not parse and sort the files using a spreadsheet or database program Also, the tool is hard coded to save all log files to the local

\WinNT\system32\config directory This can make collecting log files from multiple systems a real pain

So while ntolog has its uses, its archive ability does not really lend itself to an audit situation What is helpful however is that the tool can be used to clear log files on remote machines This is a badly needed feature which is missing from dumpel By using the two commands together, we can backup our security log and clear all existing entries The series of commands would look something like this:

dumpel -L security -f fs1-sec.txt -s SERVER -c

Trang 30

4 - 30

Checking Other Logs

• Web access via IIS

Normal file retrieval:

For example check out the two log entries Do you notice something strange about the second entry?

In the first log entry, the remote system accessed the web server using a standard anonymous logon While this is not stated we know this to be true based on the “–” entry immediately following the remote system’s IP address In the second entry the word “Administrator” appears and indicates that the user at 192.168.1.53 attempted to authenticate through IIS with the Administrator account in order to access the secret_dir directory

Trang 31

Baseline of Listening Ports

At the beginning of this course, we went through the exercise of checking the listening ports on your local system As part of your baseline you will want to document which ports are normally listening

To do this simply run netstat again, except this time direct the output to a text file

Once you know what ports are open on your system, do a quick check of the port numbers to see if the well-known port numbers associated with them make sense For example if you run the

command on a web server, you would expect to see port 80 open, since that’s the well-known port for HTTP requests

You will also want to determine which process is listening on each port, to make sure that nothing suspicious is running on your system Unfortunately, there are no tools in either stock Windows or the Resource Kit to map open ports to the applications that are using them The tool FPort from Foundstone (www.foundstone.com) can be used to determine which process/executable is listening

on which port Inzider (http://ntsecurity.nu) will do the same thing, although Inzider is sometimes buggy

Of course it would be handy to know what services and drivers are running on the machine as well This procedure is covered in the next few slides

Tiêu đề	Windows Auditing Security Essentials
Trường học	The SANS Institute
Chuyên ngành	Computer Security
Thể loại	tài liệu
Năm xuất bản	2001

Định dạng
Số trang	62
Dung lượng	0,91 MB