view release on metacpan or  search on metacpan

lib/Algorithm/ToNumberMunger.pm  view on Meta::CPAN

Named-map enum (lookup rules as L</dns_rcode_enum>) for Suricata's
C<app_proto> field -- the detected application-layer protocol on a flow or
alert (C<http>, C<dns>, C<tls>, C<ssh>, C<smtp>, C<dcerpc>, C<quic>, ...),
including C<failed> and C<unknown>, which are usually the very rows worth
keeping. These are unordered ordinals of this module's invention (Suricata
logs a string, not a number), so numeric inputs are B<not> passed through.
C<ssl> is accepted as an alias for C<tls> and C<ikev2> for C<ike>. This is
distinct from L</ip_proto_enum>, which numbers the L4 protocol
(C<tcp>/C<udp>/...) rather than the app layer riding on it.

=head2 tcp_state_enum

    { munger => 'tcp_state_enum', default => -1 }

Named-map enum (lookup rules as L</dns_rcode_enum>) mapping the TCP state
machine, as Suricata logs it under C<flow.tcp.state>, to an B<ordinal> along
the connection lifecycle: C<none> 0, C<syn_sent> 1, C<syn_recv> 2,
C<established> 3, C<fin_wait1> 4, C<fin_wait2> 5, C<closing> 6, C<time_wait>
7, C<close_wait> 8, C<last_ack> 9, C<closed> 10. Ordinal so "further along
teardown than expected" is a monotone feature a threshold split can express.
Being ordinals of our own invention, numeric inputs are not passed through.

=head2 flow_state_enum

    { munger => 'flow_state_enum', default => -1 }

Named-map enum (lookup rules as L</dns_rcode_enum>) for Suricata's
C<flow.state>: C<new> 0, C<established> 1, C<closed> 2, C<bypassed> 3,
C<local_bypass> 4 -- roughly ordinal along the flow lifecycle. Numeric inputs
are not passed through.

=head2 flow_reason_enum

    { munger => 'flow_reason_enum', default => -1 }

Named-map enum (lookup rules as L</dns_rcode_enum>) for Suricata's
C<flow.reason>, why a flow was logged out: C<timeout> 0, C<forced> 1,
C<shutdown> 2, C<unknown> 3. Numeric inputs are not passed through.

=head2 suricata_action_enum

    { munger => 'suricata_action_enum', default => -1 }

Named-map enum (lookup rules as L</dns_rcode_enum>) for Suricata's
C<alert.action> and the related rule/drop actions: C<allowed> 0, C<blocked>
1, C<pass> 2, C<drop> 3, C<reject> 4, C<alert> 5. In IDS mode the field is
C<allowed>/C<blocked>; the rule-action names are accepted too for IPS feeds
and C<drop> events. Numeric inputs are not passed through.

=head2 postfix_status_enum

    { munger => 'postfix_status_enum', default => -1 }

Named-map enum (lookup rules as L</dns_rcode_enum>) for Postfix's delivery
C<status=> disposition, numbered in a rough sent-to-failed severity order so
a threshold split is meaningful: C<sent> 0, C<deferred> 1, C<bounced> 2,
C<expired> 3, C<deliverable> 4, C<undeliverable> 5, C<hold> 6, C<discard> 7,
C<filtered> 8, C<reject> 9, C<softbounce> 10. Stock delivery agents emit only
C<sent>/C<deferred>/C<bounced>/C<expired>; C<deliverable>/C<undeliverable> come
from address verification (C<verify>), and the remainder cover HOLD/DISCARD
actions and values common log normalizers emit. Being labels of this module's
numbering, numeric inputs are not passed through.

=head2 spf_result_enum

    { munger => 'spf_result_enum', default => -1 }

Named-map enum (lookup rules as L</dns_rcode_enum>) for an SPF check result
(RFC 7208), as logged by policyd-spf or carried in an C<Authentication-Results>
header, numbered pass-to-fail: C<pass> 0, C<neutral> 1, C<none> 2, C<softfail>
3, C<fail> 4, C<temperror> 5, C<permerror> 6. The older spellings C<error>
(for C<temperror>) and C<unknown> (for C<permerror>) are accepted as aliases.
Numeric inputs are not passed through.

=head2 dkim_result_enum

    { munger => 'dkim_result_enum', default => -1 }

Named-map enum (lookup rules as L</dns_rcode_enum>) for a DKIM verification
result (RFC 8601), as logged by opendkim or carried in an
C<Authentication-Results> header, numbered pass-to-fail: C<pass> 0, C<neutral>
1, C<none> 2, C<policy> 3, C<fail> 4, C<temperror> 5, C<permerror> 6. The older
spellings C<error> (for C<temperror>) and C<unknown> (for C<permerror>) are
accepted as aliases. Numeric inputs are not passed through.

=head2 dmarc_result_enum

    { munger => 'dmarc_result_enum', default => -1 }

Named-map enum (lookup rules as L</dns_rcode_enum>) for a DMARC evaluation
result (RFC 7489 / RFC 8601), as logged by opendmarc or carried in an
C<Authentication-Results> header: C<pass> 0, C<none> 1, C<fail> 2, C<temperror>
3, C<permerror> 4, and opendmarc's C<bestguesspass> 5. This is the DMARC
I<result> (did the message pass alignment), not the policy I<disposition>
(C<none>/C<quarantine>/C<reject>) -- for that, use a plain L</enum>. Numeric
inputs are not passed through.

=head2 sasl_mech_enum

    { munger => 'sasl_mech_enum', default => -1 }

Named-map enum (lookup rules as L</dns_rcode_enum>) for the SASL
authentication mechanism -- as Dovecot logs C<mech=>, Postfix logs
C<sasl_method=>, and submission/IMAP/POP3 auth report -- numbered in a rough
B<weakest-to-strongest> order so the ordinal carries a little signal on its
own: the cleartext and C<anonymous> mechanisms sort low, the legacy
challenge-response ones (C<cram-md5>, C<digest-md5>, C<ntlm>, ...) in the
middle, then C<srp>/C<scram-*>, the OAuth/federated tokens, and finally the
Kerberos/GSS and certificate (C<external>) mechanisms. About two dozen
mechanisms are baked in, covering the IANA registry plus the ubiquitous
non-registered C<login>, C<xoauth2>, and C<apop>. Being ordinals of this
module's numbering, numeric inputs are not passed through; an unlisted
mechanism croaks unless a numeric C<default> is given.

If you would rather the number carry B<no> implied gradient, see
L</sasl_mech_iana_enum>, which numbers the same set alphabetically.

=head2 sasl_mech_iana_enum

    { munger => 'sasl_mech_iana_enum', default => -1 }