A Tale of How Not to Turn Your Cisco Router into a Public DNS and NTP Server by Accident

The Cisco IOS/IOS-XE operating system is a source of inspiration for many other vendors. The internet is full of guides on how to configure a typical Cisco router for SOHO scenarios. However, unlike consumer-grade routers, configuring something like Cisco IOS requires caution. If you don’t think things through, the router may start "living its own life" and end up, for instance, as a DDoS amplification tool.

Generally speaking, Cisco IOS-based equipment isn’t a frequent guest in SOHO environments. The main obstacle is the price: for the same money, consumer-grade "boxes" offer more attractive specs. Still, Cisco does occasionally show up in SOHO setups.

Let’s clarify: when we say IOS, we also mean IOS-XE. And let’s agree on this upfront — don’t mindlessly copy-paste from this article. First, review the documentation for any commands you're going to use.

IOS includes a built-in firewall, but it's disabled by default. Enabling the firewall (especially a zone-based firewall) introduces a set of intricacies that not everyone is ready to deal with. As a result, most people just leave the router without a firewall at all.

In general, living without a firewall is not catastrophic. But it’s worth remembering that any enabled services will be exposed not only to the local network but also to the public internet — including DNS, NTP, HTTP, SSH, Telnet, etc. While L2 services like CDP pose minimal risk, others are more critical. So if you’re skipping the firewall, at the very least you should restrict access to sensitive services at the service level. Most of them support access restrictions via ACLs.

A basic SOHO config usually has the following traits:

• There is a public-facing interface with a provider-assigned IP address.

• Behind NAT sits a local "gray" network.

• The router runs basic network services like DNS, DHCP, and NTP.

Below are the key configuration parameters. This is not the full config — only the lines relevant to the problem at hand.

hostname R1
!
ip name-server 1.1.1.1
no ip domain lookup
!
ip dhcp pool LAN
 network 192.168.0.0 255.255.255.0
 default-router 192.168.0.1
 option 42 ip 192.168.0.1
 dns-server 192.168.0.1
 lease 3
 update arp
!
vlan 1
 name LAN
!
interface GigabitEthernet0/0/0
 description Uplink
 ip address 192.0.2.2 255.255.255.0
 ip nat outside
 negotiation auto
 ip virtual-reassembly
!
interface GigabitEthernet0/1/0
 description LAN Trunk
 switchport trunk native vlan 1
 switchport trunk allowed vlan 1
 switchport mode trunk
!
interface Vlan1
 description LAN
 ip address 192.168.0.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly
!
ip nat inside source list NAT-networks interface GigabitEthernet0/0/0 overload
!
ip dns server
!
ip route 0.0.0.0 0.0.0.0 192.0.2.1 250
!
ip access-list extended NAT-networks
 permit ip 192.168.0.0 0.0.0.255 any

Key points from the config:

• There's a local network with the prefix 192.168.0.0/24, and the router has the address 192.168.0.1 on that network.

• The provider assigns a public address (192.0.2.2), which also serves as the NAT address for the LAN.

• DHCP is enabled and informs clients that the router handles DNS.

• The router acts as a recursive name server and forwards queries to 1.1.1.1.

• An ACL named NAT-networks is defined to match clients in the local network.

With this config, everything works. However, the router’s built-in DNS resolver will process recursive queries not only from local clients but from the entire internet, via the public interface. Yes, if you do dig @router_public_ipexample.com from outside, the router will respond.

This approach isn’t inherently dangerous. In fact, it was common in the early days of the internet — but not anymore. A public DNS server poses a threat to others on the network due to DDoS amplification attacks. If an attacker spoofs the source IP in a DNS packet with the victim's address, the router will respond to the victim instead. Unfortunately, IP spoofing is still possible today, making this type of DDoS attack quite popular.

Let’s try to restrict access to essential services in IOS. There are two main ways:

1. Disable unnecessary services. For example, the built-in HTTP server is rarely needed.

2. If you want to keep the service (e.g., DNS), assign an access group to it.

To go with the second option, start by creating a standard ACL listing who is allowed to connect. If access is only needed for LAN clients, you can reuse the existing NAT ACL (e.g., NAT-networks):

