Post

Secure Mikrotik RouterOS ISP template

A secure ISP template, ansible implementation will be published.

Core settings

Routerboard

  • Auto-upgrade: Enable

Services

If you want to see what ports Mikrotik uses and the matching ports: https://help.mikrotik.com/docs/spaces/ROS/pages/103841820/Services

IP->Services section controls the core management interfaces available on the router. Common services that would be enabled:

  • api(-ssl)
  • ssh
  • winbox
  • www(-ssl) - REST API

These services can be isolated in their own VRF for connectivity to a OOB network.

Hiding services

Sometimes you want to keep running a service but not expose it to the general internet.

Could we protect services behind SSH / bind strictly to 127.0.0.1/32?

  • ssh -L 8080:127.0.0.1:80 admin@<router IP> - By running this I can go to http://127.0.0.1:8080 and access the web interface of my router through the tunnel.
  • While I can firewall the port off or block access using the “allowed from” under services (you show up as 127.0.0.1 when coming through the SSH tunnel), the port is still seen as open in nmap scans and you can still connect to it via other IPs on the router.
  • The best way forward IMHO is to have an option to bind services to at minimum localhost. Preffered option would be allow it to be bound to one or more IPs on the router (reducing the visible attack surface, degrading an attackers ability to fingerprint what the device is).
  • Practically every IP service has this support as it is part of the socket bind() call which is common to all TCP/IP stacks, it just defaults to bind("0.0.0.0", <port #>) right now. This change is to allow the bind address(s) to be set to something different from the default.

SSH

  • Strong Crypto: Enable
  • Host Key Type: Ed25519

After changing the “Host Key Type” regenerate the host key.

ISP Specific

Extra packages

  • calea
  • container
  • gps
  • rose-storage
  • tr069-client
  • ups
  • user-manager
  • zerotier

Interface lists

1
2
3
/interface list
add name=exclude_discovery
add name=customer_facing

Interfaces

Vlan Interfaces

Ranges should be selected, a recommended setup could be: | Start | End | Description | | —– | — | ———– | | 1 | 1 | Reserved for onboarding / detecing misconfigurations as this is the default | | 2 | 19 | Reserved | | 20 | 49 | Backhauls / Interconnects | | 50 | 99 | Reserved | | 100 | 110 | Customer facing (Residential, Business, etc) | | 111 | 3999 | Individual

Neighbor discovery

  • Block:
    • customer facing interfaces
    • Upstream / provider facing
  • Enable:
    • Internal interfaces
    • Connections between internal sites (unless there is an external provider to be concerned about).

IP -> Firewall

  • Customer facing:
    • Block all RFC1918 blocks + multicast destinations.
    • Block any source not setup on the interface (these interfaces are not used for transit). Special use cases can have a specific list of prefixes that is allowed.
This post is licensed under CC BY 4.0 by the author.