Jump to content
  • EN

Template:Security guidelines: Difference between revisions

From Teltonika Networks Wiki
← Older edit
VisualWikitext
No edit summary
No edit summary
 
(55 intermediate revisions by 5 users not shown)
Line 1: Line 1:
==Summary==


<table class="wikitable">
This article provides details about security features and recommendations used in Teltonika Networks products and how to properly implement them ensuring cyber-security best practices.
    <tr>
 
        <th width="200">Security measurement type</th>
==Security Guidelines==
      <th width="200">Security measurement name</th>
 
      <th width="200">By default</th>
Listed below are general security recommendations and hardening techniques. These should be applied not only to Teltonika Networks products, but to all internet-facing devices to ensure the best possible security posture and resilience to cyber-attacks.
<th width="500">Details</th>
 
    </tr>
== Guideline Categories ==
    <tr>
 
      <td rowspan="5">DDOS Prevention</td>
# General Security Best Practices
      <td>SYN Flood Protection</td>
# Device Hardening Recommendations
      <td>On</td>
# Secure Operation & Maintenance
<td>A SYN flood is a form of denial-of-service attack in which an attacker sends a succession of SYN requests to a target's system in an attempt to consume enough server resources to make the system unresponsive to legitimate traffic.</td>
 
    </tr>
----
    <tr>
=== General Security Guidelines ===
      <td>Remote ICMP Requests</td>
 
      <td>On</td>
{| class="wikitable"
      <td>An Internet Control Message Protocol (ICMP) flood attack, also known as a Ping flood attack, is a common denial-of-service attack in which an attacker attempts to overwhelm a targeted device with ICMP echo-requests (pings).</td>
|+
    </tr>
|-
    <tr>
! Recommendation !! Priority !! Details
      <td>SSH Attack Prevention</td>
|-
      <td>Off</td>
| Keep Firmware Updated || Critical || Always run the latest stable firmware. Firmware updates contain critical vulnerability patches.
      <td>A Secure Shell (SSH) flood attack, is a common denial-of-service attack in which an attacker attempts to overwhelm a targeted device with SSH requests.</td>
|-
    </tr>
| Use Complex Passwords || Critical || Use complex passwords. At the least password should contain minimum 12 characters and include numbers, symbols, capital and lowercase letters. Avoid using common words.
    <tr>
|-
      <td>HTTP Attack Prevention</td>
| Enforce HTTPS and SSH || Critical || Only use secure protocols ('''''HTTPS, SSH'''''). Avoid the usage of HTTP, Telnet and other insecure protocols where available.
      <td>Off</td>
|-
      <td>A Hypertext Transfer Protocol (HTTP) flood attack is a common denial-of-service attack in which an attacker attempts to overwhelm a targeted device with HTTP requests.</td>
| Install Only Trusted Packages || Critical || Only install packages from verified and trusted sources. To ensure the integrity Teltonika Networks digitally signs all its firmware and packages.
    </tr>
|-
    <tr>
| Disable Unused Services || Critical || Turn off unused interfaces like Web CLI, WiFi, SMS utilities, etc., to reduce the attack surface.
      <td>HTTPS Attack Prevention</td>
|-
      <td>Off</td>
| Use WPA3 WiFi || High || WPA2 is still considered secure. However '''WPA3''' introduces features that provide better support IoT device security.
      <td>HyperText Transfer Protocol Secure (HTTPS) flood attack is same as HTTP flood attack but using HTTPS protocol instead of simple HTTP</td>
|-
    </tr>
| Assign Minimum Necessary Permissions || High || Make sure to provide the least amount of required permissions for any additionally created user account.
    <tr>
|-
      <td rowspan="6">Port Scan Prevention</td>
| Use Key-Based SSH Authentication || High || If possible, use public/private key pair SSH authentication instead of password-based SSH logins.
      <td>Port Scan</td>
|-
      <td>Off</td>
| Regularly Review SIM Usage || Medium || Monitor and limit SIM card SMS/data use. Disable SMS management if not in use.
<td>A port scan is a process that sends client requests to a range of server port addresses on a host, with the goal of finding an active port.</td>
|}
    </tr>
 
    <tr>
