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
