04- Windows- Logs, File Shares, and SSH

Viewing Windows Logs

Windows 2008 Server
The primary tool for log viewing in Server 2008 is the Event Viewer. To start event viewer, choose either

• Start -> Administrative Tools
• Server Manager -> Diagnostics -> Event Viewer
• Run the command eventvwr.msc

Documentation on Event Viewer is available in Help (Contents: Event Viewer)

What are the different windows logs? What are the different event properties?
Identify a logon event from the security log. Read the details of the event. Do the same for a logoff event.

From the action pane, create a custom view. What is the value of a custom view? Create a custom view to see all of the security log entries

Windows Vista
The primary tool for log viewing is still Event Viewer. Navigate My Computer (right-click) -> Properties -> Event Viewer, or simply run eventvwr.msc

What are the differences between event viewer for Windows Vista and Windows Server 2008?

Windows 7
The primary tool for log viewing is still Event Viewer. Navigate My Computer (right-click) -> Properties -> Event Viewer, or simply run eventvwr.msc.

What are the differences between event viewer for Windows 7 and Windows Server 2008?

Remote viewing of logs
It is possible to view use event viewer on one computer to view the logs on another windows computer. From Event Viewer, select Action -> Connect to Another Computer Enter the name, and the account details (if different) for the other machine.

In general, this process will fail.

Did you say fail?

What could the problem be?

If you said “Firewall” pat yourself on the back.

To enable these connections, you must adjust the firewall on the remote computer.

In Windows Server 2008, navigate Start -> Administrative Tools -> Windows Firewall with Advanced Security. Select Inbound Rules. There are three inbound rules for Remote Event Log Management. Enable them. You may wish to configure these rules as well- Right-click, select properties.

In Windows 7, navigate Start -> Control Panel -> System and Security -> Allow a program through windows firewall -> Change Settings -> Remote Event Log Management. You can specify that this is allowed from other domain members, from computers connecting through a private network (home/work) or through a public network.

In Windows Vista, navigate Start -> Control Panel -> Allow a program through Windows firewall -> UAC -> Remote Event Log Management.

Auditing Policies

Windows machines have an auditing policy that is set locally, as well as policies that they can inherit from GPOs, including domain policies as we have already seen.

To find the local auditing policy in Windows Vista / Windows 7 / Server 2008, navigate Control Panel -> Administrative Tools -> Local Security Policy
-> Security Settings -> Local Policies -> Audit Policy.

What is the default Local audit policy in Vista? In 7? In Server 2008?

By default, significant auditing policies are set at the domain controller OU level. [Which override the local policies!]

On Windows Server 2008, navigate Start -> Administrative Tools -> Group Policy
Management. What are the default doman level OU group policy settings for auditing?

With Windows Server 2008 and Windows Vista, Microsoft introduced a a new hierarchy for organizing audit log entries. Unfortunately, they did not update the GUI tools in these OSes to view these setting. Fortunately, they also did not provide a way to use group policy to update these settings anyway.

What? You actually want to see the settings? <Mr. Burns>Excellent</Mr. Burns>. From a command line, run the command

auditpol /get /category:*

What? “A required privilege is not held by the client”? Remember that, by default command prompts, even command prompts started by an administrator are not command prompts with administrator privileges. You must right-click on the entry in the start menu, and select “Run as Administrator” and pass through UAC first.

Examine the standard audit policy for your server; repeat the process for a Vista and/or a 7 box. Are the policies the same?

To change the policies on a box, you can use the command-line tool- try

auditpol /?

to see the command lne options. See also
http://technet.microsoft.com/en-us/library/cc836528.aspx

Suppose that you want to modify the audit policy on the different machines in your domain. You can’t use Group Policy, as the GUI does not aupport this new audit policy heirarchy. [Although interestingly, if you set the policies using auditpol and then join a domain, apparently the group policies will overwrite the auditpol created settings- at least according to some of the texts I have read.] There is a way to do this- by first writing a custom script that uses the auditpol tool, then by using a netlogon share you can have computers that log onto the domain run that script, and so set the policies to your preferred values. See http://support.microsoft.com/kb/921469 for the details.

Auditing File Access
Unlike the generic linux logging system, Windows can also generate log entries when particular files are accessed / modified / changed. To illustrate the process, create a file- say on the Desktop named test.txt. Navigate test.txt (right-click) -> Properties -> Security -> Advanced -> Auditing -> UAC

The window shows the user(s) and the privilege(s) that will be audited. In general you want to be broad here. If you specify that you will only audit file access from the user “Bill”, then if the user “Ted” accesses the file, then no log entry will be generated.

To illustrate, let us audit any attempt to access / modify / delete our file, from anyone. Select the Add button; for the object name, select “Everyone”. For the auditing entry, select Full Control both successful and failed. This means that an audit entry will be generated whenever any of the checked privliges are used by a user- either successfully or not. Apply your changes. Examine the security log- note that there are no entries about your file.

Open your file, modify it, and save the result. Once again examine the security log. Huh? Why are there no entries here- did we do something wrong? Although you set the auditing policy for that file, Windows does not actually pay attention to those settings unless you turn on file level auditing in your audit policy. Run the command

auditpol /set /subcategory:”file system: /success:enable /failure:enable

Open Your file. Open your security log. [You may need to refresh your view if you still have the log open from above.][Use the F5 key to refresh your view.] At this point, you should see Audit Success entries for the File System related to your auditied file.

Splunk

It is simplest to install Splunk on a machine that is not a domain controller. In what follows, we will install splunk on a machine that is a domain member, but not a doman controller.

Splunk needs a user account that will be be used to run the tool. If we want Splunk to be able to access data from other members of the domain without the use of a forwarder, then that user needs to be a domain member.

Create a domain user named splunk. This user should be a regular user, but not a domain admin. You can place this user in an appropriate OU. The splunk user also needs to be a member of the local administrator group on the machine that splunk runs (or to have roughly equivalent privileges). Because domain controllers do not have a local administrators group, this makes installing splunk on a domain controller difficult. Navigate Start -> Control Panel -> User Accounts -> User Accounts -> Manage User Accounts -> Advanced -> Advanced (in the group Advanced user management) -> Groups (double click) -> Administrators -> Add -> splunk
-> Apply. At this point, your user “your_domain”\splunk is a member of the local
administrators group on your machine.

The splunk account needs one additional privilege- it needs to be able to
log on locally as a service. Navigate Start -> Control Panel -> System and Security -> Administrative Tools -> Local Security Policy -> Security Settings -> Local Policies -> User Rights Assignment -> Log on as a service (double click) -> Add User or Group -> splunk -> Apply.

At this point, we can start the installer. Accept the license and accept the default file location. Install splunk as “Other user”. In the next window, provide the user name and credentials for the user splunk you have created. Install. (w/ UAC).

The interface to Windows Splunk is essentially the same as the Linux Splunk interface. Log in, and configure the admin user(s) and password(s) as you deem appropriate. Before continuing, note that splunk still needs Adobe flash- a recent version of flash is available on the labshare- install it and return to splunk. Update the licence to the Free license; this is done as it was for the linux
system. Open the file c:\Program Files\Splunk\etc\splunk-free.license. Copy the contents of that file. Navigate Splunk -> Manager -> License -> Change License. Paste the free license into the appropriate box. Save; then restart splunk.

Under Your apps, run the Windows app; configure it as you see fit. Take a look at the data that you are now collecting by navigating Splunk -> Launcher -> Your Apps -> Search. Note the different data sources available- logs, and active directory
data.

Once the Windows app is configured to obtain data from the local system use the Windows app to get remote logs via WMI. This will enable us to get data from other windows machines that are part of the domain without the trouble of installing splunk on those machines to act as a forwarder. Select New, then select a name and a host from which to collect the logs. Press “Find logs”.

An error? What could it be. Of course- firewall! Allow Windows Management Instrumentation (WMI) through the firewall of the target.

Select the logs you wish to obtain.

The same issues that encouraged us to install splunk on other than a domain controller also mean that WMI data is not available from domain controllers without significant additional effort. See the Splunk manual, pp. 68 ff. to see how to use WMI on a domain controller.

We still do not have data on the state of the domain controller iteself (though we have Active Directory data). To get data from the domain controller, we install splunk directly on the domain controller and have it act as a forwarder. In this case though, we install splunk as a local system user. Don’t forget flash player! As before, set up the Windows app, now on your domain controller.

Experience the joy of running IE on a domain controller. Remember-
Tools -> Internet Options -> Security -> Trusted Sites -> Sites

To set up receiving on the splunk server, navigate Splunk -> Manager -> Forwarding and Receiving -> Add New (Receive data from forwarders). Select a port (e.g. 9997).

Firewall, firewall, firewall. In Vista, navigate Start -> Control Panel -> Allow a program through windows firewall -> UAC -> Add Port. Note how the name of the entry appears in the list of programs/ ports in the Exceptions tab- and that you control that name. What if you lied?

In Win 7, navigate Start -> Control Panel -> System Security -> Windows
Firewall -> Advanced Settings -> Inbound Rules (Right Click) -> New Rule -> Port.

Set up forwarding on the domain controller. Navigate Splunk -> Manager -> Forwarding and Receiving -> Add New (Forward data to another splunk instance). Enter the host & port data. Should you use the hostname or the IP? Why? Restart splunk on the domain controller.

Return to your splunk server, and verify that you are receiving data.

It is possible to forward data from linux splunk instances to windows ones and vice versa. Try it!

If you want to use WMI data so as to avoid installing splunk forwarders on all of your windows machines, then I believe that you need your splunk server to be a Windows machine.

Remember- splunk can forward to multiple machines, and receive from multiple machines- so you can contruct a distributed / redundant splunk network.

Other options- Snare (optional)

Snare is a tool that can be used to convert Windows log entries into syslog format and then send them out via the syslog protocol.

