Configuring Terminal Security Policies & Command Guardrails

1. Overview & Purpose of Terminal Policies #

The Terminal Policies is the central security control plane in MikroWizard for governing privileged CLI access across network devices (MikroTik RouterOS, Cisco IOS, Huawei, Juniper,linux host) and host operating systems (Linux, macOS, BSD).

Unlike traditional consoles that only log commands after execution, MikroWizard Terminal Policies enforce zero-trust, pre-execution command inspection.

Every keystroke and command token submitted in an TTY session is evaluated against active policy rules, defense heuristics, and kernel system-call traps before being forwarded to the target device shell.

• Human Error Prevention: Blocks catastrophic accidental commands such as /system reset-configuration, reboot, or rm -rf /.
• Privilege Escalation Control: Prevents unauthorized users from spawning subshells or dumping unmasked credential exports.
• Multi-Vendor Syntax Normalization: Applies vendor-specific or brand-agnostic rules across mixed infrastructure.
• Audit Binding: Links every evaluated command directly to tamper-evident audit logs in the compliance repository.

2. The Access Policies Management #

Navigating to Terminal Policies in the left navigation sidebar displays the primary Access Policies table.

3. General Policy Settings (Field-by-Field Reference) #

Clicking the blue + New Policy button opens the New Terminal Policy modal dialog. The modal is organized into three distinct cards: General Settings, Strict Mode Protections, and Agent Modes.

Field Specifications: #

1. Policy Name (Required):
   
   Effect: Sets the human-readable identifier. This name appears in Device Group dropdowns when assigning policies to router pools (e.g., Default NOC Guardrails, Strict L1 Operator Filter).
   
2. Description (Optional):
   
   Effect: Provides operational documentation visible in the policy summary table.
   
3. Type (Required):
   
   Controls the global default evaluation logic for commands:
   • Blacklist (Default Allow): Permits all commands by default. Commands that match defined rules are intercepted and blocked. Ideal for general engineering staff where only dangerous or destructive commands must be restricted.
   • Whitelist (Default Deny): Blocks all commands by default. Only commands explicitly matching defined rules are allowed to execute. Recommended for junior technicians, external contractors, and read-only auditing roles.
   • Auto-Execute: Switches the policy into non-interactive automation mode. Executes a predefined batch of diagnostic commands automatically upon session connection and streams output.
4. Matching (Available for Blacklist & Whitelist):
   
   Defines the default string evaluation strategy:
   • Token (Exact): Compares command words token-by-token. For example, a rule for show version matches any command starting with those exact tokens. Faster and immune to regex syntax errors.
   • Regex (Pattern): Evaluates commands against PCRE regular expressions. Allows sophisticated wildcard matching, alternatives (e.g. /system (reboot|reset-configuration).*), and flag detection.

4. Defense Levels & Shell Bypass Protections #

In standard web terminals, malicious actors or careless users can easily bypass basic string blacklists by using subshell evaluations, backticks, or variable expansions whyle this worked perfect for normal network equipment but it is diffrent when it comes to servers/linux hosts.(e.g. typing $(echo rm) -rf / instead of rm -rf /).
The Defense Level setting configures the gateway’s heuristic pre-parser:

5. Strict Mode Protections & Blocked Binaries #

When Defense Level is set to Strict, the Strict Mode Protections configuration card becomes active:

Blocked Binaries Input Field: Enter a comma-separated list of executable binary names (e.g. bash, sh, python, python3, perl, php, node, zsh, ruby). The policy engine intercepts any execution of these binaries at both the AST parser level and the kernel syscall boundary, preventing users from spawning unrestricted subshells to evade command filtering.

6. OS-Specific Agent Enforcement Modes #

For target devices running general-purpose operating systems (Linux servers, macOS management stations, FreeBSD bastions), MikroWizard provides tailored OS enforcement agents configured in the Agent Modes card:

7. Defining & Managing Command Rules #

The Rules section at the bottom of the modal allows defining granular command patterns:

1. Brand Coverage Dropdown: Select whether a rule applies to All Brands or a specific vendor operating system (MikroTik, Cisco, Huawei, ZTE, Juniper, Linux, Windows, Fortinet, Darwin, FreeBSD).
2. Rule Matching Override: Choose Policy Default, Token, or Regex for that specific rule row.
3. Rule Input Field: Enter the exact command or PCRE regular expression pattern.
4. AI Help Button (): Moves to chatgpt to help generate verified regular expressions from natural language prompts (e.g. “Block all factory reset commands and password changes on RouterOS”).

Practical Command Rule Examples: #

8. Auto-Execute Policy Mode #

When Policy Type is set to Auto-Execute, the policy switches from interactive filtering to non-interactive diagnostic automation:

In the Auto-Execute Commands textarea, enter diagnostic or audit commands separated by newlines (e.g. show version, /system resource print, /interface print brief). When an operator connects using an Auto-Execute policy, the Terminal Gateway executes the commands sequentially, streams real-time output, and closes the session without granting an interactive prompt.

9. Command Expansions Tab (Shorthands & Aliases) #

Network engineers frequently use CLI abbreviations (e.g., typing sh ip int br instead of show ip interface brief or wr m instead of write memory). If a policy rule only checks full command strings, abbreviations could bypass filters or fail to trigger whitelists. The Command Expansions tab solves this by canonicalizing abbreviations before policy inspection.

Creating a New Command Expansion: #

1. Click the Command Expansions tab at the top of the console.
2. Click the blue + New Expansion button in the top-right toolbar.
3. In the modal dialog, configure:
   • Brand: Select target operating system (e.g. Cisco, MikroTik, or Generic).
   • Expansion Type: Choose Shorthand (Expand alias to full) or Full Command (Exact matching only).
   • Shorthand: Enter the abbreviated alias (e.g. sh l).
   • Full Command: Enter the expanded canonical command (e.g. show lldp neighbors).
4. Click Save to register the expansion.

10. Verifying Created Policies in the Inventory #

Once saved, the new policy appears immediately in the Access Policies table with its calculated rule count, defense badges, and covered brands:

To apply this policy to your network fleet, navigate to Device Groups (or Manage Users → Device Groups tab), click the Edit button under the Terminal Policy column for your target router group (e.g. containing CHR-Tower01), and select your newly configured policy.