Dnsmasq is always recursive on default install

podilarius

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.

phil.davis

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?

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.

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.

epek

@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.

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.

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

epek

@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.

johnpoz

"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? ;)

Efonnes

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.

epek

@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, …

epek

@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.

bardelot

@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