Juniper Network Switches

Overview

Juniper Networks' JunOS is an advanced operating system powering Juniper's networking devices, renowned for its reliability, performance, and comprehensive feature set for routing, switching, and security functionalities in enterprise networks.

Vendor: Juniper
Plan: Defend Prime
Supported environment: On prem
Version Compatibility: 23.2
Detection based on: Telemetry

Warning

Important note - This format is currently in beta. We highly value your feedback to improve its performance.

Supported events

This integration supports the following events:

Firewall events

Configure

This setup guide will show you how to forward your Juniper Switches logs to Sekoia.io by means of a syslog transport channel.

Prerequisites

Have an internal log concentrator

Enable Syslog forwarding

Log into the firewall console

Configure the log forwarding to the log concentrator

root@:~ #cli

root> configure

[edit]
root# set system syslog host <ip of the log concentrator> firewall any

[edit]
root# set system syslog host <ip of the log concentrator> port <port of the log concentrator>

[edit]
root# commit

Configure a firewall filters to log events (see Juniper documentation for more details)

user@:~ #cli

user> configure

[edit]
user# edit firewall family <family> filter <filter_name>

[edit firewall family <family> filter <filter_name>]
user# set term <term_name> then syslog

[edit firewall family <family> filter <filter_name>]
user# commit

Apply the filter to a logical interface (see Juniper documentation for more details)

user@:~ #cli

user> configure

[edit]
user# edit interfaces <interface_name> unit 0 family <family>

[edit interfaces <interface_name> unit 0 family <family>]
user# set filter input <filter_name>

[edit interfaces <interface_name> unit 0 family <family>]
user# commit

Exit the console

Create the intake

Go to the intake page and create a new intake from the format Juniper Switches.

Forward logs to Sekoia.io

Please consult the Syslog Forwarding documentation to forward these logs to Sekoia.io.

Raw Events Samples

In this section, you will find examples of raw logs as generated natively by the source. These examples are provided to help integrators understand the data format before ingestion into Sekoia.io. It is crucial for setting up the correct parsing stages and ensuring that all relevant information is captured.

test_network_1_1test_network_1_2test_network_2test_network_3

FW: et-1/1/1.2505 D 09c9:0800 4a:74:92:52:6c:20 -> bd:83:17:63:d5:f7  tcp 1.2.3.4 5.6.7.8 46736  3405 (1 packets)

FW: et-1/1/1.2505 D 09c9:0800 4a:74:92:52:6c:20 -> 71:89:a4:34:a0:b4  tcp 1.2.3.4 5.6.7.8 60000 29822 (1 packets)

FW: lsi.0        D 4a:74:92:52:6c:20 bd:83:17:63:d5:f7 8100:9 8847:5dc 13b  UDP 1.2.3.4 5.6.7.8 52767   161 (1 packets)

FW: ge-0/0/0.0   A icmp 1.2.3.4 5.6.7.8     8     0 (1 packets)

Detection section

The following section provides information for those who wish to learn more about the detection capabilities enabled by collecting this intake. It includes details about the built-in rule catalog, event categories, and ECS fields extracted from raw events. This is essential for users aiming to create custom detection rules, perform hunting activities, or pivot in the events page.

The following Sekoia.io built-in rules match the intake Juniper Networks Switches [BETA]. This documentation is updated automatically and is based solely on the fields used by the intake which are checked against our rules. This means that some rules will be listed but might not be relevant with the intake.

SEKOIA.IO x Juniper Networks Switches [BETA] on ATT&CK Navigator

Cryptomining

Detection of domain names potentially related to cryptomining activities.

Effort: master

Dynamic DNS Contacted

Detect communication with dynamic dns domain. This kind of domain is often used by attackers. This rule can trigger false positive in non-controlled environment because dynamic dns is not always malicious.

Effort: master

Exfiltration Domain

Detects traffic toward a domain flagged as a possible exfiltration vector.

Effort: master

Remote Access Tool Domain

Detects traffic toward a domain flagged as a Remote Administration Tool (RAT).

Effort: master

SEKOIA.IO Intelligence Feed

Detect threats based on indicators of compromise (IOCs) collected by SEKOIA's Threat and Detection Research team.

Effort: elementary

Sekoia.io EICAR Detection

Detects observables in Sekoia.io CTI tagged as EICAR, which are fake samples meant to test detection.

Effort: master

TOR Usage

Detects TOR usage, based on the IP address and the destination port (filtered on NTP). TOR is short for The Onion Router, and it gets its name from how it works. TOR intercepts the network traffic from one or more apps on user’s computer, usually the user web browser, and shuffles it through a number of randomly-chosen computers before passing it on to its destination. This disguises user location, and makes it harder for servers to pick him/her out on repeat visits, or to tie together separate visits to different sites, this making tracking and surveillance more difficult. Before a network packet starts its journey, user’s computer chooses a random list of relays and repeatedly encrypts the data in multiple layers, like an onion. Each relay knows only enough to strip off the outermost layer of encryption, before passing what’s left on to the next relay in the list.

Effort: master

TOR Usage Generic Rule

Detects TOR usage globally, whether the IP is a destination or source. TOR is short for The Onion Router, and it gets its name from how it works. TOR intercepts the network traffic from one or more apps on user’s computer, usually the user web browser, and shuffles it through a number of randomly-chosen computers before passing it on to its destination. This disguises user location, and makes it harder for servers to pick him/her out on repeat visits, or to tie together separate visits to different sites, this making tracking and surveillance more difficult. Before a network packet starts its journey, user’s computer chooses a random list of relays and repeatedly encrypts the data in multiple layers, like an onion. Each relay knows only enough to strip off the outermost layer of encryption, before passing what’s left on to the next relay in the list.

