05- Windows Logging, Splunk, SSH, File Shares, & Situational Awareness

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

The server shows three sets of logs common to all Windows systems- the Application log, the Security Log, and the System log. There are also two new logs, the Setup log and the Forwarded Events log.

Take a look at the security log; you are likely to see a number of 4624 Logon events as well as a number of 4634 Logoff events. Microsoft has provided a description of the various security events in KB 947226. Because of the fine-grained nature of Windows logs, these entries do not correspond to a user sitting down at the machine and logging on; rather these are typically service accounts logging on to perform a task and then logging right back out. You can find out more about each event by double clicking it in the Event Viewer; here is a typical Windows 4624 Logon event:

In the general tab, you can find out more about the event:

An account was successfully logged on.

Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0

Logon Type: 3

New Logon:
Security ID: SYSTEM
Account Name: GISKARD$
Account Domain: CLASS
Logon ID: 0xaa685
Logon GUID: {d4dcbd44-a07b-e138-9bcb-0b83cb22c72a}

Process Information:
Process ID: 0x0
Process Name: -

Network Information:
Workstation Name:
Source Network Address: fe80::827:40d8:419d:412b
Source Port: 49239

Detailed Authentication Information:
Logon Process: Kerberos
Authentication Package: Kerberos
Transited Services: -
Package Name (NTLM only): -
Key Length: 0

This event is generated when a logon session is created. It is generated on
the computer that was accessed.

The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local
process such as Winlogon.exe or Services.exe.

The logon type field indicates the kind of logon that occurred. The most common
types are 2 (interactive) and 3 (network).

The New Logon fields indicate the account for whom the new logon was created,
i.e. the account that was logged on.

The network fields indicate where a remote logon request originated. Workstation
name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this
specific logon request.
- Logon GUID is a unique identifier that can be used to correlate this
event with a KDC event.
- Transited services indicate which intermediate services have
participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM
protocols.
- Key length indicates the length of the generated session key. This
will be 0 if no session key was requested.

Reading through this documentation, we discover a few important things. These entries do not tell you what account logged on- rather it tells you what service requested the logon. We also see that this is a network logon, as the logon type was 3. Don’t jump to conclusions though- this is just one of many logon events that appeared when the system started; this was not generated by a remote user accessing this system.

To give you a better feel for the Windows logs, let’s see what happens in the domain controller log when we do something relatively common. Select a workstation other than your domain controller(s) and log in to that machine as a domain user. Now go back to the security log and see what we find. (Be sure to refresh your log view!) Find the event that corresponds to your account login; be sure to identify the EventID. You may wish to use the Find entry in the action pane.

Once you have found the log on entry, go ahead and log out of the workstation. Can you find a corresponding logoff entry in the domain controller logs? Are you sure you have the right event? Take a very close look at the time stamps of the logon event and the logoff event, and be sure to compare them to the actual time you logged off. Do you notice anything?

The question of exactly how Windows keeps track of account logons and logon/logoff events is more complex than would appear. Fortunately, Randy Franklin Smith has a nice article available on the EventTracker blog that explains some of these points. Unfortunately, we do not have sufficient class time to delve into these issues in detail.

You may wish to compare the log on and log off process noted above with what occurs when you log on from a Linux machine that you have connected to the domain.

Windows Vista

Even if a system is not a domain controller, it will still contain a set of logs; the primary tool for log viewing is still Event Viewer. In Windows Vista, 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.

Windows 8

The primary tool for log viewing is still Event Viewer. As might be expected though, finding it is the trick. If you right-click on the Metro screen to get all of the apps, you can select the Run entry and use eventvwr.msc. You can also go to the Control Panel, then select System and Security, then Administrative Tools, then View Event Logs.

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

Remote Viewing of Windows 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. Be sure that you have selected Event Viewer (Local) in the navigation pane, or the option to connect to another computer will not appear in the Action menu. 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 Vista, navigate Start → Control Panel → Allow a program through Windows firewall → UAC → Remote Event Log Management.

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 8, Navigate Control Panel → System and Security → Windows Firewall → Allow an App or Feature through Windows Firewall → Change Settings → 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 → System and Security → Administrative Tools → Local Security Policy → Security Settings → Local Policies → Audit Policy.

What is the default Local audit policy in Vista? In 7? In 8? 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 domain level OU group policy settings for auditing?

