IP Whitelisting and Access Control

IP Whitelisting and Access Control

IP whitelisting (also called IP allowlisting) restricts access to your systems based on the source IP address. Only requests from approved IPs are allowed; everything else is blocked. This is one of the most effective ways to prevent unauthorised access.

Where to Apply IP Whitelisting

There are three levels where IP restrictions add value:

1. IPTVbp Vendor Dashboard -- restrict who can log into your admin dashboard.
2. IPTV Panel API -- restrict which servers can call your panel's API.
3. Server-Level Firewall -- restrict SSH, database, and other service access.

Level 1: Dashboard IP Allowlist

Restrict vendor dashboard access to known IPs:

1. Go to Settings > Security > IP Allowlist.
2. Click Add IP Address.
3. Enter your IP (find it at whatismyip.com) and a label (e.g. "Office", "Home", "VPN").
4. Repeat for each location you access from.
5. Toggle Enable Allowlist.

Once enabled, any login attempt from an unlisted IP is rejected with a "403 Forbidden" response, regardless of whether the credentials are correct.

Dynamic IPs

If your ISP assigns a dynamic IP, you have several options:

• Use a VPN with a static IP and whitelist the VPN IP.
• Use a Dynamic DNS service and update the allowlist when your IP changes.
• Disable the allowlist temporarily when travelling, then re-enable it.

Level 2: Panel API Restrictions

Your IPTV panel receives API requests from IPTVbp to create and manage user lines. Restricting these requests to only the IPTVbp server IP prevents unauthorised provisioning.

Xtream UI

Xtream UI does not have a built-in IP allowlist for its API. Use a server firewall instead:

# Allow IPTVbp server IP on panel port
sudo ufw allow from 45.137.20.16 to any port 25500
sudo ufw allow from 45.137.20.139 to any port 25500

# Block all other access to the panel port
sudo ufw deny 25500

This ensures only IPTVbp servers can make API calls to your panel.

NXT Dashboard

NXT Dashboard supports IP restrictions in its API settings:

1. Log into NXT admin.
2. Go to Settings > API Access.
3. Edit your API token.
4. Under Allowed IPs, enter the IPTVbp server IPs.
5. Save.

Requests from other IPs using this token will be rejected.

Level 3: Server Firewall

Every server in your infrastructure should have a firewall configured. Here is a recommended baseline using UFW (Uncomplicated Firewall):

# Default: deny incoming, allow outgoing
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH from your IPs only
sudo ufw allow from YOUR_IP to any port 22

# Allow HTTP/HTTPS (for web traffic)
sudo ufw allow 80
sudo ufw allow 443

# Allow database access from application server only
sudo ufw allow from APP_SERVER_IP to any port 5432  # PostgreSQL
sudo ufw allow from APP_SERVER_IP to any port 6379  # Redis

# Enable the firewall
sudo ufw enable

Fail2Ban for Brute Force Protection

Fail2Ban monitors log files and bans IPs that show malicious behaviour (e.g. repeated failed login attempts):

sudo apt install fail2ban
sudo systemctl enable fail2ban

Configure for SSH:

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 22
maxretry = 3
bantime = 3600
findtime = 600

After 3 failed SSH attempts within 10 minutes, the IP is banned for 1 hour.

VPN-Based Access

For maximum security, access all admin interfaces through a VPN:

1. Set up a WireGuard or OpenVPN server.
2. Assign static IPs to each team member's VPN connection.
3. Whitelist only VPN IPs in all allowlists and firewall rules.
4. Team members connect to VPN before accessing any admin interface.

This eliminates the dynamic IP problem and adds encryption to all traffic.

Network Architecture Best Practices

Component	Access Level	Restriction
IPTVbp Vendor Dashboard	Vendor IPs only	IP allowlist + 2FA
IPTV Panel Admin UI	Vendor IPs only	Firewall rule
IPTV Panel API	IPTVbp server IPs only	Firewall rule or token IP restriction
Database (PostgreSQL)	Application server only	Firewall rule, no public access
Redis	Application server only	Firewall rule, requirepass
SSH	Admin IPs only	Firewall rule + key-based auth + Fail2Ban

Testing Your Restrictions

After configuring IP restrictions:

1. Test from an allowed IP -- confirm you can access all services.
2. Test from a different IP (e.g. mobile data) -- confirm access is blocked.
3. Test panel provisioning -- place a test order and verify IPTVbp can still communicate with the panel.
4. Document all whitelisted IPs in a secure location so you can update them if infrastructure changes.

Common Mistakes

• Locking yourself out: Always keep a backup access method (console access, out-of-band management).
• Forgetting to update after IP change: Set a reminder to check your IPs if you move offices or change ISPs.
• Whitelisting too broadly: Avoid whitelisting entire /16 or /8 ranges. Be as specific as possible.
• Not restricting database access: PostgreSQL and Redis should never be accessible from the public internet.