PCI Compliance - DNS server problems

RouterOS General
1

Ok - so here’s a curiousity - I have a routerboard 433 setup - and we have this company doing an audit of the system - they claim there are 2 critical errors with our setup (that they can see from the outside)

they are both related to DNS issues

98.191.121.61 Medium domain (53/udp) DNS Server Cache Snooping Remote Information Disclosure
98.191.121.61 Medium domain (53/udp) DNS Server Recursive Query Cache Poisoning Weakness

I have the internal network on a NAT setup with DNS (allow remote requests on)

I have setup a firewall to drop packets from the WAN port on port 53 both TCP and UDP (this is supposed to drop all DNS requests coming to the routerboard from the internet), and the packet counters go up when I run nmap to see what ports are still open. nmap reports DNS/53 is “filtered” even though I’m dropping all packets and it still doesn’t pass the audit due to those two issues above.

does anyone have any suggestions on how to totally limit port 53 visibility on the WAN port so we can pass this PCI compliance test?

cheers,
Paul

2

Maybe posting your rules from “/ip firewall filter” would help us help you.

3

sorry - should have provided more details

results for firewall - filter rules

ether1-cox is the WAN-internet port

Flags: X - disabled, I - invalid, D - dynamic 
 3   chain=input action=drop protocol=tcp in-interface=ether1-cox dst-port=53 

 4   chain=input action=drop protocol=udp in-interface=ether1-cox dst-port=53 

 5   chain=input action=drop protocol=tcp in-interface=ether1-cox dst-port=2000
4

Ok this problem has been solved - and the solution was interesting for me. I’ll outline what was needed in order to pass the PCI compliance test.

So as previously mentioned I was DROPPING packets coming in on the WAN port to port 53 - which was effective in stopping attacks from the WAN side — HOWEVER apparently security specialists don’t consider a DROPPED packet a secure way of showing that the service is not open. It just means that there was NO answer at that particular time and that it MAY be possible the service would come back up at a future time.

Apparently they are looking for a flat out rejection in the form of a REJECT message with TCP reset as seen in the following ip firewall filter configuration.


Flags: X - disabled, I - invalid, D - dynamic 
  3   chain=input action=reject reject-with=tcp-reset protocol=tcp in-interface=ether1-cox dst-port=53 
 4   chain=input action=reject reject-with=icmp-port-unreachable protocol=udp in-interface=ether1-cox 
     dst-port=53 
 5   chain=forward action=reject reject-with=tcp-reset protocol=tcp in-interface=ether1-cox dst-port=53 
 6   chain=forward action=reject reject-with=icmp-port-unreachable protocol=udp in-interface=ether1-cox 
     dst-port=53 
 7   chain=input action=reject reject-with=icmp-port-unreachable protocol=tcp in-interface=ether1-cox 
     dst-port=2000

This allowed us to pass the PCI compliance test - even though a DROP filter would have had the same effect. Hopefully this helps someone else who may be having a similiar problem.

cheers,
Paul

5

Resurrecting a dead thread here, but pmurdock’s solution of rejecting TCP packets worked a treat. PCI scan passed now.

Thanks

6

The german ISP “Deutsche Telekom” recently has startet to scan their customers for vulnerabilitys. Much of our ADSL (T-DSL Business) using customers got Letters stating the have an open recursive dns resolver. Our checks showed the DNS was not open. We always had firewall rules to drop the connections. pmurdock is right, reject does the trick…

obvious this is the solution to an (in reality) non existing problem :slight_smile: