==================================================

[DIDS - Distributed IDS Systems]

Creating the Ultimate Security Tools

**********************************

[red0x - Underground Labs]

[mixter - <mixter@newyorkoffice.com>]

==================================================

/---------------Legend----------------\

| (?) = not sure if I’ll include this |

| (V) = verify |

\-------------------------------------/

Prelim Outline:

A. Intro

1. What This is About

2. Terms

a. SPOF = [S]INGLE [P]OINT [O]F [F]AILURE

b. IDS

c. DIDS

d. Firewall

e. Topography

f. Router

g. Secure

h. Insecure

3. Linux

a. What

b. Why

c. Where

d. How Much (FREE)

B. Common IDS Methods

1. Tripwire

a. Pros

i. Detects File Changes

ii. Detects unauthorized users

iii. Can keep lists of users

iv. Can log commands

b. Cons

i. DDoS

ii. Annoying

iii. Dumb

iv. No Network Protection

v. SPOF (only on one host at a time)

2. Snort

1. Pros

i. Easily detects unauthorized connects

ii. Logs portscans

iii. Can block Backdoor attacks

iv. Blocks DDoS

v. Firewalls

2. Cons

i. Signature Files

ii. Promiscuous Mode

iii. DoS

iv. No file protection (tripwire style)

v. Hard to configure for Beginners

vi. SPOF

3. Firewalls

1. Pros

i. Block Services

ii. Block IP Ranges

iii. Secures entire network

iv. Transparent

2. Cons

i. Hard to configure

ii. Non-Dynamic (wont adapt, usually)

iii. Remotely Configurable (Hackable)

iv. Non-Transparent

v. Only on Your Router

vi. SPOF

vii. Firewalking

C. New/Rare Methods

1. Spider Nets [spidernet - mixter.void.ru]

1. Pros

i. Distributed Across Network

ii. Incoporates Tripwire Style IDS

iii. Central Logs

2. Cons

i. Weak as Standalone Security System

ii. Central Log Server is a SPOF

iii. User-Space Process

2. Echelon [e4d - mixter.void.ru]

1. Pros

i. Sniffs ALL Traffic for Sensitive Data

ii. Central Logs

iii. Non PROMISC Sniffer

2. Cons

i. Reactive, takes no action, just logs

ii. Data to be sniffed for can be reversed out of the code.

iii. Central Log Server is a SPOF

iv. Non PROMISC Sniffer

v. Unencrypted Logs

vi. User-Space Process

