intrusion detection/prevention

[Ryan Pugatch-4]

Hi all,

Looking in to my options for intrusion detection and prevention. Top of
the list, of course, is Snort either open source or on a Sourcefire
appliance.  I am wondering if anyone has any suggestions or
recommendations.

Thanks

--
Ryan Pugatch
Systems Administrator, TripAdvisor
_______________________________________________
Discuss mailing list
Discuss@...
http://lists.blu.org/mailman/listinfo/discuss

[theBlueSage]

On Tue, 2009-06-30 at 13:22 -0400, Ryan Pugatch wrote:

> Hi all,
>
> Looking in to my options for intrusion detection and prevention. Top of
> the list, of course, is Snort either open source or on a Sourcefire
> appliance.  I am wondering if anyone has any suggestions or
> recommendations.
>
> Thanks
>


I have personally used tripwire, portsentry, and snort / Oinkmaster over
the last several years ...and have now dropped everything except
Snort/Oinkmaster. TRipwire annoyed me as it emailed me masses of stuff
everyday about what had NOT changed. Portsentry tended to clog up the
iptables with things it found bothersome, which meant I kept having to
flush the tables. I could have set it to 'no action', but then what was
the point?

Sort and OinkMaster are a good answer for me, YMMV :)

Richard


_______________________________________________
Discuss mailing list
Discuss@...
http://lists.blu.org/mailman/listinfo/discuss

[Tom Metro-16]

ref wrote:
> TRipwire annoyed me as it emailed me masses of stuff
> everyday about what had NOT changed.

When I used Tripwire I also found that it required a lot of maintenance
in order to make it provide useful reports. If you don't keep up with
it, it ends up flooding you with useless reports (reporting the same
changes over and over), which leads to the reports being ignored.

Most file system change detection tools work on a model where they set a
baseline and then once they detect a deviation from that baseline, they
email you perpetually until that baseline gets reset. This is the
secure, paranoid way to do it, but not particularly practical.

Back when I set up my first Debian system I went looking for something
simpler than Tripwire, and ran across Integrit, and have been using it
ever since, even though it remains fairly obscure. It was easy to set
up, and with a few tweaks to to its cron script, I was able to have it
automatically reset its baseline after changes. This eliminates
maintenance effort, and it only generates reports if there have been
changes since the last change occurred, so most of the time it stays quiet.

Note that although these file system change detection tools are often
promoted as intrusion detection tools, they're actually more beneficial
for routine system administration by providing a record of what system
files changed when. This can be useful if system behavior changes and
you want to track down when a config was modified or when some upgrade
changed a shared library.

  -Tom

--
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/
_______________________________________________
Discuss mailing list
Discuss@...
http://lists.blu.org/mailman/listinfo/discuss

[Dan Ritter-2]

On Tue, Jun 30, 2009 at 04:02:51PM -0400, Tom Metro wrote:

> ref wrote:
> > TRipwire annoyed me as it emailed me masses of stuff
> > everyday about what had NOT changed.
>
> When I used Tripwire I also found that it required a lot of maintenance
> in order to make it provide useful reports. If you don't keep up with
> it, it ends up flooding you with useless reports (reporting the same
> changes over and over), which leads to the reports being ignored.
>
> Most file system change detection tools work on a model where they set a
> baseline and then once they detect a deviation from that baseline, they
> email you perpetually until that baseline gets reset. This is the
> secure, paranoid way to do it, but not particularly practical.

It's the only really useful way. There are two tricks:

- make it easy to reset the baseline
        - a single word alias is best

- map exactly what parts of your filesystems you can ignore
        - in particular, you need to have the monitor
          automatically ignore logs, temp files, pidfiles, mail
          spools and user home directories

> Back when I set up my first Debian system I went looking for something
> simpler than Tripwire, and ran across Integrit, and have been using it
> ever since, even though it remains fairly obscure. It was easy to set
> up, and with a few tweaks to to its cron script, I was able to have it
> automatically reset its baseline after changes. This eliminates
> maintenance effort, and it only generates reports if there have been
> changes since the last change occurred, so most of the time it stays quiet.

