DNS wildcards are actually very wonderful. I use them a lot. We have lots of clients, and with wildcards, we can start serving up subdomained web sites immediately rather than having to wait 3 days.
clientname.ourdomain.com instantly points to their development web site as soon as I configure Apache, not 3 days later.
There are a few other tricks you can do with it, but this is where it has helped me out the most.
Nope. The way it will work is that you can specify certain zones as "Delegation Only". So, the root name servers can be designated as delegation-only, meaning that they cannot resolve domain names themselves, but can only delegate to authoritative name servers. So, the intermediate servers will only accept NS records from them, and not A records. Anyway, the only possibility I see is that if the wildcards started only containing NS records that point to Verisign servers. However, I don't think the code to do that is part of BIND right now, and the actually name-serving software is not in Verisign's control I don't think.
This was fixed in WinXP SP1. However, Microsoft didn't release information about the fix until a month afterwards after pressure from Steve Gibson. They fixed the problem, but swept it into a service pack and didn't identify the exposure. It is listed in the SP1a list, but it is dated past the SP1 date, even though that is when it was included.
The nature of _my_ rants at least, include the following:
* UNIX does better at risk minimization (i.e. - chroot jails, more services running as unprivileged users, using processes rather than threads, etc)
* UNIX vulnerabilities are published quickly, and hotfixes are available quickly. In this case, we have a _potential_ vulnerability patched before anyone knows of any way to exploit it. In addition, it made frontpage Slashdot - everyone agrees it's a big deal. This is different from the MS attitude of "sweep it into the next service pack and noone will know".
* I have the source code to the patches, so I can validate whether or not the fix does indeed fix the problem it proposes to, and whether there will be any other impact caused by the patch.
* The patch doesn't require me to reboot anything - I can patch a running system and keep on trucking. Kernel patches should be the only thing that needs a reboot (and, when HURD gets mainstream, we won't even need to then).
* The source code is open to allow more scrutiny. Having the source code available still gives Linux users fewer security-incidents-per-feature than Microsoft while keeping their source closed. Ballmer, I believe, said under oath that giving out the source code to Windows publicly would be a threat to national security.
Nothing about the release of an exploit for Linux changes any of these issues.
In the problematic code, the buffer structure contained the incorrect size for the allocated space. Since this structure is not freed, I assume it's used for something later (unless fatal() simply logs the error and calls exit()). Therefore, in future accesses, this buffer will contain the incorrect size of it's contents. This lead to a buffer overrun.
In the new code, the new buffer size is calculated in a separate variable, which is not assigned to the buffer structure until _after_ it is confirmed valid.
Contact VERISIGN NOW! Contact their _sales_ department and tell them you will no longer be using any of their products until they get this fixed. Probably the person on the other end of the phone won't have a clue what you're talking about, but be aware, if this goes through the sales channels, it WILL be heard by upper management.
This is still space that could be used for something else, and it makes a bigger cable mess.
As for the fans, they still make noise and still break.
And the whole thing uses more electricity. We often forget this has a cost. I forget where, but I once saw the numbers as a result of consolidating a roomful of servers onto an IBM mainframe - they save $250,000 a year in electricity costs. Paying attention to these things can find your company money where it didn't think it had any.
However, the casing and the noise is a big deal. For example, if they manage to fit the whole thing in a completely silent chassis that is very, very small, you then buy yourself real estate - meaning that each user has more desk space - that's something not easily purchased.
In addition if they don't have fans, it both keeps the noise down to silent (which enhances productivity) and is one less thing to break and need replacing, making the # of movable parts 0.
Finally, if the Transmeta processor is energy efficient, you may be saving a whole, whole lot on electricity costs over its lifetime.
So, I don't know the numbers, but this could be very worth it's price. Just because anything _can_ be used as a terminal doesn't mean that these don't do the job better.
But not as many as are switching to Linux. This month there was a decrease in the total numbers of Windows systems, while there was an increase in Linux systems. This means that, while the migrations _from_ Linux are generally to Win2k3, most migrations are actually _to_ Linux (or Apache, I should say)
The difference is in standard practices. Microsoft thinks that adding various unrelated hotfixes in a single patch is good, while linux people tend to avoid it. That way, it is very evident what each fix will do. In addition, Linux gives you the source code for your fix, allowing you to determine the extent of the patch before applying it.
This is one thing that concerned my about the article. The distribution of "infiltration" EXACTLY matches the distribution of Apache/IIS on netcraft. Isn't that a bit odd? It makes me think that either the report is flawed or the interpretation of the report is flawed.
Anyway, I'm highly suspect of this report. It may turn out to be true, but until we see the data, we are unsure.
You misunderstood his post. He was being mildly humorous/ironic by changing the meaning of the word "attack". He is saying that Linux is "attacked" every day by FUDers, but they never succeed. He also seems to indicate that this article is a part of that FUD, which I am inclined to agree with.
"All of the Blaster issues would have been mitigated if every windows machine was patched as soon as the patch was released."
However, this does not qualify as good system administration. Since you do not have the source code to the patch, good system administration would require you to do a full test of the system in your development environment before pushing out the fix. In addition, since you don't have the source code, if that testing fails, you then have to spend lots of time figuring out what changed with the patch, and why it broke your software.
Shortest time period: 1 day for small applications, 5 days for large ones
Longest time period: depending on the problem and the abilities of the development staff, it could be months.
The nice thing about Linux is that the source code for the patches are out in the open, so you can verify for sure what is affected by the patch. If it is simply adding a missing case statement to a long switch, you can be pretty sure that it works with minimal testing. Deeper changes would require deeper testing, but you can tell from the patch itself.
"Why wouldn't you leave a note on the outside of the house?"
In the case of physical security, it's obvious what the problem is and the reason for it. With technical things, with many admins, they just don't know what you mean.
I don't know the details of the case (this is Slashdot, so reading the articles is pointless), but what if someone found that your door is repeatedly left open, and then one day when you're out, walks in and leaves a sign that says "You left your back door open". Is that damage?
I'm tired of people saying "maybe this kind of software is where free software lags". For every example of software types, I've seen free software that kicks butt. However, in the free market, there will always be software from multiple vendors, and some pieces of software will have better proprietary versions, some better open versions. I think it has little to do with the community's or proprietary software's methods in general.
We do all in-house coding on Linux because it's a much faster development time. Emacs is one of the best programmer tools in existence. Couple that with GIMP scripts for making bookoos of templated images, regular expressions for condensing hundreds of lines of code into one, scripting languages out the wazoo with libraries that hook into absolutely every protocol ever made.
As for the information, I've found that it is usually right at my fingertips. Google is just as valid a tools as searching through help, except that it's usually much faster and gives better answers.
As with any environment, there are dusty corners, but nothing that's hampered my company's speed of development.
"and almost fell thru the hole in my ass when it said installation would require over 1gb!"
Then use a smaller dist. Considering that there are many the size of a floppy, I think you weren't looking hard enough.
The point about Linux is that you can make it the exact size you need. If you have big needs, get a big dist and a big computer. If you have small needs, get a small dist and a small computer.
Slashdot Mirror
DNS wildcards are actually very wonderful. I use them a lot. We have lots of clients, and with wildcards, we can start serving up subdomained web sites immediately rather than having to wait 3 days.
clientname.ourdomain.com instantly points to their development web site as soon as I configure Apache, not 3 days later.
There are a few other tricks you can do with it, but this is where it has helped me out the most.
Nope. The way it will work is that you can specify certain zones as "Delegation Only". So, the root name servers can be designated as delegation-only, meaning that they cannot resolve domain names themselves, but can only delegate to authoritative name servers. So, the intermediate servers will only accept NS records from them, and not A records. Anyway, the only possibility I see is that if the wildcards started only containing NS records that point to Verisign servers. However, I don't think the code to do that is part of BIND right now, and the actually name-serving software is not in Verisign's control I don't think.
http://support.microsoft.com/default.aspx?scid=kb; en-us;328940
This was fixed in WinXP SP1. However, Microsoft didn't release information about the fix until a month afterwards after pressure from Steve Gibson. They fixed the problem, but swept it into a service pack and didn't identify the exposure. It is listed in the SP1a list, but it is dated past the SP1 date, even though that is when it was included.
None of the rants assumed it couldn't happen.
The nature of _my_ rants at least, include the following:
* UNIX does better at risk minimization (i.e. - chroot jails, more services running as unprivileged users, using processes rather than threads, etc)
* UNIX vulnerabilities are published quickly, and hotfixes are available quickly. In this case, we have a _potential_ vulnerability patched before anyone knows of any way to exploit it. In addition, it made frontpage Slashdot - everyone agrees it's a big deal. This is different from the MS attitude of "sweep it into the next service pack and noone will know".
* I have the source code to the patches, so I can validate whether or not the fix does indeed fix the problem it proposes to, and whether there will be any other impact caused by the patch.
* The patch doesn't require me to reboot anything - I can patch a running system and keep on trucking. Kernel patches should be the only thing that needs a reboot (and, when HURD gets mainstream, we won't even need to then).
* The source code is open to allow more scrutiny. Having the source code available still gives Linux users fewer security-incidents-per-feature than Microsoft while keeping their source closed. Ballmer, I believe, said under oath that giving out the source code to Windows publicly would be a threat to national security.
Nothing about the release of an exploit for Linux changes any of these issues.
In the problematic code, the buffer structure contained the incorrect size for the allocated space. Since this structure is not freed, I assume it's used for something later (unless fatal() simply logs the error and calls exit()). Therefore, in future accesses, this buffer will contain the incorrect size of it's contents. This lead to a buffer overrun.
In the new code, the new buffer size is calculated in a separate variable, which is not assigned to the buffer structure until _after_ it is confirmed valid.
Contact VERISIGN NOW! Contact their _sales_ department and tell them you will no longer be using any of their products until they get this fixed. Probably the person on the other end of the phone won't have a clue what you're talking about, but be aware, if this goes through the sales channels, it WILL be heard by upper management.
n dex.html?sl=060104.
The phone number to use is 877-438-8580, pulled from
http://www.verisign.com/corporate/about/contact/i
If they get enough of these, they'll stop.
"I use a web-based call tracking application in my IT job. Its slow, buggy, and not enterprise worthy by any standard."
Maybe its the application and not the fact that its web-based.
This is still space that could be used for something else, and it makes a bigger cable mess.
As for the fans, they still make noise and still break.
And the whole thing uses more electricity. We often forget this has a cost. I forget where, but I once saw the numbers as a result of consolidating a roomful of servers onto an IBM mainframe - they save $250,000 a year in electricity costs. Paying attention to these things can find your company money where it didn't think it had any.
However, the casing and the noise is a big deal. For example, if they manage to fit the whole thing in a completely silent chassis that is very, very small, you then buy yourself real estate - meaning that each user has more desk space - that's something not easily purchased.
In addition if they don't have fans, it both keeps the noise down to silent (which enhances productivity) and is one less thing to break and need replacing, making the # of movable parts 0.
Finally, if the Transmeta processor is energy efficient, you may be saving a whole, whole lot on electricity costs over its lifetime.
So, I don't know the numbers, but this could be very worth it's price. Just because anything _can_ be used as a terminal doesn't mean that these don't do the job better.
But not as many as are switching to Linux. This month there was a decrease in the total numbers of Windows systems, while there was an increase in Linux systems. This means that, while the migrations _from_ Linux are generally to Win2k3, most migrations are actually _to_ Linux (or Apache, I should say)
I do.
The difference is in standard practices. Microsoft thinks that adding various unrelated hotfixes in a single patch is good, while linux people tend to avoid it. That way, it is very evident what each fix will do. In addition, Linux gives you the source code for your fix, allowing you to determine the extent of the patch before applying it.
Are you sure? Is his for 2K Professional or Server? Can you quote the clause?
This is one thing that concerned my about the article. The distribution of "infiltration" EXACTLY matches the distribution of Apache/IIS on netcraft. Isn't that a bit odd? It makes me think that either the report is flawed or the interpretation of the report is flawed.
Anyway, I'm highly suspect of this report. It may turn out to be true, but until we see the data, we are unsure.
Or, their previous ones were attempts to get Gates to buy them off.
You misunderstood his post. He was being mildly humorous/ironic by changing the meaning of the word "attack". He is saying that Linux is "attacked" every day by FUDers, but they never succeed. He also seems to indicate that this article is a part of that FUD, which I am inclined to agree with.
Hmmmm...
This whole article seems fishy. If this has been the case all along, why did only now these numbers come out?
And the numbers seem awfully small.
And it doesn't say what qualifies something as a server.
Nor does it say what it counts as a successful attack.
I'm inclined not to believe it without better data, especially considering the data we've had previous to this.
"All of the Blaster issues would have been mitigated if every windows machine was patched as soon as the patch was released."
However, this does not qualify as good system administration. Since you do not have the source code to the patch, good system administration would require you to do a full test of the system in your development environment before pushing out the fix. In addition, since you don't have the source code, if that testing fails, you then have to spend lots of time figuring out what changed with the patch, and why it broke your software.
Shortest time period: 1 day for small applications, 5 days for large ones
Longest time period: depending on the problem and the abilities of the development staff, it could be months.
The nice thing about Linux is that the source code for the patches are out in the open, so you can verify for sure what is affected by the patch. If it is simply adding a missing case statement to a long switch, you can be pretty sure that it works with minimal testing. Deeper changes would require deeper testing, but you can tell from the patch itself.
"Why wouldn't you leave a note on the outside of the house?"
In the case of physical security, it's obvious what the problem is and the reason for it. With technical things, with many admins, they just don't know what you mean.
I don't know the details of the case (this is Slashdot, so reading the articles is pointless), but what if someone found that your door is repeatedly left open, and then one day when you're out, walks in and leaves a sign that says "You left your back door open". Is that damage?
Loser. I speak Ethernet directly.
I'm tired of people saying "maybe this kind of software is where free software lags". For every example of software types, I've seen free software that kicks butt. However, in the free market, there will always be software from multiple vendors, and some pieces of software will have better proprietary versions, some better open versions. I think it has little to do with the community's or proprietary software's methods in general.
We do all in-house coding on Linux because it's a much faster development time. Emacs is one of the best programmer tools in existence. Couple that with GIMP scripts for making bookoos of templated images, regular expressions for condensing hundreds of lines of code into one, scripting languages out the wazoo with libraries that hook into absolutely every protocol ever made.
As for the information, I've found that it is usually right at my fingertips. Google is just as valid a tools as searching through help, except that it's usually much faster and gives better answers.
As with any environment, there are dusty corners, but nothing that's hampered my company's speed of development.
Much better than the current school of thought -
"Security through Plain Ignorance"
"and almost fell thru the hole in my ass when it said installation would require over 1gb!"
Then use a smaller dist. Considering that there are many the size of a floppy, I think you weren't looking hard enough.
The point about Linux is that you can make it the exact size you need. If you have big needs, get a big dist and a big computer. If you have small needs, get a small dist and a small computer.