SRX

I need to prove a requirement that Juniper SRX and EX series devices do not shut down upon failure of auditing.  This is similar to showing a Linux box does not halt or go into single user mode if log space fills up or logging stops, by looking at the settings in auditd.conf and using auditctl.

The trouble is I don't know if I need to prove this by looking in the running config, in the OS or both.  I don't have access to the Juniper GUI, so I have to rely on CLI commands, which I'm only just beginning to learn.

If anyone can point me to documentation that shows definitely how to prove that an SRX or EX device (running Junos 19.x - 22.x) does not shut down upon audit failure, I would greatly appreciate the help.  For reference, I've seen the SRX STIG (V-214522) and have seen the "RT_FLOW"SESSION" events are being logged to the messages file, but that in itself doesn't prove (by our requirements) that the device will not shut down on audit failure (for whatever reason).

Thanks in advance.

How do your requirements define "audit failure" exactly??

Speaking of CLI, you can say start shell or, if you have the password, start shell user root to drop into the FreeBSD shell where you can do (almost) whatever you like.

------------------------------
Nikolay Semov

Original Message:
Sent: 06-19-2025 20:36
From: BRAD KINSER
Subject: Showing SRX Devices Do Not Shut Down Upon Audit Failure

I need to prove a requirement that Juniper SRX and EX series devices do not shut down upon failure of auditing.  This is similar to showing a Linux box does not halt or go into single user mode if log space fills up or logging stops, by looking at the settings in auditd.conf and using auditctl.

The trouble is I don't know if I need to prove this by looking in the running config, in the OS or both.  I don't have access to the Juniper GUI, so I have to rely on CLI commands, which I'm only just beginning to learn.

If anyone can point me to documentation that shows definitely how to prove that an SRX or EX device (running Junos 19.x - 22.x) does not shut down upon audit failure, I would greatly appreciate the help.  For reference, I've seen the SRX STIG (V-214522) and have seen the "RT_FLOW"SESSION" events are being logged to the messages file, but that in itself doesn't prove (by our requirements) that the device will not shut down on audit failure (for whatever reason).

Thanks in advance.

------------------------------
BRAD KINSER
------------------------------

Anything that would cause auditing to stop--audit service stopping, audit partition full, remote syslog host not available, etc.  I'm used to the checks for RHEL 7/8/9 that have settings in auditd.conf to tell the system to either write to syslog, halt, go to single user mode or other options if various conditions occur that affect auditing.  The auditctl tool can also be set to cause the system to do nothing, write to syslog or panic if there is a failure of kernel auditing.

I'm looking for the Juniper equivalents, whether they're on the running config or part of the OS, and how to definitively prove what the settings are, so I can capture objective evidence.

------------------------------
BRAD KINSER

Original Message:
Sent: 06-20-2025 09:57
From: Nikolay Semov
Subject: Showing SRX Devices Do Not Shut Down Upon Audit Failure

How do your requirements define "audit failure" exactly??

Speaking of CLI, you can say start shell or, if you have the password, start shell user root to drop into the FreeBSD shell where you can do (almost) whatever you like.

------------------------------
Nikolay Semov

Original Message:
Sent: 06-19-2025 20:36
From: BRAD KINSER
Subject: Showing SRX Devices Do Not Shut Down Upon Audit Failure

I need to prove a requirement that Juniper SRX and EX series devices do not shut down upon failure of auditing.  This is similar to showing a Linux box does not halt or go into single user mode if log space fills up or logging stops, by looking at the settings in auditd.conf and using auditctl.

The trouble is I don't know if I need to prove this by looking in the running config, in the OS or both.  I don't have access to the Juniper GUI, so I have to rely on CLI commands, which I'm only just beginning to learn.

If anyone can point me to documentation that shows definitely how to prove that an SRX or EX device (running Junos 19.x - 22.x) does not shut down upon audit failure, I would greatly appreciate the help.  For reference, I've seen the SRX STIG (V-214522) and have seen the "RT_FLOW"SESSION" events are being logged to the messages file, but that in itself doesn't prove (by our requirements) that the device will not shut down on audit failure (for whatever reason).

Thanks in advance.

------------------------------
BRAD KINSER
------------------------------

I don't think JunOS has auditing that parallels that in RHEL to begin with.

BSD / JunOS doesn't have an audit service like RHEL. There's no audit partition. Things may start breaking if disk space fills up, but that's just regular unexpected behavior rather than an intentional halt or something like that.

You may find references to an "audit-process" in JunOS -- that's for RADIUS accounting, far from what auditd is in RHEL.

Anything that would cause auditing to stop--audit service stopping, audit partition full, remote syslog host not available, etc.  I'm used to the checks for RHEL 7/8/9 that have settings in auditd.conf to tell the system to either write to syslog, halt, go to single user mode or other options if various conditions occur that affect auditing.  The auditctl tool can also be set to cause the system to do nothing, write to syslog or panic if there is a failure of kernel auditing.

I'm looking for the Juniper equivalents, whether they're on the running config or part of the OS, and how to definitively prove what the settings are, so I can capture objective evidence.

------------------------------
BRAD KINSER

Original Message:
Sent: 06-20-2025 09:57
From: Nikolay Semov
Subject: Showing SRX Devices Do Not Shut Down Upon Audit Failure

How do your requirements define "audit failure" exactly??

Speaking of CLI, you can say start shell or, if you have the password, start shell user root to drop into the FreeBSD shell where you can do (almost) whatever you like.

------------------------------
Nikolay Semov

Original Message:
Sent: 06-19-2025 20:36
From: BRAD KINSER
Subject: Showing SRX Devices Do Not Shut Down Upon Audit Failure

I need to prove a requirement that Juniper SRX and EX series devices do not shut down upon failure of auditing.  This is similar to showing a Linux box does not halt or go into single user mode if log space fills up or logging stops, by looking at the settings in auditd.conf and using auditctl.

The trouble is I don't know if I need to prove this by looking in the running config, in the OS or both.  I don't have access to the Juniper GUI, so I have to rely on CLI commands, which I'm only just beginning to learn.

If anyone can point me to documentation that shows definitely how to prove that an SRX or EX device (running Junos 19.x - 22.x) does not shut down upon audit failure, I would greatly appreciate the help.  For reference, I've seen the SRX STIG (V-214522) and have seen the "RT_FLOW"SESSION" events are being logged to the messages file, but that in itself doesn't prove (by our requirements) that the device will not shut down on audit failure (for whatever reason).

Thanks in advance.

------------------------------
BRAD KINSER
------------------------------

Thanks.  If I could find documentation that states those facts, that would help prove there is no default system halt related to auditing specifically.

I don't think JunOS has auditing that parallels that in RHEL to begin with.

BSD / JunOS doesn't have an audit service like RHEL. There's no audit partition. Things may start breaking if disk space fills up, but that's just regular unexpected behavior rather than an intentional halt or something like that.

You may find references to an "audit-process" in JunOS -- that's for RADIUS accounting, far from what auditd is in RHEL.

Anything that would cause auditing to stop--audit service stopping, audit partition full, remote syslog host not available, etc.  I'm used to the checks for RHEL 7/8/9 that have settings in auditd.conf to tell the system to either write to syslog, halt, go to single user mode or other options if various conditions occur that affect auditing.  The auditctl tool can also be set to cause the system to do nothing, write to syslog or panic if there is a failure of kernel auditing.

I'm looking for the Juniper equivalents, whether they're on the running config or part of the OS, and how to definitively prove what the settings are, so I can capture objective evidence.

------------------------------
BRAD KINSER

Original Message:
Sent: 06-20-2025 09:57
From: Nikolay Semov
Subject: Showing SRX Devices Do Not Shut Down Upon Audit Failure

How do your requirements define "audit failure" exactly??

Speaking of CLI, you can say start shell or, if you have the password, start shell user root to drop into the FreeBSD shell where you can do (almost) whatever you like.

------------------------------
Nikolay Semov

Original Message:
Sent: 06-19-2025 20:36
From: BRAD KINSER
Subject: Showing SRX Devices Do Not Shut Down Upon Audit Failure

I need to prove a requirement that Juniper SRX and EX series devices do not shut down upon failure of auditing.  This is similar to showing a Linux box does not halt or go into single user mode if log space fills up or logging stops, by looking at the settings in auditd.conf and using auditctl.

The trouble is I don't know if I need to prove this by looking in the running config, in the OS or both.  I don't have access to the Juniper GUI, so I have to rely on CLI commands, which I'm only just beginning to learn.

If anyone can point me to documentation that shows definitely how to prove that an SRX or EX device (running Junos 19.x - 22.x) does not shut down upon audit failure, I would greatly appreciate the help.  For reference, I've seen the SRX STIG (V-214522) and have seen the "RT_FLOW"SESSION" events are being logged to the messages file, but that in itself doesn't prove (by our requirements) that the device will not shut down on audit failure (for whatever reason).

Thanks in advance.

------------------------------
BRAD KINSER
------------------------------