Linux Server Security (2nd Edition( [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Linux Server Security (2nd Edition( [Electronic resources] - نسخه متنی

Michael D. Bauer

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید







13.3. Other Integrity Checkers


As powerful and useful as Tripwire Open Source is,
it's also complex and CPU-intensive. Furthermore, if
you run "commercial" operating
systems such as Windows or Solaris, no free version is available.
Therefore, two 100% free and open source alternatives to Tripwire are
worth mentioning.

The
Advanced Intrusion Detection Environment (AIDE) is designed to meet
and exceed Tripwire's functionality and is available
from http://www.cs.tut.fi/~rammer/aidel or
http://aide.sourceforge.net. As
of this writing its version number is 0.10, which reflects its youth:
this may or may not have performance and stability implications. (For
what it's worth, based on recent postings to the
AIDE mailing list, AIDE seems to have more compile-time than runtime
issues.) AIDE is 100% free to run on any of its supported platforms,
whether in commercial or noncommercial settings.


IDS, Forensic Tool, or Both?


The premise behind this part of the chapter is that Tripwire and
other integrity checkers can act as burglar alarms when run
automatically at set intervals. Many people run integrity checkers in
this way, as do I (admittedly, on a limited scale). But is this a
reliable IDS methodology?

Not everyone thinks so. In his book Network Intrusion
Detection: An Analyst's Handbook (Sams),
Stephen Northcutt says:


To run a program such as Tripwire once at system build to get a
file-integrity baseline is cheap, easy, and smart. To run Tripwire
every day is costly because someone has to examine the results of the
scan.


In other words, in Northcutt's opinion, you
shouldn't run Tripwire checks routinely: only after
you determine, through other means, that a breach has occurred. This
approach limits Tripwire's role to assisting your
forensics efforts (i.e., figuring out what happened and which files
were affected).Then you're using it more like a
security camera's backup tape.

I personally think using Tripwire only for forensics makes sense if
you have reason to fear attackers skilled enough to trick Tripwire or
you have too many servers from which to monitor frequent lengthy
Tripwire reports. If either condition applies to you, do further
research on the subject and consider a more sophisticated host-based
IDS package such as the free Linux Intrusion
Detection System (LIDS) (http://www.lids.org). Information on LIDS and
many other IDS tools can be found in the
"Tools" section at http://online.securityfocus.com.

A less Unix-centric alternative is Fcheck,
which is available at http://www.geocities.com/fcheck2000/fcheckl.
Fcheck is a Perl script, which makes it both
highly portable and very easy to customize. It's
also extremely easy to configure: the configuration file is primarily
a list of directories and files to scan and files and subdirectories
to exclude. Command-line flags determine which attributes are checked
for all of these: Fcheck has an
"all or nothing" approach. (For
you, that may or may not be a plus.) On the downside, Fcheck has no built-in
cryptographic functionality: unless you configure it to use an
external program like md5sum (part of the GNU
textutils package), it relies on simple CRC
hashes, which are much easier to subvert than cryptographic hashes
such as MD5 or Haval. Nor does it encrypt its database as Tripwire
does. Fcheck was originally designed with
change-control in mind, not security per se.

For this reason, Fcheck's
performance is very fast. While running any integrity checker without
cryptographic hash checks is probably a bad idea on high-risk
systems, it may be justifiable on systems on which you want a nominal
check in place that uses minimal system resources. (Note that
Tripwire can be configured this way, too.) Another mitigating factor is frequency of checks: if your integrity
checker runs every half hour, an attacker has only 30 minutes to
disable or otherwise subvert it before their activity is caught by
the checker. Thus, if using noncryptographic hashes makes it feasible
for you to run checks more often, this might be a sensible trade-off.
If, on the other hand, the system in question has a large number of
local users (i.e., shell accounts), I strongly recommend against it;
such users may be able to learn a lot about the system without
triggering a violation. The weak hash-check method, insofar as
it's ever justifiable, is good only against external
attackers.

By the way, running an integrity checker very frequently is
not likely to help you
catch an attacker "in the act."
This is for the simple reason that there is an inevitable lag between
the time an integrity checker sends a report and the time when
someone actually gets around to reading and responding to it. Rather,
the practical value of frequent checks lies in the fact that the more
frequently your checker writes reports, the more granularity
you'll have to analyze a successful attack after the
fact, which may improve your ability to recover from it.

Of the three tools I've covered here, Tripwire is
the most mature but also the most encumbered from a software-license
perspective. AIDE is completely free, and it has some additional
functionality, but is much less mature than Tripwire.
Fcheck is fast, free, highly portable, and
simple, but also makes some notable trade-offs at
security's expense.


/ 94