[ previous ] [ next ] [ threads ]
 
 From:  =?WINDOWS-1252?B?lSCV?= <googl3meister at gmail dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] IDSFirewall "koolaid" ;] "Re: [m0n0wall] Re: m0n0wall + Snort"
 Date:  Wed, 22 Jun 2005 13:34:55 +1000
On 6/22/05, Adriel T. Desautels <atd at secnetops dot com> wrote:
> Chris,
>    Well put man! There's something else I'd like to add to this thread as well.
> 
>    Factually speaking anyone can spoof network traffic because the underlying
> protocols have no real facility to ensure the validity of data. Understanding
> that, how can anyone trust a network based IDS/IPS system if its opinion is
> based on potentially invalid "facts"? Simple, you can't. How many of
> you manage
> IDS systems and are smothered by false positives?
> 
>    Firewalls on the other hand are designed to control traffic and to limit
> inbound and outbound access. Firewalls are devices that I'd like to think of
> more as traffic shaping devices than security devices. Firewall work, they do
> what they are supposed to do if the code is written properly. Firewalls are a
> proved solution.
> 
>    Fact, when you combine any firewall with any IDS solution on the same
> hardware you reduce performance and reliability. The reduction in performance
> means that your IDS engine will not be able to collect and match as much data
> as it would if it was on a stand alone system.
> 
>    Also a fact, when you introduce a software product to a computer system you
> ARE introducing new vulnerabilities. In theory, every software package
> contains
> a vulnerability unless it is mathematically proved to be sure. Why introduce
> more vulnerabilities to what is possibly the most important system on a
> network?
> 
>    Now, having said all of that, IDS'es and IPS'es still have their place. They
> are in fact useful for detecting intrusions and network problems but they are
> not as great as the hype makes them out to be.
> 
> 
> 
> 
> ----- Message from cbuechler at gmail dot com ---------
>     Date: Tue, 21 Jun 2005 10:28:39 -0400
>     From: Chris Buechler <cbuechler at gmail dot com>
> Reply-To: Chris Buechler <cbuechler at gmail dot com>
> Subject: Re: [m0n0wall] Re: m0n0wall + Snort
> 
> 
> > On 6/21/05, Bob Rich <rrich at gstisecurity dot com> wrote:
> >>
> >> I don't know for sure, but i would imagine that snort runs on
> >> FreeBSD 4 just fine...isn't there a potential for using the m0n0
> >> platform for hosting snort?  The firewall and vpn capabilities could
> >> be trimmed to host protection only to avoid the dual use concerns
> >> illustrated below.  GUI pages for pointing to mysql or syslog boxen
> >> for output (to maintain 'embedability'), stealth port configuration,
> >> rule editing, etc should be much simpler than what is already in
> >> place for m0n0wall.
> >>
> >
> > FreeBSD is the platform of choice for many of the most accomplished
> > and recognized people in the IDS/NSM (Network Security Monitoring)
> > world, so sure, it'd work.
> >
> > What wouldn't work really well on the type of setup m0n0wall runs is
> > keeping the necessary session data and other log info to make the IDS
> > worthwhile.  It's not feasible to dump all that over to syslog and/or
> > mysql, and m0n0wall's file system isn't conducive to that type of
> > system.
> >
> > What the people who are fooled by the marketing folks of firewall
> > devices with built in IDS don't realize is they're practically useless
> > in that context.  First, what some call "IDS" has only a couple dozen
> > signatures detecting attacks like the "ping of death" that haven't
> > been used (effectively) since the 90's.  If you're still vulnerable to
> > decade-old attacks, you have way more issues than needing an IDS.
> > Secondly, even if they do include a full blown IDS ruleset, I've yet
> > to see any that provide anything much more than a one line "Alert -
> > XYZ exploit detected".
> >
> > So, how do you know it really was an exploit attempt on that, and not
> > a signature mismatch?  Can't see the actual packets, so you don't
> > know.  How did your server respond, or did it respond at all?  Sorry,
> > can't figure that out either.  For all you know, the exploit worked,
> > and the server is rootkitted.  So you can't trust the machine, and the
> > only way to then tell with certainty what happened is to go into
> > incident response mode, pull the server offline, and examine with
> > known-good tools.
> >
> > My point is, if you think these firewall-embedded IDS systems are
> > actually doing much of anything for you, you're seriously mistaken and
> > have drank way too much of the marketing Kool Aid.  If anybody knows
> > of a firewall that does provide full session data, I'd love to hear
> > about it.
> >
> > I'd strongly recommend http://www.bookpool.com/sm/0321246772 if you
> > have further interest in this area.
> >
> > -Chris
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> >
> 
> 
> ----- End message from cbuechler at gmail dot com -----
> 
> 
> 
> Regards,
>      Adriel T. Desautels
>      Secure Network Operations, Inc.