Effort: master

Event Categories

The following table lists the data source offered by this integration.

Data Source	Description
`Network device logs`	None

In details, the following table denotes the type of events produced by this integration.

Name	Values
Kind	``
Category	`network`
Type	`info`

Transformed Events Samples after Ingestion

This section demonstrates how the raw logs will be transformed by our parsers. It shows the extracted fields that will be available for use in the built-in detection rules and hunting activities in the events page. Understanding these transformations is essential for analysts to create effective detection mechanisms with custom detection rules and to leverage the full potential of the collected data.

test_network_1_1.jsontest_network_1_2.jsontest_network_2.jsontest_network_3.json

{
    "message": "FW: et-1/1/1.2505 D 09c9:0800 4a:74:92:52:6c:20 -> bd:83:17:63:d5:f7  tcp 1.2.3.4 5.6.7.8 46736  3405 (1 packets)",
    "event": {
        "action": "discard",
        "category": [
            "network"
        ],
        "type": [
            "info"
        ]
    },
    "destination": {
        "address": "5.6.7.8",
        "ip": "5.6.7.8",
        "mac": "bd-83-17-63-d5-f7",
        "port": 3405
    },
    "network": {
        "packets": 1,
        "transport": "tcp"
    },
    "observer": {
        "ingress": {
            "interface": {
                "name": "et-1/1/1.2505"
            }
        },
        "product": "switch",
        "vendor": "Juniper"
    },
    "related": {
        "ip": [
            "1.2.3.4",
            "5.6.7.8"
        ]
    },
    "source": {
        "address": "1.2.3.4",
        "ip": "1.2.3.4",
        "mac": "4a-74-92-52-6c-20",
        "port": 46736
    }
}

{
    "message": "FW: et-1/1/1.2505 D 09c9:0800 4a:74:92:52:6c:20 -> 71:89:a4:34:a0:b4  tcp 1.2.3.4 5.6.7.8 60000 29822 (1 packets)",
    "event": {
        "action": "discard",
        "category": [
            "network"
        ],
        "type": [
            "info"
        ]
    },
    "destination": {
        "address": "5.6.7.8",
        "ip": "5.6.7.8",
        "mac": "71-89-a4-34-a0-b4",
        "port": 29822
    },
    "network": {
        "packets": 1,
        "transport": "tcp"
    },
    "observer": {
        "ingress": {
            "interface": {
                "name": "et-1/1/1.2505"
            }
        },
        "product": "switch",
        "vendor": "Juniper"
    },
    "related": {
        "ip": [
            "1.2.3.4",
            "5.6.7.8"
        ]
    },
    "source": {
        "address": "1.2.3.4",
        "ip": "1.2.3.4",
        "mac": "4a-74-92-52-6c-20",
        "port": 60000
    }
}

{
    "message": "FW: lsi.0        D 4a:74:92:52:6c:20 bd:83:17:63:d5:f7 8100:9 8847:5dc 13b  UDP 1.2.3.4 5.6.7.8 52767   161 (1 packets)",
    "event": {
        "action": "discard",
        "category": [
            "network"
        ],
        "type": [
            "info"
        ]
    },
    "destination": {
        "address": "5.6.7.8",
        "ip": "5.6.7.8",
        "mac": "bd-83-17-63-d5-f7",
        "port": 161
    },
    "network": {
        "packets": 1,
        "transport": "udp"
    },
    "observer": {
        "ingress": {
            "interface": {
                "name": "lsi.0"
            }
        },
        "product": "switch",
        "vendor": "Juniper"
    },
    "related": {
        "ip": [
            "1.2.3.4",
            "5.6.7.8"
        ]
    },
    "source": {
        "address": "1.2.3.4",
        "ip": "1.2.3.4",
        "mac": "4a-74-92-52-6c-20",
        "port": 52767
    }
}

{
    "message": "FW: ge-0/0/0.0   A icmp 1.2.3.4 5.6.7.8     8     0 (1 packets)",
    "event": {
        "action": "accept",
        "category": [
            "network"
        ],
        "type": [
            "info"
        ]
    },
    "destination": {
        "address": "5.6.7.8",
        "ip": "5.6.7.8",
        "port": 0
    },
    "network": {
        "packets": 1,
        "transport": "icmp"
    },
    "observer": {
        "ingress": {
            "interface": {
                "name": "ge-0/0/0.0"
            }
        },
        "product": "switch",
        "vendor": "Juniper"
    },
    "related": {
        "ip": [
            "1.2.3.4",
            "5.6.7.8"
        ]
    },
    "source": {
        "address": "1.2.3.4",
        "ip": "1.2.3.4",
        "port": 8
    }
}

Extracted Fields

The following table lists the fields that are extracted, normalized under the ECS format, analyzed and indexed by the parser. It should be noted that infered fields are not listed.

Name	Type	Description
`destination.ip`	`ip`	IP address of the destination.
`destination.mac`	`keyword`	MAC address of the destination.
`destination.port`	`long`	Port of the destination.
`event.category`	`keyword`	Event category. The second categorization field in the hierarchy.
`event.type`	`keyword`	Event type. The third categorization field in the hierarchy.
`network.packets`	`long`	Total packets transferred in both directions.
`network.transport`	`keyword`	Protocol Name corresponding to the field `iana_number`.
`observer.ingress.interface.name`	`keyword`	Interface name
`observer.product`	`keyword`	The product name of the observer.
`observer.vendor`	`keyword`	Vendor name of the observer.
`source.ip`	`ip`	IP address of the source.
`source.mac`	`keyword`	MAC address of the source.
`source.port`	`long`	Port of the source.

For more information on the Intake Format, please find the code of the Parser, Smart Descriptions, and Supported Events here.