Configuration

Review firewall, SSH and management-access changes

Preserve a working access route, use exact previews and verify reconnection independently.

Platform
Go
Technology
Go

Prepare recovery and permissions

Use a current administrator session with security:manage, fresh verification and the installed registered security capability. Retain the provider console and original authenticated operator connection. Firewall/SSH changes require a protected current management route, automatic rollback and independent reconnect verification; a successful browser click is not enough.

Firewall fields

Review allowed inbound TCP/UDP ports, allowed source CIDRs, manually blocked source CIDRs and new SSH connections per minute. The typed policy validates actual port/CIDR bounds; source allowlisting never bypasses an independently restricted port or WAF policy. Do not use an arbitrary shell command or disable AppArmor to obtain access.

The source accepts at most 64 unique allowed ports per transport and 32 unique networks in its structured policy. Use the actual assigned networks and a deliberate IPv4/IPv6 plan. No country blocking is claimed: it requires licensed/current geography data and tested rule compilation, which are not implemented here.

SSH fields

Review the desired SSH port and supported root SSH policy through the protected form. Customer application SSH access is a separate account-scoped capability; this Admin control does not issue customer root access. SSH-key management for a general administrator key inventory is not implemented, though scoped transfer-user keys have their own file-transfer flow.

Apply the exact plan

Request /v1/security/preview, read before/after impact, rollback conditions and exact confirmation, then explicitly submit /v1/security/operations with api_version: 1, the fresh preview_id and confirmation. The operation must retain its reviewed idempotency key. If the preview expires or state changes, inspect a new plan; never replay a stale confirmation automatically.

Verify and recover

From a second authorized connection, prove the intended new route, expected denied route, retained TLS and IPv4/IPv6 behavior before accepting the change. Inspect security status and durable operation events. If reconnect fails, use the documented automatic rollback/console recovery and preserve evidence. Do not remove access fences, broad-allow all ports or edit private journals to force success. Customer IP Blocker, country feeds, generic root terminal and one-click global security advisor are not implemented in this checkpoint.

← All EmailaPanel guidesGet help →

Need help with EmailaPanel?

Tell us the product version and what you are trying to do. Keep passwords and private keys out of your message.

Contact Emaila