V4D - Viet4Design: 2007

29.9.07

The basics of Internet Information Services 7.0 also known as IIS 7.0. IIS 7.0 is the web server role in Windows Vista and Windows Server 2008.
Introduction

Internet Information Services 7.0 (IIS 7.0) is Microsoft’s latest version of their web server. IIS has been included with Windows Server since Windows 2000 Server as a Windows Component and since Windows NT as an option. IIS 7.0 is available with Windows Vista and Windows Server 2008, which is scheduled for release in Q1 2008. IIS 7.0 has gone through a major overhaul and has been completely redesigned from scratch. This has been done to make the most flexible and secure platform for web and application hosting.

IIS 7.0 has been designed to be the most secure and flexible web and application platform from Microsoft. Microsoft has redesigned IIS from the ground and during this process the IIS team has focused on 5 major areas:

*
Security
*
Extensibility
*
Configuration and Deployment
*
Administration and Diagnostics
*
Performance

What’s New

Almost everything is new in IIS 7.0. Microsoft has focused on modularity when building IIS 7.0, which means that only the binaries needed is installed, this minimizes the attack surface of the web server.

An example to this: If you need the FTP Server or the Caching feature in IIS, you install the FTP Server or Cache modules to manage and enable either the caching activity or the FTP Server.

Windows Server 2008 will include all the IIS features needed to support hosting of web content in production environments. Windows Vista only has some IIS features and the features depend on your Vista version. IIS 7.0 in Windows Vista is ideal for building and testing web applications. Additional modules and features will be available from Microsoft or you can code your own, maybe even buy some from 3rd party vendors.
Architecture

Besides the changes to the core components of IIS 7.0, the focus has been with modular design in mind. The modular design gives more flexibility and security to IIS 7.0, compared to previous versions of IIS.

Figure A: Overview of the main modules and components of IIS 7.0

The main advantage of the new modular design is that it helps to reduce the footprint, which results in a more secure web server platform, since the attack surface has been minimized.

IIS 7.0 provides a new native core API, which replaces the ISAPI filter from previous versions of IIS. With the new API it’s now possible to extend IIS with extra modules or even replace any of the built-in modules with custom written modules.

New modules can be downloaded from Microsoft’s IIS.net website, where Microsoft maintains a download repository for IIS: http://www.iis.net/downloads
Administration

There are several ways of administrating IIS 7.0.

*
The GUI way using IIS Manager
*
APPCMD command tool
*
Remote administration using IIS Manager
*
Scripting using Windows PowerShell
*
Microsoft.Web.Administration API interface

The GUI Management interface has also been redesigned, the new IIS Manager is now more task-oriented and action based, as we know from ISA Server and the new Exchange Server 2007.

Figure B: Screenshot of the IIS Manager

IIS Manager can be used to configure IIS and ASP.NET settings, the configuration settings will be written to the xml configuration files. As something new, Health and diagnostics information can now be seen and run as integrated tools directly from within IIS Manager and is already a part of IIS 7.0.

APPCMD is the new main general purpose command prompt tool for IIS 7.0, which can be used for administration and configuration of IIS. APPCMD is the new enhanced version of the old adsutil.vbs, for those of you who are familiar with that tool from IIS 6.0.

Remote Administration has been enhanced and is now possible using the IIS Manager, communicating securely over https to the web server.

There’s also the option of scripting all IIS management. This is now done using Windows PowerShell, which is Microsoft’s new scripting language. It’s an easy and effective way of handling administration of IIS on your web server and this is especially useful if you manage several web servers or large web farms. Windows PowerShell can be used directly against the WMI interface of IIS or used to read and write in the IIS 7.0 XML configuration files.

IIS 7.0 has backward compatibility with the IIS 6.0 metabase and the ADSI and WMI scripting interface known from IIS 6.0, which means that all your old scripts for IIS 6.0 will still work on IIS 7.0.

Microsoft.Web.Administration API is the interface targeted to developers, who want to code their own programs or scripts to manage IIS 7.0.

In IIS 7.0 it’s now possible to delegate the management of IIS and the web sites. You can now delegate full administrative access to the site owners of a website. The site owners can then control and manage all the website settings using IIS Manager, without compromising server security. All the settings the site owners manage, are written to the web.config xml file of their own website.
Configuration

The configuration has been made simple and is based on distributed XML files that hold the configuration settings for the entire IIS and ASP.NET.

Configuration settings can be done globally for the entire web server or for specific websites using either the XML files or through the GUI Management interface. The GUI just writes the configuration settings to the same XML files. The main xml configuration files in IIS 7.0 are:

*
Applicationhost.config
*
Global web.config
*
Machine.config
*
Site web.config
*
App web.config

By using xml based configuration files, deployment and scale-out in large web hosting environments has been optimized. It’s fairly easy to copy the IIS configuration to a new server and be up and running relatively quickly.

Handling replication of web server configuration is also relatively easy with IIS 7.0 compared to IIS 6.0, because of the xml based configuration files. This makes it very easy to replicate and deploy configurations in larger web farm environments. With IIS 6.0 this was best handled by using Microsoft Application Center 2000 or other 3rd party products.

Shared Configuration is a new feature of IIS 7.0, which is designed for web farm scenarios. With Shared Configuration it’s now possible for multiple web servers to share a single configuration file (applicationhost.config). A master of the applicationhost.config file will be placed on a common UNC path. The Shared Configuration feature is a great alternative to the perspective of replicating IIS settings.

The Applicationhost.config xml file is the main configuration file of IIS 7.0, this configuration file contains all the information about sites, virtual directories, applications, application pools and global settings for the web server.

Content replication can relatively easy been managed by simple x-copy or robocopy commands, as well as specific website configurations, which are saved in web.config xml files within each website.
Conclusion

With the redesign of IIS, Microsoft has really focused on making the IIS 7.0 a better web server for everyone, from IT Professionals, Developers to Web Hosters. To sum up I’ll try to highlight some of the main reasons why I believe IIS 7.0 is a strong product:

*
The product is more secure – only the binaries needed are installed
*
It’s extendable in a flexible way, because of the new modular architecture
*
It’s easier to scale-out – because of the simplicity in configuration, based on xml files
*
Better performance – due to the improvements to the core of IIS (http.sys)

There are plenty of opportunities for trying out IIS 7.0 yourself and getting familiar with it before the official release.

IIS 7.0 is available for public download together with the latest version of Windows Server 2008, currently in Beta 3. You can download the Windows Server 2008 beta from: http://www.microsoft.com/windowsserver2008/default.mspx.

Microsoft has created a special Go Live license, which is available for free and permits customers to deploy beta releases of IIS 7.0 in live production environments, before the official release of Windows Server 2008, which is scheduled for release in Q1 2008.

The IIS 7.0 Go Live license can be obtained from: http://www.iis.net/default.aspx?tabid=79.

28.9.07

Nếu bạn học CNTT trong trường đại học, tôi đoán chắc rằng bạn sẽ phải học môn Mạng máy tính nhưng chưa chắc bạn sẽ biết cách bấm cáp mạng LAN thành thạo. Thực tế thì công việc này không quá khó lắm đâu, bài viết này sẽ hướng dẫn từng bước để bạn có thể tự mình thực hiện được.

Việc bấm cáp mạng LAN là cần thiết khi bạn muốn nối 2 máy tính với nhau, hoặc bạn nối máy tính với Hub/Switch để kết nối Internet। Trước hết bạn cần chuẩn bị đầu nối RJ45, kìm bấm chuyên dụng và dây cáp mạng.

Dây cáp mạng thường dùng hiện nay là

loại CAT - 5 (100Mbps) gồm 4 cặp với 8 đầu dây được chia thành các màu: xanh dương, trắng - xanh dương, da cam, trắng - da cam, xanh lá cây, trắng - xanh lá cây, nâu, trắng - nâu. Hãy cắt bỏ một đoạn vỏ nhựa bọc ngoài, gỡ và sắp xếp dây theo chuẩn (xem bên dưới) rồi dùng kìm cắt bằng các đầu dây.
Có 2 chuẩn bấm dây là: T568A và T568B (thường được gọi là chuẩn A, chuẩn B). Lồng các đầu dây vào trong đầu nối RJ45. Hãy xem cách bố trí các đầu dây của từng chuẩn trong hình sau:

Bạn sẽ hỏi: trường hợp nào thì dùng chuẩn A, trường hợp nào dùng chuẩn B? Nếu nối máy tính (PC) tới Hub/Switch thì bạn bấm cả 2 đầu dây với cùng 1 chuẩn: cùng là T568A hoặc cùng T568B. Lúc này ta có dây cáp thẳng (Straight Through). Còn khi bấm dây để nối từ PC đến PC (trường hợp chỉ có 2 máy tính) hoặc từ Hub/Switch vào Hub/Swtch (trong trường hợp muốn nối 2 Hub/Switch lại với nhau) ta bấm 1 đầu dây theo chuẩn T568A còn đầu kia theo chuẩn T568B. Đây gọi là dây cáp chéo (Cross Over). Bạn chỉ cần ghi nhớ rằng: nối 2 thiết bị khác loại thì đấu thẳng, nối 2 thiết bị cùng loại thì đấu chéo.

