Network Security & Access Policy

Network Access & Security Model

Default Model

Database Mart uses a lightweight network exposure model: servers are directly accessible via public IP, basic usage requires no VPC configuration, and no manual security group setup is needed.

The network access model has three layers:

• Default public accessibility (Public IP Access)
• Platform-level port filtering (Platform-level Port Filtering)
• OS-level firewall control (OS Firewall Responsibility)

Public Access

The network model supports standard two-way public internet communication. Servers can both expose services and access external resources.

Outbound access includes:

• Downloading software updates and packages
• Using package managers (apt / yum / pip / npm)
• Accessing third-party APIs and external services
• Connecting to external databases
• Downloading files and resources from the internet
• Pulling Docker/container images

Exposed services can include:

• Websites and web applications
• APIs and backend services
• Databases and management tools
• Control panels (cPanel, Plesk, etc.)
• VPN, FTP, mail, and other network services
• Custom business applications

Platform Security Policy

Platform-Level Port Filtering

To reduce the risk of malicious scanning, proxy abuse, and exposure of high-risk services, the platform network layer blocks the following TCP ports by default:

135-139, 427, 445, 593, 1024-1030, 1080, 1363-1377, 3128, 8888, 9999, 5985, 389, 4444, 3333, 14444, 33333, 2222, 22222

Note: If your application depends on any of these ports, we recommend changing the service's listening port. Most AI workloads (FastAPI, vLLM, TGI, ComfyUI, Web APIs, etc.) are not affected by these restrictions.

OS Firewall Responsibility

In addition to platform-level policies, the OS-level firewall inside your server may also affect access. Users are responsible for managing:

• Linux firewall (iptables / ufw)
• Windows Firewall
• Application-level authentication and access control
• API Token / Authentication configuration

Common reasons for inaccessibility:

• Server not in Running state
• Service not started
• Service bound to 127.0.0.1 instead of 0.0.0.0
• OS firewall blocking access
• Service using a restricted port

Security Responsibility & Best Practices

Security Responsibility

Database Mart is responsible for:

• Infrastructure-level network isolation
• Routing security
• Platform-level security policies (including infrastructure isolation, network routing, and server-level resource isolation)

Security configuration inside the server is the user's responsibility, including:

• Internal security settings
• Service authentication and access control
• API security and permission management

Best Practices

To ensure your services are reliably accessible and secure:

Service Configuration:

• Use fixed ports (e.g., 8000 / 8080)
• Avoid restricted or system-reserved ports
• Services must bind to 0.0.0.0, not 127.0.0.1 (localhost)

Authentication & Monitoring:

• Add authentication mechanisms in production (API Key / Token / Authentication)
• Monitor server status and resource usage regularly

Security Hardening:

• Change the default SSH/RDP port
• Disable root login
• Use SSH keys instead of passwords (Linux)
• Enable a firewall (iptables / ufw)
• Install Fail2Ban
• Disable unnecessary services
• Back up data regularly