Hi out there,
openbsd come with strong mechanisms for prevention of attacks. But what
about the detection of attacks? Attacks still happen and who kows, if
they are successfull or not?
And further more: What about the possibilities to respond? Of course
this strongly depends on the kind of the attack. But detection means
nothing without responds.
Would'nt it be good to have a default intrusion detection system? A
policy for the respond?

IDS are present for a couple of years, so there may be good reasons,
not to integrate them in the default installation. I just don't know
them.


Best Regards
Ralf

On Thu, 14 Sep 2006 03:57:25 -0700, Ralf Müller wrote:

> IDS are present for a couple of years, so there may be good reasons,
> not to integrate them in the default installation. I just don't know
> them.

IDSs are 3rd party applications, which have additional 3rd party build and
run dependencies. Snort and kismet are two IDS applications that are
available from the ports and packages collection.


--
--------
E-mail will only get through if you use my first name before the @

Josh Grosse wrote:
> On Thu, 14 Sep 2006 03:57:25 -0700, Ralf Müller wrote:
>
> > IDS are present for a couple of years, so there may be good reasons,
> > not to integrate them in the default installation. I just don't know
> > them.
>
> IDSs are 3rd party applications, which have additional 3rd party build and
> run dependencies. Snort and kismet are two IDS applications that are
> available from the ports and packages collection.

Yes, but WHY do they have to be 3rd party apps, whereas apache, perl,
pf, lynx, ... are part of the default system?
Ok, pf is switched of by default, just like apache and other things. So
they just behave like an installed Snort. Propably it's about the
freedom to choose the IDS you want or the size of the installation...?

Just wandered, why prevention comes with the default system whereas
detection and response don't.


Thanks
Ralf

On Thu, 14 Sep 2006 06:59:25 -0700, Ralf Müller wrote:

> Yes, but WHY do they have to be 3rd party apps, whereas apache, perl,
> pf, lynx, ... are part of the default system?
> Ok, pf is switched of by default, just like apache and other things. So
> they just behave like an installed Snort. Propably it's about the
> freedom to choose the IDS you want or the size of the installation...?
>
> Just wandered, why prevention comes with the default system whereas
> detection and response don't.

I am not a developer, so this is conjecture:

1. The tools you mention are fairly static. IDS applications, by their
nature, are not.

2. IDS applications have been and can still be subject to attack -- which
is why many IDS vendors and developers recommend that systems installed as
sensors *not* have IP addresses on monitored networks.

3. Implementations of IDS applications vary widely to meet
individual infrastructure requirements. Not only in the number and use
of sensors, but in reporting and management solutions. For example, I
happen to use three sensors, and my particular implementation
requires a full-featured DBMS. Adding a full featured DBMS to the OS
userland would add a significant amount of unneeded complexity, and
increased capacity requirements to installs and upgrades.

--
--------
E-mail will only get through if you use my first name before the @

Ralf M?ller <stark.dreamdetective@googlemail.com> wrote:
> Yes, but WHY do they have to be 3rd party apps, whereas apache, perl,
> pf, lynx, ... are part of the default system?

All these, except perl, have a reasonable size. pf has been developed
by the OpenBSD team, it is not a 3rd party application added to the
operating system.

> Ok, pf is switched of by default, just like apache and other things. So
> they just behave like an installed Snort. Propably it's about the
> freedom to choose the IDS you want or the size of the installation...?

In my humble opinion, the main problem with IDS systems is that attacks
evolve over the time. There is a strong need to maintain an updated
database with information about new threats. On the other hand,
IDS systems are highly complex tools.

