Security Guide
Your public IP is probed within 4 minutes of going live
Understand the real-world risks of exposing a Teltonika router on a public IP SIM – and learn exactly how to harden it.
What happens when a Teltonika gets a public IP?
Within minutes of your SIM acquiring a public IP address, automated scanners will discover and probe your device. Here is what that looks like in practice.
Shodan, Censys, and a host of criminal botnets continuously scan the entire IPv4 address space – all 4.3 billion addresses – looking for open management ports. A typical Teltonika on factory defaults exposes:
PORT 80 – WebUI (HTTP)
The full router admin panel. Each probe request loads the login page (~8-15KB). Bots attempt thousands of credential pairs per day. No rate limiting on default config.
PORT 22 – SSH
Enabled by default on many firmware versions. SSH brute-force attacks are relentless – scripts try thousands of username/password combinations automatically.
PORT 443 – WebUI (HTTPS)
Encrypted but still probed. The TLS handshake itself consumes data (~5KB per probe) even when rejected. Self-signed cert triggers browser warnings but not bots.
PORT 161 – SNMP
If enabled, SNMP with default community string “public” leaks full device info including firmware version, model, uptime, and connected interfaces.
Security Best Practices – Priority Order
Each issue is rated by severity and includes the exact fix for Teltonika RutOS devices.
01
Critical
Disable WAN Access to WebUI
The single biggest risk. If your router’s admin panel is reachable from the internet, every bot on the planet will attempt to log in. Even strong passwords can be bypassed through firmware vulnerabilities.
Fix – RutOS Firewall Rule
Network > Firewall > Traffic Rules
Add rule: Drop all incoming WAN traffic on port 80 and 443
Name: Block_WebUI_WAN
Direction: Input
Protocol: TCP
Destination Port: 80, 443
Action: DROPAlternative – Use RMS for Remote Management
Teltonika RMS (Remote Management System) tunnels management traffic through an outbound TLS connection – meaning NO inbound ports need to be open at all. This is the recommended approach for all production deployments.
02
Critical
Change Default Credentials Immediately
Default credentials for Teltonika routers are widely published. Older firmware uses admin/admin01. Newer firmware generates a password from the device serial number – which is often printed on the label visible in photos of installations.
Fix
System > Administration > Change Password. Use a minimum 16-character password with mixed case, numbers, and symbols. Document it securely in a password manager – never in a shared spreadsheet or email.
03
Critical
Disable or Restrict SSH Access
SSH on port 22 is the number one target for automated brute-force attacks globally. If you need SSH access, restrict it to specific source IPs only, or switch to key-based authentication and disable password login entirely.
Fix Option A – Disable SSH on WAN
Services > SSH
Set "Enable" to OFF, or
Set "Interface" to LAN only (not WAN)Fix Option B – SSH Key Authentication
Services > SSH > Authentication Keys
Paste your public key
Then: PasswordAuthentication no
04
High
Disable Unused Services (SNMP, Telnet, FTP)
Every enabled service is an attack surface. Telnet sends credentials in plaintext. SNMP v1/v2c with default community strings reveals full device configuration. Disable anything you are not actively using.
Fix
Services > SNMP – set to Disabled unless required. If SNMP is needed, use SNMPv3 with authentication and encryption, never v1/v2c with community string “public”. Services > Telnet – disable completely; SSH is always preferable.
05
High
Keep Firmware Up to Date
Teltonika releases regular firmware updates that patch discovered vulnerabilities. Running outdated firmware on a public IP is particularly dangerous as exploits are sometimes published before patches are widely applied.
Fix
System > Firmware > Check for Updates. Enable automatic update notifications via RMS. Teltonika’s firmware changelog is published at wiki.teltonika-networks.com – review before updating production devices.
06
High
Enable HTTPS Only – Disable HTTP
HTTP login pages transmit credentials in plaintext. Any man-in-the-middle on the mobile network can capture them. Force HTTPS and consider changing the default port to reduce automated probe volume.
Fix
System > Administration > Access Control
HTTP: Disabled
HTTPS: Enabled
Consider changing HTTPS port from 443 to a non-standard port
07
Good Practice
Configure IP Allowlisting for Management
If you must allow WAN management access, restrict it to specific IP addresses only. This eliminates virtually all automated attack traffic since bots operate from random IPs.
Fix
Network > Firewall > Traffic Rules
Create rule allowing port 443 from [YOUR-OFFICE-IP] only
Drop all other port 443 traffic from WAN
08
Good Practice
Enable Login Attempt Limiting
Newer RutOS firmware includes built-in brute-force protection that temporarily blocks IPs after a set number of failed login attempts. Ensure this is active if WAN access is permitted.
Fix
System > Administration > Safety – enable “Attempts” limiting. Set to 3-5 failed attempts before a temporary block. This significantly reduces the effectiveness of credential stuffing attacks.
Data Usage Impact Calculator
Estimate how much of your SIM data allowance is being consumed by automated probing – before a single legitimate byte is sent.
Bot Traffic Data Estimator
Based on real-world honeypot and packet capture data from exposed IoT cellular connections
WebUI probe requests per day
–
SSH brute-force attempts per day
–
SNMP probe requests per day
–
Estimated daily data waste
–
Estimated monthly data waste
–
Status
–
Live Exposure Test Tool
Enter a public IP address to run a simulated security assessment. This tool checks common Teltonika management ports and evaluates exposure based on service fingerprinting and known default configurations.
Teltonika Public IP Security Scanner
Only use this tool on IP addresses you own or have permission to test. Results include AI-powered remediation advice.
Ports to Check
Initialising scan…
0%
0
Critical
0
High
0
Info
0
Secure
AI Security Analysis
Interactive Security Audit Checklist
Work through each item for your Teltonika deployment. Your score updates in real time as you confirm each control is in place.
Security Score
0
/ 100
Critical Risk
Tick each control as you confirm it is in place on your device.
Items Completed
0 / 0
Data Usage: Default vs Hardened Configuration
Monthly data consumption comparison between a factory default Teltonika on a public IP and a properly secured deployment. Figures based on real-world packet capture data from IoT cellular connections.
Default Configuration
Total Monthly Attacker Traffic
~456 MB
of a 500MB SIM plan consumed by bots
Hardened Configuration
Total Monthly Attacker Traffic
<2 MB
background noise only – SYN packets
Source: Based on 30-day honeypot data from Teltonika RUT241 units on public IP SIMs across UK mobile networks. HTTP probe figures vary significantly by carrier and whether the IP has previously been indexed on Shodan or Censys.
Real-World Attack Scenarios
Understanding how attackers actually exploit exposed Teltonika devices helps you prioritise the right defences.
Hardened RutOS Configuration Reference
Copy these settings directly into your Teltonika. Navigate to each path in the RutOS WebUI.
01
▼
Firewall – WAN Input Rules
Network > Firewall > Traffic Rules
/* Drop all inbound management from WAN */ Rule 1: Block WebUI on WAN Name: Drop_WebUI_WAN Protocol: TCP Source: WAN (any) Destination: Device Dest Ports: 80, 443 Action: DROP Rule 2: Block SSH on WAN Name: Drop_SSH_WAN Protocol: TCP Source: WAN (any) Destination: Device Dest Ports: 22 Action: DROP Rule 3: Block SNMP on WAN Name: Drop_SNMP_WAN Protocol: UDP Source: WAN (any) Destination: Device Dest Ports: 161 Action: DROP /* Default WAN input policy */ Default input policy: DROP (Network > Firewall > General Settings)
02
▼
SSH Hardening
Services > SSH
/* SSH service configuration */ Enable: ON (LAN only) or OFF if using RMS Port: 22 -> change to 52222 or similar Interface: LAN (NOT WAN) Password Authentication: Disabled Root Login: Prohibited password (key only) /* Add your public key */ Services > SSH > Authentication Keys Paste contents of ~/.ssh/id_rsa.pub /* Generate key on your PC (PowerShell / bash) */ ssh-keygen -t ed25519 -C "teltonika-mgmt" # Paste the .pub content into the router UI
03
▼
Login Security
System > Administration
/* Admin access */
Username: admin (consider changing)
Password: Minimum 16 chars, mixed case + numbers + symbols
Example pattern: 4-word passphrase + numbers
/* Access restrictions */
HTTP: Disabled
HTTPS: Enabled
HTTPS Port: 8443 (non-standard reduces probe volume)
/* Safety */
System > Administration > Safety
Enable: ON
Attempts: 3
Timeout: 600 seconds
/* Session timeout */
Idle timeout: 300 seconds (5 minutes)
04
▼
RMS Configuration (Recommended Remote Access Method)
Services > Cloud Solutions > RMS
/* RMS uses outbound TLS - no inbound ports required */ Enable: ON Connect: rms.teltonika-networks.com:15009 /* RMS provides */ - WebUI access through encrypted tunnel - SSH access through encrypted tunnel - Remote CLI - Device monitoring and alerts - Firmware updates - No public IP required for management /* After enabling RMS, add firewall rules */ Drop all WAN input except: - Established/related connections (default) - VPN tunnel traffic if in use All management via RMS only
05
▼
VPN – Replace Port Forwards with Tunnels
Services > VPN > OpenVPN / WireGuard
/* WireGuard (recommended - simpler, faster) */ Services > VPN > WireGuard > Add Listen Port: 51820 Private Key: [auto-generated] Add Peer (your laptop/office router): Public Key: [from peer wg pubkey] Allowed IPs: 10.0.0.2/32 Endpoint: [peer public IP]:51820 Firewall: Allow UDP 51820 from WAN for VPN only All LAN device access via VPN tunnel Remove all port forward rules /* OpenVPN (more compatible with corporate firewalls) */ Services > VPN > OpenVPN Role: Server Protocol: UDP Port: 1194 Cipher: AES-256-GCM Auth: SHA256 TLS Auth: Enable (prevents DoS on VPN port)
Common Applications – Port Forwards and Endpoint Hardening
These are the most common deployments where a Teltonika router is used to provide remote access to equipment on a cellular connection. For each application, the table shows the ports typically forwarded and – critically – what hardening must be done on the endpoint device itself. The router is only one layer of the security stack.
â ī¸
Important – The Router is Not the Last Line of Defence
A port forward rule passes traffic directly to the device behind the router. If that device has weak or no authentication, default credentials, or unpatched firmware, the Teltonika’s security is irrelevant – the endpoint is the vulnerability. Always harden the destination device before opening a port forward to the internet.
CCTV / IP Camera Systems
NVRs, DVRs, IP cameras – Hikvision, Dahua, Axis, Uniview
8080
554
37777
80
▼Typical Port Forwards
80 / 8080Web interface / mobile app accessHigh risk
554RTSP live video streamHigh risk
37777Dahua proprietary protocolMedium
443HTTPS web interfaceMedium
CCTV systems are among the most exploited internet-connected devices. Hikvision and Dahua have both had critical unauthenticated remote code execution CVEs in the last 3 years. Many systems are still deployed with default credentials.
Endpoint Hardening Required
Change admin password on the NVR/DVR – never leave admin/12345 or admin/blank
Update NVR/DVR/camera firmware – Hikvision and Dahua issue frequent security patches
Disable RTSP anonymous access – require authentication for stream access
Disable UPnP on the NVR – it can automatically punch holes through your router firewall
Use P2P cloud access (Hik-Connect / DMSS) instead of port forwards where possible
If port forwards are needed, use VPN tunnel instead – access RTSP/web over the tunnel only
Blame allocation: If a CCTV system is compromised through a port forward and footage is accessed or the camera joins a botnet, the liability sits with the installer and device owner – not the SIM provider or router. Documenting that endpoint hardening was completed and recommended protects you professionally.
BMS / Building Management Systems
HVAC, lighting, access control, energy monitoring
502
47808
4911
▼Typical Port Forwards
502Modbus TCP – meters, PLCs, sensorsCritical
47808BACnet/IP – HVAC, building systemsCritical
4911IEC 61850 MMS – electrical systemsCritical
102Siemens S7 – PLC communicationsCritical
2404IEC 60870-5-104 – SCADA/energyCritical
Modbus and BACnet have zero authentication by design. They were created for isolated plant networks. Exposing them to the internet means any attacker can read live data and in many cases write control values.
Endpoint Hardening Required
Never directly expose Modbus or BACnet to the internet under any circumstances
Use VPN exclusively – WireGuard or OpenVPN on the Teltonika, access via tunnel only
If the monitoring platform requires a public IP, use firewall allowlist – only permit the monitoring station’s IP on those ports
Enable Teltonika’s built-in Modbus gateway authentication where firmware supports it
Segment BMS network – devices should only be able to reach the Teltonika, not each other
Log all Modbus register read/write operations where the gateway supports it
Blame allocation: Exposing Modbus to the internet violates IEC 62443 and most building services contracts. If a building’s HVAC is manipulated or energy data is exfiltrated via an open port 502, the contractor who configured the port forward bears significant professional and potentially legal liability.
Energy Meters / Smart Metering / SCADA
Electricity, gas, water metering and grid-edge equipment
2404
502
4059
▼Typical Port Forwards
2404IEC 60870-5-104 – most common UK AMRCritical
502Modbus TCP – legacy meter commsCritical
4059IEC 61968 meter dataHigh
8899Various meter proprietary APIsHigh
IEC 60870-5-104 is heavily used for AMR (Automatic Meter Reading) in the UK energy sector. It is an unauthenticated protocol – the assumption is always that it sits inside a private APN or VPN. Direct internet exposure is a significant risk to meter data integrity.
Endpoint Hardening Required
IEC 104 must only be accessible from the head-end server IP – apply strict source IP allowlist on Teltonika firewall
Use private APN where available – keeps meter traffic entirely off the public internet
Configure Teltonika firewall to only allow connection from known polling server IP on port 2404
Enable connection tracking – only allow established sessions, block unsolicited inbound connections
For DNO / regulated metering deployments follow Ofgem SMETS2 security guidelines
Relevant to Millbeck / IoT deployments: For energy sector work on public IP SIMs where a private APN is not available, the minimum acceptable configuration is firewall allowlisting of the head-end server IP. Document this in your deployment checklist and obtain sign-off from the customer.
Access Control / Door Entry Systems
HID, Paxton, Gallagher, Suprema, ZKTeco
4050
8080
443
▼Typical Port Forwards
4050Paxton Net2 server commsHigh
8080/443Web-based management portalsHigh
3001ZKTeco device managementHigh
7788HID VertX / Edge controllersCritical
Access control systems are high-value targets. Compromising the controller can unlock doors, disable alarms, or exfiltrate cardholder data including names, card UIDs, and access histories – potential GDPR breach.
Endpoint Hardening Required
Change default controller credentials – many ship with admin/admin or blank passwords
Update controller firmware – HID VertX controllers had critical RCE vulnerabilities widely publicised
Use VPN rather than port forward – access controller management over WireGuard tunnel
Enable HTTPS on web management interface – never use HTTP for access control systems
Restrict management access to installer / monitoring company IP ranges only
Blame allocation: Physical security breaches resulting from a compromised access control system create serious liability. If a door is unlocked remotely because the controller had default credentials behind an open port forward, the installer and system integrator carry significant responsibility.
POS / Payment Terminals / ATMs
Retail cellular failover and primary connectivity
443
3389
▼Typical Port Forwards
443Payment processor HTTPS connectionLower risk
3389RDP for POS system managementCritical
5900VNC remote desktopCritical
POS on cellular is usually outbound-only for payment processing (secure by design). The risk comes from RDP or VNC port forwards added by IT teams for “convenience” to manage the POS terminal remotely. RDP on port 3389 is the single most attacked port on the internet after port 22.
Endpoint Hardening Required
Remove RDP port forward entirely – use VPN or RMS for management
PCI DSS requires isolated payment network – payment terminals must not be on a network with internet-facing management ports
Enable Network Level Authentication (NLA) on any Windows RDP if it absolutely must be used
Payment processor connections are outbound HTTPS – no inbound ports needed for the payment function itself
PCI DSS note: Exposing RDP on a network that handles payment card data is a PCI DSS violation. Acquirers and card schemes can levy fines and remove card acceptance ability. The router configuration is part of the PCI scope.
The Right Solution
VPN-Based Access Control – Who Gets In and When
Replacing port forwards with a VPN tunnel gives you granular control over exactly who can access devices on your cellular network. Instead of every attacker on the internet seeing your open ports, only authenticated VPN users can reach anything.
đ¤
The Monitoring Station Problem – Why You Still Need a Public IP
Here is the tension that catches many deployments out. You want to lock down the router so no inbound traffic can reach it – but your monitoring platform (SCADA head-end, AMR system, CCTV control room, BMS server) needs to poll the device or receive data pushes from it on a regular basis. It cannot do that if the router drops everything inbound.
This is exactly why a public IP SIM is specified in the first place. The monitoring station needs a known, reachable address to connect to. The challenge is allowing that specific connection while blocking everything else.
đ¯
Option 1 – Source IP Allowlisting
The monitoring server has a fixed IP. Create a firewall rule that only allows inbound traffic on the protocol port from that specific IP. Drop everything else. Simple and highly effective when the monitoring platform has a stable static IP.
Best for:
AMR head-ends, SCADA polling servers, fixed monitoring platforms
â Minimal config, highly reliable, works with all protocols
đ
Option 2 – VPN with User Certificates
Run OpenVPN or WireGuard on the Teltonika. Each engineer, technician, or monitoring platform gets a unique certificate or key pair. Only those holding valid credentials can establish a tunnel and reach LAN devices. The monitoring server becomes a VPN peer rather than connecting directly.
Best for:
Multi-user access, field engineer access, CCTV, BMS, access control
â Per-user revocation, full audit trail, no open ports
âī¸
Option 3 – Central VPN Hub (Recommended for Fleets)
Run a VPN server on a cloud instance (AWS, Azure, or a dedicated VPS). All Teltonika devices connect outbound to this hub – no public IP SIM required on the router. All monitoring traffic routes through the hub. Engineers connect to the hub to reach any device on the fleet.
Best for:
Large deployments, mixed SIM types, fleet management
â Standard SIMs work, central management, scales to thousands of sites
When You Genuinely Need a Port Open to the World
Some legacy monitoring platforms cannot act as VPN peers and cannot connect via a hub. The polling software at the head-end simply dials the site IP on a specific port. In these cases, VPN is not an option and a port must remain open. The minimum mitigations are:
Firewall Source Allowlist
Allow the specific protocol port only from the monitoring server’s static IP. Block all other source IPs on that port. This eliminates 99.9% of automated scanning.Private APN
Ask your SIM provider for a private APN. Traffic routes through an MPLS or IPSec tunnel to the monitoring platform – never touching the public internet. Often cheaper than the security engineering required to safely expose a public port.Protocol Proxy / Application Gateway
Put a Teltonika with Modbus or IEC 104 gateway functionality in front of the device. The gateway validates and proxies requests – adding a layer between the raw protocol and the internet.Connection Tracking Only
Configure firewall to only allow established/related connections from the monitoring server – the session must be initiated from the allowed IP, unsolicited inbound packets from other sources are dropped.Related Guides and Tools
Security is only one part of a robust Teltonika deployment. These guides cover the operational topics that sit alongside security in a well-managed cellular IoT installation.
Auto Reboot with Ping Watchdog
Configure Teltonika’s built-in ping reboot to automatically recover from connection drops – essential for unattended deployments. Covers ping targets, intervals, and reboot thresholds.
Read guide →
Signal Strength Optimisation
Getting the best signal from your cellular connection – antenna selection, placement, cable runs, and using Teltonika’s network scan tools to pick the best band and carrier.
Read guide →
RMS Remote Management Setup
Step-by-step guide to configuring Teltonika RMS for fleet management – device registration, user permissions, alert configuration, and remote access without opening inbound ports.
Read guide →
OpenVPN Configuration Guide
Full walkthrough for setting up OpenVPN on Teltonika routers – server and client modes, certificate generation, split tunnelling, and connecting to a central VPN hub server.
Read guide →
WireGuard VPN Setup
WireGuard is faster and simpler than OpenVPN. This guide covers peer configuration, key management, road warrior setup for mobile engineers, and site-to-site tunnels.
Read guide →
Antenna and Cable Selection
Choosing the right external antenna and cable assembly for cellular IoT – connector types, cable loss, antenna gain, IP ratings, and why cable quality matters more than antenna spec.
Read guide →
WAN Failover Configuration
Configure Teltonika’s multi-WAN failover for resilient connectivity – primary broadband with cellular backup, failover triggers, failback behaviour, and load balancing options.
Read guide →
Modbus Gateway Configuration
Using Teltonika’s Modbus TCP/RTU gateway to connect serial field devices to IP networks – register mapping, polling configuration, and how to keep Modbus traffic off the public internet.
Read guide →
Multi-Network SIM Guide
Understanding multi-network and eUICC SIMs for IoT deployments – how they work, when to use them, carrier steering, and how to avoid the pitfalls of cheap reseller SIMs.
Read guide →
Need a Hardened Teltonika Configuration?
Download our complete RutOS security configuration template – covering firewall rules, SSH hardening, and RMS setup for production deployments.