Integrit is pretty good. So is AIDE.

> Note that although these file system change detection tools are often
> promoted as intrusion detection tools, they're actually more beneficial
> for routine system administration by providing a record of what system
> files changed when. This can be useful if system behavior changes and
> you want to track down when a config was modified or when some upgrade
> changed a shared library.

Though there are three better tools:

- keep your configurations in a version control system
- and/or keep snapshots of your configurations (or whole
  filesystems)
- look in your OS package installation log (/var/log/dpkg, for
  instance)

-dsr-

--
http://tao.merseine.nu/~dsr/eula.html is hereby incorporated by reference.

You can't defend freedom by getting rid of it.
_______________________________________________
Discuss mailing list
Discuss@...
http://lists.blu.org/mailman/listinfo/discuss

[Ryan Pugatch-4]

Dan Ritter wrote:

> On Tue, Jun 30, 2009 at 04:02:51PM -0400, Tom Metro wrote:
>> ref wrote:
>>> TRipwire annoyed me as it emailed me masses of stuff
>>> everyday about what had NOT changed.
>> When I used Tripwire I also found that it required a lot of maintenance
>> in order to make it provide useful reports. If you don't keep up with
>> it, it ends up flooding you with useless reports (reporting the same
>> changes over and over), which leads to the reports being ignored.
>>
>> Most file system change detection tools work on a model where they set a
>> baseline and then once they detect a deviation from that baseline, they
>> email you perpetually until that baseline gets reset. This is the
>> secure, paranoid way to do it, but not particularly practical.
>
> It's the only really useful way. There are two tricks:
>
> - make it easy to reset the baseline
> - a single word alias is best
>
> - map exactly what parts of your filesystems you can ignore
> - in particular, you need to have the monitor
>  automatically ignore logs, temp files, pidfiles, mail
>  spools and user home directories
>
>> Back when I set up my first Debian system I went looking for something
>> simpler than Tripwire, and ran across Integrit, and have been using it
>> ever since, even though it remains fairly obscure. It was easy to set
>> up, and with a few tweaks to to its cron script, I was able to have it
>> automatically reset its baseline after changes. This eliminates
>> maintenance effort, and it only generates reports if there have been
>> changes since the last change occurred, so most of the time it stays quiet.
>
> Integrit is pretty good. So is AIDE.
>
>> Note that although these file system change detection tools are often
>> promoted as intrusion detection tools, they're actually more beneficial
>> for routine system administration by providing a record of what system
>> files changed when. This can be useful if system behavior changes and
>> you want to track down when a config was modified or when some upgrade
>> changed a shared library.
>
> Though there are three better tools:
>
> - keep your configurations in a version control system
> - and/or keep snapshots of your configurations (or whole
>   filesystems)
> - look in your OS package installation log (/var/log/dpkg, for
>   instance)
>
> -dsr-
>

I probably should have included 'network' in the subject line for when
the thread progressed. I am looking at solutions for network intrusion
detection (i.e. Snort) rather than something for an individual system.
I appreciate these suggestions though.



--
Ryan Pugatch
Systems Administrator, TripAdvisor
_______________________________________________
Discuss mailing list
Discuss@...
http://lists.blu.org/mailman/listinfo/discuss

[Bill Bogstad]

On Tue, Jun 30, 2009 at 4:36 PM, Dan Ritter<dsr@...> wrote:

> On Tue, Jun 30, 2009 at 04:02:51PM -0400, Tom Metro wrote:
>> ref wrote:
>> > TRipwire annoyed me as it emailed me masses of stuff
>> > everyday about what had NOT changed.
>...
>> Note that although these file system change detection tools are often
>> promoted as intrusion detection tools, they're actually more beneficial
>> for routine system administration by providing a record of what system
>> files changed when. This can be useful if system behavior changes and
>> you want to track down when a config was modified or when some upgrade
>> changed a shared library.
>
> Though there are three better tools:
>
> - keep your configurations in a version control system
> - and/or keep snapshots of your configurations (or whole
>  filesystems)
> - look in your OS package installation log (/var/log/dpkg, for
>  instance)

