Having been waiting for this for ages, the ability to use the (pretty robust and secure) audit structure in Linux to log traffic has been finally integrated into the kernel, together with its supporting files and extensions in iptables. Unfortunately, this would be available in .39 version and above of the kernel, which is quite a long way away. The new AUDIT target logs the following elements of any traffic and is protocol independent (so it could be used equally well in iptables and ebtables): - netfilter hook - packet length - incomming/outgoing interface - MAC src/dst/proto for ethernet packets - src/dst/protocol address for IPv4/IPv6 - src/dst port for TCP/UDP/UDPLITE - icmp type/code This data is available through the audit daemon (auditd) and is also retrievable using standard audit tools (ausearch/aureport). I was able to bring all relevant code and integrate it into the .35 version of the kernel, together with the latest version of iptables (1.4.10) and conducted various tests over the past 2 days. It works a treat! The problem I am now having is that I had to be very "creative" and do some rather ugly hacks to integrate it into the test harness and thought that it would be better to ask here if I could replace the standard log mechanism on shorewall with the new AUDIT target? This is how it works (some very rudimentary example from the man page of the AUDIT target): iptables -N AUDIT_DROP iptables -A AUDIT_DROP -j AUDIT --type DROP iptables -A AUDIT_DROP -j DROP A rule which would typically drop a packet would then invoke the new chain to record packets before dropping them. The "--type" above has one function only - to indicate to the audit daemon the type of operation logged - one of: drop, reject or accept. Full logs are stored, securely, and these are retrievable, together with all security-related events on the system, using ausearch and aureport - no need to use anything else and since I use both tools extensively on all my systems here I could apply filters to the type of events I am interested in without having the need to look at all syslogs and such. So, is this doable in shorewall? ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
On May 18, 2011, at 2:51 PM, Mr Dash Four wrote:> Having been waiting for this for ages, the ability to use the (pretty > robust and secure) audit structure in Linux to log traffic has been > finally integrated into the kernel, together with its supporting files > and extensions in iptables. Unfortunately, this would be available in > .39 version and above of the kernel, which is quite a long way away. > > The new AUDIT target logs the following elements of any traffic and is > protocol independent (so it could be used equally well in iptables and > ebtables): > > - netfilter hook > - packet length > - incomming/outgoing interface > - MAC src/dst/proto for ethernet packets > - src/dst/protocol address for IPv4/IPv6 > - src/dst port for TCP/UDP/UDPLITE > - icmp type/code > > This data is available through the audit daemon (auditd) and is also > retrievable using standard audit tools (ausearch/aureport). > > I was able to bring all relevant code and integrate it into the .35 > version of the kernel, together with the latest version of iptables > (1.4.10) and conducted various tests over the past 2 days. It works a > treat! > > The problem I am now having is that I had to be very "creative" and do > some rather ugly hacks to integrate it into the test harness and thought > that it would be better to ask here if I could replace the standard log > mechanism on shorewall with the new AUDIT target? This is how it works > (some very rudimentary example from the man page of the AUDIT target): > > iptables -N AUDIT_DROP > iptables -A AUDIT_DROP -j AUDIT --type DROP > iptables -A AUDIT_DROP -j DROP > > A rule which would typically drop a packet would then invoke the new > chain to record packets before dropping them. The "--type" above has one > function only - to indicate to the audit daemon the type of operation > logged - one of: drop, reject or accept. > > Full logs are stored, securely, and these are retrievable, together with > all security-related events on the system, using ausearch and aureport - > no need to use anything else and since I use both tools extensively on > all my systems here I could apply filters to the type of events I am > interested in without having the need to look at all syslogs and such. > > So, is this doable in shorewall? >Sounds easy -- I assume that the --type values are all upper case? I''ll work up a patch against 4.4.20-Beta2 if you would be willing to test it. -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
> Sounds easy -- I assume that the --type values are all upper case? I''ll work up a patch against 4.4.20-Beta2 if you would be willing to test it. >Good question! I haven''t actually tried lowercase even though the c source tells me that it is actually "drop" (and so does the man page).... Just quickly tested it - the value of the "--test" parameter is not case sensitive, but accepts only "drop", "reject" or "accept" as values, naturally! It is also worth noting that "mixing" of type and action should not be allowed (this is something shorewall internally needs to resolve), i.e. -N ADROP -A ADROP -j AUDIT --type accept -A ADROP -j DROP should not be allowed - the action (DROP) should match the AUDIT "--type" value (accept). It would be nice if you could distinguish between the various jump targets, in other words - "DROP" is "standard" drop, but you could call the new audit drop ADROP for example. Similar with ACCEPT (which logs all ACCEPTed matches) and REJECT targets. I am more than willing to test this and give you a hand if needed, not least because if I manage to implement this feature throughout my entire audispd/auditd system I will be saving myself a *lot* of hassle - the main reason why I am so eager and can''t afford to wait until the .39 kernel comes out. ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
On 05/18/2011 05:10 PM, Mr Dash Four wrote:> > I am more than willing to test this and give you a hand if needed, not > least because if I manage to implement this feature throughout my entire > audispd/auditd system I will be saving myself a *lot* of hassle - the > main reason why I am so eager and can''t afford to wait until the .39 > kernel comes out.Okay -- give me a couple of days and I''ll send you a pre-release of 4.4.20-Beta3. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
On 18/05/2011 22:51, Mr Dash Four wrote:> Having been waiting for this for ages, the ability to use the (pretty > robust and secure) audit structure in Linux to log traffic has been > finally integrated into the kernel, together with its supporting files > and extensions in iptables. Unfortunately, this would be available in > .39 version and above of the kernel, which is quite a long way away. > > The new AUDIT target logs the following elements of any traffic and is > protocol independent (so it could be used equally well in iptables and > ebtables): > > - netfilter hook > - packet length > - incomming/outgoing interface > - MAC src/dst/proto for ethernet packets > - src/dst/protocol address for IPv4/IPv6 > - src/dst port for TCP/UDP/UDPLITE > - icmp type/code > > This data is available through the audit daemon (auditd) and is also > retrievable using standard audit tools (ausearch/aureport).Aha - this sounds perfect for my needs (see question a day ago about logging all traffic using NFLOG for accounting purposes). I haven''t come across AUDIT before though... Obviously apart from hitting google right away, where can I learn about the AUDIT target and find api info to build my own auditd demon? Thanks Ed W ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
Hi The .39 kernel has just been released. Ed W <lists@wildgooses.com> wrote: On 18/05/2011 22:51, Mr Dash Four wrote:> Having been waiting for this for ages, the ability to use the (pretty > robust and secure) audit structure in Linux to log traffic has been > finally integrated into the kernel, together with its supporting files > and extensions in iptables. Unfortunately, this would be available in > .39 version and above of the kernel, which is quite a long way away. > > The new AUDIT target logs the following elements of any traffic and is > protocol independent (so it could be used equally well in iptables and > ebtables): > > - netfilter hook > - packet length > - incomming/outgoing interface > - MAC src/dst/proto for ethernet packets > - src/dst/protocol address for IPv4/IPv6 > - src/dst port for TCP/UDP/UDPLITE > - icmp type/code > > This data is available through the audit daemon (auditd) and is also > retrievable using standard audit tools (ausearch/aureport).Aha - this sounds perfect for my needs (see question a day ago about logging all traffic using NFLOG for accounting purposes). I haven''t come across AUDIT before though... Obviously apart from hitting google right away, where can I learn about the AUDIT target and find api info to build my own auditd demon? Thanks Ed W ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. NOTE: URL removed for security purposes - contact terry.gilsenan@interoil.com for support. _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
>> The new AUDIT target logs the following elements of any traffic and is >> protocol independent (so it could be used equally well in iptables and >> ebtables): >> >> - netfilter hook >> - packet length >> - incomming/outgoing interface >> - MAC src/dst/proto for ethernet packets >> - src/dst/protocol address for IPv4/IPv6 >> - src/dst port for TCP/UDP/UDPLITE >> - icmp type/code >> >> This data is available through the audit daemon (auditd) and is also >> retrievable using standard audit tools (ausearch/aureport). >> > > Aha - this sounds perfect for my needs (see question a day ago about > logging all traffic using NFLOG for accounting purposes).Yes, I saw that and since I am - as you also are - a subscriber to the netfilter-dev mailing list, I followed the AUDIT target development since it was first conceived by Thomas Graf and the patch first posted on that mailing list on 14 Jan 2011. That was followed by a numerous improvements and finally integrated into the .39 kernel tree recently. I don''t think the .39 kernel itself is stable enough, but I do think that the actual AUDIT target code is good enough to be included in production environment, so I took it apart a couple of days ago and was finally able to integrate it into a more stable kernel (.35 is what I use here).> I haven''t > come across AUDIT before though... Obviously apart from hitting google > right away, where can I learn about the AUDIT target and find api info > to build my own auditd demon? >Since I''ve already done most of the work and have the patches needed to "enable" this functionality - at least on the .35 kernel - I can provide you with these plus instructions how to integrate them into the kernel. After that kernel is recompiled and installed you have to to the same with iptables (as I already pointed out I am using the latest iptables - 1.4.10 - as basis). Once this is done you are ready to go, provided you have a decent-enough version of auditd/audispd up and running. All you have to do then is define your targets and check your auditd for any messages and wait until shorewall catches up and is able to implement this in the same way the (NF)LOG targets currently are. As I already pointed out the AUDIT target is of great benefit to me as it enables me to centralise all system-related security events into one place (I also run a number of auditd daemons which are interlinked between various machines providing me with one place where all logs are stored and could be retrieved/viewed using ausearch/aureport). ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
> The .39 kernel has just been released. >It will be a while until it propagates down to the various distros, so knowing from experience how long that may take, I won''t be counting my chickens just yet! ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
> Okay -- give me a couple of days and I''ll send you a pre-release of > 4.4.20-Beta3. >No worries, I know it won''t be easy to integrate as the LOG target is used everywhere in shorewall. ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
On 05/19/2011 04:28 AM, Mr Dash Four wrote:> >> Okay -- give me a couple of days and I''ll send you a pre-release of >> 4.4.20-Beta3. >> > No worries, I know it won''t be easy to integrate as the LOG target is > used everywhere in shorewall.Here are the release notes for what I have working at this point. I''m distributing them for comment before sending out the code. 5) Support for the AUDIT target has been added. AUDIT is a feature of the 2.6.39 kernel and iptables 1.4.10 that allows security auditing of access decisions. Note: This support note is the only documentation of this support currently available. The support involves the following: a) A new "Audit Target" capability is added and is required for auditing support. To use AUDIT support with a capabilities file, that file must be generated using this or a later release. Use ''shorewall show capabilities'' after installing this release to see if your kernel/iptables support the AUDIT target. b) In /etc/shorewall/policy''s POLICY column, the policy (and default action, if any) may be followed by '':audit'' to cause application of the policy to be audited. It is allowed to also specify a log level on audited policies resulting in both auditing and logging. c) Three new builtin actions that may be used in the rules file, in macros and in other actions. AACCEPT - Audits and accepts the connection request ADROP - Audits and drops the connection request AREJECT - Audits and rejects It is allowed to specify a log level with these actions to provide both auditing and logging. d) The BLACKLIST_DISPOSITION, MACLIST_DISPOSITION and TCP_FLAGS_DISPOSITION options may be set as follows: BLACKLIST_DISPOSITION ADROP or AREJECT MACLIST_DISPOSITION ADROP AREJECT, unless MACLIST_TABLE=mangle TCP_FLAGS_DISPOSITION ADROP or AREJECT Thanks, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
On 05/19/2011 12:18 PM, Tom Eastep wrote:> Here are the release notes for what I have working at this point. I''m > distributing them for comment before sending out the code.And here''s a slightly cleaned up version. 5) Support for the AUDIT target has been added. AUDIT is a feature of the 2.6.39 kernel and iptables 1.4.10 that allows security auditing of access decisions. Note: This support note is the only documentation of this support currently available. The support involves the following: a) A new "AUDIT Target" capability is added and is required for auditing support. To use AUDIT support with a capabilities file, that file must be generated using this or a later release. Use ''shorewall show capabilities'' after installing this release to see if your kernel/iptables support the AUDIT target. b) In /etc/shorewall/policy''s POLICY column, the policy (and default action, if any) may be followed by '':audit'' to cause application of the policy to be audited. Only ACCEPT, DROP and REJECT policies may be audited. Example: #SOURCE DEST POLICY LOG # LEVEL net fw DROP:audit It is allowed to also specify a log level on audited policies resulting in both auditing and logging. c) Three new builtin actions that may be used in the rules file, in macros and in other actions. AACCEPT - Audits and accepts the connection request ADROP - Audits and drops the connection request AREJECT - Audits and rejects A log level may be supplied with these actions to provide both auditing and logging. Example: AACCEPT:info loc net ... d) The BLACKLIST_DISPOSITION, MACLIST_DISPOSITION and TCP_FLAGS_DISPOSITION options may be set as follows: BLACKLIST_DISPOSITION ADROP or AREJECT MACLIST_DISPOSITION ADROP AREJECT, unless MACLIST_TABLE=mangle TCP_FLAGS_DISPOSITION ADROP or AREJECT -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
> And here''s a slightly cleaned up version. > > 5) Support for the AUDIT target has been added. AUDIT is a feature of > the 2.6.39 kernel and iptables 1.4.10 that allows security auditing > of access decisions. > > Note: This support note is the only documentation of this support > currently available. >You may wish to expand on this a bit. This was submitted by Thomas Graf <tgraf@redhat.com> (the author of the AUDIT patch) on the netfilter-dev list back in January: This patch adds a new netfilter target which creates audit records for packets traversing a certain chain. It can be used to record packets which are rejected administratively as follows: -N AUDIT_DROP -A AUDIT_DROP -j AUDIT --type DROP -A AUDIT_DROP -j DROP A rule which would typically drop or reject a packet would then invoke the new chain to record packets before dropping them. -j AUDIT_DROP The module is protocol independent and works for iptables, ip6tables and ebtables. The following information is logged: - netfilter hook - packet length - incomming/outgoing interface - MAC src/dst/proto for ethernet packets - src/dst/protocol address for IPv4/IPv6 - src/dst port for TCP/UDP/UDPLITE - icmp type/code This is the man page for the iptables/AUDIT target: AUDIT This target allows to create audit records for packets hitting the target. It can be used to record accepted, dropped, and rejected packets. See auditd(8) for additional details. --type {accept|drop|reject} Set type of audit record. Example: iptables -N AUDIT_DROP iptables -A AUDIT_DROP -j AUDIT --type drop iptables -A AUDIT_DROP -j DROP And there is another explanation as to why AUDIT is needed: "AUDIT exists because a very large number of gov''t customers (Not just USA) have special requirements about how ''relevant'' information is gathered and stored. They require centralization and standardization and require pretty formal documentation describing it''s operation. The gov''t certification authority has recently added a requirement that they be able to log ''illegal attempted network connections'' via the approved audit facility. Thus, this patch." So, pick and choose if you find anything from the above suitable. The patch is pretty stable as it went through at least 3 revisions before it was merged into the (now final) .39 kernel tree. If what I submit in the next few days as suggestions (i.e. a patch with further additions to this functionality), there will be even more revisions added to it. The normal (audited) output as a result of AUDIT match looks like this: (raw auditd logs) type=NETFILTER_PKT msg=audit(1305830538.903:31222): action=1 hook=3 len=60 inif=? outif=eth0 saddr=10.1.1.7 daddr=10.2.1.1 ipid=61024 proto=6 sport=33271 dport=22 type=NETFILTER_PKT msg=audit(1305830538.920:31223): action=1 hook=3 len=52 inif=? outif=eth0 saddr=10.1.1.7 daddr=10.2.1.1 ipid=61025 proto=6 sport=33271 dport=22 (aureport) 18165. 05/19/2011 19:42:18 31222 NETFILTER_PKT nfsnobody unset 18166. 05/19/2011 19:42:18 31223 NETFILTER_PKT nfsnobody unset (ausearch) time->Thu May 19 19:42:18 2011 type=NETFILTER_PKT msg=audit(1305830538.903:31222): action=1 hook=3 len=60 inif=? outif=eth0 saddr=10.1.1.7 daddr=10.2.1.1 ipid=61024 proto=tcp sport=33271 dport=22 ---- time->Thu May 19 19:42:18 2011 type=NETFILTER_PKT msg=audit(1305830538.920:31223): action=1 hook=3 len=52 inif=? outif=eth0 saddr=10.1.1.7 daddr=10.2.1.1 ipid=61025 proto=tcp sport=33271 dport=22> b) In /etc/shorewall/policy''s POLICY column, the policy (and > default action, if any) may be followed by '':audit'' to cause > application of the policy to be audited. > > Only ACCEPT, DROP and REJECT policies may be audited. > > Example: > > #SOURCE DEST POLICY LOG > # LEVEL > net fw DROP:audit > > It is allowed to also specify a log level on audited policies > resulting in both auditing and logging. >Perfect! I assume if log level is not specified, no logging is performed, but auditing is still done, right?> c) Three new builtin actions that may be used in the rules file, > in macros and in other actions. > > AACCEPT - Audits and accepts the connection request > ADROP - Audits and drops the connection request > AREJECT - Audits and rejects > > A log level may be supplied with these actions to > provide both auditing and logging. > > Example: > > AACCEPT:info loc net ... >On a second thought, if it isn''t much of a trouble could you change this to A_ACCEPT, A_DROP and A_REJECT as AACCEPT looks like a spelling error. I know it was my suggestion, but as I see it now it doesn''t look quite right. ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
Hi> Yes, I saw that and since I am - as you also are - a subscriber to the > netfilter-dev mailing list, I followed the AUDIT target development > since it was first conceived by Thomas Graf and the patch first postedI have only been following the list for a few weeks - whilst I will try and scan the archives, are there any highlights I should know about?> Since I''ve already done most of the work and have the patches needed to > "enable" this functionality - at least on the .35 kernel - I can provide > you with these plus instructions how to integrate them into the kernel.Sure - please post. I assume it''s largely a case of simply grabbing the last modules and adjusting the makefiles/Kconfig?> All you have to do then is define your targets and check your auditd for > any messages and wait until shorewall catches up and is able to > implement this in the same way the (NF)LOG targets currently are. As I > already pointed out the AUDIT target is of great benefit to me as it > enables me to centralise all system-related security events into one > place (I also run a number of auditd daemons which are interlinked > between various machines providing me with one place where all logs are > stored and could be retrieved/viewed using ausearch/aureport).This actually sounds very cool and I''m immediately wondering how I can leverage it on our servers... Although we are now OT, can you perhaps sketch out some of the things you use this for in your system? Although I get the idea, I''m wondering if it is a good match for the kinds of things I might otherwise monitor with nagios/cacti? eg - jobs failing - sudden spam run - low disk space - network flow rates changing - increase in network hacking/probe attempts The last one seems within scope of the iptables stuff we are talking about, but seems like something more subtle than say a single rule So just curious what kind of things you find it helpful for? (For reference my architecture is a moderate number of virtual vserver machines on a small number of physical boxes) Thanks and good luck Ed W ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
On 05/19/2011 03:21 PM, Mr Dash Four wrote:> >> And here''s a slightly cleaned up version. >> >> 5) Support for the AUDIT target has been added. AUDIT is a feature of >> the 2.6.39 kernel and iptables 1.4.10 that allows security auditing >> of access decisions. >> >> Note: This support note is the only documentation of this support >> currently available. >> > You may wish to expand on this a bit. This was submitted by Thomas Graf > <tgraf@redhat.com> (the author of the AUDIT patch) on the netfilter-dev > list back in January:Thanks -- I''ll use some of this information when I write an Audit article for the web site.>> b) In /etc/shorewall/policy''s POLICY column, the policy (and >> default action, if any) may be followed by '':audit'' to cause >> application of the policy to be audited. >> >> Only ACCEPT, DROP and REJECT policies may be audited. >> >> Example: >> >> #SOURCE DEST POLICY LOG >> # LEVEL >> net fw DROP:audit >> >> It is allowed to also specify a log level on audited policies >> resulting in both auditing and logging. >> > Perfect! I assume if log level is not specified, no logging is > performed, but auditing is still done, right?Sure: Logging is still totally optional (as is auditing).> >> c) Three new builtin actions that may be used in the rules file, >> in macros and in other actions. >> >> AACCEPT - Audits and accepts the connection request >> ADROP - Audits and drops the connection request >> AREJECT - Audits and rejects >> >> A log level may be supplied with these actions to >> provide both auditing and logging. >> >> Example: >> >> AACCEPT:info loc net ... >> > On a second thought, if it isn''t much of a trouble could you change this > to A_ACCEPT, A_DROP and A_REJECT as AACCEPT looks like a spelling error. > I know it was my suggestion, but as I see it now it doesn''t look quite > right.Yes, I wasn''t particularly excited about the names either. They are easy to change at this point (one of the reasons for sending skeletal documentation with the initial release). Thanks, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
Based on feedback from Mr Dash Four, I''ve made several changes:
1) An ''audit'' option has been added to the
/etc/shorewall/blacklist file which causes the packets matching
the entryto be audited. ''audit'' may not be specified
together
with ''accept''.
2) With the exception of ''Limit'', the builtin actions
(dropBroadcast, rejNonSyn, etc.) now support
an ''audit'' parameter which causes all ACCEPT, DROP and
REJECTs
performed by the action to be audited. This allows creation of
audited versions of the Shorewall-provided default actions
(action.Drop and action.Reject).
3) When an audited action is specified in shorewall.conf
(BLACKLIST_DISPOSITION, etc.), auditing is now done in-line
rather than in a separate chain.
-Tom
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay