Description

Syslog based on only specific conditions defined within Stateful firewall terms requires raising the severity levels under service-sets.

Symptoms

By default, syslog defined in the [services service-set service-set-name] hierarchy logs everything, regardless of the action set for 'then syslog' statement defined in "term" under the [services stateful-firewall rule] hierarchy.

Example:
To configure syslog only for destination address 192.168.1.1:

services {
    service-set test_sfw {
        syslog {
            host local {   
            services any;    <<<< low severity level
        }
    }
    stateful-firewall-rules accept_all;
        interface-service {
            service-interface sp-0/0/0;
        }
    }
    stateful-firewall {
        rule accept_all {
            match-direction input-output;
            term syslog {
                from {
                    destination-address {
                        192.168.1.1/32;
                    }
                }
                then {
                    accept;
                    syslog;
                }
            }
            term no_sylog {
                from {
                    destination-address {
                        192.168.1.2/32;
                    }
                }
                then {
                    accept;
                }
            }
        }
    }
}

In this example, packets sent to 192.168.1.1 will generate syslog as expected since it is defined in stateful-firewall term.
user@router> show log messages | match 192.168.1.1
Oct 20 15:17:00 J4350-B8_36 (FPC Slot 0, PIC Slot 0) {TEST_SFW.EN_US}[FWNAT]: ASP_SFW_RULE_ACCEPT: proto 1 (ICMP ECHO REQUEST) application: icmp, ge-0/0/1.0:9.9.9.2:31028 -> 192.168.1.1, Match SFW accept rule-set: , rule: accept_all, term: syslog
Oct 20 15:17:00 J4350-B8_36 (FPC Slot 0, PIC Slot 0) {TEST_SFW.EN_US}[FWNAT]: ASP_SFW_CREATE_ACCEPT_FLOW: proto 1 (ICMP ECHO REQUEST) application: icmp, ge-0/0/1.0:9.9.9.2:31028 -> 192.168.1.1, creating forward or watch flow

However, packets for 192.168.1.2  which are not configured for syslog would also appear in the log.
user@router> show log messages | match 192.168.1.2
Oct 20 15:17:00 J4350-B8_36 (FPC Slot 0, PIC Slot 0) {TEST_SFW.EN_US}[FWNAT]: ASP_SFW_RULE_ACCEPT: proto 1 (ICMP ECHO REQUEST) application: icmp, ge-0/0/1.0:9.9.9.1:31028 -> 192.168.1.2, Match SFW accept rule-set: , rule: accept_all, term: no_syslog
Oct 20 15:17:00 J4350-B8_36 (FPC Slot 0, PIC Slot 0) {TEST_SFW.EN_US}[FWNAT]: ASP_SFW_CREATE_ACCEPT_FLOW: proto 1 (ICMP ECHO REQUEST) application: icmp, ge-0/0/1.0:9.9.9.1:31028 -> 192.168.1.2, creating forward or watch flow

Solution

This is by design. This behavior is different compared to stateless firewall filters. By design, syslog defined in stateful-firewall terms override syslog parameters defined at the service-set or the interface level. In order to only send syslog based on what is defined in stateful-firewall rule terms, you must raise the syslog severity level at [services service-set service-set-name] hierarchy.

The following is an example where service-set syslog is set to a high severity level. Thus, syslog is generated only  for conditions defined within stateful-firewall terms. In this example, syslog is done only for destination address of 192.168.1.1 as described in the stateful-firewall rule.

services {
    service-set test_sfw {
        syslog {
            host local {   
            services critical;    <<<< higher severity level
        }
    }
    stateful-firewall-rules accept_all;
        interface-service {
            service-interface sp-0/0/0;
        }
    }
    stateful-firewall {
        rule accept_all {
            match-direction input-output;
            term syslog {
                from {
                    destination-address {
                        192.168.1.1/32;
                    }
                }
                then {
                    accept;
                    syslog;
                }
            }
            term no_sylog {
                from {
                    destination-address {
                        192.168.1.2/32;
                    }
                }
                then {
                    accept;
                }
            }
        }
    }
}

Note that the following 5 severity levels would give similar desired output: Emergency, Alert, Critical, Error, Warning, Notice.

The following defines the severity levels:
http://www.juniper.net/techpubs/software/junos/junos92/swconfig-system-basics/including-priority-information-in-system-log-messages.html

The following describes the override behavior of the syslog:
http://www.juniper.net/techpubs/software/junos/junos82/swconfig82-services/html/service-set-config13.html