----
      <td>SYN-FIN attack</td>
 
      <td>Off</td>
=== Security Hardening Recommendations ===
<td>An attacker may send TCP/IP packets with the SYN and FIN TCP/IP flags set to a target system, ranging across all ports, to find open TCP/IP ports for further attacks. The target system will drop packets which are destined to open ports and send back RST/ACK packets for closed ports. The attacker may gather information from the system responses.</td>
 
    </tr>
{| class="wikitable"
    <tr>
|+
      <td>SYN-RST attack</td>
|-
      <td>Off</td>
! Recommendation !! Priority !! Details
<td>SYN-RST attack, also known as TCP reset attack, is an abrupt closure of the session which causes the resources allocated to the connection to be immediately released and all other information about the connection is erased. TCP reset is identified by the RESET flag in the TCP header.</td>
|-
    </tr>
| Limit Administrative Access || Critical || Do not expose WebUI or SSH to the public internet. Use a VPN or allowlist IPs if remote access is needed.
    <tr>
|-
      <td>X-Mas attack</td>
| Use a VPN for Remote Access || Critical || Use IPsec, OpenVPN, WireGuard or other reliable VPN service for remote access. Never expose management interfaces directly.
      <td>Off</td>
|-
<td>Christmas Tree (X-Mas) Attack is designed to send a very specifically crafted TCP packet to a device on the network. This crafting of the packet is one that turns on a bunch of flags. There is some space set up in the TCP header, called flags. And these flags all are turned on or turned off, depending on what the packet is doing.</td>
| Apply IP Whitelisting || Critical || Restrict access to remote services based on specific IP addresses using a firewall.
    </tr>
|-
    <tr>
| Do Not Rely on Obscure Ports Alone || High || Avoid using non-standard ports as a primary defense. Use in conjunction with firewall rules.
      <td>FIN scan</td>
|-
      <td>Off</td>
| Disable WiFi if Not Needed || High || Disable WiFi instead or reduce transmission power.
<td>FIN packets can bypass firewalls without modification. Closed ports reply to a FIN packet with the appropriate RST packet, whereas open ports ignore the packet on hand. This is typical behavior due to the nature of TCP.</td>
|-
    </tr>
| Use Secure Firmware Validation || High || Teltonika Networks firmware is digitally signed and authorized for security. Additionally only apply firmware with verified '''SHA-256''' hashes. Avoid '''MD5/SHA-1'''.
    <tr>
|-
      <td>NULLflags attack</td>
| Disable SMS/Call Utilities by Default || Medium || Disable SMS command features unless explicitly required. Use phone number whitelists and log all commands. Authentication is available via administrative password, custom password or device serial number.
      <td>Off</td>
|}
<td>A Null Scan is a series of TCP packets that contain a sequence number of 0 and no set flags. In a production environment, there will never be a TCP packet that doesn’t contain a flag. Because the Null Scan does not contain any set flags, it can sometimes penetrate firewalls and routers that filter incoming packets with particular flags.</td>
 
    </tr>
----
    <tr>
 
      <td rowspan="8">Access Control</td>
