An introduction to intrusion detection systems
|An Introduction to Intrusion Detection Systems (IDS)|
IDS stands for Intrusion Detection System, and is a program that will detect and inform you of network misuse, this could range from someone attacking your network to your employees running a Quake server or looking at pornography.
NID stands for Network Intrusion Detection is a real time IDS that will search for signatures in the packets that pass it by.
HID stands for Host Intrusion Detection and is an IDS that will examine log files (such as syslog and /var/log/messages on UNIX machines) on the network host for evidence of an attack or misuse on the clients machine.
When data is sent through a TCP/IP network the data is broken up in to small manageable pieces called Packets.
Host based filtering is a firewall that allows no connections in to the network and it proxies all services the internal network offers, so from the outside it looks like only one machine is on the network.
Each packet contains a header to say, where it is going and on which port and where it came from and from which port. Packet filtering is used by firewalls to stop packets that are intended for a or from a computer or from a or to a port that you don't want to allow access too. It works by reading the packet header.
It currently supports Linux, FreeBSD, OpenBSD, Solaris (x86 and sparc) and is currently been ported it to HP-UX.
This is the question with a long answer and lots of arguments but in a nutshell: UNIX is historically the operating system for servers because it's stable and reliable. It has always been built around the TCP/IP protocol since it was invented in the 70s, which means networking has always been an important part of the OS unlike MS who added it to their OS's in the early 90s. This also means that a UNIX box can be completely administered remotely. UNIX is also capable of being in promiscuous mode on the network without being given an IP address and is therefore harder to see it's presence.
Therefore if you want a platform that can collect every packet that goes by without ever falling over and able to control that machine without visiting it then UNIX is the master. Also in the case of Linux, FreeBSD and OpenBSD then the OS is free or relatively cheap.
No, but Dragon products do compile on those systems. If there is serious interest in running Dragon on systems such as these or any others, please contact Portcullis. All plans to port Dragon Sensor to NT have been postponed until there is more demand for it.
Dragon Fire is the analysis and reporting tool that is used to show the data collected on the Dragon Server. Like the Dragon Rider, it is a web-based program.
A Dragon Sensor is the program that analyses every packet for ones that match it's signatures, so that it will detect if someone is doing something they shouldn't - think of it like a virus scanner but for network miss-use.
Dragon Rider is the program that communicates to the Dragon Server with all the information it has collected. In turn Dragon Rider on the server is used to control and manage each of the sensors connected to it. The Dragon Rider server interface is viewed and control using a web browser.
Dragon server is the central machine that collects all information from the sensors on the network and is able to manage all the sensors using Dragon rider. It also builds a centralised Database of all the events recorded by the all the sensors, which can be viewed using Dragon Fire.
Dragon Workbench is a sensor but instead of monitoring network traffic it can analyse packet log files that are generated with TCPDUMP.
TCPDUMP will grab every packet and log it in a file, so Workbench can work through the file as if it was network traffic.
The best place to put sensors is in key areas of your network. So you might want one in front of the firewall, so you know exactly what you are being hit with. One behind the firewall to detect traffic you have allowed through.
If you are using a VPN you want one behind the machine that decrypts the traffic, as the sensor can't read encrypted packets. This one can be used to see what traffic 'trusted' people are sending you. Then you could have sensors in front of the boxes that you offer services on such as a web or FTP server.
The more sensors the more things you can look for and sensors in certain areas can be made to look for different things. For example, there is no point in having a sensor behind a firewall detecting things you know can't get through the firewall or a sensor in front of the web server that only needs to detect web exploits.
A signature is string of information that the sensor looks for in a packet and if the string matches the signature then it is detected as an event.
How we are going to do this still hasn't been decided. We will, however, give out signatures as library files that can be sent to the sensor from the server. The library files are categorised by type of exploits you are looking for, e.g. a library for web exploits or DNS attacks.
In many cases, the total number of signatures is irrelevant. However, We will provide Dragon customers with several signature libraries. As of early 2000, our libraries were totaling over 1000 unique IDS and network misuse signatures.
We keep track of Bugtraq, Packetstorm and CERT security information. As new vulnerabilities are discovered, signatures are created for them and releases are made available as updates sometimes even on a weekly basis, sometimes quicker than that. More importantly, Dragon's signature format is trivial and adding your own custom signatures takes about five minutes to learn.
No. A large amount of time and energy has been invested in developing useful and innovative signatures to drive the Dragon line of products. Although we acknowledge that nobody "owns" attack information, finding new ways to detect those attacks is proprietary knowledge that gives Dragon products a cutting edge over the competition.
PERL stands for Practical Extraction and Report Language which is a good description of what it does, it's good at extracting information from files and reporting it back to you. PERL is basically a programming language that is widely used on the UNIX platform and web servers especially in things like guest books and CGI scripts are essentially PERL scripts.
Dragon uses PERL, as the install programs are all PERL scripts and it could be used in the web interface programs along with JAVA.
The Dragon Server uses a web server to allow the use of Dragon Fire and Rider, therefore you can point a browser on any machine to the server to control the sensors. However that presents a security problem, therefore you are better hosting the web pages on a SSL server and having some sort authentication certificate. Also because it's a UNIX platform all the sensors/servers can be administered remotely but we would recommend the use of SSH for this task.
No. End customers may mix and match their Dragon sensor platforms with their Dragon server platform.
No. The basic Dragon sensor license allows one copy of Dragon to be operated per computer. Dragon cannot pull packets simultaneously from more than one interface. Monitoring multiple networks from one Dragon sensor violates the license agreement.
No. Dragon works with packets just like TCPDUMP does in that packet are collected from network interfaces and then processed. Dragon Sensors only use libpcap() on BSD systems.
A common misunderstanding is that firewalls recognise attacks and block them. This is not true. Firewalls are simply a device that shuts off everything, then turns back on only a few well-chosen items. In a perfect world, systems would already be "locked down" and secure, and firewalls would not be needed. The reason we have firewalls is precisely because security holes are left open accidentally.
Thus, when installing a firewall, the first thing it does is to stop ALL communication. The firewall administrator then carefully adds "rules" that allow specific types of traffic to go through the firewall. For example, a typical corporate firewall allowing access to the Internet would stop all UDP and ICMP datagram traffic stops incoming TCP connections, but allows outgoing TCP connections. This stops all incoming connections from Internet hackers, but still allows internal users to connect in the outgoing direction.
A firewall is simply a fence around your network, with a couple of well chosen gates. A fence has no capability of detecting somebody trying to break in (such as digging a hole underneath it), nor does a fence know if somebody coming through the gate is allowed in. It simply restricts access to the designated points.
In summary, a firewall is not the dynamic defensive system that users imagine it to be. In contrast, an IDS is much more of that dynamic system. An IDS does recognise attacks against the network that firewall's are unable to see.
Another problem with firewalls is that they are only at the boundary to your network. Roughly 80% of all financial losses due to hacking come from inside the network. A firewall at the perimeter of the network sees nothing going on inside; it only sees that traffic which passes between the internal network and the Internet.
Some reasons for adding IDS to you firewall are: