{"id":455207,"date":"2025-04-08T21:00:51","date_gmt":"2025-04-08T21:00:51","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=455207"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=455207","title":{"rendered":"<span>A Tale of How Not to Turn Your Cisco Router into a Public DNS and NTP Server by Accident<\/span>"},"content":{"rendered":"<div><!--[--><!--]--><\/div>\n<div id=\"post-content-body\">\n<div>\n<div class=\"article-formatted-body article-formatted-body article-formatted-body_version-2\">\n<div xmlns=\"http:\/\/www.w3.org\/1999\/xhtml\">\n<p>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 <abbr class=\"habraabbr\" title=\"Small Office Home Office \u2014 usage scenario for a home or small office.\" data-title=\"&lt;p&gt;&lt;strong&gt;Small Office Home Office&lt;\/strong&gt; \u2014 usage scenario for a home or small office.&lt;\/p&gt;\" data-abbr=\"SOHO\">SOHO<\/abbr> scenarios. However, unlike consumer-grade routers, configuring something like Cisco IOS requires caution. If you don\u2019t think things through, the router may start &#171;living its own life&#187; and end up, for instance, as a <a href=\"https:\/\/www.cloudflare.com\/learning\/ddos\/dns-amplification-ddos-attack\/\" rel=\"noopener noreferrer nofollow\">DDoS amplification<\/a> tool.<\/p>\n<figure class=\"full-width\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/habrastorage.org\/r\/w780q1\/getpro\/habr\/upload_files\/5bb\/2bb\/e1d\/5bb2bbe1db2cf7bcaaaa0e8a340bdd9b.jpg\" width=\"1763\" height=\"1025\" data-src=\"https:\/\/habrastorage.org\/getpro\/habr\/upload_files\/5bb\/2bb\/e1d\/5bb2bbe1db2cf7bcaaaa0e8a340bdd9b.jpg\" data-blurred=\"true\"\/><\/figure>\n<p>Generally speaking, Cisco IOS-based equipment isn\u2019t a frequent guest in SOHO environments. The main obstacle is the price: for the same money, consumer-grade &#171;boxes&#187; offer more attractive specs. Still, Cisco does occasionally show up in SOHO setups.<\/p>\n<p>Let\u2019s clarify: when we say IOS, we also mean IOS-XE. And let\u2019s agree on this upfront \u2014 don\u2019t mindlessly copy-paste from this article. First, review the documentation for any commands you&#8217;re going to use.<\/p>\n<p>IOS includes a built-in firewall, but it&#8217;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.<\/p>\n<p>In general, living without a firewall is not catastrophic. But it\u2019s worth remembering that any enabled services will be exposed not only to the local network but also to the public internet \u2014 including DNS, NTP, HTTP, SSH, Telnet, etc. While L2 services like CDP pose minimal risk, others are more critical. So if you\u2019re 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.<\/p>\n<p>A basic SOHO config usually has the following traits:<\/p>\n<ul>\n<li>\n<p>There is a public-facing interface with a provider-assigned IP address.<\/p>\n<\/li>\n<li>\n<p>Behind NAT sits a local &#171;gray&#187; network.<\/p>\n<\/li>\n<li>\n<p>The router runs basic network services like DNS, DHCP, and NTP.<\/p>\n<\/li>\n<\/ul>\n<p>Below are the key configuration parameters. This is not the full config \u2014 only the lines relevant to the problem at hand.<\/p>\n<pre><code>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<\/code><\/pre>\n<p>Key points from the config:<\/p>\n<ul>\n<li>\n<p>There&#8217;s a local network with the prefix <code>192.168.0.0\/24<\/code>, and the router has the address <code>192.168.0.1<\/code> on that network.<\/p>\n<\/li>\n<li>\n<p>The provider assigns a public address (<code>192.0.2.2<\/code>), which also serves as the NAT address for the LAN.<\/p>\n<\/li>\n<li>\n<p>DHCP is enabled and informs clients that the router handles DNS.<\/p>\n<\/li>\n<li>\n<p>The router acts as a recursive name server and forwards queries to <code>1.1.1.1<\/code>.<\/p>\n<\/li>\n<li>\n<p>An ACL named <code>NAT-networks<\/code> is defined to match clients in the local network.<\/p>\n<\/li>\n<\/ul>\n<p>With this config, everything works. However, the router\u2019s 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 <code>dig @router_public_ip<\/code><a href=\"http:\/\/example.com\" rel=\"noopener noreferrer nofollow\"><code>example.com<\/code><\/a> from outside, the router will respond.<\/p>\n<p>This approach isn\u2019t inherently dangerous. In fact, it was common in the early days of the internet \u2014 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&#8217;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.<\/p>\n<p>Let\u2019s try to restrict access to essential services in IOS. There are two main ways:<\/p>\n<ol>\n<li>\n<p><strong>Disable unnecessary services.<\/strong> For example, the built-in HTTP server is rarely needed.<\/p>\n<\/li>\n<li>\n<p><strong>If you want to keep the service (e.g., DNS), assign an access group to it.<\/strong><\/p>\n<\/li>\n<\/ol>\n<p>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):<\/p>\n<pre><code>ip access-list extended NAT-networks \u00a0permit ip 192.168.0.0 0.0.0.255 any<\/code><\/pre>\n<p>Another approach: create a dedicated ACL for admin access if you plan to expand the list in the future. Don\u2019t forget about IPv6 \u2014 although it&#8217;s not part of this example:<\/p>\n<pre><code>ip access-list standard Maintenance-v4 \u00a0permit 192.168.0.0 0.0.0.255 log \u00a0permit host 198.51.100.254 log \u00a0deny \u00a0 any log<\/code><\/pre>\n<p>Here, we define our LAN segment and an external host (<code>198.51.100.254<\/code>) that also has access \u2014 imagine it&#8217;s an external monitoring system.<\/p>\n<p>Now, let\u2019s briefly touch on how to protect typical network services:<\/p>\n<p><strong>SSH and Telnet<\/strong> are limited via the line sections. The number of VTIs depends on your router model.<\/p>\n<pre><code>line vty 0 4 \u00a0access-class Maintenance-v4 in line vty 5 97 \u00a0access-class Maintenance-v4 in<\/code><\/pre>\n<p><strong>SNMP<\/strong> only responds to explicitly defined hosts.<\/p>\n<pre><code>snmp-server host 198.51.100.254 version 2c CommunityName<\/code><\/pre>\n<p><strong>HTTP server<\/strong>, if you really need it, can be restricted like this:<\/p>\n<pre><code>ip http access-class ipv4 Maintenance-v4<\/code><\/pre>\n<p>General rule of thumb: for any service called <code>servername<\/code>, check the <code>ip servername<\/code> section for an <code>access-class<\/code> or similar directive and apply your ACL there, remembering the correct address family.<\/p>\n<p>DNS, however, is trickier. Still, it&#8217;s possible to restrict access using the DNS <em>view<\/em> 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:<\/p>\n<pre><code>ip dns view-list Recursor  view default 1   restrict source access-group NAT-networks<\/code><\/pre>\n<p>Next, you apply the view to the DNS server:<\/p>\n<pre><code>ip dns server view-group Recursor<\/code><\/pre>\n<p>So the DNS config will look something like this:<\/p>\n<pre><code>ip name-server 1.1.1.1 ! ip dns view-list Recursor \u00a0view default 1 \u00a0\u00a0restrict source access-group NAT-networks ip dns server view-group Recursor ip dns server<\/code><\/pre>\n<p><strong>Bonus topic: NTP \u2014 a legacy protocol still used in DDoS attacks alongside DNS.<\/strong><\/p>\n<p>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:<\/p>\n<pre><code>ntp max-associations 32 ntp master ntp server server_1 ntp server server_2<\/code><\/pre>\n<p><strong>Reminder:<\/strong> Be cautious when using DNS names for NTP servers \u2014 this often delays the router\u2019s boot process. It\u2019s recommended to use IP addresses.<\/p>\n<p>If you <em>must<\/em> 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\u2019s why.<\/p>\n<p>Access to NTP is also controlled via an <code>access-group<\/code>, but with a twist. You must separately list the IP addresses of your NTP pool servers. If you don\u2019t, time synchronization may fail, or your router may become a public NTP server \u2014 both undesirable outcomes.<\/p>\n<p>Let\u2019s say your reference NTP servers are <code>198.51.100.5<\/code> and <code>203.0.113.5<\/code>. The access control config should look like this:<\/p>\n<pre><code>ip access-list standard NTP-servers \u00a0permit 198.51.100.5 \u00a0permit 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<\/code><\/pre>\n<p>And finally: don\u2019t forget to restrict L2 services that face the provider. The risks of leaving them open are small, but still present.<\/p>\n<p>These settings are traditionally applied per interface. The list below isn\u2019t exhaustive. Some of them are applied automatically in modern IOS versions and hidden from the config:<\/p>\n<pre><code>interface GigabitEthernet \u00a0description WAN \u00a0no ip redirects \u00a0no ip proxy-arp \u00a0ipv6 nd ra suppress all \u00a0no ipv6 mfib forwarding input \u00a0no cdp enable \u00a0no lldp transmit \u00a0no lldp receive<\/code><\/pre>\n<p><strong>Fun fact:<\/strong> 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 \u201cserious\u201d features \u2014 and the routers are firewalled to the teeth. However, we also have what\u2019s called an OOB (Out-of-Band) network \u2014 intentionally simple both physically and logically. It\u2019s isolated from the main network and connects to the internet via an LTE fallback link.<\/p>\n<p>This specific case involved an ISR4331 router with a hefty switch card in the SM slot, connected to admin interfaces of various devices. That\u2019s where we ended up accidentally exposing both DNS and NTP to the outside world \u2014 a classic case of \u201ceven pros slip up sometimes.\u201d<\/p>\n<\/p>\n<\/div>\n<\/div>\n<\/div>\n<p><!----><!----><\/div>\n<p><!----><!----><br \/> \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438 <a href=\"https:\/\/habr.com\/ru\/articles\/898932\/\"> https:\/\/habr.com\/ru\/articles\/898932\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<div><!--[--><!--]--><\/div>\n<div id=\"post-content-body\">\n<div>\n<div class=\"article-formatted-body article-formatted-body article-formatted-body_version-2\">\n<div xmlns=\"http:\/\/www.w3.org\/1999\/xhtml\">\n<p>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 <abbr class=\"habraabbr\" title=\"Small Office Home Office \u2014 usage scenario for a home or small office.\" data-title=\"&lt;p&gt;&lt;strong&gt;Small Office Home Office&lt;\/strong&gt; \u2014 usage scenario for a home or small office.&lt;\/p&gt;\" data-abbr=\"SOHO\">HO&#187;>SOHO<\/abbr> scenarios. However, unlike consumer-grade routers, configuring something like Cisco IOS requires caution. If you don\u2019t think things through, the router may start &#171;living its own life&#187; and end up, for instance, as a <a href=\"https:\/\/www.cloudflare.com\/learning\/ddos\/dns-amplification-ddos-attack\/\" rel=\"noopener noreferrer nofollow\">DDoS amplification<\/a> tool.<\/p>\n<figure class=\"full-width\"><\/figure>\n<p>Generally speaking, Cisco IOS-based equipment isn\u2019t a frequent guest in SOHO environments. The main obstacle is the price: for the same money, consumer-grade &#171;boxes&#187; offer more attractive specs. Still, Cisco does occasionally show up in SOHO setups.<\/p>\n<p>Let\u2019s clarify: when we say IOS, we also mean IOS-XE. And let\u2019s agree on this upfront \u2014 don\u2019t mindlessly copy-paste from this article. First, review the documentation for any commands you&#8217;re going to use.<\/p>\n<p>IOS includes a built-in firewall, but it&#8217;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.<\/p>\n<p>In general, living without a firewall is not catastrophic. But it\u2019s worth remembering that any enabled services will be exposed not only to the local network but also to the public internet \u2014 including DNS, NTP, HTTP, SSH, Telnet, etc. While L2 services like CDP pose minimal risk, others are more critical. So if you\u2019re 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.<\/p>\n<p>A basic SOHO config usually has the following traits:<\/p>\n<ul>\n<li>\n<p>There is a public-facing interface with a provider-assigned IP address.<\/p>\n<\/li>\n<li>\n<p>Behind NAT sits a local &#171;gray&#187; network.<\/p>\n<\/li>\n<li>\n<p>The router runs basic network services like DNS, DHCP, and NTP.<\/p>\n<\/li>\n<\/ul>\n<p>Below are the key configuration parameters. This is not the full config \u2014 only the lines relevant to the problem at hand.<\/p>\n<pre><code>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<\/code><\/pre>\n<p>Key points from the config:<\/p>\n<ul>\n<li>\n<p>There&#8217;s a local network with the prefix <code>192.168.0.0\/24<\/code>, and the router has the address <code>192.168.0.1<\/code> on that network.<\/p>\n<\/li>\n<li>\n<p>The provider assigns a public address (<code>192.0.2.2<\/code>), which also serves as the NAT address for the LAN.<\/p>\n<\/li>\n<li>\n<p>DHCP is enabled and informs clients that the router handles DNS.<\/p>\n<\/li>\n<li>\n<p>The router acts as a recursive name server and forwards queries to <code>1.1.1.1<\/code>.<\/p>\n<\/li>\n<li>\n<p>An ACL named <code>NAT-networks<\/code> is defined to match clients in the local network.<\/p>\n<\/li>\n<\/ul>\n<p>With this config, everything works. However, the router\u2019s 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 <code>dig @router_public_ip<\/code><a href=\"http:\/\/example.com\" rel=\"noopener noreferrer nofollow\"><code>example.com<\/code><\/a> from outside, the router will respond.<\/p>\n<p>This approach isn\u2019t inherently dangerous. In fact, it was common in the early days of the internet \u2014 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&#8217;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.<\/p>\n<p>Let\u2019s try to restrict access to essential services in IOS. There are two main ways:<\/p>\n<ol>\n<li>\n<p><strong>Disable unnecessary services.<\/strong> For example, the built-in HTTP server is rarely needed.<\/p>\n<\/li>\n<li>\n<p><strong>If you want to keep the service (e.g., DNS), assign an access group to it.<\/strong><\/p>\n<\/li>\n<\/ol>\n<p>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):<\/p>\n<pre><code>ip access-list extended NAT-networks \u00a0permit ip 192.168.0.0 0.0.0.255 any<\/code><\/pre>\n<p>Another approach: create a dedicated ACL for admin access if you plan to expand the list in the future. Don\u2019t forget about IPv6 \u2014 although it&#8217;s not part of this example:<\/p>\n<pre><code>ip access-list standard Maintenance-v4 \u00a0permit 192.168.0.0 0.0.0.255 log \u00a0permit host 198.51.100.254 log \u00a0deny \u00a0 any log<\/code><\/pre>\n<p>Here, we define our LAN segment and an external host (<code>198.51.100.254<\/code>) that also has access \u2014 imagine it&#8217;s an external monitoring system.<\/p>\n<p>Now, let\u2019s briefly touch on how to protect typical network services:<\/p>\n<p><strong>SSH and Telnet<\/strong> are limited via the line sections. The number of VTIs depends on your router model.<\/p>\n<pre><code>line vty 0 4 \u00a0access-class Maintenance-v4 in line vty 5 97 \u00a0access-class Maintenance-v4 in<\/code><\/pre>\n<p><strong>SNMP<\/strong> only responds to explicitly defined hosts.<\/p>\n<pre><code>snmp-server host 198.51.100.254 version 2c CommunityName<\/code><\/pre>\n<p><strong>HTTP server<\/strong>, if you really need it, can be restricted like this:<\/p>\n<pre><code>ip http access-class ipv4 Maintenance-v4<\/code><\/pre>\n<p>General rule of thumb: for any service called <code>servername<\/code>, check the <code>ip servername<\/code> section for an <code>access-class<\/code> or similar directive and apply your ACL there, remembering the correct address family.<\/p>\n<p>DNS, however, is trickier. Still, it&#8217;s possible to restrict access using the DNS <em>view<\/em> 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:<\/p>\n<pre><code>ip dns view-list Recursor  view default 1   restrict source access-group NAT-networks<\/code><\/pre>\n<p>Next, you apply the view to the DNS server:<\/p>\n<pre><code>ip dns server view-group Recursor<\/code><\/pre>\n<p>So the DNS config will look something like this:<\/p>\n<pre><code>ip name-server 1.1.1.1 ! ip dns view-list Recursor \u00a0view default 1 \u00a0\u00a0restrict source access-group NAT-networks ip dns server view-group Recursor ip dns server<\/code><\/pre>\n<p><strong>Bonus topic: NTP \u2014 a legacy protocol still used in DDoS attacks alongside DNS.<\/strong><\/p>\n<p>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:<\/p>\n<pre><code>ntp max-associations 32 ntp master ntp server server_1 ntp server server_2<\/code><\/pre>\n<p><strong>Reminder:<\/strong> Be cautious when using DNS names for NTP servers \u2014 this often delays the router\u2019s boot process. It\u2019s recommended to use IP addresses.<\/p>\n<p>If you <em>must<\/em> 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\u2019s why.<\/p>\n<p>Access to NTP is also controlled via an <code>access-group<\/code>, but with a twist. You must separately list the IP addresses of your NTP pool servers. If you don\u2019t, time synchronization may fail, or your router may become a public NTP server \u2014 both undesirable outcomes.<\/p>\n<p>Let\u2019s say your reference NTP servers are <code>198.51.100.5<\/code> and <code>203.0.113.5<\/code>. The access control config should look like this:<\/p>\n<pre><code>ip access-list standard NTP-servers \u00a0permit 198.51.100.5 \u00a0permit 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<\/code><\/pre>\n<p>And finally: don\u2019t forget to restrict L2 services that face the provider. The risks of leaving them open are small, but still present.<\/p>\n<p>These settings are traditionally applied per interface. The list below isn\u2019t exhaustive. Some of them are applied automatically in modern IOS versions and hidden from the config:<\/p>\n<pre><code>interface GigabitEthernet \u00a0description WAN \u00a0no ip redirects \u00a0no ip proxy-arp \u00a0ipv6 nd ra suppress all \u00a0no ipv6 mfib forwarding input \u00a0no cdp enable \u00a0no lldp transmit \u00a0no lldp receive<\/code><\/pre>\n<p><strong>Fun fact:<\/strong> 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 \u201cserious\u201d features \u2014 and the routers are firewalled to the teeth. However, we also have what\u2019s called an OOB (Out-of-Band) network \u2014 intentionally simple both physically and logically. It\u2019s isolated from the main network and connects to the internet via an LTE fallback link.<\/p>\n<p>This specific case involved an ISR4331 router with a hefty switch card in the SM slot, connected to admin interfaces of various devices. That\u2019s where we ended up accidentally exposing both DNS and NTP to the outside world \u2014 a classic case of \u201ceven pros slip up sometimes.\u201d<\/p>\n<\/p>\n<\/div>\n<\/div>\n<\/div>\n<p><!----><!----><\/div>\n<p><!----><!----><br \/> \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438 <a href=\"https:\/\/habr.com\/ru\/articles\/898932\/\"> https:\/\/habr.com\/ru\/articles\/898932\/<\/a><br \/><\/br><\/br><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-455207","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/455207","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=455207"}],"version-history":[{"count":0,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/455207\/revisions"}],"wp:attachment":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=455207"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=455207"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=455207"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}