=== Secure Operation & Maintenance ===
      <td>Remote SSH access</td>
 
      <td>Off</td>
{| class="wikitable"
<td>All Remote access is disabled by default. If user is using remote access feature it may be a security threat. If user decides to use this feature - it is recommended to use a strong password.</td>
|+
    </tr>
|-
    <tr>
! Recommendation !! Priority !! Details
      <td>Remote HTTP access</td>
|-
      <td>Off</td>
| Continuous Access Monitoring || Critical || Regularly monitor login attempts and access logs. Enable Event Juggler alerts for critical changes.
<td>All Remote access is disabled by default. If user is using remote access feature it may be a security threat. If user decides to use this feature - it is recommended to use a strong password.</td>
|-
    </tr>
| Review and Audit Firewall Rules || Critical || Keep firewall rules up to date. Remove unused or overly permissive rules.
    <tr>
|-
      <td>Remote HTTPS access</td>
| Rotate Passwords & SSH Keys Periodically || High || Rotate credentials and SSH keys at regular intervals. Immediately revoke compromised credentials.
      <td>Off</td>
|-
<td>All Remote access is disabled by default. If user is using remote access feature it may be a security threat. If user decides to use this feature - it is recommended to use a strong password.</td>
| Audit Protocols and Services || High || Ensure only secure protocols are used. Disable legacy or insecure options ('''''e.g., FTP, Telnet''''').
    </tr>
|-
    <tr>
| Conduct Periodic WiFi Audits || Medium || Reassess SSID use, encryption standards, and user access.
      <td>Remote CLI access</td>
|-
      <td>Off</td>
| Verify Backups Securely || Medium || Encrypt backups. Use '''SHA-256/SHA-512''' hashes to validate backups before restoring them. Store securely.
<td>All Remote access is disabled by default. If user is using remote access feature it may be a security threat. If user decides to use this feature - it is recommended to use a strong password.</td>
|}
    </tr>
 
    <tr>
----
      <td>Local SSH access</td>
      <td>On</td>
<td>Enabled by default for user convenience, allows possibility of configuring the device when user is in the same LAN.</td>
    </tr>
    <tr>
      <td>Local HTTP access</td>
      <td>On</td>
<td>Enabled by default for user convenience, allows possibility of configuring the device when user is in the same LAN.</td>
    </tr>
    <tr>
      <td>Local HTTPS access</td>
      <td>Off</td>
<td>By default turned off - where is no scenario where HTTPS usage would be needed "out side the box".</td>
    </tr>
    <tr>
      <td>Local CLI access</td>
      <td>On</td>
<td>Enabled by default for user convenience, allows possibility of configuring the device when user is in the same LAN.</td>
    </tr>
    <tr>
      <td rowspan="2">Block Unwanted Access</td>
      <td>SSH Access Secure</td>
      <td>On</td>
<td>By default, device allows a maximum of 5 login attempts (user defined). If all attempts are used, device will block SSH acccess from that source.</td>
    </tr>
    <tr>
      <td>WebUI Access Secure</td>
      <td>On</td>
<td>By default, device allows a maximum of 5 login attempts (user defined). If all attempts are used, device will block WebUI acccess from that source.</td>
    </tr>
    <tr>
      <td>Configuration via SMS</td>
      <td>SMS Utilities</td>
      <td> By router admin password</td>
<td>Default authorization method for configuration via SMS command is by router admin password. It's very important to have a strong password for admin account.</td>
    </tr>
    <tr>
      <td>Default admin password</td>
      <td>First login</td>
      <td>On</td>
<td>Default password for Teltonika's devices is admin01 (weak password) but on first login to WebUI - RutOS forcefully requires user to change it. Recommendation is to use strong password or passphrase*</td>
    </tr>
    <tr>
      <td></td>
      <td></td>
<td></td>
    </tr>
    <tr>
      <td></td>
      <td></td>
<td></td>
    </tr>
    <tr>
      <td></td>
      <td></td>
<td></td>
    </tr>
    <tr>
      <td></td>
      <td></td>
<td></td>
    </tr>
    <tr>
      <td rowspan="5"> DDOS Prevention</td>
      <td></td>
      <td></td>
<td></td>
    </tr>
    <tr>
      <td></td>
      <td></td>
<td></td>
    </tr>
    <tr>
      <td></td>
      <td></td>
<td></td>
    </tr>
    <tr>
      <td></td>
      <td></td>
<td></td>
    </tr>
    <tr>
      <td></td>
      <td></td>
<td></td>
    </tr>
    <tr>
      <td rowspan="5"> DDOS Prevention</td>
      <td></td>
      <td></td>
<td></td>
    </tr>
    <tr>
      <td></td>
      <td></td>
<td></td>
    </tr>
    <tr>
      <td></td>
      <td></td>
<td></td>
    </tr>
    <tr>
      <td></td>
      <td></td>
<td></td>
    </tr>
    <tr>
      <td></td>
      <td></td>
<td></td>
    </tr>
    <tr>
      <td rowspan="5"> DDOS Prevention</td>
      <td></td>
      <td></td>
