Re: Same source port queries dropped by ServerIron load balancer
On 4/4/2010 2:24 PM, Sten Carlsen wrote: On 04/04/10 17:41, Kevin Darcy wrote: On 4/1/2010 9:19 PM, Barry Margolin wrote: In articlemailman.1048.1270148466.21153.bind-us...@lists.isc.org, Kevin Darcyk...@chrysler.com wrote: Re-use of source ports for DNS queries is a bad security practice. I cast my vote in favor of penalizing it, in the default configuration of any device that responds to DNS requests. It's really not the job of a load balancer or server to force clients to use good security practices. Trouble is, when everyone carves out their little area of responsibility such that enforcing good security practices is not my job, man, then very few things enforce security practices, and ultimately they don't get enforced at all. Certainly a load-balancer can legitimately refuse to serve queries that are suspect, can it not? E.g. that are malformed in particular ways that indicate hostile intent. So, where in the spectrum of suspectness can we draw the line and say, everything on that side, I trust to answer, and everything on the other side of the line, I don't? I think a client that re-uses source ports is untrustworthy. Therefore I think it's a reasonable default to decline to service queries from such clients. The question I saw being raised was not if such queries wer trustworthy or not; but whether it is the job of a load balancer to judge the inner workings of an application protocol. Sorry, pet peeve, but DNS is an application protocol like paddles on a rowboat are merely ornamental trappings. Sure, one _could_ theoretically get along with it/them, but how realistic is that? In practical terms, DNS is a core networking protocol, necessary for most process-to-process communcation at the Transport Layer and above. That's how it's treated by support organizations, too: does one ever see DNS lumped in with applications from a support standpoint? I tend to agree that the load balancer should just hand the packets on to whoever is there to answer the questions/serve the content. It wasn't clear (to me, at least) from the original post whether the load-balancer in question was just front-ending some DNS service, or whether it was a GSLB-type load-balancer that was actually the definitive source of the (dynamically-changing) DNS information, front-ending some other protocol(s), e.g. HTTP/HTTPS, SMTP, LDAP. If it's a GSLB device that is the last link-in-the-chain, then certainly it has the right to enforce whatever security policies the owner/administrator wants. If on the other hand it's just forwarding the query to some back-end DNS infrastructure, and if it can provide the information necessary for the back-end infrastructure to make a reasonable security determination (i.e. using the client's original source port), then fine, pass on the responsibility for enforcement. If not, then the load-balancer needs to do the enforcement itself. This would be the reason we have heard so much about broken routers/bridges/firewalls/... that will not allow EDNS packets, because they were once suspect. Routers/bridges/firewalls, etc. that should, in the normal case, be passing packets back and forth without presuming special knowledge of the DNS protocol, should be lumped together with load-balancers that front-end a DNS infrastructure. But, again, if we're talking about a load-balancer that is a GSLB *definitive* source of the DNS data, then it is in a different class than transparent or proxying devices. It is, in effect, the *source* of the DNS information, and shouldn't be giving out data to clients it suspects may misuse that data or be compromised by the response. When DNSSEC/NSEC/... is completely implemented, who will then reevaluate if this load balancer is in need of a change? maybe there will be nobody to fix it? I think that's part of the larger question of how all of these Stupid DNS Tricks that people are today performing with load-balancers, CDNs, etc. will inter-operate with DNSSEC, if at all. The Stupid DNS Tricks, after all, do essentially amount to *lying* about DNS data, and DNSSEC is essentially a mechanism for detecting, and presumably rejecting, DNS lies. It's hard to get such things to co-exist. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Same source port queries dropped by ServerIron load balancer
On 4/4/2010 3:33 PM, Barry Margolin wrote: In articlemailman.1058.1270395730.21153.bind-us...@lists.isc.org, Kevin Darcyk...@chrysler.com wrote: On 4/1/2010 9:19 PM, Barry Margolin wrote: In articlemailman.1048.1270148466.21153.bind-us...@lists.isc.org, Kevin Darcyk...@chrysler.com wrote: Re-use of source ports for DNS queries is a bad security practice. I cast my vote in favor of penalizing it, in the default configuration of any device that responds to DNS requests. It's really not the job of a load balancer or server to force clients to use good security practices. Trouble is, when everyone carves out their little area of responsibility such that enforcing good security practices is not my job, man, then very few things enforce security practices, and ultimately they don't get enforced at all. There's a well-defined place where security is supposed to be enforced: the firewall. I suppose the device in question may be a combination firewall and load balancer. There's a difference between the product category firewall and the actual *role* firewall (which I believe is classically defined as a device which applies policy-based security controls.to network traffic flowiing between entities at differing levels of trust, or similar wording). Just because a load-balancer (according to product category) may not be labelled as a firewall on its front panel plate, or in a diagram of the network topology, doesn't mean it can't or shouldn't be serving that role in the network/security infrastructure. As for the singular a well-defined place, there's nothing wrong with having multiple levels of security and security enforcement, or multiple levels of firewalls (the role not the product category) in the environment. http://en.wikipedia.org/wiki/Defense_in_depth_(computing) But a firewall in front of a server should be protecting the server, not protecting the clients from themselves. Preventing any complicity in the poisoning of a client's cache is certainly a legitimate security policy objective, is it not? Certainly a load-balancer can legitimately refuse to serve queries that are suspect, can it not? E.g. that are malformed in particular ways that indicate hostile intent. So, where in the spectrum of suspectness can we draw the line and say, everything on that side, I trust to answer, and everything on the other side of the line, I don't? I think a client that re-uses source ports is untrustworthy. Therefore I think it's a reasonable default to decline to service queries from such clients. Since when does a DNS server need to trust the client? The server just answers questions, it doesn't incorporate any information from the client (except for dynamic DNS updates, but these are almost always clients inside the security perimiter). I'm not sure exactly what point you're trying to make. If DNS servers never need to trust their resolving clients, then why does BIND have multiple ways of identifying clients (either source address/range or TSIG key), which then can be used in any of the allow- stuff (-transfer, -query, -query-cache, -recursion), or by match-clients as a basis for view selection, and so forth? - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Same source port queries dropped by ServerIron load balancer
In article mailman.1074.1270505464.21153.bind-us...@lists.isc.org, Kevin Darcy k...@chrysler.com wrote: On 4/4/2010 3:33 PM, Barry Margolin wrote: In articlemailman.1058.1270395730.21153.bind-us...@lists.isc.org, Kevin Darcyk...@chrysler.com wrote: On 4/1/2010 9:19 PM, Barry Margolin wrote: In articlemailman.1048.1270148466.21153.bind-us...@lists.isc.org, Kevin Darcyk...@chrysler.com wrote: Re-use of source ports for DNS queries is a bad security practice. I cast my vote in favor of penalizing it, in the default configuration of any device that responds to DNS requests. It's really not the job of a load balancer or server to force clients to use good security practices. Trouble is, when everyone carves out their little area of responsibility such that enforcing good security practices is not my job, man, then very few things enforce security practices, and ultimately they don't get enforced at all. There's a well-defined place where security is supposed to be enforced: the firewall. I suppose the device in question may be a combination firewall and load balancer. There's a difference between the product category firewall and the actual *role* firewall (which I believe is classically defined as a device which applies policy-based security controls.to network traffic flowiing between entities at differing levels of trust, or similar wording). Just because a load-balancer (according to product category) may not be labelled as a firewall on its front panel plate, or in a diagram of the network topology, doesn't mean it can't or shouldn't be serving that role in the network/security infrastructure. As for the singular a well-defined place, there's nothing wrong with having multiple levels of security and security enforcement, or multiple levels of firewalls (the role not the product category) in the environment. http://en.wikipedia.org/wiki/Defense_in_depth_(computing) But a firewall in front of a server should be protecting the server, not protecting the clients from themselves. Preventing any complicity in the poisoning of a client's cache is certainly a legitimate security policy objective, is it not? I think there's a difference between complicity and forcing the client to protect itself. Especially since end users typically can't fix the problem themselves (they're usually using caching servers operated by someone else -- their ISP or their corporate IT Dept.). So if someone gets blocked by this, what are they supposed to do about it? Even if they can change DNS servers (e.g. switch to OpenDNS or Google DNS), it wouldn't be obvious that the problem is one that would be solved by this. Certainly a load-balancer can legitimately refuse to serve queries that are suspect, can it not? E.g. that are malformed in particular ways that indicate hostile intent. So, where in the spectrum of suspectness can we draw the line and say, everything on that side, I trust to answer, and everything on the other side of the line, I don't? I think a client that re-uses source ports is untrustworthy. Therefore I think it's a reasonable default to decline to service queries from such clients. Since when does a DNS server need to trust the client? The server just answers questions, it doesn't incorporate any information from the client (except for dynamic DNS updates, but these are almost always clients inside the security perimiter). I'm not sure exactly what point you're trying to make. If DNS servers never need to trust their resolving clients, then why does BIND have multiple ways of identifying clients (either source address/range or TSIG key), which then can be used in any of the allow- stuff (-transfer, -query, -query-cache, -recursion), or by match-clients as a basis for view selection, and so forth? All the allow-XXX stuff is for privacy, not trust. And the multiple methods of identifying the client are to work around limitations in TCP/IP (source addresses can be spoofed) and deal with different networking environments. For instance, TSIG key is often useful when you need to transfer two different views to the same slave server, so that it can also serve both views; you can't use match-address because they're the same address. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Same source port queries dropped by ServerIron load balancer
On 4/1/2010 9:19 PM, Barry Margolin wrote: In articlemailman.1048.1270148466.21153.bind-us...@lists.isc.org, Kevin Darcyk...@chrysler.com wrote: Re-use of source ports for DNS queries is a bad security practice. I cast my vote in favor of penalizing it, in the default configuration of any device that responds to DNS requests. It's really not the job of a load balancer or server to force clients to use good security practices. Trouble is, when everyone carves out their little area of responsibility such that enforcing good security practices is not my job, man, then very few things enforce security practices, and ultimately they don't get enforced at all. Certainly a load-balancer can legitimately refuse to serve queries that are suspect, can it not? E.g. that are malformed in particular ways that indicate hostile intent. So, where in the spectrum of suspectness can we draw the line and say, everything on that side, I trust to answer, and everything on the other side of the line, I don't? I think a client that re-uses source ports is untrustworthy. Therefore I think it's a reasonable default to decline to service queries from such clients. I realize that such a default setting may not be very popular. A lot of, er, unsophisticated customers for such devices may not realize or understand the default setting and then may have a tough time understanding why they have difficulty serving DNS to certain clients. But this is a matter of notification/documentation and education. The manual should have in big red letters IF YOU WANT TO SUPPORT CERTAIN LEGACY CLIENTS THAT DO NOT CONFORM TO BEST CURRENT SECURITY PRACTICES, YOU NEED TO CHANGE THE DEFAULT SETTING. At least then, the customer is made aware of the insecurity that they are enabling by changing the setting. This may also be a factor if there is ever any question about legal liability in the case of a security event. I suspect this is actually a bug, but the vendor is using the security value of it as an excuse to lower its priority. That may also be true, if I were dealing with the vendor I'd point out that if it is a deliberate security design, it should only be a default and there *must* be a way to turn it off. I can think of lots of internal environments where the clients and servers, and their interaction is considered secure, but there is a re-use -- or apparent re-use -- of source ports, and in those particular cases the load-balancer shouldn't be refusing service. If there is no way to turn off this security feature, then it should be possible to embarrass the vendor into admitting that it's really a bug rather than a designed-in feature. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Same source port queries dropped by ServerIron load balancer
On 04/04/10 17:41, Kevin Darcy wrote: On 4/1/2010 9:19 PM, Barry Margolin wrote: In articlemailman.1048.1270148466.21153.bind-us...@lists.isc.org, Kevin Darcyk...@chrysler.com wrote: Re-use of source ports for DNS queries is a bad security practice. I cast my vote in favor of penalizing it, in the default configuration of any device that responds to DNS requests. It's really not the job of a load balancer or server to force clients to use good security practices. Trouble is, when everyone carves out their little area of responsibility such that enforcing good security practices is not my job, man, then very few things enforce security practices, and ultimately they don't get enforced at all. Certainly a load-balancer can legitimately refuse to serve queries that are suspect, can it not? E.g. that are malformed in particular ways that indicate hostile intent. So, where in the spectrum of suspectness can we draw the line and say, everything on that side, I trust to answer, and everything on the other side of the line, I don't? I think a client that re-uses source ports is untrustworthy. Therefore I think it's a reasonable default to decline to service queries from such clients. The question I saw being raised was not if such queries wer trustworthy or not; but whether it is the job of a load balancer to judge the inner workings of an application protocol. I tend to agree that the load balancer should just hand the packets on to whoever is there to answer the questions/serve the content. This would be the reason we have heard so much about broken routers/bridges/firewalls/... that will not allow EDNS packets, because they were once suspect. When DNSSEC/NSEC/... is completely implemented, who will then reevaluate if this load balancer is in need of a change? maybe there will be nobody to fix it? Let each part of the system do the job it was put there to do and not try to do what it does not really understand how to do in the long run. Otherwise you ask for trouble for your successor. I realize that such a default setting may not be very popular. A lot of, er, unsophisticated customers for such devices may not realize or understand the default setting and then may have a tough time understanding why they have difficulty serving DNS to certain clients. But this is a matter of notification/documentation and education. The manual should have in big red letters IF YOU WANT TO SUPPORT CERTAIN LEGACY CLIENTS THAT DO NOT CONFORM TO BEST CURRENT SECURITY PRACTICES, YOU NEED TO CHANGE THE DEFAULT SETTING. At least then, the customer is made aware of the insecurity that they are enabling by changing the setting. This may also be a factor if there is ever any question about legal liability in the case of a security event. I suspect this is actually a bug, but the vendor is using the security value of it as an excuse to lower its priority. That may also be true, if I were dealing with the vendor I'd point out that if it is a deliberate security design, it should only be a default and there *must* be a way to turn it off. I can think of lots of internal environments where the clients and servers, and their interaction is considered secure, but there is a re-use -- or apparent re-use -- of source ports, and in those particular cases the load-balancer shouldn't be refusing service. If there is no way to turn off this security feature, then it should be possible to embarrass the vendor into admitting that it's really a bug rather than a designed-in feature. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Best regards Sten Carlsen No improvements come from shouting: MALE BOVINE MANURE!!! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Same source port queries dropped by ServerIron load balancer
In message 4bb8b33b.4070...@chrysler.com, Kevin Darcy writes: On 4/1/2010 9:19 PM, Barry Margolin wrote: In articlemailman.1048.1270148466.21153.bind-us...@lists.isc.org, Kevin Darcyk...@chrysler.com wrote: Re-use of source ports for DNS queries is a bad security practice. I cast my vote in favor of penalizing it, in the default configuration of any device that responds to DNS requests. It's really not the job of a load balancer or server to force clients to use good security practices. Trouble is, when everyone carves out their little area of responsibility such that enforcing good security practices is not my job, man, then very few things enforce security practices, and ultimately they don't get enforced at all. Certainly a load-balancer can legitimately refuse to serve queries that are suspect, can it not? Suspect of what? I could be using SIG(0) or TSIG or IPSEC or 0x20 or ... to secure the queries. It's not the load balancer's job to ensure that client can't be spoofed. I could be just be asking lots of questions and have re-used the source port. As a client I just need to keep the qid unique for any outstand queries to this server from this port. E.g. that are malformed in particular ways that indicate hostile intent. So, where in the spectrum of suspectness can we draw the line and say, everything on that side, I trust to answer, and everything on the other side of the line, I don't? I think a client that re-uses source ports is untrustworthy. Therefore I think it's a reasonable default to decline to service queries from such clients. A client that re-uses source ports is 100% normal. It may not be up to current best practice but there is nothing abnormal about it. I realize that such a default setting may not be very popular. A lot of, er, unsophisticated customers for such devices may not realize or understand the default setting and then may have a tough time understanding why they have difficulty serving DNS to certain clients. But this is a matter of notification/documentation and education. The manual should have in big red letters IF YOU WANT TO SUPPORT CERTAIN LEGACY CLIENTS THAT DO NOT CONFORM TO BEST CURRENT SECURITY PRACTICES, YOU NEED TO CHANGE THE DEFAULT SETTING. At least then, the customer is made aware of the insecurity that they are enabling by changing the setting. This may also be a factor if there is ever any question about legal liability in the case of a security event. I suspect this is actually a bug, but the vendor is using the security value of it as an excuse to lower its priority. That may also be true, if I were dealing with the vendor I'd point out that if it is a deliberate security design, it should only be a default and there *must* be a way to turn it off. I can think of lots of internal environments where the clients and servers, and their interaction is considered secure, but there is a re-use -- or apparent re-use -- of source ports, and in those particular cases the load-balancer shouldn't be refusing service. If there is no way to turn off this security feature, then it should be possible to embarrass the vendor into admitting that it's really a bug rather than a designed-in feature. - Kevin -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Same source port queries dropped by ServerIron load balancer
On 4/1/2010 12:37 AM, Mark Andrews wrote: In message4bb1c63b.30...@ies.etisalat.ae, Abdulla Bushlaibi writes: We are facing query drops by using dnsperf tool from ISC testing the DNS service via load balancer. Multiple queries from the same source port are being dropped partially by the load balancer and as per the load balancer vendor feed back, this is a security feature and this situation doesn't happen in real life scenarios. Most of the cases, clients are generating unique random source ports for each DNS query, however we are not sure about the option of reusing the same source port for multiple queries and how does it apply in real life scenarios. Appreciate your comment on this subject. -- Abdulla Ahmad Bushlaibi ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users A load balancer that cannot cope with multiple outstanding queries that have the same source port is broken. A server (and that includes any load balancer in front of it) should not care about the source port. Re-use of source ports for DNS queries is a bad security practice. I cast my vote in favor of penalizing it, in the default configuration of any device that responds to DNS requests. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Same source port queries dropped by ServerIron load balancer
On 3/30/2010 5:36 AM, Abdulla Bushlaibi wrote: We are facing query drops by using dnsperf tool from ISC testing the DNS service via load balancer. Multiple queries from the same source port are being dropped partially by the load balancer and as per the load balancer vendor feed back, this is a security feature and this situation doesn't happen in real life scenarios. What do you mean by dropped partially? Is it responding or not? - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Same source port queries dropped by ServerIron load balancer
In message 4bb4ed5a.20...@chrysler.com, Kevin Darcy writes: On 4/1/2010 12:37 AM, Mark Andrews wrote: In message4bb1c63b.30...@ies.etisalat.ae, Abdulla Bushlaibi writes: We are facing query drops by using dnsperf tool from ISC testing the DNS service via load balancer. Multiple queries from the same source port are being dropped partially by the load balancer and as per the load balancer vendor feed back, this is a security feature and this situation doesn't happen in real life scenarios. Most of the cases, clients are generating unique random source ports for each DNS query, however we are not sure about the option of reusing the same source port for multiple queries and how does it apply in real life scenarios. Appreciate your comment on this subject. -- Abdulla Ahmad Bushlaibi ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users A load balancer that cannot cope with multiple outstanding queries that have the same source port is broken. A server (and that includes any load balancer in front of it) should not care about the source port. It's only bad practice if you are not using other methods to prevent spoofing attacks succeeding. A load balance should work with all traffic paterns. Re-use of source ports for DNS queries is a bad security practice. I cast my vote in favor of penalizing it, in the default configuration of any device that responds to DNS requests. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Same source port queries dropped by ServerIron load balancer
In article mailman.1048.1270148466.21153.bind-us...@lists.isc.org, Kevin Darcy k...@chrysler.com wrote: Re-use of source ports for DNS queries is a bad security practice. I cast my vote in favor of penalizing it, in the default configuration of any device that responds to DNS requests. It's really not the job of a load balancer or server to force clients to use good security practices. I suspect this is actually a bug, but the vendor is using the security value of it as an excuse to lower its priority. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Same source port queries dropped by ServerIron load balancer
The tool queryperf is a useful tool and it gives you details about a DNS server performance. However, it would be useful to have an option in queryperf to use random source ports to test real life scenarios. -- Abdulla Ahmad Bushlaibi On 3/31/2010 12:07 AM, Kevin Darcy wrote: On 3/30/2010 8:00 AM, Tony Finch wrote: On Tue, 30 Mar 2010, Abdulla Bushlaibi wrote: We are facing query drops by using dnsperf tool from ISC testing the DNS service via load balancer. Multiple queries from the same source port are being dropped partially by the load balancer and as per the load balancer vendor feed back, this is a security feature and this situation doesn't happen in real life scenarios. High performance stub resolvers like adns use the same UDP port for many queries. Thus reducing entropy and commensurately increasing the chance of accepting a spoofed response as genuine. I think the load-balancer vendor has the right default here, and adns should re-think their methodology. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Same source port queries dropped by ServerIron load balancer
On Tue, 30 Mar 2010, Abdulla Bushlaibi wrote: We are facing query drops by using dnsperf tool from ISC testing the DNS service via load balancer. Multiple queries from the same source port are being dropped partially by the load balancer and as per the load balancer vendor feed back, this is a security feature and this situation doesn't happen in real life scenarios. High performance stub resolvers like adns use the same UDP port for many queries. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Same source port queries dropped by ServerIron load balancer
On 3/30/2010 8:00 AM, Tony Finch wrote: On Tue, 30 Mar 2010, Abdulla Bushlaibi wrote: We are facing query drops by using dnsperf tool from ISC testing the DNS service via load balancer. Multiple queries from the same source port are being dropped partially by the load balancer and as per the load balancer vendor feed back, this is a security feature and this situation doesn't happen in real life scenarios. High performance stub resolvers like adns use the same UDP port for many queries. Thus reducing entropy and commensurately increasing the chance of accepting a spoofed response as genuine. I think the load-balancer vendor has the right default here, and adns should re-think their methodology. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
