Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 2 subscribers
  • Views 1316 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DNS listening where it shouldn't?

Jack Daniel
Hi folks, been a while...

I'm probably missing something obvious, but my UTM9 (9.002) has DNS open on the WAN interface, and it is not configured to do so.  No NAT rules are active which should come into play.

netstat shows named is listening on interfaces where I don't want or expect it to listen (interfaces not listed in DNS Allowed Networks), including the WAN interface- and it is responding to external DNS queries. Listening on both TCP and UDP, too. 

Any thoughts?

Thanks
Jack


This thread was automatically locked due to age.
  • 0
    Looks like you figured it out jack.  Telnet to port 53 failing.  [:)]
  • 0 in reply to Scott_Klassen
    (delayed response due to travel)

    The problem still exists. I've updated to the latest, and after rebooting netstat still shows named listening on the external IF on 53 TCP and UDP.  I am still able to perform DNS queries against it remotely.

    I did realize one of the stray interfaces was a just VPN pool, but that's automagically added when SSL VPN is enabled- and that makes sense. What doesn't make sense is what's enabling named on the WAN interface.  No RED is connected (but one is configured), disabling all remote access (including HTML5 via portal) only removes the VPN IF, not the WAN IF.  Disabling the WAF doesn't make a different, either.

    netstat screenshot provided for entertainment and possible enlightenment.

    Odd...
  • 0
    Hey Jack - great to see you around!

    I get the same netstat results - named listening on port 53 for all IPs defined on all interfaces.  A port 53 request from any network not listed in 'Allowed networks' in DNS results in a default drop out of the INPUT chain - apparently that box determines firewall rules instead of the named configuration, but I don't know the way to see that.

    Cheers - Bob
  • 0
    Thanks Bob.

    Very interesting.  After trying a few things and rebooting a few times, I still see UDP 53 as open from the Internet, but not TCP, and I can no longer use it for DNS resolution remotely.  This all started with a regular Nessus scan of my Internet facing addresses (run from Moscow, truly remote) where DNS reported as responding and I confirmed by using the ASG/UTM external IP for DNS lookups remotely while traveling last week (while not connect by VPN).

    So, if the DNS is supposed to listen, something was making iptables unhappy and keeping that default drop from happening.

    Curious. If it happens again I'll dig through iptables and see what I can find there.

    Thanks
    Jack
  • 0
    I still see UDP 53 as open from the Internet, but not TCP

    I only tried TCP.

    Cheers - Bob
  • 0
    I'm just ran NMAP remotely against my 3 Astaro firewalls; 7.509, 8.305, and 9.001; all show 

    PORT   STATE    SERVICE
    53/tcp filtered domain

    and 
    PORT   STATE         SERVICE
    53/udp open|filtered domain


    I used
    nmap -sU -Pn -p U:53 target
    and
    nmap -Pn -p 53 target

    my netstat output looks similar.

    nslookup fails to work... Jack, is that what you're using to run remote queries?


    Barry
  • 0
    Hi Barry,

    Yes, I used nslookup on Windows hosts and dig on Linux systems to query to my UTM remotely.  It is working as expected now, (which is to say it doesn't work) but it was an unpleasant surprise while on the road.

    I've added a scheduled scan to my Russian lab so I should be able to spot it should it happen again.

    Jack