Tuesday, October 14, 2008
In a recent article Tina Holmboe made something abundantly clear that a number of individuals still flatly deny - XHTML is not properly supported in browsers. While sites and Web developers are commonly using XHTML, they are typically using more of a loose HTML version and not really gaining the full power of strict XML rules. Tina also reveals that in addition to dodging browser issues, developers need to make sure they don’t serve real XHTML to devices that don't handle it well. What to do? She presents the appropriate solution - Content Negotiation.
You can read about the context of Content Negotiation for XHTML and HTML here but unfortunately she doesn't actually explain how to accomplish this practically. On Apache it is pretty straightforward: you can use mod_negotiation. However for those running IIS there was no implementation at all for this task. This is the main reason we designed pageXchanger a number of years ago; it also addresses dealing with PNG images in some browsers and not others.
What Tina proposes is to properly serve XHTML; pageXchanger is the solution for IIS. If you want to serve content dictated by device (when the device sends appropriate HTTP Accept headers), pageXchanger can do that. If you want to serve content by language it can do that too.
Unfortunately the market has yet to directly discover the decade-old power of generalized content negotiation (even though our compression products actually require this concept as well). Instead most of those who try pageXchanger seem to mainly use the product to build clean URLs, which is a bit like using a screwdriver to hammer nails – it works, but doesn’t take advantage the best features of the product.
Many search engine "experts" seem to think a clean URL is relevant to indexability and high rank. Don't get us wrong, we like clean URLs more than the next person; we wrote a paper on the very topic. The problem is that determining causality or correlation between query strings and rank is weak at best. It would appear in reality the variability and date information on the page are the more predictive factors, rather than the query string.
Very dynamic pages (regardless of query string or not) aren't going to be favored by Google or any other bot if they change too rapidly. This makes perfect sense; there’s no motivation to index an object that will change in a few moments. While the query string is one clue to non-indexable dynamism, it is certainly not the most obvious; there are a number of headers that show this regardless of URL style. Forget cleaning all tell-tale signs of dynamic pages; page changes are easily exposed by a simple double fetch by the search bot. Maybe you are doing black hat SEO content cloaking or just simply making the mistake of believing dynamic pages can be well-indexed. Regardless of the appropriateness of SEO motivations - clean your URLs anyway. That's just a good idea; even people like Tim Berners Lee think so. You know that guy -- the one who invented the Web?
That said, while we certainly aren't trying to tell people not to use pageXchanger to clean up their urls, it isn't really designed for that. You’ll get the most impact from pageXchanger using it for true content negotiation, allowing you to transparently select and serve language, image, and other content based on the user’s browser or device type. Simply put, content negotiation is a great technology for the diversity of the Web, as one page really doesn't fit all!
Cheers,
Port80
Thursday, June 05, 2008
For many, the most obvious use of our popular
LinkDeny filter for Microsoft IIS Web servers is to block the illegal theft of bandwidth (called leeching), usually in the form of direct image hotlinking. However, LinkDeny wasn’t designed just for that particular problem… In fact, the product aims to provide a multitude of access control mechanisms that can be used on arbitrary URLs. Think of LinkDeny as the step before you force authentication or even the one after authentication, an extra step where you can effectively keep people from abusing your site or application.
One of the most interesting ideas we included was the idea of providing enforced URLs by using a message authentication code (MAC) on the query string. It appears that Amazon thinks this is an interesting idea as well, as they have recently added it to the Web Services APIs (
http://docs.amazonwebservices.com/AmazonDevPay/2007-12-01/DevPayDeveloperGuide/WebQueryStringAuth.html). Amazon calls this "Query String Authentication" or "Pre-Signed URLs".
You can follow the link for the details but here's how it works in a nutshell:
Suppose you have a product that stores data using Amazon's Simple Storage Service (S3) and, to keep things simple, that also uses Amazon's billing and account management service (DevPay) to make sure you get paid when someone uses your product. Now it might be very convenient in this situation if you could give third parties (your customers) direct access to your S3 data, without having to proxy all their requests. The question arises though: how can you do this while still getting paid for the use of the data?
The answer is that you can provide your customers with a URL to use that is "pre-signed" with a secret (a key) that only you and Amazon know about. If someone tries to get at your data to whom you have not given this magic URL, they don't get a thing. The URL itself becomes an authentication mechanism for your legitimate customers.
The recipe for doing this is not complex. If you have an Amazon Web Services account, you already have a secret key, plus an identifier (an access key id) that corresponds to it. When forming the URL, you simply use that private key to hash various elements of the request, and then pass that hash, along with the access key id, on the query string. To prevent replay attacks, you also pass an expiration time. On the S3 side, Amazon's authentication routine simply takes access key id, looks up your corresponding access key, and uses it to recompute the hash on the request. If the hashes match, they know this request is authentic, and the data is sent back.
The neat thing about this is that the entire authentication is handled in the URL itself. There are no other HTTP headers or handshakes or anything of the kind. Making your data available, while restricting it to authenticated users, becomes as easy as exposing a URL.
Now, this happens to be the same basic approach that LinkDeny can take, in order to prevent your valuable external files like images and scripts from being hijacked. This is called the LinkDeny URL Time Limit feature. The difference between LinkDeny's approach and the Amazon API is that all you have to do is supply a mask (a sequence of arbitrary characters) in the URLs that are in your source code (for instance, the src attributes of your image tags) -- and LinkDeny does all the rest.
As your pages are sent out from the server, the mask in those URLs is replaced with a time-limited MAC that is based, as in the Amazon scheme, on a private key. This is analogous to your providing legitimate customers with pre-signed URLs for all your dependent files. That would be impossible to manage manually of course, but LinkDeny handles that part for you, keeping track of the currently-valid requests and rejecting any that hit their expiration time-outs, or that lack a valid signature. While the basic use for this is to protect images and other page elements, you could easily adapt it to a
RESTful Web service as well.
So there you have it, if you want to provide a
RESTful Web service via your URLs, either purposefully or by accident, it is time to install
LinkDeny and enjoy the same protection Amazon does -- without all the code!
Cheers,
Port80
Wednesday, May 28, 2008
Here is a short and sweet list of free IIS security tools by Kevin Beaver @ TechTarget (he wrote the classic Hacking for Dummies):
http://searchsecurity.techtarget.com.au/articles/24798-Free-tools-to-improve-IIS-security
Port80's HeaderCheck and other free HTTP analysis tools are mentioned in there as well (toot-toot goes the horn), but it is a useful list of tools. And free is nice, given the price of gas and all!
Cheers,
Port80
PS Our Deal Packs are not “free“, but they are a little lighter on the ol' budget -- check them out at http://www.port80software.com/deals/.
Wednesday, May 21, 2008
Given latency and constrained connections out there, if you ever receive this download warning, make sure you have lots of food and water stored up for the wait:
http://www.w3schools.com/downloadwww.htm
There are some files even HTTP compression and caching cannot help!
: )
Cheers,
Port80
Learn how to send less data, less often in this new archived webinar from Port80 Software!
Port80 Software invites you to view a webinar on Web performance solutions... We recently reviewed the Web acceleration market, where Port80 Software solutions like httpZip, ZipEnable, CacheRight, and w3compiler come to play on IIS Web server performance, and how to analyze HTTP compression and Expiry Cache Control solutions with HTTP analysis tools.
Agenda -- Web Performance Solutions for Microsoft IIS Web Servers:
- Common Web Performance Challenges
- The Web Acceleration Market
- Analyzing the HTTP Request/Response Cycle
- HTTP Compression
- Expiry Based Cache Control
- Questions and Answers...
Login to Access the Archived Webinar:
- Go to https://www119.livemeeting.com/cc/port80/view?id=Web_Performance_Solutions_1.
- Enter your name, the Recording ID if not already entered (Web_Performance_Solutions_1), bypass the Recording Key (this is not required), and then click View Recording.
- You will be presented with two format options on the next screen:
- We recommend choosing the second version as the first version does not include video.
- Click the Windows Media icon under ‘View’ for the Microsoft Office Live Meeting Replay version, and this will launch the Webinar in Windows Media Player (http://www.microsoft.com/windows/windowsmedia/default.mspx).
- If you have any trouble logging into the Webinar, please just ask for help at support@port80software.com.
Thanks for watching, and please let us know if you have a topic for our next webinar event or if we can answer any questions on IIS performance!
Best regards,
Port80 Software
Monday, April 28, 2008
The recent wave of SQL injection attacks has made mainstream news, just in case you have not seen it:
Hundreds of Thousands of Microsoft Web Servers Hacked
Jeremiah Grossman and others have made the point, accurately, that this is not a Microsoft IIS Web server issue, but rather that Web developers not adhering to security best practices are to blame (for shame, it is not like we have enough to do already!):
Security expert: Don't blame Microsoft for mass site defacements
To solve this puzzle, look no further than controlling parameters, permissions and sanitizing your inputs with a Web application firewall or WAF like ServerDefender AI or the upcoming ServerDefender VP. Yes, you can learn to write more secure code, but why wait to get protected or deal with recoding legacy bits? Get a WAF, and get PCI complaint, something we all need to be focusing on now.
Cheers,
Port80
PS BTW thanks to Jeremiah for being one of the early believers in ServerMask... it is nice to watch as his security star rises!
Thursday, March 06, 2008
Minor releases rarely get headlines, but why not? They are important as well!
This interim release of httpZip has important changes for improved reporting and swatting a few bugs, so if you are a Zip customer or a just checking out HTTP compression, download the new bits. However, get ready for a major httpZip upgrade in the future, as 64 bit is on the way. We are working on getting the code out to our beta testers as soon as we can.
So, if you aren’t on the Zip bandwagon yet, remember that even with massive broadband penetration, your Web users always want more speed (http://www.emarketer.com/Article.aspx?id=1006022).
More to come,
Port80
Thursday, February 28, 2008
In the spring of 2003, as Microsoft was touting Windows Server 2003, a group from Port80 Software trekked up to Microsoft WHQ in Redmond, WA and had a meeting with the IIS team. We had all sorts of ideas for where they should take the Internet Information Services Web server, and with Port80 being new on the scene with its then four products for IIS, we wanted to know where Microsoft planned to go with IIS in the future. We were talking Apache and its culture of modules to extend Web functionality that dominated and gave competitive advantage to the open source Web server. Microsoft’s IIS folks understood this (which surprised us), and they said that IIS 7 would be worth the wait...
Fast forward to February 27, 2008, and the hottest new feature in the (formerly Longhorn) now shipping Windows Server 2008 is... IIS 7! Unless it is the focus of a news or blog piece, IIS 7 is usually the last feature brought up in discussions of Server 2008, but at least during this launch, IIS is a major selling point for the OS for once -- and rightfully so.
Here is why Port80 Software is excited about IIS 7, Microsoft’s lucky number Web server:
1. IIS 7 is modular by design.
As one early adopter from an Australian bank put it, “Server 2008 and IIS7 represents one of the more exciting developments in hosting because the ability to integrate third-party modules into IIS7.” Though you could always build out new Web server features with ISAPI on IIS 4/5/6 on Windows NT/2000/2003, the interface was purported to have issues. Good ISAPI filters are possible if you know what you are doing and have a lot of practice, but Port80’s tech teams are excited to code new IIS 7 modules with the same API that Microsoft’s team used to build IIS 7 itself. A better foundation will make for better enhancements to the Web server. Of course, this modularity is also a security feature, as you have the option to only deploy the pieces of Web server functionality that you need (however, do note that there are some reasons that a few deeper aspects of IIS will live no matter what modules are deployed, but on the sly).
2. IIS 7 has a new GUI.
Microsoft has always had a good track record with UI design, but this advantage was never pressed in their Web server software. Though IIS 6 did offer some UI changes, it is nothing like IIS 7, with different panes for tasks and the ability to marshall more data and Web server control at once. Besides, what Web admin isn’t sick of the old UI? Everyone likes a new dashboard:
:
3. IIS 7 also has no GUI.Now it is possible to run IIS 7 with no UI as a
Server Core installation (you can’t do this just yet with ASP.NET, but look for an update there soon). Less resource intensive as the Server Core option simply uses less disk space (only a gigabyte to run it all), it boots faster (some claims of speed reduction by two thirds), and finally less moving parts again reduces the potential attack service. When you combine this Windows 2008 GUI-less environment with the
Power Shell interface, you begin to seriously erode the perceived Apache advantage of command line automation.
4. IIS 7 performs well.Check out these comments:
“We also tested IIS 7 via Web get/posts using inclining concurrency of the get/posts (using static pages), and found that there was no additional performance advantage of Windows 2003 over 2008 server editions until concurrency (number of users getting and posting) was raised significantly, where Windows 2008 and IIS 7 became very fast compared with Windows 2003 and IIS 6,”
Network World found. Lot’s of POSTs in Web 2.0, good for IIS 7…
“Internet hosting company
Rackspace has found that hardware requirements have decreased 16% to 35% per cluster by using IIS 7.0,”
per Information Week. The focus on doing more with less pays off here…
"The memory handling is extremely improved over 2003 and we'll be able to run more websites per server," said that same early adopter at
that Aussie bank we mentioned earlier.
More features and IIS 7 still delivers more requests on less hardware. What’s not to like?
5. IIS 7 leverages a better TCP/IP stack for more connections, especially on 64 Bit.We all know 64 bit is going to be the standard in high performance Web server OSes, but it is nice to see the whole thing coming together in Windows 2008. Here is
what ServerWatch had to say:
“Finally, although there has long been a 64-bit version of Server 2003, it's only with the introduction of Server 2008 that companies will be moving to 64-bit hardware in significant numbers as they refresh their server rooms. Because of the way TCP/IP connection states are stored and the fact that 32-bit systems can address only 4 gigabytes of RAM, 32-bit systems have in effect been limited to around 20,000 to 30,000 connections per machine. Since 64-bit machines running Server 2008 Enterprise Edition can address 2 terabytes of RAM, IIS 7 running on these machines has the potential to maintain many, many more TCP/IP connections than it (or any other Web server) would on 32-bit boxes.”
As we are currently working at Port80 Software on our own x86-64 Bit code, we were excited to see that IIS 7 shines in this context.
6. Finally, you can use the Web-based UI in IIS 7 for easier administration.No, we will have six points in this IIS 7 review, but it is true that you can finally safely administrate IIS over the Web without terminal services, RDP or a control panel. Turn on the built-in functionality, and administer IIS 7 over the Web -- once you have locked that box down, of course!
7. Microsoft is opening up officially, Web app-wise, with IIS 7."Today, Windows [or IIS] is becoming the most popular platform on the planet for running PHP applications, which has a certain irony to it,"
Steve Ballmer said recently.
FastCGI, a module that ships with IIS 7, makes it super easy to host application frameworks such as PHP, Ruby on Rails and Perl, and then applications built on those Web app platforms can run on IIS 7. No longer should you tie the app development environment to one type of Web server: develop where and in what you like and then deploy on *NIX or Windows, Apache or IIS. With all of these new features, Apache admins should at least take a fresh look at IIS 7.
We at Port80 Software would like to congratulate the Microsoft IIS team on a great job of not only building a stellar new Web server, but in their commitment to the IIS community with the very active site
http://www.iis.net, which just got a new face lift. It is a good week for Web serving, and we look forward to seeing what customers have to say on Windows 2008 and IIS 7 in the real world.
So after all this, you might wonder what are Port80’s IIS 7 plans? Well, we are certainly working hard on it. However, truth be told, what customers so far are really clamoring for right now is x86-64 bit support for our current world renown products on Windows Server 2003. To meet this demand,
httpZip will be the first tool to support 64 bit on IIS 6 shortly, to be followed quickly by most of the Port80 product line for IIS. IIS 7 products and .NET platform products of course are also in the works. With all this change in the air, we invite customers to
join our new beta program to be the first to get your hands on IIS7 and 64 bit code from Port80. Beyond that, we hope that you will let us know what you would like to see in the world of Windows Web serving. What is keeping you up at night concerning IIS and HTTP?
Cheers,
Port80 Software
Friday, February 22, 2008
FACT: HTTP Compression really improves Web serving.
FACT: Big sites like Google and Yahoo! use compression.
UNFORTUNATE FACT: Some services are not aware enough of compression and may break... unless you have a smart compression engine!
This underutilized technology transparently reduces the size of all text-based content served from a Web site or Web service, speeding up transmission across the Web, reducing bandwidth expenses, and freeing up Web server availability to handle more requests. Compression deployments are accelerating among business sites, and Google.com has been compressing responses for a long time (see this real-time report: http://www.port80software.com/tools/compresscheck?url=www.google.com).
Google’s Googlebot, their Web crawler that indexes sites to form the basis of search results, also likes to see compressed content. At a search engine conference a few years back, search guru Danny Sullivan spent some time focusing on this: Google only indexes so much of a page, so if you send the Googlebot compressed content (which it asks for by the presence of the “accept-encoding: gzip, deflate“ header in a request), you can theoretically get more content indexed and save bandwidth on that request from Googlebot and all other requests to IE, FireFox and other browsers and search bots with HTTP compression. Very cool.
It is ironic then, given Google’s knowledge and use of HTTP compression, that Google's AdSense program, which sells contextual advertising on third party sites, use technology that is not compatible with HTTP compression. One of Port80 Software’s httpZip compression clients received this email recently from Google’s AdSense team in response to why the Port80 client’s contextual ad site was not getting index by the AdSense crawler bot program (which goes by the user-agent name starting with “mediapartners-google”; a user agent is the Web client’s name, usually a browser or bot)... this is part of the email from a Google AdSense rep to our client:
“I've reviewed your site and have determined that our crawler is having difficulty accessing your URL. Specifically, your webserver is sending our crawler HTML in a compressed format, which our crawler is unable to process.
We recommend that you speak with your web administrator to ensure your system does not send our crawler compressed data. You can determine our crawler by looking for user agents starting with 'Mediapartners-Google'.
Additionally, please be aware that after you have turned off the encoding, it may be 1 or 2 weeks before the changes are reflected in our index. Until then, we may display less relevant or non-paying public service ads. You should expect your ad relevance to increase over time.”
So, the AdSense crawler bot does not like HTTP Compression. But the real question is -- why are they asking for it? In the request to get compression from any Web server, a user agent must first have that “accept-encoding: gzip, deflate” header in the original request… if the AdSense bot cannot deal with compression, it should not be requested by the bot itself. That makes sense, right?
It looks like Google AdSense is asking clients to not compress responses to their bot to fix this issue, rather than fixing the decompression bug (an educated guess) in their bot code. So, the fix for now if you have a Web server, are in the AdSense program from the serving side (you host Google AdSense ads on your own site), and still want to use compression for all other Web visitors, an exception must be made for any request with a user-agent starting in “mediapartners-google”.
Unfortunately, you cannot do this on Microsoft IIS 4 or 5 servers (NT or 2000) without a third party compression tool like httpZip from Port80 Software that can add a compression exclusion for a user agent. On IIS 6 (Windows 2003), you can use httpZip or ZipEnable to add such an exception or exclusion. We will be adding the default exception for this browser to a minor version upgrade of both products soon, but here is how to add an exception for this AdSense bot with httpZip and ZipEnable.
Excluding Google’s AdSense Bot IIS Compression with httpZip:
- Install the free httpZip trial from www.httpzip.com/try.
- Once installed, confirm compression is working fine (http://www.port80software.com/products/httpzip/evaluationguide).
- Open the httpZip Settings Manager.
- On the compression tab, to add a new Browser Exception for a MIME type, select "New" and, in the Add Browser Exception dialog, enter a Browser Name (like “AdSense Bot”) for the browser in the text box labeled "Browser Name." Next, enter the search string text used to identify the browser (use “mediapartners-google” to get all versions of the bot, this short version will wildcard for specific software versions of the bot) in the text box labeled "Search String", then click OK. Please note: you will have to add this for the MIME types being requested by the bot, which should include “text/html”, “text/css”, “text/javascript”, and “application/x-javascript” MIMEs, and probably a few more, based on what you are serving and want to get indexed.
Picking a MIME (text/html) to Exclude the AdSense Bot from compression:
Setting up the AdSense Bot Exception for text/html MIME:
- Apply your settings in the httpZip Settings Manager. Repete proces for other MIMEs that you want to get indexed (FYI, text/html should take care of most dynamic content output from ASP, ASP.NET, CFM, PHP, JSP, etc. files).
- You can use Wfetch, a free tool in the IIS 6 Resource Kit, to test that no responses will compress when requested by the AdSense bot (http://support.microsoft.com/kb/840671). Just add these headers to a request in Wfetch (“accept-encoding: gzip, deflate”), and the response from the server with the new httpZip exclusion will not be compressed (it should have no headers like “content-encoding: gzip” or “content-encoding: deflate” in the response from the Web server and is therefore not compressed).
- All your other requests from good browsers and bots will now be compressed while you can feel safe that you are not messed up with the Google AdSense bot. Remember, it may take a few weeks for the AdSense bot to reindex your site correctly.
You can add an exclusion to compression requests from the AdSense bot on IIS 6 with ZipEnable by following the instructions above and adding an exclusion directly in ZipEnable -- here is the documentation for that process in ZipEnable (http://www.port80software.com/products/zipenable/docs#adv_set_browser). You will also want to use something like Wefetch that will allow you to alter your request headers so you can trick out the user-agent and make sure you are getting no compression when the user agent includes “mediapartners-google*” (make sure the search string is a wildcard implictly in ZipEnable , a bit different than in httpZip: “mediapartners-google*” ).
We hope this helps clear up any confusion on Google AdSense and HTTP compression – please contact us for help here and for other tips on IIS performance boosts!
Best regards,
Port80 Software
Wednesday, January 23, 2008
Happy 2008, folks. We have been in offline blog mode for some time, but we are getting back on the stick here for the new year.
Look for an update e-mail tomorrow from Port80 Software with information on IIS 7, httpZip 4.0 for IIS compression with 64 bit support (we are looking for beta testers), ServerDefender AI 1.1 (with some new features and a helpful evaluation guide), and a list of good Web dev and network freeware tools.
We also just got an e-mail from IIS guru Brett Hill that announced the IIS Team at Redmond has released a new IIS migration tool. They are looking for us in the IIS Community at large to use the tool and maybe give them some feedback. Here are the details copied below.
More to come in from the Port80 Team in 2008 (including httpZip.NET and a new ServerDefender VP tool). Windows Server 2008 is going to be an interesting launch given Vista and the direct impact of a whole new IIS in the 7.0 version. We have our own lists, but what are your key IIS challenges for 2008? We would love to hear what you are up to!
Cheers,
Port80 Software
FROM THE MICROSOFT IIS TEAM:
IIS is thrilled to announce the Technical Preview 1 release of the Microsoft Web Deployment Tool! The tool provides deployment and migration support for IIS 6.0 and 7.0. It incorporates many features that enable web server administrators to deploy, sync and migrate sites, including configuration, content, SSL certificates and other types of content associated with a Web server.
This tool can be used on Windows Server 2008 and IIS 7.0 as well as Windows Server 2003 and IIS 6.0. Please note that this is a Technical Preview release of the tool and should not be used on production servers. For a Tech Preview, only forum level support is available.
How to Get Started
Download and read the walkthroughs: http://go.microsoft.com/?linkid=8100895
Download the x86 version: http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1602
Download the x64 version: http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1603
Web Deployment Tool forum: http://forums.iis.net/1144.aspx
Web Deployment Team blog: http://blogs.iis.net/msdeploy/
Features
The following list contains several of the features in this version:
· Synchronization and Snapshot of IIS 6.0/IIS 7.0:
The sync operation provides administrators with a way to quickly synchronize a site or server and deploy changes to existing sites and servers. A synchronization allows you to synchronize one source with one destination. For example, you can synchronize two directory paths or two web servers. The sync can be performed with local or remote objects.
The snapshot, or archive, functionality allows administrators or developers to quickly take an archive of their web site or server for rollback, restore or backup purposes.
· Migration from IIS 6.0:
The migrate operation provides administrators with a way to migrate sites or entire servers from IIS 6.0 to IIS 7.0, including their settings and content. A migration is essentially a way of synchronizing, filtered by migration rules. For example, when migrating from IIS 6.0 to IIS 7.0, MS Deploy will check the value of some properties and see if it is the IIS 6.0 default. If it is the default, such as the log files directory, it will instead use the value set on the IIS 7.0 server. This enables a server admin to maintain new settings on IIS 7.0 while moving sites or applications from IIS 6.0.
· Analysis of IIS 6.0 Installed Features:
The analyze operation allows administrators to check what components are installed on the source server. In this way, they can determine if features are present that they will need in IIS 7.0 or that require more advanced setup than simply copying files. For example, ASP.NET requires more than a file copy and will need to be installed on the destination server.
· Troubleshooting and Validation Features:
For validating an operation, the -whatif flag allows administrators to see what actions would happen when they perform an operation. This is especially useful for performing sync or migration, when they want to validate what changes will be made before performing them. For troubleshooting, the -verboseLevel flag allows administrators to get rich detail about what operations are being performed, and upon failure, the ability to diagnose the problem.
Monday, October 22, 2007
Hello there,
We have been mentioning a new Web app firewall since this spring at TechEd, and we are happy to announce that the new ServerDefender Artificial Intelligence (or ServerDefender AI for short) Web application firewall for Microsoft IIS Web servers (and the app layer) is ready for your review at our site!
Building on the security layers of defense from ServerMask and LinkDeny, ServerDefender AI offers solid attack signatures from SANS, OWASP and our own research to protect against the myriad attacks we have all come to know and loath like SQL injection, buffer overflows, cross-site scripting (XSS) and request forgery (CSRF), directory traversal, zero-day, brute force, dictionary, denial of service and others (here is our new Port80 review of Web app attacks and countermeasures). ServerDefender AI then employs a learning Web app firewall that maps your normal traffic and then begins to use this data to detect and block anomalies. You can get involved in this training process or set the AI to train without your supervision. This Web app firewall not only protects IIS, but your app server layer(s) like .NET, .asp, .php, .cfm, Java server pages, etc. -- and of course your database’s precious gems as well.
Other key features include request throttling (controlling frequency of requests to a given page to block bots and other attacks), network-layer IP blocking (threats never even get to IIS), threat management options (a configurable framework to customize Web app sec), notification alert management (get paged, texted or even stop IIS in the event of an attack), detailed logging (you will be surprised how many hacker requests your site is getting right now), and much more.
We kept the price low for a Web app firewall that works at $649.95 per IIS instance, and this is a first tool from Port80 Software to offer centralized deployment (install/activate) and management from a single console. Server Defender AI will even stop IIS in a very bad hack attempt (based on your preferences). Check out ServerDefender AI today, and let us know what you like and what we can change to make this security solution more robust.
At the same time, we are working on a sister Web app firewall, ServerDefender Vulnerability Protection (VP), that will focus on input sanitization and attack vectors like error information leakage -- adding effective Web app security with less frills than ServerDefender AI, but at a lower price (we are targeting $349.95/server for ServerDefender VP).
We appreciate your interest and feedback on ServerDefender AI and IIS security. Let’s make it a bad day for hackers, indeed.
Sincerely,
Port80 Software
P.S. We also have a current promotion ($600 down from $850) on the ServerMask ip100 security appliances for intrusion defense and anti-reconnaissance. Check out this deal for better network-edge defense that works in tandem with Port80 origin server security tools (and your existing hardware firewall and IPS solutions)!
We are all for futurism here at Port80.
It is important to look ahead to what is coming, and make dreams become reality. So, when Vint Cerf says we will have an Internet capability in space by 2010, it worth noticing... This type of vision makes sense, given the success and number of unmanned, robotic experiments taking place in our solar system right now. Pretty cool stuff:
http://physorg.com/news111816547.html
But, when we start to hear Web 3.0, we have to laugh. Ask 10 smart folks in our industry about Web 2.0, and you are liable to have 10 different definitions. It is less than a decade since the golden days of the Dot Com MOAB, but with all the real work we have to do serve complex Web apps today, do we need more snake oil sales blabber?:
http://bits.blogs.nytimes.com/2007/10/19/what-i-meant-to-say-was-semantic-web/?em&ex=1192939200&en=3c233d05e8ff4dd3&ei=5087%0A
Have a good one,
Port80
Wednesday, August 22, 2007
Last week, we released our updated surveys of Fortune 1000 Web sites and the Web technology they use to deliver their sites.
Port80 Software has been conducting this survey since 2003, when we felt there was so much negativity out there on Microsoft IIS. Apache, long loved in the open source community and more widely used than IIS, and the Apachephiles themselves were always kicking sand in IIS’ face. So, IIS’ ongoing lead in our Fortune 1000 survey as the Web server of choice (it still leads with 55% share in July 2007) has been a kind of a counterbalance against Netcraft’s surveys that had promoted the concept that Apache is so much more widely used on the Internet than IIS -- so much so that you needed to have your head examined if you were still running IIS. Or so the headlines told us…
Recently, IIS has been adding sites in Netcraft’s survey relative to Apache, gaining on the open source superstar, and this has upset folks in that camp. Having blasted IIS for years, it must sting a bit to have the tables turned. Our latest survey only strengthens the argument that IIS is on the rise, and the much-anticipated IIS7 release in Windows Server 2008 probably won’t help the numbers for Apache in the future.
But this story is really all old news. True technologists know that is not so much the platform that you are building upon but rather what Web site or application you are building, that makes the difference. Yes, we are an IIS shop, and yes we have stoked the fires of this somewhat religious Web server battle for supremacy, but at heart we know that IIS and Apache offer two different ways to serve Web content, two different ways to skin the Net cat, so to speak. Also, it is important to note the small but steady rise in alternate Web servers in the Fortune 1000 survey which demonstrates that IIS and Apache are not the only players here.
Port80 Software was recently quoted as saying that IIS is more difficult to tune and manage than Apache -- we do not believe that. Rather, this is the common perception among those unfamiliar with IIS or already in the Apache camp to say that “Apache is more secure” or easier to administer. From Port80’s perspective, it is not what you serve with, but how much you configure, add on new functionality and work to solve tech and business problems.
We will keep producing our survey, as long as Netcraft is out there, to provide an alternative perspective. But that’s all it is -- one more slice of a very complicated Internet, one more story of technology in use, one more stat in your inbox.
Back to work,
Port80
We released LinkDeny 1.1 last week with some fixes and new features worth the mention. For customers and test downloaders, this is a freebie update:
Changes in LinkDeny version 1.1 (8/2007):
1. Updated GeoIP.dat file for most current IP address and geographic data.
2. Altered type of HTTP redirection for this Action option from temporary redirects (302) to permanent redirects (301).
3. Added feature to update IIS logs with proper HTTP status code when LinkDeny action is taken like 404 error response or 301 redirection response.
4. Fixed various bugs in the Time Limit Test, both functional and UI.
5. Fixed UI bug that caused crash when many LinkDeny rules were loaded in the Settings Manager.
Also, we are working hard to release ServerDefender Artificial Intelligence (AI) in the next few weeks, the first of our two new upcoming Web app firewalls…
More to come,
Port80