You're being quite unreasonable (and a bit disingenuous), saying things like: "encryption fobs wont help, smart cards wont help", etc.
It's true that an RSA SecureID type of fob, or a SmartCard type of tool will not solve all authentication and authorization problems for the entire universe forever. However, thats not what we're trying to do here, we're just trying to dramatically improve the current situation.
A smart card or secureId fob is so many orders-of-magnitude of an improvement over the current processes, that you complaining about it because its not absolutely perfect in all attack scenarios is a bit silly.
As an example, lets worst-case the failure mode of a smart card or secureId fob. Say someone successfully does a MITM on your web browser session, intercepts your user/pass, and then intercepts your (the consumer's) response to the challenge from the bank.
You can then return that response to the bank, effectively take over the person's web browsing session, and make any transactions that you want.
But this only lasts for the ONE SESSION. Next time the bank website sends a challenge, you are unable to respond. The SecureID has rotated to a new time interval, or the smart-card has been issued a new, unique challenge. Unless you can somehow trick the user into staying online, and then respond to the 2nd+ challenge, you're now out of luck forever.
See the difference? This attack has to happen in real time, and its only good for a very limited amount of time.
Compare that to a MITM attack or keylogger without that additional factor. In that case, the user/pass combos can be collected, and used later, en masse if desired. In addition, if the bank consumer doesnt catch it, the user/pass can continue to be re-used.
In addition, a smart bank site can drastically mitigate even this worst-case scenario, by requiring a first challenge/response on initial login, and then another challenge response on any attempt to transfer money out of the account or send checks.
Think about how much harder this makes the MITM attack. You not only have to be in there doing a MITM attack in real-time, but you have to get the person to respond to the first challenge, and then convince them they're still browsing the website long enough for you to solicit the second challenge, and then get them to respond to that.
By doing this, you've knocked out the vast, vast majority of currently successful attack modes, and radically improved the robustness of the system, and its resilience to phishing and identity theft attacks.
*sigh* and of course while trying to complain about someone's writing of incoherent sentences, I write an incoherent sentence.
What I meant to say was:
You're also quoting an Oracle employee who can only occasionally produce coherent sentences (ie, appears to have trouble writing sentences that make sense), and insists on referring to Windows as 'windoze'.
This (RH AS vs. WinXP) is an apples to oranges comparison.
You've got RedHat's most advanced, most highly-tuned for server duties compared to Windows lowest-end, most-highly-tuned-for-anything-but-server-duties.
A correct comparison would be to Win2000 Advanced Server, or Win2003 Enterprise Server, depending on the exact timing of the comparison.
You're also quoting an Oracle employee who can only occasionally coherent (ie, appears to have trouble writing sentences that make sense), and insists on referring to Windows as 'windoze'. This is not exactly your most trustworthy, professional consultant here.
An application pool runs under an isolated process.
Multiple threads (configurable) service requests for this pool, in a pooled, as-available fashion.
So in the current system, you have visibility into the application pools, and you can see how many threads are servicing requests, there is no mechanism to make a given (hung or misbehaving) request visible and killable.
Now granted, this is a very minor feature, as if a typical asp or asp.net script is looping or hung, it'll either time out or be terminated by the system as a misbehaving execution.
So its nice, but the times when you need this granularity is rare.
In fact, the only times I've seen where it would be useful would be in killing runaway perl processes running under IIS. Currently, its difficult to figure out what script, or what request is looping/hung, and there is no automatic timeout for perl scripts or processes.
I'm not sure if you're trolling or just havent been much involved in Windows systems in 10 years.
NT == Windows. The last time there was a difference was Windows ME. ME was the last of what you're referring to as 'windows'. NT4, Windows 2000, Windows XP, and Windows 2003 Server (NT4, NT5, NT5.1 and NT5.2 respectively) are all based on the NT line.
Windows is not a single-user system, and applications do not own the system. For some insane reason, there are still some people and some organizations that do their daily work running as a local administrator account. But this is not smart. The correct, safe, and intelligent thing to do is use a non-privileged account for your daily work, and then either use runas (ie, sudo) or login as a local admin account. This is no different than best-practices on any operating system.
The 7-character encryption you're referring to is a full three generations old. The current system does not suffer from this, and hasnt for years.
About the only legitimate complaint about the current password hashing is that all windows systems, across all domains, use the same seed for the hash. Now this has some upsides, in that the same user & same password will work across domains without having to re-authenticate. The downside is that it lets you pre-compute rainbow-tables. If this seed issue is a proble, Syskey is available to you to eliminate this problem.
However, you can use upper-case, lower-case, numbers, symbols, spaces, and higher-order characters in your windows passwords, and passwords can be up to 128 passwords long. Or you can use smart-cards, support for which is built into the OS.
Local security is the same as in any other multi-user system. People are limited only to the files & folders & processes that they have been given privileges to. In fact, its only very recently that *nix file systems are catching up to NTFS and introducing proper inherited ACLs. Not saying they did everything right, but MS was way ahead of the unix world with NTFS ACLs.
Windows Web Edition was created to provide a cheap version of the OS w/ IIS that did not require any CALs (Client Access License).
Same for the versions that run on the purpose-built NAS boxes sold by many vendors.
Product segmentation in any industry serves the same purpose: to gain more customers than they'd have without it.
So you charge more for the high end versions to people that want those features and can pay more. You charge less for the versions that are simpler and appeal to those who might otherwise buy a cheaper/free competitor.
One 45 minute scheduled downtime (assuming its scheduled) per month isnt terrible. It's not great, but costs really start to go up as you add nines beyond those 3.
I am quite interested to see all of these people who are so gung-ho about switching out of Windows when they obviously havent taken the time to learn how to manage their networks.
Regardless of whether you are running Windows or Linux, you still have to learn how to do things like lock down the workstations & servers, how to do configuration management across your entire network at once, and you have to have some way to do automated patch management, and patch verification.
All of these things are fairly easy to do on Windows, and require nothing but free tools and a little bit of effort on the parts of the SysAdmins.
What is sad is that when they switch, they'll probably consult best practices manuals, and actually set up these processes on their linux systems, and then complain how everything works so much better, but they never set up good management processes on Windows.
Bottom line is that to do your job well as a SysAdmin you have to implement good network & system management practices & processes. If you're doing these, then there is zero marginal effort to deploy each additional patch, as your process does it for you, and only notifies you when something goes wrong!
You can do this quite reasonably on either platform, but you have to actually put the effort in, and do more than just run around like a chicken with your head cut off when the latest patch comes out.
If you have to put in ANY extra hours because of a vulnerability like the MS RPC one... then your network is not well managed, and you need to do a better job.
- Create (bootable) server images that deploy on either CD/DVD media or over the network (RIS)
- Login remotely if necessary (rarely) or use any of the command line, gui, or programmatic tools to remotely administer any machine. Rather than being limited to just remote shell, you can do remote shell (RDP), remote management via GUI tools (computer management, etc), remote management vs command line tools (resource kit & support tools), or remote management via scripting (WMI, WSH, ADSI, etc).
- you can have a small group of knowledgeable and experienced windows admins... this is because you can script & automate pretty much every conceivable thing in windows (mind you, I'm referring to 2000 and above).
You are certainly welcome to install servers at each location, and depending on the bandwidth available on your WAN link, this may or may not be a good idea.
If you do choose to go that way, you can use DFS and Sites to (automatically) have the clients at each site preferentially use network and file-server resources local, but then failover to the central site if anything should go down.
The comments above are often made by people who are not experienced windows admins. There is very little you cant do via command line, and absolutely nothing you cant do via scripting or programmatic access.
This leads to one of the key distinctions between unix and windows administration... windows is written with the assumption that every sysadmin is also a competent programmer, and the tools are focused on that. The equivalent to shell scripts is WSH/WMI/ADSI in the windows world.
A couple hundred users on one low-end server box is the lower-end of Exchange scaling.
My local department supports a bit over 300 users on Exchange 5.5 running on NT4sp6. The only reason this box ever gets shut down is to apply security related patches. Most of the time it runs at 25% or less processing power (4+ years old hardware), and it could certainly do with more memory (old hardware only supports 512MB) so that the entire store could fit in memory.
This is one of the servers that basically just runs and runs and runs, and you never have to touch it, and it never crashes, over 4+ years (gives you an idea how old the hardware is).
Most months, we have zero (as in not even a minute) downtime.
What most people seem to not understand is that Exchange is a simply gargantuan product, and does have a significant learning curve. But once you set it up and configure it correctly, you can largely just forget it.
As someone posted elsewhere in this thread, you've got to watch out for some of these second rate companies that host Exchange very poorly, or corps thats put some paper-MCSE as the Exchange admin who couldnt even calculate a subnet mask, and they wonder why their box is flaky.
Bottom line, as far as I see it: Its not the software, its the people.
Slashdot Mirror
You're being quite unreasonable (and a bit disingenuous), saying things like: "encryption fobs wont help, smart cards wont help", etc.
It's true that an RSA SecureID type of fob, or a SmartCard type of tool will not solve all authentication and authorization problems for the entire universe forever. However, thats not what we're trying to do here, we're just trying to dramatically improve the current situation.
A smart card or secureId fob is so many orders-of-magnitude of an improvement over the current processes, that you complaining about it because its not absolutely perfect in all attack scenarios is a bit silly.
As an example, lets worst-case the failure mode of a smart card or secureId fob. Say someone successfully does a MITM on your web browser session, intercepts your user/pass, and then intercepts your (the consumer's) response to the challenge from the bank.
You can then return that response to the bank, effectively take over the person's web browsing session, and make any transactions that you want.
But this only lasts for the ONE SESSION. Next time the bank website sends a challenge, you are unable to respond. The SecureID has rotated to a new time interval, or the smart-card has been issued a new, unique challenge. Unless you can somehow trick the user into staying online, and then respond to the 2nd+ challenge, you're now out of luck forever.
See the difference? This attack has to happen in real time, and its only good for a very limited amount of time.
Compare that to a MITM attack or keylogger without that additional factor. In that case, the user/pass combos can be collected, and used later, en masse if desired. In addition, if the bank consumer doesnt catch it, the user/pass can continue to be re-used.
In addition, a smart bank site can drastically mitigate even this worst-case scenario, by requiring a first challenge/response on initial login, and then another challenge response on any attempt to transfer money out of the account or send checks.
Think about how much harder this makes the MITM attack. You not only have to be in there doing a MITM attack in real-time, but you have to get the person to respond to the first challenge, and then convince them they're still browsing the website long enough for you to solicit the second challenge, and then get them to respond to that.
By doing this, you've knocked out the vast, vast majority of currently successful attack modes, and radically improved the robustness of the system, and its resilience to phishing and identity theft attacks.
*sigh* and of course while trying to complain about someone's writing of incoherent sentences, I write an incoherent sentence.
What I meant to say was:
You're also quoting an Oracle employee who can only occasionally produce coherent sentences (ie, appears to have trouble writing sentences that make sense), and insists on referring to Windows as 'windoze'.
This (RH AS vs. WinXP) is an apples to oranges comparison.
You've got RedHat's most advanced, most highly-tuned for server duties compared to Windows lowest-end, most-highly-tuned-for-anything-but-server-duties.
A correct comparison would be to Win2000 Advanced Server, or Win2003 Enterprise Server, depending on the exact timing of the comparison.
You're also quoting an Oracle employee who can only occasionally coherent (ie, appears to have trouble writing sentences that make sense), and insists on referring to Windows as 'windoze'. This is not exactly your most trustworthy, professional consultant here.
This is trivial to do.
.vbs script easily.
Change the NTFS ACLs such that Users and SYSTEM has an explicit Deny Read.
There you go, 30 second fix, can be packaged into a
Use a Passport Limited Account, and you get a passport without any personal information.
http://www.passport.com/
(The last option under 'Sign Up Today' has the option to create a Limited Account, and information about it.)
Or get a regular passport and put in fake information.
An application pool runs under an isolated process.
Multiple threads (configurable) service requests for this pool, in a pooled, as-available fashion.
So in the current system, you have visibility into the application pools, and you can see how many threads are servicing requests, there is no mechanism to make a given (hung or misbehaving) request visible and killable.
Now granted, this is a very minor feature, as if a typical asp or asp.net script is looping or hung, it'll either time out or be terminated by the system as a misbehaving execution.
So its nice, but the times when you need this granularity is rare.
In fact, the only times I've seen where it would be useful would be in killing runaway perl processes running under IIS. Currently, its difficult to figure out what script, or what request is looping/hung, and there is no automatic timeout for perl scripts or processes.
Is anyone aware of other sites with these articles?
I've never been able to read a story at 1up.com, as their server just never responds, even days after the stories post.
I'm not sure if you're trolling or just havent been much involved in Windows systems in 10 years.
NT == Windows. The last time there was a difference was Windows ME. ME was the last of what you're referring to as 'windows'. NT4, Windows 2000, Windows XP, and Windows 2003 Server (NT4, NT5, NT5.1 and NT5.2 respectively) are all based on the NT line.
Windows is not a single-user system, and applications do not own the system. For some insane reason, there are still some people and some organizations that do their daily work running as a local administrator account. But this is not smart. The correct, safe, and intelligent thing to do is use a non-privileged account for your daily work, and then either use runas (ie, sudo) or login as a local admin account. This is no different than best-practices on any operating system.
The 7-character encryption you're referring to is a full three generations old. The current system does not suffer from this, and hasnt for years.
About the only legitimate complaint about the current password hashing is that all windows systems, across all domains, use the same seed for the hash. Now this has some upsides, in that the same user & same password will work across domains without having to re-authenticate. The downside is that it lets you pre-compute rainbow-tables. If this seed issue is a proble, Syskey is available to you to eliminate this problem.
However, you can use upper-case, lower-case, numbers, symbols, spaces, and higher-order characters in your windows passwords, and passwords can be up to 128 passwords long. Or you can use smart-cards, support for which is built into the OS.
Local security is the same as in any other multi-user system. People are limited only to the files & folders & processes that they have been given privileges to. In fact, its only very recently that *nix file systems are catching up to NTFS and introducing proper inherited ACLs. Not saying they did everything right, but MS was way ahead of the unix world with NTFS ACLs.
It's the other way around, actually.
Windows Web Edition was created to provide a cheap version of the OS w/ IIS that did not require any CALs (Client Access License).
Same for the versions that run on the purpose-built NAS boxes sold by many vendors.
Product segmentation in any industry serves the same purpose: to gain more customers than they'd have without it.
So you charge more for the high end versions to people that want those features and can pay more. You charge less for the versions that are simpler and appeal to those who might otherwise buy a cheaper/free competitor.
No. 0.1% != 0.1
365 days * 24 hrs/day = 8760 hours per year
0.1% downtime = 0.001 downtime
8760 * 0.001 = 8.76 hrs
You're off by two orders of magnitude.
8.76 hrs / 12 months = 0.73 hrs/month = 43.8 minutes/month
One 45 minute scheduled downtime (assuming its scheduled) per month isnt terrible. It's not great, but costs really start to go up as you add nines beyond those 3.
ipconfig /all
I am quite interested to see all of these people who are so gung-ho about switching out of Windows when they obviously havent taken the time to learn how to manage their networks.
... then your network is not well managed, and you need to do a better job.
Regardless of whether you are running Windows or Linux, you still have to learn how to do things like lock down the workstations & servers, how to do configuration management across your entire network at once, and you have to have some way to do automated patch management, and patch verification.
All of these things are fairly easy to do on Windows, and require nothing but free tools and a little bit of effort on the parts of the SysAdmins.
What is sad is that when they switch, they'll probably consult best practices manuals, and actually set up these processes on their linux systems, and then complain how everything works so much better, but they never set up good management processes on Windows.
Bottom line is that to do your job well as a SysAdmin you have to implement good network & system management practices & processes. If you're doing these, then there is zero marginal effort to deploy each additional patch, as your process does it for you, and only notifies you when something goes wrong!
You can do this quite reasonably on either platform, but you have to actually put the effort in, and do more than just run around like a chicken with your head cut off when the latest patch comes out.
If you have to put in ANY extra hours because of a vulnerability like the MS RPC one
With Windows tools you can:
... this is because you can script & automate pretty much every conceivable thing in windows (mind you, I'm referring to 2000 and above).
... windows is written with the assumption that every sysadmin is also a competent programmer, and the tools are focused on that. The equivalent to shell scripts is WSH/WMI/ADSI in the windows world.
- Create (bootable) server images that deploy on either CD/DVD media or over the network (RIS)
- Login remotely if necessary (rarely) or use any of the command line, gui, or programmatic tools to remotely administer any machine. Rather than being limited to just remote shell, you can do remote shell (RDP), remote management via GUI tools (computer management, etc), remote management vs command line tools (resource kit & support tools), or remote management via scripting (WMI, WSH, ADSI, etc).
- you can have a small group of knowledgeable and experienced windows admins
You are certainly welcome to install servers at each location, and depending on the bandwidth available on your WAN link, this may or may not be a good idea.
If you do choose to go that way, you can use DFS and Sites to (automatically) have the clients at each site preferentially use network and file-server resources local, but then failover to the central site if anything should go down.
The comments above are often made by people who are not experienced windows admins. There is very little you cant do via command line, and absolutely nothing you cant do via scripting or programmatic access.
This leads to one of the key distinctions between unix and windows administration
A couple hundred users on one low-end server box is the lower-end of Exchange scaling.
My local department supports a bit over 300 users on Exchange 5.5 running on NT4sp6. The only reason this box ever gets shut down is to apply security related patches. Most of the time it runs at 25% or less processing power (4+ years old hardware), and it could certainly do with more memory (old hardware only supports 512MB) so that the entire store could fit in memory.
This is one of the servers that basically just runs and runs and runs, and you never have to touch it, and it never crashes, over 4+ years (gives you an idea how old the hardware is).
Most months, we have zero (as in not even a minute) downtime.
What most people seem to not understand is that Exchange is a simply gargantuan product, and does have a significant learning curve. But once you set it up and configure it correctly, you can largely just forget it.
As someone posted elsewhere in this thread, you've got to watch out for some of these second rate companies that host Exchange very poorly, or corps thats put some paper-MCSE as the Exchange admin who couldnt even calculate a subnet mask, and they wonder why their box is flaky.
Bottom line, as far as I see it: Its not the software, its the people.