General security

HIDS—A Simplified Design Construct

This article will briefly discuss the host-based intrusion detection system (HIDS) and an abstract approach that can be used to design an application firewall.

As per OSSEC, HIDS is an application-level firewall that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting, and active response. This is installed on a single server machine and its agents are deployed on the server that needs the service (protection).

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

Simple Deployment Scenario

Instead of focusing on definitions, types or various deployment, this article will focus on the design of the HIDS and how, with some simple programming knowledge, you can design your own free-of-cost IDS.

First, the basics of an operating system will help us understand the core functionality. Any operating system logs process activity within its domain to keep tab on the activity and maintain accountability. In the Windows family, the logs include application logs, system logs, and security logs. Click Start, and then click Control Panel. Click Performance and Maintenance, then click Administrative Tools, and then double-click Computer Management. Or, open the MMC containing the Event Viewer snap-in. In the console tree, click Event Viewer. The application, security, and system logs are displayed in the "Event Viewer" window.

In the Unix family, the syslogs reside at various locations, depending on the flavor. In RHEL you can find the logs under /var/log/messages, /var/log/secure, /var/log/wtmp, etc.

Regardless of which operating system, the logs collect all the information regarding application, security, and system. For example, when a user logs in to the system, a log is generated in the system.

In case of RHEL.

Now here is a simple plan to develop the IDS.

Now let's roll into the actual implementation part. I would be running this part with RHEL 5. Though the basics remain the same, as I mentioned, only the path for logs will change depending on the flavors of the OS.

Let's add a user to generate logs:
# USERADD TEST

This command will add a user. To confirm this, we can look at the entry in the passwd file.

# CAT /ETC/PASSWD

Running this command will generate a log in the secure file:

Now try changing the user ID:

The corresponding log generated is:

The key part here is to observe the syntax of the log generated and develop a simple script to tap this format and log it. From the above examples, when we add a new user the syntax is:

[c]

USER ADD -> “useradd[**]: new user: name=**, UID=**, GID=**, home=**, shell=**”

USERMOD -> “usermod[**]: change user ‘**’ UID from ‘**’ to ‘**’”

[/c]

This syntax formatting varies for different flavors of the UNIX, so this needs to be optimized accordingly when you go for an enterprise edition.

We can search for specific key word using a Perl script:

[html]

open INPUT, "<filename" or die "File not foundn";

while () {

s/th/TH/gi;

print $_;

}

close INPUT;

[/html]

You can echo the line that matches the criteria that you provide and this can form output to the Java console.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan