THE OFFICIAL BLOG OF THE SBS "DIVA"

Susan,
It's nice to find you are so trusting... of course, this "robot exclusion" is only good for robots that observe the rules. Also, websites can be scanned by robots or people to discover content which is technically different but has the same end result.

1. If you have something really private exposed to the Internet, don't trust anybody, don't trust any generally observed but unenforced standard.

2. If you have anything really private you wish to keep private, secure by requiring authentication. Microsoft technologies supports one easy to configure, strong method... NTFS permissions. Like on the LAN, it's cool to secure resources granularly at the file level. Note that this requires Windows Authentication, you can't disable Windows Authentication and still enjoy the benefits of NTFS. Files stored in a database can also be secure, for example Windows SharePoint Services (ie. Companyweb) stores files securely in a database instead of individual files so although NTFS is not part of the security solution, it still employs good Windows Authentication to access files.

3. Not all website resources can be secured with Windows Authentication, alternative Authorities might be set such as RADIUS or most often a simple list of authorized Users stored in a table. You will not benefit from Security Policies already in place, so in these cases you will be pretty much on your own designing proper security which is more often done poorly than not.

4. Don't secure only the gateway to resources. This used to be very common in the early days of the Web, but poorly designed private areas may only secure the login page assuming that is sufficient overlooking the fact that anyone who knows the URL of a private resource can bypass the gateway and be browsing your private resources without being challenged. This is similar to the ever-trusting SysAdmins who rely only on a firewall but ignore what might happen if someone is able to bypass the firewall and have full run of the internal network without being challenged.

Bottom line is that if you have something really important, either rely on a known good solution such as a Web Portal solution (like Companyweb) or put in the work to secure your web resources properly.

Tony

Regarding the specific supposed vulnerability or whether we should even care whether logon pages are collected in the Google (or other search engine database)

- In general, there's probably no useful or worthwhile purpose for a logon page to be indexed and stored publicly, so in keeping with "divulge only as much information as necessary" instructing spiders not to index the logon page can be recommended.

- Conceivably if a vulnerability should be found in SBServer, such an index might be useful for a hacker to locate victims quickly.

- It's my opinion that if known "best practices" logon policies are applied to authentication and simple passwords are made impossible, there is no significant additional risk compared to if logon pages were not indexed. The point is that logon pages are easily discovered using other methods than doing a Google search.

An example of probable faulty vulnerability evaluation is the "Google Hacker's" index of OWA logons. Because by default GPO Password Policy is applied to logons, ordinarily this is not a vulnerability. Normally three failed logins will force the hacker to wait 30 minutes before trying again. Bad Password Policy will hurt you in many ways, not just OWA or RWW (the supposed Google database index that found your server). And, there is no hiding what your server is, it's too easy to fingerprint your machine.

Tony