My company has an Exchange 5.5 box on the Internet, directly behind a small Flowpoint router/firewall. I've had to apply about 5 Exchange Server patches since 5/2000 (not counting the NT 4.0 Server patches) but I haven't had a single successful intrustion since original product installation.
Any organization that has a decent firewall in place can block unnecessary ports. That, applying NT/Exchange patches, disabling anonymous/guest accounts, and disabling the mail relay option is about all the maintenance I've had to do on the box.
The server hasn't hit a BSOD, required a mandatory reboot due to software issues, etc. in well over a year and a half. As much as folks bash Microsoft perhaps they should focus their attacks more. Home users on Windows XP Home Edition with an out of the box DSL ISP connection, yeah. Poor schmucks trying to get Windows ME to work with all of their legacy PC games, sure. Some smaller companies still trying to get Windows 95 to keep a session up for more than 2 hours at a time due to memory leaks, definitely.
But as long as IT business staff simply join the Microsoft Security Bulletin mailing list and patch their boxes the Microsoft server line isn't as bad as folks make out. Back when I supported a call center and had a good number of Sun Solaris boxes I recall some instability there for sure. As a matter of fact a lot more instability than Windows NT 4.0 Servers patched at SP6a running parallel.
I'm curious as to those who are bashing the server product line. Have y'all had to actually support these products? If so if you have had PITA experiences with intrusions, exploits, and stability most likely these are due to your own ineptitudes.
This honestly isn't intended to be a troll, but I'm sure it will probably be modded as such. Microsoft has had a slew of issues trying to patch apparently flawed reused code (since all Windows versions are built on top of each other's code, with reportedly Longhorn being the first "from scratch" Windows version). The fact that the same buffer overflows are so pervasive in their product line is inexcusable. Input validation and boundary checks are basics most folks learn in CS101 - Introduction to Programming. You wouldn't expect such flaws in each and every version of Windows software.
All of that being said, no technology area is devoid of security flaws. Look at the recent attention given to H.323 standard vulnerabilities due to default ASN.1 parsing. That affects many vendors and product lines. Today I read an ISC diary entry detailing a couple of exploits that affect non-Windows environments. Apache, OpenSSH, QMail, Sendmail, etc. have all had their share of recently announced flaws.
Of course Open Source Software *should* be more secure since many eyes can review the code as it is maintained and updated. But the fact that nevertheless there are significant flaws and exploits in this area further proves my point. Microsoft is the largest software company on the planet so of course they have a target on their back. There are no doubt many third party organizations dedicated to doing nothing but trying to break Windows in order to submit security reports. Of course there are anonymous black hats doing the same but for other obvious reasons.
If the same manpower and effort was dedicated to breaking Linux and OSS applications (which currently have much less exposure and market share) I am sure that even more holes would be poked into what most folks on this board defend as being the silver bullet against corporate greed, monopolistic tyranny, and gaping security holes.
Checking some of his other websites I found a nice picture of him from one of his long bike trips. He looks like a real sharp one whose viewpoints are to be seriously considered. Truly a Renaissance Man of our time to be reckoned with.
Out of curiosity have you ever worked at a hospital or have any idea what underlying software runs at a hospital? When one of my infant sons was in for multiple heart procedures I actually saw monitoring PC equipment running Microsoft software. And lo and behold I didn't see the nursing staff coming in to reboot every 3-4 hours!
The point is that the software Microsoft scales down for industry-specific usage probably isn't the crap caliber of a Windows ME or XP Home Edition. Many ATMS run a stripped down Windows version and (although I've seen some funny pictures of BSOD's posted on the 'Net) I haven't seen them hacked or crashed everywhere I go.
Can Squid allocate Winsock client connections? Our company has certain non-web browsing apps that don't fall under HTTP proxy. They have to use the Winproxy Services and AFAIK Microsoft is the only solution. *Sigh*
Taking all factors into account. This vulnerability affects many vendors due to standard H.323 implementation which involves ASN.1 parsing. As copied from Packetizer.Com.
H.323 Security Flaw Real, Impact Minimal
(January 13, 2004) Apex, NC - An article published today on CNET and resulting from a security advisory posted by NISCC reported a security vulnerability with H.323. The flaw is related to H.323 and its use of ASN.1 Packed Encoding Rules (PER) for encoding and decoding messages, improper handling of malformed H.225.0 messages, and resource leakage. The security flaw is real, but the impact is minimal.
The primary security vulnerability arises from systems that do not properly check for malformed H.225.0 messages or malformed ASN.1 PER messages or messages of indefinite lengths. As a message is received, it should be checked to ensure that it is properly formed, both prior to decoding and during the decoding process. Thus, the problem is not inherent in the H.323 protocol or even ASN.1, but with the PER or message processing implementations used by some H.323 systems.
Correcting this vulnerability is relatively straightforward and most vendors have already taken corrective action. It involves putting proper constraint checking in the PER decoding libraries to ensure that malformed messages messages are properly discarded and do not disrupt system operation and to check the H.225.0 messages for proper content.
The second class of vulnerabilities relates to resource leakage. This is again due partly to the malformed message not being processed correctly, resulting in memory leaks. It is also due to the fact that some H.323 systems are not proactive in closing TCP connections over which a call is never established. The latter is not unusual, in fact, for any TCP-based system. A default Apache server, for example, will leave the TCP connection established for five (5) minutes before closing the connection. H.323 and any TCP-based system should be more proactive in closing connections to eliminate wasted resources.
While H.323 is the most widely used VoIP communication protocol worldwide, the impact is mitigated by the fact that most VoIP systems are operated on private networks that are out of reach from most hackers who would attempt to exploit such vulnerabilities. What this means is that global long distance networks that presently carry billions of voice minutes each month will not likely to be impacted at all.
Any vendor that implements the H.323 standard is likely suspect. If the ASN.1 parser is built into the stack then it's probably vulnerable. Since OpenH323 is open source of course we could just look at the underlying code for ourselves:-)
You obviously didn't RTFA or look any deeper than "Oooh Microsoft is mentioned. They suck so they're the real bad guys." There are inherent flaws in the standard H.323 implentation. That's why vendors employing this standard are all affected. Nortel, Cisco, Microsoft, et. al. There was another post on this topic that mentioned ASN.1 being the specific piece that's vulnerable. And this is supposedly part of the Linux 2.6 kernel. God forbid!!
No doubt. These VoIP flaws involve flawed implementations of the H.323 standard. They also involve multiple vendors --- including Internet voice/data cornerstones like Cisco and Nortel. So obviously it's not like Microsoft is all alone on this one. This time at least:-0
Cisco equipment can be totally locked up requiring rebooting, for example, due to IOS flaws supporting VoIP. And it affects practically every IOS version that's out there. That is pretty serious stuff in my book.
Sometimes it's better to not immediately bring out the wooden cross and instead focus on the big picture. I've said this for the past few years as VoIP gains popularity. Look at what this technology is based on.
Compare this now. What are the recent major security flaws in telco's POTS implementation? The old "blue boxes" that could hijack payphones back in the day? Or perhaps a caller pretending to be from telco tricking a company receptionist to transfer them to a long distance dialtone? A Cayman Islands area code chargeback scam? All of these are small potatoes compared with bringing the relatively insecure world of IP Internet data into the mix. I sure wouldn't want to be the one trying to make a 911 call and getting dead air because of some new VoIP worm or DDoS attack.
This time I will point a finger. Look at the multiple (and I do mean multiple!!) instances of Microsoft reusing flawed code that doesn't perform input validation or any sort of boundary checking. It's happened over and over again ever for years. It still happens in Windows Server 2003, Exchange Server 2003, etc. Flawed coding and isn't ever put down for the count it seems. And this is supposed to be a key player in VoIP? At least Microsoft isn't. Thank God.
Then take into account how the IP Internet wasn't designed to be secure in the first place. It was intended to be a disaster backup communication method like shortwave radio. And it hasn't evolved from there very much if you really think about it. There are still flawed standards and implementations rampant through the the standard set of IP services. I certainly am not hopping on the VoIP/WVoIP VPN bandwagon for sure. Wait and see how things play out. I know there are problems with POTS and it isn't 100% failsafe. But it's night and day compared with current VoIP.
Reading the Micro$loth Product Lifecycle pages I see that Extended Support for Windows NT 4.0 Server will end effective 3/31/2004. This means that all paid support, patches, service packs, hotfixes, etc. will also cease on this date. Of course the nearer this date approaches Micro$loth could always back down and extend things further. Like they did for Windows 98 as you have mentioned.
But until then I can only base my business planning on what I read on vendor websites. Assumptions and intuition really shouldn't sway me. Of course ditching NT in favor of a Samba server network would be a good alternative:-)
Yep. Just like back when Novell had 70% of the business Network Operating System market share Microsoft came out with 'Services for Netware' that ran on their NT Server platform. Over the next couple of years after its release this was definitely a helpful tool in migrating away from Netware. I had to roll a couple of companies over and found tools like this helpful.
Checking the download site for the final beta 3.5 release I see that it won't run on Windows 9x or XP Home Edition. So I suppose the answer is no.
As for Microsoft postponing the Windows 98 retirement party, they will only be offering paid support and be *possibly* releasing security patches and other hotfixes that are deemed critical. So I wouldn't look for bleeding edge technology (and I do mean bleeding) coming to a Windoze 98 box near you.
Me! Me! Me! But I will be forced to upgrade by the next quarter, however, since Windows NT 4.0 Server will be retired 3/31/2004 and hence all security patches and other hotfixes will disappear then as well. *Sigh*
It has to be super secure. Because hardly anyone is actively running it I'm sure there aren't a wealth of Internet-borne exploits in the wild that would affect it. Kind of like if I took my Tandy 100 minicomputer and placed the phone handset back on its 300 baud modem cradle.
Ahhh. Brings back memories. Razz the old local bulletin boards until I would finally see crawl across the bottom of the display.
Good point. I know that some software vendors I have purchased from in the past have had clauses where their source code is held in escrow. If the company goes belly up then the customer base receives the source code out of escrow and can take off on their own with either in-house or contracted programming work.
Most software vendors who have offered this assurance are typically smaller scale. So this idea is out there indeed.
I used to support Banyan VINES as well. A couple of boxes with StreetTalk enabled for broad WAN usage for Conner (then bought out by Seagate). So I know *exactly* where you are coming from. Banyan folded a couple of years ago, but their ideas were good catalysts for what was to come. They were the true pioneer in this area.
But in terms of a global user acccount/network service implementation that became more industry accepted I would still argue that NDS was the first of significance. I saw a child post on this thread stating that NDS came out before the NT 3.5x domain structure. I don't recall this, as I thought that Netware 4 came out between 1994 and 1995, whereas NT 3.5x predated this a bit. But the old memory isn't what it used to be I suppose.
This isn't a troll attempt, but other than Directory Services, what has Novell introduced or enhanced that was so revolutionary?
I recall working on native Novell products about 10 years ago don't relish back in the day of creating and managing Netware 2.x or 3.x user accounts on each server (with each server requiring its own login authentication). When Micro$loth introduced the NT domain model that raised the bar significantly for NOS'es. Following that Novell came out with Directory Services. That was the first and seemingly last great advance that they made.
As is echoed in other posts on this topic, most of Novell's headlines have involved mismanaging acquisitions. WordPerfect, UNIXWare, ad nauseum. I am almost afraid to see what becomes of the Linux companies they will be absorbing into their quagmire.
Look at how they could take a stable, logical product like NetWare and fail to market it effectively enough to grab what it deserved. They finally moved beyond unstable NLM's crashing and core dumping but what new customers noticed?
You name it. Applet, servlet, whatever. I know the servlet part is reliant on the processing power of the app server. And I know there are other variables. Plus, as you mentioned, the initial JVM load takes awhile as a one-time process.
But all that being said I still think that Java apps execute pretty slow. Not the most scientific statement I know, especially without specs or baseline. But just a statement.
I don't see why it matters in terms of compilation speed. You could use lower level assembly or machine language and even get faster results. But I personally judge a language on its practicality, logic, structure, rules, portability, elegance, security, etc.
All that being said:-| I think that Java in terms of building bytecode, client execution, and server execution is far behind the pack. Unless you have some multiple processor system with tons of bandwidth and memory it seems as if Java code is dog slow. Not trying to troll, just being honest. I can always pick out a website that delivering Java content by the number of times I keep on moving my mouse to ensure my system's still responding.
Man, is anyone out there submitting any new material? This site is starting to read like a Milton Berle joke book. How many "we've said this before" subjects have I seen the past week or two. Jeeezzzzusss!!!
Slashdot Mirror
Count me in. I'll be bringing Circus Atari and Night Driver. Just can't find those damn paddle controllers.
Any organization that has a decent firewall in place can block unnecessary ports. That, applying NT/Exchange patches, disabling anonymous/guest accounts, and disabling the mail relay option is about all the maintenance I've had to do on the box.
The server hasn't hit a BSOD, required a mandatory reboot due to software issues, etc. in well over a year and a half. As much as folks bash Microsoft perhaps they should focus their attacks more. Home users on Windows XP Home Edition with an out of the box DSL ISP connection, yeah. Poor schmucks trying to get Windows ME to work with all of their legacy PC games, sure. Some smaller companies still trying to get Windows 95 to keep a session up for more than 2 hours at a time due to memory leaks, definitely.
But as long as IT business staff simply join the Microsoft Security Bulletin mailing list and patch their boxes the Microsoft server line isn't as bad as folks make out. Back when I supported a call center and had a good number of Sun Solaris boxes I recall some instability there for sure. As a matter of fact a lot more instability than Windows NT 4.0 Servers patched at SP6a running parallel.
I'm curious as to those who are bashing the server product line. Have y'all had to actually support these products? If so if you have had PITA experiences with intrusions, exploits, and stability most likely these are due to your own ineptitudes.
All of that being said, no technology area is devoid of security flaws. Look at the recent attention given to H.323 standard vulnerabilities due to default ASN.1 parsing. That affects many vendors and product lines. Today I read an ISC diary entry detailing a couple of exploits that affect non-Windows environments. Apache, OpenSSH, QMail, Sendmail, etc. have all had their share of recently announced flaws.
Of course Open Source Software *should* be more secure since many eyes can review the code as it is maintained and updated. But the fact that nevertheless there are significant flaws and exploits in this area further proves my point. Microsoft is the largest software company on the planet so of course they have a target on their back. There are no doubt many third party organizations dedicated to doing nothing but trying to break Windows in order to submit security reports. Of course there are anonymous black hats doing the same but for other obvious reasons.
If the same manpower and effort was dedicated to breaking Linux and OSS applications (which currently have much less exposure and market share) I am sure that even more holes would be poked into what most folks on this board defend as being the silver bullet against corporate greed, monopolistic tyranny, and gaping security holes.
Checking some of his other websites I found a nice picture of him from one of his long bike trips. He looks like a real sharp one whose viewpoints are to be seriously considered. Truly a Renaissance Man of our time to be reckoned with.
The point is that the software Microsoft scales down for industry-specific usage probably isn't the crap caliber of a Windows ME or XP Home Edition. Many ATMS run a stripped down Windows version and (although I've seen some funny pictures of BSOD's posted on the 'Net) I haven't seen them hacked or crashed everywhere I go.
Yep. Jane's Addiction's first album. Good one. Jane Says and some other good acoustic tunes.
Can Squid allocate Winsock client connections? Our company has certain non-web browsing apps that don't fall under HTTP proxy. They have to use the Winproxy Services and AFAIK Microsoft is the only solution. *Sigh*
H.323 Security Flaw Real, Impact Minimal
(January 13, 2004) Apex, NC - An article published today on CNET and resulting from a security advisory posted by NISCC reported a security vulnerability with H.323. The flaw is related to H.323 and its use of ASN.1 Packed Encoding Rules (PER) for encoding and decoding messages, improper handling of malformed H.225.0 messages, and resource leakage. The security flaw is real, but the impact is minimal.
The primary security vulnerability arises from systems that do not properly check for malformed H.225.0 messages or malformed ASN.1 PER messages or messages of indefinite lengths. As a message is received, it should be checked to ensure that it is properly formed, both prior to decoding and during the decoding process. Thus, the problem is not inherent in the H.323 protocol or even ASN.1, but with the PER or message processing implementations used by some H.323 systems.
Correcting this vulnerability is relatively straightforward and most vendors have already taken corrective action. It involves putting proper constraint checking in the PER decoding libraries to ensure that malformed messages messages are properly discarded and do not disrupt system operation and to check the H.225.0 messages for proper content.
The second class of vulnerabilities relates to resource leakage. This is again due partly to the malformed message not being processed correctly, resulting in memory leaks. It is also due to the fact that some H.323 systems are not proactive in closing TCP connections over which a call is never established. The latter is not unusual, in fact, for any TCP-based system. A default Apache server, for example, will leave the TCP connection established for five (5) minutes before closing the connection. H.323 and any TCP-based system should be more proactive in closing connections to eliminate wasted resources.
While H.323 is the most widely used VoIP communication protocol worldwide, the impact is mitigated by the fact that most VoIP systems are operated on private networks that are out of reach from most hackers who would attempt to exploit such vulnerabilities. What this means is that global long distance networks that presently carry billions of voice minutes each month will not likely to be impacted at all.
Any vendor that implements the H.323 standard is likely suspect. If the ASN.1 parser is built into the stack then it's probably vulnerable. Since OpenH323 is open source of course we could just look at the underlying code for ourselves :-)
SIP was affected by another vulnerability awhile back, however. So it might affect Vonage equipment, eh?
Cisco equipment can be totally locked up requiring rebooting, for example, due to IOS flaws supporting VoIP. And it affects practically every IOS version that's out there. That is pretty serious stuff in my book.
Sometimes it's better to not immediately bring out the wooden cross and instead focus on the big picture. I've said this for the past few years as VoIP gains popularity. Look at what this technology is based on.
Compare this now. What are the recent major security flaws in telco's POTS implementation? The old "blue boxes" that could hijack payphones back in the day? Or perhaps a caller pretending to be from telco tricking a company receptionist to transfer them to a long distance dialtone? A Cayman Islands area code chargeback scam? All of these are small potatoes compared with bringing the relatively insecure world of IP Internet data into the mix. I sure wouldn't want to be the one trying to make a 911 call and getting dead air because of some new VoIP worm or DDoS attack.
This time I will point a finger. Look at the multiple (and I do mean multiple!!) instances of Microsoft reusing flawed code that doesn't perform input validation or any sort of boundary checking. It's happened over and over again ever for years. It still happens in Windows Server 2003, Exchange Server 2003, etc. Flawed coding and isn't ever put down for the count it seems. And this is supposed to be a key player in VoIP? At least Microsoft isn't. Thank God.
Then take into account how the IP Internet wasn't designed to be secure in the first place. It was intended to be a disaster backup communication method like shortwave radio. And it hasn't evolved from there very much if you really think about it. There are still flawed standards and implementations rampant through the the standard set of IP services. I certainly am not hopping on the VoIP/WVoIP VPN bandwagon for sure. Wait and see how things play out. I know there are problems with POTS and it isn't 100% failsafe. But it's night and day compared with current VoIP.
But until then I can only base my business planning on what I read on vendor websites. Assumptions and intuition really shouldn't sway me. Of course ditching NT in favor of a Samba server network would be a good alternative :-)
As for Microsoft postponing the Windows 98 retirement party, they will only be offering paid support and be *possibly* releasing security patches and other hotfixes that are deemed critical. So I wouldn't look for bleeding edge technology (and I do mean bleeding) coming to a Windoze 98 box near you.
Me! Me! Me! But I will be forced to upgrade by the next quarter, however, since Windows NT 4.0 Server will be retired 3/31/2004 and hence all security patches and other hotfixes will disappear then as well. *Sigh*
Ahhh. Brings back memories. Razz the old local bulletin boards until I would finally see crawl across the bottom of the display.
Sysop entering...
Most software vendors who have offered this assurance are typically smaller scale. So this idea is out there indeed.
But in terms of a global user acccount/network service implementation that became more industry accepted I would still argue that NDS was the first of significance. I saw a child post on this thread stating that NDS came out before the NT 3.5x domain structure. I don't recall this, as I thought that Netware 4 came out between 1994 and 1995, whereas NT 3.5x predated this a bit. But the old memory isn't what it used to be I suppose.
I recall working on native Novell products about 10 years ago don't relish back in the day of creating and managing Netware 2.x or 3.x user accounts on each server (with each server requiring its own login authentication). When Micro$loth introduced the NT domain model that raised the bar significantly for NOS'es. Following that Novell came out with Directory Services. That was the first and seemingly last great advance that they made.
As is echoed in other posts on this topic, most of Novell's headlines have involved mismanaging acquisitions. WordPerfect, UNIXWare, ad nauseum. I am almost afraid to see what becomes of the Linux companies they will be absorbing into their quagmire.
Look at how they could take a stable, logical product like NetWare and fail to market it effectively enough to grab what it deserved. They finally moved beyond unstable NLM's crashing and core dumping but what new customers noticed?
But all that being said I still think that Java apps execute pretty slow. Not the most scientific statement I know, especially without specs or baseline. But just a statement.
All that being said :-| I think that Java in terms of building bytecode, client execution, and server execution is far behind the pack. Unless you have some multiple processor system with tons of bandwidth and memory it seems as if Java code is dog slow. Not trying to troll, just being honest. I can always pick out a website that delivering Java content by the number of times I keep on moving my mouse to ensure my system's still responding.
Steadman get *that* much closer to marrying Oprah and her millions. But he just can't seem to drag her wide ass up to the altar!
Ayn Rand. Read "Atlas Shrugged" sometime and ask "Who is Bill Gates?"
Man, is anyone out there submitting any new material? This site is starting to read like a Milton Berle joke book. How many "we've said this before" subjects have I seen the past week or two. Jeeezzzzusss!!!