Ta thấy rằng chỉ có 4 dây trong số 8 sợi dây được sử dụng là 1, 2, 3, 6 - tương ứng với 4 dây tín hiệu TX+, TX- (TX - Transmit), RX+, RX- (RX - Receive) của card mạng (NIC - Network Interface Card). Việc của bạn là xác định chuẩn cần bấm, rồi sử dụng kìm bấm để ép đầu nối RJ45 vào đầu các sợi dây.
Một vài chú ý:
- Khi cắt phần vỏ bọc phải chú ý độ dài của đầu sợi dây, không được ngắn quá hoặc dài quá. Dài quá khi bấm vào đầu RJ45 sẽ dễ bị tuột, tốt nhất là đầu RJ45 phải "cắn" vào phần vỏ bọc.
- Thực tế thì bấm thế nào cũng được, không cần theo chuẩn, miễn sao 2 đầu dây giống nhau là có thể chạy được. Song nếu khoảng cách xa (dưới 100m) thì cần phải đúng chuẩn. Việc bấm đúng chuẩn sẽ khử độ nhiễu, giúp tín hiệu đi xa hơn.
- Khi bấm đầu RJ45 cần nhẹ nhàng chính xác, bấm mạnh quá sẽ làm vỡ "hạt".

Các hàm tìm kiếm của Google

Gúc-Gồ là anh cả trong việc tìm kiếm trên internet, có thời điểm nó chiếm 80% lượng tìm kiếm trên net, điều làm lên khác biệt so với phần còn lại của thế giới ( Yahoo! và MSN )là nó có những cấu trúc tìm kiếm chuyên biệt mà không bộ máy nào có được.
Phần lớn những kẻ đi phá hại người khác dùng Google để tìm các lỗi của các trang web khi tấn công.
Sau đây tôi sẽ giới thiệu cho bạn một vài cấu trúc tìm kiếm cơ bản:
. cache: Tìm kiếm trong bộ nhớ của Google, cách này thường được sử dụng khi link đó không còn tồn tại.
Cấu trúc cache:www.abc.com
. link: Tìm xem có trang web nào đặt link đến site của bạn.
Cấu trúc link:www.abc.com
. related: tìm các trang web có liên quan đến trang mình đang tìm.
Cấu trúc related:www.abc.com
. info: tìm các thông tin về trang web đó như quốc gia, nhà cung cấp...
Cấu trúc info:www.abc.com
. define: Định nghĩa 1 từ nào đó ( phải bằng tiếng Anh )
Cấu trúc define:từ cần định nghĩa
. stocks: Tìm thông tin về cổ phiếu.
Cấu trúc stocks:mã cổ phiếu.
. site: Tìm trong 1 website do mình chọn.
Cấu trúc site:www.website.com
Ví dụ để tìm thông tin trong site của mình bạn gõ vào Google site:nguyenhunghn.blogspot.com
. allintitle: Tìm trong tiêu đề
Cấu trúc allintitle:tiêu đề.
. intitle: Cũng tìm trong tiêu đề, nhưng nó giới hạn trọng 1 từ nhất định.
. inurl: Tìm chữ trong đường dẫn URL.
Cấu trúc inurl:từ cần tìm

Thực ra hàm tìm kiếm còn rất nhiều nhưng những hàm trên mà tôi đã giới thiệu cũng đã đủ cho bạn sử dụng Gúc-gồ ngon lành.

Web Server Security Issues and Front Page Server Extensions

It's "common knowledge" (at least in some circles) that FrontPage Server Extensions are insecure and Web Sites created with FrontPage are vulnerable -- but is it true? What are the risks associated with FrontPage and what can you do about them? What are the recommended best practices for securing FP Web sites? In this article, we'll look at Web security from the FrontPage perspective.

Regardless of the software you’re using, Web servers are vulnerable because they’re generally “out there” on the public Internet. This opens up the computer that hosts the Web server software to access from those outside the organization. For this reason, it’s especially important to protect your public Web servers and isolate them from other systems on your internal network – for example, by placing them in a DMZ or perimeter network (also sometimes called a screened subnet) with both front and back end firewalls to protect the DMZ from the Internet and to protect the internal LAN from the DMZ.

The FrontPage Server Extensions

FrontPage Server Extensions (FPSE) can run on both UNIX-based and Windows (IIS) Web servers, and the security issues differ somewhat depending on the underlying operating system and Web server software. The purpose of FPSE is to allow Web masters to create Web pages and manage Web sites through the FrontPage interface, which is more user friendly than uploading, removing and changing Web files via File Transfer Protocol (FTP). Microsoft calls a Web server running FPSE an extended Web server.

The latest version of FrontPage is 2003, but the latest version of FPSE is 2002. FP 2003 works with the 2002 server extensions, which are included with Windows Server 2003. Windows SharePoint Services also provides functionality of FPSE. You can download FPSE 2002 for Windows at http://www.microsoft.com/downloads/details.aspx?FamilyID=5cc0a845-1884-4a16-a8cb-25d2f0815fa3&displaylang=en. They can be installed on Windows NT 4.0 (with SP 6a), Windows 2000 and Windows XP with IIS.

You can download FPSE 2002 for UNIX at http://www.microsoft.com/downloads/details.aspx?FamilyID=0c5eb0ad-e1ad-4100-9b76-8772a8220062&displaylang=en. They will run on Solaris, HP/UX, Linux (Red Hat), Free BSD and other versions of UNIX.

FPSE 2002 is required for the following:

to upload files to the Web site via FrontPage
to create custom link bars, use shared border background properties and other FrontPage components
to get usage analysis reports
to take advantage of user roles for security

Some versions of FPSE are required to create hit counters, server-side image maps, search forms and other components that you insert with FrontPage.

What are the Security Issues?

It is important that only authorized users be able to add, change or delete Web content. Some components, such as Java applets and scripts, can present security risks.

Another security risk occurs when Web users connect to a database to access information.

In the following section, we’ll discuss what you can do to protect your FrontPage Web sites from these risks.

Protecting FrontPage Web Sites

There are a number of steps you can take to protect your FrontPage Web sites.

You can restrict access to the Web sites you create with FrontPage by configuring permissions. There are three levels of access to a site: end-users (browsers), those who can create content (authors) and those who can manage the site (administrators). You can set individual permissions for different sites and you can set different permissions for subsites within a site (by default, subsites inherit the permissions of their parent sites).

To set permissions for a subsite from within FrontPage 2003, do the following after opening the subsite:

Click Tools | Server | Permissions
On the Settings tab, select Use unique permissions for this Web site.
Click Apply.
Click the Groups, Users or Computers tab to set access rights for a group, user or computer. In the appropriate tab, click the Add button to add a new group, user or computer, or click the Edit button to change the access rights for a group, user or computer that is already listed.

To set permissions for a particular machine, you’ll need to enter its IP address. You can also set permissions for a group of machines within an address range by using the wildcard (*). For example, 162.198.1.*. For the group(s), user(s) or computer(s), you can select to allow browsing of the Web, authoring and browsing, or administering, authoring and browsing.

Note:
Permissions are cumulative. A group, user or computer with administrative rights can also author and browse; one with author rights can also browse.

You can also restrict access to Web pages by password protecting them. For information on how to use Active Server Pages (ASP) and an Access password database to password protect FrontPage 2003 Web sites, see KB article 825498 at http://support.microsoft.com/default.aspx?scid=kb;en-us;825498.

If you have a Web site on a UNIX server, you can use the Registration Form Handler to create registration forms and configure user permissions. For more information on how to use this feature to create a registration Web, see KB article 143092 at http://support.microsoft.com/kb/q143092/.

Note:
Registration Web pages are not supported by IIS.

A site author can turn off support for Active Server Pages (ASP) or for features that require FPSE from within FrontPage. This is done via Tools | Page Options. On the Authoring tab, you can check or uncheck the technologies that you want the site to support, including:

SharePoint Services
Browse-time Web components
Author-time Web components
ActiveX controls
VBScript
JavaScript/Jscript
Java applets
Frames
ASP
Cascading Style Sheets (CSS)
PGN graphics

FrontPage 2003 includes the Database Interface and Results wizards that allow you to configure options to decrease the risk when users connect to a database through the Web server. Defaults are also set for better security; for example, by default database error information is not displayed because it can be used by attackers to gain more information about the database. Another measure is to set up a special account for accessing the Web page that connects to the database, and password protecting it with a user name and password that are different from those that are used for other resources. If the database contains built-in macros, you should disable them. You also should not allow HTML content to be displayed in database columns.

10 Steps to a Secure FTP Server

With his first article for WindowSecurity.com, we are pleased to welcome Ray Zadjmool (MCSE, CISSP, CCNA) to our team of authors. FTP [File Transfer Protocol] is one of the oldest and most popular services found on the on the internet today. Serving as an easy and effective method by which to transfer files over a network, FTP has become a standard that is both accepted and widely accessible to users across almost every network and operating system in use today. In this article we will examine 10 options available native in Windows 2000 that can be used to secure an FTP site.