With Windows Server 2008 and Windows Vista, Microsoft introduced a a new hierarchy for organizing audit policies. Rather than the nine broad categories we have seen so far, we can instead manage policies on a much finer level. Unfortunately, they did not update the GUI tools in these OSes to view these setting. The way to get at these settings is directly from the command line. Indeed, run the command

C:\Windows\system32>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 manage the policies on a box with the command-line tool, start by running

C:\Windows\system32>auditpol /?
Usage: AuditPol command [<sub-command><options>]


Commands (only one command permitted per execution)
  /?               Help (context-sensitive)
  /get             Displays the current audit policy.
  /set             Sets the audit policy.
  /list            Displays selectable policy elements.
  /backup          Saves the audit policy to a file.
  /restore         Restores the audit policy from a file.
  /clear           Clears the audit policy.
  /remove          Removes the per-user audit policy for a user account.
  /resourceSACL    Configure global resource SACLs


Use AuditPol  /? for details on each command

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

If we want to see the policies in the logon/logoff category, we ran run

C:\Windows\system32>auditpol /get /category:Logon/Logoff
System audit policy
Category/Subcategory                      Setting
Logon/Logoff
  Logon                                   Success and Failure
  Logoff                                  Success
  Account Lockout                         Success
  IPsec Main Mode                         No Auditing
  IPsec Quick Mode                        No Auditing
  IPsec Extended Mode                     No Auditing
  Special Logon                           Success
  Other Logon/Logoff Events               No Auditing
  Network Policy Server                   Success and Failure

and if want to see only the logoff subcategory, we run

C:\Windows\system32>auditpol /get /subcategory:logoff
System audit policy
Category/Subcategory                      Setting
Logon/Logoff
  Logoff                                  Success

If we want to change the settings so that we record both successful and failed attempts to logoff, we run

C:\Windows\system32>auditpol /set /subcategory:logoff /failure:enable
The command was successfully executed.

A subsequent check of the policies will show the change:

C:\Windows\system32>auditpol /get /subcategory:logoff
System audit policy
Category/Subcategory                      Setting
Logon/Logoff
  Logoff                                  Success and Failure

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 support this new audit policy hierarchy.

