We recently looked at KaVaDo's Webservice firewall application, InterDo , which is an excellent way to prevent attacks on web-based systems. ScanDo, the package's sister product, handles the other half of the web security function – proactive scanning of websites to identify potential security issues. Unlike packages like ISS Internet Scanner, ScanDo isn’t restricted by its licence key to probing a limited set of servers, so you could in theory use it to probe other people's sites for vulnerabilities, but the company is confident that since it knows who owns what, reports of unwanted probes could quickly be traced back to the licensee. Crawling
Once you've told the package what websites it's licensed to use, the first step is to allow it to ‘explore’ the items that you want to probe for security holes. ScanDo will then crawl over the site(s) and discover what lies therein. Depending on the size of the site (we had about 4,000 pages on our sample site) this can take a while, but you're given ample progress information, along with a window that alerts you to any errors the system finds as it goes through (pages missing, server errors and such like). There is also, incidentally, an option to perform a single ‘manual’ probe on a site or page, which is useful if you're trying to fix a problem and you don't want to run a whole scan each time you change something and need to try it out. While the scan goes on, you can examine the contents of the various items it's found; there's an Explorer-like two-pane window that lets you select an item in the left-hand side and view its detail in the main pane. It pulls out the various items into categories, so you can look at stuff like comments, links, cookies, style sheets, JavaScripts really easily (it even seemed to lay everything out rather more neatly than it appeared in our original source code, which made for excellent readability). In addition to the ‘virtual’ layout of the site that's shown in the scan results, there's also a ‘File System’ view, in which ScanDo puts what it's found in the order it thinks the items are located on the server hard disk – which will generally be rather like the main scan result screen, but which is a useful alternative view. As the scan progresses, the system will spot links to sites outside your specified URL's hostname; whenever this happens, you're asked if you wish to include the newly discovered site in your list of licensed sites. Once the package has crawled over your target site, the next step is to assess the potential security holes. The assessment process, like the exploration phase, is wizard-based, and you have two main choices – to run a ‘quick’ assessment based on common parameters, or to define your own ‘profile’ that's more closely related to your site. For the first scan, we chose the ‘quick’ assessment; you're given a list of vulnerability types that you can turn on and off, you choose the scan result set you want to work on, and then the system goes away and probes your site. The list of attack types is extensive, and includes (among others) TCP port scans on the server, attempting to insert low-level database queries into URLs that look like they contain SQL, attempting to use HTTP methods (PUT, DELETE and such like) that you wouldn’t necessarily want people to use, and modifying cookie contents in an attempt to bypass security mechanisms. As you'd expect, the ‘profile’ assessment allows you to customise the scan far more than the ‘quick’ one. What you're effectively doing is customising the scan process to your particular installation – so if you're not using databases at the back end, you can tell it not to bother with database attacks, or if you know the Webserver is Microsoft IIS you can set it to probe IIS-specific issues but not bother with Apache, ColdFusion, Domino, etc. You can also set the extent to which vulnerabilities are probed – for instance, you could stop at detecting what HTTP methods are permitted, or you could go so far as to (say) attempt a PUT or a DELETE to check if they can be executed. The ‘profile’ approach also allows you to be a little more advanced with the way you access the site, specifically by providing a client certificate or by using a username/password authentication mechanism to access the site. These features are important, since if your site requires authentication before it'll let you in, a scanner program's scope would be restricted to server-level probing, not to investigating your home-written site scripts. In addition to the plethora of built-in scripts, there's also a VBA scripting mechanism in the system that lets you hand-craft your own vulnerability tests, though we suspect most people will be happy with what they get out of the box. Aside from the technique-based probes that ScanDo performs, it also works on a collection of ‘CVE’ (Common Vulnerability/Exposure) signatures. There's a handy CVE lookup table that describes all of the vulnerabilities it knows about, with links to the Internet-based CVE site if you really want to know even more (the same applies for the ICAT vulnerability database). As the assessment progresses, ScanDo gradually builds up a list of the vulnerabilities it finds in the left-hand pane of the screen. These are presented as a hierarchy, with the vulnerability types at the top level and with each item broken into high, medium and low threat categories at level two. Each threat item is accompanied by an extensive explanation of just what was tried by the package, and what its implications are. Because we deliberately threw some vulnerabilities in, we weren't surprised to be told, for example, that FrontPage Server Extensions were turned on or that WebDAV had been enabled. ScanDo did, however, also report a couple of vulnerabilities that we weren't aware of – which was a little surprising, but reassured us that you actually do need to consider this type of package if you want a properly secured Website. Like any package of this kind, ScanDo isn't immune to ‘false positives’ – reporting something that looks like a problem but isn't. In our test, for instance, it reported, with severity ‘Medium’, that it had found a script called ‘test.asp’, which (in its words): ‘might indicate that other default settings were applied when installing your webserver’. Actually, this was just a quick script we'd knocked up to verify that the server could talk to the database, not part of the default installation, but on the whole we think it's right for the package to err on the side of caution and report ‘maybe’ issues. The final aspect of ScanDo is the reporting engine, which takes the results of the assessment stage and puts much more meat on the bones. So instead of just telling you what the problem is, it gives some more insight into what you need to do to fix the problems. Most of the reports work on a single session, and you can choose what type of report to include (you might run off a ‘programming practices’ report for the developers, which talks about parameter or database sabotage, and an exec summary for the management). The ‘trend analysis’ is a useful multi-session report, though – it works on a number of analysis results and shows how any changes you've made have benefited (or broken…) the security of your world. We mentioned earlier that ScanDo is a sister product to InterDo; when you've finished the assessment process, ScanDo can communicate with your InterDo firewall installations and configure them to block the vulnerabilities it's found. Again, it's a little wizard that does this; you're asked for the address and authentication details of the InterDo server and it goes away and sets up the right permissions for you. Of course, what you should really be doing is fixing the underlying server problems rather than simply trying to stop people getting to them, but this can take time, and so it makes perfect sense to keep the attackers out using the firewall while your developers and systems guys plug the holes. Like InterDo, ScanDo is easy to get to grips with but flexible. The range of intrusion types it can detect is extensive and, like its peers, it includes by necessity a group of attacks that could kill the server if it's vulnerable, so you need to be a little careful when you use it.


If you have standardised on a certain server platform (or set of platforms) examine the options on the market to see which ones have specific support for the vulnerabilities of your particular platform(s). Be aware also that the most comprehensive packages will be capable of running tests that will kill a vulnerable server, and ensure you have adequate downtime provision and recovery processes/equipment.