P r o f e s s i o n a l — M a n a g e m e n t — S o l u t i o n s
RSS icon Email icon Home icon
  • IIS Security Checklist

    Posted on August 15th, 2008 Admin No comments

    The following checklist is a summary of the security points which should be checked prior to bringing an IIS server online. In cases where these points are not followed, the admin may want to securely document the known security issues for referral should a security compromise occur. .

    General assumptions:

    1 No IIS on a domain controller

    2 Install only services needed (ftp, www, smtp, nntp). Mailing out does NOT require smtp; use CDOSYS.DLL (a COM based method native to Windows) or a 3rd party executable like blat.exe for web applications that require outgoing mail.

    3 Virtual directories are NEVER used across servers.

    4 The underlying Windows OS has been secured.

    5 Only system administrators are local administrators.

    Design Guidelines
    1 Websites should NEVER be on the system drive.

    2 Setup SSL if transmitted information is sensitive. Require SSL (Remove ability to access via port 80) if SSL is enabled.

    3 All FTP sites, and as needed WWW sites should enable IP filtering for stanford-only sites. Ipsec filters can be used to accomplish this.

    4 Virtual directories should be used as little as possible. They aren’t needed unless you need to span drives. And if you need to span drives reconsider based on the security implications.

    5 Remove NTFS write perms everywhere possible.

    6 Don’t make it easy to find your scripts and code. Hackers target code seeking vulnerabilities they can use to take control of the server. Good ideas include:

    a Don’t use an obvious name for your scripts directory. ‘Scripts’, ‘cgi-bin’, ‘exchange’, and ‘bin’ are so common that automated tools look for them.

    b Consider renaming the extension on all of your scripts to something uncommon. For example, rename myscript.asp to myscript.dum. This will require adding an ISAPI extension mapping for .dum to the appropriate code handler (asp.dll in this case). This makes your scripts harder to find. Incidentally, specifically renaming all .asp scripts to .html works fine without modifying the ISAPI extension mapping.

    c Consider compiling scripts into dll files. This not only protects the code from analysis, but it also results in a major performance gain. Compiled code runs about 20 times faster.

    d Web applications (i.e. scripts and executables) only need a limited amount of permissions to run properly. Giving more permissions than is necessary allows a malicious hacker to download and analyze your code for vulnerabilities. The minimum permissions needed are: NTFS: Read, IIS: Execute. IIS: Read is NOT required, and will allow a hacker to download your code.

    e Be careful when using the Add/Remove control panel on an IIS Server. If you open the Windows components, Windows will inadvertently reset all ISAPI filter and extensions to the default, and may reset other things. This is a poor design by Microsoft that you need to be careful with.

    Installation configuration

    1 Delete all default virtual directories (icon w/ world on top of folder) and application roots (icon w/ green ball in box)

    2 Delete iisadmin

    3 Delete iissamples

    4 Delete msadc.

    5 Delete iishelp

    6 Delete scripts

    7 Delete printers

    8 Delete ALL default content.

    9 Delete %systemdirectory%\inetsrv\iisadmin

    10 Delete %systemdirectory%\inetsrv\iisadmpwd

    11 Delete inetpub\wwwroot (or \ftproot or \smtproot)

    12 Delete inetpub\scripts

    13 Delete inetpub\iissamples

    14 Delete inetpub\adminscripts

    15 Delete %systemroot%\help\iishelp\iis

    16 Delete %systemroot%\web\printers

    17 Delete %systemdrive%\program files\common files\system\msadc. Only websites that integrate with Microsoft Access databases need msadc.

    18 Configure Default Website with extremely secure settings (e.g. require ssl, Integrated Windows auth only, accessible from only one IP, NTFS perms to none on an empty home directory, etc.), then stop the site. This results in a broken default website that 80% of hackers will blindly attack, instead of your real website.

    19 Configure all website(s) with host header matching the DNS name of the site. Go to ISM, Web Site tab, Advanced button, Select “All Unassigned” (or the specific IP) and Edit Button, and designate the host header in the appropriate field. Do this for both http and https. Do NOT configure default website with host header. This will prevent 90% of all automated hacking tools from working by sending them to your crippled default website.

    20 Home directory IIS perms: Enable Read and Log. TURN OFF Write, Index, Browsing, Script Source Access (only WebDAV uses this), and Frontpage Web permissions. Set execute permissions to None. Enable execute permissions for the directory that holds your scripts.

    21 Disable all unnecessary ISAPI filters. Do this under ISM, ISAPI filters tab.

    a Delete the Frontpage ISAPI filter (or extensions on older IIS servers), if you have a choice. If Frontpage ISAPI (extensions) is required, make them read only. On older IIS servers, you disable Frontpage extensions with the following command: “c:\program files\common files\microsoft shared\web server extensions\40\bin\fpsrvadm –o uninstall –p all”.

    b Digest Authentication. This authentication method requires support for reversibly encrypted passwords—which is a bad idea. Reversible encrypted passwords aren’t supported in the Stanford Windows Infrastructure. Delete this filter.

    c HTTP Compression. This filter allows compression of the http stream. This is a nice feature, but might be at the expense of security.

    22 SSL. It’s unlikely you wouldn’t want SSL support, but if you don’t need it, then delete it.

    23 Delete the dll files associated with ISAPI filters that you disabled. Frontpage: fpexdll.dll, Digest: md5filt.dll, Compression: compfilt.dll, SSL: sspifilt.dll.

    24 Unmap the following extensions (if possible):
    .asa, .asp, .bat, .cdx, .cer, .htr, .htw, .ida, .idc, .idq, .printer, .shtm, .shtml, .stm
    Within ISM, go to the Home Directory tab, and choose Configuration button.

    25 Disable “Enable Parent Paths” setting. Go to ISM, Home Directory tab, Configuration button, App Options tab, uncheck checkbox. This prevents malicious web traversal without knowing the underlying directory structure. Web developers can not use paths like ..\..\default.htm and must use fully qualified paths.

    Patch level

    1 Apply Service Packs and hotfixes. UpdateExpert makes this very easy or Microsoft’s HfCheck tool can be used.

    2 Install high encryption pack (comes with Windows 2000 SP2) so 128 bit encryption is available.

    Authentication model:
    1 Basic authentication disabled at site level, virtual directory level, directory level –Everywhere!

    2 Digest authentication disabled everywhere.

    3 IUSR & IWAM accounts should not be domain users nor should they be guests. If no anonymous access is required, delete these accounts.

    4 If web data is ultra-sensitive consider placing server outside a domain.

    Authorization Changes
    1 Enable IIS auditing, change to W3 extended logging, and check that the info that is being logged is appropriate. (e.g. Is username needed?) Consider enabling the following items: Date and time, IP address of the client, IP address of the server, Server port, Username, HTTP method used to access your site, URI Stern, URI Query, Status of the request.

    2 Set permission to IIS logs to system and local administrators only.

    3 Remove write perms to hklm\software for non-admin accounts. Administrators & System: FULL, Everyone: Read/Execute

    4 Restrict NTFS perms to ALL executables on system. NTFS perms: Administrators & System: FULL, Users: Read/Execute. Give IUSR account execute permissions sparingly.

    5 Restrict perms to any script interpreters such as perl. NTFS perms: Administrators & System: FULL, Everyone: Read/Execute. Give IUSR account execute permissions sparingly.

    6 Ensure Everyone has only read on:

    Web root
    %systemroot%
    %systemroot%\system32
    %systemroot%\system32\inetsrv
    %systemroot%\system32\inetsrv\asp
    %systemroot%\program files\common files

    Share/Save/Bookmark

  • Setup Ensim on Windows

    Posted on July 22nd, 2008 Admin No comments

    The first thing you will need is a Unique Fully Qualified Hostname such as server.yourhostname.com.  Especially with Ensim you do not want to have a hostname that conflicts with any other service, so do not use mail.yourdomain.com or www.yourdomain.com as this will cause conflicts that will cause Ensim to break.

    - Set the Unique Fully Qualified Hostname in DNS so that it points to the primary IP address of the server, such as:

    server.yourhostname.com A 12.34.56.78

    - Set the Unique Fully Qualified Hostname in Microsoft Windows.

    Right click My Computer – Select Properties – Select the Computer Name tab – Click Change – In Computer Name put the host portion of the hostname of the computer such as server – Click More – In Primary DNS suffix of this computer put the domain name portion of the hostname such as yourhostname.com. Click OK and the computer will need to reboot for the changes to take effect.

    - Set the Unique Fully Qualified Hostname in Ensim

    Locate \Program Files\Ensim\WEBppliance\cp\admin\bin\Networkconfiguration.exe and select it to run.

    Under ISP Login:

    Username – admin
    Password – Put the password used for the admin account setup in windows.
    Primary IP Address – Remains the primary IP address of the server

    Fully Qualified Hostname – Put the Unique Fully Qualified Hostname from above

    Select Finish, it will a bit of time to complete. Once complete reboot the server.

    - Set the Unique Fully Qualified Hostname in Mail Enable

    In Ensim create a domain for administration with an e-mail account.

    Locate \Program Files\Mail Enable\Bin\MailEnable.msc and select it to run. You might want to create a shortcut on your desktop to allow access to this for future reference.

    In the MailEnable.msc locate MailEnable – MailEnable Management – Servers – localhost – Connectors – SMTP – Right click SMTP and select Properties – Find the General tab

    Under “Local Domain” Name enter the domain portion of the Unique Fully Qualified Hostname

    Under “Default Mail Domain” enter the hostname used in the administration domain MX record.

    Under “Specify the mail address when sending notifications” enter the e-mail account for the administration account

    Select Apply – and OK

    Share/Save/Bookmark

  • RAID

    Posted on January 1st, 2008 Mark No comments

    Redundant Array of Inexpensive Disks…..

    Read the rest of this entry »

    Share/Save/Bookmark