Prologue
Every system has resources which are very essential to have the designated task performed by the system as intended. Some of these resources are exposed to the outside world and some are not. Of all these only few can be controlled and others are not. This is to protect the system integrity and functionality from the novice and probing hands.
But in times of technological and information age, there is lot of information to be shared without having any troubles. The sharing may be with in local intranet or remote internet. In these cases we need look for some issues which place crucial role in the system performance also.
Details
In the above scenario, we may require to monitor and control the resources in a system for protecting as well as enhancing the performance of that system. But the monitoring and controlling activities if done at local system level, the time and the effort needed are going to be unimaginably huge. In addition, the controlling/monitoring authority is not going to have a clear view of ‘ what is what’ about the systems.
The solution for this kind of issues is having the controlling and monitoring power at one end. From this terminal or system the other systems/ computers in the local intranet or remote internet can be controlled or monitored as the administrator/ controlling authority wishes to do.
Requirements:
This proposed System Resource Controller solution requires a keen and carefully planned vision. As we are controlling the resources from a remote end, the network resource overloading is going to be a burden. Without causing much traffic the controlling has to be done.
We are proposed to use some nifty components from the Windows Operating System for the effective controlling of the system resources in the network.
At top level the issues that are going to be controlled monitored are…..
- System Physical Resources
- Software Resources of a System
- The Network Resources
- Finally, Analytical Results of Scrutinization
PRELIMINARY PLANNING / INVESTIGATION
To protect the system integrity and functionality from the novice and probing hands. In times of technological and information age, there is lot of information to be shared without having any troubles. The sharing may be with in local intranet or remote internet. In these cases we need look for some issues which place crucial role in the system performance also.
The goals of SRC is protect system integrity and functionality, and to maintain performance
Objectives:
To achieve the above goal we need to achieve the following sub-goals or objectives…
We need some nifty components from the Windows Operating System for the effective controlling of the system resources in the network.
At top level the issues that are going to be controlled monitored are…..
- System Physical Resources
- Software Resources of a System
- The Network Resources
- Finally, Analytical Results of Scrutinization.
Module Description:
The System Resource Controller project is designed keeping in view of a Network Administrator’s requirements while administering the LAN. As per the analysis results, the identified tasks should be achieved under single application in a much collaborative way providing complete required information at the finger tips of the Administrator.
During the module design phase, the first two modules concentrate on user interface design for all tasks and privilege verification and authentications. The remaining modules focuses on the different tasks both designing and techniques.
To recall, the identified tasks from the analysis are …
- Gets the list of different domains / sub domains
- Gets the list of different system under domains / sub domains
- Gets the list of system switched ON
- Gets the list of logins (login enumeration)
- Gets the list of processes running on each system
- Gets list of each system startup time (?)
- Get the information about the memory usage of each system
- Get the CPU usage / load of an individual system
- Get the hardware details of an individual system
- Get the software details of an individual system
- Broadcasts messages to all systems
- Sends messages to all systems under specific domain / sub domain
- Sends messages to an individual system
- Kills a process in a system
- Shuts down, Reboot or logs off a system
Module 1: Interface Design
One of the intrigued things while designing the System Resource Controller project is the interface design. It is some kind of one stop solution for the network administrator to perform most of the general and routine tasks.
The SRC has three layers of design …
- Forms, where carefully placed controls are used to achieve different SRC tasks.
- MDI form, which links all other forms together at one place for easy access.
- Dialogs, which help the user / administrator in notifying some key events.
Sample forms are provided in the appendix
Module 2: Privileges & Authentication
In this module, we provide security for monitoring as well as controlling the resources of system under network. Security here is implemented in two stages. Stage one is from the existing Windows Network security policy, and stage two is from the SRC itself.
The Windows Network Security policy will take care of the privileges of different groups identified by the domains. This directly controls the accessibility of the systems under different domains of the same network. These policies can be set by the administrator only once according the organization needs.
The security adopted by the SRC on its own has another authentication system exclusively to access the SRC application itself. Administrator decides the users of the SRC application, along with different levels of access and utilization privileges.
We utilize the System.Web.Security namespace partially here to provide certain level of security.
Module 3: Enumerating Domains & System
One of the preliminary tasks in SRC is to know how many systems are present in the given network. This can be achieved by proper usage of system related API calls in addition to exploiting the.NET network namespaces. Herein this module we are going to enumerate the list of domains present in the network and the systems connected under each domain.
For the purpose of enumerating we are taking the help of system.management namespace, which imbibes the WMI concept. We are concentrating on the following techniques to achieve our targets.
Module 4: Enumerating Users
Similar to the above task, the ‘Enumerating Users’ module also does the similar job. But here we are concentrating on the list of users rather than the systems and domains. This module enumerates the list of users from the Windows Network Authentication. It also gets the details of users and to which groups they belong.
For the purpose of enumerating we are taking the help of system.management namespace, which imbibes the WMI concept. We are concentrating on the following techniques to achieve our targets.
Module 5: Finding the Running Systems & Running Time
This module is little tricky. This module performs two different sub tasks.
- Finding the working systems: This doesn’t mean that all the systems that are switched on. It goes a step ahead and finds out of all the systems that are on, which system is currently working (using system resources to perform some processes)
- Finding the running time: This again is very difficult to find out how much time that each system is working. We are following a way round approach to find this. Our System Resource Controller is going to watch all the systems under network in the background. It notes down the time when the system boots up and shuts down, and calculates the difference to find out the approximately running time.
Module 6: Hardware Details
This module completely depends on WMI concepts to find out the hardware details. The GetObject method of the WMI namespace will be used here. Using this technique we can found the key hardware resource details.
These are the details we are trying to find out using the WMI.
- Motherboard
- Memory
- Hard disc & Logical Discs
- Network card
- BIOS
- Monitor
- Display
- Removable Drives
- Processor
Module 7: Software Details
As in the above module, this module also totally relies on WMI. Similar techniques will be used here to find out the details of software resources. But this doesn’t give accurate results as expected. WMI exposes only the resources that are active. Due to this reason, we can’t list out the software that is not actively running.
In any case, we can find out the OS details, and other software which were running services on OS. The other software information installed on that system can be retrieved as and when that software is running. Another glitch here is not all software products support information exchange through WMI object.
We may use Win32_InstalledSoftwareElement.Software namespace to optimize our search for installed software components.
Module 8: Enumerating Running Processes & Controlling
In this module, we are going to bring out three different things as and when they are running. This doesn’t mean that SRC is going to watch these issues for every second. This certainly adds up the already running processes and becomes extra load on CPU diminishing its performance.
- Processes
- Threads
- Handles
WMI object doesn’t give differentiated list of processes, threads and handles, instead it gives all in a pool. We should programmatically regroup all these. We may even go to the extent of finding the length of each process, or thread in terms of time. The CPU utilization for all these processes will be done in a separate module which will be detailed in
Module 10
We are going to look at these issues, either at pre-defined intervals of time, and results will be logged for future reference or at the administrator click of a mouse button on the corresponding control. Of these the first option is not implemented in the current version, and is planned for the next release.
Module 9: Memory Utilization
This and the next modules are extension of the previous module. These modules use the same objects of WMI along with additional CIMV2 classes and namespaces to find out the memory and its utilization.
Generally, we will display the selected systems memory details under the following heads.
- Page File
- Total Size
- In Use
- In Use (Max)
- Free
- Physical Memory
- Virtual Memory
- Total Size
- In Use
- In Use (Max)
- Free
- Totals
- Processes
- Threads
- Handles
This detailed structure of memory utilization will help the network administrator to find out the optimum utilization of memory. He can also control the memory leaks when some unnecessary processes, handles or threads are consuming extra chunks of memory by killing those. These killing processes, handles and threads will be dealt in same module but under another sub module.
Module 10: CPU Utilization
To find out the CPU utilization, we don’t require any separate WMI object. As said earlier, we can use the Module 8’s objects with little tweaking. We are going to exploit the CIMV2 sub classing options here.
In general, CPU will be used only to do one or the other kind of processing. All these processes can be listed out using the Module 8’s functionality. If we finds out each process, thread or handle’s CPU utilization along with its memory utilization, we can have total and averages of CPU utilization at any given point of time.
Module 11: Broadcasting & Sending Messages
These are the simplest tasks of the SRC project. There is nothing we need to do great programming to perform broadcasting and sending messages to groups of systems or even individual systems.
We can simply use the system calls (nothing but system network related API calls).
Module 12: Log Off, Reboot, & Shutdown
Module 13: Saving the Results
Module 14: Graph Display (*)
Module 15: Reports (*)
Conclusion
The project undertaken is useful for Controlling of System resources.
Useful for maintaining system integrity, functionality and to increase performance of the system.
By the Use of VB.net process for execution makes it easier to work with and also it a very user interactive.
