Below are the log file formats supported in IIS 6. It is important to choose the right one for your server so that you can make use of the data it collects. I personally use W3C Extended because it provides the most information. The downside is that it produces more disk activity, however if you have a fast file system you may not notice a performance hit. I also like the ODBC logging because I can create a web-based front-end to display and manipulate the data/statistics. I’ve outlined the major components of each log format and the information it collects.
Microsoft IIS Log File Format
-Fixed ASCII text-based format.
-Cannot be customized.
-Records: client IP, username, date, time, service, server name, server IP, time taken, client bytes sent, server bytes sent, service status code, Windows status code, request type, target of operation and script parameters.
NCSA Common Log File Format
-Fixed ASCII text-based format.
-Cannot be customized.
-Records: remote host address, remote log name (blank), username, date, time, GMT offset, request and protocol versions, service status code and bytes sent.
W3C Extended Log File Format
-ASCII text-based format.
-Customizable.
-Records: Date, Time, Client IP Address, User Name, Service Name and Instance Number, Server Name, Server IP Address, Server Port, Method, URI Stem, URI Query, HTTP Status, Win32 Status, Bytes Sent, Bytes Received, Time Taken, Protocol Version, Host, User Agent, Cookie, Referrer and Protocol Substatus.
ODBC Logging Format
-Records to any ODBC-compliant database (SQL Server, Oracle, Access).
-Records: Client Host, User Name, Log Time, Service, Machine, Server IP, Processing Time, Bytes Received, Bytes Sent, Service Status, Win32 Status, Operation, Target, Parameters.
-In order to use this method of logging the administrator needs to configure a database table with the appropriate fields, and then configure a logon/password for use with the ODBC connector. This is viewed as a security risk. Do not use the SQL server username “SA” for logging (even more of a security risk). This method of logging can also slow down the server due to Http.sys cache being disabled.
Windows cannot set the password for <user> because: The password does not meet the password policy requirements. Check the minimum password length, password complexity and password history requirements.
This error is because the password you or the user has tried to enter does not meet the password policy set in Windows Server 2003.
As a Server Administrator, you may find yourself in a situation where you need to change this policy, for more complex or simpler passwords to appease corporate users. Below are the default password policy requirements.
Minimum password length:
This security setting determines the least number of characters that a password for a user account may contain. You can set a value of between 1 and 14 characters, or you can establish that no password is required by setting the number of characters to 0.
Default:
7 on domain controllers.
0 on stand-alone servers.
Password Complexity Requirements:
Not contain the user’s account name or parts of the user’s full name that exceed two consecutive characters
Be at least six characters in length
Contain characters from three of the following four categories:
English uppercase characters (A through Z)
English lowercase characters (a through z)
Base 10 digits (0 through 9)
Non-alphabetic characters (for example, !, $, #, %)
Complexity requirements are enforced when passwords are changed or created.
Default:
Enabled on domain controllers.
Disabled on stand-alone servers.
Maximum password age:
This security setting determines the period of time (in days) that a password can be used before the system requires the user to change it. You can set passwords to expire after a number of days between 1 and 999, or you can specify that passwords never expire by setting the number of days to 0. If the maximum password age is between 1 and 999 days, the Minimum password age must be less than the maximum password age. If the maximum password age is set to 0, the minimum password age can be any value between 0 and 998 days.
Note: It is a security best practice to have passwords expire every 30 to 90 days, depending on your environment. This way, an attacker has a limited amount of time in which to crack a user’s password and have access to your network resources.
Default: 42.
To Change the Default Password Policy in Windows Server 2003
Select Domain Security Policy from Administrative Tools.
Click on Security Settings > Account Policies > Password Policy.
Right-click on Passwords must meet complexity requirements.
Click Properties from the context menu.
Do not remove the check from the Define this policy setting checkbox.
Select the Disabled option.
(This will allow less complex passwords)
Click the OK button.
Double-click on Minimum Password Length in the right pane.
Enter a new minimum password length. Entering Zero (0) will remove the password requirement.
Do not remove the check from the Define this policy setting checkbox.
Click the OK button.
Close the Default Domain Security Settings window.
Type gpupdate /force at the Command Prompt. This will refresh the security policy without restarting.
Press the Enter.
I’ve been asked a few questions on email addresses and their limitations or recommended practices as a server administrator. I will outline a small bit of information in regards to valid email addresses, server types and spam evasion.
The Internet Engineering Task Force RFC (Request for Comment) 2821 defines the local part of an SMTP email address a maximum of 64 characters. This of course is not set in stone and many servers will accept more than 64 characters for the local area of an address (the part before the @ sign). Domain names are limited to a maximum of 255 characters which is enforced by the domain registrars.
In the early days of the Internet, the local part of an SMTP address was most often in lowercase ASCII characters. For the most part they still are, but it looks as if system administrators bowing to corporate pressure (or something!), have allowed users to have their names with uppercase first characters. This creates a problem: Many people still have the idea that all email addresses are lowercase (which is technically wrong, but mostly accurate) and others believe they are case-sensitive (which is technically right, but mostly inaccurate). So because of this confusion system administrators are forced to make their domain policy case-insensitive such that users can have Chris@domain.com, chris@domain.com, CHRIS@domain.com and all other variations point to the same SMTP address. This effectively reduces the number of possible addresses available on a system. This is similar to the folder structure problem of UNIX and Windows web servers. On UNIX, the folder /Chris is different from /chris, while on IIS /Chris is the same folder as /chris.
According to RFC 2822, the local-part of the address may use any of these ASCII characters:
Uppercase and lowercase letters (case sensitive)
The digits 0 through 9
The characters ! # $ % * / ? | ^ { } ` ~ & ‘ + – =
The underscore _
The stop/period character . provided that it is not the first or last character in the local-part.
For the most part the upper and lower case characters, numerals and the period do not pose a problem for servers. Where problems occur is the use of the special characters: ! # $ % * / ? | ^ { } ` ~ & ‘ + – =. Have you ever seen an email address containing those? Probably not. For interoperability between operating system and mail system types, disallowing those characters is essential. There are some tricks to using those special characters, for example to use [ and ] they have to be encapsulated in quotations. [chris]@domain.com is invalid, whereas “[chris]“@domain.com IS. You can also have a space character if enclosed in quotations. Just stay away from these characters as people will be confused.
To combat spam, people have started typing their email addresses in forums and blogs as name[something]@doman.com, or [name]@domain.com. While some administrator must have in the past mentioned this as a good way to confuse email harvesters, it is no longer the case. Old harvesters used to rely on regular expressions and syntactically correct email structure to harvest addresses so emails with special characters would have been taken and recorded as verbatim. The address would have then been invalid since it wasn’t the user’s real address. Harvesters are now programmed with the idea that users are ignorant of email policy and throw special characters in their address to confuse spam-bots. They now automatically take those special characters out when harvesting addresses.
So what to do to confuse them? Put real words in the address that must be taken out. For example chrisssss@domain.com (take out the ssss) is more effective than chris[at]domain.com. It’s simply too bad for chrisssss@domain.com if there is such an address.
For all the system administrators and system builders out there, Windows XP sales are coming to an end. At the end of January 2008, Microsoft will no longer be producing or selling retail or OEM copies. Volume at some stores might last a month or two after that.
Windows XP Professional
Date of General Availability: December 31, 2001
Direct OEM and Retail License Availability (end date): January 31, 2008
System Builder License Availability (end date): January 31, 2009
Windows XP Tablet PC Edition
Date of General Availability: February 11, 2003
Direct OEM and Retail License Availability (end date): January 31, 2008
System Builder License Availability (end date): January 31, 2009
Windows XP Professional x64 Edition
Date of General Availability: April 25, 2005
Direct OEM and Retail License Availability (end date): January 31, 2008
System Builder License Availability (end date): January 31, 2009
Windows XP Home Edition
Date of General Availability: December 31, 2001
Direct OEM and Retail License Availability (end date): January 31, 2008
System Builder License Availability (end date): January 31, 2009
Windows XP Media Center Edition
Date of General Availability: October 28, 2002
Direct OEM and Retail License Availability (end date): January 31, 2008
System Builder License Availability (end date): January 31, 2009
Do you have IIS logging enabled? Do you ever use it? If you don’t use it, consider turning it off. By looking at the log files, you can see an awful lot of text is recorded with every visitor. Items such as bytes sent, referrers, and domain/host info slows down the server considerably. Reverse DNS requests when logging host info for a visitor will really slow the server. For small sites hosted on powerful servers performance may not be an issue. If you have a site with many visitors and/or databases (forums), logging can cause significant hard disk activity and paging.
To disable logging, go into the IIS Manager -> Right-click on Websites and select Properties-> Uncheck “Enable Logging”
You can also do this for FTP sites as well. To disable it for a specific site, right-click on the site-name and disable logging.
|
 Loading ...
|
4 Comments