Contact:[email protected]
==================================================
[DIDS - Distributed IDS Systems]
Creating the Ultimate Security Tools
**********************************
[red0x - Underground Labs]
[mixter - ]
Copyright (C) 2000 red0x, mixter
==================================================
/---------------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
Back to the Index