Security Events
 

آگاهی داشتن از Attack به یک سرور بسیار برای یک Admin مهم می باشد .روشهای مختلفی وجود دارد که همه آنها به یک چیز وابسته می باشد

و آن هم Log می باشد سیستم Windows بر روی Domain دارای Log های مناسبی می باشد برای بررسی موارد خرابی سیستم و سرویس ها و

از جمله موارد حمله Attacker ها و هکرها .نرم افزار MOM 2005 بر روی DC در شبکه می تواند تمامی موارد مهم شبکه را برای Admin بصورت

گزارش نمایش دهد اما در اینجا ما فرض را بر این می گیریم که این نرم افزار را نداریم و می خواهیم از EventViewer سیستم استفاده

کنیم باید به چه نکاتی دقت کنیم برای بدست آوردن Log های Security سیستم .

   Figure 1: Security Log - Event IDs

    Figure 1: Security Log - Event IDs

شکل 1  یک سری از روش های ممکن برای Attack را نمایش می دهد .البته همیشه این روش ها حمله نمی باشد بلکه می تواند Log مربوط

به کار روزانه افراد باشد که به نادرست انجام  شده ....

برای شناسایی Attack به سیستم خود می توانید از Event Viewer سیستم استفاده کنید برای مثال در زیر به Account با نام های Damon_M و

Administrator حمله شده یا بهتر است گفته شود که سعی شده با  این Account ها به سیستم نفوذ کرد یا logon کرد حالا یا بصورت Locally

و با بصورت Remote ممکن است که خود مالک سیستم اشتباه PWD را وارد کرده باشد که در این صورت این Log نمی تواند نمایان کننده یک Attack

باشد .

   Figure 2: Audit Policy

    Figure 2: Audit Policy

قبل از شروع باید به این نکته توجه کرد که برای ایجاد Log های امنیتی بر روی Security در Event Viewer باید Audit Policy را فعال کرد.

همانند شکل 2.برای اطلاعات بیشتر درمورد Auditing بر روی آن کلیک کنید .

 

در مرحله بعد شما می توانید Security Log را بر روی Event Viewer داشته باشید .

   Figure 3: Event Viewer - Security Logs

    Figure 3: Event Viewer - Security Logs

همانند شکل 3 می توانید مواردی که با علامت قفل نمایان می باشد را مشاهده کنید که دارای Event ID 680;529 می باشند.

این Log ها نمایان کنند این میباشد که فردی  با برنامه و یا سرویسی بصورت Locally و یا Remote سعی کرده

از طریق یک Account به سیستم دسترسی داشته باشد اماموفق نشده.اگر بر روی یکی از آنها که دارای EventID 529 می باشد کلیک کنید

می توانید اطلاعات کاملتری بدست آورید همانند شکل 4.

    Figure 4: Event Viewer - Security Logs - Event ID 529 (Unknown User name or bad Password)

    Figure 4: Event Viewer - Security Logs - Event ID 529 (Unknown User name or bad Password)

دراینجا می توانید مشاهده کنید که Account Administrator مورد حمله قرار گرفته اما بدون نتیجه بوده چون برای مثال PWD درست را فرد

حمله کنند نداشته .اگر این Log ها بصورت پشت سرهم و بسیار زیاد باشد این نمایان کنند یک Attack خطرناک به این Account می باشد

در این مثال این عمل از طریق Client بنام DOTNETFX رخ داده که همان سیستم Local می باشد یعنی اینکه فردی برای مثال بصورت Localy

سعی کرده واردی سیستم شود در زمان Boot یا در زمان Look بودن Desktop و....

این نوع حمله می تواند در زمان Ctrl + Alt + Delete زمان Boot سیستم باشد و یا از طریق یک سرویس موجود بر روی سیستم شماو یا

سیستم هکر باشد و یا هکر توسط  یک Red Code این کار را بکند و سعی کند از طریق سیستم Remote به سیستم شما Logon کند  و....

برنامه هایی وجود دارد که می توانند در یک دقیقه بیش از 1 میلیون PWD برای سیستم هدف ارسال کنند تا PWD درست را پیدا کنند برای هر

بار حمله بک Security log با این id و این Category ایجاد می شود .البته برنامه جدید تر دیگر از این روش استفاده نمی کنند و با استفاده

از LM Hash ,NTLM Hash و Decode کردن آنها سعی می کنند که PWD را بدوست آورند وبا راهی برای نفوذ پیدا کنند که در این صورت شاید این

Log ایجاد نشود . به همین دلیل استفاده از NTLM V2 و استفاده از Policy های مربوط به آن مهم می باشد .

در پایین این صفحه می تواند لیست کامل انواع Security Log های مهم و خطرناک را مشاهده کنید .در Event Viewer می توانید با کمک Filtering

هر یک از Event ID را بر روی سیستم چک کنید.همانند شکل 5.

   Figure 5: Event Viewer - Security Logs - Filtering

    Figure 5: Event Viewer - Security Logs - Filtering

برای مثال در اینجا بهد از Right-click کردن بر روی Security Log می توانید مانند شکل 5 مشخص کنید که فقط Log هایی که EventID 529 دارند

را نمایش دهد .

برای اینکه بیشتر از قدرت Monitoring Log فایل ها مطلع شوید یک مثال دیگر زده می شود برای مثال یک User بنام 1 بر روی سیستم

شما بصورت قانونی Logon کرده اما سعی کرده که Security Log های سیستم را مشاهده کند و یا Clear کند بدلیل نداشتن اجازه Access به

این Object بر روی سیستم User 1 بعد از سعی برای این کار همانند شکل 6 یک Error دریافت کرده.شما به عنوان Administrator می توانید این

رویداد را که رخ داده را با دیدن Security Log با EventID 578 متوجه شوید و با User برخورد لازم را انجام دهید .

   Figure 6: Event Viewer - Security Logs - ( Current User "1" )

    Figure 6: Event Viewer - Security Logs - ( Current User "1" )

در شکل زیر می توانید این Security Log را مشاهده کنید که User 1 سعی کرده اما نتوانسته به Object دسترسی داشته باشد بدلیل نوع Type

Event که Failure Audit می باشد .

   Figure 7: Event Viewer - Event IDs 578

     Figure 7: Event Viewer - Event IDs 578

● 529 — logon failure (bad user name or password)
● 644 — a user account was auto locked
● 675 — pre-authentication failed on a DC (incorrect password)
● 676 — authentication ticket request failed
● 681 — logon failure

در زیر می توانید لیست کامل مواردی که بر روی Security Log می توان یافت را مشاهده کنید.

Table 4.1: File Permission Change Events
560  Access granted to existing object

These events show where an object has successfully granted
access to a request, such as list, read, create, and delete. Check
Primary Logon ID, Client User Name, and Primary User Name
fields to detect unauthorized attempts to change file permissions.
Check Accesses field to identify the operation type. This event
only shows that access was requested or granted—it does not
mean that the access took place. The acting user is the Client
User (if present); otherwise it is the Primary User.

567  A permission associated with a handle used

This event occurs on the first instance of an access type (list,
read, create, and so on) to an object. To correlate with event 560,
compare the Handle ID fields of the two events.

Table 4.2: Password Reset Events

627 Change Password Attempt

This event results from a password change request in which the
user supplies the original password to the account. Compare
Primary Account Name to Target Account Name to determine
whether the account owner or someone else attempted to change
the password. If Primary Account Name does not equal Target
Account Name, someone other than the account owner tried to
change the password. On computers that run Microsoft Windows
Me or Windows NT®, it is common to see Anonymous as the
account that requests the change. This is because the user might
not have been authenticated. However, the requestor had to supply
the old password, so this is not a significant security risk.

698 Change Directory Services Restore Mode Password

Records when someone attempts to change the Directory Services
Restore Mode password on a domain controller. Check
Workstation IP and Account Name and investigate immediately.

Table 4.3: User Account Change Events

624 Creating a user account

Only authorized people and processes should create network
accounts. Examine the Primary User Name field to detect
whether an authorized person or process created an account. This
event also detects if administrators create accounts outside
organizational policy guidelines.

642 Changing a user account

This event records changes made to security-related properties of
user accounts that events 627-630 do not cover.

685 Changing an account name

Verify that Primary Account Name corresponds to an authorized
person or process.

624 Creating a user account

Only authorized people and processes should create network
accounts. Examine the Primary User Name field to detect
whether an authorized person or process created an account. This
event also detects if administrators create accounts outside
organizational policy guidelines.

642 Changing a user account

This event records changes made to security-related properties of
user accounts that events 627-630 do not cover.

685 Changing an account name

Verify that Primary Account Name corresponds to an authorized
person or process.

Table 4.4: Group Membership Change Events

631 to 634 Security Enabled Global Group Changes
Examine this event for groups that have global or broad
access privileges, such as the Domain Admins group, to
ensure that no changes occur outside organizational policy
constraints. The group name is in the Target Account Name
field.


635 to 638 Security Enabled Local Group Changes
Examine this event for groups such as Administrators, Server
Operators, and Backup Operators to ensure that no changes
take place outside of policy constraints. The group name is in
the Target Account Name field.


639 641 668 Security Enabled Group Changes
These events indicate other changes to a group besides
deletion, creation, or membership changes. You should
examine these events for groups that have high privilege
levels to make sure that no changes take place outside policy
constraints. The group name is in the Target Account Name
field.


659 to 662 Security Enabled Universal Group Changes
Examine for groups that have high privilege levels, such as
Enterprise Admins or Schema Admins, to ensure that no
changes take place outside policy constraints. The group
name is in the Target Account Name field.

Table 4.5: Unauthorized Logon Events

528/540 Logon success Suspicious where Target Account Name equals the default
administrator account
. However, event 528 is a common
event in typical operational usage.


529 Logon failure — unknown user name or password
Check for attempts where Target Account Name equals
Administrator or the renamed default administrator account.
Check multiple logon failures that are below the account
lockout threshold.


531 Logon failure — disabled account
Always investigate this event. Check Target Account Name
value and Workstation Name. This event can signal
attempted abuse by former internal users.


532 Logon failure — expired account
Always investigate this event. Check Target Account Name
value and Workstation Name. This event can signal
attempted abuse by contractors or temporary internal users.


576 Special Privileges assigned to new logon
This event appears whenever a new logon session gains
privileges that could provide administrator access or tamper
with the audit trail. Correlate with event 528 or event 540 by
comparing the Logon ID field in the two events. Event 576 is
a quick way to check if an account obtained administrator
equivalence at logon time. This approach is easier than
trying to calculate group membership.

Table 4.6: Logon with Service Account Credentials Events

528 Logon Success – console attack or Terminal Services
If an event log records Event 528 for a service account or for
local system with logon type 2, an attack is in progress, the
attacker has obtained the password to the service account
and has logged on at the console. If an event log records
logon type 10, an attacker has used Terminal Services to
log on. In either case, you should investigate immediately.


534 Logon failure — logon type not allowed
Check Target Account Name, Workstation Name, and
logon type. This event indicates a failed attempt to log on
interactively with service account credentials when Group
Policy settings prevent that account from interactive logon.


600 Process was assigned a primary token
This event occurs when a service uses a named account to
log on to a computer that runs Windows XP or later.
Correlate this event with Events 672, 673, 528, and 592.


601 User attempts to install a service
This event should be a very rare occurrence because
installation of services is not an everyday action. You should
investigate all successes and failures for this event.

Table 4.7: Run Unauthorized Programs Events

592 Creating a new process
Check Image File Name and User Name for new
processes. All processes should be present on the
authorized programs list.


602 Creating a scheduled job
Check Target Name for authorization to run scheduled
processes and check Task Time for event correlation with
known task schedules.

Table 4.8: Access Attempts to Unauthorized Resources Events

560 Access refused to existing object
Monitor for audit failures. Look at the Object Name field for the
accessed resource. Correlate with Primary User Name and
Primary Domain fields or the Client User Name and Client
Domain fields.


568 Attempt made to create a hard link to an audited file
This event occurs when a user or program attempts to create a
hard link to a file or object. After a user creates a hard link, the
user can manipulate a file within that user's rights without
creation of an audit trail.

Table 4.9: Run Unauthorized Platform Events

529 Logon failure — unknown user name or password
Check for attempts where Target Account Name equals
Administrator and Domain Name is unknown or Target
Account Name equals root.


592 Creating a new process
Check Image File Name and User Name for new
processes. All processes should be authorized programs.

Table 4.10: Circumvent Auditing Events

512 Windows is starting up
Usually appears after Event 513. Investigate unexpected
restarts.


513 Windows is shutting down
Usually appears before Event 512
. On high-value
computers, authorized personnel should restart computers in
accordance with established policies. Investigate
immediately when this event occurs on any server.

516 Audit failure
This event can occur when too many security events
overwhelm the event log buffer. Limit the number of events
that you audit. This event can also occur if you configure the
security log not to overwrite. You must monitor computers
closely in areas where you must maintain high audit log
levels. Security settings can cause some computers to shut
down when the security logs fill up. Monitor event 516 on all
computers where security is of concern.


517 Clearing the security event logs
Administrators should not clear security event logs without
authorization. Check Client User Name and Client Domain,
then cross-correlate with authorized personnel.


520 Changing the system time
This action can mislead forensic investigation or provide an
attacker with a false alibi. The process name is %windir
%\system32\svchost.exe. Check Client User Name and
Client Domain, then cross-correlate with authorized
personnel.


521 Unable to log events
Windows is unable to write events to the security event log.
You should investigate this event immediately if it occurs on
high value computers.


608 A user account privilege was assigned
This action grants a new privilege to a user account. The
event log records this action along with the user account
Security Identifier (SID), not the user account name.


609 A user account privilege was removed
This action removes a user account privilege. The event log
records this action along with the user account SID, not the
user account name.

612 Changing audit policy
This event does not necessarily indicate a problem.
However, an attacker can change audit policy as part of a
computer system attack. You should monitor for this event
on high value computers and domain controllers.

621 System Access was granted to an account
A user was granted access to a system. Check User Name
and Account Modified, particularly if access permission is
interactive.

622 System Access was removed from an account
This event might indicate that an attacker removed evidence
of event 621, or is attempting to deny service to some other
account(s).

643 Changing the domain security policy
This event indicates an attempt to modify password policy or
other domain security policy settings. Check user name of
subject and correlate with authorization.

Table 4.11: Changing Trust Relationships Events

610  611  620  Trust relationship with another domain was created, deleted, or modified
These events appear on the domain controller on which the
trusted domain object is created. This event should generate
an alert and immediate investigation. Check User Name of
subject that carried out the trust operation.

Table 4.12: Policy Change Events

612 Changing audit policy
Identifies any change to audit policy. Correlate this event with
changes that authorized personnel make to system policy.


613  614  615 Changing IPSec Policy
Monitor these events and investigate any occurrences that are
outside system startups.

618 Encrypted Data Recovery Policy
If encrypted data recovery policy is in use, monitor for this
event and investigate any occurrences outside specified
policy.

Table 4.13: Attack Authentication Credentials Events

529 Logon failure — unknown user name or password
Check for attempts where Target Account Name equals
Administrator or the renamed default administrator account. Check
multiple logon failures that are below the account lockout threshold.
This event can indicate when an unauthorized individual attempts
to guess the local administrator password. Correlate Event 529
with Event 539 to identify a pattern of continuous account lockouts.

534 Logon failure — logon type not allowed
A user attempted to log on by use of a logon type that is not
allowed, such as network, interactive, batch, or service. Check
Target Account Name, Workstation Name, and logon type.

539 Account Locked out
A user attempted to log on to an account that has already locked
out. Correlate with Event 529 to detect a pattern of continued
lockouts.

553 Replay attack detected
This event occurs when the authentication package (usually
Kerberos) detects an attempt to log on by replay of a user's
credentials. Investigate immediately. Alternatively, this could be a
sign of incorrect network configuration.

627 Change Password Attempt
Compare Primary Account Name against Target Account Name
to determine if the account owner or someone else attempted an
account password change. If Primary Account Name does not
equal Target Account Name, this indicates that someone other
than the account owner tried to change the password.

628 User Account Password Set or Reset
Only authorized people or processes, such as help desk or user
self-service password reset, should perform this task. Investigate
this event immediately if this is not the case.

644 User AccountAutomatically Locked
A user account has locked out because the number of sequential
failed logon attempts is greater than the account lockout limit.
Correlate this event with Events 529, 675, 676 (Windows 2000
Server only), and 681. See also the entry in this table for Event 12294.


675 Preauthentication failed
Correlate with event 529 to find the additional reason for the logon
failure. Reasons can include time synchronization or computer
accounts that have not joined the domain correctly.


12294 Account lockout attempt
This event indicates a possible brute force attack against the
default Administrator account. Because this account does not lock
out, the system event logs records SAM event 12294 instead.
Investigate even a single occurrence of this event immediately,
because this can also indicate the presence of an unauthorized
operating system. Check Domain Name field for unknown
domains.