ip access-list extended NAT-networks
 permit ip 192.168.0.0 0.0.0.255 any

Another approach: create a dedicated ACL for admin access if you plan to expand the list in the future. Don’t forget about IPv6 — although it's not part of this example:

ip access-list standard Maintenance-v4
 permit 192.168.0.0 0.0.0.255 log
 permit host 198.51.100.254 log
 deny   any log

Here, we define our LAN segment and an external host (198.51.100.254) that also has access — imagine it's an external monitoring system.

Now, let’s briefly touch on how to protect typical network services:

SSH and Telnet are limited via the line sections. The number of VTIs depends on your router model.

line vty 0 4
 access-class Maintenance-v4 in
line vty 5 97
 access-class Maintenance-v4 in

SNMP only responds to explicitly defined hosts.

snmp-server host 198.51.100.254 version 2c CommunityName

HTTP server, if you really need it, can be restricted like this:

ip http access-class ipv4 Maintenance-v4

General rule of thumb: for any service called servername, check the ip servername section for an access-class or similar directive and apply your ACL there, remembering the correct address family.

DNS, however, is trickier. Still, it's possible to restrict access using the DNS view feature. You can define multiple views. In our case, we have a simple recursive resolver for the LAN, so our view will just allow name resolution for the local subnet. Reusing the NAT ACL is a good fit:

ip dns view-list Recursor
 view default 1
  restrict source access-group NAT-networks

Next, you apply the view to the DNS server:

ip dns server view-group Recursor

So the DNS config will look something like this:

ip name-server 1.1.1.1
!
ip dns view-list Recursor
 view default 1
  restrict source access-group NAT-networks
ip dns server view-group Recursor
ip dns server

Bonus topic: NTP — a legacy protocol still used in DDoS attacks alongside DNS.

If you configure time synchronization on the router using external NTP pools, the router itself becomes an NTP server. This is expected behavior due to how the protocol works. While this can be beneficial (e.g., you want a local time source), it can also be misused by amateur DDoS attackers in amplification attacks. A typical NTP config might look like this:

ntp max-associations 32
ntp master
ntp server server_1
ntp server server_2

Reminder: Be cautious when using DNS names for NTP servers — this often delays the router’s boot process. It’s recommended to use IP addresses.

If you must use domain names for pool servers, consider setting them via a scheduler after the router fully boots and has internet access. Still, DNS-based NTP configs are best avoided. Here’s why.

Access to NTP is also controlled via an access-group, but with a twist. You must separately list the IP addresses of your NTP pool servers. If you don’t, time synchronization may fail, or your router may become a public NTP server — both undesirable outcomes.

Let’s say your reference NTP servers are 198.51.100.5 and 203.0.113.5. The access control config should look like this:

ip access-list standard NTP-servers
 permit 198.51.100.5
 permit 203.0.113.5
!
ntp max-associations 32
ntp access-group peer NTP-servers
ntp access-group serve NAT-networks
ntp master
ntp server 198.51.100.5
ntp server 203.0.113.5

And finally: don’t forget to restrict L2 services that face the provider. The risks of leaving them open are small, but still present.

These settings are traditionally applied per interface. The list below isn’t exhaustive. Some of them are applied automatically in modern IOS versions and hidden from the config:

interface GigabitEthernet
 description WAN
 no ip redirects
 no ip proxy-arp
 ipv6 nd ra suppress all
 no ipv6 mfib forwarding input
 no cdp enable
 no lldp transmit
 no lldp receive

Fun fact: While this article focuses on using a Cisco router as a SOHO device, we actually encountered this issue outside a SOHO environment. We manage a lot of IOS-XE gear with no DNS but plenty of BGP, OSPF, and other “serious” features — and the routers are firewalled to the teeth. However, we also have what’s called an OOB (Out-of-Band) network — intentionally simple both physically and logically. It’s isolated from the main network and connects to the internet via an LTE fallback link.

This specific case involved an ISR4331 router with a hefty switch card in the SM slot, connected to admin interfaces of various devices. That’s where we ended up accidentally exposing both DNS and NTP to the outside world — a classic case of “even pros slip up sometimes.”