There are better tools, but that's in some sense irrelevant.  We don't
have file permissions and
memory protection to just protect against malicious action.  It more
often prevents mistakes/errors
from getting out of hand.  Sysadmins are human and will sometimes make
mistakes, not follow procedures, etc.  The methods you suggest are
great, but file modification checking can still be a good backstop
against human error.  It is also possible for tools (particularly
software installers) to make undocumented changes to unexpected files.
 Tripwire/AIDE/etc. will let you discover this quickly.

Bill Bogstad

_______________________________________________
Discuss mailing list
Discuss@...
http://lists.blu.org/mailman/listinfo/discuss

[Tom Metro-16]

Dan Ritter wrote:
> Tom Metro wrote:
>> Most file system change detection tools work on a model where they set a
>> baseline and then once they detect a deviation from that baseline, they
>> email you perpetually until that baseline gets reset.
>
> It's the only really useful way. There are two tricks:
>
> - make it easy to reset the baseline
> - a single word alias is best

What is the advantage of having that manual intervention? If you're
busy, and don't get to manually reset the baseline before the next
report, the deltas accumulate, and after a few days the reports become a
useless muddled mess.

This results in changes made on day 2, 3, etc. being far less
noticeable, which I consider to be a far more serious threat than the
unlikely prospect that an attacker breaches your system and resets the
baseline.

(If you've automated resetting the baseline to the point where it is a
single word alias, then you haven't really gained any security over a
system that automatically resets the baseline after changes are
reported. Once you've eliminated the use of a complex passphrase that
gets hand-typed, anyone who has gained root can circumvent the system.
Even then, I tend to think that as long as your database is hosted on
the system itself, the passphrase approach is more of an illusion. If
you want real security, you need to bypass the target system's kernel
and directly scan the drive using another host or a live CD.)


> - map exactly what parts of your filesystems you can ignore
> - in particular, you need to have the monitor
>  automatically ignore logs, temp files, pidfiles, mail
>  spools and user home directories

That's a requirement for any file system change detection tool,
otherwise you end up with a lot of noise. Integrit has a pretty simple
config file syntax with rules to skip specified paths entirely or
partially (such as ignoring modification time or content changes, while
still monitoring other attributes, like inode number). The default rules
in the Debian package do a decent job, though they get tripped up by the
/dev changes triggered by udev.

>> ...they're actually more beneficial for routine system
>> administration by providing a record of what system files changed
>> when.
>
> Though there are three better tools:
>
> - keep your configurations in a version control system
> - and/or keep snapshots of your configurations (or whole
>   filesystems)
> - look in your OS package installation log (/var/log/dpkg, for
>   instance)

I agree with all of that, but find that the file change reports provide
an additional way of accessing the information that is often more
convenient. Package installation logs often won't tell you when a
specific file has changed. A search on the mail folder containing
Integrit reports will. A VCS also won't necessarily tell you when a
package installer has overwritten your local config - only that it is
different. I also don't "check in" configs that have no local modifications.

  -Tom

--
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/
_______________________________________________
Discuss mailing list
Discuss@...
http://lists.blu.org/mailman/listinfo/discuss

[Derek Martin-9]

On Tue, Jun 30, 2009 at 10:08:25PM -0400, Tom Metro wrote:
> Dan Ritter wrote:
> > - make it easy to reset the baseline
> > - a single word alias is best
>
> What is the advantage of having that manual intervention? If you're
> busy, and don't get to manually reset the baseline before the next
> report, the deltas accumulate, and after a few days the reports become a
> useless muddled mess.

If you're in the habit of automatically updating your baseline, an
educated attacker can cover his tracks by doing it for you.  I've read
(and agree with) advice from "experts" that it's a good idea to leave
some stuff modified out of the baseline.  It's much harder for an
attacker to fool you by duplicating the state of the report before he
broke in if there's stuff there (and you know what it is), than if
it's empty.

