Dnsmasq is always recursive on default install



  • The default settings of dnsmasq will result in recursive answers on wan and external interfaces.
    The default should represent a set of the options "bind-interfaces", "listen-address=ip" or "interface=lan".

    See http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

    Not turning recursive off may lead to DNS Amplification attacks as reported by
    http://slashdot.org/story/06/03/16/1658209/ddos-attacks-via-dns-recursion
    http://www.nominum.com/dns/best-practices-for-securing-the-dns-infrastructure

    in German language: http://www.heise.de/security/meldung/DDoS-auf-Heise-ueber-zu-offene-DNS-Server-1674636.html



  • By default isn't DNS blocked by the firewall on external interfaces?

    If so then it's not an open DNS server, correct?

    These options can be added in the Services: DNS Forwarder Advanced section.

    While at it the strict-order, domain-needed, and except-interface= <interface name="">options may also be desirable.

    Also I think the interface designation is the device name, such as 'lo0', 'de0', 'de1', etc., not 'lan', 'wan', etc.
    The interface device names can be found in the pfSense config xml 'interfaces' section or by running ifconfig.</interface>



  • @NOYB:

    By default isn't DNS blocked by the firewall on external interfaces?

    Blocking something, which has been opened previously is not a well designed security concept, is it?
    I cannot confirm - at least in my configuration - that your argument is true. I was surprised to see an open recursive server, not on wan, but on a routed external network recently, when doing some checks.

    @NOYB:

    If so then it's not an open DNS server, correct?

    In the case of a routed external network, this would not be true. It would mislead the admin to the assumption, that dnsmasq is unconfigured by default. Besides, if you would pass dns-traffic for legitimate servers, you would not assume, that dnsmasq is open anyways.
    Reconfiguration of dnsmasq required knowledge of dnsmasq config files, which is contradictory to pfSense (WebGUI) concepts.

    @NOYB:

    These options can be added in the Services: DNS Forwarder Advanced section.

    While at it the strict-order, domain-needed, and except-interface= <interface name="">options may also be desirable.</interface>

    In my homble opinion it would be much more correct to not use except-interfaces (which adds interfaces to an ignore list, while still listening, but to use bind-interfaces in the first place and add interfaces with the interface=<…> option instead. This prevents undesirable open ports.

    @NOYB:

    Also I think the interface designation is the device name, such as 'lo0', 'de0', 'de1', etc., not 'lan', 'wan', etc.
    The interface device names can be found in the pfSense config xml 'interfaces' section or by running ifconfig.

    That was demonstrative for the exact use. With the exception to lo/lo0 interface names do not imply zone membership.
    Instead of interface device names, also ip ranges can be set using listen-address=<ipaddress>.

    IMO The current dnsmasq default config is inappropriate, filtering rules do not adequately compensate for this.</ipaddress>


  • Rebel Alliance Developer Netgate

    Patches accepted - if you want to shoot yourself in the foot, have at it, open it up in the firewall. There are use cases for answering there, too.

    If someone is just passing through DNS to other servers they shouldn't have the DNS forwarder enabled, and they wouldn't have a rule passing DNS to the firewall itself anyhow in that case - if they did, it's an improper firewall rule, which is also a security issue.

    Sure it may be more secure to only bind to certain interfaces, and if you (or someone else) wants to code that up and submit a pull request on github, it might even be approved, but I'm not sure the default would be changed as it would break a lot of current installs when activated.

    The best you could do would be to use the same logic that we currently use to determine if an interface is a LAN or WAN – that is, if an interface has a gateway set on it, it's a WAN. And then put all of the LANs into the list for binding. However there would need to be an option to override that, or manually select them, or just keep the current behavior. The problem with that approach is that people unknowingly or by accident set a gateway on their LAN interface(s) and this would break their access to the DNS forwarder.

    The bottom line is this:

    • dnsmasq will respond to recursive queries if it gets traffic on an interface, and people use this now and expect it to, so long as the rules allow the traffic
    • If you don't use dnsmasq, you should be disabling it anyhow
    • If you are allowing traffic to DNS servers inside the firewall, set your firewall rules to pass to those servers, and not a destination of 'any' on port 53 -- that's just bad form anyhow and would probably be flagged on an audit

    Yes, it's possible to have "more secure" default - but the same argument could be made for the GUI binding, SSH binding, and several other services.

    There is only so much you can do to protect a user from himself.



  • Has pfSense changed paradigms?
    Computer scientist have been tought, that each and every service will increase the chance to impair security.

    The primary use case is firewalling, routing and security as far as I remember.
    An open service, the user does not know about in a fresh install in the first place, contradicts this paradigm.
    An open unneeded service contradicts this paradigm even more.

    Usually a sys admin sets up a system and than opens willigly, what should be opened.
    An open public accessible DNS resolver is not usually not what you want - it will - in contrary - upset the admin ;-)

    BTW: since 2.1 is still under development, changes are to be expected and that's what the changelog or readme is for.
    BTW II: In my case it was the external network which was CIP routed with machines firewalled by other solutions. I neither expected dnsmasq to be active anyways nor to be answering on (and to) external (non RFC-1918 networks) by default.

    Proposal: make a checkbox on the interface setup pages, which states, wheter or not dnsmasq shall listen on the interface in question (if it's ipv4 config is outside the ranges described in RFC1918).


  • Rebel Alliance Developer Netgate

    Except it's not open by default, someone has to specifically put a rule in there to allow it – same as any other service.

    That's like saying the GUI is open to the world, or SSH is open to the world, because in their default configs they bind/listen on the WAN.

    So the fundamental flaw in your logic is considering DNS to be a special case here - if an admin adds an incorrect rule, incorrect things happen.



  • Jimp, I disagree respectfully:
    A service must not be open by default.

    Just blocking an open (probably) unneeded service is security by obscurity.

    E.g.: Would you activate CIFS on WAN and block it afterwards, just in case?
    No, you would open it in the first place.

    The same applies to DHCP, where pfSense asks previously to starting the service. This is the correct approach.



  • DHCP on a fresh install is open and running on LAN interface. Just saying.
    It would be nice if you only enabled dnsmasq on LAN only by default and then choose to bind it to other interface should you choose to.
    I agree with JimP though, it needs to be started and working, but I would say on a least LAN so that home users and fresh installs are able to get going much quicker.
    I would take is listening on all interfaces and block than it not working at all. At least is is known and as an admin, you can block it.



  • There are a few things that are sitting there listening away on WAN without an explicit way to tell them what interfaces to listen on. I can think of SSH and ICMP ping in addition to the DNS being discussed here.
    When I am trying to get something going and sorting out what rule is needed, I sometimes put an "allow everything" rule on the WAN for a while. Then I can ping it from outside, and quickly notice that random IPs from unusual countries (Kenya was one) start trying to do SSH logins - the sshlockout shuts them off after 15 tries, and of course I have a good password. There are hackers out there all the time looking for open ports to try. (Yes - I realise I could move SSH to another port number also, to hide it.)
    Maybe SSH could have a way to pick which interfaces it listens on?
    Maybe ICMP ping could also just listen on specified interfaces?


  • Rebel Alliance Developer Netgate

    Limiting with firewall rules is not security by obscurity. Listening on a non-default port for DNS but still allowing on WAN would be security by obscurity. Limiting with firewall rules renders the DNS service inaccessible from that network.

    Securing by firewall rules is a perfectly valid way to secure a service. Not listening at all would be more secure, yes, but the current method is nowhere near as dire as you're making it out to be.

    Ping doesn't "listen" per se, not in that way that's being implied here. SSH could be limited, but as with DNS, it would result in a default config that breaks more than it would help.

    Options to change the binding are welcome, but I wouldn't expect the default to be changed. The default is secure, but as with many other things, if the admin does something wrong, then it can result in wrong/unexpected behavior.

    Here's a much more subtle DNS binding/firewall rule issue that your suggestions would not help:

    • You have an internal segment that is routable on the LAN or DMZ interface that you want to be "open to the world" but you still want to provide recursive DNS from the firewall for clients
    • On your WAN rules, you add a "Pass all to DMZ subnet" rule
    • Whoops, you just allowed recursive DNS to the world on the firewall's IP in the DMZ, as well as the GUI and SSH
      The correct solution for that is to limit traffic to the firewall's IPs with firewall rules. Not a binding change. Disallowing recursive queries by subnet is even better, but dnsmasq isn't capable of that as far as I can see.

    Perhaps when the default configuration is switched from dnsmasq to unbound more will be possible, but I still wouldn't expect the default to change too much.



  • @jimp:

    Limiting with firewall rules is not security by obscurity. Listening on a non-default port for DNS but still allowing on WAN would be security by obscurity. Limiting with firewall rules renders the DNS service inaccessible from that network.

    An unavailable service does not need to be blocked. Binding a service to all interfaces is a rather negligent and partial approach to security. This is obscure, isn't it?

    @jimp:

    Securing by firewall rules is a perfectly valid way to secure a service.

    If you know about a service you can block it. If you don't know about it, you won't see a necessity to do so.
    Filter rules change, sometimes by accident or during debugging.

    @jimp:

    Not listening at all would be more secure, yes, but the current method is nowhere near as dire as you're making it out to be.

    Recent DNS amplification attacks contradict your assessment.

    @jimp:

    Ping doesn't "listen" per se, not in that way that's being implied here. SSH could be limited, but as with DNS, it would result in a default config that breaks more than it would help.

    Why would a /visible/ choice wether or not to activate a recursive dns server on a specific interface break anything? The dhcp server isn't active on all interfaces automatically, too. This is nothing different than that.

    Closing the ports will prevent abuse of unwilligly open interfaces.

    @jimp:

    Options to change the binding are welcome, but I wouldn't expect the default to be changed. The default is secure, but as with many other things, if the admin does something wrong, then it can result in wrong/unexpected behavior.

    The dnsmasq configuration on both pfSense and OpenWRT follows the dogma, that listening on all interfaces makes things more simple. The point is, that this simplicity results in unexpected behaviour, because "admin" is lead to believe, that everything is ok and that is in fact hazardous:

    How many "admins" even know this special kind of DDOS (dns amplification) attack and it's consquences? There are scenarios where pfSense is used for routing only, but has of course an IP within the routed subnet. In that use case that behaviour is unexpected.
    There is no warning whatsoever concerning this behaviour. If you currently want to turn this off, you have to read dnsmasq's manual. A newbie won't understand it at first.

    @jimp:

    Here's a much more subtle DNS binding/firewall rule issue that your suggestions would not help:

    • You have an internal segment that is routable on the LAN or DMZ interface that you want to be "open to the world" but you still want to provide recursive DNS from the firewall for clients

    This is a bad example:
    Then you should bind to the interface address/subnet, not the whole interface. In that case you even know of your recursive server. You can expect it, since you know of it. In those cases you would probably not use pfSense dnsmasq, but provide a separate dns server.

    @jimp:

    • On your WAN rules, you add a "Pass all to DMZ subnet" rule
    • Whoops, you just allowed recursive DNS to the world on the firewall's IP in the DMZ, as well as the GUI and SSH

    That, too will include that the "admin" takes an active action - here: adding a firewall rule to allow sth.
    If you just would use pfSense as a router for an external (non RFC1918) subnet, you may not want to use firewalling, but just forward traffic.

    @jimp:

    The correct solution for that is to limit traffic to the firewall's IPs with firewall rules. Not a binding change. Disallowing recursive queries by subnet is even better, but dnsmasq isn't capable of that as far as I can see.

    That limitation is there, nevertheless much can be done with

    bind-interfaces
    listen-address
    except-interface
    interfaces

    bind-interfaces will deactivate automatic binding to all interfaces, which is the default behaviour.
    [cite] "On systems which support it, dnsmasq binds the wildcard address, even when it is listening on only some interfaces. It then discards requests that it shouldn't reply to."[/cite]. http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

    Nevertheless, the dnsmasq basic install is open to all, which I regard to be the wrong approach.

    @jimp:

    Perhaps when the default configuration is switched from dnsmasq to unbound more will be possible, but I still wouldn't expect the default to change too much.

    The effects of changing the server software are limited by the correct use of that software. dnsmasq is not supposed to be an external resolver anyways. Therefore it should not be external under any circumstances. The first step is to exchaust it's own config options. The second is filtering.
    It's not a problem of dnsmasq itself, it's the configuration and the missing will to add gui options or warnings, that will not correlate with the requirement to have a secure host.


  • Rebel Alliance Developer Netgate

    Except that would break people who need to use dnsmasq over VPNs, static routed subnets, or indeed purposefully listening on WAN when pfSense is not on the edge of a network.

    The example I gave is no different than the examples you are giving, I have seen people do these things in production on purpose or on accident. As I said before, the default is secure. IF a user adds a rule that makes it no longer secure, that does not affect the fact that the default configuration is secure. Argue against that all you like, but you'll never be right. Anything that starts with "If the user takes action X…" is no longer speaking about the defaults.

    Whether or not there is an attack on DNS doesn't make it any different, if there was an OpenSSH flaw or lighttpd flaw it could also be exploited with overly permissive rules. If someone wants to submit code for this to add an option (off by default) to control the binding, have at it. But the kind of people who would seek out and enable that option aren't the kind of people who would be adding allow all rules on their WAN...

    If an admin leaves their rules wide open there are things even worse than DNS that could be exposed depending on their config. People get giant bills all the time because they fail to properly configure their SIP servers and then they get hacked and have to pay thousands of dollars in toll charges. Is the firewall to blame for that? No, the user added the rules. They may not have known what they were doing when they added them, but it's still user error.

    I suppose we'll have to agree to disagree on this one.

    /out



  • @jimp:

    Except that would break people who need to use dnsmasq over VPNs, static routed subnets, or indeed purposefully listening on WAN when pfSense is not on the edge of a network.

    See "listen-address" in the manual. Since each interface will necessarily have an ip in those cases, you may define it that way.
    Nevertheless there may be cases, where you would not want dnsmasq open in a VPN, a statically routed subnet. The admin should have a fair chance to configure that easily rather than to be taken into sth.
    There is really no need to bind to all.

    @jimp:

    The example I gave is no different than the examples you are giving, I have seen people do these things in production on purpose or on accident.

    If it can be done easily and accidentially, the basic configuration as well as the gui need to be worked over.
    Those who want to do this on purpose will know

    @jimp:

    As I said before, the default is secure. IF a user adds a rule that makes it no longer secure, that does not affect the fact that the default configuration is secure. Argue against that all you like, but you'll never be right. Anything that starts with "If the user takes action X…" is no longer speaking about the defaults.

    Adding rules to block a insecure configuration of a computer service is not the correct approach. Not doing this means that a line of defence is missing. Please attend a course in computer security.

    @jimp:

    Whether or not there is an attack on DNS doesn't make it any different, if there was an OpenSSH flaw or lighttpd flaw it could also be exploited with overly permissive rules. If someone wants to submit code for this to add an option (off by default) to control the binding, have at it. But the kind of people who would seek out and enable that option aren't the kind of people who would be adding allow all rules on their WAN…

    If you open such a service, you know the risks.
    It should not happen, that one is able to activate access such a service by accident without even beeing aware of that service.
    Most people don't even know, that dnsmasq is running and how it is configured.

    OpenSSH and lighttpd are not comparable, since the users more are aware of their abscence/presence.

    @jimp:

    If an admin leaves their rules wide open there are things even worse than DNS that could be exposed depending on their config. People get

    You are not proving your point by repeating it. Rules are secondary. Securing services is primary.

    @jimp:

    giant bills all the time because they fail to properly configure their SIP servers and then they get hacked and have to pay thousands of dollars in toll charges. Is the firewall to blame for that? No, the user added the rules. They may not have known what they were doing when they added them, but it's still user error.

    That's exactly the point, but you are contradicting yourself. In your example users should secure their vulnerable SIP servers by firewalling rules?

    @jimp:

    I suppose we'll have to agree to disagree on this one.

    I agree, that you got the point, but keep ignoring the consquences.


  • Rebel Alliance Global Moderator

    "Not doing this means that a line of defence is missing. Please attend a course in computer security."

    Dude your really starting to go off the deep end here.

    Keep in mind the wide audience of this product.  Best practice would be to not have any internal services listening on any interface!  That would be best practice for a firewall..  That is clearly not a nice startup method for the less experienced users out there that are using pfsense as their home router, etc.

    The admin should have to start every service he wants to start, and sure pick which interface that service even listens on - and then yes open the correct firewall rules to allow said access to service from where he wants it to be access from.

    This really can be a PITA - and would scare away many many users of this product.  You answer a couple of questions and shazam you have a Nat router firewall up and running!  Its really sweet if you ask me.

    And your bitching that a service listens on a port that is blocked by the firewall??  Come on dude your making a bit much out of it are you not.

    As stated, a default install of pfsense has NO PORTS open on the wan!  NONE..  The admin/user would have to open said port to be open to your dns amplification attack – yes anyone working with firewalls would know what such an attack is.

    I really don't see the concern your seeing - since any admin/user that brings up a new system and does not look to see what ports are open/listening shouldn't be bringing up new systems connected to the public internet in the first place.  If you don't verify what is being listened for and what is open on a device that you connect to the public internet you shouldn't be connecting things to the public internet - at least not in any security/admin role that is for damn sure.

    Would it be a more secure setup if it only listened on lan port..  I agree this would be a better setup, feel free to submit the code to do that and I am sure the developers will take a look if can be implemented.

    But you seem to be making more out of than seems normal -- let me guess you got hit with your pants down and now your trying to blame it on pfsense that shouldn't of been listening in the first place type of thing? ;)



  • On a related note, it might be nice to have a page that lists listening ports (and only that) as an alternative to having to run a console command to find out.



  • @johnpoz:

    Keep in mind the wide audience of this product.  Best practice would be to not have any internal services listening on any interface!  That would be best practice for a firewall..  That is clearly not a nice startup method for the less experienced users out there that are using pfsense as their home router, etc.

    What's the use case again?
    On a home router, you definitely won't need dnsmasq to listen on non-internal interfaces.

    @johnpoz:

    […]
    This really can be a PITA - and would scare away many many users of this product.  You answer a couple of questions and shazam you have a Nat router firewall up and running!  Its really sweet if you ask me.

    It is dangerous to hand out a product that can be easily misconfigured - especially without notice.

    @johnpoz:

    And your bitching that a service listens on a port that is blocked by the firewall??  Come on dude your making a bit much out of it are you not.

    It is not blocked as soon as you add an interface, for a subnet with namesservers. But would you expect, that a service open to all even runs on that machine?

    @johnpoz:

    As stated, a default install of pfsense has NO PORTS open on the wan!  NONE..  The admin/user would have to open said port to be open to your dns amplification attack – yes anyone working with firewalls would know what such an attack is.

    Which can easily happen in above example. The point is, you don't expect the service to even listen on that interface or port, but that's the default.
    I regard this behaviour of a service as a strict "must not" for a security related product.

    @johnpoz:

    I really don't see the concern your seeing - since any admin/user that brings up a new system and does not look to see what ports are open/listening shouldn't be bringing up new systems connected to the public internet in the first place.  If you don't verify what is being
    listened for and what is open on a device that you connect to the public internet you shouldn't be connecting things to the public internet - at least not in any security/admin role that is for damn sure.

    That line of argumentation is partly invalid. I agree, that such a system should not be connected to an interconnected network, but that is exactly, what a firewalling distro is being made for. In the context of its purpose, other rules of measurement apply.
    A dns forwarder is surely a useful thing, but it should not run in some kind of - pardon me for deliberately using the wrong term - promiscuous mode.

    @johnpoz:

    Would it be a more secure setup if it only listened on lan port..  I agree this would be a better setup, feel free to submit the code to do that and I am sure the developers will take a look if can be implemented.

    The configuration options are quite simple, I've posted them before. The easiest way to do this, is to add 'bind-interfaces' to the basic config, which prevents the daemon to listen on all interfaces in the first place (otherwise it would listen, but ignore excluded interfaces.)

    The most useful way of implementing this would be, to add a "listen-address" option on the interface configuration page.

    @johnpoz:

    But you seem to be making more out of than seems normal – let me guess you got hit with your pants down and now your trying to blame it on pfsense that shouldn't of been listening in the first place type of thing? ;)

    I keep reviewing some openwrt-based flavour of a mesh routing software and they recently had "their pants down", as your coulourful metaphor. So I am more sensitive to such scenarios. I don't want pfSense, which I regard to be excellent for some use cases, to experience the same or similar. Since this is a BETA, these things are still in time to be repaired. So it is quite the opposite of blaming, it's a well-intentioned warning not to take this flaw over.

    I strongly believe, that this current approach is wrong for the reasons explained before. I would really hope for you guys not to appease to the severity of such configurations. A set of firewall rules is always only one half of the security concept. I am a bit upset, that some of you try to explain to me, that the ruleset alone is sufficent, while bringing up the counter-arguments in the same sentence (e.g. SIP-Server example). Come on, …



  • @Efonne:

    On a related note, it might be nice to have a page that lists listening ports (and only that) as an alternative to having to run a console command to find out.

    This would be appreciated.

    A warning message for those services, that are bound to all interfaces, would be helpful, too, especially for the "home router" use case.



  • @Efonne:

    On a related note, it might be nice to have a page that lists listening ports (and only that) as an alternative to having to run a console command to find out.

    Based on diag_routes.php I once prepared a similar output for the sockstat utility, feel free to use it if you find it useful.

    diag_sockets.php.txt


Locked