Table 4.14: Identifying Events from Exploiting Vulnerabilities by Escalating

528  538 Local Logon and Logoff
Local logons should be very rare on perimeter computers.
Correlate on Logon ID field. Investigate if unexpected values
for User Account Name, Time, or Workstation name.

576  Privileged Logon
In Windows Server 2003 with SP1 or later, this event indicates
an “administrator” logon: a logon with enough privilege to
tamper with the Trusted Computing Base (TCB) or take over
the computer. For earlier versions of Windows, this event is
only of interest if it contains a sensitive privilege such as
SeSecurityPrivilege or SeDebugPrivilege.

Table 4.15: Rootkit or Trojan Events

592 Creating a new process
Check Image File Name and User Name for new
processes. All processes should be authorized programs.

Table 4.16: Unauthorized Computer Usage Events
 

528  Successful Logon   . Check Workstation Name and then check User Account
Name.
Check that Source Network Address is within the
organization's IP address range.


530 Logon Failure — time restrictions
This event indicates an attempt to logon outside permitted
times. Check User Account Name and Workstation Name.

 

************

Exclude Unnecessary Events

Table A.1: Reducing Storage Load by Removing Events

538 User logoff

This event does not necessarily indicate the time
that the user stopped using the computer. For
example, if the user turns the computer off
without first logging off, or if the network
connection to a share breaks, the computer
might not record a logoff at all, or might record a
logoff only when the computer notices that the
connection is broken.


551 User initiates logoff Use Event 538, which confirms logoff instead.


562 A handle to an object closed Always records a success.


571 Client Context deleted by
Authorization Manager.
Normal where Authorization Manager is in use.


573 Process generates nonsystem audit
event with Authorization Application
Programming Interface (AuthZ API)
Typical behavior.


577  578 Privilege service called, privileged object operation
These high volume events typically do not
contain enough information either to understand
what happened or to act upon them.


594 A handle to an object was duplicated Typical behavior.


595 Indirect access to an object was obtained Typical behavior.


596 Backup of data protection master key Occurs automatically every 90 days with default settings.


597 Recovery of data protection master key Typical behavior.


624 642  Event 624 where User equals System, followed by 642 where Target Account Name equals IUSR_machinename or
This event sequence indicates that an administrator has installed IIS on the computer. IWAM_machinename and Caller
User Name equals machinename$.

624 630 642  User equals System and all three events have same time-stamp and
New/Target Account Name equals HelpAssistant and Caller User Name equals DCname$
This sequence is generated when an administrator installs Active Directory on a computer that runs Windows Server 2003.


624 or 642  User equals ExchangeServername$ and Target Account Name is a Globally Unique Identifier (GUID)
This event occurs when an Exchange Server first comes online and automatically generates system mailboxes.


624 Caller User Name is any user and New Account Name is machinename$
A user in the domain has created or connected a new computer account in the domain. This event is acceptable if users have the right to join
computers to a domain; otherwise you should investigate this event.


627 User equals System and Target Account Name equals TsInternetUser and Caller User Name is usually DCname$
These events result from the normal behavior of a computer that runs Terminal Services.


672 Kerberos AS Ticket request If you collect logon events 528 and 540 from all
computers, event 672 might not contain any additional useful information, as it just records
that a Kerberos TGT was granted. There must still be a service ticket granted (event 673) for any access to occur.


680 Account Logon If you collecting logon events 528 and 540 from all computers, event 680 might not contain any
additional useful information, because it just records validation of the account credentials. A separate logon event records what the user accessed.


697 Password policy checking API called Typical behavior.


768 Forest namespace collision Not security related.


769  770  771  Trusted forest information added, deleted or modified These events indicate normal operation of interforest
trusts. You should not confuse these with addition, deletion, or modification of the trust itself.

832 to 841  Various Active Directory replication issues No security implications.

 

*************************

Implement Group Policy Settings

Table B.1: Group Policy Security Audit Settings
 

1. Local Policies/ Audit Policy ==>  Audit account logon events
Enable audit success for all computers, as this event
records who accessed the machine. Enable audit failure
with caution as an attacker with network access but with
no credentials could cause a denial of service (DoS)
attack, as the computer consumes resources to generate
these events. Enable audit success with caution as this
setting can cause DoS attacks if computers shut down
when audit logs are full. Correlate any administrator logons
with any other suspicious entries.