To do so, install SNARE Agent on the windows machine. From Network Configuration, set up Destination Snare Server Address, with Destination port 514 and “include SYSLOG Header”. Change configuration (and be sure to “Apply the Latest Audit
Configuration”) then test.

Snare can also be used to receive syslog entries sent either from linux machines or from other Windows machines using Snare or another syslog protocol. Snare can also be used to send logs from one windows machine to another using its own Snare protocol.

Install Snare BackLog on the windows machine. Be sure that the ports (UDP 514 for syslog UDP 6161 for Snare Native) are open in the firewall. Set up the sending machine to log to the correct host.

Wireshark

Wireshark for Windows is available on the lab share.

SSH

The best client for SSH from a Windows System in PuTTY. It is available on the lab share.

PuTTY supports password based logons; it also supports PKI. Read the section in the PuTTY help manual on PKI; use PKI to log on to one of your linux servers. Save the session variables in your PuTTY configuration so that they do not need to be specified each time a connection is made.

There are some SSH servers available for Windows- see OpenSSH Server, and CopSSH.

File Sharing

Microsoft Windows operating systems are designed to allow users to share files and folders.

Creating a (SMB) file share (Windows 7 / Vista)
Create a folder; navigate Folder (right click) -> Sharing -> Advanced Sharing. Specify the Share name, and the permissions of the users allowed to access the share. The default is everyone can read, no one can write. Note that two sets of permissions apply to the share- the NTFS (file system) and the SMB (sharing). Be sure that both are set appropriately.

Setting up a file server (Windows 2008)
We can also use a Windows server as a file server. In this example, we will create a new server to act as the file server for our network separate from our domain controller and DNS architecture.

Follow the existing notes; set up the IP address and networking of the new
server. Set up the name of the host and join it to our domain. Be sure that the
appropriate entries exist in the DNS server. From initial configuration tasks, select Add Roles -> File Services Install both the File Server and the File Server Resource Manager (only). [We just don’t have the time to cover much beyond this.]

Examine the settings for storage usage monitoring, but keep the defaults. Do the same for Report Options. Let us create a shared directory that all domain users can use. Navigate Server Manager -> Roles -> File Services -> Share and Storage Management. In the action pane, choose Provision Share

Create a folder in the system that will be shared; say c:\ShareData\CommonData. Edit the NTFS permissions on that folder so that all domain users have full control.

Select SMB as the protocol for sharing the file; note the Share path for later. Examine the Advanced SMB settings, but keep their default values. Set the SMB permissions for the folder; allow all domain users to have full control over the folder. For simplicity, we do not apply a quota or a file screen. We will not use DFS namespace mappings. Create.

Automatic Drive Mappings via Group Policy
We would like each user to have a drive letter mapped to the file share just created; this is done through Group Policy.

On a domain controller, go to group policy management and create a new group policy object- say “Common Drive Mapping”. Edit that policy: Common Drive Mapping -> User Configuration -> Preferences -> Windows Settings -> Drive Maps.

In the Drive Maps window, right click and select New -> Mapped Drive. For Action, select “Create”; for Location, select the file share created previously. (You did remember the Share path in Step xii didn’t you?) Select a label for the drive share; select a drive letter- say P:. Apply the result.

Exit the group polocy editor (with our policy now saved).

Return to Group Policy Management; select Group Policy Management -> Forest -> Domains -> “YourDomainNameWhateverItIs” (Right click) -> Link an existing GPO -> Select your new GPO, which this example calls “Common Drive Mapping”. Apply this policy.

You do not need to apply this policy to the entire domain; you could simply apply it to one or more OUs.

Log onto a machine in your domain; verify that the drive p: is now mapped to the file share.

Accessing a (SMB) file share
Suppose that the file share is on the server “Server” with share name “fileshare”. [Note that the share name can be different from the name of the folder that is beng shared.] This can be from a file server, but does not need to be.

Windows (File explorer)
From file explorer or the equivalent, navigate to

\\Server\fileshare

You will need sufficient permissions to access the share.

These permissions are cached, so you can run into trouble if either the settings or your credentials change during e.g. the process of setting up the share.

Windows (command line)
Run the command

net use z: “\\Server\fileshare”

to map the file share to the drive letter z:. You can also specify the user & password used to authenticate to the share on the command line; use the help command

net use /?

to see the command line options.

Windows (File explorer -> Drive mapping)
From file explorer, navigate Tools -> Map Network Drive. From here you can specify the drive letter, the remote share, and the user and password that will be used to authenticate to the share.

Linux (Gnome GUI- e.g. CentOS, Ubuntu)
Navigate Places -> Connect to Server -> Windows Share. Enter the Server name, Share, User Name, and Domain Name. Provide the password when asked.

Linux (KDE4 GUI- e.g. OpenSuSE)
Open the Konqueror (the file browser); in the address bar, enter

smb://Server/fileshare

When asked for credentials, for the user name enter domain/username together with the the corresponding password.