3. Heuristics Scanning [ewatch - http://www.eecs.harvard.edu/~rtm/README-ewatch.html]

1. Pros

i. Scans ALL Traffic

ii. `Learns' to recognize traffic

iii. Recognizes `bad' traffic

iv. Logs `bad' traffic

2. Cons

i. Takes a while to learn (your network must be secured) (V)

ii. No Protection (Firewalling)

iii. User-Space

iv. Annoying

v. Local, SPOF (kill -KILL pid)

D. Designing a Good System

1. What to Avoid

i. Single Point of Failure (SPOF)

ii. Central Log/Config Servers

iii. Self/Net-DoS/DDoS

iv. Raw Logs

v. User Space Processes, if possible

vi. Plain-Text Net Traffic, always

vii. setuid, setgid executables, if possible

2. What to Include

i. Possibility to Distribute (DIDS)

ii. Good Topography

iii. Good IP Logging

iv. Encryption of Logs

v. Encryption of Net Traffic

vi. PROMISC/RAWSOCKS Capability

vii. Intelligence, if possible

viii. Heuristics

ix. Firewalling

x. Tripwire Style IDS

xi. Inter-Agent Communcations

xii. Host Disconnection

xiii. Anti-DoS/DDoS/Flooding

E. Enter Agents

1. What is DDIS? (Agents)

2. Why DDIS? (Agents)

i. Pros

a. No Single Point of Failure (Distributed)

b. Hard to beat

c. Adaptive

d. Insecure Host Disconnection

e. Tripwire Style IDS

f. Spider Net Style NIDS

g. Firewalling

ii. Cons

a. User Space

b. Static Code

c. Not too Intelligent

d. Spoofing (?)

e. Slow Probe Intervals (?)

F. Conclusion: What to expect from distributed IDS (DIDS)

1. Is DIDS Better Than Any Other IDS For My Network

i. Topography

a. Ring

b. Star, Star^n

c. Backbone

d. Others (?)

ii. OS

a. Linux (see terms section for more info)

2. How Is It Better?

i. Pros

a. Distributed Across All Hosts (No SPOF)

b. Encrypted Net Traffic

c. Encrypted Logs on All Hosts (NO SPOF)

d. PROMISC/RAWSOCKS Capability

e. IDS and Inter IDS Communications

f. Heuristics

g. Good Logs

ii. Cons

a. User Space

b. Static Code

c. Sniffable

d. setuid/gid (?)

e. PROMISC in Star Topography on unswitched Networks

3. Where Can I Get a Taste of DIDS?

i. Free Agents NIDS [sourceforge.net/projects/freeagent]

ii. Agents [december Scientific American, "Red Team versus the Agents"]

iii. Any others?

G. Notes, Thanks, Etc.

*************************************************************************************

[1. What This is About]

The Internet today has become a place where security is constantly in question;

every hour, just about, it seems there is another exploit out for the most popular service.

No one can be completely secure. But, one can try. This paper will outline some popular

(well known) and not so popular (rare) security schemes that have been noted. This informational

paper is provided as-is, with no warranty, either expressed or implied, of any kind. The reader

chooses what he/she will do with the knowledge contained herein, and the author, host, and

contributors take absolutely no responsibility for the readers' action(s). There, now that that is

done, lets move on.

[2. Terms]

Some terms you may find helpful to know, which are used in this paper, are defined below.

If you know all of them, feel free to skip ahead. These terms are here to help you understand this

document.

[a. SPOF]

A SPOF, or Single Point Of Failure, is a single host, program, log, -- whatever --,

such that, if that Point is compromised, your whole network IDS is in jeopardy.

In other words, say you have an IDS system that reports to a central log server, if

that log server gets compromised, the whole IDS is invalidated, and you now have 0

security.

[b. IDS]

An IDS is an Intrusion Detection System. These can range from firewalls to programs

that search for `wierd' traffic on your network. These alert the administrator of

suspicious activity on his computer/network. These systems are what this paper is

about. Read on.

[c. DIDS]

A new term, coined by red0x. A DIDS is almost the same as an IDS, with one exception:

A copy of the DIDS program is distributed to [close to] every host on the network you

want to secure (hence distributed). These take many forms, but generally, they

communicate amongst themselves and have the ability to shut compromised hosts off from

the rest of the network. Pretty spiffy, eh?

[d. Firewall]

A firewall sounds scary, like a hacker's tool almost. But, its not (if you think that,

stop being so stupid and narrow minded, read packetstorm.securify.com papers). A

firewall is a program or piece of hardware that sits on your network (usually close to

the boarder) and blocks access to certain services on your network from the outside

world, blocks IP ranges from accessing your network, can hook your entire net into one

single IP address [NAT], and can generally be reconfigured from the network/internet.

[e. Topography]

Any network admin should know this. The topography of your network is how it is layed

out. If you use hubs to hook up your net, chances are, your topography is `star.' If

you use switches, it is still probably `star'; BNC cables, most likely ring; a fiber

router hooked to some other routers and hubs, probably 'backbone.' You should get the

idea by now. If not, go look online for +"Network" +"Topography". That should help.

[f. Router]

A router is a piece of hardware that forwards packets to where they should go. This is

how the internet works. Routers choose the best route (figure that one out) to the

destination host, send the packet that way, and return it when it comes back.

[g. Secure]

Secure implies that a certain host or network is either 1) detached completely from the

net, 2) Protected behind a single IP address and many access controls, or 3) reasonably

unhackable. Hackers will argue that nothing is unhackable; this is true. That is why

I said, 'reasonably.'

[h. Insecure]

Insecure inplies that a certain host or network either 1) has been hacked, 2) is not

protected in any way, or 3) is not reasonably secure.

[3. Linux]

[a. What]

Linux is an opensource operating system that the greater part of smart internet server

admins use. I say smart, because the dumb ones use Windows NT or the like. That is

not smart for many reasons: 1) It is not opensource, therefore, the code has not been

audited, 2) it is REALLY expensive, compared to linux's hefty price of $0, and 3) Windows

crashes WAY more than linux or BSD (if you dont know, dont ask).

[b. Why]

Linux is good for servers. I wouldn't give linux to your staff, they probably wouldn't

know how to use it. But, I would put it on your company's servers, instead of Windows.

The reasons are simple: 1) Free upgrades, 2) security updates, 3) Linux is free, 4) the

damn thing WONT CRASH, and 5) it is open source, so you can easily reconfigure it for

your network's needs.

[c. Where]

www.linux.org

www.opensource.org

www.slackware.org

www.redhat.com

www.valinux.com

Search for it, but be warned, there are many flavors of Linux. Try them all if you want.

But, this isn't a linux add, so on with the show.

[d. How Much]

Linux is absolutely free to download, my man, but buying it usually comes with support,

and that cost depends on what flavor. I wouldn't recommend Redhat for secure networks.

If you want really secure, get BSD, but for linux, try Slackware. Look around for more

info.

[B. Common IDS Methods]

Today, there are lots of IDS systems. We will only talk about the linux ones. Most of the IDS

systems I've seen for linux are one of two sorts: 1) Host-Based, 2) Port-Based. First of all,

lets discuss Host-based, then Port-Based.

[1. Tripwire]

Tripwire is a Host-Based IDS system. That means that Tripwire sits on your computer

monitoring file changes. If it records changes, it logs them and alerts you. Then,

you, as the admin, can see what happened.

[a. Pros]

Tripwire, and the like, easily detect file changes. They use signatures held in

either every directory or in a central location (SPOF). Some types of this kind

of IDS can detect logins by unauthorized users -- you have to tell it what that

means though. Also, most can and will keep logs of who is online and who is

changing what file. I'm sure you could also get some that log command lines

on a per-user, per-session bassis.

[b. Cons]

Say you are running Linux, and you want to upgrade you X-Windows servers. You

go download the new code. Tripwire alerts you of file changes... You extract

the code. Tripwire... You configure and compile. Tripwire for everyfile...

This can get alittle annoying and can easily cause a DoS of syslog, hiding stuff

that should get in it. That is bad, in case you didn't figure that out.

Tripwire and it's variants are dumb, in programming speek. They can't usually

tell the difference betweem what was meant to be changed and what wasn't. So

it alerts you about all of them. Also, even worse, any person could hack into

your system by guessing a password of one of your users, and Tripwire wont alert

you. Why? Because no files were changed. That is also bad. Even worse, if you

store your file signatures in one directory, what if the hacker deletes them?

That is a SPOF.

[2. Snort]

Snort is my favorite firewall type program. If you want one, its free, and damn-good.

www.snort.org, check it out. What it does is sit on your machine, probably close to your

border, listen for packets in PROMISC mode (if you dont know what that is, move on), and

takes the appropriate action based on the packet's contents.

[a. Pros]

Snort, and the like, can easily detect connection attempts to ports you

specify to block. It can also, easily, detect portscans, even stealth ones.

After it detects these, it can block access from the originating host. Also,

snort keeps a signature file [SPOF] for the currently known attacks and if

any packets match the signature, they are dropped. This eleminates most backdoor

attacks from your network. But hackers know how to program backdoors and could

easily change one to evade the signatures.

As far as I know, snort has signatures of packets that could start a DDoS of your

or somebody else's machine/network, and will block them. Good stuff, huh?

