by Anonymous Coward writes:
on Sunday August 01, 2004 @08:01AM (#9857157)
An interesting property of DNS is that there are servers all over the net which will happily relay your message. Even if your only connection to the net is through application level proxies, you probably have a local DNS resolver. That's all you need. No packet has to traverse the firewall directly.
They may have used spoofed DNS packets just to bypass a firewall, but information can also be tunneled in real DNS packets, so even if you only allow DNS to/from certain servers, you're still not safe from this leak.
They may have used spoofed DNS packets just to bypass a firewall, but information can also be tunneled in real DNS packets, so even if you only allow DNS to/from certain servers, you're still not safe from this leak.
Yup, and that's not the half of it. With the extensions being duct-taped onto the existing spec it makes it easier and easier to do this. I've seen some hacks to allow all sorts of arbitrary information to live on the servers, some relayed automatically because of the extensions, some used to modify how mail servers respond, some even for routing. It's nothing new (remember transferring data via ICMP ECHO?) but it's on a new level now.
I cringe when someone proposes bolting their latest P2P or broadcast hack to DNS every week. Willy-nilly adding extensions to working protocols is almost always a bad idea. It's like giving Murphy a free kick.
I hate to feed a troll, but actually copy/paste can be EASIER with a unix desktop (sometimes too easy the single click paste takes a bit to get used to -- I used it for years way back when and was fine but once I started running Windows at work it was a little strange to switch back and forth).
In addition I write this comment on a win2k workstation. It is rather nice to have a clickable link so that in mozilla I can open in a new tab to process later. In other words actually have a hyperlink be clickable
And I've been bitching about SPF using DNS TXT records for longer than that. Don't people firewall their DNS anymore? If your inside a network and your trying to leak info out, DNS is the best way to do it.
Dan is literally *using* DNS to hide his traffic, not just using udp:53.
Even so, this still isn't that interesting. So you mime encode it (or whatever), tack on a domain, and talk to a rogue dns server. Anyone dealing with secure networks should know that having any opening to the internet is a security risk and take that into account when designing one's network.
Recursive lookup support isn't required to achieve incoming connectivity (see induced lookups), and being able to do lookups against the outside world isn't identified by anyone as a risk.
SO... is there any chance of developing a distributed, secure DNS implemenation that is backward-compatable?
Right now, we rely on 13 servers to run DNS, why not 26? Why even have root name servers at all? Could we develop a DNS system ala Usenet, that sends updates both up and down stream... And then just have the ability to slowly or quickly accept new incoming information as true based on various criteria, to avoid having bad information flooding the DNS servers?
This story seems quite similar to a previous one about using DNS for communications, from LayerOne. Incredibly stupid to use for mainstream communications, but perfect for hackers, with low data requirements, anyway.
...Microsoft plans to release a security update to Windows XP which will secure the DNS hack. For all future internet usage, please enter in http://216.239.57.99. It's not a bug, it's a feature.
to somthing called DNS poison [google.com]. Why? Because system administrators are anal and fail to realize that software like BIND is not written to be secure. Hell, DNS was not even designed for such a large internet. The original DNS implementors were bad programmers and designers.
BIND9... don't get your hopes up. The BIND company sells paches for their software. Meaning that if you don't pay them money then you're going to be running an errornouse DNS server.
Still most people use BIND for two reasons: no one wants to learn the crusty details of DNS and 2) Linux comes with BIND as it's default name library.
Alternative like djbdns [cr.yp.to] should be used.
>Until a true open source alternative to BIND appears, we're stuck with it.
By "true alternative" do you mean it has to be GPLable?
Get real. djbdns' source is 100% available for you to look at and patch to your hearts content. If you find an error, send a fix to DJB and he'll add it after review. He'll even give you $500 [cr.yp.to] as a reward for your hard work. Find me a GPL program that makes an offer like that.
Now, if he doesn't like your patch, you can post the patch on the internet. You can even put it alongside the source. You can even make an autopatch program that will patch djbdns during make so that dumb users can handle the process
For the disbelievers, here's [cr.yp.to] the source code.
Here's [cr.yp.to] bernstein's statement about the freedom of his software. Feel free to print it out and sign it if you're insane on the idea he can revoke your license.
That's what people call "shared source". Open Source requires that you can distribute modifications of the source. Bernstein doesn't allow that, so consequentially djbdns is not Open Source. This may or may not make it less valuable to you, but don't lie about the facts to lure others into misevaluating the situation.
Thanks for posting that so I wouldn't have to:) It's sad to see that many people seem to think availability of source code equals Open Source, when the term is clearly defined by the Open Source Initiative. If we tolerate this, Microsoft will have an easy going convincing people that Open Source doesn't matter since they have "Shared Source" already. You have the source, right?
"Now, if he doesn't like your patch, you can post the patch on the internet. You can even put it alongside the source. You can even make an autopatch program that will patch djbdns during make so that dumb users can handle the process"
Can you make binaries of your new program and distribute them? If not, I can't see how you call this open-source. It cuts off all of the distributors from carrying patched versions that work with their own distribution, instead of whatever way that djb wants.
"You would be correct in saying this project is closed-binary. The difference is huge."
Open-source typically means the ability to redistribute modified binaries. Even if it doesn't (which, if you read the open-source definition, it does), the usefulness which most people attribute to open-source is lost. If you can't recombine modified binaries into a distribution of software, how "open" is it?
The open-source definition says that the software must be (a) redistributable in both source and binary forms,
The $500 guantee is worthless. How many hours do you think it takes to audit the djbdns source code? Anything more than 50, and you'd only need to make $10 an hour at your current job to make it a very unprofitable way to spend your time.
(Also: Who judges the "entrants" for the $500 prize? That's right, DJB does, and there are no formal rules as to exactly what qualifies as a security bug).
No, it is worth something. If his software wasn't secure, offering the guarantee would have been an extremely arrogant move. DJB is arguably enough of an asshole that I suspect that there are numerous people who would go out of their way to find security holes in his guaranteed software, just to spite him.
No, it is worth something. If his software wasn't secure, offering the guarantee would have been an extremely arrogant move. Guess what? DJB is extremely arrogant (as many clever people tend to be).
DJB is arguably enough of an asshole that I suspect that there are numerous people who would go out of their way to find security holes in his guaranteed software, just to spite him.
You failed to answer my point about who gets to judge the "entrants" and the rules of the contest.
You failed to answer my point about who gets to judge the "entrants" and the rules of the contest.
It's irrelevent to my contradiction of your statement, "The $500 guantee is worthless."
Look, it's a simple matter of economics: Auditing code is mostly tedious and there are sufficiently many ways of earning much more money (and with a guaranteed payoff!) auditing code that no amount of spite is worth it.
One matter of economics you're not considering is that value and worth are not equivalent to monetary
Incorrect, it is open source. It isn't GPL. There's a big difference.
Yes, but the trolls [trollse.cx] have redubbed anything to which you can read the code "Open Source." It confuses the argument, but it makes PHB's feel better about using software not developed by a money-grubbing company (the kind they were taught to like while they were earning their MBAs).
DJB's software is Open Source. It is free-as-in-beer, not free-as-in-speech, perhaps. That said, just because something is Free Software does not make it sup
You miss my point -- the whole "Open Source" movement clouds the definitions. OSI embraced the original APSL, which in many ways was more restrictive than the DJB licenses.
There are many things that are open source and not free. DJB's stuff. Quite a bit of UW mail software, etc. etc. You can't distribute a patched version of pine, either, without UW's permission.
OSI obfuscates these issue because the trolls don't get along with RMS.
You miss my point -- the whole "Open Source" movement clouds the definitions. OSI embraced the original APSL, which in many ways was more restrictive than the DJB licenses.
There are many things that are open source and not free. DJB's stuff. Quite a bit of UW mail software, etc. etc. You can't distribute a patched version of pine, either, without UW's permission.
OSI obfuscates these issue because the trolls don't get along with RMS.
Actually, the definition of "open source" used by OSI (launched
the parent post that started this all was quick frankly trolling. bind9 was a complete rewrite from the ground up. I don't recall the last time I had an exploit in bind9. I have had multiple openssl and openssh vulnerabilities in the past year however.
So as I have told many people, every network app is going to have its issues. Some have more than others, but with proper patch management (and despite the original posters claim, you don't have to pay for BIND patches) you can keep your network secure.
Incorrect, it is not open source. You cannot distribute modified versions. And 'modified versions' in his case means so much as having the binaries installed in a different location than they would be by building and installing his source distribution... among other things. You can only redistribute a djbdns package if the effects of installing your package on a system are exactly the same as the effects of installing his official source distribution.
Incorrect, it is open source.
It isn't GPL.
There's a big difference.
Yes, there is a big difference, and djbdns is not Open Source. It violates points #3 and #4 of the Open Source Definition [opensource.org]. (It also doesn't comply with the DFSG [debian.org] which is why Debian has it in non-free.)
I quote:
3. Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
Get real. djbdns' source is 100% available for you to look at and patch to your hearts content. If you find an error, send a fix to DJB and he'll add it after review.
"Available Source" !== "Free Software".
You can't redistribute changed, patched DJBDNS. You can't fork it if you figure something requires a fundamental change in design philosophy. You cannot distribute binaries. DJB release a new version every millenium or so - so when you set up Qmail or DJBDNS, you spend a week applying patches and testi
Open source doesn't just mean access to the source code.
Note that opensource.org invented the term "open source" - it was not in use to describe software until they had that meeting where they invented the term - so they certainly get to say what it means.
Until a true open source alternative to BIND appears, we're stuck with it.
By "true alternative" do you mean it has to be GPLable?
Not necessarily. Being distributable wouln't hurt, though.
Being compatible with the DNS standard would also be a plus.
Don't get me wrong, I am all for alternatives to BIND, but djbdns cannot even be distributed as a simple rpm or deb package not messing the whole bloody filesystem, for God's sake.
If you want a name server with such a strong emphasis on security
The $500 security guarantee is utterly irrelevant. (Btw: Who gets to judge what is a security problem? That's right, DJB himself. If that doesn't tell you something, then you're not the sharpest tool in the shed).
The $500 correpsonds to less than 50 hours at $10 an hour (being extremely generous with the hourly wages here, in favour of the "gaurantee"). Do you think anyone can audit the djbdns source code -- even ignoring the fact that it's largely uncommented and messy (#define, what's that?) -- in 50 hours? No, I didn't think so.
BIND is open source, but that doesn't make it safe and secure. it's probobly more insecure just because of that.
BIND may be Open Source (note capitalization) while djbdns isn't. That doesn't mean you can't get source for djbdns. In fact it's probably easier to get source than binaries for djbdns because of the unbelievably stupid djbdns license.
So they are both equally "insecure" from that perspective.
The $500 security guarantee is utterly irrelevant.
I not only have seen script kiddies trading private exploits for sums at least an order of magnitude greater than that, but they were selling it to multiple buyers. I am talking about script kiddies, not professionals, mind you. Even $100,000 would be laughable. $1,000,000 might start looking interesting for people not willing to make any serious usage (industrial espionage, etc.) of their exploits. But $500? Please don't mind if I die laughing. See
$100,000 is probably more money than djb makes in a year. If he offered to sacrifice a year's salary to someone who found a security flaw in software he wrote in his spare time and gives away for free, I would hardly call that laughable.
Daniel Bernstein's salary is completely irrelevant. $500 is not any less miserable (or laughable, for that matter) if it is given by someone who is poor.
Note also that Schneier's essay is pretty much irrelevant to this situation.
I interpreted the reply as being to the bind8 portion of the post. As would anyone who had heard of the vulnerability being pointed out (and as would those who hadn't heard of it but read the linked page).
this [cr.yp.to] page, problems remained up until (at least) BIND 8.2.2-P5. Pretty sad since this attack has been known for ages (especially since it's so easy to prevent).
No doubt you'll be on +5 informative soon for this 15 year old information.
BIND hasn't been vulnerable to DNS Poisoning since about version 4.8 unless you set it up allowing external updates from 0.0.0.0 (have to be specified as they're not allowed by default).
And djbdns is about as useful as a condom machine in the vatican for anyone needing more than a dns cache for a LAN.
As the AC above states, BIND hasn't been vulnerable to DNS poisons for many years.
Because system administrators are anal and fail to realize that software like BIND is not written to be secure. Not sure why you say this, ISC have released a constant stream of patches since BIND was released and every announced security hole has been fixed. Not only that but they even added options to chroot the daemon and run it as an unprivileged user. They also have links on its homepage to guides on how to chroot the e
stop spreading fud. They do sell support contracts. The patches are freely available. In fact check out their security matrix. It lists all the known problems, versions effected, and suggests a patch or upgrade to get.
BIND9... don't get your hopes up. The BIND company sells paches for their software. Meaning that if you don't pay them money then you're going to be running an errornouse DNS server. [original emphasis]
Still most people use BIND for two reasons: no one wants to learn the crusty details of DNS and 2) Linux comes with BIND as it's default name library.
Alternative like djbdns [cr.yp.to] should be used.
I wish it was so simple. There are two most important problems with djbdns, though. Namely:
And this has to do with what exactly? Others have ripped your issues with BIND to shreds so I don't need to comment on it. However, nothing in the article discusses BIND and afaik Mr. Kaminsky's hack is going to work with *any* DNS server. If his claims are right and the packet is crafted to look kosher than any DNS server is going to forward it. Even your precious djbdns.
some good people could break into the nameservers of a large ISP such as AOL and send out spoofed NS records for update.windowsupdate.com or whatever it is and deploy linux to all windows users.
Yeah, you could proxy DNS and use source address verification. Still, the installation this wasn't a problem.
We were actually limiting access from the internal to external network. So, all DNS requests were only allowed to a target server. (Our servers of course).
Specifically, this was implemented to prevent IP over DNS so users couldn't get passed the firewall.
Yeah... it's stupid we had to police our own staff . If people were doing their jobs... they could have had their fun too. However, this was not
I don't think so. I would assume a normal user browsing the net (especially sites with lots of ads) and sending 4-5 emails (without using a relaying proxy) generates quite a bit of DNS traffic.
I think it may be worth the firewall's while to check if the DNS packets are in the right format - for example if the domain name in the request is ghjj!!&^ then one should frown ! I don't what kind of load this would mean for the firewall, though.
(I type this even as I recover from the nausea, vomitting and sic
I've noticed in the past that many of the public wireless networks that want you to pay to use allow DNS traffic to flow even before you've paid. I've often thought that'd you could use that to build a tunnel and not have to pay for service.
Mind you, I've never done it because it would be kind of rotten, but it did cross my mind.
You are right, I know people who do that when they travel through international airports. It doesn't work that fast (something like a 36k modem) , but it is free. AFAIK you do need a domain and a DNS server you control yourself.
not quite sure: but you can probably only connect to the local DNS (caching) server on the WLAN. DNS requests are forwarded to the server that is responsible for a certain domain. So to route the DNS packets (with other traffic encapsulated in it) to your DNS server, you need a domain... I guess...
The local wireless Domain Name Server will only accept DNS requests, and will only give you DNS replies.
So you create bogus DNS requests pointing to various places on your domian. But they aren't real places on your domain - they are encoded data. The wireless service doesn't know the answer to your DNS request, so it forwards the request to the domain to get the answer - it forwards the request to your domain. You configure your domain to decode your bogus DNS requests into g
You probably could, but that can easily be foiled, if that kind of behaviour becomes commonplace.
All the wireless network admins have to do is forward all DNS packets to a DNS server that only allows you to look up a specific domain, and block everything else.
IP Tunneling Through Nameservers [slashdot.org]. And you can apparently stop that [seclists.org] too, but I doubt it's very efficient unless you whitelist domains unauthenticated clients can look up.
my standard iptables rules only allow some ISPs dns-servers
And then those ISP's dns-servers relay those messages to the hackers DNS server... The downside is that every packet that goes out has the destination server's domain name marked on it.
Surely we all know that "DNS" comes at the top of the list of the Internet's vulnerabilities? Tunneling data; many bugs in DNS software over the years; vulnerability to DOS: Surely we all know this already - why is this news?
DNS was an afterthought - but it seems to me a very necessary one, and one we will have to continue to live with.
That is why any GOOD sysadmin will set up the system so that there is a single DNS server for the plant, and that server and that server alone is allowed to send and receive DNS packets to the greater Internet - all other machines are to use the local DNS server.
Not only does this GREATLY reduce the amount of DNS traffic a shop produces (by caching all requests locally) it helps prevent this sort of foolishness by requiring all packets to be well formed DNS packets - else the server drops them.
Then, you can block any client that makes more than a few requests a second.
Yes, it is easier to set up a firewall to be very porous to outbound traffic, but it is more secure to deny all direct access, and force clients to run through proxies for the various services.
The packets in question are (or at least could be) well formed.
Imagine that I own ISpy.com, and a user does a lookup on "user.jsmith.passwd.12345.ispy.com". Your server, in the middle, will forward that request to the NS for ispy.com more or less unchanged. And it doesn't have to be this obvious - it would certainly be easy enough to come up with some form of steganography appropriate to use in DNS.
Not that proxies are a bad idea, but in this case proxies will not prevent the attack. Mostly, they'll
Yeah, check out the slides. I rather obsessively follow the spec (limit to Base32 my upstream queries, Base64 my downstream TXT records, though I could just as easily use Base32'd CNAME's or MX's).
The whole point is that DNS is equivalent to every web server proxying, and that this proxy service does have security implications.
But please, cache stuff locally:-) It makes my radio hack work much much better.
Gosh, I even went so far as to state, very clearly, that a key part of defeating this sort of thing was, and I quote my previous post, "block any client that makes more than a few requests a second."
Now, lets see. DNS packets are limited to 512 bytes per spec (and having just finished implementing an DNS client the spec is quite clear in my mind). Let us take the commonly used value of "less than ten" for the term "a few".
So, you have less than 5120 bytes/second of throughput. That's assuming that you don
There was an old slashdot story [slashdot.org] eons ago about people using DNS tunnels to abuse the free dial up lines used for setting up a dial up ISP account. Covert comms over DNS is nothing new, but oddly it doesn't seem to have ever caught on.
I've read somewhere that there are some "implicit" rules in the Firewall 1 default configuration that let DNS through anyway. Is that true ? I have the eval CD here, but haven't had the time and the resources to test it.
That flaw in most firms' network security leaves a vulnerability that can be used by hackers to sneak intellectual property outside a company, communicate with a compromised server inside the company,
In other security news alerts, there was a major hole disocvered in SSH. It turns out if a hacker installs a rogue SSH daemon on the server, he can do nefarious things with it.
Most trojans need to poll the outside world periodically, to determine whether they have a new set of operations to execute. With this approach, no polling is necessary -- there's an open pipe _into_ the organization, and the trojan can remain perfectly silent.
by Anonymous Coward writes:
on Sunday August 01, 2004 @10:56AM (#9857709)
Note that LDAP is fully capable of doing host name resolution, there's even an RFC for it (AFAIK the one that specifies how to store POSIX user info also specifies how to store host names). And in fact, DNS can be used for user details via Hesiod.
Both LDAP and DNS are hierarchical federated database systems. Personally, I find current LDAP implementations to be more manageable, better designed, and generally nicer (can set very fine grained permissions) than current DNS implementations. A name system based on LDAP rather than DNS would be fully feasible and IMHO as or more globally scalable.
But we must distinguish between DNS-the-protocol and DNS-the-implementations - It would be possible to have the same piece of software answer both DNS and LDAP queries from the same database. Hey, hello Microsoft Active Directory! But MAD is nasty for other reasons - so where are the Open Source projects to provide a slapd plugin for DNS protocol lookup to openldap databases? It should actually be pretty simple, maybe it's so simple no-one is interested hacking on it....
The DNS P2P-server/client system has been proven to be reliable, supporting the unified Internet namespace continuously for hundreds of millions of concurrent users, for many years. Regardless of the techniques used, can LDAP claim that kind of bulletproof track record?
Thought of this almost two years ago. Run OpenVPN [sourceforge.net] over UDP port 53. I figure a fair number of firewalls may not analyse UDP DNS traffic to see if it actually is UDP DNS traffic. Haven't had a chance to try it out though.
Thinking big picture, you realise that once opportunistic IPsec becomes available, and with IPv6 it will be, any device in the network trying to interpret traffic, such as firewalls and proxy servers, will become just about useless.
I was poking around the the FTP site that has nstx and I noticed migr. It's a hack to migrate processes between systems. The migration is not completely transparent to the migrated process since it will lose filepoint locations at least. It appears to reload the migrated process by installing it as a SEGV handler with signal stack and then unmapping most of the loader causing a segfault which starts the migrated process.
Even doing network tunneling over DNS -- ALSO not that big a deal; NSTX has been doing this for a while.
DNS radio is new. By segmenting audio into small chunks, we actually get universal caching of the streaming signal -- a functionality we've never really had before. Generally, audio broadcast over the Internet falls apart after a few thousand users. Based on this ring-buffer-into-BIND architecture, combined with the utterly minimal bandwidth load of Speex, we should be able to host audio for a much greater number of listeners.
The entire suite of incoming attacks to firewalls are also new. DNS trusts the hierarchy to tell it the next hop to its target name; since I can acquire second level domains in the hierarchy for minimal cost, it's trivial for me to insert arbitrary destinations along the DNS route path. In technical terms, whenever a recursing resolver comes to my name server to resolve a name, rather than providing an answer, I can redirect that request to another, supposedly authoritative server. That server can be at any address -- even one I cannot IP route to -- but if the resolver communicating with me can route to that address (say 10.0.1.11) my communication will reach that host. If there's an SSH over DNS daemon running on 10.0.1.11, I've now achieved incoming connectivity to the network of my choice, completely bypassing firewalls and a trojan's need to poll.
Recursion on dual hosted interfaces is not even necessary. There are large numbers of applications that, upon receiving untrusted traffic, execute DNS name lookups. Most commonly, they are reverse PTR lookups, but occasionally there are other types (MX from mail servers, most notably) that can be easily induced. When they are induced, the hierarchy is followed. When the hierarchy is followed, the attacks previously discussed start working. In practice, this means an IDS triggers the DNS server to start proxying traffic between an external attacker host and an internal trojaned machine. Nasty.
There's some other stuff -- check out the slides and the code -- but long story short, there's some new stuff out:-)
are more of a problem than covert channels. Every cell phone is a covert channel out of a business. Since DNS can't be used to deliver advertisements, I don't see a business threat here. It may be a concern to a military installation though.
The opulence of the front office door varies inversely with the fundamental
solvency of the firm.
TCP or UDP (Score:3, Interesting)
Rus
Re:TCP or UDP (Score:5, Informative)
They may have used spoofed DNS packets just to bypass a firewall, but information can also be tunneled in real DNS packets, so even if you only allow DNS to/from certain servers, you're still not safe from this leak.
Re:TCP or UDP (Score:5, Interesting)
They may have used spoofed DNS packets just to bypass a firewall, but information can also be tunneled in real DNS packets, so even if you only allow DNS to/from certain servers, you're still not safe from this leak.
Yup, and that's not the half of it. With the extensions being duct-taped onto the existing spec it makes it easier and easier to do this. I've seen some hacks to allow all sorts of arbitrary information to live on the servers, some relayed automatically because of the extensions, some used to modify how mail servers respond, some even for routing. It's nothing new (remember transferring data via ICMP ECHO?) but it's on a new level now.
KL
Re:TCP or UDP (Score:1)
Re:TCP or UDP (Score:2)
Old news (Score:5, Informative)
Re:Old news (Score:3, Informative)
http://cgi.nessus.org/plugins/dump.php3?id=1158
Re:Old news (Score:3, Informative)
Here's a link:
http://cgi.nessus.org/plugins/dump.php3?id=11580
And here's a clickable hyperlink (you may have seen these before):
http://cgi.nessus.org/plugins/dump.php3?id=11580 [nessus.org]
Seriously, it's not that hard! In Slashdot all you have to do is put <URL: at the start and > at the end.
Re:Old news (Score:2, Informative)
Mozilla: Select the url, middle click into a new tab. Bam.
Konqueror: Ibid.
Links (graphical): Select the url, hit g, middle click
Re:Old news (Score:2)
In addition I write this comment on a win2k workstation. It is rather nice to have a clickable link so that in mozilla I can open in a new tab to process later. In other words actually have a hyperlink be clickable
Re:Old news (Score:1)
Re:Old news (Score:2)
Dan is literally *using* DNS to hide his traffic, not just using udp:53.
I know Dan and he's one of those people crazy (smart) enough to hack on something as dumb as this long enough to get something interesting out of it.
-davidu
Re:Old news (Score:3)
Even so, this still isn't that interesting. So you mime encode it (or whatever), tack on a domain, and talk to a rogue dns server. Anyone dealing with secure networks should know that having any opening to the internet is a security risk and take that into account when designing one's network.
Re:Old news (Score:3, Informative)
--Dan
Re:Old news (Score:2)
Right now, we rely on 13 servers to run DNS, why not 26? Why even have root name servers at all? Could we develop a DNS system ala Usenet, that sends updates both up and down stream... And then just have the ability to slowly or quickly accept new incoming information as true based on various criteria, to avoid having bad information flooding the DNS servers?
This is supposed to be 'news'? (Score:5, Informative)
Repeated (Score:2)
So does this mean (Score:4, Funny)
In other news... (Score:3, Funny)
90% of the internet is valnerable ... (Score:4, Interesting)
BIND9... don't get your hopes up. The BIND company sells paches for their software. Meaning that if you don't pay them money then you're going to be running an errornouse DNS server.
Still most people use BIND for two reasons: no one wants to learn the crusty details of DNS and 2) Linux comes with BIND as it's default name library.
Alternative like djbdns [cr.yp.to] should be used.
Re:90% of the internet is valnerable ... (Score:3, Interesting)
Re:90% of the internet is valnerable ... (Score:4, Informative)
Incorrect, it is open source.
It isn't GPL.
There's a big difference.
>Until a true open source alternative to BIND appears, we're stuck with it.
By "true alternative" do you mean it has to be GPLable?
Get real. djbdns' source is 100% available for you to look at and patch to your hearts content. If you find an error, send a fix to DJB and he'll add it after review. He'll even give you $500 [cr.yp.to] as a reward for your hard work. Find me a GPL program that makes an offer like that.
Now, if he doesn't like your patch, you can post the patch on the internet. You can even put it alongside the source. You can even make an autopatch program that will patch djbdns during make so that dumb users can handle the process
For the disbelievers, here's [cr.yp.to] the source code.
Here's [cr.yp.to] bernstein's statement about the freedom of his software. Feel free to print it out and sign it if you're insane on the idea he can revoke your license.
Re:90% of the internet is valnerable ... (Score:2, Informative)
Re:90% of the internet is valnerable ... (Score:2)
Re:90% of the internet is valnerable ... (Score:4, Insightful)
Can you make binaries of your new program and distribute them? If not, I can't see how you call this open-source. It cuts off all of the distributors from carrying patched versions that work with their own distribution, instead of whatever way that djb wants.
Re:90% of the internet is valnerable ... (Score:2)
Open-source typically means the ability to redistribute modified binaries. Even if it doesn't (which, if you read the open-source definition, it does), the usefulness which most people attribute to open-source is lost. If you can't recombine modified binaries into a distribution of software, how "open" is it?
The open-source definition says that the software must be (a) redistributable in both source and binary forms,
$500 is nothing. (Score:2, Informative)
(Also: Who judges the "entrants" for the $500 prize? That's right, DJB does, and there are no formal rules as to exactly what qualifies as a security bug).
Re:$500 is nothing. (Score:2)
So? (Score:2)
Guess what? DJB is extremely arrogant (as many clever people tend to be).
You failed to answer my point about who gets to judge the "entrants" and the rules of the contest.
Look, it's a simple matter of
Re:So? (Score:2)
It's irrelevent to my contradiction of your statement, "The $500 guantee is worthless."
Look, it's a simple matter of economics: Auditing code is mostly tedious and there are sufficiently many ways of earning much more money (and with a guaranteed payoff!) auditing code that no amount of spite is worth it.
One matter of economics you're not considering is that value and worth are not equivalent to monetary
Re:90% of the internet is valnerable ... (Score:2)
Incorrect, it is open source. It isn't GPL. There's a big difference.
The point being made is that djbdns is not open in some pretty important ways, like allowing other people to extend it for example.
Bernstein is a total control freak, he demands that people install and use his code in very specific ways...
Re:90% of the internet is valnerable ... (Score:2)
Yes, but the trolls [trollse.cx] have redubbed anything to which you can read the code "Open Source." It confuses the argument, but it makes PHB's feel better about using software not developed by a money-grubbing company (the kind they were taught to like while they were earning their MBAs).
DJB's software is Open Source. It is free-as-in-beer, not free-as-in-speech, perhaps. That said, just because something is Free Software does not make it sup
Wrong (Score:2)
The DJB license does not do that (and even prevents modified source distribution). End of story.
Re:Wrong (Score:2)
There are many things that are open source and not free. DJB's stuff. Quite a bit of UW mail software, etc. etc. You can't distribute a patched version of pine, either, without UW's permission.
OSI obfuscates these issue because the trolls don't get along with RMS.
“Open Source” and “Free Software (Score:2)
Actually, the definition of "open source" used by OSI (launched
Re:90% of the internet is valnerable ... (Score:2)
So as I have told many people, every network app is going to have its issues. Some have more than others, but with proper patch management (and despite the original posters claim, you don't have to pay for BIND patches) you can keep your network secure.
A
Re:90% of the internet is valnerable ... (Score:2)
Incorrect, it is not open source. You cannot distribute modified versions. And 'modified versions' in his case means so much as having the binaries installed in a different location than they would be by building and installing his source distribution... among other things. You can only redistribute a djbdns package if the effects of installing your package on a system are exactly the same as the effects of installing his official source distribution.
Because of it not being
Re:90% of the internet is valnerable ... (Score:2)
Yes, there is a big difference, and djbdns is not Open Source. It violates points #3 and #4 of the Open Source Definition [opensource.org]. (It also doesn't comply with the DFSG [debian.org] which is why Debian has it in non-free.)
I quote:
Re:90% of the internet is valnerable ... (Score:2)
"Available Source" !== "Free Software".
You can't redistribute changed, patched DJBDNS. You can't fork it if you figure something requires a fundamental change in design philosophy. You cannot distribute binaries. DJB release a new version every millenium or so - so when you set up Qmail or DJBDNS, you spend a week applying patches and testi
Re:90% of the internet is valnerable ... (Score:2)
Assuming that people have compilers, make, etc. on their production servers
DJBDNS is not Open Source (Score:2)
Open source doesn't just mean access to the source code.
Note that opensource.org invented the term "open source" - it was not in use to describe software until they had that meeting where they invented the term - so they certainly get to say what it means.
DJBDNS is "disclosed source". Big difference.
True Alternative (Score:2)
Not necessarily. Being distributable wouln't hurt, though. Being compatible with the DNS standard would also be a plus. Don't get me wrong, I am all for alternatives to BIND, but djbdns cannot even be distributed as a simple rpm or deb package not messing the whole bloody filesystem, for God's sake.
If you want a name server with such a strong emphasis on security
Re:90% of the internet is valnerable ... (Score:2, Insightful)
http://www.powerdns.com/products/powerd
Irrelevant^2 (Score:5, Insightful)
The $500 correpsonds to less than 50 hours at $10 an hour (being extremely generous with the hourly wages here, in favour of the "gaurantee"). Do you think anyone can audit the djbdns source code -- even ignoring the fact that it's largely uncommented and messy (#define, what's that?) -- in 50 hours? No, I didn't think so.
BIND may be Open Source (note capitalization) while djbdns isn't. That doesn't mean you can't get source for djbdns. In fact it's probably easier to get source than binaries for djbdns because of the unbelievably stupid djbdns license.
So they are both equally "insecure" from that perspective.
Not only irrelevant—it's utterly laughable (Score:2)
I not only have seen script kiddies trading private exploits for sums at least an order of magnitude greater than that, but they were selling it to multiple buyers. I am talking about script kiddies, not professionals, mind you. Even $100,000 would be laughable. $1,000,000 might start looking interesting for people not willing to make any serious usage (industrial espionage, etc.) of their exploits. But $500? Please don't mind if I die laughing. See
That is completely irrelevant (Score:2)
Daniel Bernstein's salary is completely irrelevant. $500 is not any less miserable (or laughable, for that matter) if it is given by someone who is poor.
It is hardly irrelevant in m
Re:90% of the internet is valnerable ... (Score:3, Informative)
Re:90% of the internet is valnerable ... (Score:3, Interesting)
That't not what this securityfocus article says [securityfocus.com].
Re:90% of the internet is valnerable ... (Score:2)
Yes it does...
Note that was in January *2003*. Any admin not running a server patched against this should be shot (or given an MCSE).
Re:90% of the internet is valnerable ... (Score:2)
Re:90% of the internet is valnerable ... (Score:2)
According to (Score:2)
Re:90% of the internet is valnerable ... (Score:3, Informative)
BIND hasn't been vulnerable to DNS Poisoning since about version 4.8 unless you set it up allowing external updates from 0.0.0.0 (have to be specified as they're not allowed by default).
And djbdns is about as useful as a condom machine in the vatican for anyone needing more than a dns cache for a LAN.
Re:90% of the internet is valnerable ... (Score:1)
Re:Insightful my ass (Score:2)
Because system administrators are anal and fail to realize that software like BIND is not written to be secure.
Not sure why you say this, ISC have released a constant stream of patches since BIND was released and every announced security hole has been fixed. Not only that but they even added options to chroot the daemon and run it as an unprivileged user. They also have links on its homepage to guides on how to chroot the e
Re:90% of the internet is valnerable ... (Score:2)
Problems with djbdns (Score:2)
I wish it was so simple. There are two most important problems with djbdns, though. Namely:
Re:90% of the internet is valnerable ... (Score:2)
helpful (Score:5, Funny)
Warning: this update may require a reboot.
Re:helpful (Score:1)
This is why.... (Score:3, Insightful)
After the IP over DNS tunnel came out... it was actually a bit necessary. Our staff would do anything to get out of doing work...
Re:This is why.... (Score:1)
Could you explain in laymans terms what this is/how it works?
ACLs are not secure (Score:1)
The use of ACLs is not secure because an atacker may spoof easily the IP address.
Is a good way , yes, but not the ONLY and FINAL way to protect our networks.
Re:ACLs are not secure (Score:1)
For what values of easily? (i.e. UDP or TCP?)
Re:ACLs are not secure (Score:2)
We were actually limiting access from the internal to external network. So, all DNS requests were only allowed to a target server. (Our servers of course).
Specifically, this was implemented to prevent IP over DNS so users couldn't get passed the firewall.
Yeah... it's stupid we had to police our own staff . If people were doing their jobs... they could have had their fun too. However, this was not
Suspicious? (Score:3, Insightful)
Re:Suspicious? (Score:2, Interesting)
I think it may be worth the firewall's while to check if the DNS packets are in the right format - for example if the domain name in the request is ghjj!!&^ then one should frown ! I don't what kind of load this would mean for the firewall, though.
(I type this even as I recover from the nausea, vomitting and sic
Re:Suspicious? (Score:2)
Only if someone or something is checking for it.
Cheating Wireless networks (Score:5, Insightful)
Mind you, I've never done it because it would be kind of rotten, but it did cross my mind.
Re:Cheating Wireless networks (Score:3, Interesting)
Re:Cheating Wireless networks (Score:2)
Re:Cheating Wireless networks (Score:1)
Re:Cheating Wireless networks (Score:2)
Re:Cheating Wireless networks (Score:2)
The local wireless Domain Name Server will only accept DNS requests, and will only give you DNS replies.
So you create bogus DNS requests pointing to various places on your domian. But they aren't real places on your domain - they are encoded data. The wireless service doesn't know the answer to your DNS request, so it forwards the request to the domain to get the answer - it forwards the request to your domain. You configure your domain to decode your bogus DNS requests into g
Re:Cheating Wireless networks (Score:2)
A while ago...
People were dialing up to MSN's 800 service (the number your system dial's before you have an account) and DNS was completely open.
Thus spawned IP over DNS. There was a previous slashdot story concerning this. Free dial-up provided you had a modified DNS server.
Neat huh.
Re:Cheating Wireless networks (Score:2)
All the wireless network admins have to do is forward all DNS packets to a DNS server that only allows you to look up a specific domain, and block everything else.
Been there, done that. (Score:2)
Reason why (Score:1)
Re:Reason why (Score:2)
And then those ISP's dns-servers relay those messages to the hackers DNS server... The downside is that every packet that goes out has the destination server's domain name marked on it.
Misleading Title (Score:1, Informative)
Harmless? (Score:5, Insightful)
So? (Score:1)
Re:So? (Score:1)
Well known that DNS is iffy,s urely? (Score:1, Redundant)
DNS was an afterthought - but it seems to me a very necessary one, and one we will have to continue to live with.
That's why you use proxies! (Score:5, Informative)
Not only does this GREATLY reduce the amount of DNS traffic a shop produces (by caching all requests locally) it helps prevent this sort of foolishness by requiring all packets to be well formed DNS packets - else the server drops them.
Then, you can block any client that makes more than a few requests a second.
Yes, it is easier to set up a firewall to be very porous to outbound traffic, but it is more secure to deny all direct access, and force clients to run through proxies for the various services.
Doesn't work that way (Score:3, Insightful)
Imagine that I own ISpy.com, and a user does a lookup on "user.jsmith.passwd.12345.ispy.com". Your server, in the middle, will forward that request to the NS for ispy.com more or less unchanged. And it doesn't have to be this obvious - it would certainly be easy enough to come up with some form of steganography appropriate to use in DNS.
Not that proxies are a bad idea, but in this case proxies will not prevent the attack. Mostly, they'll
Re:That's why you use proxies! (Score:3, Informative)
The whole point is that DNS is equivalent to every web server proxying, and that this proxy service does have security implications.
But please, cache stuff locally
--Dan
Re:That's why you use proxies! (Score:2)
Now, lets see. DNS packets are limited to 512 bytes per spec (and having just finished implementing an DNS client the spec is quite clear in my mind). Let us take the commonly used value of "less than ten" for the term "a few".
So, you have less than 5120 bytes/second of throughput. That's assuming that you don
Covert communication over DNS tunnels (Score:2, Insightful)
Firewall 1 lets through DNS by default ? (Score:2)
I've read somewhere that there are some "implicit" rules in the Firewall 1 default configuration that let DNS through anyway.
Is that true ? I have the eval CD here, but haven't had the time and the resources to test it.
cheers,
Rainer
Re:Firewall 1 lets through DNS by default ? (Score:1, Informative)
It is quite simple and SHOULD be turned off
It is a mere matter of unchecking one box and setting up explicit rules for your local DNS server to comminicate to its external DNS resolovers
Duh... (Score:5, Funny)
In other security news alerts, there was a major hole disocvered in SSH. It turns out if a hacker installs a rogue SSH daemon on the server, he can do nefarious things with it.
Re:Duh... (Score:4, Informative)
--Dan
"without DNS" = LDAP (Score:4, Interesting)
And in fact, DNS can be used for user details via Hesiod.
Both LDAP and DNS are hierarchical federated database systems. Personally, I find current LDAP implementations to be more manageable, better designed, and generally nicer (can set very fine grained permissions) than current DNS implementations. A name system based on LDAP rather than DNS would be fully feasible and IMHO as or more globally scalable.
But we must distinguish between DNS-the-protocol and DNS-the-implementations - It would be possible to have the same piece of software answer both DNS and LDAP queries from the same database. Hey, hello Microsoft Active Directory! But MAD is nasty for other reasons - so where are the Open Source projects to provide a slapd plugin for DNS protocol lookup to openldap databases? It should actually be pretty simple, maybe it's so simple no-one is interested hacking on it....
Re:"without DNS" = LDAP (Score:2)
How about this : OpenVPN over UDP port 53 ie. DNS (Score:5, Interesting)
Thought of this almost two years ago. Run OpenVPN [sourceforge.net] over UDP port 53. I figure a fair number of firewalls may not analyse UDP DNS traffic to see if it actually is UDP DNS traffic. Haven't had a chance to try it out though.
Thinking big picture, you realise that once opportunistic IPsec becomes available, and with IPv6 it will be, any device in the network trying to interpret traffic, such as firewalls and proxy servers, will become just about useless.
nstx (Score:2)
http://slashdot.org/article.pl?sid=00/09/10/223024 2&tid=95 [slashdot.org]
and the current version of nstx:http://nstx.dereference.de/nstx/nstx-1.1-beta 5.tgz [dereference.de]
Re:nstx (Score:3, Informative)
Quick Summary: What's New (Score:4, Informative)
Throwing arbitrary data in DNS -- NOT a big deal.
Even doing network tunneling over DNS -- ALSO not that big a deal; NSTX has been doing this for a while.
DNS radio is new. By segmenting audio into small chunks, we actually get universal caching of the streaming signal -- a functionality we've never really had before. Generally, audio broadcast over the Internet falls apart after a few thousand users. Based on this ring-buffer-into-BIND architecture, combined with the utterly minimal bandwidth load of Speex, we should be able to host audio for a much greater number of listeners.
The entire suite of incoming attacks to firewalls are also new. DNS trusts the hierarchy to tell it the next hop to its target name; since I can acquire second level domains in the hierarchy for minimal cost, it's trivial for me to insert arbitrary destinations along the DNS route path. In technical terms, whenever a recursing resolver comes to my name server to resolve a name, rather than providing an answer, I can redirect that request to another, supposedly authoritative server. That server can be at any address -- even one I cannot IP route to -- but if the resolver communicating with me can route to that address (say 10.0.1.11) my communication will reach that host. If there's an SSH over DNS daemon running on 10.0.1.11, I've now achieved incoming connectivity to the network of my choice, completely bypassing firewalls and a trojan's need to poll.
Recursion on dual hosted interfaces is not even necessary. There are large numbers of applications that, upon receiving untrusted traffic, execute DNS name lookups. Most commonly, they are reverse PTR lookups, but occasionally there are other types (MX from mail servers, most notably) that can be easily induced. When they are induced, the hierarchy is followed. When the hierarchy is followed, the attacks previously discussed start working. In practice, this means an IDS triggers the DNS server to start proxying traffic between an external attacker host and an internal trojaned machine. Nasty.
There's some other stuff -- check out the slides and the code -- but long story short, there's some new stuff out
--Dan
Advertisements and Spam (Score:2)