I both agree and disagree with both of you :)

There are "horses for courses" meaning that under certain conditions
we as security professionals always make allowances/adjustments based
upon the *local* conditions and the best value for money for the
client, whilst at the same time maintaining the highest possible
degree of 'measurable' security, be it ISO17799/4360, SOX, US HiPPA,
Aust. Privacy Act... or other home grown policies.

The client wants their IT infrastructure to 'be as secure as they can
afford it to be, whilst still being useable and maintainable at a
realistic budgetary level (oh, and with decent performance)' which
usually means complying with at least some basic principles and
bending others as appropriate. eg: In all other communications
operations it's considered a sin to ever send management traffic
in-band over the same physical medium (the cable, satellite, microwave
link) as user data traffic.  In the IT world we typically do it every
day simply due to budgetary constraints, except in the higher security
systems which often combine backup, account management and monitoring
into a physically separate network (two of course for DR purposes...)
which are sometimes required to comply with the regulations
controlling that particular industry.  But they won't have any
m0n0walls around, I digress.

What I am saying is that we make allowances based on conditions,
requirements and budget.  I have installed snort into the m0n0 image
myself and set it up syslogging to a central server.  I have no fears
of examing false positives because I have no services exposed and so
the firewall drops the packet anyway.  What I wanted was visibility
for R&D and that is all.  It works perfectly (thank you Manuel!).  I
have mitigating factors in place to guard against failures within
snort - it's defence in depth.  It takes time to tune it for it's
intended purpose, for certain, but the gain in information far exceeds
the blindlessness of not knowing what it is that ticks away at the
firewall all day.

With regards to traffic spoofing, those same packets hit your
firewall, so your firewall logs are equally useless following that
argument.  I've yet to see a recommendation to turn off firewall
logging, however.

--cheers
gm

ps: Process to create your own snort +m0n0 image in ten lines or less
for those interested in doing so (no gui, exec.php driven as reqd):
(Assumes you already have a freebsd machine of the right version
available to you and you know what man command and google are for - if
the first line frightens you, please do not proceed)
1) download and uncompress the image, vn/mdconfig it and then mount it
somewhere (MFS-Source)
2) copy mfsroot.tgz from $MFS-Source, uncompress it, vn/mdconfig it
and mount it somewhere else (original-m0n0-runtime-filesystem)
3) dd a new image file called mfsroot large enough to hold snort + the
existing image + snort dependencies (libpcap, libpre, others) - I used
22M initially but I think it will need increasing - the original
uncompressed image is 16M by comparison
4) vnconfig, fdisk, disklabel, newfs and mount the new image somewhere
(new-m0n0-runtime-fs)
5) cd $original-m0n0-runtime-fs && duplicate everything to
$new-m0n0-runtime-fs using tar preferably to maintain links and
ownership (haven't checked for links but using tar makes it no issue)
6) cd /usr/ports/security/snort && make -DNOMAN
-DPREFIX=/$new-m0n0-runtime-fs-mount-point/usr/local install (or
similar - check for your version) then remove any info files installed
by libtool. You will need to manually copy any library dependencies if
you already have any of them installed, as they will not be rebuilt
using the prefix to the new image.
7) configure the rules files and snort.conf and syslog.conf files, add
to startup scripts, don't forget to create user/group as required (if
necessary) and create the log directory so it doesn't whinge on
startup (despite only logging to syslog).
8) unmount and tar & gzip the new image file => mfsroot.tgz
9) create another new image file to hold the compressed kernel and
mfsroot files, copy the kernel.gz from step 1 and the mfsroot.gz from
step 8, then unmount and transfer this image to a hard disk using dd.
Be carefult not to overwrite the wrong disk. I say again, be careful
not to overwrite the wrong disk. You have been warned. Put disk in
second machine. Voila.

*Serious disclaimer* : The above is from memory and you might shoot
yourself in the foot following these instructions - I make no claims
about the validity of the above, so feel free to USE AT YOUR OWN RISK.
 It took me a few goes to get it right, but at least you can boot off
the second disk in the master machine and see if it at least boots
before transferring the harddisk to the real mono hardware. Others
will no doubt improve/correct as necessary - please feel free to do
so.