I have 2 CentOS servers that are both authoritative DNS for several domains and local resolvers. As configured, they are publicly visible resolvers, which I've known for awhile is not a good thing.
whats the appropriate way of configuring the bind on CentOS 5.current to not allow recursion on queries from the public side, but still allow recursion locally? is it as simple as adding allow-recursion{} with the appropriate private subnets and localhost to named.conf ?
On 3/28/2013 11:11 AM, Jorge Fábregas wrote:
On 03/28/2013 02:05 PM, John R Pierce wrote:
is it as simple as adding allow-recursion{} with the appropriate private subnets and localhost to named.conf ?
Yes. That's basically it.
k, thanks, looks like its working!
Am 28.03.2013 um 19:29 schrieb John R Pierce pierce@hogranch.com:
On 3/28/2013 11:11 AM, Jorge Fábregas wrote:
On 03/28/2013 02:05 PM, John R Pierce wrote: Yes. That's basically it.
k, thanks, looks like its working!
i would suggest to using view clauses to divide such configurations ...
-- LF
Am 29.03.2013 15:13, schrieb Leon Fauster:
i would suggest to using view clauses to divide such configurations ...
I think that's overkill. allow-recursion{} is perfectly sufficient for this purpose. Views are only needed if you want to return different results for the same query from different clients, such as hiding internal addresses from external queriers.
On Thu, 2013-03-28 at 11:29 -0700, John R Pierce wrote:
On 3/28/2013 11:11 AM, Jorge Fábregas wrote:
On 03/28/2013 02:05 PM, John R Pierce wrote:
is it as simple as adding allow-recursion{} with the appropriate private subnets and localhost to named.conf ?
Yes. That's basically it.
k, thanks, looks like its working!
<Disclamer>
I'm one of the original founders of Internet Security Systems, now part of IBM. I was a founder of the ISS X-Force and am still one of their "Senior Wizards" and a senior security researcher. However! I am not speaking for or on behalf or representing ISS or X-Force or IBM... I am writing, personally, as a professional "white hat hacker" and security researcher. This will be a bit of a long soap-box / tub thump.
</Disclaimer>
I love to believe in coincidences and I'm a firm believer in coincidences... But... The timing of your original post leads me to think otherwise. The fact that you say "looks like it's working" tells me that you're seeing something active on your network that makes me believe that this is not a coincidence.
By any chance, might you have been one of the thousands of open resolvers that got caught up in the Spamhaus / Cyberbunker debacle of the last two weeks? Don't bother to answer that and don't worry about it if you were. If you were, you were only one (or a handful) out of thousands who were abused in this attack on Spamhaus. They all (you all) were, in turn, only a small fraction of the tens (or hundreds) of thousands of open resolvers present on the net, so you're actually in good (large) company (unfortunately).
The suggested solution will solve a (BIG) part of the problem. It WILL solve the problem being exploited in the Spamhaus attack, that of abusing open resolvers in attacking others in a DNS resource amplification attack. Unfortunately, it does NOT solve the problem of someone attacking you exploiting your own resolvers against you.
Resource amplification attacks like this utilize spoofed packets (packets spoofed to be "from" the actual target). The amplified payloads are the replies back to the spoofed addresses.
Now, suppose someone has YOU in their crosshairs. They identify your resolvers (not really a major task - especially if you make the mistake of using your authoritative name servers as resolvers as well) and then proceed to spoof packets into your resolvers as if they were coming from your IP addresses. By the time the packets reach your resolvers, they have no way to tell if the source address is legitimate or not, and will match your recursion allow rules. It's the the job of your security perimeter firewalls to filter local vrs foreign packets and on-session vrs unsolicited packets. Consequently, your resolvers will amplify that traffic (factor of 100 or more) and reflect it back to your internal network.
It's actually amusing how attackers can abuse the very nature of the DNS for this. They prime an authoritative name server with a MASSIVE payload and then spoof the first request into the target resolver for that resource. The resolver then caches it and then subsequent requests are served out of the resolver's cache and doesn't load down the attacker's name servers further. So, he can then hit you with hundreds of thousands of spoofed requests delivering GB of data at his intended target (possibly you) having only serviced a single query request for a few K. Gotta love that for efficiency.
Years ago, I actually had a customer (a major multinational corporation who shall remain unnamed) come under such an attack and was crying for help. Restricting your resolvers to "local networks" does not help in this case. They had an exposed resolver, outside of their firewall perimeter, and the attacker was spoofing packets from their internal addresses. Even if your firewall blocks those responses (stateful firewall) it still overloads your pipe in front of the firewall. It was crushing them with no way to filter it.
Let me make this clear. Any recursive name server, restricted or not, which can be reached from the greater Internet can be abused to attack the networks for which it is configured to allow recursion. The restrictions limit what can be attacked. Without firewalling an external filtering, it does not restrict where you can be attacked from, since it's a spoofed attack in the first place.
Years before, I had published a series of articles for our customers on "Robust DNS Deloyments". One of the recommendations was to NOT have your authoritative name servers be recursive name servers at all (except for localhost). That was their only solution. They had to scramble and shut down those external recursive resolvers entirely and switch to internal ones protected behind their firewalls that could block the spoofed packets.
The argument goes at this...
Your authoritative name servers (at least some of them) must be public. That's their nature, to publicly advertise your domain name information (exception here is that I recommend the master name server be private and all your public name servers be slaves off the private master - but that's a deeper story). That implies that outside, foreign, addresses must be able to communicate with your public authoritative name servers. Foreign addresses must be able to initiate queries with your authoritative name servers in order to ask for the information they are advertising.
Not so with your resolvers. Your resolvers initiate communications with other name servers but no foreign name server should ever initiate a communication with your resolver (it's not authoritative for anything). Your resolvers should be maintained behind firewalls that can, in turn, maintain a knowledge of what constitutes "local" addresses on one side and "foreign" addresses on the other side. Firewall rules then prevent packets from the foreign side spoofed to look like they came from addresses on the local side. THAT prevents anyone from abusing your resolvers to attack both others and you.
The net (excuse the pun) gist of it is that resolvers and authoritative name servers provide their services in different security zones and should not be mixed on the same server. As easy as it is to provide both services on the same name servers, it is not best common practice to do so. Provide those services in their respective zones on separate systems, appropriately protected and locked down.
If you absolutely MUST combine them (and I would love to hear the rational as to why, beyond cost and laziness) then, by all means, restrict recursion to your local networks, with the understanding that they can still be abused to attack yourself..
I don't know where you are in the Internet "food chain" (end consumer, ISP, Tier 1 provider, or backbone) but if you are in the routing chain (you manage or provide routing - anyone other than an end consumer) then it's also very important to implement BCP (Best Common Practice) 38. BCP 38 recommends router egress filtering. That is, you only route out what will route back in. That prevents you (or any of your customers) from being a spoofing source. That strikes at the heart of many of these types of attacks.
With Linux systems acting as routers, that's actually pretty easy and is (last time I looked) enabled by default. On Linux, this is the "route verification" option. With route verification enabled on Linux, it will not send a packet on an interface if the source address would ALSO be routed out through the same interface (i.e. spoofed). "Triangular routing" (not uncommon with some VPNs) is an exception to this and should be a very rare exception and treated as a strict exception. This can get real complicated and difficult if you are running BGP (Border Gateway Protocol) on overtaxed gateway routers but still should be implemented if at all possible.
Routing issues and BCP38 aside, you really should separate your authoritative an recursive name servers if at all possible.
https://isc.sans.edu/diary/Where+Were+You+During+the+Great+DDoS +Cybergeddon+of+2013+/15496
http://news.cnet.com/8301-1009_3-57576947-83/how-the-spamhaus-ddos-attack-co...
http://tools.ietf.org/html/bcp38
-- john r pierce 37N 122W somewhere on the middle of the left coast
Regards, Mike
On Mon, Apr 1, 2013 at 8:11 AM, Michael H. Warfield mhw@wittsend.com wrote:
It's the the job of your security perimeter firewalls to filter local vrs foreign packets and on-session vrs unsolicited packets.
You say that as though everyone has such tools. Or that they are such an integrated part of the TCP/IP standards that applications can simply assume that it is someone else's problem... But I don't think that is generally true - or that the concept even makes sense in the context of the redundant routing TCP/IP is clearly designed to handle. You might instead say that people are forced to add specialized tools like that by stupid applications that are easy to exploit if you don't...
If you absolutely MUST combine them (and I would love to hear the rational as to why, beyond cost and laziness) then, by all means, restrict recursion to your local networks, with the understanding that they can still be abused to attack yourself..
The rationale is that the applications were written that way. Put the blame on the design where it belongs. And talk about it in terms of people later being essentially forced to deal with the fallout from the design by having to change the buried IP address configurations that the DNS system was supposed to avoid having to do in the first place.
I don't know where you are in the Internet "food chain" (end consumer, ISP, Tier 1 provider, or backbone) but if you are in the routing chain (you manage or provide routing - anyone other than an end consumer) then it's also very important to implement BCP (Best Common Practice) 38. BCP 38 recommends router egress filtering. That is, you only route out what will route back in. That prevents you (or any of your customers) from being a spoofing source. That strikes at the heart of many of these types of attacks.
So, what tools do that in combination with dynamic routing protocols? And with asymmetric routes?
Routing issues and BCP38 aside, you really should separate your authoritative an recursive name servers if at all possible.
I don't disagree with that, but I look as a workaround to fix an initial bad design and wouldn't call the people who haven't accomplished it yet lazy.
On 4/1/2013 6:11 AM, Michael H. Warfield wrote:
it's also very important to implement BCP (Best Common Practice) 38. BCP 38 recommends router egress filtering. That is, you only route out what will route back in. That prevents you (or any of your customers) from being a spoofing source.
of course, this breaks a bunch of types of ad-hoc multihoming, where you have multiple ISPs, each with their own subnets, and you're trying to load balance your outbound traffic.
On Mon, 2013-04-01 at 11:17 -0700, John R Pierce wrote:
On 4/1/2013 6:11 AM, Michael H. Warfield wrote:
it's also very important to implement BCP (Best Common Practice) 38. BCP 38 recommends router egress filtering. That is, you only route out what will route back in. That prevents you (or any of your customers) from being a spoofing source.
of course, this breaks a bunch of types of ad-hoc multihoming, where you have multiple ISPs, each with their own subnets, and you're trying to load balance your outbound traffic.
It doesn't have to and it's just as easy to argue that stateful firewalls also break such configurations (they do). It is possible to interface your load leveling and dynamic routing into your filter if it's done properly. The point there is that you have to do it properly up front. Once it's done, it should require little maintenance. Unfortunately, if you have to go back into an established architecture and retrofit one in, that can be a difficult and time consuming prospect, especially if you didn't design the network to begin with.
If you're dealing with multihoming and multiple ISPs then you should be talking BGP (or IS-IS) to your ISPs (I have my own ASN and advertise my own routes on IPv4 and IPv6 but you can use private ASNs and many ISPs will cooperate if you have the address space to advertise) and it should all be integrated.
If you are trying to do ad-hoc mutihoming without using BGP or IS-IS to manage the routing to your ISPs, then I have no sympathy for you. That's just inviting a never ending stream of self-inflicted trouble and grief when routing breaks (been there, done that, not pretty). Being abused for DNS amplification attacks is the least of your problems then. Once we had multiple connections to the same ISP (redundant fiber links running in different directions out the street outside of our building) we were running BGP to manage it.
But I also understand that in many large organizations (particularly ones who are NOT ISPs and their primary business is not networking) much of the IT staff is even more terrified of BGP than they are DNS and probably for good reasons.
That's a statement from personal experience. Years ago, I asked for a "read-only BGP" feed from our IT department way back then (10 or 15 years ago) and got a "not no - hell no - are you insane?" answer. Their reasoning was that they trusted me (as if they had a choice) but they didn't trust all of their mainline minions (err, staff) to stick their fingers in those routers. BGP is so critical to those who rely on it (especially if you are multihomed) that, if someone makes even a minor mistake, it can disasterously disconnect you from the net or worse. Unfortunately, even worse than DNS, once it's working people (management) want you to LEAVE IT ALONE lest you beak it. So, most IT people are even less familiar with BGP than DNS and plenty are scared shitless about breaking DNS.
DNS itself can be just as bad. Simple mistakes can be amplified and obfuscated. Just ask Microsoft. They got dropped off the net for days several years ago after someone misconfigured a firewall so their slaves couldn't talk to their master and the TTL (Time To Live) expired several hours after the guilty party was off duty and had gone home. On top of that, they had all their public name servers on the same subnet (violation of several BCPs going back decades) compounding the problem AND opening them up to a DOS against the router leading into that subnet.
We (IETF, IEEE, ACM, etc al) can publish and update BCPs but it doesn't mean people will follow them. It does mean that we can say "we told you not to do that..." after it breaks. You pays your nickel and you takes your chance. :-/
-- john r pierce 37N 122W somewhere on the middle of the left coast
Regards, Mike
-
John R Pierce -
Jorge Fábregas -
Leon Fauster -
Les Mikesell -
Michael H. Warfield -
Tilman Schmidt