[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

C:\Windows\system32>auditpol /set /subcategory:"file system" /success:enable 
/failure:enable
The command was successfully executed.

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

To install Splunk on a Windows system, select the appropriate installer and launch. Because Splunk runs services, you will be prompted to choose the user that will be used to run those services. If you use a domain member, then your Splunk install can access information about other domain members through Windows methods like WMI. However, previous classes found that process somewhat problematic. This year, we will use local system users for our installation. This means that we will need to use forwarders to collect data from other Windows hosts in the same fashion that they are necessary to collect data from other Linux hosts.

After installation, proceed to the Splunk Manager web interface as before; be sure to change your license to the Free License. You can do that by navigating through Manager → Licensing &rarr Change License Group. Simply select the Free License, and restart Splunk.

Once installed, one very valuable data source would be the Windows event logs. Note that, since we installed Splunk as a local user, we will not be able to use WMI to collect Windows event logs from other machines in the domain.

Now if you want to find all of the logon entries in you logs, you can perform a simple Splunk search

You can also set up the Splunk Windows App. App → Manage Apps → Install app from file. You can get the app directly from splunkbase or from the labshare. Like the apps for Linux, these are .tgz files that do not need to be unpacked or uncompressed.

Once it is installed, the Windows app needs to be configured. If your system is using DHCP for addressing, you may want to record that data; otherwise if you have already configured Splunk to manage the logs (System, Application, Security), then the default configuration can be accepted.

You can set up Splunk to collect data from multiple machines in the same fashion as we did with Linux machines, by using forwarders. Start by configuring your receiver by navigating Manager → Forwarding and receiving → Configure receiving → New then select a port e.g. 9997. Be sure to open that port in your firewall; instructions on how to manage the firewall are in the Setup document and vary depending on the version of Windows.

In Windows 7/8, navigate Control Panel → Windows Firewall → Advanced Settings → UAC.

Once there, navigate to Inbound Rules then select New Rule from the action pane; choose the port, the action, the network profiles, and the name of the subsequent rule.

Essentially the same actions are taken in Windows 2008, save that you navigate Start → Administrative Tools → Windows Firewall with Advanced Security.

In Vista, navigate Control Panel & rarr; Security → Windows Firewall → Change Settings → Exceptions → Add port.

With the receiver correctly configured, go to the Splunk Manager web interface on the hosts you want to forward data. Navigate Manager → Forwarding and receiving → Configure forwarding → New; then provide the information for your receiver.

By correctly configuring forwarders throughout your network, you can have all of the log data for all of your hosts forwarded to a central location for subsequent correlation and analysis.

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

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

Note also that it will take some time after forwarding and receiving is set up for all of the information from the forwarder to be sent to the receiver. My experience with my virtual machines suggest that the process can be very resource intensive, and may slow the virtual machines until the transfers complete.

Other options- Snare

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

Installation of Snare for Windows proceeds in the usual fashion. I recommend that you install Snare as a local system user, and recommend that you enable web access, at least for your localhost, to allow you to more easily configure the tool.

When the installation is complete, use your browser and visit localhost, TCP port 6161. If you specified a password, remember that the user name will be “snare”.

To configure Snare to forward its log messages to another host using the syslog protocol, navigate to Network configuration and enter the host name and the (UDP) port number to receive the logs. You also need to manually tell Snare to use syslog headers (instead of Snare native); you also choose the facility and priority for all of the syslog messages your system will dispatch.

We can also collect Snare and syslog messages on a host, this time using Snare Backlog. It too is installed in the usual fashion. Once running it listens on both the standard syslog (UDP 514) and the Snare native (UDP 6161) ports for messages. You can then configure either Linux machines (via syslog) or Windows machines (via syslog or Snare native) to send their results to this central server. Be sure you open the proper ports in the firewall!

Here you can see Snare backlog on a Windows 8 machine receiving messages from the host on which it is running, as well as syslog messages sent by a Linux machine.

SSH

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

Its general use is straightforward- enter the required connection information in the box and select Open. You can save the profile settings by simply giving it a name and
choosing Save.

If PKI has not been configured, you will be prompted for a username and a password; provide them correctly and you will obtain your shell.

We can also use PKI with PuTTY. Start by running the PUTTYGEN key generator program; be sure you select SSH2-RSA for the key type, as there are weaknesses with the other approaches.

Save both the private key and the public key. We don’t have the simple technique to add the public key to the remote server that we used before, however we can use SSH with a password, then copy and paste the public key on to the server. Unfortunately, the format that PuTTY uses is not one well suited to copying.

For example, here is the public key file generated in this example

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20130216"
AAAAB3NzaC1yc2EAAAABJQAAAIEAopJxxH7wdbzj/WEiGtlZTlLJEbRkBDWw3Bb7
89EXmYtAfK6ngD9pP7ebt+3MhjdomGYXRAMM7MLeOTIARBphsC2RA+88TKj/tHkQ
6pgtgPW2Se099f+A6jnbA7/4z3Ev6G4cattVqmVVdw+jYwwOPi9QL/PXsandQCrt
YGndFXM=
---- END SSH2 PUBLIC KEY ----

If you copy this to the file ~/.ssh/authorized_keys file for a user, it will fail. Why? Suppose that we have an existing authorized_keys file generated by OpenSSH; it has permissions 600, and has contents similar to the following

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA3b9Hp1k4lqRUNIbx4jg1nrXJw1CkchKIgdtKrTSQi52
72tC84mg74XNlxxlNkzVs8cxxJTxfimXOhZUHWbaYHoMPius9o9yQk2U+2/CHMx6JS90pTaHkMvEgyM
aZNnSVZhIg2/v0n/aLOM2ite2iaTQKN3LNZ39rTdcejLSo/DGWJACR6JJS5Af3dD1AWiIyNhDELXCsJ
FMuQqhrIzIfNT52qJ3Yd8gmNbWctATSQKNxBKK1zoBCTVlYjZ/IkRhoANjpCsnFV20VOU9xFrQ2aQ6S
kXzp7NzsIk+DlGV1FefbnhNKiMGglzgPNLXWZ24Bjq/XsSeikFsCLLHOSLQeFw== seldon@proclas
.cosc.tu
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA6y+v/2XXCk/694UzQ3egHOE0jWzAM/gwkLTbud371A6
TbcRS5+chfLwmDl1aO5+T/dz9ydkHKOOln4QbFs/JtCtJecpE9DlLC9jFQf9H1+4Vbv5eYYmPKlbkJa
GLoSPs4Vk1EVg75kx4pBGRdfR839t9axiDwIrku7HdGapoGRmFOzvcNmNbagx8Rz7/74GRmpdYCHbSL
dQ7BtcRHX3XV2NtdQIifCiUje5KSp+RT08JT82q7qZ++Hsbk6OnTJDBJ5TeJXXU4WgNikKlKn+gAYSW
DcjmYTfZLvnzkte6OFPNQXktvivI27y3lPRPWQXNQ7RdzL3hgDD/ro2bDlXJ+w== root@proclas.c
osc.tu

Here we see two RSA keys, one for the user seldon on the host proclas.cosc.tu, and a second for the user root on the same host. We need to modify our PuTTY generated key so that it has the same format; is needs to start with the text ssh-rsa and should end with the user and host that has the corresponding private key; the commented lines need to be removed. Further, the result needs to be on a single line with no newlines.

Even better, if you open the public key with a simple text editor like Notepad, you won’t even realize that the key is split over multiple lines, so and copying it becomes even more trouble.

Here is one way to proceed. Open the public key in Wordpad. Under View, make sure that lines are not being wrapped. Delete the first two lines and the last line; then make sure that all that remains is on a single line. Be sure that the line starts with the magic text "ssh-rsa" and ends with the user name and host name where the private key is stored; you should end with something like this

Copy that single line into the file ~/.ssh/authorized_keys on the remote server; I did it by using SSH and a password to login, then used vi to open the file, and just pasted the result to the end of the file by right-clicking. You should obtain something like the following:

Save the result. To log in using this key, specify the user name in the Data dialog box (beneath Connection), while the location of the private key is specified in the Auth dialog box (beneath Connection, beneath SSH).

Given the settings in different places, I recommend that you save your resulting configuration (in Session).

Opening the connection will then

There are some SSH servers available for Windows- see FreeSSHd, 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 8)