Snort, and variants, can also be used like any firewall to block IP ranges, ports,

etc.

[b. Cons]

The signature file is snorts first con. If somebody develops a new attack, keeps

the code private, and never uses it, except against you, snort might as well be

a backdoor. It will let that go right on and continue. This is bad. Not only that

but the files are a SPOF, if they get deleted, there goes your protection until you

make new ones. Snort works in PROMISC mode, meaning it grabs ALL packets on your

unswitched network. Bad idea for some people who want to run a secure network.

If you have the right skills, you could reverse engineer snort to dump the packets

if they contain sensitive data, a possible security compromise. Snort also has DoS

vulnerabilities, pretty much all IDS' do. I'm not sure about them exactly, but

I'm sure they are there. Another con, snort offers no tripwire style protection.

What if somebody comes and changes your .rhosts file to contain "+ +", your host

is now insecure, and all the traffic to exploit that could get past snort.

Snort's Achilles heel is that it is tough as hell for beginners to use. What about

a manual, guys? If you run snort on your border, and somebody who works near it

goes over and types "killall -KILL snort", your entire network is compromised now.

Bad to have such a drastic SPOF.

[3. Firewalls]

Everyone should know what a firewall is. The most common for `secure' networks is the

hardware flavor. The smartest admins put these close to the border of the network, before

the internal network. This allows for the best coverage. Also, if you have separate

sub-networks, you may want to put on between these nets and the main network at your site.

These firewalls are capable of blocking IP ranges (*.*.*.* is good for security),

ports, services, and protocols. It is a good idea to only let incoming TCP/UDP and block

everything else.

[a. Pros]

Firewalls are good at your border because they can block the outside net from using

certain services that you mark for blocking. So, anyone not `behind' the firewall

can't connect to the specified port of ANY machine behind your wall. Another

pro is that it can block IP ranges. So if you read your logs and see evidence

of an upcomming attack, you can start blocking the IPs, totally. Not only that,

but a firewall secures your entire network, just by being at the border. That

is the best benefit of a firewall. Even more advantageous is the ability to become

transparent on the net. Firewalls can (and should) block ICMP, which will give

the impression that your host is down to IP range scanners (a plus). Also,

firewalls can port redirect, so you can have one machine serving ONLY port 80

of your single public IP address (saves money), while another machine is serving

FTP. That way, each of your services is secured from the rest, making it harder

to identify what OS you are running (taking such messages out of connection

banners is a good idea.

[b. Cons]

Firewalls are a pain to configure and update; it all must be done by the user

and usually from the command line using such ambiguous commands as

`ipchains -A ....' You may have no idea what it is doing. Also, firewalls wont

adapt to your network, so if you use 192.168.*.* for one subnet, and then add

another 10.*.*.* subnet, your firewall will have to be reconfigured to use that

new subnet, a slow and annoying process. A big minus for firewalls (the hardware

flavor) is that most can be remotely configured. If you choose a bad password,

any hacker could guess it, change your configuration to leave your entire net

exposed, and hack in using a method that was previously secured. Also, some

firewalls wont be transparent, so it is possible to bypass them (if your net

topography allows). An example is you bought an IP block 165.67.234.*, you

put up your net, and your firewall is on 165.67.234.1 and router is on

165.67.234.2, not directly connected, but through a hub, to your firewall. If

your router is misconfigured, that firewall will do nothing at all. Also, a

firewall is usually on its own machine (software), your router (software), or

hooked in by itself. That is an SPOF. Break the firewall, and the entire net

is compromised, bad idea. Also, a new technique has been developed called

firewalking. You can read more on packetstorm [link]. Basically, it gets

your network layout without setting off alarms and bypassing filters in your

firewall. Pretty spiffy, huh?

[C. New/Rare Methods]

Some new methods, mostly good ideas, have been developed. These methods are generally mixtures

of the aforementioned methods that add pros and reduce the amount of cons for each. Basically,

most of these methods are good things to have, in addition to your current IDS system.

[1. Spider Nets [spidernet - mixter.void.ru]]

This is something I have never seen before coming to mixter's site. Mixter came up

with the idea of having multiple Host-Based IDS (tripwire style IDS) `talk' to

each other. Pretty Spiffy, huh?

[1. Pros]

The first and most important thing about this method is that it is distributed.

A big plus! This way, there is no SPOF. All the spiders on the network talk

to a log server and to each other (V). Another good thing, is not only

can you have it do echelon style monitoring (discussed below), but you

can also incorporate Tripwire Style IDS. Also, there is a central logs server,

that will encrpyt the logs, etc.

[2. Cons]

The downside is that this is weak as a standalone security system. So you have

a bunch of computers with logs going out to other places, big deal. A real

hacker can easily get around this. :O) Also, the central logs server, if

implemented, is a big SPOF. Lose your logs and you lose your protection.

Even worse, arguably, is that spidernet runs as a user-space process, so

a simple 'killall -KILL spiderd spidermon' would to the trick to effectively

disable this IDS. Good idea tho.

[2. Echelon [e4d - mixter.void.ru]]

One of my favorites, you could call it a distributed sniffer. Sound like a good idea,

well it is. Especially if you want to see what computers on your net are access what

information.

[1. Pros]

Some good things about echelon is that is sniffs all the traffic at the socket

level (IP only). It can read emails, telnet sessions, X windows, everything

that isn't encrypted (and that too, but it wont b/f the key for you :p).

Another plus is that the logs can be stored both on and off site. Sound good?

Even better for unswitched networks in the star topography is that this IDS

uses NON-PROMISC sniffing techniques, so you wont get a bunch of repeat data

in your logs. Even better, all communications to the log server are encrypted

using aes. :O)

[2. Cons]

Echelon is good, but not that good; here's why. Echelon is very NOT proactive.

all it does is take logs of what and from/to where data is going by. And not

all data, only data you enter into the source code. Another minus: you could

conceivably reverse the sensitive data that you sniff for out of the sniffer

itself. Another bad thing, this system uses a central logging server, another

SPOF. If you want to know what information is going past your router, echelon,

at least in mixter's implementation, is not for you. It doesn't use PROMISC

mode, remember, so it only sees data bound for it. Not only that, but the

data in the logs ins't encrypted. The most common minus is here too: echelon

runs as a user-space process. 'killall -KILL e4d' = bye, bye echelon.

[3. Heuristics Scanning [ewatch - http://www.eecs.harvard.edu/~rtm/README-ewatch.html]]

This is a cool project, because it actually works like modern virus scanners. It

searches your net traffic looking for interesting changes in behaviour. If you dont

usually do zone transfers, and one hits your DNS server, this takes note and flags

you down. Pretty good stuff here. Great combined with a firewall and a tripwire!

[1. Pros]

I don't know much about this project, so here are some good things about

heuristics:

i. Scans ALL Traffic

ii. `Learns' to recognize traffic

iii. Recognizes `bad' traffic

iv. Logs `bad' traffic

[2. Cons]

Here are some bad:

i. Takes a while for it to learn (your network must be secured during that

time) (V)

ii. No Net Protection (Firewalling)

iii. User-Space (killall -KILL ewatch = bye, bye)

iv. Annoying at first (flags you down alot)

v. Local program = SPOF

[D. Designing a Good System]

On to the good part, here are some helpful hints to take to heart when you are designing

a new IDS system. Listed are things to avoid, include, and what to expect.

[1. What to Avoid]

At all costs, try to distribute your IDS throughout your network, avoiding a SPOF.

DO NOT EVER make IDS systems with central configuration servers. Logs servers

are ok, but not configuration servers. If they get compromised, your whole entire

IDS and network is compromised. Bad idea. Try to avoid the possibility for your

IDS to flood itself, the console, syslog, or hosts on the net. Extensive testing

and debugging should be able to find all such occurances and weed them out. At

all costs, avoid storing raw logs. MD5 sum all logs, keep them in a secure directory

(umask 700), and encrypt them. If at all possible, try to avoid developing IDS that

run as user-space processes. This will avoid the 'killall -KILL program' SPOF.

Always, Always, Always avoid plain-text net traffic, especially when using DIDS.

The reason is just common sense, you have the element of surprise. If you can,

try avoiding developing code that must be run as root or setuid/setgid. This

will usually help you avoid developing remote exploits (buffer overflows).

[2. What to Include]

Some things to include in your IDS:

A major design feature is the ability to distribute your IDS (thus making it a

DIDS). Once the size of your IDS is dynamic, so is your measure of security. You

can run it only on your router machine, or you can put a copy on every host on

your net, and they all will `talk' and help secure your network from the inside,

even if one host gets compromised. Try to pick a good setup for your topography,

make the IDS fit you, not vice versa. If you use a backbone system, an IDS using

a PROMISC sniffer on the backbone would be wise. If you use an unswitched star

topography, dont use PROMISC mode, or all the hosts will have exactly the same logs

(although, that could be good...). Always include good IP logging for questionable

packets. It is a good idea to add that last measure of security (even though

spoofing is easy as 1-2-3). Encrypt your logs, that is a must. Also, a good idea

is to encrypt and sign your network IDS traffic. This way, it is harder to forge.

Try to include the capability to be switched from PROMISC mode to raw sockets at

compile time WITHOUT changing encryption keys, etc. That way making more nodes for

your DIDS is easier. If you have the code-fu, try to get your nodes to think, whether

using heuristics, neural nets, or just plain lisp, intelligent `agents' are better

than dumb nodes. Even without intelligence, heuristics is good to have. It is

almost a rule now to make IDS that can interface with firewalls and reconfigure

them at run time. That is a good practice and can save the network admin a lot of

time. Another good idea is to include tripwire style IDS functions in your new DIDS.

This allows for the system to tell some other system if it has been compromised, and

to dynamically shut it off from the rest of your net, saving the admin from hell.

Try to have the nodes, or `agents,' talk to each other and tell each other useful

info, like 'hey agent 0193a, i'm insecure, shut me down.' Then agent 0193a will

mark that system and agent as `evil,' add that hosts to hosts.deny, firewall him out,

and tell all the other agents to do so as well. Pretty spiffy, huh? This implies

that the nodes of your DIDS must be able to block traffic from or to specific hosts.

That is definitely a good thing to include. Another wise thing, is the spoofing

capability to shut down SYN floods (close half-open connections by spoofing FIN/RST

packets, etc.) and block other DoS/DDoS/Flood attacks.

[E. Enter Agents]

We have an idea. To make an IDS system that isn't standalone, its distributed. It isn't

just host-based, its also network based. It doesn't use signatures, it uses heuristics.

Enter Free Agents NIDS [sourceforge.net/projects/freeagent]

[1. What is DDIS? (Agents)]

What the hell are agents? Think of the IDS (DIDS) we were just talking about.

Each node, if it had some intelligence, would become an agent. The good thing

about agents is that you can put one on every host on your network, and they will

all talk, and learn, what is good and what is bad traffic. Also, they can tell

each other if they have been compromised, and therefore, dynamically re-secure

your network. So why would you want this kinds of Distributed IDS? (DIDS)

[2. Why DDIS? (Agents)]

The reasoning is simple. Here is your network, a huge backbone with stars off

the main fiber.

[your network]

* <- secured, classified host/net (G)

[===[=]=====T1-backbone======[=]============[router]==={NET}--

* <- 10 normal hosts (a-j), j is trusted by G, but none other.

fig. 1

Imagine someone compromises your web host, a, and this hack goes unnoticed. That

hacker could then easily break into anyother host, except G. So that hacker then

uses the finger system to find any sort of trust relationships the a-j may have to

secured host G. Boom! Our hacker finds that G trusts only j. So, easily perpetrated

from behind the firewall software on your linux router, our valiant hacker compromises

j, and no one notices that either. Well, my friends, all our hacker has to do is rlogin

over to G and he could easily bounce the data through your own network (to avoid your

IDS firewall and sniffer), to a third party, already hacked web host, and through a

private, unlogged proxy, into his home computer. Good luck cleaning that mess up.

With a DIDS, you would've caught the problem as soon as the hacker got host a. If not,

the heuristics would've notified you about the finger attempts from inside. That,

my friend, is why you would want DIDS as opposed to a vanilla IDS.

[i. Pros]

Obviously, on a true DIDS, there is no SPOF. As illutrated above, this IDS is

very hard to beat. Not only that, but it could adapt to your network and the

common traffic that is used. The number one advantage (i think) of DIDS is

the insecure host disconnection. As soon as one host is deemed compromised, the

entire network if your DIDS shuts that host outside of the firewall (if possible),

and blocks all communications from/to it. Neat, huh? :p The way the DIDS

would detect if its host was compromised is using a tripwire style IDS. Changes in

files will alert the network that something is up. This DIDS also includes the

spider net style NIDS. All the nodes (agents) communicate with each other and

watch out for you network's security. The capability to place a node (agent) on

your linux router/firewall increases your security from the outside too! If host

'a' and your router had nodes from your DIDS, host a could've told the router,

in the SYN flood case, that it was being flooded by X.X.X.X, and the router

could've been reconfigured to block that address. Nice, eh?

[ii. Cons]

Free Agents isn't all pluses. The biggest offset to its power is that, for now,

it runs as a user space process ('killall -KILL agent' = no more node). Although,

the other nodes could be configured to take that as a sign of attack (if the host

is still online). Another downfall is that the agents never evolve; the code

is static. The only way to make it smarter is to upgrade. Not only that, but

there is a limit to how smart C programs can be. :( Another possible downfall

could be attributed to agent spoofing. Although we dont even have a working agent

yet, it is always possible to spoof something. We're working on solutions.

[F. Conclusion: What to expect from distributed IDS (DIDS)]

This can only be answered on a per network basis. But in general, here are some questions that

we can answer:

[1. Is DIDS Better Than Any Other IDS For My Network]

That all depends, what topography, is it homogenous, what OS are you using, and how

is it set up?

[i. Topography]

[a. Ring]

Good idea to have at least a node of tripwire and a NIDS on each host.

Not important to have agents, but it is a possibility.

[b. Star, Star^n]

Sure, DIDS would be great here, just be sure to turn off PROMISC mode if

your network is unswitched.

[c. Backbone]

A great idea to put an agent on each host. Put the ones on the backbone

in PROMISC while the ones on the side nets, if unswitched, should be

on raw sockets mode, otherwise, put them all in PROMISC.

[d. Others (?)]

Use the general rules outlined in the following sections about what

to include and to avoid.

[ii. OS]

What operating system are your hosts using? Currently we are only developing

for linux, but once done, there will be Sun, BSD, HP, and windoze ports

(i hate bill...).

[a. Linux (see terms)]

[2. How Is It Better?]

Read above. Here is an outline for those of you who skipped (read: attention deficit)

[i. Pros]

a. Distributed Across All Hosts (No SPOF)

b. Encrypted Net Traffic

c. Encrypted Logs on All Hosts (NO SPOF)

d. PROMISC/RAWSOCKS Capability

e. IDS and Inter IDS Communications

f. Heuristics

g. Good Logs

[ii. Cons]

a. User Space

b. Static Code

c. Sniffable

d. setuid/gid (?)

e. PROMISC in Star Topography on unswitched Networks

[3. Where Can I Get a Taste of DIDS?]

Look here:

i. Free Agents NIDS [sourceforge.net/projects/freeagent]

ii. Agents [december Scientific American, "Red Team versus the Agents"]

iii. Any others?

[G. Notes, Thanks, Etc.]

-- red0x