RE: Log checking?

["Paul D. Robertson" <paul () compuwar net>]

On Thu, 30 Sep 2004, FW Wizards Mailing List wrote:

> While I've really enjoyed reading this communication regarding logging,
> I'm a little concerned.  I think that all incoming traffic that is
> dropped should be logged.  An accept for an incoming ftp request would

There's a good case to be made for logging *everything*- but there are
mitigating concerns (it's all discoverable, there's a lot of it, you need
to be able to deal with the analysis...)

While I generally recommend folks log as much as possible, with specific
sunsets on retention, if you have 5,000 script kiddie attacks a day, you
tend to evaluate where and what logging is important in a different light.
It didn't take me long to decide that dropping anything out of band at the
border was organizationally more palatable than building an
infrastructure to keep up with logging and analyzing that much "attack"
traffic when it wasn't going to be successful anyway.  If it got past the
outer screens, then I logged it and analyzed it, but I was still a lot
more interested in what got through than what was blocked at that stage.

Now, if you're not sued often, the idea of discoverable information may
not be all that much of an issue- but if you've dealt with fulfilling
discovery motions, you'll not want to have to excerpt terabytes of logs
for every fishing expedition a lawyer might mount.  That's probably the
biggest danger in logging permitted traffic too, especially if you're a
target of hostile workplace fishing expeditions, or trade secret ones.
That's to say that there's risk even in logging, which needs to be
evaluated against the benefits.

Maybe it's the nature of the incidents I generally deal with, but while
I've been happy to analyze a year's worth of firewall denied logs, the
times I've been frustrated have been the times that I haven't had
application logs from that same time period (stuff that was permitted
through the firewall).

> look legitimate, when logging drops would show that an attempt on a
> blocked port took place prior to that "legitimate" ftp traffic.
> Additionally, for legal purposes it would be important to have
> documentation of all drops that a firewall had from a specific

If you have evidence of an intrusion, that's always been sufficient in my
experience to get discovery motions approved by a judge, or search
warrants in criminal cases.  While showing defeated attempts may help
paint a "better picture," records of successful malicious activity always
win in my experience.  I've done some denied logging excepts to paint that
picture for Web server attacks, but these days, I think judges in most
jurisdictions have had enough cases that it's icing, not the cake, and
denied application logs (allowed through the firewall, blocked by the
application) have generally been the key (there's an argument that a
smarter application firewall would put those in the denied log bucket.)

While I'm waiting on a criminal case to see if the suspect accepts a plea
bargain, in everything else I've done that hasn't been dropped for other
reasons, settlements always happened for insider stuff where we didn't
have denied firewall traffic logs or denied logs with any relevant data.

Don't get me wrong, it's always cool to say something like "attempted 5000
different ID/password combinations, then attacked...," but it only makes
the case if you want to prosecute complete failures (that may be
appropriate for some organizations)- if it's successful, then you *need*
the successful traffic or evidence of it, unsuccessful attempts are most
helpful in early discovery when going after unsuccessful attackers.

It's also possible that if there have been forensics issues with a
workstation (shared credentials, overwritten files, etc.) then having
off-box evidence is a really good thing, even if it's stuff that was
blocked, or to correlate activity (here's where the FTP command is in the
command history, here's where it hits the firewall...)  But again, "here's
the command, here's where it goes through the firewall to the other
company" is still way better for getting a settlement or plea agreement.

> destination.  I don't think there is ever too much "noise."  You need to
> filter your logs to provide you with the information you need.  I do
> agree that it is vital to monitor your employee's behavior.  The only
> traffic that I wouldn't want to log is NetBIOS traffic, etc, being
> dropped by the internal interface on the firewall.  A proper IDS
> configuration (one on the inside and one on the outside) will help you
> to audit your security policy.  Without proper logging, how can your
> security policy be as effective as it could be?  Personally, I'm all for
> logs that will provide the information desired upon need.  I'd hate not
> to get enough information when it is needed from a firewall.

If you have lots of failed attempts, and limited bandwidth to deal with
things, then you have to make a trade-off.  Ignoring the script kiddie
events hasn't bitten me yet, but I've always been able to have a
conservative security policy that allowed a very small number of systems
to communicate with the world at large, so attacking or tunneling over a
small number allowed protocols was my only major attack vector left open.

Only you can make a determination for your organization if say logging
automated probes where there are no accessible systems is "worth it."
Same with Windows pop-up message stuff where you have bunch of Sun
servers.  There's enough "background noise" these days that you'll pay
pretty significantly in terms of logging infrastructure and backup
infrastructure to log things that'll never succede if you have a good
chunk of real estate to protect (even a single /16 these days gets lots of
probes)- it may be a different answer than if you have fewer visible
addresses.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul () compuwar net       which may have no basis whatsoever in fact."
probertson () trusecure com Director of Risk Assessment TruSecure Corporation
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards