You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Ja...@cardsetc.com on 2001/01/22 04:41:54 UTC
Logging Best Practices: Security???
Apologies for the slightly off-topic post, but I thought that this might be
a particularly good forum to discuss the following, given everyone's focus
towards logging.
How do you effectively secure your system log? By 'secure' I mean, against
tampering, I'm less worried about having lots of people see it. I see a
couple of options:
1. Rely only on operating-system security. Set the permissions of the file
such that only the superuser and the user that the server process runs
under can modify this file (I am considering that logs go to a file rather
than a database, as I consider logging to a database slow and unwieldy for
little positive gain). The issue then is that if the superuser or server
user accounts are compromised, the logs can be tampered and system activity
could be misrepresented (which might be key in permitting the attacker to
cover their tracks, or might affect financials if the logs are processed in
batch to produce bills for different parties using the system).
2. Add signatures or other crypto to the messages. There is more to this
than just adding a hash to each record, since the attacker could recompute
the hash (since we cannot reasonably expect the algorithm we use to compute
it to remain secret) for their 'new' record, or just delete records
altogether. So, it becomes necessary to interlock the hashes of all records
in some fashion, and guard against the possibility of an attacker just
deleting records from the end of the file (thus necessitating the use of
some kind of footer) - possibly via a trojan installed on the system. All
whilst maintaining a reasonable level of performance of course!
What sort of practices have you employed?
Regards,
James W.
--------------------------------------------------------------------------
This e-mail is from Cards Etc Pty Ltd (ACN: 069 533 302). It may contain
privileged and confidential information. It is intended for the named
recipient(s) only. If you are not an intended recipient, please notify us
immediately by reply e-mail or by phone on +61 2 9212 7773 & delete this
e-mail from your system.
--------------------------------------------------------------------------
Re: Logging Best Practices: Security???
Posted by Ceki Gulcu <cg...@urbanet.ch>.
Hate to follow up on myself but you can get the article at:
http://www.research.ibm.com/security/publ.html
>Hash chaining only guarantees authenticity. If you are also interested in
>non-repudiation, for example if you are running a bank, then consider
>one-time signatures which are supposed to be 2 orders of magnitude faster
>than signatures based on the difficulty of computing discrete logarithms
>(e.g. DSS) or refactoring composite numbers (e.g. RSA). There was an
>article about this in Crypto 97 by Gennaro and Rohatgi entitled "How to
>sign digital streams." Cheers, Ceki
----
Ceki Gülcü (cgu@urbanet.ch)
Re: called and callee logging :-)
Posted by "Max R. Andersen" <ma...@cs.auc.dk>.
> >ie I have a method foo.bar.UberM() and it calls:
> >
> >
> >foo.baz.m1()
> >bar.foop.m2()
> >
> >crazy.foo.bar.m3()
> >crazy.foo.bar.m5()
> >
> >
> >and each of those other methods call a LOT OF STUFF.
> >
> >but I don't really know what those all call. I just want to
> >say: ANYTHING that UberM() calls I want to set that to print out debug
> >statements.
This is exactly what AspectJ was created for :)
To do cross-cutting programming...check out www.aspectj.org
By using aspectj you do not even have to insert the log statetments manually
in each method :)
Regards
Max
Re: called and callee logging :-)
Posted by Ceki Gulcu <cg...@urbanet.ch>.
At 20:36 21.01.2001 -0800, you wrote:
>Is there any way in the current architecture to make a category that will
>log everything called by a specific function across packages?
>
>
>ie I have a method foo.bar.UberM() and it calls:
>
>
>foo.baz.m1()
>bar.foop.m2()
>
>crazy.foo.bar.m3()
>crazy.foo.bar.m5()
>
>
>and each of those other methods call a LOT OF STUFF.
>
>but I don't really know what those all call. I just want to
>say: ANYTHING that UberM() calls I want to set that to print out debug
>statements.
>
>
>
>yes this will be REALLY REALLY REALLY slow as each call has to look on
>the stack to see if was called by UberM() (though one could make some
>flag in the log4j static structure. )
I think you might be lucky on this one. Here is a relatively easy solution:
1) At the start of foo.bar.UberM() set the NDC to some value that is easy
to recognize later.
2) Add filters to appenders where you want to isolate foo.bar.UberM()
tracing. These filters should accept logs that contain the NDC pattern that
was specified in (1) and reject all other logging events.
3) Clear the NDC when you leave foo.bar.UberM().
I predict that you can have this implemented and running in 30 minutes. See
the filters in org/apache/log4j/varia for filtering examples. Hope this
helps, Ceki
----
Ceki Gülcü (cgu@urbanet.ch)
Re: Logging Best Practices: Security???
Posted by Ceki Gulcu <cg...@urbanet.ch>.
James,
At 14:41 22.01.2001 +1100, you wrote:
>Apologies for the slightly off-topic post, but I thought that this might be
>a particularly good forum to discuss the following, given everyone's focus
>towards logging.
Not at all. This is a very interesting topic actually.
>How do you effectively secure your system log? By 'secure' I mean, against
>tampering, I'm less worried about having lots of people see it. I see a
>couple of options:
>
>1. Rely only on operating-system security. Set the permissions of the file
>such that only the superuser and the user that the server process runs
>under can modify this file (I am considering that logs go to a file rather
>than a database, as I consider logging to a database slow and unwieldy for
>little positive gain). The issue then is that if the superuser or server
>user accounts are compromised, the logs can be tampered and system activity
>could be misrepresented (which might be key in permitting the attacker to
>cover their tracks, or might affect financials if the logs are processed in
>batch to produce bills for different parties using the system).
System security is a prerequisite to cryptographic security. If you have an
insecure system all the crypto in the world won't help. One approach is for
hosts to report their logging to a remote server. This server should be
hardened somewhat perhaps by allowing access to a very restricted set of
users. In case an intruder breaks into on of the hosts, she cannot remove
her traces at least not from the log server. This is the sanest (no
bullshit) approach I know.
>2. Add signatures or other crypto to the messages. There is more to this
>than just adding a hash to each record, since the attacker could recompute
>the hash (since we cannot reasonably expect the algorithm we use to compute
>it to remain secret) for their 'new' record, or just delete records
>altogether. So, it becomes necessary to interlock the hashes of all records
>in some fashion, and guard against the possibility of an attacker just
>deleting records from the end of the file (thus necessitating the use of
>some kind of footer) - possibly via a trojan installed on the system. All
>whilst maintaining a reasonable level of performance of course!
>
>What sort of practices have you employed?
Hash chaining only guarantees authenticity. If you are also interested in
non-repudiation, for example if you are running a bank, then consider
one-time signatures which are supposed to be 2 orders of magnitude faster
than signatures based on the difficulty of computing discrete logarithms
(e.g. DSS) or refactoring composite numbers (e.g. RSA). There was an
article about this in Crypto 97 by Gennaro and Rohatgi entitled "How to
sign digital streams." Cheers, Ceki
----
Ceki Gülcü (cgu@urbanet.ch)
possible bug
Posted by msew <ms...@ev1.net>.
So when you have an XML file for your config options for when and how log4j
is supposed to print out log statements and you do what I have below.
that is having a category explicitly tell which appender it wants to
use. the lo4j will not check to see if the appender is the same as one
already higher up on the hierarchy.
so you get the same log messages sent to the SAME logger N times where N is
the number of times that appender is on the path to the category from the
root for the category hierarchy.
whether one should be explicitly listing out the appenders per category is
a different question of maintenance and philosophy as both camps do have
points.
but that aside the log4j should be checking to see if the category is the
same before putting it in the list of appenders to send to
example xml file
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE configuration SYSTEM "log4j.dtd">
<configuration>
<appender name="defaultLogger" class="org.apache.log4j.FileAppender">
<param name="File" value="System.out" />
<param name="Append" value="true" />
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern"
value="%-5p [%t] %C{2} (%F:%L) - %m\n"/>
</layout>
</appender>
<!-- categories -->
<root>
<priority value ="error" />
<appender-ref ref="defaultLogger" />
</root>
<category name="foo.bar.robots.testing4j">
<priority value="info" />
<appender-ref ref="defaultLogger" />
</category>
<category name="foo.bar.robots.testing4j.pack">
<priority value="info" />
<appender-ref ref="defaultLogger" />
</category>
<category name="foo.bar.robots.testing4j.pack.m1()">
<priority value="debug" />
<appender-ref ref="defaultLogger" />
</category>
</configuration>
called and callee logging :-)
Posted by msew <ms...@ev1.net>.
Is there any way in the current architecture to make a category that will
log everything called by a specific function across packages?
ie I have a method foo.bar.UberM() and it calls:
foo.baz.m1()
bar.foop.m2()
crazy.foo.bar.m3()
crazy.foo.bar.m5()
and each of those other methods call a LOT OF STUFF.
but I don't really know what those all call. I just want to
say: ANYTHING that UberM() calls I want to set that to print out debug
statements.
yes this will be REALLY REALLY REALLY slow as each call has to look on
the stack to see if was called by UberM() (though one could make some flag
in the log4j static structure. )
but can you do it in the current log4j? :-)
thanks
msew