Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 26 Mar 2000 15:03:47 -0800
From:      "John Fitzgibbon" <fitz@jfitz.com>
To:        <keramida@ceid.upatras.gr>
Cc:        <freebsd-security@FreeBSD.ORG>
Subject:   Re: Publishing Firewall Logs
Message-ID:  <001701bf9777$9481cc20$040ba8c0@fitz>
References:  <003801bf9688$87418540$040ba8c0@fitz> <20000326161722.A5903@hades.hell.gr>

next in thread | previous in thread | raw e-mail | index | archive | help
Giorgos,
Thanks for the well thought out response.

I'm inclined to agree that I should put a disclaimer with the logs -- I'm
not suggesting that these IP addresses are trying to "attack" me, or are
"bad". In fact the most common log events are "ident" requests, which are
most likely "legitimate". I believe strongly in freedom of information. How
people choose to interpret the information is up to them. My hope would be
that sys admins can use this information, (which may or may not be forged at
source, redirected, etc., etc...), to help them track down sources of
distributed attacks. As you say, it would be a shame to see the information
misinterpreted, like assuming that any IP that's ever hit a closed port is
automatically a "cracker".

I would resist removing information from the logs unless forced to do so by
court order, (and I'd probably fight that too), as I think that diluting the
information dilutes our ability to extract knowledge. As I said in an
offline reply yesterday, if you visit my house, I believe I have the right
to say "you visited my house". I do not have the right to say "you visited
my house, so you must be a criminal", and I am not trying to do so.
Fitz.

----- Original Message -----
From: "Giorgos Keramidas" <keramida@ceid.upatras.gr>
To: "John Fitzgibbon" <fitz@jfitz.com>
Cc: <freebsd-security@FreeBSD.ORG>
Sent: Sunday, March 26, 2000 5:17 AM
Subject: Re: Publishing Firewall Logs


> On Sat, Mar 25, 2000 at 10:31:10AM -0800, John Fitzgibbon wrote:
> >
> > I decided to start publishing my firewall logs on the web
> > http://63.194.217.126/logs/
> >
> > My thinking is that to identify the root, (excuse the pun), source of
> > distributed attacks, administrators need access to a broad set of logs.
>
> This could help, some times.  But it can only help when packets that we
> need to identify, were not forged at their source.
>
> > I'm aware of the obvious counter-argument that any information you
> > make available creates a risk.
>
> I'm also aware of this, and I always was, but I still chose to publish
> on the web the way my ipfw rules were written.  Having someone know by
> first hand what's allowed and what not, is a bit too much of information
> to give.  However, I've received so many personal e-mails that thanked
> me for `having such a helpful page on ipfw' or something along these
> lines, that I think it's worth the risk :)
>
> > This is basically what I'm looking for feedback on -- Is this
> > information useful?
>
> The obvious counter-counter-argument of what you mentioned, is also
> useful here.  "Any kind of information is useful now or `possibly'
> useful in the future."
>
> What you're discussing of doing, is dangerous though.  Despite the fact
> that it would be nice to know that a certain IP address has been the
> source of several distributed attacks during the past few months/years,
> there is always the danger of 'blacklisting' the wrong people.
>
> I have to admit, that in giving the information away, you have not made
> any implicit assumptions on the way it should be used, or what could be
> done with it.  However, it would be a very sad thing if using such
> information as evidence would result on someone being accused of being
> the source of distributed attacks, especially if the accused one had
> nothing to do with it, apart from being the network 'bridge' for the
> packets comprising the attack.
>
> As it should be obvious by now, having the information readily available
> is one thing.  Dictating how and why it should be used is most of the
> time another, totally different thing.  Just thing of the efforts done
> to stop spammers.  The information is there.  The lists of open relays
> are there.  Anyone who wants to use them can go ahead and blackhole
> entire domains, company networks, hell even entire countries.
>
> The worst problems of these efforts though start when they start trying
> to think of a 'policy' for adding something to their list, and removing
> it after some checks have been done and passed successfully.  What I
> mean here is, let's suppose you receive a lot of strange packets from
> the dialup users of an ISP.  And you publish these logs.  Then the ISP,
> having read your online logs, tries to stop such attacks, and fixes
> their router access lists, dropping those strange packets on the floor.
> Do you remove the relevant logs from the Web?  Do you leave them as they
> are, and post a notice saying something to the effect of "but the nice
> and friendly techies of ISP A.B.C. did their best and stopped such
> attempts on their source"?
>
> Of course, it could get even trickier.  Having some ISP block the
> strange packets, once they see your logs.  Then they would post a notice
> to you, asking you in varying degrees of kindness, to remove the logs
> from the web.  You fail to remove the logs in a reasonable amount of
> time, and they sue you, with a charge of spreading libels, and hurting
> their reputation.
>
> I do support the availability of such information, but please take care
> to avoid problems like those described above.  Even a simple disclaimer
> paragraph stating that you're not suggesting in any way the use of this
> information, or that you do not take any responsibility on what others
> might do with it, would probably be enough.  Then again, I'm no lawyer,
> and I'm probably mistaken in hypotheses about anything legal.
>
> - Giorgos Keramidas
>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001701bf9777$9481cc20$040ba8c0>