| April 2002 | ||||||
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | ||||
| Mar May | ||||||
This site is no longer maintained.
My current weblog.
Tuesday, April 09, 2002Trying to visualize an Array of Array of various Structs and Strings... Wound up taking a dry-erase marker to a nearby mirror. Life would be better if eVB supported classes.
I really need a whiteboard close to my computer.
Stopped by my local Best Buy today. They are selling the Treo 180 at the reported $299 price, via a $100 mail-in rebate. The Zaurus SL-5500 was also on display, conveniently encased in a security device that prevented it's keyboard from being viewed.
Almost purchased a nice belt case for my PDAs, figuring that since I am writing about them so much I should carry one with me more often. But I could not tell if the Zaurus would fit (the Maestro was listed on the back). Next time I'll have to bring mine with me...
Web Services do need protection...
The threat is from Hackers, not Microsoft's desktop monopoly. The article is about a serious security flaw in a specific SOAP implementation, Perl's SOAP::Lite module. If you're using SOAP::Lite, go read that article right now! [via Scripting News]
Bigger picture, the SOAP and XML-RPC specs do not address security, leaving it to the developer to create security at the transport or application levels. This is how BigCos are going to achieve lock-in with SOAP. Each will come up with their own mechanism for Transport security and Authentication. They will not be compatible with anyone else's implementations. Ta-da, you're stuck with Microsoft or IBM or SomeOtherBigCo.
The standards process totally dropped the ball here. SOAP should have had mechanisms for negotiating security from the begining. For implementation ease, the specification could have been as basic as "The TLS 1.0 RFC will be used for transport security. HTTP's Auth model will be used to negotiate authentication. For non-HTTP transports, and implementations that do not control the transport, Auth negotiation may be encapsulated as part of the XML request payload using this format..."
Not particularly complicated. TLS is transport-agnostic. Implementations that depend on an existing web server for transport wouldn't have to do anything, and could negotiate to handle Authentication at the Application layer if necessary (this is important).
Since everything is negotiable, light implementations could simply negotiate no security.
Simple as 3.14159265...
My buddy with the heart attack is being transferred to another facility. They'll be cracking his chest open in a couple of hours, his blockage cannot be reached through the less-invasive methods.
And he is in-between insurance providers.
Ouch.
Sun: Web Services Need Protection. And SBC seems to think that unified messaging services need protection too. It's like everyone is coming out of the woodwork in an attempt to legally prevent Microsoft from competing against them. When is General Motors going to testify? Microsoft killed the Trans-Am!
Here's some reality for SBC: If Microsoft's products work better with Windows than your own, you fucked up, you failed to compete. Microsoft's desktop monopoly affords them a single advantage: getting new products in front of customers. Everything else can be yours for the mere price of an MSDN Universal subscription.
Then again, what would an ILEC know about competing in the marketplace? SBC lead the charge to deny competitors access to RDSLAMs.
It's embarassing to live in a non-settling state.
Microsoft offers free tool for security checks
Called the Microsoft Baseline Security Analyzer (MBSA), the tool is intended to provide users with an easy way to check their systems for common problems that arise when computers are configured incorrectly or when users fail to install suggested security patches, Microsoft said. [IDG InfoWorld]
An ounce of prevention is worth many pounds of cure.
Nimda was bad for my former employer. On the Shared hosting side, we had long been immune to most Port 80 attacks, but Dedicated hosting customers were being infected like crazy. In my "Special Projects" role, I was called upon to do something about it. I wound up creating wrappers for HFNetChk to scan and report on our customers' servers, and created a tool to remotely force a machine to patch itself (very sneaky and not at all difficult). The latter was never used due to legal questions... But I digress.
The Busy Admin's Guide to Securing an IIS Web Server
Disclaimer: Use this advice at your own risk. It cost you nothing, and that's exactly what it is worth. I am not responsible for anything, ask anyone.
-
Secure IIS: Delete the default web site, along with all of it's files, and start over with a fresh one. Disable all ISAPI filters except for asp.dll and ssinc.dll. Index Server's filter in particular is not trustworthy, and if you do use Index Server you're probably querying it with some custom ASP scripts anyway, right?
-
Secure your network: Use your router or firewall to drop all incoming traffic that isn't directed to your public services, including traffic from your LAN! Ideally you should only allow incoming HTTP and HTTPS traffic. Traffic to your remote management service (VNC, Terminal Services, etc) should only be allowed from the LAN and/or VPN server. Strongly consider placing your web servers behind their own router/firewall if there are other servers providing additional Internet-exposed services.
- Secure your server: Disable services that are not necessary. Especially the Server service. If you need to move lots of files around, build or buy something that will "pull" them from a central location instead of "pushing" them.
Following these three simple steps can take just a few minutes and will prevent your web servers from being directly vulnerable to the vast majority of future exploits. Stay subscribed to NTBUGTRAQ anyway, because you do need to remain aware of the rare new vulnerabilities to ASP.DLL, SSINC.DLL, and IIS itself.
This is not defense-in-depth. The truly paranoid, and those running scripts from "untrustworthy" sources (like customers) will need to take additional steps, such as severely locking down the filesystem and thoroughly removing all non-essential services, but this is a good foundation.
Did I ever mention that the Audiovox Maestro comes with a data cable for the Audiovox CDM-9100 cellular phone? I just noticed it sitting on top of the box in my closet. It was thoughtful of Audiovox to include that, even it if useless to the majority and incompatible with all of their other phones.
They've also added the CMDA Thera Pocket PC Phone to the catalog. Having a mere 1100mAh battery (vs. 1400mAh for other vendor's non-phone PPCs), heavy cellular users need not apply.
Audiovox's PPCs support SDIO, how does that compare to other vendors? Bluetooth SDIO cards are available, where is 802.11b? I would think that Palm users would be loving such a card.
Mobile Offline Blogger has been delayed a bit further. In part this is to clean up the codebase. A mess has been created while working around numerous bugs in Embedded Visual Basic. While cleaning up the mess, it made sense to finish the porting of XMLRPCCOM. And finally, this delay provides a chance to improve the editor UI a bit.
Hopefully it will be ready to release in a day or two.