Creating a file share for a Windows 8 system connected to a domain is actually quite simple. Suppose that the domain user John Sales has a folder called "Shared Folder" in the Documents Library. To share that folder, simply navigate to that folder and select Share, then Specific People. You can then grant permissions to user(s) and group(s) defined on the domain controller. So, for example we can give all domain members permission to read the directory, and all members of the sales admin group (which we created in our discussion of group policy) both read and write permissions.

Creating a (SMB) file share (Windows 7)

Create a folder; navigate Folder (right click) → Properties → Sharing → Sharing. Specify the Share name, and the permissions of the users allowed to access the share. One apparent difference is that an administrator password was required for Windows 7 but not for Windows 8 to enable the share. That may be particular to my setup though- I will have to look into this some more.

Setting up a file server (Windows 2008)

In most large organizations however, file shares are provided centrally as part of the overall network infrastructure and run from a file server.

In this example, we will set up a Windows 2008 R2 system as a file server. This system will be a domain member, but will not be a domain controller. In this example, the system will be named baley.class.tu; it will be a member of the domain class.tu, which has giskard.class.tu as the domain controller; the system will live at the IP address 10.0.2.205.

With the basics covered, go to initial configuration tasks, select Add Roles → File Services. In this example, we install both the File Server and the File Server Resource Manager.

With the role installed, now we need to create the shared directory that the approved domain users can use. Navigate Start → Administrative Tools → Share and Storage Management. In the action pane, choose Provision Share.

The first task when provisioning a share is to select the location of the directory to be shared. In this example, we will create the directory C:\ShareData\CommonData and will share that directory.

With the folder created, we modify permissions for the folder in the usual fashion so that all domain users have full control over that directory.

We will use SMB as our file sharing protocol; this is the preferred method for Windows systems. We have not discussed NFS, nor have we even installed the necessary services for NFS component on the server.

When the wizard asks for the SMB permissions to be used, we specify that Administrators have Full Control while all other users have Read and Write permissions. Remember- the enforced permission set is the more restrictive of the SMB permissions and the NTFS permissions.

For simplicity in this example, we will not apply a quota policy, nor will we set up a file screen.