I certainly believe on small but useful operating systems. Adding a
lot of third party software to the base system is not an acceptable
goal for most people. In fact, in my opinion it would be nice moving
some of these tools to the ports to make the system smaller (but it
is only my personal taste)... for example, is really Gnu info required
when there is an excellent set of manual pages available? I find it
ugly and mostly useless and outdated, something that remembers me the
OpenVMS help system, but worse. It cannot compare with the exceptional
documentation provided in the operating system man pages. Perl is
useful but too large (and its size increses a lot on each new version!).
I would not complain if it is moved to the ports either. :-) fvwm is
nice, but I would prefer OpenMotif (I like fvwm, but if it is installed
on my systems it is because fvwm comes with the base system, I will not
miss it if it is available on the ports). lynx is an excellent browser
and apache... well, it has been audited by the OpenBSD team over the
years. I would run it on a web server instead of the more up to date
(but less secure) apache releases we can download.

The key here is that if something comes with the OS, users do not have
a chance (currently) to not install it. If it is available in ports,
users can decide if they want or not to install it. It is an advantage.
I would never install fvwm or Gnu info... and perl only on servers
(not embedded computers or special purpose systems).

> Just wandered, why prevention comes with the default system whereas
> detection and response don't.

Detection and response is a challenging area: IDS are too complex,
require updated databases and sometimes make mistakes in the
identification of traffic patterns. Not the class of software
I would like on a high-quality operating system, but certainly an IDS
has a place in the perimeter of a network.

Just my personal opinion... but it is the way I see the BSD operating
systems.

Igor.

Ralf M?ller <stark.dreamdetective@googlemail.com> wrote:
> Hi out there,
> openbsd come with strong mechanisms for prevention of attacks. But what
> about the detection of attacks? Attacks still happen and who kows, if
> they are successfull or not?
> And further more: What about the possibilities to respond? Of course
> this strongly depends on the kind of the attack. But detection means
> nothing without responds.
> Would'nt it be good to have a default intrusion detection system? A
> policy for the respond?
>
> IDS are present for a couple of years, so there may be good reasons,
> not to integrate them in the default installation. I just don't know
> them.

IDSes are very difficult beasts. Some aspects - lack of security, the
need for frequent updates - have already been mentioned. A default
installation is also likely to flag normal traffic as attacks, requiring
fine tuning; and one might want some sort of analysis framework, which
brings in a lot of additional complexity (BASE is fairly well-known in
the Snort world, I believe, and involves PHP and a SQL server; Prelude
is a correlation engine and would most likely involve similar
dependencies).

So, anyone who can get an IDS running smoothly is certainly capable of
installing one from ports. Also, there are very real disadvantages; I'll
name a couple.

For one, the most well-known and probably most useful (at the moment)
IDS is Snort. However, Snort is not available under a BSD license, and
as such cannot be included in the base. Thus, license issues effectively
make this a moot point. (Of course, you can argue this decision, but
that is entirely off-topic.)

Secondly, I've found that an IDS is not too useful. It only catches
known attacks, and - without commercial support (which *is* offered for
Snort, by Sourcefire) - most signatures will be developed quite late in
the game. Of course, commercial support could be used, and the Bleeding
Snort rules may fill the gap, but the first is expensive and somewhat at
odds with the OpenBSD idea, and the latter requires a lot of time and
expertise.
I've personally found that getting a proper log watcher going is more
effective, both in terms of problems caught and in terms of
security/effort ratio.

This is not to say an IDS cannot have its place in a network; but I
would protest any attempt to import it into base, unless it was small,
had few dependencies, was very secure, and actually works.

Joachim

Begin <1158227845.682583.60330@b28g2000cwb.googlegroups. com>
On 2006-09-14, Ralf Müller <stark.dreamdetective@googlemail.com> wrote:
> IDS are present for a couple of years, so there may be good reasons,
> not to integrate them in the default installation. I just don't know
> them.

As already pointed out, an IDS is not a silver bullet, but a complex and
finnicky tool at best. You will only benefit from it if you know what
you are doing, else, well... Search for "goober with firewall" to see
what can happen with even low-end software like a ``personal firewall''
that reports too much, and the wrong things to boot.

In short: IDSen do not lend themselves at all for default deployment.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

Of course, IDSs are pretty complex things and one should always have in
mind, that the whole system should getting better and not worse.
I pointed out the IDSs as an example of detection. Probably there are
more solutions (like the log watcher).
Detection seems to be too complex to have a single tool to get the job
done (like pf for packet filtering).

