<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Before I put this out into the public I
thought I would familiarize myself with it again, and I think
there is a mistake that never seems to get invoked anyways.
Perhaps Balázs could review.<br>
<br>
Attached is the correlate.xml patterndb for correlating the
messages.<br>
<br>
I think the mistake is the the two "action condition" clauses
where the MESSAGE<br>
is set to "${csologline}@1". I think this should be
"${csologline}". It is working in my environment,<br>
so perhaps the clause "$(context-length)" == "$max" is never true
and it is the timeout that always gets triggered.<br>
<br>
The other consideration is that if these unwrapped log messages
are sent on to an analysis framework that understands the native
format of these messages, the patterndb should maintain the
message number, max and counters. To do that the rule IDs *_0
should set csologline with<br>
<br>
<value name="csologline">CSCOacs_Failed_Attempts $msgnum 1 0
$line</value><br>
<value name="csologline">CSCOacs_Passed_Authentications
$msgnum 1 0 $line</value><br>
<br>
I can not do that in my environment because I have already
rewritten these log lines to give them a program name.<br>
<br>
Here are the details.<br>
<br>
1. I use the rewrite.xml pattern database to detect the acs log
lines and give them a program name.<br>
<br>
template t_rewrite { template("$MSGHDR$MESSAGE");
template_escape(no); };<br>
parser p_rewrite {<br>
db_parser(<br>
file("rewrite.xml")<br>
inject_mode(internal)<br>
template(t_rewrite)<br>
);<br>
};<br>
<br>
2. Then I use the correlate.xml pattern database to unwrap the log
messages. This only works because I have already added the program
name.<br>
<br>
parser p_correlate {<br>
db_parser(<br>
file("correlate.xml")<br>
inject_mode(pass-through)<br>
);<br>
};<br>
<br>
<br>
The final bit of configuration to get this all working.<br>
<br>
filter f_correlate_drop {<br>
tags("CORRELATE_DROP") and not tags("CORRELATE_CONTINUE");<br>
};<br>
<br>
<br>
log {<br>
source(s_network);<br>
parser(p_rewrite);<br>
parser(p_correlate);<br>
# if the p_correlate parser is unwrapping lines, then the
line snippits need to be dropped<br>
log {<br>
filter(f_correlate_drop);<br>
flags(final);<br>
};<br>
... whatever else you need for logging<br>
};<br>
<br>
<br>
I hope this makes it into some official docs, blog or repository
for everyone to use.<br>
<br>
Evan<br>
<br>
<br>
On 11/15/2017 09:01 AM, Scheidler, Balázs wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CANWQT2NgBnZoJzHf=YKvWJ0Oa=JhP7cJ2R=ZTUG=vSe=L1sqyA@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="auto">Yup, I might even add this use case to my latedt
application parsers framewrok.</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Nov 15, 2017 17:57, "Kókai Péter"
<<a href="mailto:peter.kokai@balabit.com"
moz-do-not-send="true">peter.kokai@balabit.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hello,
<div><br>
</div>
<div>It would be really useful if you could share it (Y).</div>
<div><br>
</div>
<div>Kokan</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Wed, Nov 15, 2017 at 5:18 PM Evan Rempel
<<a href="mailto:erempel@uvic.ca" target="_blank"
moz-do-not-send="true">erempel@uvic.ca</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div
class="m_-6223846521663224332m_755489706249316649moz-cite-prefix">Answered
out of band because the details are messy.<br>
If there is sufficient interest I can clean it up
and post it to the list.</div>
</div>
<div text="#000000" bgcolor="#FFFFFF">
<div
class="m_-6223846521663224332m_755489706249316649moz-cite-prefix"><br>
<br>
Evan.</div>
</div>
<div text="#000000" bgcolor="#FFFFFF">
<div
class="m_-6223846521663224332m_755489706249316649moz-cite-prefix"><br>
<br>
On 11/15/2017 04:26 AM, Scot wrote:<br>
</div>
</div>
<div text="#000000" bgcolor="#FFFFFF">
<blockquote type="cite">
<div dir="ltr">Thanks Evan,
<div>Didn't see much in term of cisco
documentation of the format. Is that 1st number
in the message header unique to each message and
do you share patterns ?</div>
<div><br>
</div>
<div>Scot</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Nov 14, 2017 at
8:36 PM, Evan Rempel <span dir="ltr"><<a
href="mailto:erempel@uvic.ca"
target="_blank" moz-do-not-send="true">erempel@uvic.ca</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">At our side we used a
patterndb to unwrap the ACS logs into single
long line messages. These long lines seem to
be wrapped at the source (Cisco device) before
sending to the syslog server.<br>
<br>
Evan.
<div>
<div
class="m_-6223846521663224332m_755489706249316649h5"><br>
<br>
On 11/14/2017 02:03 PM, Scot wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"> Hi,<br>
<br>
Has anyone worked with ACS logs and
solved the message header limit ?<br>
We can get syslog working but as
expected the message gets truncated.<br>
<br>
Local logs on the ACS have the entire
payload.<br>
<br>
Thinking there may be a way to script a
log fetch or something.<br>
<br>
Thanks</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<p><br>
</p>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>