The wizard will then ask whether we want to publish the SMB share to a DFS namespace. DFS is a system that allows one namespace to be served by multiple physical file servers and shares. Since our time is limited and our examples small, this is unnecessary for us.

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, as a domain administrator 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. Be sure that you include both the host name and the directory for your share. In this example, the file server is Baley and the shared directory is CommonData, so the location is \\Baley\CommonData. Select a label for the drive share; select a drive letter- say P:\. Apply the result.

Exit the group policy 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.

Individual file shares

We can also set up a directory to provide an individual file share for each domain user. We start by creating the file share itself, so we launch Share and Storage Management (Start → Administrative Tools → Share and Storage Management). Here we again Provision a Share; given that we have set up our common share at c:\ShareData\CommonData, in this example we will set up the directory c:\ShareData\UserData.

Now we will be more careful about the NTFS permission set we will apply. Select Edit Permissions, and then choose Advanced; when you do you will be presented with a dialog similar to the following:

From this we see that all users have read and execute privileges on the folder- something that we do not want, so we want to remove them. Attempting to do so however, we discover that we cannot. The reason for this is that these permissions are being inherited from the object’s parent. Thus, we start by unchecking the appropriate box. You are then given three options:

To cancel, and not make any changes,
To remove, and remove all inherited permissions, and
To Add, which will convert the inherited permissions into explicit ones.

We select Add, which will keep the settings as they are, but allow us to now modify them. Remove the permissions for USERS. We now need to be sure that we can create the required subdirectories, so we require that Domain Admins have full control over the directory. Doing so, we end up with a permission set like

For the remaining settings we proceed as we did for the Commmon Share; be sure that your SMB permissions give users and groups Read and Write Access.

With the share complete, we now move to the individual users. From a domain controller, navigate to Active Directory Users and Computers (e.g. Start → Administrative Tools → Active Directory Users and Computers). Select a user, then select Properties. From the dialog box that results, choose the Profile tab. Under Home Folder, choose a drive letter and then provide the path to the file share we just created- with one additional twist. We will actually provide a link to a subdirectory based on the account user name; we can even simply specify %username in the directory name:

We repeat this process for each user.

When complete, we can simply login as a user, and verify that both drives are mapped to the correct places:

When you perform these tasks, you should also verify that you are unable to access the file shares of other users.

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 being 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

c:\>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

c:\net use /?

to see the command line options. Running net use without any arguments will provide a list of all existing shares:

Microsoft Windows [Version 6.2.9200]
(c) 2012 Microsoft Corporation. All rights reserved.

C:\Users\hardin>net use
New connections will be remembered.


Status       Local     Remote                    Network

-------------------------------------------------------------------------------
OK           P:        \\BALEY\CommonData        Microsoft Windows Network
OK           Z:        \\BALEY\UserData\Hardin   Microsoft Windows Network
The command completed successfully.

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.

On e.g. a Mint 11 machine, you can start navigate File → Connect to Server from the file browser.

Situational Awareness

As in the case of our Linux system, it is important to know what is occurring on our system.

Netstat

Like Linux systems, windows systems also come with a tool called netstat. The tools are similar, though the options are quite different. To have netstat show all of the listenting ports, use the -a switch; to have the ports displayed in numeric form use -n and to include the PID of the process that opened the port, use -o. On our Windows File server, this results in a set of output like the following

C:\Users\administrator>netstat -ano

Active Connections

  Proto  Local Address          Foreign Address        State           PID
  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       672
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:47001          0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:49152          0.0.0.0:0              LISTENING       368
  TCP    0.0.0.0:49153          0.0.0.0:0              LISTENING       760
  TCP    0.0.0.0:49154          0.0.0.0:0              LISTENING       472
  TCP    0.0.0.0:49155          0.0.0.0:0              LISTENING       792
  TCP    0.0.0.0:55119          0.0.0.0:0              LISTENING       464
  TCP    10.0.2.205:139         0.0.0.0:0              LISTENING       4
  TCP    10.0.2.205:445         10.0.2.201:59373       ESTABLISHED     4
  TCP    10.0.2.205:445         10.0.2.202:64547       ESTABLISHED     4
  TCP    [::]:135               [::]:0                 LISTENING       672
  TCP    [::]:445               [::]:0                 LISTENING       4
  TCP    [::]:47001             [::]:0                 LISTENING       4
  TCP    [::]:49152             [::]:0                 LISTENING       368
  TCP    [::]:49153             [::]:0                 LISTENING       760
  TCP    [::]:49154             [::]:0                 LISTENING       472
  TCP    [::]:49155             [::]:0                 LISTENING       792
  TCP    [::]:55119             [::]:0                 LISTENING       464
  UDP    0.0.0.0:123            *:*                                    832
  UDP    0.0.0.0:5355           *:*                                    920
  UDP    10.0.2.205:137         *:*                                    4
  UDP    10.0.2.205:138         *:*                                    4
  UDP    127.0.0.1:57729        *:*                                    792
  UDP    127.0.0.1:59780        *:*                                    920
  UDP    127.0.0.1:59782        *:*                                    472
  UDP    [::]:123               *:*                                    832
  UDP    [::]:5355              *:*                                    920
  UDP    [fe80::9043:db76:ab4d:5ba7%11]:546  *:*
    760

We see here that there are both IPv4 and IPv6 connections, with both TCP and UDP represented. If you just wanted, say TCP on IPv4, you could add the additional switch

C:\Users\administrator>netstat -ano -p TCP

Active Connections

  Proto  Local Address          Foreign Address        State           PID
  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       672
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:47001          0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:49152          0.0.0.0:0              LISTENING       368
  TCP    0.0.0.0:49153          0.0.0.0:0              LISTENING       760
  TCP    0.0.0.0:49154          0.0.0.0:0              LISTENING       472
  TCP    0.0.0.0:49155          0.0.0.0:0              LISTENING       792
  TCP    0.0.0.0:55119          0.0.0.0:0              LISTENING       464
  TCP    10.0.2.205:139         0.0.0.0:0              LISTENING       4
  TCP    10.0.2.205:445         10.0.2.201:59373       ESTABLISHED     4
  TCP    10.0.2.205:445         10.0.2.202:64547       ESTABLISHED     4

If you want to know the name of the process that opened the connection, you can add the -bswitch:

C:\Users\administrator>netstat -anob -p TCP

Active Connections

  Proto  Local Address          Foreign Address        State           PID
  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       672
  RpcSs
 [svchost.exe]
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
 Can not obtain ownership information
  TCP    0.0.0.0:47001          0.0.0.0:0              LISTENING       4
 Can not obtain ownership information
  TCP    0.0.0.0:49152          0.0.0.0:0              LISTENING       368
 [wininit.exe]
  TCP    0.0.0.0:49153          0.0.0.0:0              LISTENING       760
  eventlog
 [svchost.exe]
  TCP    0.0.0.0:49154          0.0.0.0:0              LISTENING       472
 [lsass.exe]
  TCP    0.0.0.0:49155          0.0.0.0:0              LISTENING       792
  Schedule
 [svchost.exe]
  TCP    0.0.0.0:55119          0.0.0.0:0              LISTENING       464
 [services.exe]
  TCP    10.0.2.205:139         0.0.0.0:0              LISTENING       4
 Can not obtain ownership information
  TCP    10.0.2.205:445         10.0.2.201:59373       ESTABLISHED     4
 Can not obtain ownership information
  TCP    10.0.2.205:445         10.0.2.202:64547       ESTABLISHED     4
 Can not obtain ownership information

Full details about some of the other netstat options can be found with the /? switch:

C:\Users\riose>netstat /?

Displays protocol statistics and current TCP/IP network connections.

NETSTAT [-a] [-b] [-e] [-f] [-n] [-o] [-p proto] [-r] [-s] [-t] [interval]

  -a            Displays all connections and listening ports.
  -b            Displays the executable involved in creating each connection or
                listening port. In some cases well-known executables host
                multiple independent components, and in these cases the
                sequence of components involved in creating the connection
                or listening port is displayed. In this case the executable
                name is in [] at the bottom, on top is the component it called,
                and so forth until TCP/IP was reached. Note that this option
                can be time-consuming and will fail unless you have sufficient
                permissions.
  -e            Displays Ethernet statistics. This may be combined with the -s
                option.
  -f            Displays Fully Qualified Domain Names (FQDN) for foreign
                addresses.
  -n            Displays addresses and port numbers in numerical form.
  -o            Displays the owning process ID associated with each connection.
  -p proto      Shows connections for the protocol specified by proto; proto
                may be any of: TCP, UDP, TCPv6, or UDPv6.  If used with the -s
                option to display per-protocol statistics, proto may be any of:
                IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, or UDPv6.
  -r            Displays the routing table.
  -s            Displays per-protocol statistics.  By default, statistics are
                shown for IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, and UDPv6;
                the -p option may be used to specify a subset of the default.
  -t            Displays the current connection offload state.
  interval      Redisplays selected statistics, pausing interval seconds
                between each display.  Press CTRL+C to stop redisplaying
                statistics.  If omitted, netstat will print the current
                configuration information once.

Process Explorer

Another useful tool is Process Explorer. This is not part of a standard windows installation, but instead is available as a separate download as part of the Sysinternals suite. This tool provides a graphical view of the processes running on the system, with the ability to simply click to find more information. Here is what the tool looks like on our Windows Server with the lower pane enabled (CTRL+L)

If you double click on a process, you can find out even more detail; if you double click on the jucheck process for example, you will be given a dialog box that lets you determine, for example, what TCP/IP connections that process has made. Here we see the process has connected to an Akamai server, almost certainly to tell me that my version of Java is old and out-of-date.

TCPView

If your interests are solely on the network connections being made to and from your system, you may want to try TCPView. This is another Sysinternals tool that provides just this information; it even highlights new connections for your attention (in green). Here is what the tool looks like while running on our File Server. You can see the NetBIOS session and directory services connections.

Process Monitor

Process Monitor is another Sysinternals tool; it captures he different actions of the processes running on your system. Here is a screen shot of the tool running on the domain controller, where the filter is set to only show networking events.

Note that it is showing an entry for each send or receive event- and there are a lot of them- some quarter million such events. This is a great tool if you want to investigate a particular process; you can even find the complete stack trace for each event.

The sheer number of events makes it less valuable for determining the state of the system as a whole however.

Logon Sessions

If you want to know the details of all of the users logged in to your system, you can use the Sysinternals tool Logon Sessions. This is a command line tool; when run on the file server it gives information like the following:

C:\Users\administrator\Desktop>logonsessions.exe

Logonsesions v1.21
Copyright (C) 2004-2010 Bryce Cogswell and Mark Russinovich
Sysinternals - wwww.sysinternals.com


[0] Logon session 00000000:000003e7:
    User name:    CLASS\BALEY$
    Auth package: Negotiate
    Logon type:   (none)
    Session:      0
    Sid:          S-1-5-18
    Logon time:   2/17/2013 10:41:51 AM
    Logon server:
    DNS Domain:   class.tu
    UPN:          BALEY$@class.tu

[1] Logon session 00000000:000003e5:
    User name:    NT AUTHORITY\LOCAL SERVICE
    Auth package: Negotiate
    Logon type:   Service
    Session:      0
    Sid:          S-1-5-19
    Logon time:   2/17/2013 10:42:01 AM
    Logon server:
    DNS Domain:
    UPN:

[2] Logon session 00000000:0001533f:
    User name:    NT AUTHORITY\ANONYMOUS LOGON
    Auth package: NTLM
    Logon type:   Network
    Session:      0
    Sid:          S-1-5-7
    Logon time:   2/17/2013 10:42:20 AM
    Logon server:
    DNS Domain:
    UPN:

[3] Logon session 00000000:00094ab5:
    User name:    CLASS\salesadmin
    Auth package: Kerberos
    Logon type:   Interactive
    Session:      2
    Sid:          S-1-5-21-3777769887-227576269-3891321149-1113
    Logon time:   2/17/2013 10:59:22 AM
    Logon server: GISKARD
    DNS Domain:   CLASS.TU
    UPN:          salesadmin@class.tu

[4] Logon session 00000000:002115dd:
    User name:    BALEY\Administrator
    Auth package: NTLM
    Logon type:   Interactive
    Session:      2
    Sid:          S-1-5-21-3777769887-227576269-3891321149-500
    Logon time:   2/17/2013 1:00:13 PM
    Logon server: BALEY
    DNS Domain:
    UPN:

[5] Logon session 00000000:00245699:
    User name:    CLASS\riose
    Auth package: Kerberos
    Logon type:   Network
    Session:      0
    Sid:          S-1-5-21-3777769887-227576269-3891321149-1110
    Logon time:   2/17/2013 1:07:03 PM
    Logon server:
    DNS Domain:   CLASS.TU
    UPN:

[6] Logon session 00000000:0000a12c:
    User name:
    Auth package: NTLM
    Logon type:   (none)
    Session:      0
    Sid:          (none)
    Logon time:   2/17/2013 10:41:52 AM
    Logon server:
    DNS Domain:
    UPN:

[7] Logon session 00000000:000003e4:
    User name:    CLASS\BALEY$
    Auth package: Negotiate
    Logon type:   Service
    Session:      0
    Sid:          S-1-5-20
    Logon time:   2/17/2013 10:42:00 AM
    Logon server:
    DNS Domain:
    UPN:

[8] Logon session 00000000:0010f5ae:
    User name:    CLASS\seldon
    Auth package: Kerberos
    Logon type:   Interactive
    Session:      1
    Sid:          S-1-5-21-3777769887-227576269-3891321149-1001
    Logon time:   2/17/2013 11:35:39 AM
    Logon server: GISKARD
    DNS Domain:   CLASS.TU
    UPN:          seldon@class.tu

[9] Logon session 00000000:0010f5cc:
    User name:    CLASS\seldon
    Auth package: Negotiate
    Logon type:   Interactive
    Session:      1
    Sid:          S-1-5-21-3777769887-227576269-3891321149-1001
    Logon time:   2/17/2013 11:35:39 AM
    Logon server: GISKARD
    DNS Domain:   CLASS.TU
    UPN:          seldon@class.tu

[10] Logon session 00000000:00241760:
    User name:    CLASS\Hardin
    Auth package: Kerberos
    Logon type:   Network
    Session:      0
    Sid:          S-1-5-21-3777769887-227576269-3891321149-1108
    Logon time:   2/17/2013 1:04:29 PM
    Logon server:
    DNS Domain:   CLASS.TU
    UPN:

From this we can see a number of different users on the system-

The local system’s administrator account
The domain users CLASS\salesadmin, CLASS\riose, CLASS\seldon, and CLASS\hardin

We even know what time they succesfully logged on to the system. Note that, even though the session is still active, it does not mean that they are still "on" the system. The sessions may still be active, even if the user has logged out of the system that made the original connection; this is the case here. Most of the users listed here had finished their work on the network share and logged out of their workstation some time before this command was run; despite this, they still appeared in this list.

ShareEnum

ShareEnum is another sysinternals tool; this one determines the various shares that are available on your network. If run as a domain administrator, it can provide insight into the different shares on the network. Here is that tool, run on the file server.

It is useful to note that the tool picked up on the share from the system daneel.class.tu, even though it is not being shared as part of the file server, but rather from the workstation of one of the domain users.

PS Utilities

The next set of tools are the PS utilities. These are all command line tools that let you perform various tasks on different systems, provided you have the proper permissions. Here is a brief summary of the tools, taken from the Microsoft web page that describes them.

PsExec – execute processes remotely
PsFile – shows files opened remotely
PsGetSid – display the SID of a computer or a user
PsInfo – list information about a system
PsPing – measure network performance
PsKill – kill processes by name or process ID
PsList – list detailed information about processes
PsLoggedOn – see who’s logged on locally and via resource sharing
PsLogList – dump event log records
PsPasswd – changes account passwords
PsService – view and control services
PsShutdown – shuts down and optionally reboots a computer
PsSuspend – suspends processes
PsUptime – shows you how long a system has been running since its last reboot

The PSLoggedOn tool when run on the file server is able to clearly distinguish between who was logged in locally and who was accessing shares; this is an improvement over what we say with logonsessions

C:\Users\administrator\Desktop\PSTools>PsLoggedon.exe

PsLoggedon v1.34 - See who's logged on
Copyright (C) 2000-2010 Mark Russinovich
Sysinternals - www.sysinternals.com

Users logged on locally:
     2/17/2013 1:00:13 PM       BALEY\Administrator

Users logged on via resource shares:
     2/17/2013 3:27:39 PM       (null)\Hardin
     2/17/2013 3:30:13 PM       (null)\riose

BGInfo

This is another Sysinternals tool. Unlike these others, it does not monitor your system. It merely sets the desktop background for your system on startup based on the values of various variables. If you have many systems, it is convenient when switching systems to see right on the desktop the hosts’s IP address, name, and other critical system informatin. BGInfo can provide that for you.

Comments (0) Trackbacks (0) Leave a comment Trackback

No comments yet.

No trackbacks yet.

CyberOperations