|
Replies:
13
-
Last Post:
May 31, 2007 12:46 AM
by: tzeman
|
Threads:
[
Previous
|
Next
]
|
|
Posts:
47
From:
Prague, Czech Republic
Registered:
12/8/06
|
|
|
|
Problem: Remote Audit trail storage
Posted:
Feb 14, 2007 4:06 AM
To: Projects » audit » discuss
|
|
Hi folks,
there has been some discussion and interest in implementing remote audit trail
storage and it would be nice if we had a feedback from sysadmins deploying
Solaris Auditing and wider audience as well.
Motivation:
-----------
Secure and reliable transmission and storage of audit records via (encrypted) TCP
stream. Currently, the existing deployment of the NFS as a remote audit trail
storage is not sufficient. audit_syslog(5) plugin which sends audit records to
syslog is not the solution either.
Architecture:
-------------
+------------+
+------------+| tcp +--------------------+
+------------+|+ -------------------> |audit storage server|
| audit host |+ audit records +--------------------+
+------------+
Proposal consists of 2 main components:
1. auditd plugin capable of sending the audit records via tcp to the remote
server.
2. remote audit server, eg. raudit which listens on network, validates and
stores received data possibly using existing auditd plugins
(audit_binfile(5))
Audit plugins: audit_tcp, audit_ssl
-----------------------------------
Operation:
Each received record (via private interface auditd_plugin() is
forwarded via a tcp connection to the remote audit server. Stream would
consist of successive sequence of record length token and record
itself.
If sending fails or connection is not established, a plugin will try to
open/send again for a predefined number of times before enforcing audit
policy (eg. dropping records if policy is 'cnt' or halting system if
policy is 'hlt'). auditd_plugin() implementation can be called from
several threads so it has to ensure appropriate locking.
Configuration:
- configuration similar to audit_binfile, ie. via audit_control(4)
Attributes:
- host audit server hostname or IP address
- port tcp port
- retries how many times to try resending event/opening connection
- timeout tcp connection timeout - sslcert cert file for for audit_ssl plugin
Questions:
- Would it make sense to have the ability to filter out certain events,
ie. setting interesting audit classes for which the audit events will
be sent remote? (viz. man audit_syslog(5) - section "Object
Attributes") Or should it behave exactly as audit_binfile(5) which
processes _all_ records received from the kernel?
Remote audit service: raudit
----------------------------
Operation:
Listens on the configured tcp port, verifies incoming data and writes
to audit trail. tcp_wrappers will be used to filter (un)wanted hosts.
Configuration:
Similar to auditd(1m) in audit_control(4). It could be audit_remote(4).
Questions:
How the audit trails be organized? What the sysadmins would like to have?
Multiple directories can be configured (as per audit_binfile)
and raudit will automatically create a subdirectory for each
host where it writes audit trails.
Eg. let's have
dir:/var/audit
dir:/z1/audit
dir:/z2/audit
then the structure will be:
/var/audit/host1/
/var/audit/host2/
...
/var/audit/hostn/
/z1/audit/host1/
/z1/audit/host2/
...
/z1/audit/hostn/
/z2/audit/host1/
...
/z2/audit/host2/
/z2/audit/hostn/
Backpressure/policy enforcement:
--------------------------------
1. Network outage/raudit outage
For short outages, audit plugins will try to resent audit records, for
longer outages they will enforce audit policy configured for each host.
2. Traffic congestion/heavy load of raudit server
Should there be audit policy enforcement as well? Or should the
processes on audited hosts be slowed down?
Related RFEs/proposals:
-----------------------
- 6376592 need audit plugin to send full audit records to a remote server [1]
- 4009451 need mechanism for putting audit trail on remote machine
- Related but different from Tamper evident/resistant audit trail [2],
discussed on this list as well.
Opinions/flames?
regards,
tomas
[1] http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6376592
[2] http://www.opensolaris.org/jive/thread.jspa?threadID=21170
|
|
|
Posts:
68
From:
SE
Registered:
5/18/05
|
|
|
|
Re: Problem: Remote Audit trail storage
Posted:
Feb 14, 2007 10:43 AM
in response to: tzeman
|
|
Hi Tomas!
On Feb 14, 2007, at 13:06 , Tomas Zeman wrote:
> Motivation:
> -----------
> Secure and reliable transmission and storage of audit records via
> (encrypted) TCP
> stream. Currently, the existing deployment of the NFS as a remote
> audit trail
> storage is not sufficient. audit_syslog(5) plugin which sends audit
> records to
> syslog is not the solution either.
>
> Architecture:
> -------------
>
> +------------+
> +------------+| tcp +--------------------+
> +------------+|+ -------------------> |audit storage server|
> | audit host |+ audit records +--------------------+
> +------------+
>
> Proposal consists of 2 main components:
> 1. auditd plugin capable of sending the audit records via tcp to
> the remote
> server.
> 2. remote audit server, eg. raudit which listens on network,
> validates and
> stores received data possibly using existing auditd plugins
> (audit_binfile(5))
>
> Audit plugins: audit_tcp, audit_ssl
> -----------------------------------
> Operation:
> Each received record (via private interface auditd_plugin() is
> forwarded via a tcp connection to the remote audit server.
> Stream would
> consist of successive sequence of record length token and
> record
> itself.
>
> If sending fails or connection is not established, a plugin
> will try to
> open/send again for a predefined number of times before
> enforcing audit
> policy (eg. dropping records if policy is 'cnt' or halting
> system if
> policy is 'hlt'). auditd_plugin() implementation can be
> called from
> several threads so it has to ensure appropriate locking.
>
> Configuration:
> - configuration similar to audit_binfile, ie. via
> audit_control(4)
> Attributes:
> - host audit server hostname or IP address
> - port tcp port
> - retries how many times to try resending event/
> opening connection
> - timeout tcp connection
> timeout -
> sslcert cert file for for audit_ssl plugin
>
I think you need the ability to use a "backup" host, because if you
don't have one, you only have "timeout" seconds to reboot the
receiving end before all your systems sending audit trails will halt
(when you use +htl).
I also think you need to be able to daisy-chain raudit to each other,
so you can aggregate audit trails in a better way. It also helps
firewall traversal as it will only be a single host to host
communication.
> Questions:
> - Would it make sense to have the ability to filter out
> certain events,
> ie. setting interesting audit classes for which the audit
> events will
> be sent remote? (viz. man audit_syslog(5) - section "Object
> Attributes") Or should it behave exactly as audit_binfile
> (5) which
> processes _all_ records received from the kernel?
>
Yes, it does.
> Remote audit service: raudit
> ----------------------------
>
> Questions:
> How the audit trails be organized? What the sysadmins would
> like to have?
>
> Multiple directories can be
> configured (as per audit_binfile)
> and raudit will automatically create a subdirectory
> for each
> host where it writes audit trails.
>
One directory per host is a requirement. How do you intend to deal
with log rotation? I.e. when will a new file be created? when you
call "audit -n"?
> Backpressure/policy enforcement:
> --------------------------------
>
> 1. Network outage/raudit outage
> For short outages, audit plugins will try to resent audit
> records, for
> longer outages they will enforce audit policy configured
> for each host.
>
See above.
> 2. Traffic congestion/heavy load of raudit server
> Should there be audit policy enforcement as well? Or should
> the
> processes on audited hosts be slowed down?
>
Do you mean that the raudit daemon should signal the remote systems
sending in audit records to slow down? How do you tell them to slow
down? priocntl(2)?
> Related RFEs/proposals:
> -----------------------
>
> - 6376592 need audit plugin to send full audit records to a remote
> server [1]
> - 4009451 need mechanism for putting audit trail on remote machine
> - Related but different from Tamper evident/resistant audit trail [2],
> discussed on this list as well.
I think the tamper evident/resistant audit records should come before
this project, so we can have confidence in the records on the remote
host.
> Opinions/flames?
>
Yay! :)
cheers,
/Martin
--
Martin Englund, Java Security Engineer, Java SE, Sun Microsystems Inc.
Email: martin dot englund at sun dot com Time Zone: GMT+2 PGP: 1024D/AA514677
"The question is not if you are paranoid, it is if you are paranoid
enough."
_______________________________________________
audit-discuss mailing list
audit-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/audit-discuss
|
|
|
|
|
Posts:
47
From:
Prague, Czech Republic
Registered:
12/8/06
|
|
|
|
Re: Problem: Remote Audit trail storage
Posted:
Feb 15, 2007 1:46 AM
in response to: martin
To: Projects » audit » discuss
|
|
Hi Martin and Sue,
thanks for your comments,
On Wed, Feb 14, 2007 at 07:43:11PM +0100, Martin Englund wrote:
> Hi Tomas!
>
> On Feb 14, 2007, at 13:06 , Tomas Zeman wrote:
>
> > Configuration:
> > - configuration similar to audit_binfile, ie. via audit_control(4)
> > Attributes:
> > - host audit server hostname or IP address
> > - port tcp port
> > - retries how many times to try resending event/opening connection
> > - timeout tcp connection timeout - sslcert cert file for for audit_ssl plugin
> >
> I think you need the ability to use a "backup" host, because if you don't have one, you only have "timeout" seconds to reboot the receiving end before all your
> systems sending audit trails will halt (when you use +htl).
good catch, thanks. In fact the plugin may use a pool of hosts and try to send
records in their order. Configuration then would be like:
- hosts: comma-separated list of audit hosts, in the form of hostIP:port or hostname:port
>
> I also think you need to be able to daisy-chain raudit to each other, so you can aggregate audit trails in a better way. It also helps firewall traversal as it wil
l
> only be a single host to host communication.
I'm not sure if I understand correctly; raudit servers don't need to send
records again; audit trails can be aggregated then eg. via auditreduce(1m).
Firewalls between audited hosts and raudit servers will have to allow
communication to each raudit server anyway.
>
> > Questions:
> > - Would it make sense to have the ability to filter out certain events,
> > ie. setting interesting audit classes for which the audit events will
> > be sent remote? (viz. man audit_syslog(5) - section "Object
> > Attributes") Or should it behave exactly as audit_binfile(5) which
> > processes _all_ records received from the kernel?
> >
> Yes, it does.
OTOH the plugin will have to parse audit records to filter them which will
create additional performance overhead.
>
> >Remote audit service: raudit
> >----------------------------
> >
> > Questions:
> > How the audit trails be organized? What the sysadmins would like to have?
> > Multiple directories can be configured (as per
> >audit_binfile)
> > and raudit will automatically create a subdirectory for each
> > host where it writes audit trails.
> >
> One directory per host is a requirement. How do you intend to deal with log rotation? I.e. when will a new file be created? when you call "audit -n"?
Either as is today via audit -n on a regular basis or rotate logs when the
logfile size reaches a threshold. My intention was to retain current behavior
in the first implementation.
>
> >Backpressure/policy enforcement:
> >--------------------------------
> >
> >1. Network outage/raudit outage
> > For short outages, audit plugins will try to resent audit records, for
> > longer outages they will enforce audit policy configured for each host.
> >
> See above.
Yep, multiple raudit hosts help.
>
> >2. Traffic congestion/heavy load of raudit server
> > Should there be audit policy enforcement as well? Or should the
> > processes on audited hosts be slowed down?
> >
> Do you mean that the raudit daemon should signal the remote systems sending in audit records to slow down? How do you tell them to slow down? priocntl(2)?
>
My intention was to use present functionality as described in
audit_plugin(3BSM) (not delivered, available in PSARC 2002/150):
NOTES
The audit daemon does not make any assumptions about how long a
call to audit_plugin() will take; for example if the plugin makes
a blocking call to a database or gets backpressure on a
communications channel, all threads allocated for serving audit
records to the plugin may become busy for an indeterminate time.
The audit daemon's response to this is to block the flow of data
from the Solaris kernel; depending on the audit policy this
backpressure on the kernel can cause all audited processes to
block. Failure to return from audit_plugin() can cause the
system to come to a standstill as each audited process blocks.
It is recommended that the default audit policy, "auditconfig
-setpolicy +cnt" be used for systems running a plugin.
Thus if sending records to the remote server will be slow, auditd will cause
backpressure on the kernel automagically.
One could also imagine the raudit will send backpressure commands and the
audit_tcp plugin will renice either all processes or processes in a zone in
which it runs via priocntl(2). However that would require the plugin has to
have privileges for that and will need to implement some sort of adaptive
control. IMO that would unnecessarily complicate the implementation and I'm not
sure if that would bring the desired results.
> >Related RFEs/proposals:
> >-----------------------
> >
> >- 6376592 need audit plugin to send full audit records to a remote server [1]
> >- 4009451 need mechanism for putting audit trail on remote machine
> >- Related but different from Tamper evident/resistant audit trail [2],
> > discussed on this list as well.
>
> I think the tamper evident/resistant audit records should come before this project, so we can have confidence in the records on the remote host.
Actually they are quite independent on each other as each project addresses
different problem but I agree having audit records signed in the first place
will make the infrastructure more resilient to attacks.
tomas
|
|
|
|
|
Susan Diller
sukadill@hotmail.com
|
|
|
|
RE: Problem: Remote Audit trail storage
Posted:
Feb 14, 2007 10:53 AM
in response to: tzeman
|
|
syslog allows for a separate or additional loghosts. Although, it has what
I consider to be a bug in that it obtains its time stamp from the actual
time it writes the record, not when the incident occurred. (SUN had a
reason for this, which I do not remember.) I like the flexibility of having
different files or hosts for various types of records.
I don't know if it would still be a requirement anywhere, but quite awhile
back, I had all DECnet messages going to one server's console, which was a
hardcopy device. This server then had to send its remaining messages
elsewhere, so as not to end up in the DECnet log. Would there be a use for
having logs sent directly to a backup media, so it could not be changed once
it is written and removed from the server?
Sue Diller
>From: Tomas Zeman <tomas dot zeman at sun dot com>
>To: audit-discuss at opensolaris dot org
>Subject: [audit-discuss] Problem: Remote Audit trail storage
>Date: Wed, 14 Feb 2007 04:06:46 PST
>
>Hi folks,
>
>there has been some discussion and interest in implementing remote audit
>trail
>storage and it would be nice if we had a feedback from sysadmins deploying
>Solaris Auditing and wider audience as well.
>
>
>Motivation:
>-----------
>Secure and reliable transmission and storage of audit records via
>(encrypted) TCP
>stream. Currently, the existing deployment of the NFS as a remote audit
>trail
>storage is not sufficient. audit_syslog(5) plugin which sends audit records
>to
>syslog is not the solution either.
>
>Architecture:
>-------------
>
> +------------+
> +------------+| tcp +--------------------+
>+------------+|+ -------------------> |audit storage server|
>| audit host |+ audit records +--------------------+
>+------------+
>
>Proposal consists of 2 main components:
> 1. auditd plugin capable of sending the audit records via tcp to the
>remote
> server.
> 2. remote audit server, eg. raudit which listens on network, validates
>and
> stores received data possibly using existing auditd plugins
> (audit_binfile(5))
>
>Audit plugins: audit_tcp, audit_ssl
>-----------------------------------
> Operation:
> Each received record (via private interface auditd_plugin() is
> forwarded via a tcp connection to the remote audit server. Stream
>would
> consist of successive sequence of record length token and record
> itself.
>
> If sending fails or connection is not established, a plugin will
>try to
> open/send again for a predefined number of times before enforcing
>audit
> policy (eg. dropping records if policy is 'cnt' or halting system
>if
> policy is 'hlt'). auditd_plugin() implementation can be called
>from
> several threads so it has to ensure appropriate locking.
>
> Configuration:
> - configuration similar to audit_binfile, ie. via audit_control(4)
> Attributes:
> - host audit server hostname or IP address
> - port tcp port
> - retries how many times to try resending event/opening
>connection
> - timeout tcp connection timeout
> - sslcert cert file for for audit_ssl plugin
>
> Questions:
> - Would it make sense to have the ability to filter out certain
>events,
> ie. setting interesting audit classes for which the audit events
>will
> be sent remote? (viz. man audit_syslog(5) - section "Object
> Attributes") Or should it behave exactly as audit_binfile(5)
>which
> processes _all_ records received from the kernel?
>
>
>Remote audit service: raudit
>----------------------------
> Operation:
> Listens on the configured tcp port, verifies incoming data and
>writes
> to audit trail. tcp_wrappers will be used to filter (un)wanted
>hosts.
>
> Configuration:
> Similar to auditd(1m) in audit_control(4). It could be
>audit_remote(4).
>
>
> Questions:
> How the audit trails be organized? What the sysadmins would like
>to have?
>
> Multiple directories can be configured (as
>per audit_binfile)
> and raudit will automatically create a subdirectory for
>each
> host where it writes audit trails.
>
> Eg. let's have
> dir:/var/audit
> dir:/z1/audit
> dir:/z2/audit
>
> then the structure will be:
> /var/audit/host1/
> /var/audit/host2/
> ...
> /var/audit/hostn/
>
> /z1/audit/host1/
> /z1/audit/host2/
> ...
> /z1/audit/hostn/
>
> /z2/audit/host1/
> ...
> /z2/audit/host2/
> /z2/audit/hostn/
>
>
>Backpressure/policy enforcement:
>--------------------------------
>
>1. Network outage/raudit outage
> For short outages, audit plugins will try to resent audit records,
>for
> longer outages they will enforce audit policy configured for each
>host.
>
>2. Traffic congestion/heavy load of raudit server
> Should there be audit policy enforcement as well? Or should the
> processes on audited hosts be slowed down?
>
>
>Related RFEs/proposals:
>-----------------------
>
>- 6376592 need audit plugin to send full audit records to a remote server
>[1]
>- 4009451 need mechanism for putting audit trail on remote machine
>- Related but different from Tamper evident/resistant audit trail [2],
> discussed on this list as well.
>
>
>
>Opinions/flames?
>
>
>regards,
>
>tomas
>
>[1] http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6376592
>[2] http://www.opensolaris.org/jive/thread.jspa?threadID=21170
>--
>This message posted from opensolaris.org
>_______________________________________________
>audit-discuss mailing list
>audit-discuss at opensolaris dot org
>http://opensolaris.org/mailman/listinfo/audit-discuss
_________________________________________________________________
Laugh, share and connect with Windows Live Messenger
http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline
_______________________________________________
audit-discuss mailing list
audit-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/audit-discuss
|
|
|
|
|
Posts:
3,793
From:
GB
Registered:
3/9/05
|
|
|
|
Re: Problem: Remote Audit trail storage
Posted:
Feb 14, 2007 10:56 AM
in response to: Susan Diller
|
|
Susan Diller wrote:
> syslog allows for a separate or additional loghosts. Although, it has
> what I consider to be a bug in that it obtains its time stamp from the
> actual time it writes the record, not when the incident occurred. (SUN
> had a reason for this, which I do not remember.) I like the flexibility
> of having different files or hosts for various types of records.
The reason for syslog doing this is because the original syslog protocol
works that way.
--
Darren J Moffat
_______________________________________________
audit-discuss mailing list
audit-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/audit-discuss
|
|
|
|
|
Posts:
47
From:
Prague, Czech Republic
Registered:
12/8/06
|
|
|
|
Re: Problem: Remote Audit trail storage
Posted:
Feb 26, 2007 5:26 AM
in response to: tzeman
|
|
Hi all,
I've created a prototype for audit_tcp plugin (description [1], webrev [2])
What's in there:
- multiple hosts: configurable host pool where to send audit records; if
primary host is unavailable, connection timeouts or sending data is so slow
that even (a small) data chunk timeouts, other host in order is chosen and
data is sent there... and so on
- sending audit records via plain tcp (no encryption)
- network protocol is simplified, ie. only pure audit records are being sent
(no record-length token prior a record); that helps testing before the
raudit service will have been implemented - data stream can be captured and
dumped into a file via eg. tcpserver utility (part of ucspi-tcp package[3])
and examined with praudit(1m) directly
I welcome your notes/comments on the code, esp. on the timeouting logic and
socket operations.
Issues:
If a record cannot be sent to the current host, audit_tcp plugin tries other
hosts and if all attempts fail, auditd_plugin() returns AUDITD_RETRY which is
handled in auditd(1m) in usr/cmd/auditd/doorway.c:1245 and error is reported to
syslog. That means burst of syslog messages which is bad.
What could be done:
- either skip reporting errors for the same condition (report only once per a
certain interval)
- or sleep in auditd_plugin() after each round of pooled hosts has been
finished (ie. after attempts is increased, see
usr/src/lib/auditd_plugins/tcp/audit_tcp.c:444) thus ensuring that
auditd_plugin() returns no sooner than timeout value (or possibly
retries*timeout value) in case all hosts are unavailable
regards,
tomas
[1] http://opensolaris.org/os/project/audit/projects/remote_storage/
[2] http://cr.grommit.com/~tzeman/audit_tcp/
[3] http://cr.yp.to/ucspi-tcp.html
On Wed, Feb 14, 2007 at 04:06:46AM -0800, Tomas Zeman wrote:
>
> Motivation:
> -----------
> Secure and reliable transmission and storage of audit records via (encrypted) TCP
> stream. Currently, the existing deployment of the NFS as a remote audit trail
> storage is not sufficient. audit_syslog(5) plugin which sends audit records to
> syslog is not the solution either.
>
> Architecture:
> -------------
>
> +------------+
> +------------+| tcp +--------------------+
> +------------+|+ -------------------> |audit storage server|
> | audit host |+ audit records +--------------------+
> +------------+
>
> Proposal consists of 2 main components:
> 1. auditd plugin capable of sending the audit records via tcp to the remote
> server.
> 2. remote audit server, eg. raudit which listens on network, validates and
> stores received data possibly using existing auditd plugins
> (audit_binfile(5))
>
_______________________________________________
audit-discuss mailing list
audit-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/audit-discuss
|
|
|
|
|
Posts:
68
From:
SE
Registered:
5/18/05
|
|
|
|
Re: Problem: Remote Audit trail storage
Posted:
Feb 27, 2007 5:21 AM
in response to: tzeman
|
|
Hi Tomas!
On Feb 26, 2007, at 14:26 , Tomas Zeman wrote:
> I've created a prototype for audit_tcp plugin (description [1],
> webrev [2])
>
> What's in there:
> - multiple hosts: configurable host pool where to send audit
> records; if
> primary host is unavailable, connection timeouts or sending
> data is so slow
> that even (a small) data chunk timeouts, other host in order is
> chosen and
> data is sent there... and so on
> - sending audit records via plain tcp (no encryption)
> - network protocol is simplified, ie. only pure audit records are
> being sent
> (no record-length token prior a record); that helps testing
> before the
> raudit service will have been implemented - data stream can be
> captured and
> dumped into a file via eg. tcpserver utility (part of ucspi-tcp
> package[3])
> and examined with praudit(1m) directly
>
>
Excellent! I want to try it out a.s.a.p., but I just had a NIC
failure on my system, so I'm waiting for a replacement MB...
> I welcome your notes/comments on the code, esp. on the timeouting
> logic and
> socket operations.
>
> Issues:
> If a record cannot be sent to the current host, audit_tcp plugin
> tries other
> hosts and if all attempts fail, auditd_plugin() returns
> AUDITD_RETRY which is
> handled in auditd(1m) in usr/cmd/auditd/doorway.c:1245 and error is
> reported to
> syslog. That means burst of syslog messages which is bad.
>
> What could be done:
> - either skip reporting errors for the same condition (report
> only once per a
> certain interval)
> - or sleep in auditd_plugin() after each round of pooled hosts
> has been
> finished (ie. after attempts is increased, see
> usr/src/lib/auditd_plugins/tcp/audit_tcp.c:444) thus ensuring that
> auditd_plugin() returns no sooner than timeout value (or possibly
> retries*timeout value) in case all hosts are unavailable
>
It makes sense to not flood the syslog with error messages, but on
the other hand, it will just show "last event occurred X times".
I think one might have to adjust the kernel audit queue when using
this plugin, as the sum of the network timeout(s) easily could cause
the queue to fill up, and thus either halt the system or start
dropping records.
I need to do some experiments with this to see how quickly it fills up.
cheers,
/Martin
--
Martin Englund, Java Security Engineer, Java SE, Sun Microsystems Inc.
Email: martin dot englund at sun dot com Time Zone: GMT+2 PGP: 1024D/AA514677
"The question is not if you are paranoid, it is if you are paranoid
enough."
_______________________________________________
audit-discuss mailing list
audit-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/audit-discuss
|
|
|
|
|
Posts:
47
From:
Prague, Czech Republic
Registered:
12/8/06
|
|
|
|
Re: Problem: Remote Audit trail storage
Posted:
Mar 16, 2007 4:55 AM
in response to: tzeman
|
|
Hello folks,
on http://opensolaris.org/os/project/audit/projects/remote_storage/ page you'll
find updated webrevs + patches against ON sources for audit_tcp plugin and now
rauditd prototype as well.
The communication protocol is now as described on the page, ie. plugin sends
audit record length and then the record itself so while it is still possible to
dump the trail via daemontools, praudit will bail on invalid format. It is now
much better to use new rauditd service to do all the work and read trails for
each host in its own directory.
rauditd uses Solaris event ports API to manage new/open connections and thread
notifications, worker threads and scf repository for configuration.
Note the patches now contain DEBUG macro set to 1 for tracing of what's going
on so rauditd is very verbose (using /var/audit/dump as a log file). To play
with rauditd, apply the patches, compile sources and import service manifest
svccfg import rauditd.xml
Change the configuration (if needed)
svccfg -s svc:/system/rauditd setprop (or addpropvalue)
and run rauditd via:
SMF_FMRI="svc:/system/rauditd:default" rauditd
I welcome your thoughts/comments on what else should be done, besides the following TODOs:
* IPv6: structs used in rauditd are IPv6 compliant but the overall operation is not ready yet
* code cleaning
* rauditd control utility, similar to audit(1m), what about raudit(1m)?
* use tcp_wrappers
IMO we need more reliable communication protocol on app. layer than just
relying on success of write(2) and the underlying tcp infrastructure. It seems
to me that having the rauditd acknowlegde each received and successfully
written audit record back to the plugin is necessary to ensure reliability.
hapy remote auditing.
regards,
tomas
_______________________________________________
audit-discuss mailing list
audit-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/audit-discuss
|
|
|
|
|
Posts:
3,793
From:
GB
Registered:
3/9/05
|
|
|
|
Re: Problem: Remote Audit trail storage
Posted:
Mar 16, 2007 10:22 AM
in response to: tzeman
|
|
What about securing the link ?
If we use SSL/TLS we need to consider trust anchors.
I'd like to see GSS-API considered for securing this and maybe even per
socket IPsec.
--
Darren J Moffat
_______________________________________________
audit-discuss mailing list
audit-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/audit-discuss
|
|
|
|
|
Posts:
47
From:
Prague, Czech Republic
Registered:
12/8/06
|
|
|
|
Re: Problem: Remote Audit trail storage
Posted:
Mar 23, 2007 6:12 AM
in response to: darrenm
|
|
Hi Darren,
I'm sorry for late response as I was offline most of this week.
What I had in mind at first was to use IPsec/ ssh-port-forwarding/ openvpn/
whatever which secures the link and does not require programmatic approach.
In the second stage, some sort of securing the transmitted data should be used.
Is gss-api generally the preferred way to do that? Should it be a part of this
project right from the beginning (ie. in PSARC) or could it be extended
thereafter?
thanks
tomas
On Fri, Mar 16, 2007 at 05:22:15PM +0000, Darren J Moffat wrote:
> What about securing the link ?
>
> If we use SSL/TLS we need to consider trust anchors.
>
> I'd like to see GSS-API considered for securing this and maybe even per socket IPsec.
>
> --
> Darren J Moffat
> _______________________________________________
> audit-discuss mailing list
> audit-discuss at opensolaris dot org
> http://opensolaris.org/mailman/listinfo/audit-discuss
_______________________________________________
audit-discuss mailing list
audit-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/audit-discuss
|
|
|
|
|
Posts:
3,793
From:
GB
Registered:
3/9/05
|
|
|
|
Re: Problem: Remote Audit trail storage
Posted:
Mar 23, 2007 6:19 AM
in response to: tzeman
|
|
Tomas Zeman wrote:
> Hi Darren,
>
> I'm sorry for late response as I was offline most of this week.
>
> What I had in mind at first was to use IPsec/ ssh-port-forwarding/ openvpn/
> whatever which secures the link and does not require programmatic approach.
>
> In the second stage, some sort of securing the transmitted data should be used.
> Is gss-api generally the preferred way to do that? Should it be a part of this
> project right from the beginning (ie. in PSARC) or could it be extended
> thereafter?
I think it MUST be part of the project on its initial integration
because the data is very sensitive. It is not acceptable in my opinion
to depend on lower level transport security because it may not always be
there.
Doing GSS-API should be the easiest - and IMO actually one of the most
useful cases.
If you haven't used GSS-API before have a look here:
http://docs.sun.com/app/docs/doc/816-4863/6mb20lvfn?a=view
and for some sample code try here:
http://docs.sun.com/app/docs/doc/816-4863/6mb20lvh8?a=view
--
Darren J Moffat
_______________________________________________
audit-discuss mailing list
audit-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/audit-discuss
|
|
|
|
|
Posts:
47
From:
Prague, Czech Republic
Registered:
12/8/06
|
|
|
|
Re: Problem: Remote Audit trail storage
Posted:
Mar 23, 2007 6:36 AM
in response to: darrenm
|
|
Thank you for the pointers, I'll start incorporating gss-api into audit_tcp plugin and remote audit.
tomas
On Fri, Mar 23, 2007 at 01:19:58PM +0000, Darren J Moffat wrote:
> I think it MUST be part of the project on its initial integration because the data is very sensitive. It is not acceptable in my opinion to depend on lower level
> transport security because it may not always be there.
>
> Doing GSS-API should be the easiest - and IMO actually one of the most useful cases.
>
> If you haven't used GSS-API before have a look here:
>
> http://docs.sun.com/app/docs/doc/816-4863/6mb20lvfn?a=view
>
> and for some sample code try here:
>
> http://docs.sun.com/app/docs/doc/816-4863/6mb20lvh8?a=view
>
> --
> Darren J Moffat
_______________________________________________
audit-discuss mailing list
audit-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/audit-discuss
|
|
|
|
|
Posts:
47
From:
Prague, Czech Republic
Registered:
12/8/06
|
|
|
|
UPDATE: Remote Audit trail storage
Posted:
May 29, 2007 4:18 AM
in response to: darrenm
|
|
Hi all,
I'm nearly finished with the prototype of gssapi support for remote audit
service (I'm going to post a webrev soon).
The goals of using gss:
- make both auditd plugin and rauditd pure gss, ie. not depending
on/expecting particular gss mechanism (eg. Kerberos5).
- using hostbased principals, service principal is audit@<FQDN>
(fully qualified domain name)
- rely on the default gss credentials acquisition/authentication:
- audit_tcp (auditd runs under root) gets default host
credentials from the keytab (if krb5 is used host/<FQDN> or
root/<FQDN>) or publickey/nis in case of dh mechanism
There are some updates which I'd like to get a feedback from you folks
if possible:
1. Access control
- to control which client is allowed to send audit records, a deny
access list /etc/security/rauditd.deny will list denied client
principals (with wildcard functionality), similar to kadm5.acl(4).
- default policy for rauditd is to be open. It relies on the
underlying infrastructure to provide authentication and its deny
list will provide sort of ACL/authorization.
2. Client differentiation
- for each client rauditd creates a set of directories as described
on the website[1]
- Possibilities (+Pros/-Cons):
1 whole client's principal name
+ mechanism agnostic
+ authenticiry ensured by infrastructure
- different principal names as described above
2 extract hostname from princ. name
+ easy to follow/analyse for sysadmin
- depends on mechanism which I'd like to avoid
3 client's IP address
+ easy to follow/analyse for sysadmin
+ DNS neutral
- not working with NAT
4 client's hostname by reverse DNS lookup/nss
+ easy to follow/analyse for sysadmin
- DNS infrastructure or nss must be configured correctly
- easy to spoof
5 client's IP address extracted from audit record (exheader token) / hostname
- need to parse audit records (at least the first one)
- unique client IP addresses must be ensured (ie. not collecting
data from several NATed networks
Currently, 3 is in my prototype, 1 (or 5) are best choices, both not
dependent on the network infrastructure, firewalls etc.
Opinions are warmly welcomed.
cheers,
tomas
[1] http://opensolaris.org/os/project/audit/projects/remote_storage/
On Fri, Mar 23, 2007 at 01:19:58PM +0000, Darren J Moffat wrote:
> I think it MUST be part of the project on its initial integration
> because the data is very sensitive. It is not acceptable in my opinion
> to depend on lower level transport security because it may not always be
> there.
>
> Doing GSS-API should be the easiest - and IMO actually one of the most
> useful cases.
>
> If you haven't used GSS-API before have a look here:
>
> http://docs.sun.com/app/docs/doc/816-4863/6mb20lvfn?a=view
>
> and for some sample code try here:
>
> http://docs.sun.com/app/docs/doc/816-4863/6mb20lvh8?a=view
>
> --
> Darren J Moffat
_______________________________________________
audit-discuss mailing list
audit-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/audit-discuss
|
|
|
|
|
Posts:
47
From:
Prague, Czech Republic
Registered:
12/8/06
|
|
|
|
|
|
