DNS Open Resolver

[Flyshuffle]

Hi Everyone, The IP addresses on our internet facing physical interface, as well as on the VIP IP addresses recently got flagged as vulnerable DNS open resolver servers. This surprised me, as we do not run any internet facing DNS servers and have never explicitly configured the Fortigate (FortiOS 5.2) firewall to listen on port 53, or forward port 53 traffic to an internal DNS server. But when I checked an IP address with openresolver.com, sure enough, that says the IP address is listening on port 53, and is vulnerable to a DNS amplification attack. Anyone know what gives? Thanks!

[Dave_Hall · Accepted solution]

Check the firewall polices that you have VIPs on that they are only opening up ports need for that traffic and whether NAT is enabled (it shouldn't be unless you have unusual reasons for needing it).

Maybe temporarily disconnect the server in question then see if you can still ping it/checked the IP with openresolver.com.  Alternately use nslookup and connect to the IP address to see what info is handed back. Worst case is you have DNS running on an AD server or other internal server that is responding to outside requests to through a NATed firewall policy or VIP.

You could try sniffing the traffic...

diag debug reset diag debug flow filter addr <IP address> diag debug flow filter proto 6 diag debug flow filter port 25 diag debug flow show console enable diag debug flow trace start 1000 diag debug en

Though you really should try to fix/resolve the problem -- a possible workaround is to look into setting up local-in-policy rules.

[AndreaSoliva · Accepted solution]

Hi

the only thing which comes in my mind is following:

If you use a DNS Database Server which means if you configured the FortiGate to be a DNS server you have to open listener on the corresponding interfaces. Example if you open Internal you will set this listener to "recursive". This IP of the Internal is afterwards used within DHCP Server to be provided to user as internal DNS server. If a user is launching a dns request it will be send to the Internal Interface IP. This request goes to the DNS Database entries and looks for a corresponding entry. If found the request will be answered directly. If there is no corresponding entry the request will be forwarded to the FortiGate system DNS servers. In old cookbooks and some other sysadmin books there is shown that for this function to be forwarded to the FortiGate System DNS server on the wan1 (ISP Interface) has to be opened also a listener. This is true for 4.x but fatal for 5.x because if you do so you have a open recursive dns listener accessable from outsite world.

have a look if this is the case on your site and if so delete the listener on ISP interface

hope this helps

have fun....

Andrea

[Dave_Hall · Accepted solution]

Check the firewall polices that you have VIPs on that they are only opening up ports need for that traffic and whether NAT is enabled (it shouldn't be unless you have unusual reasons for needing it).

Maybe temporarily disconnect the server in question then see if you can still ping it/checked the IP with openresolver.com.  Alternately use nslookup and connect to the IP address to see what info is handed back. Worst case is you have DNS running on an AD server or other internal server that is responding to outside requests to through a NATed firewall policy or VIP.

You could try sniffing the traffic...

diag debug reset diag debug flow filter addr <IP address> diag debug flow filter proto 6 diag debug flow filter port 25 diag debug flow show console enable diag debug flow trace start 1000 diag debug en

Though you really should try to fix/resolve the problem -- a possible workaround is to look into setting up local-in-policy rules.

[AndreaSoliva · Accepted solution]

Hi

the only thing which comes in my mind is following:

If you use a DNS Database Server which means if you configured the FortiGate to be a DNS server you have to open listener on the corresponding interfaces. Example if you open Internal you will set this listener to "recursive". This IP of the Internal is afterwards used within DHCP Server to be provided to user as internal DNS server. If a user is launching a dns request it will be send to the Internal Interface IP. This request goes to the DNS Database entries and looks for a corresponding entry. If found the request will be answered directly. If there is no corresponding entry the request will be forwarded to the FortiGate system DNS servers. In old cookbooks and some other sysadmin books there is shown that for this function to be forwarded to the FortiGate System DNS server on the wan1 (ISP Interface) has to be opened also a listener. This is true for 4.x but fatal for 5.x because if you do so you have a open recursive dns listener accessable from outsite world.

have a look if this is the case on your site and if so delete the listener on ISP interface

hope this helps

have fun....

Andrea

[Flyshuffle]

Thank you to those who replied and offered suggestions. We ended up creating a local-in policy that denied port 53 inbound from the Internet. I'm still not 100% sure on what the underlying issue was (In System > Config > Features, DNS Database was not selected) but in any event, Fortinet support walked us through setting up the local-in policy and is now resolved.

Thanks again!

[Chris_Harvey · Accepted solution]

I've been struggling with the same issue, a customers FTG60c was getting flooded with DNS queries and it was maxing out the customers internet circuit. Finally, after running DNS recursion tests against the customers IP block, we noticed the FTG's WAN interface had port 53 open, though there were no visable policies to allowing this port through the firewall. Seemingly DNS was forwarding through to the WAN to the FTG's internal DNS server... To correct this, we enabled the DNS server feature on the FTG and disabled DNS recursion on the affected WAN interface which effectively closed 53. Not sure how this got turned on in the first place, but hope this helps someone else..

-Chris