Skip to main content
Glama
OpenSIPS

OpenSIPS MCP Server

Official
by OpenSIPS

security_audit_config

Analyze OpenSIPS configuration snippets to identify common security misconfigurations and anti-patterns. Returns a list of findings and summary counts.

Instructions

Perform a basic security audit on an OpenSIPS configuration snippet.

Checks for common misconfigurations and security anti-patterns.

Parameters

config_content: The OpenSIPS configuration text to analyse.

Returns

dict Contains findings (list of issues) and summary counts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
config_contentYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The main handler function for the 'security_audit_config' MCP tool. Decorated with @mcp.tool() and @require_permission('config.read'). Takes a config_content string, runs regex-based security checks against _SECURITY_CHECKS patterns, and checks for missing essential security modules (pike, permissions). Returns findings with severity levels and a summary.
    @mcp.tool()
    @require_permission("config.read")
    async def security_audit_config(
        ctx: Context,
        config_content: str,
    ) -> dict[str, Any]:
        """Perform a basic security audit on an OpenSIPS configuration snippet.
    
        Checks for common misconfigurations and security anti-patterns.
    
        Parameters
        ----------
        config_content:
            The OpenSIPS configuration text to analyse.
    
        Returns
        -------
        dict
            Contains ``findings`` (list of issues) and ``summary`` counts.
        """
        findings: list[dict[str, str]] = []
        warnings = 0
        info = 0
    
        for pattern, check_id, message in _SECURITY_CHECKS:
            if re.search(pattern, config_content):
                severity = "info" if check_id in ("pike_present", "force_send_socket") else "warning"
                findings.append(
                    {
                        "check": check_id,
                        "severity": severity,
                        "message": message,
                    }
                )
                if severity == "warning":
                    warnings += 1
                else:
                    info += 1
    
        # Check for missing security modules
        essential_modules = [
            ("pike", "Anti-flood protection (pike) module is not loaded."),
            ("permissions", "IP-based permissions module is not loaded."),
        ]
        for module, msg in essential_modules:
            if f'loadmodule "{module}.so"' not in config_content and f"loadmodule \"{module}\"" not in config_content:
                findings.append(
                    {
                        "check": f"missing_{module}",
                        "severity": "warning",
                        "message": msg,
                    }
                )
                warnings += 1
    
        return {
            "findings": findings,
            "summary": {
                "total": len(findings),
                "warnings": warnings,
                "info": info,
            },
        }
  • The _SECURITY_CHECKS list defines the regex patterns, check IDs, and human-readable messages used by the security_audit_config tool to detect security issues in OpenSIPS configs. This serves as the rule definitions/schema for the audit.
    # Patterns that indicate potential security issues in OpenSIPS configs
    _SECURITY_CHECKS: list[tuple[str, str, str]] = [
        (
            r"(?i)\blisten\s*=\s*udp:\*:",
            "wildcard_listen",
            "Listening on all interfaces (0.0.0.0 / *) — consider binding to specific IPs.",
        ),
        (
            r"(?i)\blisten\s*=\s*udp:0\.0\.0\.0:",
            "wildcard_listen_v4",
            "Listening on all IPv4 interfaces — consider binding to specific IPs.",
        ),
        (
            r"(?i)modparam\s*\(\s*[\"']auth_db[\"']\s*,\s*[\"']calculate_ha1[\"']\s*,\s*1\s*\)",
            "plaintext_passwords",
            "calculate_ha1=1 means passwords are stored in plaintext — use pre-computed HA1 hashes instead.",
        ),
        (
            r"(?i)modparam\s*\(\s*[\"']tls_mgm[\"']\s*,\s*[\"']verify_cert[\"']\s*,\s*[\"']0[\"']\s*\)",
            "tls_no_verify",
            "TLS certificate verification is disabled — enable it in production.",
        ),
        (
            r"(?i)#!define\s+WITH_DEBUG",
            "debug_enabled",
            "Debug mode is enabled — disable in production to reduce log volume and improve performance.",
        ),
        (
            r"(?i)modparam\s*\(\s*[\"']permissions[\"']\s*,\s*[\"']default_allow_file[\"']",
            "permissions_allow",
            "Using file-based permissions — ensure allow/deny files are properly maintained.",
        ),
        (
            r"(?i)xlog\s*\(\s*[\"'].*\$ru.*[\"']\s*\)",
            "uri_logging",
            "Logging SIP URIs may expose PII — ensure log access is restricted.",
        ),
        (
            r"(?i)modparam\s*\(\s*[\"']httpd[\"']\s*,\s*[\"']ip[\"']\s*,\s*[\"']0\.0\.0\.0[\"']\s*\)",
            "httpd_wildcard",
            "MI HTTP interface bound to all interfaces — restrict to localhost or private network.",
        ),
        (
            r"(?i)force_send_socket",
            "force_send_socket",
            "force_send_socket is used — verify the bound socket is correct for your topology.",
        ),
        (
            r"(?i)modparam\s*\(\s*[\"']pike[\"']\s*,",
            "pike_present",
            "Pike module is loaded — good, anti-flood protection is configured.",
        ),
    ]
  • The @mcp.tool() decorator on line 142 registers the security_audit_config function as an MCP tool. The @require_permission('config.read') decorator enforces RBAC access control.
    @mcp.tool()
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It states 'Perform a basic security audit' which implies a read-only analysis, but does not explicitly confirm that no changes are made, nor does it mention any authorization requirements or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured with a clear sentence, followed by a Parameters section and Returns section. All information is relevant and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (basic security audit on a config), the description covers the main inputs and outputs, including the return structure with 'findings' and 'summary counts'. No output schema was provided in the input, but the description mentions it. However, it lacks details on what specific issues are checked.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'config_content' has a clear description: 'The OpenSIPS configuration text to analyse.' This adds meaning beyond the schema's simple type declaration, compensating for the 0% schema description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Perform a basic security audit on an OpenSIPS configuration snippet.' This provides a specific verb and resource, and distinguishes it from sibling tools like cfg_lint or security_generate_ha1.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. There is no mention of when not to use it or which other tools might be better suited for different types of security checks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/OpenSIPS/opensips-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server