<td></td>
    </tr>
    <tr>
      <td></td>
      <td></td>
<td></td>
    </tr>
    <tr>
      <td></td>
      <td></td>
<td></td>
    </tr>
    <tr>
      <td></td>
      <td></td>
<td></td>
    </tr>
    <tr>
      <td></td>
      <td></td>
<td></td>
    </tr>
</table>

Latest revision as of 13:13, 18 August 2025

Summary

This article provides details about security features and recommendations used in Teltonika Networks products and how to properly implement them ensuring cyber-security best practices.

Security Guidelines

Listed below are general security recommendations and hardening techniques. These should be applied not only to Teltonika Networks products, but to all internet-facing devices to ensure the best possible security posture and resilience to cyber-attacks.

Guideline Categories

  1. General Security Best Practices
  2. Device Hardening Recommendations
  3. Secure Operation & Maintenance

General Security Guidelines

Recommendation Priority Details
Keep Firmware Updated Critical Always run the latest stable firmware. Firmware updates contain critical vulnerability patches.
Use Complex Passwords Critical Use complex passwords. At the least password should contain minimum 12 characters and include numbers, symbols, capital and lowercase letters. Avoid using common words.
Enforce HTTPS and SSH Critical Only use secure protocols (HTTPS, SSH). Avoid the usage of HTTP, Telnet and other insecure protocols where available.
Install Only Trusted Packages Critical Only install packages from verified and trusted sources. To ensure the integrity Teltonika Networks digitally signs all its firmware and packages.
Disable Unused Services Critical Turn off unused interfaces like Web CLI, WiFi, SMS utilities, etc., to reduce the attack surface.
Use WPA3 WiFi High WPA2 is still considered secure. However WPA3 introduces features that provide better support IoT device security.
Assign Minimum Necessary Permissions High Make sure to provide the least amount of required permissions for any additionally created user account.
Use Key-Based SSH Authentication High If possible, use public/private key pair SSH authentication instead of password-based SSH logins.
Regularly Review SIM Usage Medium Monitor and limit SIM card SMS/data use. Disable SMS management if not in use.

Security Hardening Recommendations

Recommendation Priority Details
Limit Administrative Access Critical Do not expose WebUI or SSH to the public internet. Use a VPN or allowlist IPs if remote access is needed.
Use a VPN for Remote Access Critical Use IPsec, OpenVPN, WireGuard or other reliable VPN service for remote access. Never expose management interfaces directly.
Apply IP Whitelisting Critical Restrict access to remote services based on specific IP addresses using a firewall.
Do Not Rely on Obscure Ports Alone High Avoid using non-standard ports as a primary defense. Use in conjunction with firewall rules.
Disable WiFi if Not Needed High Disable WiFi instead or reduce transmission power.
Use Secure Firmware Validation High Teltonika Networks firmware is digitally signed and authorized for security. Additionally only apply firmware with verified SHA-256 hashes. Avoid MD5/SHA-1.
Disable SMS/Call Utilities by Default Medium Disable SMS command features unless explicitly required. Use phone number whitelists and log all commands. Authentication is available via administrative password, custom password or device serial number.

Secure Operation & Maintenance

Recommendation Priority Details
Continuous Access Monitoring Critical Regularly monitor login attempts and access logs. Enable Event Juggler alerts for critical changes.
Review and Audit Firewall Rules Critical Keep firewall rules up to date. Remove unused or overly permissive rules.
Rotate Passwords & SSH Keys Periodically High Rotate credentials and SSH keys at regular intervals. Immediately revoke compromised credentials.
Audit Protocols and Services High Ensure only secure protocols are used. Disable legacy or insecure options (e.g., FTP, Telnet).
Conduct Periodic WiFi Audits Medium Reassess SSID use, encryption standards, and user access.
Verify Backups Securely Medium Encrypt backups. Use SHA-256/SHA-512 hashes to validate backups before restoring them. Store securely.
Retrieved from "https://wiki.teltonika-networks.com/index.php?title=Template:Security_guidelines&oldid=154142"