Anyway,
thanks for the answers

Ralf

jKILLSPAM.schipper@math.uu.nl wrote:
>
> IDSes are very difficult beasts. Some aspects - lack of security, the
> need for frequent updates - have already been mentioned. A default
> installation is also likely to flag normal traffic as attacks, requiring
> fine tuning; and one might want some sort of analysis framework, which
> brings in a lot of additional complexity (BASE is fairly well-known in
> the Snort world, I believe, and involves PHP and a SQL server; Prelude
> is a correlation engine and would most likely involve similar
> dependencies).

The only advantage I see on providing an IDS in the base system,
is that it could use the Berkeley DB (I am more accustomed to NetBSD,
but I suppose that Berkeley DB is available in OpenBSD too for users
management, am I wrong?)

Perhaps an alternative that the original poster would like is the
development of a BSD-licensed IDS that takes advantage of software
currently installed in the base system of BSDs (e.g., Berkeley DB)
without being distributed as a part of the operating system. I see
that usually BSD clones of known tools (OpenSSH, OpenCVS, OpenNTP,
OpenBGPD...) are cleaner and better designed than their counterparts.

> This is not to say an IDS cannot have its place in a network; but I
> would protest any attempt to import it into base, unless it was small,
> had few dependencies, was very secure, and actually works.

I would protest any attempt to import an IDS into base too. IMHO,
an operating system should be small, compact and powerful. In its
current state, all BSDs are excellent OSes... in fact, I would say
that currently some BSD operating systems (and OpenBSD is an example)
have too many packages imported (like Gnu info, that is not really
required as OpenBSD provides the best set of manual pages I have
read in years.) The fewer packages an operating system imports,
the easier it is to maintain.

Igor.

Igor Sobrado <igor@nospam.invalid> wrote:
> jKILLSPAM.schipper@math.uu.nl wrote:
>>
>> IDSes are very difficult beasts. Some aspects - lack of security, the
>> need for frequent updates - have already been mentioned. A default
>> installation is also likely to flag normal traffic as attacks, requiring
>> fine tuning; and one might want some sort of analysis framework, which
>> brings in a lot of additional complexity (BASE is fairly well-known in
>> the Snort world, I believe, and involves PHP and a SQL server; Prelude
>> is a correlation engine and would most likely involve similar
>> dependencies).
>
> The only advantage I see on providing an IDS in the base system,
> is that it could use the Berkeley DB (I am more accustomed to NetBSD,
> but I suppose that Berkeley DB is available in OpenBSD too for users
> management, am I wrong?)

No, OpenBSD seems to use straight dbm, not BDB.

Also, even if BDB were in base, a port could make use of it as easily as
a part of the base system, no?

> Perhaps an alternative that the original poster would like is the
> development of a BSD-licensed IDS that takes advantage of software
> currently installed in the base system of BSDs (e.g., Berkeley DB)
> without being distributed as a part of the operating system. I see
> that usually BSD clones of known tools (OpenSSH, OpenCVS, OpenNTP,
> OpenBGPD...) are cleaner and better designed than their counterparts.

bro-ids seems to be something along those lines; it also seems pretty
dormant...

>> This is not to say an IDS cannot have its place in a network; but I
>> would protest any attempt to import it into base, unless it was small,
>> had few dependencies, was very secure, and actually works.
>
> I would protest any attempt to import an IDS into base too. IMHO,
> an operating system should be small, compact and powerful. In its
> current state, all BSDs are excellent OSes... in fact, I would say
> that currently some BSD operating systems (and OpenBSD is an example)
> have too many packages imported (like Gnu info, that is not really
> required as OpenBSD provides the best set of manual pages I have
> read in years.) The fewer packages an operating system imports,
> the easier it is to maintain.

GNU info is required [1] to read the GCC documentation, for instance.

Joachim

[1] Well, it would of course be possible to convert it; but info happens
to be the native format, and the only other format which would be usable
for this document is HTML. Converting to HTML might or might not be
easy.