نمایش نتایج: از شماره 1 تا 7 از مجموع 7

موضوع: Describing an alternative method to FTP over TLS by the use of WebDav over TLS published through ISA

  
  1. #1
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272

    Describing an alternative method to FTP over TLS by the use of WebDav over TLS published through ISA

    کد:
    http://www.carbonwind.net/ISA/WebDav/WebDav1.htm
    Part 1 - Overview

    In this article we will describe an alternative method to FTPS(FTP over TLS).
    A lot of people use WebDav over TLS for viewing files and easily manage them(drag and drop). It's actually quite popular among universities for example.
    The old FTP protocol does not meet the security requirements for transfering files over an insecure connection. FTP over TLS can perform secure file transfers. It uses SSL/TLS to encrypt the control and/or data channels. RFC4217 Securing FTP with TLS, an "Internet Official Protocol Standards" (STD 1), describes FTPS.
    Before moving to WebDav let's first discuss FTP and FTPS. You can skip this part but I think is quite useful to put a couple of pictures along with a few comments about FTP and FTPS.
    Note: FileZilla FTP Server and Serv-U FTP Server (Trial Version) were used as the FTP servers within this article. GlobalScape CuteFTP 8.1 Professional (Trial Version) served as the FTP client. The FTP server is using 192.168.22.58 as the IP address and the FTP client 192.168.22.70 respectively.
    Without entering into a too technical dicussion let's quickly analyse FTP and FTPS.
    As you might know FTP uses a control channel and a data channel. By default, FTP servers listen on TCP port 21 for incoming connections from FTP clients. So TCP port 21 is used for the control connection used to exchange FTP commands and control information. For the data connection, for Active FTP, TCP port 20 is used and for Passive FTP, a random TCP port is used on the server side. The data connection is used to transmit the files.
    In case of Active FTP the client issues the "PORT" command specifying a port on which the server will connect back for the data connection. Then the server wil connect using the source TCP port 20 and the destination port which was specified by the client with the "PORT" command(see Figure1, a Wireshark capture).

    Figure1: The FTP PORT Command
    If the client is behind a firewall, this firewall(if unaware of the FTP protocol) will simply drop this connection because it appears as an inbound connection.
    "A Firewall-Friendly" approach will be to use Passive FTP. In this case the FTP client will issue the "PASV" command to the server and the server will pick up a random port on which the client will connect back for the data connection(see Figure2).

    Figure2: The FTP PASV Command
    If the FTP server is behind a firewall doing NAT, the firewall must recognize FTP in order to allow the connection for the data channel. And that's not all. As you can see from Figure2, the server response to the "PASV" command contains an IP address. Since the server is behind a NAT device, it must be aware of the public IP address of that NAT device(some FTP servers let you manually specify it or can detect it by themselves or the FTP client, like the FileZilla FTP Client, can be configured to use the server external IP address instead of the local one received within the response to the PASV command). To overcome this issue the client can use the "EPSV" command ("Extended Passive Mode"). Doing so, the server will reply back only with the port number and the client assumes that it will connect to the same IP address that was originally connected to (see Figure3). Please refer to RFC2428 FTP Extensions for IPv6 and NATs, an "Internet Official Protocol Standards" (STD 1).

    Figure3: The FTP EPASV Command
    However not all the FTP servers currently support the EPSV command. We can draw a simple conclusion: we need more ports "open" on the firewall from a packet filtering point of view and also it is desirable to have an application filter for FTP. ISA 2006 Firewall comes with an application FTP filter, please read the following:
    http://www.microsoft.com/technet/isa/2006/application_filters.mspx
    As you can notice the simple FTP protocol can put some pressure on the firewall.
    Talking about FTPS, some firewalls might simply throw in the towell due to fact that the control and data chanels are encrypted so the firewall can't inspect FTP traffic and thus recognize FTP commands.
    But how FTPS work?
    We have two modes: Explicit SSL(preferred mode as defined per RFC) and Implicit SSL(an old mode).
    Implicit SSL means that the connection is secured by default and the client will connect to TCP port 990.
    Explicit SSL means that security can be requested when desired with the "AUTH SSL" command (see Figure4 and Figure5). Note that the "AUTH TLS" command can be used too (see Figure6).

    Figure4: FTPS PASV Requesting AUTH SSL

    Figure5: FTPS PASV Starting the data connection

    Figure6: FTPS PASV Requesting AUTH TLS
    Now the authentication and the "PASV" or "PORT" commands are protected by SSL. Therefore the firewall cannot sniff anymore the ports required by FTP in order to dynamically "open" up them.
    However the control channel or the data channel can remain unprotected.
    The data channel is secured by use of the "PBSZ" ("Protection Buffer Size") and "PROT" ("Data Channel Protection Leve"l) commands. See RFC2228 FTP Security Extensions, an "Internet Official Protocol Standards" (STD 1).
    According to RFC2228:
    "The PBSZ command is compulsory prior to any PROT command. This document also defines a data channel encapsulation mechanism for protected data buffers. For FTP-TLS, which appears to the FTP application as a streaming protection mechanism, this is not required. Thus, the PBSZ command MUST still be issued, but must have a parameter of '0' to indicate that no buffering is taking place and the data connection should not be encapsulated."
    So the FTPS client will use the "PBSZ 0" command(no buffering) prior to the "PROT" command.
    The FTPS client normally issues the "PROT P" command meaning that the protection level is set to "Private", this indicates that the data will be integrity and confidentiality protected.
    But the client can issue the "PROT C" command (the protection level is "Clear") meaning that the data channel will carry the raw data of the file transfer, with no security applied. Therefore only the control channel is protected (the credentials are protected too).
    Also the client can issue the "CCC (CLEAR COMMAND CHANNEL)" command meaning that the credentials, the "PBSZ" and "PROT" commands will be secured while the rest of the control session continues in plaintext, thus the "PASV" command will be sent in clear(see Figure7 and Figure8, now 192.168.22.70 represents the FTP server). Typically the "AUTH" (authentication needed), "USER" (specify user name), "PASS" (specify user's password), "PBSZ", and "PROT" commands would be protected within the TLS protocol and then the "CCC" command(also TLS protected) would be issued to return to a plaintext socket state.

    Figure7: FTPS PASV CCC

    Figure8: FTPS PASV CCC, the PASV command is sent in clear
    Note that the use of the "CCC" command has serious security issues since an attacker could insert a command on the control stream, and the server would have no way to know that it was invalid. One scenario where the "PROT C" might be used is the case when the credentials must be protected but the data can be passed in clear.
    Therefore it is unlikely that the firewall will see the needed FTP commands in order to properly allow FTPS communication.
    Also the firewall cannot trully inspect (meaning application layer inspection) the FTPS traffic(in case you publish a FTPS server behind it) because it is encrypted thus the firewall is dumbed into stateful packet filtering mode which really does not give you much for your server these days (and TCP ports used for filtering are meaningless, you can pass "anything" over TCP port 21).
    For a high security environment, a feasible scenario will be to first pre-authenticate the client at the firewall and then allow traffic to pass while the firewall is able to inspect/filter the encrypted traffic passing through it.
    Also, if you connect to a remote FTPS server behind your firewall, if you do not know the exact port range used by the remote FTPS server(for Passive mode) you might need to allow through your firewall communications over TCP ports > 1023 to the IP adrress of the FTPS server(something you may not want). So a restrictive firewall policy might block your FTPS access.
    FTPS allows you to request a client certificate, so you can use two level of authentication, TLS and user credentials(user name and password). But both the FTPS Server and Client must support this.
    Enough about FTPS.
    WebDAV(Web-based Distributed Authoring and Versioning) refers to a set of extensions to the HTTP (Hypertext Transfer Protocol) which allows users to download, upload, edit, rename or delete files(thus to manage files) on remote World Wide Web servers.
    WebDav is described through the following RFCs:
    RFC2291 Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web, "provides information for the Internet community. It does not specify an Internet standard of any kind."
    RFC2518 HTTP Extensions for Distributed Authoring - WebDAV, an "Internet Official Protocol Standards" (STD 1)
    RFC3253 Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning), an "Internet Official Protocol Standards" (STD 1)
    RFC3648 Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol, an "Internet Official Protocol Standards" (STD 1)
    RFC3744 Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol, an "Internet Official Protocol Standards" (STD 1)
    RFC4316 Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties, "an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind."
    RFC4331 Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections, an "Internet Official Protocol Standards" (STD 1)
    RFC4437 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources, "an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind."
    RFC4709 Mounting Web Distributed Authoring and Versioning (WebDAV) Servers, "provides information for the Internet community. It does not specify an Internet standard of any kind."
    RFC4791 Calendaring Extensions to WebDAV (CalDAV), an "Internet Official Protocol Standards" (STD 1)
    RFC4918 HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV), an "Internet Official Protocol Standards" (STD 1)
    We are going to use WebDAV over SSL to securely publish content to an IIS 6.0 (Internet Information Services) web server(Windows 2003 Standard R2 SP2).
    WebDAV adds methods like "PROPFIND", "MOVE", "COPY", "MCKOL", "PROPPATCH", "LOCK" or "UNLOCK" to HTTP.
    WebDAV uses port 80, the same port used by HTTP. Within this article we will tunnel WebDav over TLS thus TCP port 443 will be used. Already a contrast with FTPS where we need a couple of TCP ports, thus our firewall is starting to not feel the pressure. And when we are away behind a restrictive firewall we should be able to connect without any major problems.
    With WebDAV you can edit files directly on the remote server, just as they were locally on your computer(with the right client on a fast network).
    Also while allows multiple users to read a file, WebDAV lets only one user to modify a file at a time. So the file is locked(overwrite prevention) while it's being edited. And WebDav can be used for file storage(web-based) accessible from anywhere(you can easily download, upload, rename, move or delete files) which we want to achieve.
    As you can see WebDav has certain advantages over FTP.
    In the scenario described within this article, you have the following options for viewing/accessing data(Windows XP has a built-in WebDAV client):
    Note: Figure9-14 show images while the IIS 6.0 server is behind the ISA 2006 Firewall.
    - Use the web browser interface(see Figure9 and Figure10), so you can browse, list, save or open(supported files)
    - “Open as Web Folder” from Internet Explorer(by selecting File/Open and checking the checkbox mentioned before), see Figure11. Here you can "upload" files too, rename or move.
    - Add a Network Place in My Network Places thus creating a shortcut to the web folder(see Figure12). For example you can directly open Office documents(such as Word docs), edit them and save them to your Web Folder from within the application.

    Figure9: IE 7.0 Web Browser Interface

    Figure10: Firefox 2.0 Web Browser Interface

    Figure11: Accessing the Web Folders

    Figure12: Accessing the Web Folders from My Network Places
    However the Windows built-in WebDAV client migth have some bugs.
    Talking about Linux Distributions, Figure13 shows CentOS(version 4.4) in action under the scenario from this article. The WebDav client used by CentOS is Neon 0.24.6.

    Figure13: Accessing remote files through WebDavs on CentOS

    To unleash the power of WebDav you can use the WebDrive application(version 7.34 was used within this article), see Figure14, which mounts a WebDAV site as a seperate drive, like W:. Then, any program or so can be used to open/edit your documents, you can upload and download files, browse and so on. Although WebDrive is not free(you can download a trial version to see it in action) immediately starts packin' and runs like a champ.

    Figure14: WebDrive
    Other OS's have their own WebDav clients, for example OS X( I can't discuss it because I do not have a Mac). We will talk more about various WebDav clients later.
    Publishing WebDav over TLS through ISA 2006 Firewall enable us to use features like SSL bridging, pre-authentication, HTTP filtering or user level control.
    Actually adding ISA 2006 Firewall into equation gives us a high secure method for transfering files.
    Since ISA pre-authenticates any client, no packet will reach the IIS server before ISA accepts the user credentials. Also ISA does SSL bridging meaning that you actually terminate the TLS tunnel on ISA and ISA initiates another TLS connection to the IIS server. In this way ISA is able to do HTTP filtering(normaly encrypted traffic cannot be inspected by the firewall) which is a key security feature these days. Since you know what HTTP methods are good for your WebDav server you can instruct ISA to allow only these methods. Thus if for example ISA is set not to allow the "DELETE" method, when the client will use it, it will blocked at the firewall and therefore it will never reach the IIS server.
    So with ISA 2006 Firewall the high security scenario becomes immediately feasible.
    Figure15 shows the network diagram.

    Figure15: The Network Diagram
    ISA 2006 Firewall has three NICs: WAN(External Network), LAN(Internal Network) and DMZ(Authenticated DMZ). Also ISA is a domain member.
    As you can see the WebDav server is located on an authenticated DMZ meaning that it is a domain member. Therefore you need to allow intradomain communication through ISA between the DMZ and the Internal Network.
    Why ? Is really necessary to have this authenticated DMZ(instead of a normal DMZ) ?
    Maybe not. However you can gain advanced control over what your users do by using domain accounts. ISA pre-authenticates the clients and then delegates credentials to the IIS server using domain credentials. Very simple and efficient. Most likely this scenario applies very well in the case of private corporate FTPS like access.
    Using NTFS permissions on the IIS 6.0 server with domain accounts you can centrally manage access to the folders published. In fact every user can end-up with his/her own home directory while other general folders can use Domain Groups permissions(more restrictive). Therefore you can easily achieve a granular control on the IIS server.
    With ISA 2006 pre-authentication you can do more than only limit who's accessing the WebDav server. You can "multiply" your web publishing rule(meaning simply copy and paste) and then apply the "new" web publishing rule to another set of users. Say Rule 1 will allow multiple HTTP methods for a group of users(power users) while for another group of users with Rule 2 you can allow only a few HTTP methods(block "DELETE", "PUT", "COPY" and "MOVE" for example). Thus this group can only view and secure download data while they cannot delete, upload, duplicate or rename files on the server. Rules are processed from top to down. It is assumed that the appropiate NTFS permissions are set on the WebDav server. But with ISA you have the chance to block the unwanted/dangerous actions at the firewall. We will discuss later all these.






    موضوعات مشابه:

  2. #2
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.carbonwind.net/ISA/WebDav/WebDav2.htm
    Part 2 - Configure the IIS Server

    Let's proceed with the configuration of the IIS 6.0 server.
    First thing make sure WebDav is installed and enabled on your IIS server. See Figure16. Note that this is a global setting, not one per web site.

    Figure16: WebDav Enabled
    I have created a new web site on the IIS 6.0 server. It's called WebDavShare.
    Next we need to create a new Virtual Directory. See Figure17.

    Figure17: IIS New Virtual Directory
    Click "Next" on the "Welcome to the Virtual Directory Creation Wizard" screen.
    Enter a "Virtual Directory Alias". This will be used within the URL to your site. SharedDoc was my option. See Figure18.

    Figure18: Virtual Directory Alias
    Click "Next".
    Enter the path to the "Web Site Content Directory". I have created a folder named ShareMe on drive C:. See Figure19.

    Figure19: Web Site Content Directory
    Click "Next".
    Set the Virtual Directory Access Permisions. I have allowed "Read", "Write" and "Browse". See Figure20.

    Figure20: Virtual Directory Access Permisions
    And click "Next".
    Then "Finish".
    Time to mess with NTFS permissions. Right click on the SharedDoc Virtual Directory and click "Permissions". See Figure21.

    Figure21: SharedDoc Permissions
    This will bring up the NTFS permissions for the ShareMe folder. See Figure22.

    Figure22: ShareMe NTFS Permissions
    Here you can do a lot. To not be caught up in an endless discussion, I will say that I have created two Domain Groups: WebDav Users and WebDav2 (it's out of the scope of this article to discuss NTFS permissions).
    For example the WebDav Users Group has the following permissions over ShareMe: "Read & Execute", "List Folder Contents" and "Special Permissions".
    You can view the effective permissions for this group by clicking the "Advanced" button from Figure22 and go to the "Effective Permissions" in the "Advanced Security Settings for ShareMe". Select the WebDav Users Group. See Figure23.

    Figure23: Effective Permissions for WebDav Users
    The Special Permissions are "Create Files/Write Data", "Create Folders/Append Data". See the Permissions for files and folders Microsoft Doc.
    As you can notice these users cannot delete files. However the "Creator Owner" has "Special Permissions" too . See Figure24 .

    Figure24: Creator Owner
    You can view this "Special Permissions" by clicking "Advanced" and on the "Permissions" tab in the "Advanced Security Settings for ShareMe" and select "Edit". See Figure25.

    Figure25: Creator Owner Permissions
    And this "Special Permissions" are in this case "Full Control" over "Subfolders and files only". Therefore if an user uploads a file onto the server he/she can delete it. See Figure26.

    Figure26: Creator Owner Special Permissions
    So the conclusion is very simple: you have a lot of power with the NTFS permissions on the WebDav server, so you should carefully review the permissions you will set.
    Another example: I have created a special folder on the WebDav server called "Edit and Review Required". Within this folder I can place for example some Word docs which can be edited directly while they are on the WebDav server. With the help of the "LOCK" method other users can view the doc being edited but can't modify it (the "UNLOCK" method is used to unlock the doc). If the Word application is used the entire process is transparent for the end user(we will discuss later this aspect). The permissions for this folder can be seen in Figure27. Additionally the "Write Attributes" and the "Write Extended Attributes" are allowed for this folder. See more about permissions in the Permissions for files and folders Microsoft doc.
    The users aren't allow to delete files/folders within the "Edit and Review Required" folder.

    Figure27: Edit and Review Required Folder Permissions
    As you probably know the permissions can be inhereted or not. The "Edit and Review Required" folder keeps some of the "ShareMe" folder permissions and also adds new ones.
    A quick and general conclusion about NTFS permissions:
    - You need "Read & Execute", "List Folder Content", "Read" along with the Special Permissions "Create Files/Write Data" and "Create Folders/Append Data" in order to view, download and upload your files. If you plan to use an application like Word to edit your docs you need additionally permissions like the "Write Attributes" and the "Write Extended Attributes".
    Moving forward and leaving behind the NTFS permissions we need to configure the authentication methods on the Virtual Directory.
    Right-click SharedDoc virtual directory and select "Properties". See Figure28.

    Figure28: Accessing SharedDoc Properties
    Figure29 shows the "SharedDoc Properties" window.

    Figure29: ShareDoc Properties
    Click on the "Directory Security" tab. Click on the "Edit" button within "Authentication and access control". See Figure30.

    Figure30: ShareDoc Properties
    The "Authentication Methods" window opens. See Figure31.

    Figure31: The Authentication Methods
    Anonymous access is disabled. I have selected "Integrated Windows authentication" and "Basic authentication". It's all about how you instruct ISA to delegate credentials. Both NTLM and Basic seem to work.
    Click "OK" to save changes.
    Next we need to obtain a SSL certificate for our web site.
    Since the WebDav server is a domain member I can directly request a web site certificate from the Enterprise CA located on ISA's Internal Network. Since I traverse ISA for this operation, my request will fail. You can find out more about that reading the following Microsoft doc: "The certificate request failed because of one of the following conditions" error message when you request a certificate in ISA Server 2004
    To request a web site certificate you need to open the web site properties(not the Virtual Directory Properties) and click the "Directory Security". See Figure32.

    Figure32: Web Site Properties
    Click the "Server Certificate". The "Web Server Certificate Wizard" will pop-up.
    Click "Next" and select "Create a new certificate". See Figure33.

    Figure33: Create a new certificate
    Click "Next".
    Select "Send the request immediately to an online certification authority". See Figure34.

    Figure34: Send the request immediately to an online certification authority
    Click "Next".
    Enter a name for you certificate(do not confuse this with the Common Name) and select key length. See Figure35.

    Figure35: A name for the new certificate
    Click "Next" and enter your organization name and organizational name.
    Click "Next".
    Now you need to enter the Common Name for your web site. This name will be used by ISA to connect to the WebDav server. See Figure36.

    Figure36: Common Name
    Click "Next".
    Enter the geographical information.
    Click "Next".
    Leave the default SSL port(if you do not have other plans).
    Click "Next".
    Select the CA to process your request. See Figure37.

    Figure37: Select the CA
    Click "Next" and submit your request.
    By now you should have a certificate installed on your web server.
    Go to the your Virtual Directory properties, the "Directory Security" tab and click "View Certificate". See Figure38.

    Figure38: View Certificate
    Figure39 shows the web site certificate.

    Figure39: The Certificate
    While are in your Virtual Directory properties, the "Directory Security" tab, click the "Edit" button from "Secure Communication" area. See Figure40.

    Figure40: Edit
    Put a checkmark into the "Require secure channel (SSL)". See Figure41.

    Figure41: Require SSL
    As you probaly noticed, we did not enabled "Require secure channel (SSL)" at the web site level, only on the Virtual Directory.
    Click "OK" to save the changes.
    We need one more touch and we are done with the IIS server.
    Open the web site properties(not the Virtual Directory Properties) and click the "Directory Security". Open again the "Web Server Certificate Wizard" by clicking the "Server Certificate".
    Click "Next" at the welcome screen.
    Select "Export the current certificate to a .pfx file". See Figure42. We need to export the web site certificate along with its private key because we must import it on ISA in order to enable SSL bridging on ISA.

    Figure42: Export the current certificate to a .pfx file
    Click "Next" and select a filename and location where to save the certificate.
    Click "Next" and enter a password for your certificate.
    Click "Next" and again"Next" and "Finish".
    Now you need to copy the .pfx file on the ISA Firewall machine.





  3. #3
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.carbonwind.net/ISA/WebDav/WebDav3.htm
    Part 3 - Configure ISA 2006 Firewall

    Time to configure the ISA 2006 Firewall.
    The first thing to do is to import the web site certificate on ISA into the "Computer Store".
    Click "Start", "Run" and type "mmc". See Figure43.

    Figure43: Run: mmc
    From "File" select "Add/Remove Snap-in".
    Click the "Add" button on the "Add/Remove Snap-in" window.
    From the "Add Standalone Snap-in", select "Certificates" and hit the "Add" button.
    Choose "Computer Account" on the "Certificates Snap-in". Click "Next" .
    Select "Local Computer: (the computer this console is running on)".
    Click "Finish".
    From the console expand "Certificates (Local Computer)", the "Personal" store, right-click "Certificates", point to "All Tasks" and click on "Import". See Figure44.

    Figure44: Import Certificate
    The "Certificate Import Wizard" will start. Click "Next".
    Locate the web site .pxf file.
    Click "Next". Provide the certificate password. You do not need to select the "Mark this key as exportable".
    Click "Next".
    Choose "Place all certificates in the following store".
    Click "Next" and "Finish".
    Now the web site certificate should appear in the "Local Computer" store. Since ISA is a domain member and we are using an Enterprise CA, we do not need to place the CA certificate into the "Trusted Root Certification Authorities" store("Local Computer" store). So the certificate will not show any red X. See Figure45.

    Figure45: Local Computer Store
    Next we need to create the Web Publishing Rule.
    Using the ISA console head to the "Firewall Policy". From the "Task" panel click "Publish Web Sites". See Figure46.

    Figure46: Publish Web Site
    Enter a name for this rule. I'm going to call it "WebDav". See Figure47.

    Figure47: Web Publishing Rule Name

    Click "Next".
    Select "Allow" for the "Action to take when rule conditions are met:". See Figure48.

    Figure48: Web Publishing Rule Condition

    Click "Next".
    Select "Publish a single Web site or load balancer". See Figure49.

    Figure49: Publishing Type

    Click "Next".
    Select "Use SSL to connect to the published Web server or server farm". See Figure50.

    Figure50: Server Connection Security

    Click "Next".
    You need to enter the "Internal site name". Be very careful here since this is a critical setting. The name you enter *must* match the Common Name from the web site certificate. The Common Name from the web site certificate is fileserver.carbonwind.net. Also you can specify the IP address of the WebDav server because fileserver.carbonwind.net might not be resolved as 192.168.30.10. See Figure51.

    Figure51: Internal Publishing Details

    Click "Next".
    You can specify the path. In our case the path is https://fileserver.carbonwind.net/shareddoc/*. We need the * because we will access the subfolders too. See Figure52.

    Figure52: Specify the path

    Click "Next".
    Enter the "Public Name". This will be th name users will use to connect to the WebDav server. This name must match the Common Name from the certificate installed on ISA. In our case the Common Name from certificate imported on ISA is fileserver.carbonwind.net. Also enter the path. See Figure53.

    Figure53: Public Name Details

    Click "Next".
    We need to define a new web listener. So click the "New" button on the "Select Web Listener Page".
    Enter a name for this listener. I've called it WebDav Listener. See Figure54.

    Figure54: Public Name Details

    Click "Next".
    Choose "Require SSL secured connections with clients". See Figure55.

    Figure55: Client Connection Security

    Click "Next".
    ISA will listen for connections coming from the External Network so put a checkmark for it. I have two IP addresses on ISA's External Interface, 192.168.22.234 was used to publish OWA and Outlook Anywhere, thus 192.168.22.237 will be used to publish the WebDav server. See Figure56.

    Figure56: Client Connection Security

    Click "Next".
    Specify a certificate for this Web Listener. I have used "Use a single certificate for this listener" (I have only one IP address and one certificate on this listener). See Figure57.

    Figure57: Listener SSL Certificate

    And select the fileserver.carbonwind.net certificate. See Figure58.

    Figure58: Select The Certificate

    Click "Next".
    ISA will pre-authenicate the clients using "HTTP Authentication" and "Basic Authentication". ISA will validate credentials using "Windows (Active Directory)". See Figure59.

    Figure59: Authentication Settings

    Click "Next".
    Click "Next" on the "Single Sign On Settings". See Figure60.

    Figure60: Single Sign On Settings

    Click "Next".
    Review your settings and click "Finish" on the "Completing the New Web Listener Wizard" window. See Figure61

    Figure61: Completing the New Web Listener Wizard

    Back to the "Select Web Listener" the newly created WebDav Listener is selected. See Figure62

    Figure62: Select The Web Listener

    Click "Next".
    We need to specify how ISA will delegate credentials to the WebDav server. I have selected NTLM as it appears to work just fine(if not you can try Basic). The WebDav server was configured accordingly(go back to Part 2 for more details). See Figure63.

    Figure63: Authentication Delegation

    Click "Next".
    I have removed "All Authenticated Users" from the "User Sets" window. I have added instead the "WebDav Users" User Sets. See Figure64. The "WebDav Users" User Sets corresponds to the "WebDav Users" Domain Group. See Figure65.

    Figure64: User Sets


    Figure65: WebDav User Sets

    Click "Next".
    Review your settings and click "Finish" to complete the " New Web Publishing Rule Wizard". See Figure66.

    Figure66: WebDav User Sets

    Apply the new configuration.
    Figure67 shows the newly created Web Publishing Rule.

    Figure67: WebDav User Sets
    Time to see if it works.





  4. #4
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.carbonwind.net/ISA/WebDav/WebDav4.htm
    Part 4 - Analyzing Various WebDav Clients
    - 1. Windows Built-in WebDav Client
    - 2. WebDrive
    - 3. Total Commander
    - 4. CentOS 4.4 with the Already Installed Neon WebDav Client



    1. Windows Built-in WebDav Client
    First test with a browser, say Internet Explorer(this will tell us if the web site was published correctly). You should be prompted only once for credentials(since we are using delegation of credentials on ISA). See Figure68.

    Figure68: IE 7.0
    I can use other browsers(Firefox, Opera) with no problems too.
    Close IE and open it again. This time chose File/Open. See Figure69.

    Figure69: File/Open
    Enter your server address and select "Open as Web Folder". See Figure70.

    Figure70: Open as Web Folder
    Enter your credentials. See Figure71.

    Figure71: Credentials
    Probably you will be prompted again for these credentials. The second prompt is required also when ISA is not between the client and the WebDav server(the client is directly connected to the WebDav server). This second prompt appears when SSL is required on the WebDav server. So it looks like the built-in Windows WebDav client has some issues with WebDav over SSL.
    And you will have access to the Web Folder. See Figure72.

    Figure72: Web Folder
    Talking about the Windows build-in WebDav clients, dear Microsoft what have you done ?
    The Windows XP WebDav client comes with bugs but at least works in this scenario.
    You may encounter the following:
    - when you use IE and "Open as Web Folder" instead of viewing the Web Folder, a "My Computer" window appears (how about that ?). However you can locate it within "My Network Places". This can happen if you follow the method described here and run "webfldrs.msi". This method could save you from the error shown in Figure73. However instead of using Notepad, IE will be used to open the .txt file.
    - when you attempt to directly open a .txt file you get the following error, See Figure73. This error appears if the client is directly connect to the WebDav server(no ISA between them). Also if SSL is not required on the WebDav server, the .txt file opens correctly. Again, it looks like the built-in Windows WebDav client has certain issues with WebDav over SSL. Not even the "infamous" KB907306 can fix this problem.

    Figure73: Notepad Error
    - the URLs might be converted to UNC paths
    However the Windows XP client seems to not have any major problems connecting through ISA, the download, the upload, the sent to, the delete, the rename or the open of Office docs operations work just fine. Note that during this article some Windows XP SP2 systems did not have Microsoft Office installed, while others Windows XP SP2 machines had installed Microsoft Office 2007.
    But, wait!
    The Windows XP WebDav client(Web Foders) is yet to accept defeat. It supports user certificate authentication(so we can use on ISA SSL Client Certificate Authentication with KCD(Kerberos Constrained Delegation)). But if you have followed the method described here and run "webfldrs.msi", it seems that it will not work anymore with user certificate authentication. .
    Vista on the other side is unable to connect (the Vista machine did not have Microsoft Office installed). When I use IE and "Open as Web Folder" I get the error from Figure74.

    Figure74: Vista IE Error
    When I use "Map Network Drive" I get the error from Figure75.

    Figure75: Vista Error

    So what's happening ?
    First let's see what are saying ISA's logs, see Figure76.

    Figure76: Vista ISA Log

    As can be seen Vista keeps sending the OPTIONS request and ISA denies it. Apparently if the OPTIONS request does not succeed (saying that the server can use WebDAV), the WebDAV Redirector will not be able to connect. At least according to this post (the entire thread can be viewed here). Vista appears to have a problem with Basic authentication (does not send the Authorization header).
    ISA denies the OPTIONS request and requires authentication. If authentication succeeds the OPTIONS request will be send to the WebDav server along with the authorization header. See Figure77 (taken from a Windows XP SP2 WebDav session). Actually there are some differences between Figure76 and Figure77.

    Figure77: OPTIONS Method ISA Log

    Please refer to our explanation for further details.
    I could not get Vista's default WebDav client(Web Redirector) working through ISA. It's such a shame Microsoft did not include a proper WebDav client into the shiny Vista OS.
    Need a quick fix for Vista ?
    Then use WebDrive or Total Commander.
    Regarding the use of Microsoft Office Applications, for example with Microsoft Word, when a file is opened from the Web Folders, it is automatically locked. When the file is closed, the file is unlocked. The entire process is transparent for the end-users. The locking of the document is very useful since the user can edit the document while other users can only read it, thus preventing simultaneous editing(overwrite prevention).
    Figure78 and Figure79 shows ISA's logs for locking and unlocking a Microsoft Word document.

    Figure78: LOCK Method ISA Log


    Figure79: UNLOCK Method ISA Log

    In Figure80 you can see ISA's log for the HEAD method used by the Office Application.

    Figure80: HEAD Method ISA Log

    2. WebDrive
    Now, about WebDrive. It is very easy to connect to the WebDav server through ISA with WebDrive. Just define a new site. See Figure81.

    Figure81: Web Drive WebDav SSL

    Hit the Connect button and a new drive will be mounted. See Figure82.

    Figure82: WebDrive Drive

    The corresponding ISA logs are shown in Figure83 and Figure84.

    Figure83: ISA Log WebDrive WebDav SSL Authentication Required


    Figure84: ISA Log WebDrive WebDav SSL
    OPTIONS Request with the Authorization Header
    In Figure85 you can see the uploading of a file using WebDrive.

    Figure85: WebDrive Upload
    In Figure86 you can see that the upload was complete.

    Figure86: WebDrive Upload Complete
    No major problems.
    WebDrive can automatically lock documents when you open them. Or you can manually lock them. See Figure87 and Figure88. However I've noted that both techniques are not so reliable when you attempt to save the changes you've made(you may not be able to do so).

    Figure87: WebDrive Auto Lock


    Figure88: WebDrive Manual Lock

    3. Total Commander
    Other Windows WebDav client might be Total Commander, a popular file manager. Total Commander by itself does not support WebDav. But there is a WebDav plugin available for it. WebDav 1.6 was used within this article. Once installed, this WebDav plugin can be accessed through My Network Places. See Figure89.

    Figure89: Total Commander with the WebDav Plugin

    When you have entered the WebDav directory, hit F7 to create a new connection. I found that using the "Quick Connection" option is tricky, sometimes the connections succeed, sometimes not. No such problems using F7 and defining a new connection. See Figure90.

    Figure90: Total Commander with the WebDav Plugin Options

    Enter a name for the new connection. See Figure91.

    Figure91: Total Commander New WebDav Connection
    Set the settings for the WebDAv connection, enter the server/path (in this case the path is fileserver.carbonwind.net/shareddoc), check "Secure server (via SSL)" and aditionally you can check the other two fields from Figure92 (for the upload method).

    Figure92: Total Commander WebDav SSL Settings

    After the new connection is created, double-click it in order to connect. Figure93 shows the successful connection.

    Figure93: Total Commander WebDav SSL Connected

    In Figure94 you can see the uploading of a file using Total Commander.

    Figure94: Total Commander SSL Upload

    And ISA's logs showing the Total Commander WebDav over TLS session. See Figure95 and Figure96.

    Figure95: ISA Log Total Commander WebDav SSL Authentication Required


    Figure96: ISA Log Total Commander WebDav SSL PROPFIND Method with the Authentication Header

    Figure97 shows the successful PUT command required for the uploading described in Figure94.

    Figure97: ISA Log Total Commander WebDav PUT Method with the Authentication Header
    SSL
    4. CentOS 4.4 with the Already Installed Neon WebDav Client
    Moving away from the Windows OS, CentOS 4.4(with the already installed Neon WebDav client) was successfully used to connect to the WebDav server behind ISA.
    It's more than easy to define a WebDav connection from CentOS. From Computer, select "File/Connect to Server". Choose "Secure WebDAV (HTTPS)", enter the server name, the Folder (shareddoc) and the user name. See Figure98.

    Figure98: CentOS WebDavs

    Hit Connect. When prompted enter your password and you can select "Remember password for this session". See Figure99.

    Figure99: CentOS WebDavs Password

    And we are connected. Notice that the WebDav connection appears also as a separate drive. See Figure100.

    Figure100: CentOS WebDavs Connected

    And ISA's logs showing the CentOS TLS WebDav session. See Figure101 and Figure102.

    Figure101: ISA Log CentOS WebDavs Authetication Required


    Figure102: ISA Log CentOS WebDavs
    PROPFIND Method with the Authentication Header
    So plenty of WebDav clients(except the one from Vista) working just fine when the WebDav server is published behind ISA.





  5. #5
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.carbonwind.net/ISA/WebDav/WebDav5.htm
    Part 5 - Configure HTTP Filtering in ISA 2006 Firewall

    ISA 2006 Firewall can provide granular control over HTTP traffic through the HTTP filter, an application-layer filter that examines HTTP commands and data.
    The HTTP filter screens all HTTP traffic that passes through the ISA Server computer, and only allows compliant requests to pass through. This significantly improves the security of your Web servers, by helping ensure that they only respond to valid requests.
    Let's take a quick look at it regarding the scenario from this article.
    You can find out more about HTTP filtering in ISA by reading the following Microsoft docs:
    - HTTP Filtering in ISA Server 2004
    - Typical HTTP Policies for Web and Outlook Web Access Publishing Rules
    - HTTP Policy Walk-through Procedure 2: Configure HTTP Policy
    And from this article written by Marc Grote: Configuring the ISA Server 2006 HTTP Filter
    You can configure the HTTP filter by right-click on the WebDav Web Publishing rule and "Configure HTTP". See Figure103.

    Figure103: Configure HTTP

    And you can start configuring the HTTP policy for this rule. See Figure104, General tab.

    Figure104: HTTP Filter General tab

    The "Verify Normalization" or "Block high bit characters" features did not block access to my WebDav server using the various WebDav clients presented in this article. However "Block high bit characters" might interfere if you are using a language containing high-bit characters. "Verify Normalization" blocks requests with URLs containing escaped characters after normalization.
    Note that the "Maximum headers length" setting on the General tab of the Configure HTTP policy for rule dialog box is applied to all rules globally, so if you change it here it will apply to all rules.
    You can also type the maximum URL length allowed. You enter that value in bytes. Requests with URLs exceeding this value will be blocked. See Figure105.

    Figure105: HTTP Filter General

    For example I have considered that a maximum URL length of 120 bytes is enough for the WebDav web publishing rule used within this article (obvioulsy I've double-checked that). See Figure106.

    Figure106: Maximum URL Length

    Also you can check "Block responses containing Windows executable content" which allows you to prevent users from downloading files that are Windows executable. The HTTP filter knows if the file is a Windows executable because the response will begin with " MZ".
    Click the "Methods" tab. See Figure107.

    Figure107: Configure HTTP Methods Tab

    Here you have the choice of blocking some Methods or allow only some Methods. This is very useful for our webDav server.
    First let's talk about some of the methods that might be used within the scenario of this article(see RFC2068, RFC2518 and RFC4918 for more details).
    - OPTIONS Method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server. See Figure108.

    Figure108: OPTIONS Method ISA Log

    - PROPFIND Method retrieves properties defined on the resource identified by the Request URI or on the resource identified by the Request URI and potentially its member resources, if the resource is a collection that has internal member URLs. The PROPFIND Method can be used on collection and property resources. The PROPFIND method can be used to list all the files in the DAV-enabled directory. WebDAV clients retrieve properties of documents using the PROPFIND method. See Figure109.

    Figure109: PROPFIND Method ISA Log

    - PROPPATCH Method processes instructions specified in the request body to set and/or remove properties defined on the resource identified by the Request-URI. WebDAV clients assign properties to documents using the PROPPATCH method. Can be used to set properties for the resource at the specified destination URI. Figure110 shows the ISA Log for the operation of creating a new .txt file on the WebDav server using WebDrive.

    Figure110: PROPPATCH Method ISA Log

    - GET Method means retrieve whatever information. It specifies that a resource is being retrieved from the server. From an end-user point of view this might be associated with the download process. See Figure111.

    Figure111: GET Method ISA Log

    - HEAD Method is used to ask for information about a document. Is identical to GET except that the server MUST NOT return a message-body in the response. HEAD is much faster than GET, as a much smaller amount of data is transferred. It's often used by clients who use caching, to see if the document has changed since it was last accessed. If it was not, the local copy can be reused, otherwise the updated version must be retrieved with a GET. As said before, this method is often used for testing hypertext links for validity, accessibility, and recent modification. See Figure112.

    Figure112: HEAD Method ISA Log

    - PUT Method requests that the enclosed entity be stored under the supplied Request URI. If the Request URI refers to an already existing resource, the enclosed entity should be considered as a modified version of the one residing on the origin server. If the Request URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. From an end-user point of view is tipically associated with the upload process(uploading a new file or updating an old one). See Figure113.

    Figure113: PUT Method ISA Log

    - DELETE Method requests that the origin server deletes the resource identified by the Request URI. From an end-user point of view is tipically associated with the delete process(the user deletes a file or a directory on the remote server). See Figure114.

    Figure114: DELETE Method ISA Log

    - MOVE Method applied on a non-collection resource is the logical equivalent of a copy (COPY Method), followed by consistency maintenance processing, followed by a delete of the source, where all three actions are performed atomically. From an end-user point of view can be associated with the rename process(the user renames a file or directory on the remote server). See Figure115.

    Figure115: MOVE Method ISA Log

    - COPY Method creates a duplicate of the source resource, identified by the Request-URI, in the destination resource, identified by the URI in the Destination header. The Destination header must be present. The exact behavior of the COPY method depends on the type of the source resource. From an end-user point of view it can be associated with the action of Copy and Paste of a file for example, directly on the remote directory thus creating a duplicate of that file. See Figure116 and Figure117.

    Figure116: COPY Method ISA Log


    Figure117: Duplicate File

    - LOCK Method is used to put a lock on a resource. Locks a document(example Word doc) so other users can't edit it. This assures overwrite prevention. One user edits the document while the rest of the users can read it. See Figure118.

    Figure118: LOCK Method ISA Log

    - UNLOCK Method is used to remove a lock from a resource. Unlocks the document previously locked. Typically this happens when the user closes the document(example Word doc). See Figure119.

    Figure119: UNLOCK Method ISA Log

    - MKCOL Method creates a new collection at the location specified by the Request URI. It can be used for creating new folders for example on the remote WebDav server. See Figure120.

    Figure120: MKCOL Method ISA Log

    If you want your users to be able to do all the things described by the above methods then you should configure them as allowed methods on ISA. See Figure121.

    Figure121: Allowed Methods

    Click the Extensions tab. See Figure122.

    Figure122: The Extensions Tab Blocked Extensions

    Here you have the choice of blocking file extensions or allowing only needed extensions. I have quickly configured a few blocked extensions. This may vary depending on what you plan to allow/block to be uploaded or downloaded from your server.
    Also you can select "Block requests containing ambiguous extensions", thus requests whose file extension cannot be determined will be blocked.
    It will be more secure for your WebDav server to allow only needed extensions(depending on what types of files you store on the WebDav server). See Figure123.

    Figure123: The Extensions Tab Allow Only Specified Extensions

    Please note that if you change the extensions of a file from .jpg to .zip ISA will not block the upload of this "new" file, only the extension matters, ISA does not verify the file. Also the "." extension is needed otherwise you will not be able to connect(for example a request for https://fileserver.carbonwind.net/shareddoc will be denied). See Figure124.

    Figure124: ISA Log Extension Not Specifically Allowed

    Click the Headers tab. See Figure125.

    Figure125: The Headers Tab

    You can block certain headers(response, request). You can also specify how the server header will be returned in the response.
    I've made no changes to this tab.
    Click on the signatures tab. See Figure126.

    Figure126: The Signatures Tab

    Here you can specify whether requests or responses will be blocked based on the presence of specific signatures in the headers or body or Request URL.
    I have entered a quick list of signatures for the Request URL. If any of these strings will be found in the Request URL, the request will be blocked.
    As can be seen, using the HTTP filter you can go a long way in protecting your WebDav server.
    For example imagine that you want to allow two types of access: for power users(like above allow these users to read, delete, rename or edit files) and for normal users(they are only allowed to read and download files). Even more, you want the normal users to have access only to the a specific directory on the WebDav server (like a folder with public docs).
    ISA 2006 Firewall enables you to control all these at the firewall level. Therefore the unwanted normal users requests will never reach the WebDav server behind ISA.
    Right-click the WebDav publishing rule and click Copy. See Figure127.

    Figure127: Copy Rule
    Then one more time right-click that rule and click Paste. See Figure128.

    Figure128: Paste Rule
    And a new Web Publishing rule named WebDav(1) appears. See Figure129.

    Figure129: New Web Publishing Rule
    Do not commit yet your changes.
    Right-click it and click Properties. Click the Paths tab. And edit the path to be "/shareddoc/PublicDoc/*" instead of "/shareddoc/*". See Figure130.

    Figure130: WebDav(1) Path

    Next click the Users tab and remove the "WebDav Users" group and add the new users group. I've called this group "WebDav2" Users which corresponds to the "WebDav2" Windows Group. See Figure131.

    Figure131: WebDav2 Users

    Click OK to close WebDav(1) properties.
    Then right-click the WebDav(1) rule and click Configure HTTP Filter. See Figure132.

    Figure132: WebDav(1) Configure HTTP
    Click the Methods tab. Allow only "OPTIONS", "PROPFIND", "GET" and "HEAD" (remove the rest). See Figure133.

    Figure133: WebDav(1) Methods Tab

    Doing so "WebDav2 Users" will only be able to read, list, browse and download files.
    Click "OK" and apply the new settings.
    And the normal users are able to connect to the PublicDoc directory. See Figure134.

    Figure134: PublicDoc WebDav(1)

    ISA allows the PROPFIND method for the WebDav2 user. See Figure135.

    Figure135: ISA Log PROPFIND WebDav(1)

    A WebDav2 user attempts to download a file. The request is allowed by ISA. See Figure136.

    Figure136: ISA Log GET WebDav(1)

    If the WebDav2 user wants to upload a file, ISA denies him. See Figure137.

    Figure137: ISA Log PUT WebDav(1)

    Also if WebDav2 user attempts to enter the SharedDoc directory ISA denies him. See Figure138.

    Figure138: ISA Log Denied Action

    So the two rules are doing their job. See Figure139.

    Figure139: The Two Rules in Action

    As we have seen throughout this series, the described method gives us a very nice FTPS like solution while we are able take advantage of ISA's powerful features.





  6. #6
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.carbonwind.net/ISA/WebDav/WebDav6.htm
    Part 6 - User Certificate Authentication on ISA 2006 Firewall

    Regarding the use of a user certificate as a strong authentication method(high security), we need a WebDav client supporting such an authentication method. And that might be a problem.
    I had modified the WebDav rule (Web Listener Properties) to use "SSL Client Certificate Authentication". See Figure140.

    Figure140: SSL Client Certificate Authentication

    In the "Advanced Authentication Options" I have specified the CA from which ISA trusts user certificates. See Figure141.

    Figure141: Specify the CA From Which ISA Accepts User Certificates

    Next we need a delegation method or allow the client to authenticate directly(not desired). Therefore as the delegation method, I have selected KCD(Kerberos Constrained Delegation). See Figure142. Without KCD, ISA Server can delegate credentials only when client credentials are received using Basic authentication or HTTP forms-based authentication. So KCD is a powerful feature of ISA 2006.

    Figure142: Kerberos Constrained Delegation

    The SPN (Service Principal Name) is not http/fileserver.carbonwind.net, is the host name on which IIS is installed(I do not have a host header on the web site), IIS runs under the Network Service account. Therefore the SPN is http/webdavdmz.carbonwind.net.
    After ISA verifies the user's identity(through the SSL user certificate), ISA will obtain a Kerberos service ticket for authenticating the user to the WebDav server. When SSL user certificate is used for authentication, ISA cannot delegate the user's credentials to the WebDav server, because the client does not send to ISA a password that can be passed to the WebDav server. Also the SSL user certificate cannot be forwarded to the WebDav server because only the user has access to the private key corresponding to the public key present on the user certificate. ISA knows the user name from the user's certificate(SSL user certificates are mapped to Active Directory user accounts).
    Thus, at the domain controller, within "Active Directory Users and Computers" we need to configure the webdavdmz server to trust the Kerberos ticket obtained on the behalf of the user by ISA (actually this is done on the ISAMAIN computer and not on the WEBDAVDMZ computer). See Figure143.

    Figure143: ISA Computer Delegation Tab

    Note that the Computer name from Figure143 matches the one from the SPN entered on ISA. Please refer to the following Microsoft doc regarding KCD in ISA: Kerberos Constrained Delegation in ISA Server 2006.
    Using Internet Explorer, Firefox or Opera I can access the WebDav server with no problems (browse, download). See Figure144, Figure145 and Figure146.

    Figure144: Internet Explorer


    Figure145: Firefox


    Figure146: Opera

    Using the WebDav Windows XP built-in client also works(default install, with or without MS Office 2007 installed). Well, well, well. For sure it strikes back. When you are adding a Network Place you are prompted for a user certificate. See Figure147.

    Figure147: Adding a Network Place

    When you open the newly added Network Place you are prompted for a user certificate. See Figure148.

    Figure148: Open the Newly Added Network Place

    And success, see Figure149. No more worries about passwords strength. A powerful authentication method, requiring minimum effort from users(no more complaints about password complexity). The users only need to present a valid user certificate to ISA from the trusted CA.

    Figure149: Web Folders

    And the corresponding ISA logs. See Figure150, Figure151, Figure152 and Figure153.

    Figure150: ISA Log PROPFIND Request User Certificate Authentication + KCD


    Figure151: ISA Log PUT Request User Certificate Authentication + KCD


    Figure152: ISA Log GET Request User Certificate Authentication + KCD


    Figure153: ISA Log MOVE Request User Certificate Authentication + KCD

    If you attempt to open a Word doc for example from Web Folders, you will be prompted for the user certificate. See Figure154.

    Figure154: Word Doc User Certificate Authentication + KCD

    And some ISA logs for that attempt, see Figure155 and Figure156.

    Figure155: ISA Log LOCK Request User Certificate Authentication + KCD


    Figure156: ISA Log HEAD Request User Certificate Authentication + KCD

    WebDrive let us use client certificates. It has a certificate manager, so we can import certificates. See Figure157.

    Figure157: WebDrive Certificate Manager

    And then specify within the Properties of the Site the client certificate to be used. See Figure158.

    Figure158: WebDrive Client Certificate

    However WebDrive is unable to connect. Wireshark traces and ISA's logs show that the SSL authentication succeeds but WebDrive fails with some cryptic error(see bellow).
    "Connecting securely to https://fileserver.carbonwind.net/shareddoc:443 ...
    Connecting to port 443
    Encryption handshake successful
    OPTIONS /shareddoc HTTP/1.1
    req: Host: fileserver.carbonwind.net:443
    User-Agent: WebDrive 7.34.1801 DAV
    req: Translate: f
    req: Content-Length: 0
    req: Connection: Keep-Alive
    ReceiveLine: encrypted read error=recv() failed in crypto layer (Error 1506)
    HTTP Connection closing
    Retrying HTTP command
    Connecting to port 443
    Encryption handshake successful
    OPTIONS /shareddoc HTTP/1.1
    req: Host: fileserver.carbonwind.net:443
    req: User-Agent: WebDrive 7.34.1801 DAV
    req: Translate: f
    req: Content-Length: 0
    req: Connection: Keep-Alive
    ReceiveLine: encrypted read error=recv() failed in crypto layer (Error 1506)
    HTTP Connection closing
    Request failed: -1
    Failed to connect to Site Test at https://fileserver.carbonwind.net/shareddoc, error=Request failed: -1 , LogonFailure=0
    "
    And the corresponding ISA logs, see Figure159. ISA logs a sucessful attempt(200 OK), the same sucessful attempt can be seen in IIS logs.

    Figure159: ISA Log WebDrive User Certificate Authentication + KCD

    I did not notice an option on Total Commander WebDav plugin or on CentOS 4.4(although Neon seems to support client certificates) to specify a client certificate.
    As can be seen, with the proper WebDav client this is the way to go in implementing a strong authentication method. At the end of the day, it's not an ISA problem, only a WebDav client one




  7. #7
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.carbonwind.net/ISA/WebDav/WebDav7.htm
    Part 7 - An Explanation of WebDav Through ISA 2006 Firewall

    So what's happening on the wire when we use WebDav over TLS through ISA?
    I'm a liar, Wireshark can do that when RSA key exchange is used and we have the server's private key.
    How can we see what we can't see?
    Yep, time to bring the big guns.
    Instead of using the crappy Windows WebDav client we are going to use WebDrive.
    And Burp Proxy to sniff SSL traffic(MITM). Burp proxy can be such a very useful tool in troubleshooting scenarios involving HTTPS.
    We start hitting the ""Connect" button from WebDrive.
    Figure160 shows the ISA log for the first attempt from WebDrive. Business like usual. The OPTIONS request. Which is denied because ISA requires authorization.

    Figure160: ISA Log: ISA Denies the OPTIONS Request

    What Burp Proxy shows, see Figure161.

    Figure161: Burp Proxy OPTIONS request No Authentication

    Nothing fancy.
    And ISA's response to this. As can be seen from Figure162, ISA returns HTTP 401 Status Code informing WebDrive that it requires authentication, Basic authentication.

    Figure162: Burp Proxy ISA's Response

    And WebDrive understands that and replies accordingly. Figure163 shows the ISA log for the OPTIONS request from WebDrive. As you can see, this time it includes the authorization header, therefore is allowed to pass(WebDrive does its magic). Without attaching the authorization header to the OPTIONS request ISA will deny the packet.

    Figure163: ISA Log OPTIONS Allowed

    Burp Proxy shows us the respective packet sent by WebDrive, see Figure164.

    Figure164: Burp Proxy New OPTIONS Request

    ISA forwards this packet to the WebDav server which will respond. See Figure165. And yes, the IIS server knows about WebDav.

    Figure165: Burp Proxy IIS Response

    Next WebDrive issues a PROPFIND request along with the authorization header and traffic continues normally.
    Note that the "TRACE" method is actually disabled on the IIS server(although in Figure165 the IIS server returns it). Please read the following Microsoft doc: WWW Service Registry Entries (IIS 6.0).
    Some Security Audit reports will alert you about this, but they do *not* care about what happens when you really issue the TRACE request to the IIS server(they only acknowledge that this method was returned by the IIS server). You can use telnet and issue a TRACE request directly on your web server(not working for websites requiring SSL, you need another "telnet" client capable of using SSL):
    telnet 127.0.0.1 80
    And type something like:
    TRACE / HTTP/1.1
    Host: etregwrk
    Q: heqorgvrev

    If TRACE is allowed, a HTTP/1.1 200 OK message is return. See Figure166.

    Figure166: HTTP/1.1 200 OK
    If not you will get the HTTP/1.1 501 Not Implemented message. See Figure167.

    Figure167: HTTP/1.1 501 Not Implemented
    We can run this test with the help of Burp Proxy by modyfing on the fly a request from the WebDav client through ISA(maybe not the most fortunate test). However since the TRACE method is not allowed on ISA (the HTTP filter was configured to accept only valid methods), ISA will deny this packet. Thus a message using the TRACE method will never make it though ISA.
    The TRACE request(modified OPTIONS request on the fly). See Figure168.

    Figure168: Burp Proxy Modified Request TRACE

    The response to the TRACE request. See Figure169.

    Figure169: Burp Proxy TRACE Response

    And the corresponding ISA Log, see Figure170.

    Figure170: ISA Log Trace Method

    And what's happening on the wire when we use WebDav without TLS through ISA ?
    Note that it is not recommended to do so due to security issues, traffic being sent in clear along with the credentials. You definetely don't want to do that in a production environment.
    We can create a Web Publishing Rule on ISA in the same way we did for WebDav over TLS but this time without SSL, see Figure171 and Figure172.
    .
    Figure171: Non Secure Connection when Connecting to the Published Web Site

    Figure172: Non Secure Connection for Clients

    The authentication is the same, Basic on ISA and NTLM delegation. But "Allow Client Authentication Over HTTP" option is checked, see Figure173.

    Figure173: Allow Client Authentication Over HTTP

    If you attempt to open as Web Foder from a Windows XP SP2 machine you are caught in a loop where a window pops-up asking for credentials and nothing happens. Using a Web browser and viewing as a web page the WebDav site works fine. However you cannot open it as a WebFolder(either from IE or My Network Places).
    If you connect directly(remove ISA from the picture) is working just fine.
    So you might think ISA is doing something. See Figure174 and Figure175.

    Figure174: WebDav Redirector Through ISA No TLS


    Figure175: WebDav Redirector Through ISA No TLS

    Wrong, ISA is doing nothing!
    Is just the WebDav Redirector unable to handle the Basic authentication required by ISA.
    Remember that we have NTLM authentication also enabled on the Virtual Directory?
    Disabled Integrated Authentication(NTLM) and leave just Basic authentication on the Virtual Directory.
    Guess what ?
    If you connect directly it will not work anymore. The WebDav Redirector does not send the required authentication header.
    First let's analyze what's happening when the client connects directly(both NTLM are enabled on the IIS Virtual Directory). First issues a PROPFIND request, see Figure176. Watch for the "User-Agent".

    Figure176: WebDav Redirector XP no TLS Direct Connection

    Next the IIS server required authentication, either Basisc or NTLM, see Figure177.

    Figure177: IIS Authentication Required

    And finally the WebDav Redirector uses NTLM authentication, see Figure178.

    Figure178: NTLM Challenge

    If you go and disable NTLM authentication on the Virtual Directory, as said before you will not be able to connect.
    A solution to this will be to specify port 80 when we add a New Network Places. See Figure179.

    Figure179: Specify Port 80

    And we can connect. See Figure180.

    Figure180: Web Folder Ditect No TLS

    If you watch the Wireshark traces, something has changed, the "User-Agent". See Figure181.

    Figure181: WebDav Basic Authentication

    So it appears that the old WebDav Windows client(Web Folders) is brought into action.
    Also, by now you might get the error from Figure182 when you attempt to open a .txt file from the Web Folders.

    Figure182: Notepad Error
    Using the port trick let's try to connect through ISA this time without TLS(using the above mentioned Web Publishing Rule). And surprise, it works. See Figure183.

    Figure183: Web Folder Through ISA No TLS

    Looking at ISA's logs we can notice the old WebDav client (the "User-Agent"). See Figure184 and Figure185.

    Figure184: ISA Log WebDAV No TLS PROPFIND


    Figure185: ISA Log WebDAV No TLS OPTIONS

    What a mess!
    Vista seems to not include anymore the old WebDav client(Web Folders), only the Web Redirector which appears to have a problem with Basic authentication(does not send the Authorization header).
    If we connect directly with Vista(no ISA) and NTLM authentication is enabled on the Virtual Directory, Vista can connect. See Figure186.

    Figure186: Vista WebDav
    All these become history when proper WebDav clients like WebDrive or Neon(on CentOS) are used.
    With CentOS is quite simple to connect to a WebDav server(enter a simple user name, without the domain prefix). See Figure187.

    Figure187: CentOS WebDav

    Enter your password and check "Remember password for this session". See Figure188.

    Figure188: CentOS WebDav Password
    And we are connected. See Figure189.

    Figure189: CentOS WebDav Connected

    And ISA's logs showing the CentOS WebDav session. See Figure190 and Figure191.

    Figure190: ISA Log CentOS No TLS Requiring Authorization


    Figure191: ISA Log CentOS No TLS PROPFIND with the Authorization Header

    With WebDrive things are very simple also. Define a new site using WebDav and hit Connect. See Figure192.

    Figure192: WebDrive WebDav
    And we are connected. See Figure193.

    Figure193: WebDrive WebDav Connected

    The corresponding ISA logs are shown in Figure194 and Figure195.

    Figure194: ISA Log WebDrive WebDav No TLS Authentication Required


    Figure195: ISA Log WebDrive OPTIONS Request with the Authorization Header
    No TLS
    With Total Commander(WebDav plugin 1.6) no problems either. Hit F7 and define a new WebDav connection. See Figure196 for the settings of this connection.

    Figure196: Total Commander WebDav Settings

    And then double-click the newly created WebDav Connection to connect. See Figure197.

    Figure197: Total Commander WebDav Connected Through ISA

    The corresponding ISA logs are shown in Figure198 and Figure199.

    Figure198: ISA Log Total Commander WebDav No TLS Authorixation Required


    Figure199: ISA Log Total Commander WebDav No TLS PROPFIND Request with the Authorization Header

    So publishing a WebDav server through ISA(with our without TLS) does not represent a problem with the right WebClient.





کلمات کلیدی در جستجوها:

1

2

5

caldav iis4shareddoc is not accessiblecreator owner special permissions system foldertmg isa invalid credentials 401 publish IIS8firewall in a logical diagramnetwork diagram server farmhow ftp works diagramerror details: the authentication delegation method defined in the rule requires either that the web listener is configured to listen on the ssl port or that the option allow client authentication over http is selected.Action to take when rule conditions aressltls secure channel6map network drive error xp3filezilla ftp isa server integrated authenticationAudit Command Language Network Diagramftp ssl server cannot accept argument totalcmdU 120 connexion DMZ LANthe authentication delegation method defined in the rule requires either that the web listener is configured to listen on the ssl porterror recv() failed in crypto layer (1506) webdrivethe authentication delegation method defined in the rule requires

برچسب برای این موضوع

مجوز های ارسال و ویرایش

  • شما نمی توانید موضوع جدید ارسال کنید
  • شما نمی توانید به پست ها پاسخ دهید
  • شما نمی توانید فایل پیوست ضمیمه کنید
  • شما نمی توانید پست های خود را ویرایش کنید
  •