> This results in changes made on day 2, 3, etc. being far less
> noticeable, which I consider to be a far more serious threat than the
> unlikely prospect that an attacker breaches your system and resets the
> baseline.

I think it greatly depends on the usage of the system, how you have
tripwire configured, and whether or not you're protecting anything
that's worth someone clueful targeting it.  If you have a large number
of modifications on a daily basis, you may need to tune your config,
or if you can't reasonably reduce the noise, you may have to consider
that you need a different / another tool.

> Once you've eliminated the use of a complex passphrase that
> gets hand-typed, anyone who has gained root can circumvent the system.
> Even then, I tend to think that as long as your database is hosted on
> the system itself, the passphrase approach is more of an illusion.

Unless you write it to write-once media.  This works best if you can
keep the noise down sufficiently to keep the differences manageable
over say, a weeks time.  You just update the database weekly.

> you want real security, you need to bypass the target system's kernel
> and directly scan the drive using another host or a live CD.)

If you want real security, unplug your box, encase it in cement,
vaccuum out the air, and drop it into the Mariana trench.  One is only
slightly less practical than the other... ;-)

Tools like tripwire are great, but they are not a complete solution.
It's often not practical to monitor things like /tmp or user home
directories (though it might be in your particular environment), which
makes those excellent places for attackers to hide root kits and such.
The hope is that if an attacker installs a root kit, it actually does
something that you can detect another way...  Tripwire is great for
monitoring system binaries, kernel modules, locally installed
programs, configuration files, and data that tends to be fairly static
(e.g. a lot of web content, etc.).

On the other hand, if all you're doing is reading mail from your (not
especially subversive) friends and family, and developing an ip
calculator app on your desktop, don't bother... it's not worth the
effort to set it up and maintain it. =8^)

--
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.


_______________________________________________
Discuss mailing list
Discuss@...
http://lists.blu.org/mailman/listinfo/discuss

[Dan Ritter-2]

On Tue, Jun 30, 2009 at 10:08:25PM -0400, Tom Metro wrote:

> Dan Ritter wrote:
> > Tom Metro wrote:
> >> Most file system change detection tools work on a model where they set a
> >> baseline and then once they detect a deviation from that baseline, they
> >> email you perpetually until that baseline gets reset.
> >
> > It's the only really useful way. There are two tricks:
> >
> > - make it easy to reset the baseline
> > - a single word alias is best
>
> What is the advantage of having that manual intervention? If you're
> busy, and don't get to manually reset the baseline before the next
> report, the deltas accumulate, and after a few days the reports become a
> useless muddled mess.

Actual practice suggests that on stable production systems, this
does not happen.

My chief henchman reviews the reports daily, and less than once
per week brings something to my attention that requires a reset.

> unlikely prospect that an attacker breaches your system and resets the
> baseline.

If you can't cope with the changes on your systems, there's
something wrong with your change management procedure.

> (If you've automated resetting the baseline to the point where it is a
> single word alias, then you haven't really gained any security over a
> system that automatically resets the baseline after changes are
> reported. Once you've eliminated the use of a complex passphrase that
> gets hand-typed, anyone who has gained root can circumvent the system.

Anyone unauthorized who gains root has caused a disaster on that box. It
needs to be taken out of service immediately. Resident
filesystem integrity checkers don't solve this problem.

> Even then, I tend to think that as long as your database is hosted on
> the system itself, the passphrase approach is more of an illusion. If
> you want real security, you need to bypass the target system's kernel
> and directly scan the drive using another host or a live CD.)

Yup.

-dsr-

--
http://tao.merseine.nu/~dsr/eula.html is hereby incorporated by reference.

You can't defend freedom by getting rid of it.
_______________________________________________
Discuss mailing list
Discuss@...
http://lists.blu.org/mailman/listinfo/discuss