2. Local Policies/ Audit Policy ==> Audit account management
Enable both success and failure. Correlate all successful
audit entries with administrator authorizations. Treat all
failures as suspicious.


3. Local Policies/ Audit Policy ==> Audit directory service access
The Default Domain Controllers Group Policy enables this
setting by default. Configure audit settings on sensitive
directory objects by use of System access control lists
(SACLs) in Active Directory Users and Computers or
Active Directory Services Interface Editor (ADSI Edit). You
should plan your SACL implementation, and you should
test your SACLs in a realistic lab environment before
deploying them to a production environment. This
approach prevents overload of the security logs from too
much data.


4. Local Policies/ Audit Policy ==> Audit logon events
Enable audit success for all computers as this event
records who accessed the computer. Enable audit failure
with caution as an attacker with network access but with
no credentials could still cause your computer to consume
resources to generate these events.


5. Local Policies/ Audit Policy ==> Audit object access
Use caution when enabling this setting as it can result in
very high audit volume. Configure audit settings only on
high-value folders through SACLs and audit only the
minimum number of types of accesses that you are
interested in. Audit writes only (and no read accesses) if
your threat model allows this.


6. Local Policies/ Audit Policy ==> Audit policy change
Enable both success and failure event auditing. Crossreference
any successes with administrator authorizations.
 

7. Local Policies/ Audit Policy ==> Audit privilegeuse
Do not enable auditing for privilege use due to the high
volume of events that this generates.


8. Local Policies/ Audit Policy ==> Audit process tracking
Do not enable this setting on Common Gateway Interface
(CGI) Web servers, test computers, servers that run batch
processes, or developer workstations. Enable this setting
on vulnerable computers, and immediately act upon
unexpected application activity, through physical isolation
of the computer if necessary. This setting can cause
events to fill up event logs.

9. Local Policies/ Audit Policy ==> Audit system events
Enable both success and failure event auditing.


10. Local Policies/ User Rights Assignment ==>  Generate security audits
This setting is assigned by default to Local System, Local
Service, and Network Service. This right should not apply
to any accounts other than service accounts. An attacker
can use this setting to generate spurious or inaccurate
events in the security log.


11. Local Policies/ User Rights Assignment ==>  Manage auditing and security log
Use this setting to restrict the administrators who can
make changes to audit settings on files, folders, and
registry settings. Consider creation of a security group for
administrators who can change audit settings and remove
the administrators group from the Local Security Policy
settings. Only members of the new security group should
be able to configure auditing.


12. Local Policies/ Security Options ==> Audit: Audit the access of global system objects
This setting adds SACLs to named system objects such as
mutexes (mutually exclusive events), semaphores, and
MS-DOS devices. Default settings on Windows Server
2003 do not enable this option. Do not enable this setting
as it results in a very high volume of events.


13. Local Policies/ Security Options ==> Audit: Audit the use of Backup and Restore privilege
Backup and restore operations provide the opportunity to
steal data that ACLs protect. Do not enable this setting as
it results in a very high volume of events.


14. Local Policies/ Security Options  ==> Audit: Shut down system immediately if unable to log security audits
Enable this setting after careful consideration on very highvalue
computers only, as attackers can use this feature for DoS attacks.


15. Event Log  ==>  Maximum security log size
The maximum security log size must be a multiple of 64
kB. The average event size is 0.5 kB. Recommended
settings depend on projected event volumes and settings
for retention of security logs. For high event volume
environments, set the log file size as large as possible,
even up to 250 MB. The total size of all event logs cannot
exceed 300 MB, so do not attempt to exceed this figure.


16. Event Log   ==> Prevent local guests group  from accessing security log
Windows Server 2003 enables this setting by default — do
not change.

17.Event Log Retain security log
Enable this setting only if you select the retention method
"Overwrite events by days." If you use an event correlation
system that polls for events, ensure that the number of
days is at least three times the poll frequency to allow for
failed poll cycles.


18. Event Log Retention method for security log
For high security environments, enable the Do not
overwrite events setting. In this case, establish procedures
to empty and archive logs regularly, particularly if the
computer shuts down when the security log fills up.

 

Last Updated: November 1, 2006

Winteacher.com
Expert Zone > Security Events

 © 2003-2006 Winteacher.com . All rights reserved