FTP [File Transfer Protocol] is one of the oldest and most popular services found on the on the internet today. Serving as an easy and effective method by which to transfer files over a network, FTP has become a standard that is both accepted and widely accessible to users across almost every network and operating system in use today.

Windows 2000 comes with an FTP server as a part of IIS 5.0. Installed as a stand alone service, it is very rich in features. When combined with the other resources available inside Windows 2000 server, administrators are empowered with different options that can help make an FTP site more secure.

Having said that, we will examine 10 options available native in Windows 2000 that can be used to secure an FTP site. Some are pretty obvious but some are creative approaches that aren’t readily thought of by administrators. In addition to the tips below, add-on services such as VPNs or SSH are things to consider since there is the pesky issue of sending passwords clear text over the wire.

TIP # 1: Disable Anonymous Access.

Anonymous access is enabled by default when you first install FTP services in Windows 2000. Anonymous Access is a method by which any user can gain access to your FTP site without the need of a user account.

There are some customer facing services that can be served effectively by Anonymous FTP sites, but the majority of the time allowing anonymous access will result in the eventual hijacking of your site by individuals wanting to host illegal files and copyrighted material.

By removing the capability for anonymous access, you are essentially limiting access to your FTP site to successful authentication by a predefined user account. Access controls are then configured by the use of ACLs [access control list] defined on the FTP home directory using NTFS permissions.

Figure 1: To restrict the anonymous access to your FTP site, simply clear the Allow Anonymous Connections box in the security accounts tab of the ftp sites properties page

TIP # 2: Enable Logging.

By enabling logging your FTP site, you can ensure that you will have an accurate record of which IP addresses and users accessed your site. Maintaining a practice of routine log review can enable you to assess your traffic patterns and identify any security threats and/or breaches.

Figure 2: To enable logging of your FTP site, check the Enable Logging box in the FTP Site Tab found in the properties page of the FTP site. Log files are then created in a format of your choosing and can be reviewed later for analyzing traffic patterns and access controls.

TIP # 3: Harden your ACLS.

Access to your FTP directory should be regulated utilizing ACL restrictions across NTFS permissions. This cannot be stressed enough. Your FTP directory should not have the everyone group with full rights as this will limit your ability to control the user groups that have access into your FTP site.

Figure 3: Typically you would want to restrict this group to Read, Write, and List only [no execute] but in the case of a blind put configuration (read below) you should also deny against Read and List and only have Write access on your directory.

TIP # 4: Setup your FTP site as Blind Put.

If you only need your users to transfer files to your server and not transfer files from your server, consider configuring your FTP site as a “blind put”. What this means is that users are allowed to write files without the having the ability to read from your FTP directory. This will protect the contents of your ftp site in case of an unauthorized user getting access to your ftp directory.

Configuring Blind Puts should be done both at the FTP site and on the directory’s NTFS permissions.

Figure 4: shows you how to remove read access to your FTP site using the Home Directory Tab found in the properties page of the site.

TIP # 5: Enable Disk Quotas.

Windows 2000 comes with a handy utility that allows for the enforcement of Disk Quotas. Disk Quotas can effectively limit the amount of disk space a user can have ownership of. By default, ownership is granted to whichever user wrote the file. By enabling disk quotas and checking the deny disk space to users exceeding disk quota, you can effectively limit the possible damage caused in case your FTP site gets hijacked. One worst scenario is the abuse of an FTP site to the point that the disk fills up. This of course can have disastrous consequences to other services that might share the partition with the FTP site.

Also, by limiting the amount of disk space each FTP user can have, your site becomes an unattractive target for hackers looking for someplace to share their media files.

Figure 5: Enable Quota Management by Quota Tab found in the properties window of an NTFS disk partition.

The use of Disk Quotas is limited to NTFS partitions. Furthermore, Quotas can only be placed on a per user basis and cannot be assigned to groups.

Figure 6: Quote management can be configured on a per user basis. Limits should be set on the user accounts used for FTP access.

TIP # 6: Use Logon Time Restrictions.

Windows 2000 carries from NT 4.0 days the ability to logon hours of specific users. This option allows for a user to be limited to specific hours of the day in which he can logon.

This can be used creatively to limit access to your FTP site to only times that are authorized. If for instance you are using this Ftp site in an enterprise environment for business use, you could assess your availability needs to be limited to working hours. By denying logon during after hours, you would effectively shut down and secure your ftp site for most of the calendar day.

Figure 6: The configuration of logon times in Windows 2000 can be found in Active Directory Users and Computers under the user property page.

net user /times:

* Local User accounts cannot be configured for logon times through the Local Users and Groups console as this option is not available in the GUI.

TIP # 7: Restrict Access by IP.

Windows 2000 FTP can be restricted to specific IP addresses. By limiting access to your FTP site to known entities, you can drastically reduce your exposure to unauthorized access.

Figure 7: To restrict FTP access via IP, use the Directory Security tab found in the properties pages of the FTP site. Make sure that the default Denied Access check box is selected and that only trusted IP Addresses are listed in the list box.

TIP # 8: Audit Logon Events.

By enabling the Auditing of Account Logon Events, you can review success/fail attempts to your ftp site in the Security Log of the Event Viewer.

Frequent review of this log can alert you to suspicious activity that could be a malicious user trying to hack in. It can also be used as an effective method for intrusion detection by giving you a historical look into your FTP sites usage.

Figure 8: Audit Account Logon Events can be turned on by using the Local Security Policy configuration tool. Navigate to the local policies/audit policy container and change the local setting to reflect Success, Failure.

*Using Active Directory, Audit Account Logon Events can also be configured using Group Policies.

TIP #9: Enable Strong Password Requirement.

Using complex passwords is a good security practice whenever you are dealing with end user authentication. In the case of FTP, it can be a crucial component in securing your site.

Windows 2000 allows for administrators to force users to comply with strong password requirements. By enabling the ‘Passwords Must Meet Complexity Requirements’ field in Local Security Policy or Group Policy, FTP user accounts will be forced to adhere to following restrictions when selecting their passwords:

Must not contain all or part of the user's account name
Must be at least 6 characters in length
Contain characters from 3 of the following 4 categories:
- English uppercase characters (A - Z)
- English lowercase characters (a - z)
- Base 10 digits (0 through 9)
- Non-alphanumeric characters (e.g., !, $, #, %)

Figure 9: Passwords must meet complexity Requirements can be enabled by using the Local Security Policy configuration tool. Navigate to the local policies/Account Policies/Password Policy container and change the setting to reflect Success, Failure.

*Using Active Directory, ‘passwords must meet complexity requirement’ can also be configured using Group Policies

TIP # 10: Enable Account Lockout and Account Lockout Threshold.

FTP accounts are pretty popular targets for password cracker programs that run through an exhaustive list of passwords in an attempt to guess, or crack account access. Windows 2000 security policies allow administrators to lock down the number of times failed logins can be attempted before an account is locked out. By enabling this option and configuring the threshold, administrators can limit their exposure to password crackers.

Figure 10: Account Lockout Duration and Threshold options can be configured by using the Local Security Policy configuration tool. Navigate to the local policies/Account Policies/Password Policy container and change the setting to reflect Success, Failure.

*Using Active Directory, ‘Account Lockout Policies’ can also be configured using Group Policies

PowerShell Security

The built-in PowerShell security features as well as some additional security you can configure once in PowerShell.

If you have not heard of PowerShell you must be living under a rock. If you have heard about PowerShell, then you must have been wondering how and if PowerShell is secure. I saw PowerShell for the first time about 4 years ago at an MVP conference. With all of the effort and sweat that has gone into PowerShell, it had better come with some advanced security. Well, it does! PowerShell is not just your routine scripting language. There are built in security features, as well as some additional security you can configure once in PowerShell.

PowerShell Default Security

Just getting to the PowerShell interface can be a task for some. Not that this is security related, just that you must be in the PowerShell interface before you can do much of anything. This in itself is security. There are however, some default security measures that are there by design to help ensure that anyone with malicious intent is denied their efforts.

What is in a path?

The first default security measure that you will encounter is that fact that PowerShell won’t run scripts that are in the current folder. This is so that malicious scripts attempting to intercept cmdlets and command names will fail.

For example, if you wanted to run a script named Example.ps1 from the C:\scripts folder, you would need to include the full path to the script, even if you were in the C:\scripts folder within PowerShell. Figure 1 illustrates what happens when you just try to run Example.ps1 without a path.

Figure 1: Scripts must include the path to the script to run successfully

Now, look at what happens when you run the script including the path to the script, as shown in Figure 2.

Figure 2: When the path is included with the script, the script runs without a hitch

Why am I Restricted?

Another default setting that is directly related to security is the fact that all scripts must be run interactively. This is a security measure that ensures that PowerShell scripts cannot be executed from a script based virus. This means that you must be at the PowerShell interface and run the script in real time for it to function.

This default setting is associated with the ExecutionPolicy setting within PowerShell. The ExecutionPolicy by default is set to Restricted, as shown in Figure 3.

Figure 3: The ExecutionPolicy by default is set to Restricted to secure the execution of remote PowerShell scripts

Going Beyond the Defaults

The default ExecutionPolicy in PowerShell is very secure. It does not allow for any scripts to be run, from anywhere. So, scripts that you create and put on a system won’t run. Scripts that you download from the Internet won’t run. Scripts that you even sign and secure to the nth degree won’t run. Therefore, you will need to reset the level of ExecutionPolicy before you can run your scripts.

Setting the ExecutionPolicy Level

There are four levels of the ExecutionPolicy. These four levels provide you with great security over what scripts can run and what requirements need to be associated with the script to run. The four levels and the requirements include:

Restricted
This is the default configuration in PowerShell. This setting means that no script can run, regardless of its signature. The only thing that can be run in PowerShell with this setting are individual commands.

AllSigned
This setting does allow scripts to run in PowerShell. The script must have an associated digital signature from a trusted publisher. There will be a prompt before you run the scripts from trusted publishers. This exposes you to running signed, but malicious, scripts.

RemoteSigned
This setting allows scripts to be run, but requires that the script and configuration files that are downloaded from the Internet have an associated digital signature from a trusted publisher. Scripts run from local computer don’t need to be signed. There are no prompts before running the script. Still exposes you to scripts that are signed, yet malicious.

Unrestricted
This is not a suggested setting! This allows unsigned scripts to run, including all scripts and configuration files downloaded from the Internet. This will include files from Outlook and Messenger. The risk here is running scripts without any signature or security.

To set anyone of these levels, just type set-executionpolicy , as shown in Figure 4.

Figure 4: Setting the ExecutionPolicy is as easy as running the set-executionpolicy command.

Using Group Policy

PowerShell is great, but if scripts can’t run on computers in your environment, it does have limitations. First, you must get PowerShell on each computer. Since PowerShell is installed via an EXE, it is very easy to install the application. You can either use a ZAP file and push it out using Group Policy, or you can use your current centralized method of installing applications. Keep in mind that PowerShell is considered a hotfix, so Windows Update can also push out the installation of PowerShell.

After you get PowerShell installed, we just investigated that you need to enable scripts to run. With the ExecutionPolicy set at Restricted as a default, you need to configure every computer to run scripts, that will run scripts. This could take days if you are trying to do this manually.

However, you can also use Group Policy to get this done for you. Of course, you could create your own Administrative Template (ADM file) to make this change, or download the ADM template that Microsoft provides for you. I suggest you do the latter by downloading the ADM template.

After downloading, you will need to install the MSI. I will admit, it is not the cleanest or most efficient install. After installation, the ADM file is shoved under the C:\program files\Microsoft Group Policy folder. If nothing else, this is great security! The file you need to import into the Group Policy Object Editor is PowerShellExtensionPolicy.ADM. After importing, you will have two new nodes in your Group Policy Object. One will be at Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell and the other at User Configuration\Administrative Templates\Windows Components\Windows PowerShell, as shown in Figure 5.

Figure 5: PowerShell ADM template adds settings to Computer Configuration and User Configuration for script execution

When you go to configure this policy, you will see that you have three options for a setting, as shown in Figure 6.

Figure 6: The ExecutionPolicy settings for PowerShell in a GPO

Summary

PowerShell is the new kid on the block. With Windows Server 2008 coming out in early 2008, PowerShell will take off like a rocket ship. With all of the attention that PowerShell is getting, everyone is hoping that it comes with security already built-in. Well, the worry is over. PowerShell provides security directly out of the box, with default security features. The fact that the scripts are set to have a restricted execution policy is fantastic. Even if you have created a .PS1 file, that script being associated with Notepad is nice default security. Even if you can get to the PowerShell interface, the fact that the path to the script must be typed in adds value. Beyond the defaults, being able to set the execution policy and control PowerShell through Group Policy gives centralized control over PowerShell security.

27.9.07

search files on Rapidshare server too

Few days back we talked about searching Google for Torrents. Using the same method you can search files on Rapidshare server too

Just go to Google.com and punch “site:rapidshare.de” followed by:

“inurl:pdf” for Ebooks in PDF Format
“inurl:avi|wmv|mpg|nva” for Movies
“inurl:mp3|ogg|wma” for Audio Files
“inurl:exe” for executable application
“inurl:zip|rar|7zip|tar” for RAR, ZIP, 7ZIP or TAR compressed archieve

Examples:

If your searching for Google Earth in ZIP format, then you must search for “site:rapidshare.de inurl:zip google earth” (obviously without the quotes)

Similarly if your searching for XYZ video, then it should be something like “site:rapidshare.de nurl:avi|wmv|mpg|nva XYZ”

25.9.07

Generating SSL Certificates for Exchange 2007 and ISA Server 2006

Using ISA Server to front a single Exchange 2007 server in a split DNS configuration.

If you have started to delve into the world of Exchange 2007 and SSL you would have already figured out that things are not as simple as they used to be. You can no longer simply get a standard SSL certificate and put it on the Exchange server – if you do, all sorts of things will go wrong especially if you have Outlook 2007 on your network.

There are various articles on the web which discuss several ways to generate SSL certificates with Exchange 2007 however they often do not take ISA Server into account. The trick with Exchange 2007 is that SSL is used for all sorts of things which varies depending on the version of Outlook to which server roles are installed on the box.

In this article, we will discuss a common scenario where ISA Server is used to front a single Exchange 2007 server in a split DNS configuration. We shall make use of an internally generated SSL certificate on the Exchange server and a public SSL certificate on the ISA Server. The split between public and private certs makes things more flexible for you as your Exchange requirements change internally and keep costs down as the certificate requirements for Exchange 2007 mean that you can just get any old cert from your favourite provider.

You do not have to have a huge PKI deployment to make this work, as a minimum, your ISA Server and Exchange Servers must trust your certificate server root! Your client PCs do not need to trust the root as Outlook 2007 DOES NOT validate the trust chain of the SSL cert for address book lookups.

Getting Started

If you already have ISA Server in front of Exchange 2003 you probably already have a public SSL certificate containing a Common Name of mail.yourcompany.com which is a great starting point. If you do not have a public SSL certificate for your ISA server then this is the time to get one.

Tip:
A basic SSL certificate will do. However, be careful who you buy one from as some of the low cost providers are not trusted out of the box by Windows Mobile. So if you want to make use of ActiveSync you should get a certificate from a provider that is supported otherwise you have to install a new trusted root cert in your mobile devices which can be very messy and time consuming – and some operator locked devices may not allow this.

In this scenario we are using a Basic SSL certificate from Entrust with a CN of mail.vircom.co.uk. This certificate should be installed onto the ISA Server into the computer certificate store. The EXTERNAL DNS record for host MAIL should resolve the external IP on the ISA Server.

Although this article does not go into the intricacies of creating the required ISA Server rules and authentication delegation, please be aware that there is an update available for ISA Server 2006 for publishing Exchange 2007. Make sure this is installed on your ISA Server before publishing any Exchange 2007 resources – The download is available here Update for Publishing Microsoft Exchange Server 2007 for Microsoft Internet Security and Acceleration (ISA) Server 2006. If you have existing rules publishing Exchange 2003 then disabled those rules and run the Mail Server Publishing Rule Wizards for creating the new Exchange 2007 publishing rules. It is recommended to create new rules with the wizard as Exchange 2007 uses extra web folders that are not used by Exchange 2003. The Web Listener should be using Forms Based Authentication (FBA) and the public SSL certificate.

SSL Certificate Requirements

At this point, remote clients (Web, Outlook, Windows Mobile etc) can all resolve and connect to the outside of the ISA Server with a trusted SSL certificate. The next step is to make sure that the ISA Server can do the same to the Exchange 2007 server – i.e. the second half of the SSL bridge. To do this we need a SSL certificate on the Exchange 2007 server that will meet various requirements:

The main name of the certificate will be a FQDN starting with MAIL to cater for all the Exchange 2007 services. This name will be the Common Name (CN) which in this scenario is MAIL.VIRCOM.CO.UK.
Exchange 2007 also configures itself for TLS encryption with SMTP. If you change the advertised name of the SMTP service you need to have an SSL certificate that matches this name otherwise your event log will fill up with errors. In this scenario the SMTP service is configured to use SMTP.VIRCOM.CO.UK.
Exchange 2007 also needs to have the FQDN starting with the host name AUTODISCOVER in the certificate if you want to use the new autodiscover service. In this scenario it is AUTODISCOVER.VIRCOM.CO.UK.
It is recommended that the DNS domain name is also included in the SAN. In this scenario it is VIRCOM.CO.UK.
To make sure that all the other Exchange 2007 services continue to function as expected it is recommended that you also include the servers own FQDN based on the computer name. In this scenario the Exchange server FQDN is VIRCOM07.VIRCOM.CO.UK.
Outlook 2007 will use HTTPS to connect to the address book on an Exchange 2007 server – even on the LAN! This is all part or Microsoft’s grand design to phase out public folders. The Outlook 2007 client will use the Exchange 2007 server HOST name (not FQDN) to connect to the address book service over SSL (changing the host portion of the URL for the address book in the Exchange UI seems to have NO effect). In this scenario the Exchange server host name is VIRCOM07.
Note:
If Outlook 2007 is not able to find the server host name in the certificate it will display a warning to the user – you really do not want this to happen! NB: Outlook 2007 only hosts name and date validation and NOT a certificate chain lookup thus a trusted root is NOT required. This is to allow for the self signed certificate that Exchange 2007 creates during set up to function. If you are using previous version of Outlook then this will not be an issue, but plan ahead now!
To top all this, ISA 2006 has a bug regarding Common Names (CNs) and Subject Alternative Names (SANs). When ISA Server bridges a SSL Connection to a web server with a certificate containing SANs, it ignores the CN and only does a name match with the FIRST SAN entry! To work around this make sure the FIRST SAN listed is the same as the CN which in this scenario is MAIL.VIRCOM.CO.UK.

Note:
In a scenario where all the Exchange 2007 roles are not on a single server then all these requirements may not apply to a single certificate.

Creating the SSL Certificate

One nice thing (although there aren’t many) about the new Power Shell with Exchange 2007 is that you can generate a SSL certificate request without having to play with IIS directly. To generate your certificate request file, start up the Power Shell and run the following command (substituting your host and domain names accordingly):

New-ExchangeCertificate -GenerateRequest -SubjectName "DC=vircom, DC=co, DC=uk, O=Vircom, CN=mail.vircom.co.uk" -DomainName mail.vircom.co.uk, smtp.vircom.co.uk, autodiscover.vircom.co.uk, vircom.co.uk, vircom07.vircom.co.uk, vircom07 -FriendlyName "Microsoft Exchange 2007" -Path c:\mail.vircom.co.uk.req

This will generate a certificate request file in the root of the C: drive. Note that the SANs in the certificate will be listed in the same order as they are requested with this command, thus ensure that the FIRST SAN is the same as the CN (mail.vircom.co.uk) to ensure that ISA Server will be able to trust the certificate.

Next go to your Microsoft certificate server web UI (Note the issues using the web UI from Windows Vista How to use Certificate Services Web enrollment pages together with Windows Vista) and request a certificate. Use the CA Administrative tool to approve the certificate request. Next return to the web UI to download the approved certificate in BASE 64 format to the C: of the Exchange 2007 server e.g. c:\mail.vircom.co.uk.cer . At the Power Shell console run the following command (using the appropriate .cer file name):

Import-ExchangeCertificate -path c:\mail.vircom.co.uk.cer

This will complete the SSL certificate creation. You can see the new certificate using the Certificates MMC snap-in. Although the certificate has been created Exchange still has to be configured to use it.

Configuring Exchange 2007 with the new SSL certificate

To configure Exchange 2007 to use a certificate you have to provide the thumbprint of the certificate, so first we need to find out what is the thumbprint of our new certificate. At the Power Shell console run the following command (using the appropriate CN name):

Get-ExchangeCertificate -DomainName "mail.vircom.co.uk"

Note:
Make sure that you use the thumbprint of the Web site certificate that you generated and not the thumbprint of the self-signed certificate that was automatically generated by the MS Exchange installation routine.

A list of certificate details will be presented for certificates that contain your CN. Take note of the thumbprint for the newly created certificate. At the Power Shell console run the following command (using the appropriate thumbprint):

Enable-ExchangeCertificate -thumbprint ED7E626A0A74449F990350349F62EBE6019B04A4 -services "IIS,SMTP"

This will configure the IIS (in other words HTTP) and SMTP services in Exchange 2007 to use the new certificate. You can also configure IMAP, POP and UM (Unified Messaging) to use a specific certificate if required by including “IMAP, POP, UM” in the services list for the above command. The services do not all have to use the same certificate, but you can if you wish to. Just make sure the correct host name is configured in the original certificate request if you use different host names for different services, e.g. imap.vircom.co.uk may be required.

Warning:
During testing it was found when IISRESET was run or the Exchange Server rebooted that IIS would sometimes at random revert back to using the original SSL certificate. It is worth double checking in IIS to ensure that the Web Site is making use of the new certificate after a restart.

As part of the split DNS configuration, the host entry for MAIL.VIRCOM.CO.UK on the INTERNAL zone resolves to the Exchange 2007 server and NOT the ISA Server. This is done so that ISA Server is able establish a connection to the Exchange 2007 server using the same name that External client use which avoids any name translation issues. It also meant that when clients are on the Internal network they access the same URL’s from either side of the ISA server which is much less confusing for end users.

Autodiscover Service

If you want to make use of the new autodiscover service in Exchange 2007 when on the Internet you have some options:

Configure a separate Web Listener on ISA Server with a separate basic public SSL certificate for AUTODISCOVER.YOURCOMPANY.COM. Configure the EXTERNAL DNS to resolve AUTODISCOVER to the IP address of the new listener and use the new Web Listener in the ISA rule that published the autodiscover feature. This option is easy to set up however it will require a separate IP address for the new Web Listener.
Replace your existing public SSL certificate with a new public wildcard certificate. You can then use the same Web Listener on ISA Server. This option is a higher cost option and you will have issues using Windows Mobile devices. Windows Mobile 6 does however support wildcard certificates.

23.9.07

Virtual Private Networking

What is VPN?

The majority of typical VPN-related documents define VPN, as the extension of a private network. However this type of definition means nothing and only characterises the VPN concept as a determining factor of a private network, which is still somewhat unclear. VPN is an abbreviation for Virtual Private Network. Everybody knows what a “network” is making explanations pointless. A private network is one where all data paths are secret to a certain extent, yet open to a limited group of persons, for example, to employees of a specific company. In theory, the simplest way to create such a network would be to isolate this network from the Internet. However in the case of a business with some remote branches it is not so simple. Leased lines could be a solution, but a costly one, which would not necessarily ensure the required degree of security. Furthermore, leased circuits suffer from a single faulty link syndrome – the connection that goes down from time to time may create a major or minor disaster for a company. Besides, there is sometimes a need to give access to a part of the resources of a private network to external users, and that would not be possible over a physically separated network. Of course, a solution might be to employ a remote server however it would involve additional fees for phone sessions that may also be long distance. What about the buzz word “virtual”? At present, VPN is far from being a physically separated structure. It uses the existing infrastructure that encompasses both LANs and WANs, and where an IPv6 backbone may be supported as well as any networking, provided that it may be seamlessly integrated with today’s technologies. Transfer of data over a public network is accomplished using one of the available tunnelling technologies and all data can be encrypted to boost security.

After this introduction, the definition of a VPN as a dedicated private network based on the existing public network infrastructure and incorporating data encryption and tunnelling techniques to provide data security, is pretty straightforward.

What are the benefits of using VPN?

There are several reasons to use VPNs. Sensitive data security is undoubtedly a major issue, as well as other matters such as losing passwords, which contrary to popular belief is not the worst possible fate.

For example, if a multi-branch software development company stores its software source files in a central CVS repository, and a rival IT Company manages to intercept network traffic between the branch and the CVS, it may steal some brilliant ideas incorporated in the software programs. The amount of damages involved in such a case may be millions of dollars however possible lawsuits are rarely as quick and straightforward as expected.

From the economic point of view, creation of a VPN may be less expensive than maintaining leased lines, although the cost of VPN firmware may appear to be enormous. In fact, lost data may turn out to be far more expensive. Costly equipment is rarely needed to implement a VPN. In practice, any Microsoft Windows machine can be used as the VPN client and any Windows 2000 or Windows .NET computer can be configured to be the VPN server.

What protocols can be used over a VPN connection?

The VPN networking concept is based, to a certain extent, on point-to-point links. In VPN networks they are emulated using data encapsulation and tunneling i.e. the data is wrapped with a header that provides necessary routing information. In order to enhance data confidence and integrity, packets being sent may be encrypted prior to entering the tunnel and even if intercepted (which is not difficult as they are sent over a public network), they will remain indecipherable without encryption keys. VPN connections permit users working from home or away on a business trip to obtain a remote, dynamically, set up VPN connection with their company’s Intranet. From the user’s perspective, the VPN is a point-to-point connection within the organisation’s server, which logically operates to some extent as a leased line or provides support for dial-in VPN connectivity.

The VPN gear can be built around various protocols depending on both the hardware and software capabilities. For Windows 2000 general use VPNs, commonly recognized protocols are PPTP and L2TP, combined with IPSec.

Between these two protocols, PPTP is older. It is a Layer 2 (OSI) tunneling protocol that encapsulates PPP frames as IP datagrams. For both tunnel creation and maintenance, PPTP uses the TCP protocol. The encapsulation uses an ephemeral (random) client-side port while the PPTP server is associated with port 1723. Packets are encapsulated using Generic Routing Encapsulation (GRE). PPTP encapsulation for payloads is as follows:
- The payload is encapsulated with a PPP frame.
- The PPP frame is encapsulated with a GRE header and trailer.
- The GRE frame is sent as a new payload for a new IP datagram between the client and PPTP server.

Data encryption is a vital part of a VPN. PPTP uses PPP mechanisms to provide data confidentiality. In Microsoft Windows 2000 implementations, the PPP frame is encrypted with MPPE. The keys for encryption are generated from the MS-CHAP or EAP-TLS authentication process, therefore the client must use either protocol for the communications with the VPN server to be encrypted, otherwise all payloads will be sent in plaintext over the tunnel.

PPTP is documented in RFC 2637.
L2TP protocol is a combination of Cisco® Systems Inc. Layer 2 Forwarding and PPTP using the best of both. L2TP is more flexible than PPTP, its use, however, implies that a more powerful computer is needed than for a PPTP implementation. L2TP operates in Layer 2 (OSI) tunneling protocol. It encapsulates PPP frames to send them between the server and the client. It has been designed to operate directly with various non-IP WAN technologies. Like PPTP, L2TP encapsulates original IP datagrams over the network. Since encryption for L2TP is provided with IPSec, encapsulation is divided into two layers – the initial L2TP encapsulation and the IPSec encapsulation. The process is as follows:
- The initial payload is encapsulated with a PPP frame.
- The PPP frame is placed in a new IP datagram encapsulated with a UDP header and a L2TP header.

TheL2TP encapsulated payload is IPSec i.e. it is added with an IPSec Encapsulating Security Payload (ESP) and an IPSec Authentication trailer (AUTH). In this way, integrity and authentication of messages are provided en route. At this stage, tunnelled messages are not yet encrypted. IPSecESP is the mechanism to provide encryption keys to L2TP data. It is possible to have a non-encrypted L2TP connection where the PPP frame is sent in plaintext. However, such an insecure solution is absurd and is definitely not recommended.

L2TP is documented in RFC 2661.
The main differences between PPTP and L2TP are as follows:
-PPTP requires an IP based network transport layer whilst L2TP only requires that the media provide point-to-point connectivity. So L2TP protocol can be used directly over IP Frame Relay, X.25 and ATM. PPTP cannot support non-IP media directly.
- PPTP supports only a single tunnel between the VPN server and the client. With L2TP, multiple tunnels can be supported to transport payloads end-to-end. Therefore, multi-tunnel operations are possible with L2TP corresponding to various levels of the Quality of Service (QoS) and security.
- L2TP protocol provides header compression mechanisms. When this function is enabled, the L2TP header is smaller than the PPTP header, and will result in fewer simultaneous RTP sessions being required to produce bandwidth efficiencies.
PPTP is still more popular than L2TP, and is used in Microsoft Windows 95, Windows 98, Windows NT 4.0, Windows 2000 and Windows XP/.NET systems. L2TP is supported from Windows 2000 onwards. L2TP implementations for older Windows versions may be available as third party products. In practice it might be difficult to find such solutions whereas for economic reasons, upgrading older OSes to Windows 2000 or XP could be less expensive than extensions of the same.

Although L2TP and PPTP are the main tunneling protocols used in Windows 2000, a certain VPN implementation can be built using the IPSec protocol already mentioned in the discussion on tunneled payload confidence ensured by L2TP. IPSec exists as the Layer 3 (OSI) data tunneling model that uses a specific mode – the ESP Tunnel mode that offers strong IP datagram encapsulation and encryption being sent over a public IP network. With this mode, whole IP datagrams are encapsulated and encrypted using ESP. The IP datagram is finally encapsulated with a new IP header and the new datagram obtained is sent over a network. Upon receipt of the L2TP datagram, the recipient processes the data-link frame to authenticate the content and sends the data to the destination site.

What security mechanisms are available through VPN?

Authorisation – VPN connections are only created for users and routers that have been authorised. For Windows 2000, authorization of VPN connections is determined by dial-in properties on the user account and remote access policies. If a user or router is not authorised for such connections, the server will disable them.

Authentication – This is a vital security concern. Authentication takes place at two levels:

Machine-level authentication – when IPSec protocol is used for a VPN connection, machine-level authentication is performed through the exchange of machine certificates during the establishment of the IPSec connection.
User-level authentication – before data can be sent over the PPTP or L2TP tunnel, the user must be authenticated. This is done through the use of a PPP authentication method.

Data encryption – the protocols used to create VPN connections allow encrypted data to be sent over a network. Although it is possible to have a non-encrypted connection, this is not recommended. Note that data encryption for VPN connections does not provide end-to-end security (encryption), but only security between the client and the VPN server. In order to provide a secure end-to-end connection, the IPSec protocol can be used once a VPN connection has been established.

Packet filtering – in order to enhance security of the VPN server, packet filtering must be configured so that the server only performs VPN routing. To this end, appropriate RRAS filters should be used (for Windows 2000) on the Internet interface of the VPN.

Connecting to the VPN server in Windows OS

Creating the VPN connection for the client is as simple as configuring dial-up networking. Therefore, the role of the system administrator is reduced to configuring the VPN server and making available information of the connection configuration, while the users may carry out the remaining procedures.

Fig. 1 Windows 2000 comes with a Network Connection Wizard for VPN configuration

In order to create a VPN connection:
- Choose NetA and Dial-up Connections followed by Make New Connection,
- Select Connect to a private network through the Internet,
- Enter the IP address of the VPN server,
- Depending on the configuration of the VPN server, a ROM chip may be used to authenticate the user,
- Determine if you want this connection to be made for all users on the network or for your own use only.

Such an established connection may require additional configuration, for example:
- Indicating the protocol type (PPTP or L2TP),
- Indicating the authentication method.

Fig. 2 The configuration of advanced security settings for a VPN connection

IPSec tunneling in Windows 2000

Knowing how to use VPN makes it easier to create a secure IPSec based tunnel between two remote networks. This is a very simple solution that requires two computers running Windows 2000.

Consider the following scenario:
There are two networks that use private addressing, one is called NetA, and the other NetB. Windows 2000 supports IPSec tunneling for situations where both tunnel endpoints have static IP addresses. Therefore, this pre-empts the use of IPSec tunneling for gateway-to-gateway scenarios although it is possible to create tunnels between the server and router. However it is interesting to note that Windows 2000 does not support protocol and port-specific tunnels. This is worth keeping in mind, because the Microsoft Management Console (MMC) interface is very generic and allows association of any type of IPSec filter with a tunnel. One must remember to use only address information in the creation of a tunnel, because the IPSec tunnel secures only traffic specified in IPSec filters. It is also essential to configure filters in Routing and Remote Access Service (RRAS) to prevent traffic outside the tunnel from being forwarded. Two IPSec rules must be created, since two tunnels are to be established, one from NetA to NetB and other from NetB to NetA. Each tunnel is represented by a rule, so two rules are required to configure an IPSec policy for the gateway internal network computers, and more particularly, two filters must be built – one to match packets going from NetA to NetB, and one to match packets going from NetB to NetA.

Typically, a Windows 2000 gateway is not a member of a domain, so local IPSec policies are created. If the Windows 2000 gateway is a member of a domain that already exists, a local IPSec policy may prevent the gateway from having its local IPSec settings. In this case, creation of an Organizational Unit (OU) in Active Directory is necessary to make the gateway a member of this OU, followed by assigning appropriate IPSec settings.

Fig. 3 An exemplary IPSec tunneling

The first phase in creating a tunnel consists in establishing the IPSec policy outlines. To do this, follow these steps:
- Activate the MMC to work on the IP Security Policy Management,
- Right-click IP Security Policies on Local Machine, and then select Create IP Security Policy,
- Click to clear the Activate the default response rule check box.

It is generally a good idea to give a sensible name to the rule and fill the check box to skip further steps related to the rule issues.
Once a general scheme of the rule has been created, you must build the filters corresponding to the traffic from NetA to Net B and from NetB to NetA. To do this, follow these steps:
- Click to clear the Use Add Wizard check box and then click Add, to create a new rule,
- On the IP Filter List tab, select Add,
- While defining the Source address select A specific IP Subnet, and then insert the data for NetA (assuming that the tunnel from NetA to NetB is to be created first),
- While defining the Destination address click also A specific IP Subnet and fill in the boxes for NetB’s address and mask,
- Click to clear the pole Mirrored, so the rule is not associated with the packets sent from NetB to NetA,
- On the Protocol tab, make sure that the protocol type is set to Any.

Fig. 4 Configuring the tunnel filters

Fig. 5 A versatile character of MMC may be misleading. The IPSec tunneling does not support protocol and port-specific tunnels.

Building a filter list for traffic from NetB to NetA follows the same steps, except that it is necessary to define appropriate addresses of the networks, i.e. NetB as a source and NetA as a target respectively.

Once the filters have been configured, create the tunnel. If it is the case of the traffic from NetA to NetB proceed as follows:
- On the IP Filter List tab, click the filter from NetA to NetB.
- On the Tunnel Setting tab, insert the IP address assigned to the gateway internal network adapter for NetB.
- On the Filter Action tab, click to clear the Use Add Wizard check box, and then click Add to create a new filter action.
- Keep the Negotiate security option enabled and click to clear the Accept unsecured communication, but always respond using IPSec check box.
- Click Add and keep the High (ESP) option selected; or you can select Custom, (but only if you know what you are targeting).
- Once the new filter action has been configured, on the Authentication Methods tab set up the authentication methods to be used. Use preshared keys for testing, otherwise use certificates for product authentication. Kerberos is technically possible, but rarely used. (Kerberos is the perfect solution to deploy secure communications across trusted domains).

The same steps as above should be made for traffic from NetB to NetA, remembering to change the IP tunnel endpoint address of the NetA computer.

In order to verify the functioning of the tunnel, use ping and IP Security Monitor programs. For Monitoring - you can additionally test the traffic using the IPSec formatted packets with a packet sniffer to verify whether the traffic is really encrypted.

Reading about VPN may create a false sense of security, which may be dangerous. Obviously, VPN secures the traffic between networks but internal traffic remains unencrypted and vulnerable to attacks of network sniffers that may intercept sensitive data. It may seem that intruders would not be able to gain access to the internal network but this would be an erroneous assumption. Remember that, from a statistical point of view, more than 80% of network security violation attempts are from within the network! Frequently, networks that are well secured from outside intrusions are sorely lacking in internal network security. IPSec may be an option to enhance corporate security by protecting internal network traffic. If this is to be a Windows 2000 domain-based network combined with Active Directory, creation of appropriate rules and requirements from computer clients is not a complex task and significantly improves internal network security.

Will a VPN implementation solve all problems related to safeguard of sensitive data? No, definitely not. IT security is a large and challenging issue and there is no single panacea for all security needs. However, VPN is a vital component of a secure corporate network.

Comparing VPN Options

Four Favorite Flavors of VPN

Because a VPN creates a secure “tunnel” through the public network, the protocols used to establish this tunneled connection are called tunneling protocols. If you ask the typical Windows administrator to name five VPN tunneling protocols, he/she is apt to get be stumped, having dealt only with the two VPN methods for which Windows provides built-in support. The five most common methods of creating a virtual private network include:

PPTP
L2TP
IPSec
SSL

The first two, of course, are familiar to Windows admins. The last two may be less so. Unfortunately, there is no clear cut one-size-fits-all solution. The best choice for your organization depends on a number of factors: server and client operating systems deployed, network resources to which access is needed, level of security required, performance issues, administrative overhead, and so forth.

PPTP

The Point-to-Point Tunneling Protocol (PPTP), developed by Microsoft in conjunction with other technology companies, is the most widely supported VPN method among Windows clients, and it is the only VPN protocol built into Windows 9x and NT operating systems. PPTP is an extension of the Internet standard Point-to-Point protocol (PPP), the link layer protocol used to transmit IP packets over serial links. PPTP uses the same types of authentication as PPP (PAP, SPAP, CHAP, MS-CHAP, EAP).

PPTP establishes the tunnel but does not provide encryption. It is used in conjunction with the Microsoft Point-to-Point Encryption (MPPE) protocol to create a secure VPN. PPTP has relatively low overhead, making it faster than some other VPN methods.

Because the client software is built into most Microsoft operating systems, PPTP servers can be deployed without having to worry about installing client software on those systems. PPTP clients are also available for Linux (see http://pptpclient.sourceforge.net/) and Macintosh OS 9.x (see http://www.rochester.edu/its/vpn/tunnelbuilder.html). Mac OS X 10.2 comes with built-in support for PPTP, and there are also third-party clients available for OS X (see http://www.gracion.com/vpn/). PPTP VPNs are supported by many major firewall appliances and enterprise level software firewalls, including ISA Server, Cisco PIX, SonicWall and some models of WatchGuard.

PPTP has been criticized in the past for various security flaws; many of these problems have been addressed in current versions of the protocol. Using EAP authentication greatly enhances the security of PPTP VPNs. One advantage of using PPTP is that there is no requirement for a Public Key Infrastructure; however EAP does use digital certificates for mutual authentication (both client and server) and highest security.

L2TP

The Layer 2 Tunneling Protocol (L2TP) was developed in cooperation between Cisco and Microsoft, combining features of PPTP with those of Cisco’s proprietary Layer 2 Forwarding (L2F) protocol. One advantage of L2TP over PPTP is that it can be used on non-IP networks such as ATM, frame relay and X.25. Like PPTP (and as its name implies), L2TP operates at the data link layer of the OSI networking model. L2TP VPNs are supported by many major firewall products, including ISA Server, CheckPoint, Cisco PIX, and WatchGuard.

The L2TP client is built into Windows 2000, XP and 2003, but you can download client software for most pre-Windows 2000 operating systems (Windows 98, ME and NT 4.0).

IP Security (IPSec), and more specifically its Encapsulating Security Payload (ESP) protocol, provides the encryption for L2TP tunnels.

L2TP requires the use of digital certificates. User authentication can be performed via the same PPP authentication mechanisms as PPTP, but L2TP also provides computer authentication. This adds an extra level of security.

L2TP has several advantages over PPTP. PPTP gives you data confidentiality, but L2TP goes further and also provides data integrity (protection against modification of the data between the time it left the sender and the time it reached the recipient), authentication of origin (confirmation that the user who claims to have sent the data really did), and replay protection (which keeps a hacker from being able to capture data that is sent, such as the sending of credentials, and then “replay” it to “trick” the server). On the other hand, the overhead involved in providing this extra security can result in slightly slower performance than PPTP.

IPSec

Windows administrators know IPSec as the protocol used for encryption in conjunction with the L2TP tunneling protocol. However, IPSec can itself be used as a tunneling protocol, and is in fact considered by many to be the “standard” VPN solution, especially for gateway-to-gateway (site-to-site) VPNs that connect two LANs. IPSec operates at a higher level of the OSI model, the network layer (Layer 3).

Many hardware VPN appliances use an implementation of IPSec. For example, Cisco’s VPN Concentrators and PIX firewalls support IPSec, as do NetScreen, SonicWall, and WatchGuard appliances. Enterprise level software firewalls such as ISA Server, CheckPoint and Symantec Enterprise Firewall also support IPSec VPNs.

IPSec in tunnel mode secures packets that are transmitted between two gateways or between a client computer and a gateway. As its name implies, an IPSec VPN works only with IP-based networks and applications. Like PPTP and L2TP, IPSec requires that the VPN client computers have client software installed.

Authentication is accomplished via the Internet Key Exchange (IKE) protocol with either digital certificates (which is the more secure method) or with a preshared key. IPSec VPNs can protect against many of the most common attack methods, including Denial of Service (DoS), replay, and “man-in-the-middle” attacks.

Many vendors include “managed client” features in their VPN client software, which make it possible for you to establish policies regarding such things as a requirement that the client machine have anti-virus software or personal firewall software installed in order to be allowed to connect to the VPN gateway.

IPSec support is included in Windows 2000/XP/2003, but not in older Windows operating systems. VPN gateway vendors, such as Cisco and CheckPoint, provide client software for their IPSec-based VPNs. Note that you may have to purchase licenses for the client software.

SSL

A VPN technology that has been growing in popularity is the Secure Sockets Layer (SSL) VPN. A big advantage of SSL VPNs is that you don’t need special VPN client software on the VPN clients. That’s because the SSL VPN uses the Web browser as the client application. Thus, SSL VPNs are known as “clientless” solutions. This also means the protocols that can be handled by an SSL VPN are more limited. However, this can also be a security advantage. With SSL VPNs, instead of giving VPN clients access to the whole network or subnet as with IPSec, you can restrict them to specific applications. If the applications to which you want to give them access are not browser-based, however, custom programming might be necessary to create Java or Active-X plug-ins to make the application accessible through the browser. A disadvantage of this is that in order to use such plug-ins, the client’s browser settings will have to be opened up to allow active content – thus exposing the browser to malicious applets unless you set it to block unsigned active content and ensure that the plug-ins are digitally signed.

SSL VPNs operate at an even higher layer of the OSI model than IPSec VPNs: the session layer. This gives them the ability to control access more granularly. SSL VPNs use digital certificates for server authentication. Other methods can be used for client authentication, but certificates are preferred as the most secure.

Even though there is no client software installed (other than the Web browser), SSL VPN gateways can still provide the advantages of “managed clients” by forcing the browser to run applets, for example, to verify that anti-virus software is in place before the VPN connection can be established.

Summary

Virtual private networking is often the best and most cost effective way to provide remote access to your company network. The first step in deploying a VPN server/gateway is selecting the type of VPN technology to use. The four most common VPN technologies in use are PPTP, L2TP, IPSec and SSL. Each has advantages and disadvantages, so it is important to familiarize yourself with the characteristics of each, and with your users’ needs, before making a decision. In this article, we’ve provide a brief overview of each of these VPN protocols.

How URL Authorization Increases Web Server Security

Web servers, by their very nature, are usually exposed to outsiders and thus are vulnerable to compromise and attack. Internet Information Services (IIS) version 6, included with Windows Server 2003, provides a number of new security features designed to increase web server security. One of these is URL authorization, which works in conjunction with Server 2003’s Authorization Manager. In this article, we’ll take a look at how URL authorization is implemented in IIS 6.0, the practicalities of using it in your web services environment, and how it enhances the security of your web sites and services.

Why URL Authorization?

Web sites are set up for many different purposes. A popular use of the web (especially on intranets) is to allow a group of people to access information they need to do their jobs, quickly and easily via a standard interface (the web browser) from any location (office, home, on the road). However, this information is often proprietary or sensitive, and you don’t want just anyone to be able to access it just because it’s on the web server.

That’s where URL authorization comes in. In these cases, we need a mechanism for controlling who can or can’t gain access to a particular web page or site. There are several ways to do this – for instance, by setting password protection on the page. The problem with this solution is that if an unauthorized person discovers (or guesses) the password, he/she will be able to access the page. A more secure way to control access is to tie it to the user’s account in the domain and/or role in the organization. Windows Server 2003 gives you a way to do this, by implementing URL authorization and configuring role-based authentication via Authorization Manager. Web applications written within the ASP.NET framework can use URL authorization to control access.

The Role of Authorization Manager

Authorization Manager is a Windows Server 2003 utility that is used to implement role based administration via authorization rules, which are scripts that configure settings to authorize users or computers for specific roles. The user roles are generally based on users’ job duties, whereas computer roles are based on the functionality of the machine within the network (for example, a web server). For more information on role-based access control and Authorization Manager, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetserv/html/AzManBizRules.asp.

User roles can be defined in Lightweight Directory Access Protocol (LDAP) queries. The user object will contain information about the user that can be accessed via an LDAP query, and this information can be used to determine whether a user fits the criteria that qualifies him/her for that role. For example, you might want to restrict the access to a particular web page to only user who work at a specific geographic location.

You can also restrict the time of day or day(s) of the week that the users can access the web page, by creating BizRules. These are dynamic business rules, which are simply scripts that are attached to task objects. They’re used to authorize users based on information that is only available at runtime (the time during which the script is run) such as the time of the day or day of the week. BizRule scripts can be written in VBScript or Jscript. You need to be familiar with one of these scripting languages to create BizRules. BizRules are added or edited with the Authorization Manager MMC, which can be opened by typing azman.msc at the Run box. For more information on creating BizRules and loading the script into the authorization store, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetserv/html/AzManBizRules.asp.

How URL Authorization Works

When you use URL authorization to control access to web resources, IIS will determine the user’s roles and base authorization decisions on that information. The software component that handles this task is the Internet Server Application Programming Interface (ISAPI) interceptor.

How to Use URL Authorization

URL authorization is not enabled by default in IIS 6.0. To use it, you’ll first need to enable the ISAPI interceptor. The file name is Urlauth.dll, and it has to be enabled for each individual web site for which you want to use URL authorization. Note that you need a local administrative account (or delegated authority) on the computer running IIS 6.0 to enable the ISAPI interceptor. Here are the steps required to do so:

Click Start | All Programs | Administrative Tools | Internet Information Services.
In the left pane of the IIS Management console, expand Web Sites.
Right click the web site for which you want to use URL authorization and select Properties.
Click the Home Directory tab. Select Configuration under Application settings.
Click the Mappings tab. Click Insert under Wildcard application maps.
In Add/Edit Application Extension Mapping, click Browse and navigate to the following directory: Windows\system32\inetsrv.
Select urlauth.dll. Click Open. Click OK.
You’ll need to repeat this process for each web site that will use URL authorization.

After you enable the ISAPI interceptor, you’re still not yet ready to use URL authorization. First, you need to set several metabase properties on the URL. These include the following:

AzEnable to enable URL authorization for that URL
AzStoreName to associate the URL with an authorization manager store
AzScopeName to associate the URL with a scope
AzImpersonationLevel to configure the web application to impersonate either the user, the IIS worker process or the IUSER_ account

To set the impersonation level, you can a value of 0, 1 or 2. A setting of 0 indicates authentication of an authenticated client. A setting of 1 indicates impersonation of the IIS worker process. A setting of 2 indicates impersonation of the anonymous user account.

You’ll need some scripting skills to set these metabase properties.

For sample scripts and detailed step by step instructions on configuring URL authorization in IIS 6.0, see http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/maintain/security/AthManWp.asp.

Summary

URL authorization is one of many new security features in Internet Information Services 6.0, the latest version of Microsoft’s web server software built into Windows Server 2003. URL authorization uses the Authorization Manager to give you more control than ever over access to web pages and web applications. If you need to control access based on user roles, check out this important new feature.

15 steps to hardening Windows Server 2003

: Jonathan Hassell, author of "Hardening Windows," recently conducted a checklist-style webcast that outlined 15 steps you can take right now to harden Windows Server 2003 against various threats. If you haven't viewed the webcast, here's a look at Jonathan's 15 steps and some of the main points he discussed. For the complete information and detailed expert advice, you may view the webcast any time.
Step 1: Be rigid on passwords
Main points: Enforce stronger authentication by encouraging the use of passphrases and requiring a 15-character minimum.
Step 2: Use Windows XP software restriction policies through Group Policy
Main points: Use Group Policy to block all extensions related to scripts and disallow especially nefarious programs (cmd. exe, Regedit.exe).
Step 3: Enable Internet Connection Firewall (ICF)
Main points: Almost every machine in your company can benefit from having a firewall. ICF only blocks incoming traffic, uses stateful packet inspection and allows you to force open particular ports.
Step 4: Kill LM hashes
Main points: To eliminate LM hashes, require a 15-character minimum for passwords and enable the Security Option "Network Security: Do not store LAN manager hash value on next password change."
Step 5: Strengthen TCP/IP stack
Main points: You should not connect Windows systems directly to the Internet. Instead increase RAM for TCP connections and decrease timeout values for 3-way handshakes.
Step 6: Mandate SMB signing
Main points: SMB signing will help you prevent man-in-the-middle attacks.
Step 7: Harden network policies
Main points: You should enable settings like "Do not allow anon. enum of SAM" and disable settings like "Allow anonymous SID/Name translation." This may be considered security by obscurity, but it's an important component of hardened Windows systems.
Step 8: Use Software Update Services (SUS)
Main points: You should always use SUS or some other patch management system to receive, distribute and schedule the most up-to-date patches.
Step 9: Rope off, quarantine, sanitize
Main points: This is a very important step. Using Network Access Quarantine Control, you should limit or disallow resources to certain clients, put non-quarantined clients in a holding bin to verify system attributes and finally provide resources to fix any problems discovered before they're allowed to connect.
Step 10: Plan for the worst
Main points: To plan for disasters, use scripts to build up 80% of your infrastructure and leave yourself much more time to manually reconstruct the remaining 20%.
Step 11: Get the Group Policy Management Console
Main points: It's now easier than ever to use Group Policy to set security policies across the board -- and you should take advantage of it.
Step 12: Use the Microsoft Baseline Security Analyzer (MBSA)
Main points: This is a handy tool used to scan computers in a Windows Update-like fashion. It is continually updated by Microsoft and it supports a number of products.
Step 13: Familiarize yourself with IPsec
Main points: IP is too public not to be encrypted. You should use IPsec to protect transmissions between servers, client tunnels and any point-to-point IP transactions where both ends know how to read IPsec.
Step 14: Use Internet Information Services (IIS) 6.0
Main points: Thanks to many new security improvements, IIS is finally ready for prime-time hosting.
Step 15: Play with Windows Server 2003 Service Pack 2 or latest
Main points: always update all hot fix

29.9.07

28.9.07

The FrontPage Server Extensions

What are the Security Issues?

Protecting FrontPage Web Sites

TIP # 1: Disable Anonymous Access.

TIP # 2: Enable Logging.

TIP # 3: Harden your ACLS.

TIP # 4: Setup your FTP site as Blind Put.

TIP # 5: Enable Disk Quotas.

TIP # 6: Use Logon Time Restrictions.

TIP # 7: Restrict Access by IP.

TIP # 8: Audit Logon Events.

TIP #9: Enable Strong Password Requirement.

TIP # 10: Enable Account Lockout and Account Lockout Threshold.

PowerShell Default Security

Going Beyond the Defaults

Summary

27.9.07

25.9.07

Getting Started

SSL Certificate Requirements

Creating the SSL Certificate

Configuring Exchange 2007 with the new SSL certificate

Autodiscover Service

23.9.07

What is VPN?

What are the benefits of using VPN?

What protocols can be used over a VPN connection?

What security mechanisms are available through VPN?

Connecting to the VPN server in Windows OS

IPSec tunneling in Windows 2000

Four Favorite Flavors of VPN

PPTP

L2TP

IPSec

SSL

Summary

Why URL Authorization?

The Role of Authorization Manager

How URL Authorization Works

How to Use URL Authorization

Summary

Viet4Design - Latest News

Sức mạnh số - Dân trí điện tử Dantri.com.vn

Viet4Design

Viet4Design - Help Desk

Link

Giới thiệu bản thân