Sie sind auf Seite 1von 424

Pr

Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
.

1[dT2^Pc2TacXUXTS
?a^gh?a^UTbbX^]P[2^dabT

8]bcadRc^aCTgcQ^^Z

eTabX^]""

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Contact Information

Blue Coat Systems Inc.


420 North Mary Avenue
Sunnyvale, California 94085

North America (USA) Toll Free: +1.866.302.2628 (866.30.BCOAT)


North America Direct (USA): +1.408.220.2200
Asia Pacific Rim (Hong Kong): +852.2166.8121
Europe, Middle East, and Africa (United Kingdom): +44 (0) 1276 854 100
training@bluecoat.com

training.books@bluecoat.com
www.bluecoat.com

Copyright 1999-2006 Blue Coat Systems, Inc. All rights reserved worldwide. No part of this document may be
reproduced by any means nor modified, decompiled, disassembled, published or distributed, in whole or in part, or
translated to any electronic medium or other means without the written consent of Blue Coat Systems, Inc. All right, title
and interest in and to the Software and documentation are and shall remain the exclusive property of Blue Coat Systems,
Inc. and its licensors. Blue Coat SG, Blue Coat AV, Blue Coat RA, Blue Coat WebFilter, Blue Coat Director, Blue
Coat Reporter, ProxySG, ProxyAV, CacheOS, SGOS, Spyware Interceptor, Scope are trademarks of Blue
Coat Systems, Inc. and CacheFlow, Blue Coat, Accelerating The Internet, WinProxy, AccessNow, Ositis,
Powering Internet Management, and The Ultimate Internet Sharing Solution are registered trademarks of Blue Coat
Systems, Inc. All other trademarks contained in this document and in the Software are the property of their respective
owners.
BLUE COAT SYSTEMS, INC. DISCLAIMS ALL WARRANTIES, CONDITIONS OR OTHER TERMS, EXPRESS OR
IMPLIED, STATUTORY OR OTHERWISE, ON SOFTWARE AND DOCUMENTATION FURNISHED HEREUNDER
INCLUDING WITHOUT LIMITATION THE WARRANTIES OF DESIGN, MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL BLUE COAT SYSTEMS, INC., ITS
SUPPLIERS OR ITS LICENSORS BE LIABLE FOR ANY DAMAGES, WHETHER ARISING IN TORT, CONTRACT OR
ANY OTHER LEGAL THEORY EVEN IF BLUE COAT SYSTEMS, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.

ii Instructor Edition

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Third Party Copyright Notices

Blue Coat Systems, Inc. utilizes third party software from various sources. Portions of this software are copyrighted by their respective
owners as indicated in the copyright notices below.
The following lists the copyright notices for:
BPF

Copyright (c) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996

The Regents of the University of California. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that: (1) source code distributions
retain the above copyright notice and this paragraph in its entirety, (2) distributions including binary code include the above copyright notice
and this paragraph in its entirety in the documentation or other materials provided with the distribution, and (3) all advertising materials
mentioning features or use of this software display the following acknowledgement:
This product includes software developed by the University of California, Lawrence Berkeley Laboratory and its contributors.

Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software
without specific prior written permission. THIS SOFTWARE IS PROVIDED AS IS AND WITHOUT ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE.
DES

Software DES functions written 12 Dec 1986 by Phil Karn, KA9Q; large sections adapted from the 1977 public-domain program by Jim
Gillogly.
EXPAT

Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the
following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN
NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Finjan Software

Copyright (c) 2003 Finjan Software, Inc. All rights reserved.


Flowerfire

Copyright (c) 1996-2002 Greg Ferrar


ISODE

ISODE 8.0 NOTICE

Acquisition, use, and distribution of this module and related materials are subject to the restrictions of a license agreement. Consult the
Preface in the Users Manual for the full terms of this agreement.
4BSD/ISODE SMP NOTICE

Acquisition, use, and distribution of this module and related materials are subject to the restrictions given in the file SMP-READ-ME.
UNIX is a registered trademark in the US and other countries, licensed exclusively through X/Open Company Ltd.
MD5

RSA Data Security, Inc. MD5 Message-Digest Algorithm

Copyright (c) 1991-2, RSA Data Security, Inc. Created 1991. All rights reserved.

License to copy and use this software is granted provided that it is identified as the "RSA Data Security, Inc. MD5 Message-Digest
Algorithm" in all material mentioning or referencing this software or this function.

License is also granted to make and use derivative works provided that such works are identified as "derived from the RSA Data Security,
Inc. MD5 Message-Digest Algorithm" in all material mentioning or referencing the derived work.

RSA Data Security, Inc. makes no representations concerning either the merchantability of this software or the suitability of this software for
any particular purpose. It is provided "as is" without express or implied warranty of any kind.
THE BEER-WARE LICENSE" (Revision 42):

<phk@FreeBSD.org <mailto:phk@FreeBSD.org>> wrote this file. As long as you retain this notice you can do whatever you want with this
stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp
Microsoft Windows Media Streaming

Copyright (c) 2003 Microsoft Corporation. All rights reserved.


OpenLDAP

Copyright (c) 1999-2001 The OpenLDAP Foundation, Redwood City, California, USA. All Rights Reserved. Permission to copy and
distribute verbatim copies of this document is granted.
http://www.openldap.org/software/release/license.html

The OpenLDAP Public License Version 2.7, 7 September 2001

Redistribution and use of this software and associated documentation ("Software"), with or without modification, are permitted provided
that the following conditions are met:
1. Redistributions of source code must retain copyright statements and notices,

2. Redistributions in binary form must reproduce applicable copyright statements and notices, this list of conditions, and the following
disclaimer in the documentation and/or other materials provided with the distribution, and
3. Redistributions must contain a verbatim copy of this document.

Instructor Edition iii

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

The OpenLDAP Foundation may revise this license from time to time. Each revision is distinguished by a version number. You may use this
Software under terms of this license revision or under the terms of any subsequent revision of the license.

THIS SOFTWARE IS PROVIDED BY THE OPENLDAP FOUNDATION AND ITS CONTRIBUTORS AS IS AND ANY EXPRESSED OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OPENLDAP FOUNDATION, ITS CONTRIBUTORS, OR
THE AUTHOR(S) OR OWNER(S) OF THE SOFTWARE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The names of the authors and copyright holders must not be used in advertising or otherwise to promote the sale, use or other dealing in this
Software without specific, written prior permission. Title to copyright in this Software shall at all times remain with copyright holders.
OpenLDAP is a registered trademark of the OpenLDAP Foundation.
OpenSSH

Copyright (c) 1995 Tatu Ylonen <ylo@cs.hut.fi>, Espoo, Finland. All rights reserved
This file is part of the OpenSSH software.

The licences which components of this software fall under are as follows. First, we will summarize and say that all components are under a
BSD licence, or a licence more free than that.
OpenSSH contains no GPL code.

1) As far as I am concerned, the code I have written for this software can be used freely for any purpose. Any derived versions of this
software must be clearly marked as such, and if the derived work is incompatible with the protocol description in the RFC file, it must be
called by a name other than "ssh" or "Secure Shell".
[Tatu continues]

However, I am not implying to give any licenses to any patents or copyrights held by third parties, and the software includes parts that are
not under my direct control. As far as I know, all included source code is used in accordance with the relevant license agreements and can be
used freely for any purpose (the GNU license being the most restrictive); see below for details.
[However, none of that term is relevant at this point in time. All of these restrictively licenced software components which he talks about
have been removed from OpenSSH, i.e.,
- RSA is no longer included, found in the OpenSSL library
- IDEA is no longer included, its use is deprecated
- DES is now external, in the OpenSSL library

- GMP is no longer used, and instead we call BN code from OpenSSL


- Zlib is now external, in a library

- The make-ssh-known-hosts script is no longer included


- TSS has been removed

- MD5 is now external, in the OpenSSL library

- RC4 support has been replaced with ARC4 support from OpenSSL
- Blowfish is now external, in the OpenSSL library
[The licence continues]

Note that any information and cryptographic algorithms used in this software are publicly available on the Internet and at any major
bookstore, scientific library, and patent office worldwide. More information can be found e.g. at "http://www.cs.hut.fi/crypto".

The legal status of this program is some combination of all these permissions and restrictions. Use only at your own responsibility. You will
be responsible for any legal consequences yourself; I am not making any claims whether possessing or using this is legal or not in your
country, and I am not taking any responsibility on your behalf.
NO WARRANTY

BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT
PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. IN NO
EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER
PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY
TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR
LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
2) The 32-bit CRC compensation attack detector in deattack.c was contributed by CORE SDI S.A. under a BSD-style license.
Cryptographic attack detector for ssh - source code

Copyright (c) 1998 CORE SDI S.A., Buenos Aires, Argentina. All rights reserved. Redistribution and use in source and binary forms, with or
without modification, are permitted provided that this copyright notice is retained. THIS SOFTWARE IS PROVIDED AS IS AND ANY
EXPRESS OR IMPLIED WARRANTIES ARE DISCLAIMED. IN NO EVENT SHALL CORE SDI S.A. BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES RESULTING FROM THE USE OR MISUSE OF
THIS SOFTWARE.
Ariel Futoransky <futo@core-sdi.com> <http://www.core-sdi.com>

3) ssh-keygen was contributed by David Mazieres under a BSD-style license.

Copyright 1995, 1996 by David Mazieres <dm@lcs.mit.edu>. Modification and redistribution in source and binary forms is permitted
provided that due credit is given to the author and the OpenBSD project by leaving this copyright notice intact.

4) The Rijndael implementation by Vincent Rijmen, Antoon Bosselaers and Paulo Barreto is in the public domain and distributed with the
following license:
@version 3.0 (December 2000)

Optimised ANSI C code for the Rijndael cipher (now AES)

@author Vincent Rijmen <vincent.rijmen@esat.kuleuven.ac.be>

iv Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Third Party Copyright Notices

@author Antoon Bosselaers <antoon.bosselaers@esat.kuleuven.ac.be>


@author Paulo Barreto <paulo.barreto@terra.com.br>
This code is hereby placed in the public domain.

THIS SOFTWARE IS PROVIDED BY THE AUTHORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
5) One component of the ssh source code is under a 3-clause BSD license, held by the University of California, since we pulled these parts
from original Berkeley code.
Copyright (c) 1983, 1990, 1992, 1993, 1995

The Regents of the University of California. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are
met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this
software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.

6) Remaining components of the software are provided under a standard 2-term BSD licence with the following names as copyright holders:
Markus Friedl

Theo de Raadt
Niels Provos
Dug Song

Aaron Campbell
Damien Miller
Kevin Steves

Daniel Kouril

Wesley Griffin
Per Allansson

Nils Nordman

Simon Wilkinson

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are
met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
OpenSSL

Copyright (c) 1995-1998 Eric Young (eay@cryptsoft.com). All rights reserved.

http://www.openssl.org/about/
http://www.openssl.org/about/

OpenSSL is based on the excellent SSLeay library developed by Eric A. Young <mailto:eay@cryptsoft.com> and Tim J. Hudson
<mailto:tjh@cryptsoft.com>.

The OpenSSL toolkit is licensed under a Apache-style license which basically means that you are free to get and use it for commercial and
non-commercial purposes.

This package is an SSL implementation written by Eric Young (eay@cryptsoft.com). The implementation was written so as to conform with
Netscapes SSL.

This library is free for commercial and non-commercial use as long as the following conditions are adhered to. The following conditions
apply to all code found in this distribution, be it the RC4, RSA, lhash, DES, etc., code; not just the SSL code. The SSL documentation included
with this distribution is covered by the same copyright terms except that the holder is Tim Hudson (tjh@cryptsoft.com).

Copyright remains Eric Youngs, and as such any Copyright notices in the code are not to be removed. If this package is used in a product,
Eric Young should be given attribution as the author of the parts of the library used. This can be in the form of a textual message at program
startup or in documentation (online or textual) provided with the package.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are
met:

Instructor Edition v

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.

3. All advertising materials mentioning features or use of this software must display the following acknowledgement: "This product includes
cryptographic software written by Eric Young (eay@cryptsoft.com)" The word cryptographic can be left out if the routines from the library
being used are not cryptographic related :-).

4. If you include any Windows specific code (or a derivative thereof) from the apps directory (application code) you must include an
acknowledgement: "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"

THIS SOFTWARE IS PROVIDED BY ERIC YOUNG AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The license and distribution terms for any publicly available version or derivative of this code cannot be changed. i.e. this code cannot
simply be copied and put under another distribution license [including the GNU Public License.]
Copyright (c) 1998-2002 The OpenSSL Project. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are
met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the following acknowledgment:

"This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)"

4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to endorse or promote products derived from this software
without prior written permission. For written permission, please contact openssl-core@openssl.org.

5. Products derived from this software may not be called "OpenSSL" nor may "OpenSSL" appear in their names without prior written
permission of the OpenSSL Project.

6. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes software developed by the
OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/)"

THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT AS IS AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
This product includes cryptographic software written by Eric Young (eay@cryptsoft.com). This product includes software written by Tim
Hudson (tjh@cryptsoft.com).
PCRE

Copyright (c) 1997-2001 University of Cambridge

University of Cambridge Computing Service, Cambridge, England. Phone: +44 1223 334714.
Written by: Philip Hazel <ph10@cam.ac.uk>

Permission is granted to anyone to use this software for any purpose on any computer system, and to redistribute it freely, subject to the
following restrictions:

1. This software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
2. Regular expression support is provided by the PCRE library package, which is open source software, written by Philip Hazel, and
copyright by the University of Cambridge, England.
ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/
PHAOS SSLava and SSLavaThin

Copyright (c) 1996-2003 Phaos Technology Corporation. All Rights Reserved.

The software contains commercially valuable proprietary products of Phaos which have been secretly developed by Phaos, the design and
development of which have involved expenditure of substantial amounts of money and the use of skilled development experts over
substantial periods of time. The software and any portions or copies thereof shall at all times remain the property of Phaos.
PHAOS MAKES NO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTY OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, REGARDING THE SOFTWARE, OR ITS USE AND OPERATION
ALONE OR IN COMBINATION WITH ANY OTHER SOFTWARE.

PHAOS SHALL NOT BE LIABLE TO THE OTHER OR ANY OTHER PERSON CLAIMING DAMAGES AS A RESULT OF THE USE OF
ANY PRODUCT OR SOFTWARE FOR ANY DAMAGES WHATSOEVER. IN NO EVENT WILL PHAOS BE LIABLE FOR SPECIAL,
INCIDENTAL OR CONSEQUENTIAL DAMAGES, EVEN IF ADVISED OF THE POSSIBLITY OF SUCH DAMAGES.
RealSystem

The RealNetworks RealProxy Server is included under license from RealNetworks, Inc. Copyright 1996-1999, RealNetworks, Inc. All
rights reserved.
SNMP

Copyright (C) 1992-2001 by SNMP Research, Incorporated.

This software is furnished under a license and may be used and copied only in accordance with the terms of such license and with the
inclusion of the above copyright notice. This software or any other copies thereof may not be provided or otherwise made available to any
other person. No title to and ownership of the software is hereby transferred. The information in this software is subject to change without
notice and should not be construed as a commitment by SNMP Research, Incorporated.

vi Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Third Party Copyright Notices

Restricted Rights Legend:

Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical
Data and Computer Software clause at DFARS 252.227-7013; subparagraphs (c)(4) and (d) of the Commercial Computer Software-Restricted
Rights Clause, FAR 52.227-19; and in similar clauses in the NASA FAR Supplement and other corresponding governmental regulations.

PROPRIETARY NOTICE

This software is an unpublished work subject to a confidentiality agreement and is protected by copyright and trade secret law.
Unauthorized copying, redistribution or other use of this work is prohibited. The above notice of copyright on this source code product does
not indicate any actual or intended publication of such source code.
STLport

Copyright (c) 1999, 2000 Boris Fomitchev

This material is provided "as is", with absolutely no warranty expressed or implied. Any use is at your own risk.
Permission to use or copy this software for any purpose is hereby granted without fee, provided the above notices are retained on all copies.
Permission to modify the code and to distribute modified code is granted, provided the above notices are retained, and a notice that the code
was modified is included with the above copyright notice.
The code has been modified.

Copyright (c) 1994 Hewlett-Packard Company

Copyright (c) 1996-1999 Silicon Graphics Computer Systems, Inc.


Copyright (c) 1997 Moscow Center for SPARC Technology

Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby granted without fee,
provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in
supporting documentation. Hewlett-Packard Company makes no representations about the suitability of this software for any purpose. It is
provided "as is" without express or implied warranty.

Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby granted without fee,
provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in
supporting documentation. Silicon Graphics makes no representations about the suitability of this software for any purpose. It is provided
"as is" without express or implied warranty.

Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby granted without fee,
provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in
supporting documentation. Moscow Center for SPARC Technology makes no representations about the suitability of this software for any
purpose. It is provided "as is" without express or implied warranty.
SmartFilter

Copyright (c) 2003 Secure Computing Corporation. All rights reserved.


SurfControl

Copyright (c) 2003 SurfControl, Inc. All rights reserved.


Symantec AntiVirus Scan Engine

Copyright (c) 2003 Symantec Corporation. All rights reserved.


TCPIP

Some of the files in this project were derived from the 4.X BSD (Berkeley Software Distribution) source.
Their copyright header follows:

Copyright (c) 1982, 1986, 1988, 1990, 1993, 1994, 1995

The Regents of the University of California. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are
met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the following acknowledgement:
This product includes software developed by the University of California, Berkeley and its contributors.

4. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this
software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
Trend Micro

Copyright (c) 1989-2003 Trend Micro, Inc. All rights reserved.


zlib

Copyright (c) 2003 by the Open Source Initiative

This software is provided as-is, without any express or implied warranty. In no event will the authors be held liable for any damages
arising from the use of this software.

ICU License - ICU 1.8.1 and later COPYRIGHT AND PERMISSION NOTICE Copyright (c) 1995-2003 International Business Machines
Corporation and others All rights reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and
associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use,
copy, modify, merge, publish, distribute, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do
so, provided that the above copyright notice(s) and this permission notice appear in all copies of the Software and that both the above
copyright notice(s) and this permission notice appear in supporting documentation. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT
SHALL THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL

Instructor Edition vii

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. Except as contained in this notice, the name of a copyright
holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written
authorization of the copyright holder.
Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document
itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the
Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

viii Instructor Edition

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Table of Contents

Chapter 1: System Architecture .................................................................. 1


Chapter 2: Advanced Services TCP Tunneling .................................... 19

Chapter 3: Content Policy Language ........................................................ 39


Chapter 4: Regular Expressions ............................................................... 73

Chapter 5: Managing Downloads and Apparent Data Types .................... 91


Chapter 6: Policy Tracing ........................................................................ 105

Chapter 7: HTTP Details ......................................................................... 113

Chapter 8: Using Authentication In Transparent Proxy Mode ................. 127

Chapter 9: Understanding Kerberos Authentication (Optional) ............... 143


Chapter 10: Using Kerberos Authentication ............................................ 157
Chapter 11: Substitution Realm .............................................................. 169

Chapter 12: Windows SSO ..................................................................... 181


Chapter 13: Advanced Authentication .................................................... 189

Chapter 14: Guest Authentication ........................................................... 209


Chapter 15: SSL Proxy ........................................................................... 225

Chapter 16: Bandwidth Management ..................................................... 239


Chapter 17: Managing Streaming Media ................................................ 259

Chapter 18: Forwarding .......................................................................... 273


Chapter 19: Reverse Proxy Implementation ...................................... 285

Instructor Edition ix

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Chapter 20: Two-Way URL Rewrite ........................................................295

Chapter 21: Failover ................................................................................307


Chapter 22: Access Logging Advanced Topics ..................................319

Chapter 23: Web Cache Communication Protocol (WCCP) ..................337


Chapter 24: Health Checks .....................................................................349

Chapter 25: ProxySG Security ................................................................361

Chapter 26: Introduction to Blue Coat Director ........................................365

Chapter 27: Introduction to Blue Coat ProxyRA ......................................375

Appendix: Understanding Digital Certificates ..........................................395


Appendix B: Blue Coat Authentication and Authorization Agent .............403

x Instructor Edition

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 1: System Architecture

Estimated Lesson Time: ProxySG 45 minutes

Instructors Note: This chapter discusses, at a very high level, the internal system
architecture of the Blue Coat SG. You must point out to the students that this chapter does
not give all the details. Deliver the message that the most intricate details of internal
architecture cannot be made public for obvious reasons. However, this chapter is an accurate
description of how ProxySG processes transactions and manages cached content.

ProxySG architecture is complex and evolves continually to support new and better features. This
chapter discusses, at a high level, the details of how the ProxySG:

Handles transactions

Analyzes and processes policy

Caches content

Some details are not discussed in this course because they are proprietary and confidential to Blue
Coat Systems.

This chapter is intended to help you understand how the ProxySG processes information,
validates policy statements, and decides how to manage cacheable content. In particular, you will
learn why certain policies must be ordered in a certain way, when some policy statements are
evaluated, and why the ProxySG is the most efficient and secure caching appliance on the market.
A section is also dedicated to discussing how the ProxySG can enhance the performance of Web
response time when it is deployed in either forward proxy mode or reverse proxy mode.
This chapter also offers some tips and tricks that are helpful when you use older-generation
firewalls or routers, which may react in an unpredictable manner to pipelining.

Finally, the topics covered in this section allow you to get a much better understanding of ProxySG
policy tracing results; policy tracing, which is discussed later on in this book, is an essential
troubleshooting tool.
The SGOS contains no general-purpose code, and does not re-use code from other systems. The
OS has been built from the ground up specifically to improve proxy caching and Web applications.
As a result, Blue Coat products have emerged as the preferred foundation for enterprise proxy
caching applications. The following pages focus on providing a high-level overview of core SGOS
technologies specifically those designed to improve the Internet user experience.

Instructor Edition 1

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

System Architecture
Software Workers

Policy Checkpoints

Caching Techniques
Pipelining Requests

6OLGH(OHPHQWVRIV\VWHPDUFKLWHFWXUH

Instructors Note: This slide summarizes the content of the section. Spend a little bit of time
describing what each bullet point represents. Mention that each topic is detailed in the
remainder of the presentation.

This chapter discusses some of the key components of ProxySG internal structure. When the
ProxySG receives a connection request, it manages this connection by creating a client worker and
then, if necessary, a server worker. These are processes within the operating system that manage
the incoming and outgoing transactions.
At each stage of the transaction, the ProxySG has some amount of information that can be
matched against the running policy. These points in the transaction process are known as policy
checkpoints.

The ProxySG needs to decide if the transaction request must be fulfilled from cache, if data must
be obtained from the Internet, or if the request should be denied. The ProxySG uses a series of very
advanced algorithms to make this determination.

Finally, to maximize performance, the ProxySG can retrieve a large number of objects concurrently
from the Internet by pipelining a large (and definable) number of TCP connections.
The combination and integration of the four elements described above give you a pretty solid
understanding of the internal system architecture for ProxySG.

2 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 1: System Architecture

Software Workers

Client Worker (CW) Maintains HTTP sessions


between the Blue Coat SG and clients

Server Worker (SW) Maintains HTTP sessions


between the Blue Coat SG and OCS
Retrieval Worker (RW) Keeps the contents of
the cache fresh

Specialized Worker Handles a specific protocol,


like IM, streaming, etc.

6OLGH0DLQVRIWZDUHZRUNHUV

Instructors Note: The main workers are listed in this slide. Tell your students that there are
many other workers used by the ProxySG. You can mention the HTTP worker because it is
useful to explain the concept of HTTP handoff later in this book. The HTTP workers (client and
server) are workers dedicated to processing HTTP requests and also are used to manage IM
traffic (when the proper license is installed). With the support of new protocols, the SGOS may
introduce new and dedicated workers, which understand that particular protocol.

The three main workers that are discussed in this book are the client worker, server worker, and
retrieval worker. There are several other workers that the ProxySG uses to manage the complex
tasks it is capable of. You can imagine that there are client and server workers dedicated for each
of the protocols that the ProxySG can understand.

At every major new release, Blue Coat plans to add new and more specialized workers to the list
available to the SGOS. The functionalities covered by each worker and their interconnections may
also change.
Full discussion of all the workers is beyond the scope of this course.

Instructor Edition 3

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Software Workers

6OLGH6RIWZDUHZRUNHUVPRGHO

Instructors Note: You need to discuss this slide in detail. This is the prelude to
understanding the policy checkpoint, which is key to understanding how policies are
interpreted and applied. Point out that each client causes the ProxySG to initiate one or more
client workers. Each user agent can cause the ProxySG to initiate multiple client workers, one
per connection. The diagram above shows the primary workers used by the HTTP proxy. Each
upper lever (Layer 7) protocol has a corresponding set of workers, the exact details of which
depend on the protocol and the control and visibility features offered. From release to release,
new workers are introduced as required for in-depth inspection and control of new protocols.

The diagram in Slide 1-3 shows the main workers that the SGOS implements to manage HTTP
transactions. You need to read the diagram from the left to the right.

When a client makes an HTTP connection to the ProxySG, the SGOS assigns a worker to manage
that transaction. That worker is called a client worker (CW). The client worker is responsible for all
aspects of communication at the HTTP level with the client. Note that one client may open a
number of simultaneous connections and therefore may cause the OS to initiate a corresponding
number of CWs. The CW is the entry point into the ProxySG.

The CW determines the destination of the HTTP request and if it is a cacheable protocol request.
For instance, if the request is an HTTP request, the CW communicates with the cache administrator
(CA) to determine if the content for that transaction is available in the local cache. As far as the CW
is concerned, all of the content comes from cache. It is the CA that determines if the object is
available in cache; if not, the worker must decide whether to obtain it from the OCS. HTTP
protocol client workers use a server worker to obtain the content regardless of whether that
content should be cached.
When the content is not available in cache, the CW causes the OS to initiate a server worker (SW).
The purpose of the SW is to create and maintain the session with the OCS. The SW retrieves the
requested content and makes it available to the CA.

The protocol-specific administrator can initiate a worker autonomously to keep the content of the
cache fresh. This worker is called a retrieval worker (RW). The effect of the RW is visible when you
have the ProxySG establishing connections to the Internet, even when clients are not making
requests.

4 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 1: System Architecture

Performance

Feature

200-0

400-1

800-1

8000-1

8000-4

Memory

256 MB

512 MB

1 GB

1 GB

4 GB

HDD

40 GB

2x40 GB

73 GB

2x73 GB

8x73 GB

Object
Limit

N/A

2,290,000

4,518,000

4,576,000

18,302,000

6OLGH3URGXFWSHUIRUPDQFH

Instructors Note: This slide covers some of the key performance parameters of the ProxySG
family of products. This list is not all-inclusive; you can look up more details on the Blue Coat
corporate Web site. The idea is to list some of the hardware from the lowest (ProxySG 200-0)
to the highest (ProxySG 8000-4). These figures refer to older hardware; this is done
intentionally.
Important: The numbers listed in the row HTTP Clients represent the total number of client
HTTP workers. The numbers in the row Object Limit refer to the maximum number of RAM
cache objects; each variant of an item is an additional object.

The table displayed in the slide above should be used as a reference guide to size the hardware
and to better understand under which conditions a ProxySG may enter overload conditions.

The maximum amount of RAM available in a ProxySG controls the maximum number of objects
that can be stored in the object store (cache) and the maximum number of concurrent HTTP
sessions that can be managed concurrently.

The maximum amount of disk space available also determines the maximum number of objects
that can be stored in the object store. Object limits control how many items can be stored; however,
the space occupied by the objects cannot exceed the maximum allocated space for the object store.
Protocols like HTTP, which manage large number of small objects, are more likely to run into the
maximum object limit rather than the disk space limit. Protocols like streaming media are more
likely to run in to the maximum amount of available disk space as a limit.
Important: The object limit is the maximum number of objects that can be stored in the object
store across all cacheable protocols. It is not a per-protocol limit.

The ProxySG uses a RAM hash table to reference all objects on each disk. The number of objects is
proportional to the amount of RAM available and not necessarily the amount of disk space. The
maximum number of cacheable objects is a combination of the physical space available between
memory and disks and the number of addressable objects.

 7KHFRQWHQWRIWKHVOLGHLVDFFXUDWHDVRI0D\VXEMHFWWRFKDQJHZLWKRXWQRWLFH

Instructor Edition 5

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

The size of the hash table limits the total number of objects that can be stored. You can compare the
hash table to a large index. A cacheable object is placed in the object store and its location is
recorded in the hash table stored in RAM. When the system needs to access (retrieve or refresh)
the object, it looks up the objects location in the RAM hash table. As an example, far from being
accurate, you can compare the RAM hash table with the FAT table on Windows-based systems;
however, the ProxySG does not have a FAT or NTFS file system but an object store (see Slide 1-13).
Not all RAM is allocated to the hash table: A small part is used by SGOS and the rest is primarily
used to manage TCP connections and cache objects. Using the threshold monitor (TM), the
ProxySG monitors several operational parameters; one of these parameters is called memory
pressure. The memory pressure condition is defined when the committed (allocated) RAM
exceeds 95 percent. The memory pressure state is abandoned after committed RAM drops below
90 percent.
During memory pressure situations:

New client connections will be delayed.

TCP/IP sockets for all proxies stop accepting new requests.

HTTP proxy begins to shut down idle persistent connections.

Management-related services (SSH, Telnet, HTTP-Console, and HTTPS-GUI) do not change


behavior.

The HTTP proxy will also adhere to a maximum active client connections count that is set per
platform. When max-active clients is reached, the idle persistent connections also begin to be shut
down. The maximum active HTTP client count supersedes TM.
Note:

This textbook should be used only as a high-level guide to understanding sizing. You
should always discuss specifics of your deployment with a qualified Blue Coat SE.

6 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 1: System Architecture

Policy Checkpoints

Checkpoints are present in multiple parts of


the transaction processing
Policy rules are evaluated at checkpoints

Triggers must be evaluated at a checkpoint


before their associated actions can be taken
Late condition [name]' guards early action:
[name]'

6OLGH3ROLF\SURFHVVLQJIORZ

Instructors Note: The easiest way for you to explain the concept of policy checkpoints is with
an example of improper policy that generates the {Late condition [name]' guards early action:
[name]' } message. For instance, you can use the example:
response.header.Content-type=text/html forward(
http://www.somesite.com )
The determination of content type is done at the server in checkpoint, while the forward
decision is done at the server out checkpoint.

Additional Note: In this section you may start introducing some concepts about CPL. This
section is pivotal to a better understanding of CPL. However, you may want to carry on most of
the discussion of the text on this page with the next slide projected on the screen.

The evaluation of the running policy is performed at various points within the ProxySG. At each
point in the evaluation process, some elements of the overall policy can be evaluated and a
decision can be made.

At each checkpoint the running policy is evaluated and properties for the transaction are set based
on the information available to the ProxySG at that moment in the processing flow. As the
transaction progresses toward another checkpoint, more information becomes available and the
property of the transaction or the decision on how to handle the transaction may change.
The triggers and properties are designed so that wherever possible, the policy writer is shielded
from the variations among protocols. This is done by making the systems timing requirements
accommodate all the protocols. Where this is not possible (because using the most restrictive
timing causes significant loss of functionality for the other protocols), protocol-specific triggers
have been introduced. When evaluated against other protocols, these triggers return the not
applicable value or N/A.

This results in the rules being skipped (the expression evaluates to false, no matter what it is). It is
possible to explicitly guard such rules so that they are only evaluated against appropriate
transactions. The variation in trigger and property timings implies that within a policy rule a
conflict is possible between a condition that can only be tested relatively late in the evaluation

Instructor Edition 7

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

sequence and a property that must be set relatively early in the evaluation sequence. Such a rule
results in a compile-time error. For example, here is a rule that would be incorrect for evaluating
any transaction:

If the user is in group xyz, require authentication.

The rule is incorrect because group membership can be determined only after authentication. It is
incorrect also because the rule tests group membership and specifies the authentication realm, a
property that must be set before the authentication challenge can be issued. The following code
illustrates this incorrect rule and the resulting message at compile time:

group=xyz authenticate(MyRealm)

Error: Late condition guards early action: authenticate(MyRealm)

However, it is correct for the authentication requirement to be conditional on the client address
(client.address=) or proxy port (proxy.port=) because they can be determined at the time
the client connection is established and therefore are available from the beginning of a proxy
transaction. For the HTTP protocol, authenticate() can be conditional on the URL (url=);
however, for MMS streaming, only the Host portion of the URL can be tested (url.host=).

A proxy transaction evaluates policy in <Proxy>, <Cache>, <Forward>, and <Exception>


layers. The <Forward> layers are evaluated only if the transaction reaches the stage of contacting
an origin server to satisfy the request. (This is not the case if the request is satisfied by data served
from cache, or if the transaction is terminated by an exception.) The <Exception> layers are
evaluated only if the transaction is terminated by an exception.
Each of the protocol-specific proxy transactions has specific information that can be tested
information that may not be available from or relevant to other protocols. HTTP headers and
Instant Messaging buddy names are two examples of protocol-specific information. Other key
differentiators among the proxy transaction subtypes are the order in which information becomes
available and when specific actions must be taken, as dictated by the individual protocols.
Variation inherent in the individual protocols determines timing, or the sequence of evaluations
that occurs as the transaction is processed.
Note:

The <Proxy> layer is the CPL equivalent of the Web Authentication and Web Access
Layers, the <Cache> layer is the equivalent of the Web Content Layer; there is no
equivalent in VPM to the CPL <Exception> layer.

8 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 1: System Architecture

Policy Checkpoints

6OLGH3ROLF\FKHFNSRLQWV

Instructors Note: You have already discussed most of this slide with the material detailed for
Slide 1-5. In this section you can focus on the fact that many checkpoints are not detailed
here. For instance, there are at least three cache-related checkpoints: Cache Query (CQ)
occurs when the cache is about to be queried to determine the availability of the requested
object; Cache Hit (CH) occurs after a response has been obtained from the cache; and Cache
Charge (CC) occurs after a response has been received from the origin server and is
cacheable. That response is about to be placed into the cache when this checkpoint is
evaluated.

You can follow the transaction from the checkpoints angle, in a way similar to the one you used to
consider the different workers.

When the ProxySG receives a connection request, the client in (CI) checkpoint is reached. The
checkpoint occurs after the ProxySG identifies the request but before it attempts to fulfill any
portion of the request. During this checkpoint, if it is enabled, authentication takes place. A
decision on how to handle the transaction may be reached at this point and the transaction may
not need to reach any other checkpoint. (For instance, the authentication fails.)

If the transaction is able to progress past the CI checkpoint, the next evaluation occurs when the
request is about to be sent to the origin server. The checkpoint will be evaluated for pipeline
requests, refresh requests, and cache misses. This checkpoint is the server out (SO) checkpoint.

After the response from the OCS is received, the transaction reaches the server in (SI) checkpoint.
At this point, the response is available for analysis by the policy-enforcement engine. For instance,
the SI checkpoint can determine if the Content-Encoding is acceptable by the policy.
The last checkpoint is client out (CO). This checkpoint is used in request/response-type
transactions. This checkpoint occurs after the response has been determined and is about to be
sent back to the client. Here the result of response virus scanning is available.

Instructor Edition 9

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Caching Techniques
Adaptive Refresh

Adapt to user patterns


Estimate staleness probability

Cost-based Deletion
Link speed analysis

Popularity Contest

6OLGH&DFKLQJWHFKQLTXHV

Instructors Note: You need to emphasize that the ProxySG is a security appliance; however
at its core it retains all the advanced caching enhancements that made CacheFlow the market
leader in the caching market. Make sure to point out that caching is now a minimal part of the
feature set offered by the proxy. However the performance gain that caching adds to your
network is significant, and it can be very visible in the branch-core deployment model.

The SGOS automatically measures and reports on the freshness of content it delivers to end users.
This reporting functionality is based on the Web object properties that are tracked by the Adaptive
Refresh algorithms. The measurement function begins by tracking the number of times an object
in the proxy appliances store is delivered to an end user since the last time its freshness was
checked. These facts are then contrasted with the results of the Adaptive Refresh activity. When a
refresh check occurs for that object, various outcomes can be calculated:

If the object has not changed on the server, the previous deliveries of that object are recorded
as having been fresh.

If the object has changed on the server, the OS calculates the percentage of previous deliveries
of the object that were fresh and whether or not any were delivered stale with respect to the
time the object changed on the origin server.

Through this reporting mechanism, network administrators can be confident that the content their
users are receiving is in fact the content that existed on the Web at the time of the request.

10 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 1: System Architecture

Asynchronous Adaptive Refresh

6OLGH$V\QFKURQRXV$GDSWLYH5HIUHVK

Instructors Note: This page discusses the patent-pending Asynchronous Adaptive Refresh
algorithm. It selectively refreshes Web objects based on their need to be refreshed.

Because content on Web servers changes, a proxy appliance must keep its cache of content up to
date. Traditionally, for a proxy to deliver fresh content to the end user, it must send a refresh
check to the origin server. However, to serve the content quickly, it must not wait until a user
requests the content before it performs this refreshing activity. If the refresh checks are performed
only at the moment the user requests the content, the user will endure the round-trip delays that
cause the Internet to be slow in the first place and Web page response time will not be
substantially improved.

The only method for delivering Web pages quickly and accurately is for the refreshing activity to
be uncoupled from the actual end-user requests. The SGOS performs this activity with another
latency-attacking algorithm called Asynchronous Adaptive Refresh. This patent-pending
algorithm selectively refreshes Web objects based upon their need to be refreshed. This refreshing
activity occurs asynchronous to actual user requests so as to not impact response times.

Selecting what objects to refresh and when requires an understanding of object behaviors. Web
objects change at different rates. Some change frequently, some rarely, and many have change
rates in between. The histogram shown on the next page is derived from data extracted from Blue
Coat proxy appliances in use around the world. (The histogram does not represent an absolute
model of how frequently objects change; it simply highlights the change rates that were observed
during the time of the analysis.)

Instructor Edition 11

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Figure 1-1: Object Change Rate

The Asynchronous Adaptive Refresh algorithm integral to the SGOS is the only technology in the
industry that develops a model of change for every Web object in its store. It also develops a
model of use based upon that object's history of being requested by users. It then combines
these two pieces of information to determine the refresh pattern appropriate to that object. (The
values derived by the algorithms also adapt to changes produced by these models over time.)

Using the Asynchronous Adaptive Refresh algorithm, the ProxySG automatically performs
freshness checks with the origin server to ensure that old content is expunged and replaced with
fresh content. For example, if the objects within the www.nbcnews.com home page are popular
among the population of users that are accessing the proxy, the OS will update the objects that
change. (For instance, the NBC logo object). This ensures that current content will be delivered
to end users quickly.
While Object Pipelining improves response times for first-time Web page requests, Asynchronous
Adaptive Refresh significantly speeds subsequent requests by removing the latency involved in
refreshing the objects.

Only through the latency-attacking algorithms pioneered by Blue Coat Systems can the Internet be
accelerated for first-time and N-time requests for content. The SGOS, through its ability to deliver
content quickly and accurately, is the foundation of the industry's most effective secure proxy
solution.

12 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 1: System Architecture

Cost Based Deletion

6OLGH&RVWEDVHGGHOHWLRQ

Instructors Note: Make it clear to that all of the different caching and deletion techniques are
used at the same time. Actual details are proprietary to Blue Coat. Reinforce the concept that
cost-based = time to download the object.

Cost-Based Deletion is a powerful algorithm used by ProxySG to determine which objects to


delete first where there is no more room in the object store. Because a caches storage is full all the
time, to make room for new incoming objects some objects must be deleted.
Cost-Based Deletion chooses to delete objects based upon their cost to end-user response time in
combination with the objects relative popularity. Basically, the average time it took to retrieve
each chunk of an object is examined. The time depends on the link and is averaged over all
retrievals. If the system has to remove an object, it makes more sense to remove one that is both
inexpensive to re-download and unpopular. (See the next page for more about popularity.)
If an object is deleted and is requested again, the request is fulfilled relatively quickly.

Instructor Edition 13

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Popularity Contest

6OLGH3RSXODULW\FRQWHVW

Instructors Note: This is not a concept unique to Blue Coat; however, not all caching
engines use an actual algorithm as sophisticated as the one implemented in the ProxySG.
Again, this is just one of the many factors that ProxySG evaluates before deciding which
object to delete.

Typically, there two main ways of handling and swapping data in a queue: FIFO (first-in, first-out)
or LIFO (last-in, first-out). While FIFO seems a reasonable approach to handling cached objects, it
fails to recognize the most important characteristic associated with the objects in the data store. An
object that has been requested only once in the last few cycles is less likely to be cached than an
object requested more frequently. On the other hand, an object that has been requested several
times should be cached because the bandwidth saving is more significant if the object is served
from the local cache.
The image in Slide 1-10 shows how the objects are sorted in the queue relative to their probability
of being deleted next. The stack on the left represents the ProxySG sorting algorithm and the one
on the right represents a generic FIFO approach. When a new object arrives and needs to be added
to the stack on the left, the least popular object is replaced; when the same object is added to a
regular stack, the oldest object in the stack in deleted, regardless of its popularity.
You should note that the popularity is not strictly based on the number of requests. The ProxySG
uses the concept of relative popularity. This concept allows the CA to prefer to refresh a
relatively popular but costly object over a relatively unpopular but inexpensive object.

14 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 1: System Architecture

RAM Object Cache

6OLGH5$0REMHFWFDFKH

Instructors Note: Do not spend too much time on this slide because the details are not
relevant to this class. The key is to explain that all of the objects served by the ProxySG to the
client appear as if they are coming from the cache. Objects are stored in RAM first, served to
the client, and swapped into the object store as needed. Point out that the way the ProxySG is
designed, there is no real marked separation between data on disk and data in RAM. The
concept of paged memory, applicable to the generic purpose OS, is not relevant to the SGOS.

The ProxySG manages the data in the object store (see next page) and objects in RAM as the same
type of entity. Every object served to the client appears as if it comes from the cache, even if it is
retrieved from the OCS. The process of serving data to the client and feeding the object store for
cached data is virtually transparent.

Objects are retrieved from the OCS and put into RAM; they will be placed in the object store based
on considerations similar to the ones used for caching. For instance, if an object is very popular it
may remain as a RAM object for a while, compared to a less popular object.

Very simply, the object store is a two-level cache, consisting of a first level of RAM cache for objects
being accessed currently and for the most popular objects. The second cache level is on the disk.

Instructor Edition 15

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Pipeline Retrieval

A client uses typically two threads per request


The Blue Coat SG can use large number of
server workers to pre-fetch content

6OLGH3LSHOLQHUHWULHYDO

Instructors Note: Emphasize the importance of pipeline retrieval. This is critical not just for
forward proxy but also for reverse proxy deployments. Do not fail to mention that at times a
firewall may not like the high number of concurrent connections that ProxySG is trying to
establish with the outside world. You can either limit the amount of pipelining performed by the
proxy (reduced performance gain) or disable the relevant alarms and policies on your firewall
and routers.

When a browser requests content, dozens of round trips must take place between the browser and
the distant Web server. This is because a Web page is typically composed of dozens of objects, and
for each object there typically must first be a TCP session setup followed by an HTTP GET request.
This serial retrieval of objects presents a major delay for the end user. With a ProxySG deployed, a
large portion of this delay is eliminated. The client connection terminates at the ProxySG, which
leverages the latency-attacking algorithms provided by the SGOS. One of these algorithms is
called Object Pipelining. Instead of retrieving objects serially, this patent-pending algorithm opens
as many simultaneous TCP connections as the origin server will allow and then retrieves objects in
parallel. The objects are then delivered from the appliance straight to the users desktop as fast as
the browser can request them.
As a result of Object Pipelining, Blue Coat typically accelerates first-time Web page retrievals by 50
percent. The NSS Group, in a published technical evaluation of Blue Coat products, has confirmed
the effects of Object Pipelining: The most surprising figures are the second set, taken during
proxy cache initialization. At this point, the proxy cache was completely empty and you would
thus expect to see no improvement over the non-cached set of figures. However, the fact that
there is a clear performance gain (retrieval times with the cache are less than half of those where
no cache is used) proves that the object pipelining technique employed by Blue Coat provides
significant benefits.

16 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 1: System Architecture

Storage Subsystem

6OLGH6WRUDJHVXEV\VWHP

Instructors Note: Use this slide to make very clear, one more time, that the SGOS is not a
UNIX-like OS. It is a custom OS, designed to store cached content. The performance of the
Blue Coat caching mechanism cannot be matched by devices using a regular file system like
NTFS or EFS. Regular file systems are designed to retrieve files. The SGOS data store is
designed to retrieve Web objects. Discuss how the disk is organized in 8KB blocks and how
the data is stored in the same pattern as the URL. Make sure to explain the fundamental
difference between a file system and an object store.

The method of storing objects on disk is critical for achieving both high performance and high
scalability. It determines (1) how quickly a cached object can be accessed when a client requests it,
(2) how rapidly new objects can be acquired and stored on disk, and (3) the rate at which client
requests can be serviced per disk drive.

The SGOS object storage system is not a file system. It is an object cache. There is no directory in
the OS. Object access is through a hash table in RAM, ensuring that any objects first chunk of data
the piece that is so critical to the experience of request latency can be obtained in a single disk
read. File systems run poorly when they are full; however, a cache achieves its highest
performance when it is full.
The disk stores objects from a portion of the URL namespace. Accesses are automatically balanced
among the available disks. The proxy appliance normally runs with its disk full of objects. Old,
seldom-used objects are continually removed to make room for new incoming objects. The disk
layout and replacement algorithms in the OS facilitate this process to optimize the speed of
writing new objects to disk.
In the unlikely event that a disk fails, the objects in its portion of the URL namespace are
automatically remapped to the remaining disks. New disks can be hot added to an existing
proxy to increase its storage capacity.

You should also consider the following statements, which describe the difference between a file
system and an object store.

Instructor Edition 17

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

File systems typically organize files into a hierarchical structure. Related files are kept together
in directories, and these directories are arranged in a tree structure. Once you walk down the
tree to a specific place, it's reasonably efficient to access all the related files. However, if you
are always accessing things using the full path name of the file, file systems can be very slow
because you have to keep traversing through all the intermediate directories every time.

Object stores store things differently, indexing all files by their full path name. With an
object store, there is no way to efficiently list just the contents of a particular directory.
However, when accessing files using their full path name, an object store can very quickly get
to any file, no matter how deep in the directory structure it is. When doing something like
HTTP object caching, each request always refers to a full path name, so it is much more
efficient to use the object store approach for accessing the cached data.

File systems typically keep files until you explicitly delete them. This is generally what you
want when you manage the files yourself, but it can be a problem on a cache because
eventually the cache will fill all available disk space. Instead of requiring the administrator to
manually clean up old files, the ProxySG object store is self-managing. It keeps track of the last
access time, popularity, and cost to reacquire the content currently stored in the cache and
automatically chooses to delete the content that is least useful in order to make room for new
content. This allows the ProxySG to always hold as much data as possible in the cache, always
keeping the content that will be most useful based on past access patterns.

18 Instructor Edition

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 2: Advanced Services TCP Tunneling

Estimated Lesson Time: 15 minutes

Instructors Note: The goal of this chapter is to formalize what TCP tunneling is and how you
should use it. You need to emphasize the edge-core deployment scenario once again. TCP
tunneling, which already existed in several previous releases, is now more effective because it
can be combined with byte caching and gzip compression to reduce bandwidth and increase
performance. It is useful for detecting peer-to-peer connections going over open ports on the
firewall.
Additional Note: Point out to the students that they should have a TCP tunnel proxy for each
port open on the firewall and route all traffic to the proxy (transparently or explicitly) in order to
achieve the most effective P2P control-and-prevention policy. If you are in a transparent proxy
deployment scenario, then you can set the default proxy service to intercept without the need
to create many different services for each used port on the firewall.

Each time a network packet reaches an interface on the ProxySG, the device needs to make a
decision whether to process the packet or ignore it. If the packet is ignored, which means policies
do not apply to that transaction, the ProxySG needs to decide how to handle the packet. The two
available options are to forward it to the next hop, or to drop it. You can configure ProxySG to
perform either action, depending on deployment and configuration options that you select.

Every time ProxySG decides to process a packet, which means apply policies if necessary, it needs
to know how to handle it. In particular the device needs to know which layer 7 protocol that
packet contains. You can associate each layer 7 protocol to a foreign language. When the ProxySG
receives the packet, it needs to know ahead of time which interpreter is attempting to read the
packet in question. Currently ProxySG supports (or you can say understands) a number of layer 7
protocols, including but not limited to: HTTP, HTTPS, FTP, CIFS, RPC, Streaming, IM, P2P, and
others.

The TCP Tunnel service, is a generic interpreter for TCP packets, which you can use to process
traffic which does not fall in the list of protocols known to ProxySG. For instance, if you have a
custom application, using a proprietary or non-standard layer 7 protocol, you can still proxy that
application through ProxySG using the TCP Tunnel service. You can compare this service to a
photocopy machine. When you are making a copy of a document, the machine does not care if it is
written in Chinese, English, or Arabic; it just copies it as-is. This service works in the exact same
way; while the information at lower layers (in particular data link, network, and transport) may be
changed, the application level information remains untouched. Later in the chapter, you will
discover how ProxySG has some built-in detection capabilities, which enable the device to
recognize selected traffic, even when passing through the ProxySG on a TCP port managed with a
TCP Tunnel service.
The Blue Coat SG supports both explicit and transparent TCP tunneling. You may choose
either method depending on your needs. Explicit TCP tunneling allows connections to one of the
ProxySG's IP addresses. Transparent TCP tunneling allows connections to any IP address other
than those belonging to the ProxySG. TCP tunneling in transparent mode supports categorization
as well as blocking of destination IP addresses, ports, hosts, and domains.
Note:

The TCP-Tunnel service does not support content filtering with Websense offbox or
ICAP.

If you want to create a transparent TCP tunneling protocol, you can do so from either the CLI or
the Management Console. When a TCP-Tunnel service is created, it is by default created as an
explicit service and is also enabled automatically.

Instructor Edition 19

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Important: If you created a transparent TCP-Tunnel service, you have completed the
procedure. However, if you created an explicit TCP-Tunnel service, you must
configure a forwarding destination port.

In essence, if you connect to the proxy on a TCP tunnel port in explicit mode, you need to give the
proxy instructions on where to route the traffic next. Since, in general, the ProxySG cannot
interpret the protocol stream, when the connection is terminated in explicit mode, you need to
create a forwarding rule to specify where the traffic has to be sent.

On the other hand, when you connect to the ProxySG on a TCP tunnel port in transparent mode,
the proxy knows where to send the traffic next. As you have learned in this class, the destination
IP address in a transparent proxy request is the one of the target OCS (Origin Content Server);
therefore, a forwarding rule is not required. ProxySG simply passes the protocol level information
to the machine with the IP address specified in the packet received from the client.
The default proxy service (which listens on all ports not assigned to other services), uses the
TCP-Tunnel proxy. The default proxy service has only one listener; its action can be set to bypass
or intercept. No new listeners can be added to the default proxy service, and the default listener
and service cannot be deleted.

Important: The default proxy service can be used only when the ProxySG acts as a bridge or
as a router (transparent proxy deployment).

20 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 2: Advanced Services TCP Tunneling

Explicit vs. Transparent Proxy

6OLGH'HSOR\PHQWRSWLRQV

Instructors Note: At this point most of your students should be very familiar with the
differences between an explicit and a transparent proxy deployment environment. However,
you want to discuss this slide in details one more time. There are few scenarios where you
need to use TCP Tunnel service in explicit proxy mode; in any case, this slide helps you
explain clearly why you need to have a forwarding rule when you are in explicit proxy
scenarios (the destination IP address in the clients request is the one of the ProxySG and the
protocol, which may contain information about the final OCS, may be unreadable to the proxy).
Similarly you can use this slide to explain why you do not need a forwarding rule in a
transparent proxy scenario (the destination IP address in the clients request is the IP address
of the final OCS).
It is important to note the differences between the two proxy deployment methods.

Explicit Proxy

The ProxySG cannot forward traffic, when operating in explicit proxy mode, if there is not a
service port associated with the destination TCP port of the incoming traffic. For instance, if you
try to connect to the ProxySG on port 8781, where, by default there are no services running, you
will get an error message saying that the proxy has refused the connection (or even that the proxy
is not there).

Transparent Proxy

The same is true when traffic is transparently sent to the proxy; however, there are two notable
exceptions to this. If the ProxySG is configured to operate in bridging mode or as a router, all the
packets that have a destination TCP port that does not match any of the services running on the
proxy will be forwarded to the next hop as specified in the packet or frame1. Another point to note
is that if you have set the Default Service to Intercept, then all the traffic will be optimized and sent
to the next hop in the application delivery network or to its final destination.

1. Routing mode requires that you have Enable IP forwarding checked (active).

Instructor Edition 21

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Transparent Proxy - Overview

6OLGH3URFHVVLQJWUDIILFLQWUDQVSDUHQWSUR[\PRGH

Instructors Note: Use this slide to remind students that in bridging or routing mode, the
ProxySG can deliver any packet but still can process only the traffic whose destination TCP
port matches one of the services running on the ProxySG. This slide shows a proxy with three
services managing 5 ports (80, 8080, 443, 22, and 3596). If the traffic received by the proxy
matches any of these five ports, it will be processed and policies may be applied. All other
traffic will be simply forwarded as-is or rejected.
Point out that in this slide the ProxySG does not have the Defaul TCP Tunnel service set to
intercept.

In transparent proxy mode, the ProxySG can operate as a Layer 2 switch (bridge) or a Layer 3
switch (router). In this deployment scenario, the ProxySG must be able to deliver and route any
kind of traffic (UDP, TCP, NetBIOS, unicast, multicast, broadcast, etc.). Nevertheless, the ProxySG
can only terminate and process those transactions in which the destination TCP port matches one
of the services running.
For instance, if there is a TCP connection on port N and the ProxySG has a TCP tunnel enabled on
port N, and a service is enabled, the action Intercept is selected, then the connection is terminated,
the traffic processed and then sent forward to its original destination (if the traffic is permitted).

If there are no services on the ProxySG listening for connections on port N, the default TCP tunnel
is set to bypass, and the proxy is in bridging mode (or acting as a router, with Enable IP forwarding
turned on), traffic is simply forwarded to the next hop as determined by the destination IP address
and MAC address.
However if the default TCP tunnel service is enabled, it is considered a service match and it will
process the traffic.
Important: Note by default, the TCP Tunnel service is set to bypass.

22 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 2: Advanced Services TCP Tunneling

TCP Tunnel - Details

6OLGH7&37XQQHOGHWDLOV

Instructors Note: Before getting into the details for this slide, you need to go over one more
time the definition of transparent and explicit proxy. If the students clearly understand it, then
they also naturally understand why you need a forwarding rule for the traffic which arrives
explicitly to the proxy and it is part of an unknown protocol. After you discuss Slide 2-5, come
back to this slide and ask: Do you still need to have a forwarding policy if the traffic on port
3128 is actually HTTP traffic ?.
Answer: If you have protocol detection enabled, you do not need the forwarding rule, as the
final destination IP address can be read in the URL (or at least in the host header).

In the slide above you have two different connections to the proxy; one is over explicit proxy and
the other one is over transparent proxy. A TCP tunnel service intercepts both connections.

The explicit proxy connection on TCP port 31282 contains a generic protocol, which ProxySG does
not recognize. Since the connection is sent over explicit proxy, ProxySG cannot determine the
destination of the connection. The destination IP address in the client request is the IP address of
the ProxySG. The only way the proxy can deliver the packet to the intended OCS is by using a
forwarding rule. You need to create a forwarding host and a forwarding rule to instruct ProxySG
where to send the traffic, which is explicitly proxied to port 3128.

The transparent connection on TCP port 25 contains most likely SMTP traffic. ProxySG does not
handle this protocol in any specific manner; however it is easy to determine the location of the
actual OCS. The destination IP address in the client request is the IP address of the final OCS, since
the connection is a transparent proxy connection.
ProxySG can open a connection with the machine located at that IP address and starts transmitting
the TCP payload byte-by-byte; it is not necessary for ProxySG to understand the content of this
data.
On TCP tunnel ports, ProxySG is always on the lookout for possible peer-to-peer activity; this
detection is done automatically, for added security. If you have a policy to control P2P traffic, the
policy is executed only when the P2P protocol detection is enabled .
2. TCP port 3128 is commonly used by squid clients. However, in this example the traffic is not necessarily
HTTP.

Instructor Edition 23

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Early Intercept

6OLGH(DUO\LQWHUFHSWRSWLRQ

Instructors Note: In previous releases of SGOS, early intercept was the only option that
ProxySG supported. The option to have delayed intercept (by turning off early intercept)
allows ProxySG to improve the transparency of the proxy. The default TCP Tunnel service that
captures all TCP ports needs to be able to correctly report back to the client which server ports
return an immediate TCP RST (connection refused) and which returns no response at all
(connection timed out). If early intercept was the only option, then all of these cases would
look to the client like the connection was successful, but then shortly after that the client
would suddenly see the connection drop (with a TCP RST) with no explanation. Clients
(excluding HTTP clients) may not handle this scenario well.

The early intercept feature controls whether the proxy responds to client TCP connection requests
before connecting to the upstream server. When this option is enabled, the ProxySG concludes the
three-way TCP handshake with the client before establishing any connection with the remote
server. From the client perspective, the TCP connection has been established, even when the
remote server may actually be not available.

The advantage of early intercept is that the ProxySG can reduce the overall time it takes to handle
the clients request. By answering the clients connection request immediately, the ProxySG gets
the actual request from the client more quickly, and can reduce the total time it takes to serve the
response. This is especially true in the case of cache hits, where the ProxySG can return the
response to the client without ever contacting the origin server. This is only possible with early
intercept enabled, otherwise the ProxySG would have to contact the server before it can determine
which URL the client was requesting (the ProxySG reads the information in the HTTP GET
request, which is sent by the client after the TCP connection has been established). Additionally,
with protocols like HTTP, the ProxySG has the option of not just dropping the connection when
the remote server is not responding; the ProxySG can return a properly formatted HTTP error
response notifying the client why the connection cannot be established.

24 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 2: Advanced Services TCP Tunneling

When early intercept is disabled, the proxy delays responding to the client until after it has
attempted to contact the server. After the client sends the TCP SYN packet, the ProxySG sends its
own TCP SYN packet to the remote server. Only after a server reply, the proxy responds to the
client. In case the server is not available (not responding), the client is not able to complete the
three-way TCP handshake. The advantage of not enabling early intercept is that ProxySG can
properly reflect back a connection refused or connection timed out error from a server back to the
client, since ProxySG has not yet actually responded to the clients connection request (TCP SYN).
Note:

When you enable the Detect Protocol option, Early Intercept is automatically enabled.

Instructor Edition 25

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Protocol Detection

6OLGH3URWRFRO'HWHFWLRQ

Instructors Note: Protocol detection is a tricky topic. Your goal is to clearly explain the
difference between protocol detection and protocol handoff; particularly clarify when one
requires the other. In particular, protocol detection inside a TCP Tunnel, HTTP CONNECT
tunnel, or SOCKS CONNECT tunnel can also trigger handoffs to HTTP, SSL, or Endpoint
Mapper. Protocol detection can also be used to identify P2P traffic, though that doesnt exactly
trigger a handoff in the normal sense.

The illustration above discusses a scenario very similar to the one in Slide 2-3. The major
difference with the previous slide is that now the ProxySG has the option detect protocol enabled.
Traffic on port 3128 is often coming from a client attempting to connect over HTTP proxy with a
machine running Squid proxy. Assuming this is the case, when the traffic over TCP port 3128
arrives to the ProxySG, the proxy immediately identifies the traffic as HTTP and begins
performing HTTP processing on the request. Since the traffic has been recognized as HTTP, all
HTTP specific triggers and actions can be used in the policy.
As long as there is a service that intercepts a connection, the connection goes through policy
processing and policies apply. However if the protocol is unknown, then only generic policies
apply. On the contrary, when the ProxySG can correct detect the protocol, additional policies
specific to that protocol can be applied to the connection.

The ProxySGs protocol detection can also look for other specific P2P protocols that masquerade as
plain requests in HTTP. With this capability, the ProxySG can classify the traffic as BitTorrent,
Fast track, or Gnutella. This is useful when you want to detect traffic that masquerades as an
HTTP traffic.
The ProxySG performs protocol detection on the clients request and not on the servers response;
this is an important difference, as certain protocols cannot be detected. For instance, HTTP can be
easily detected, as the client issues an HTTP request immediately after the three-way TCP
handshake. Other protocols, where the server speaks first, cannot be detected. For instance, in
SMTP, after the client completes the three-way handshake, it will not send any command before
receiving the prompt from the server. The ProxySG, when receiving traffic like SMTP, cannot
detect protocol, as it is waiting for the client to take some actions. When a maximum time-out time
lapses, the ProxySG process the connection as unknown protocol.

26 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 2: Advanced Services TCP Tunneling

The ProxySG attempts to make the decision about what protocol is being used before deciding
which server to connect to, as it might make different policy decisions about what forwarding host
to use or what URL rewrite to apply or various other similar actions based on the client protocol.
In order to perform protocol detection, the ProxySG reads the initial bytes of the client request; this
can be achieved only by allowing the clients connection request to complete. Therefore, enabling
protocol detection also enables early intercept to allow the ProxySG to read the client request bytes
before connecting to the remote server.

Instructor Edition 27

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Protocol Handoff

6OLGH3URWRFROKDQGRII

Instructors Note: Protocol handoff is often a tricky subject. Spend time on these concepts
and discuss the licensing details for IM and streaming protocols when protocol handoff is
enabled. (In essence, you need to have IM or streaming licenses if you want to create policies
for these protocols and to be able to use the handoff functionality.) For IM and streaming,
explain clearly that the ProxySG can process the traffic correctly only if such traffic is proxied
over HTTP; if you try to send native streaming or IM traffic over an HTTP port, the traffic will
not be allowed because it is not recognized as HTTP-compliant.

Protocol Handoff is a term used for a number of different cases where one protocol worker hands
a request or a connection off to another protocol worker. Some of these are triggered by protocol
detection, but a large number of them are not. All of the following involve handoffs without
involving protocol detection:

SOCKS acceleration by port number of HTTP or IM

SSL Forward Proxy interception as HTTPS

Streaming over HTTP

IM over HTTP

In this chapter, the focus is only on streaming media and IM protocol detection.

For Streaming Media

When a Windows Media, Real Media, or QuickTime client requests a stream from the
ProxySG over port 80, which in common deployments is the only port allowing traffic through a
firewall, the HTTP module passes control to the streaming module so HTTP streaming can be
supported through the HTTP proxy port. The ProxySG supports HTTP streaming and the HTTP
streaming request triggers a protocol handoff the downloading of media files from a HTTP
server donot trigger the handoff and are instead processedby the regular HTTP proxy on the
ProxySG. An HTTP connection established through port 80 allows you to send streaming data
from the origin server to the clients through the ProxySG.

28 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 2: Advanced Services TCP Tunneling

Note:

The default setting for HTTP handoff is enabled. If you do not want HTTP streams to
be cached or split, change this setting to disabled.

For Instant Messaging

IM handoff allows the Blue Coat HTTP proxy to handle requests from supported IM protocols. If
IM HTTP handoff is disabled, requests are passed through, and IM-specific policies are not
applied. Handoff should be enabled (the default) if you write IM policy.

If you want to allow a specific IM client to connect through HTTP through the ProxySG and that
IM protocol has not been licensed, disable IM HTTP handoff to allow the traffic to be treated as
plain HTTP traffic and to avoid an error in the licensing check done by the IM module. This also
may be necessary to temporarily pass through traffic from new versions of IM clients that are not
yet supported by Blue Coat.

Instructor Edition 29

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Static and Dynamic Bypass

6OLGH6WDWLFDQGG\QDPLFE\SDVV

Instructors Note: The slide may seem intimidating but you can easily explain it; the goal is to
point out the difference between static and dynamic bypass list. The static bypass list allows
you to create Client address and Server address pairs. When a request matches an entry in the
static bypass list, the request is passed to the OCS without being processed by the proxy. No
parameter of the connection is modified.
Static Bypass:
A- Client requests the URL http://www.bluecoat.com/, which resolves to the IP address
216.52.23.9; this matches an entry in the bypass list
B- The OCS receives the original, unmodified request from the client via the ProxySG

Dynamic Bypass:
1- Client requests the URL http://www.somesite.com/, which resolves to the IP address
10.10.2.36. There is no entry for this source/destination pair in the bypass list
2- The OCS receives the traffic processed (policies applied) from the ProxySG
3- The OCS returns an error code, which you have defined to trigger a dynamic bypass entry
4- The IP address of the OCS and the requesting client are placed in the dynamic bypass list
5- The client receives the error; further requests from that client to that same OCS will not go
through policy processing.

The bypass list contains IP addresses/subnet masks of client and server workstations. Used only
in a transparent proxy environment, the bypass list allows the ProxySG to skip processing
requests sent from specific clients to specific servers. The list allows traffic between protocol
incompliant clients and servers to pass through the ProxySG without a disruption in service
Using Policy to Configure Dynamic Bypass

Dynamic bypass, available through policy (VPM or CPL), can automatically compile a list of
response URLs that return various kinds of errors.

30 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 2: Advanced Services TCP Tunneling

Dynamic bypass keeps its own (dynamic) list of which connections to bypass, where connections
are identified by both source and destination. Dynamic bypass can be based on any combination
of policy triggers. In addition, some global settings can be used to selectively enable dynamic
bypass based on specific HTTP response codes. After an entry exists in the dynamic bypass table
for a specific source/destination IP pair, all connections from that source IP to that destination IP
are bypassed in the same way as connections that match against the static bypass list.

For a configured period of time, further requests for the error-causing URLs are sent immediately
to the origin content server (OCS), bypassing the ProxySG. The amount of time a dynamic bypass
entry stays in the list and the types of errors that cause the ProxySG to add a site to the list, as well
as several other settings, are configurable from the CLI.
Once the dynamic bypass timeout for a client and server IP address entry has ended, the ProxySG
removes the entry from the bypass list. On the next client request for the client and server IP
address, the ProxySG attempts to contact the OCS. If the OCS still returns an error, the entry is
once again added to the local bypass list for the configured dynamic bypass timeout. If the entry
does not return an error, the request is handled in the normal manner.
Notes:

Dynamic bypass entries are lost when the ProxySG is restarted.

No policy enforcement occurs on client requests that match entries in the dynamic or static
bypass list.

If a site that requires forwarding policy to reach its destination is entered into the bypass list,
the site is inaccessible.

Adding Dynamic Bypass Parameters to the Local Bypass List

The first step in configuring dynamic bypass is to set the server-threshold,

max-entries, or timeout values.

Note:

This step is optional because the ProxySG uses default configurations if you do not
specify them. Use the default values unless you have specific reasons for changing
them. Contact Blue Coat Technical Support for detailed advice on customizing these
settings.

The server-threshold value defines the maximum number of client entries before the
ProxySG consolidates clientserver pair entries into a single server entry that then applies to
all clients connecting to that server. The range is 1 to 256. The default is 16. When a
consolidation occurs, the lifetime of the consolidated entry is set to the value of timeout.

The max-entries defines the maximum number of total dynamic bypass entries. The range is
100 to 50,000. The default value is 10,000. When the number of entries exceeds the
max-entries value, the oldest entry is replaced by the newest entry.

The timeout value defines the number of minutes a dynamic bypass entry can remain
unreferenced before it is deleted from the bypass list. The range is 1 to 86400. The default
value is 60.

Enabling Dynamic Bypass and Specifying Triggers

Enabling dynamic bypass and specifying the types of errors that causes a URL to be added to the
local bypass list are done with the CLI. You cannot use the Management Console.
Using policy to enable dynamic bypass and specify trigger events is better than using the CLI,
because the CLI has only a limited set of responses.
Bypassing Connection and Receiving Errors

In addition to setting HTTP code triggers, you can enable connection and receive errors for
dynamic bypass.

Instructor Edition 31

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

If connect-error is enabled, any connection failure to the origin content server (OCS), including
timeouts, inserts the OCS destination IP address into the dynamic bypass list.
If receive-error is enabled, when the cache does not receive an HTTP response on a successful
TCP connection to the OCS, the OCS destination IP address is inserted into the dynamic bypass
list. Server timeouts can also trigger receive-error. The default timeout value is 180 seconds,
which can be changed

32 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 2: Advanced Services TCP Tunneling

Restricted Intercept

6OLGH5HVWULFWHG,QWHUFHSW

Instructors Note: This is a very useful sales and debugging tool. It allows an administrator to
test the features and functionalities of the ProxySG for few initial clients and roll out the
solution very gradually. Also, in case of some severe issues to be diagnosed, the administrator
can limit the traffic that is intercepted by the proxy so that the logs and packet captures contain
less data to process.

By default, all clients and servers evaluate the entries in Proxy Services (Configuration > Services >
Proxy Services) where the decision is made to intercept or bypass a connection. To restrict or
reduce the clients and servers that can be intercepted by proxy services, use the Restricted
Intercept List. The Restricted Intercept List is useful in a rollout, prior to full production, where
you only want to intercept a subset of the clients. After you are in full production mode, you can
disable the Restricted Intercept List.
The Restricted Intercept List is also useful when troubleshooting an issue, because you can reduce
the set of systems that are intercepted. If the restrict interception radio button (Configuration >
Services > Proxy Services > Restricted Intercept List) is selected, any systems not on the list are
bypassed.
If restricted intercept is disabled, the traffic behavior reverts to the previous behavior (before the
Restricted Intercept List was enabled). If restricted intercept is enabled, traffic not in the list of
systems is bypassed.

Note:

An entry can exist in both the Static Bypass List and the Restricted Intercept List.
However, the Static Bypass List overrides the entries in the Restricted Intercept List.

Instructor Edition 33

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Trust Destination IP

6OLGH7UXVWGHVWLQDWLRQ,3

Instructors Note: The concept of trusting destination IP is relatively simple and may be
exaplained but saying that the SG0 in the Slide 2-9 does not perform DNS resolution on the
host name found in the requests but will use whatever destination IP address the client have in
the request.
In the slide above point out the following:
- SG0 is a transparent proxy
- The clients are explicitally proxied using a PAC file, which load balances SG1 and SG2
- For one client, the trust destination IP option is disabled (default setting); when it tries to go to
www.bluecoat.com via either SG1 or SG2 proxy, the SG0 terminates the connection, performs
DNS lookup on the hostname and sends the request directly to the OCS
- For the other client, the trust destination IP option is enabled; when it tries to go to
www.bluecoat.com via either SG1 or SG2 proxy, the SG0 terminates the connection,applies
policies, but DOES NOT perform DNS resolve on the hostname. It sends it directly to IP
address found in the client request.
Important: All policies you set in your PAC file are not affected but the transparent SG0 proxy.

You can configure the ProxySG to trust a client-provided destination IP address in transparent
proxy deployments where:

The DNS configuration on the client is correct, but is not correct on the ProxySG.

The client obtains the destination IP address using WINS or DNS imputing on the ProxySG is
not configured correctly. In these cases, the ProxySG cannot obtain the destination IP address
to serve the client request.

You can use the client-provided destination IP address with transparent proxy environments that
use HTTP, native FTP, WebFTP, HTTPS, or streaming. The ProxySG cannot trust the
client-provided destination IP address in the following situations:

The ProxySG receives the client requests in an explicit proxy deployment.

The ProxySG has a forwarding rule configured for the request.

The ProxySG has a SOCKS gateway rule configured for the request.

The ProxySG has ICP enabled for the request.

34 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 2: Advanced Services TCP Tunneling

The ProxySG has policy that rewrites the server URL.

By default, the ProxySG does not trust a client-provided destination IP address. You can change
this default through the Management Console, the CLI, or through policy.
Note:

In the MACH5 edition, the ProxySG trusts the client-provided destination IP address
by default.

If a client gives the destination address of a blocked site but the hostname of a non-blocked site,
the ProxySG connects to the destination address. This might allow clients to bypass the configured
ProxySG security policy.
Using the trust_destination_ip(yes|no) property

This property allows the SG to honor client's destination IP when it intercepts client requests
transparently.

The Proxy SG will trust the client provided destination IP and not do the DNS lookup for the
HOST value in appropriate cases. This feature will not apply (i.e. existing behaviour will be
preserved) if :

The ProxySG recieves the client requets in explicit proxy deployment cases.

The ProxySG has forwarding rules configured for the given HOST value.

The ProxySG will connect upstream on SOCKS.

The ProxySG will connect upstream using ICP.

By default it is configured as enabled. To disable trusting destination IP you can use the policy
shown below:
<forward>

proxy.address=10.10.167.0/24 trust_destination_ip(no)

Instructor Edition 35

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

36 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 2: Advanced Services TCP Tunneling

Instructors Notes for TCP Tunneling Lab


Overview

In this lab you set up a TCP-Tunnel service to handle protocol requests on port 22.You want to
configure your Blue Coat SG appliance to accept connections on port 22 and redirect those
requests to an SSH server, for instance 172.16.90.100.
Note:

The scenario proposed in this lab is to control all SSH requests going to a specific
server. You should block access to SSH and port 22 for outbound traffic on the
firewall.

Computer Hardware and Software Requirements


Table 2-1: Requirements for the Instructor
Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

F SSH Server

F Open SSH version 4.0

Table 2-1: Requirements for Students


Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

F PuTTY

F Release 0.60

Instructor Edition 37

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

38 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 3: Content Policy Language

Estimated Lesson Time: 40 minutes

Instructors Note: You need to emphasize the basic terminology used in Content Policy
Language (CPL). In particular, you need to make sure that the students are familiar and clearly
understand the following terms: rule, trigger, property, definition, and action. Emphasize the
concept of layer and layer guard. Spend some time showing the VPM-generated CPL code
and compare with CPL code you would write to accomplish the same task. If you have
experience of C or other programming language, try to point out analogies and differences.

You can create policy rules using either the Visual Policy Manager (VPM), which is accessible
through the Management Console, or by composing Content Policy Language (CPL). CPL is
proprietary programming language specific to the Blue Coat SG platform. It allows you to
express the policy rules that are enforced by the ProxySG.

Almost all of the policy operations can be expressed through the VPM; however, there are a few
advanced operations which are possible only in CPL.

In this chapter, you will learn how to compose policy rules in CPL. You will then install the policy
on the ProxySG. You also will examine how that policy is evaluated during request processing to
override any default decisions arising from the initial configuration rules.

Key Concepts

Before reading sample CPL or trying to express your own policies in CPL, Blue Coat recommends
that you understand the fundamental concepts underlying policy enforcement on ProxySG
appliances. This section provides an overview of important concepts.

Policy

The term policy, as used here, refers to configuration values and rules applied to render
decisions on authentication requirements, access rights, quality of service, or content
transformations (including rewrites and off-box services that should be used to process the
request or response). Often, the policy references system configuration for the default values
for some settings and then evaluates rules to see if those settings should be overridden.

Transactions

In the CPL context, a transaction is the encapsulation of a request for service and any
associated response for the purposes of policy evaluation and enforcement. In most cases, a
transaction is created for each unique request for service, and the transaction exists for the
time taken to process the request and deliver the response.
The transaction serves the following purposes:

Q
Q
Q
Q

Exposes request and response state for testing during policy evaluation.
Ensures policy integrity during processing.

Maintains policy decisions relevant to request and response processing.

Various types of transactions are used to support the different policy evaluation
requirements of the individual protocols: administrator, cache, and proxy transactions.

Q In a few special cases, two or more transactions can be created for a single request.

Instructor Edition 39

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Policy Model

Each transaction begins with a default set of decisions, many of which are taken from
configuration of the system. These defaults include such things as forwarding hosts or SOCKS
gateways. The most important default decision affects whether or not requests should be
allowed or denied. The defaults for the various transaction types are:

Q Administrator Transaction: The default is to deny requests


Q Cache Transactions: The default is to allow requests
Q Proxy Transactions: The default is taken from system configuration

The proper approach to writing <proxy> layer policy depends on whether the default is to
allow or deny requests. The default proxy policy is configurable and represents the starting
point for writing policy to control proxy transactions. The default proxy policy is reported at
the top of every policy listing generated by the ProxySG.

; Default proxy policy is DENY

That line in a policy listing is a CPL comment, defining the starting point for proxy policy.

40 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 3: Content Policy Language

Content Policy Language (CPL)

Programming Language used by Blue Coat SG


VPM is a GUI for CPL

Three CPL Policy Files


Local
Central
Forward

6OLGH&RQWHQW3ROLF\/DQJXDJH &3/

Instructors Note: This slide introduces CPL and its associated files.

The VPM is the GUI for composing CPL on the ProxySG, and the generated code is stored in
read-only files. Unfortunately, there is no way to have the code written in CPL be reflected in the
VPM rules.
Three files are associated with policy processing on the ProxySG:

Local policy file: Contains most of the policy rules for a system when the VPM is not used.

Central policy file: Contains policies typically managed by Blue Coat.

Forward policy file: Contains policy rules associated with forwarding requests.

The policy rules from all sources (VPM and the three files above) are combined at any time into
one large set of rules called the current policy. You can specify the order of evaluation of all policy
sources in the Management Console.

The total combined current policy (VPM and CPL) in effect at any time can be viewed through the
Management Console.

Instructor Edition 41

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

CPL Policy Files

6OLGH&3/ILOHV3URFHVVLQJRUGHU

Instructors Note: This slide represents graphically how the different policy files interact and
how they contribute to creating the running policy that the ProxySG uses. The VPM generates
a VPM-CPL file, which cannot be edited. The easiest way to explain the roles of the Local,
Central, and Forward files is to compare them to containers for your policies. You write and
edit CPL code inside the Local and Forward files. The Central file is typically managed by Blue
Coat; however, you can create a custom Central file instead.
VPM-CPL, Local, and Central policy files can be placed in any order you want. Point out that
the last one has priority because the files and therefore the layers in them are processed
from top to bottom. The Forward policy file is always the last file to be processed. Aside from
having the policy better organized, it makes no difference in which file you write your policy.

The ProxySG allows you to create policies in four different files; each file is simply a container for
CPL code. The ProxySG combines all of the four files to create the current (running) policy.

You can define in which order the files are processed; the only exception is the Forward policy file,
which is always processed last.
The content of each file, as well as the entire running policy, can be viewed from the Management
Console.

VPM-CPL File

The VPM GUI generates the code in this file, and you cannot edit it. If you try to do so, the policies
may work incorrectly or may not work at all.

Local Policy File

This file typically contains most of the CPL code that you write. If you have developed most of
your policy rules in the VPM, this file generally will be empty. (However, there are some advanced
policies, which can be created using CPL only.) On upgrade from a CacheOS 4.x system, the Local
file will contain any filter rules configured under the old system.

42 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 3: Content Policy Language

Central Policy File

Blue Coat provides the Central policy file to help keep virus and other threat definitions
up-to-date. However, you can have the ProxySG point to a custom Central policy file instead.

If you configure your ProxySG to use it, you can set some parameters for the file through the CLI.
You can specify how frequently the ProxySG checks for a new version of the Central policy file. By
default, the appliance checks for an updated Central policy file once every 24 hours (1440
minutes). You must use the CLI to configure the update interval. You cannot configure the update
interval through the Management Console. To configure the update interval through the CLI,
enter the following command at the (config) command prompt:

SGOS#(config) policy poll-interval minutes

You can manually check whether the Central policy file has changed. You must use the CLI; you
cannot check for updates through the Management Console. To check for an updated Central
policy file through the CLI, enter the following command at the (config) command prompt:
command:

SGOS#(config) policy poll-now

The ProxySG displays a message indicating whether the Central file has changed.

Forward Policy File

This file is normally used for all forwarding policy, although you can use it to supplement any
policy created in the other three policy files. The Forward policy file was originally introduced to
contain Advanced Forwarding rules when the system is upgraded from a previous version of
SGOS (2.x) or CacheOS (4.x).
Each of the previous files may contain rules and definitions, but an empty file is also legal. (An
empty file specifies no policy and has no effect on the ProxySG.)

The final installed policy is assembled from the policy stored in the four files by concatenating
their contents. The order of assembly of the VPM, Central, and Local policy files is configurable.
The default evaluation order is VPM, Local, Central. The Forward policy file is always last.

Instructor Edition 43

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Layers

A policy layer is a CPL construct to separate


decisions
Helps control policy complexity
Each layer has the form:
<layer_type [label]>

[layer_condition][layer_properties] ...
layer_content

6OLGH&3/OD\HUV

Instructors Note: Point out that layers in CPL work the same way as layers in the VPM.
Remind the students that the VPM was created as a GUI to CPL later in the life span of the
ProxySG. More features are available in CPL than in the VPM. As in the VPM, the last layer is
the most significant. Spend some time talking about the layer guard construct, which is
currently not yet available in the VPM. You should be able to create an example, similar to the
one shown here, where the use of a layer guard is advantageous. Discuss the fact that a layer
guard offers a performance improvement; if the layer_condition is not met, the entire
layer is skipped.

A layer is a CPL construct for expressing rules for a single policy decision. Within a layer, rules are
evaluated and the first rule matched ends the processing for that layer. Multiple layers can be used
to make multiple decisions. Layers are evaluated in top-to-bottom order, like the left-to-right layer
processing in the VPM. Decisions made by later layers can override decisions made by earlier
layers.
A CPL layer contains some or all of the following elements:

Layer_type, such as <proxy> or <admin>, defines the transactions evaluated against this
policy, and restricts the triggers and properties allowed in the rules used in the layer. You must
always have at least the <layer_type> in a CPL layer.

Layer_condition, such as user=kelly, is a list of triggers, all of which must evaluate to


true before the layer content is evaluated.

Layer_properties is a list of properties that will become the default settings for those
properties for any rule matched in the layer. These can be overridden by explicitly setting a
different value for that property in a specific rule within the layer.

The layer_content is a list of rules, possibly organized in sections.

If a rule has the logical form if (condition is true) then set properties, a layer has the form:

44 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 3: Content Policy Language

if (layer_condition is true) then


{
if (rule1_condition is true) then set layer_properties then set rule1
properties
else if (rule2_condition is true) then
set layer_properties then set rule2 properties
else if (rule3_condition is true) then
set layer_properties then set rule3 properties
...
}

Collectively, layer_condition and layer_properties are often referred to as layer guard


expressions. Often, the same set of conditions or properties appears in every rule in a layer. The
following is an example of a specific user group for which a number of individual cases exist
where some things are denied:

<Proxy>
group=general_staff
group=general_staff
group=general_staff
; etc.
group=general_staff

url.domain=competitor.com/jobs deny
url.host=bad_host deny
condition=whatever deny
allow

You can factor out the common elements into guard expressions. Notice that the common
elements are group=general_staff and deny. The following is the same policy, expressed as a
layer employing a guard expression:

<Proxy>1 group=general_staff2 deny3


url.domain=competitor.com/jobs
url.host=bad_host
condition=whatever
; etc.
allow

Note that the explicit allow overrides the deny specified in the layer guard. This is an instance of a
rule-specific property setting overriding the default property settings specified in a guard.
Note:

The layer guard construct is not yet available in VPM.

1. This is the layer_type


2. This is the layer_condition
3. This is the layer_property

Instructor Edition 45

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Sections

Rules in layers can have one or more sections

A section consists of a section header followed


by a list of rules
A section has the form:

[section_type [label]]

[section_condition][section_properties]
section_content

6OLGH&3/VHFWLRQV

Instructors Note: There are two main reasons for creating sections within a layer:
performance and structural organization. The most significant benefit of using sections is the
performance improvement that you have when you use long lists of URLs to define a
condition. The URLs listed in the [url] section are loaded by ProxySG as a hashed table;
comparing hashed signatures is much faster than doing string matching between the rule
condition and the requested URL. Focus some time on the example at the end of this section.
In the lab you will show your students how the Blue Coat Central policy file is organized. There
are several sections in that policy file. Review it ahead of time and be ready to explain it line by
line. The file is available at https://download.bluecoat.com/release/SG4/files/CentralPolicy.txt

A section is a way of grouping rules that have like syntax. Sections consist of a section header that
defines the section type, followed by policy rules. The section type determines the allowed syntax
of the rules and an evaluation strategy.
Four sections types are supported in a standard CPL file:

[url]

This section type is used to group a number of rules that test the URL. The [url] section
restricts the syntax of rules in the section. The first token on the rule line is expected to be a
pattern appropriate to a url= trigger. The trigger name is not included. Rules in [url]
sections are evaluated through hash table techniques, with the result that the time taken is not
dependent on the number of rules in the section. [url] sections are not allowed in <Admin>
or <Forward> layers.

[url.domain]

The [url.domain] section is used to group a number of rules that test the URL domain. The
[url.domain] section restricts the syntax of rules in the section. The first token on the rule
line is expected to be a pattern appropriate to a url.domain= trigger. The trigger name is
not included. (The [url.domain] section replaces the [domain-suffix] section used in
previous versions of CPL.) Rules in [url.domain] sections are evaluated through hash table
techniques, with the result that the time taken is not dependent on the number of rules in the
section. [url.domain] sections are not allowed in <Admin> or <Forward> layers.

46 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 3: Content Policy Language

[url.regex]

The [url.regex] section is used to test the URL. The [url.regex] section restricts the
syntax of rules in the section. The first token on the rule line is expected to be a pattern
appropriate to a url.regex= trigger. The trigger name is not included. The
[url.regex] section replaces the [Regex] section used in previous versions of CPL. Rules
in [url.regex] sections are evaluated sequentially, top to bottom. The time taken is
proportional to the number of rules in the section. [url.regex] sections are not allowed in
<Admin> or <Forward> layers.

[server_url.domain]

The [server_url.domain] section is used to test the domain of the URL used to fetch
content from the origin server. The [server_url.domain] section restricts the syntax and
rules in the section. The first token on the rule line is expected to be a pattern appropriate to a
server_url.domain= trigger. The trigger name is not included.
[server_url.domain] sections contain policy rules very similar to [url.domain]
sections except that these policy rules test the server_url, which reflects any rewrites to the
request URL. Rules in [server_url.domain] sections are evaluated through hash table
techniques, with the result that the time taken is not dependent on the number of rules in the
section. [server_url.domain] sections are allowed only in <Exception> or <Forward>
layers.

To better understand who to use sections, imagine that you have a policy constructed in a way
similar to the example below:

<Proxy>
url.domain=abc.com/sports deny
url.domain=nbc.com/athletics deny
; etc, suppose its a substantial list
;
url.regex="sports|athletics" access_server(no)
url.regex="\.mail\." deny
; etc
;
url=www.bluecoat.com/internal group=!bluecoat_employees deny
url=www.bluecoat.com/proteus group=!bluecoat_development deny
; etc
This can be recast into three sections:

<Proxy>
[url.domain]
abc.com/sports deny
nbc.com/athletics deny
; etc.
;
[Rule]
url.regex="sports|athletics" access_server(no)
url.regex="\.mail\." deny
;
[url]
www.bluecoat.com/internal group=!bluecoat_employees deny
www.bluecoat.com/proteus group=!bluecoat_development deny
Note:

The performance advantage of using the [url], [url.domain], or


[server_url.domain] sections is measurable when the number of URLs being
tested reaches roughly 100. Certainly for lists of several hundred or thousands of
URLs, the performance advantage is significant.

Instructor Edition 47

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

CPL and VPM Layers

VPM

CPL

Description

Web Authentication

<proxy>

User authentication and allowed triggers

Web Access

<proxy>

Access control and general transaction


testing

Web Content

<cache>

Object store behavior modification and


virus scanning

Forward

<forward>

Request destination control

Admin Authentication

<admin>

User authentication when accessing the


proxys administrative console

Admin Access

<admin>

Access control and Read/Write privilege


control for the proxys administrative
console

SSL Intercept

<ssl-proxy>

Determines whether to tunnel or intercept


HTTPS traffic

SSL Access

<ssl>

Determines the actions for intercepted


HTTPS traffic

N/A

<exception>

Control of exception responses including


header set/rewrite/delete

6OLGH&3/DQG930OD\HUV

Instructors Note: Make sure the students understand that not all CPL layer types are
available in VPM. Also VPM splits some layers, which are the same layer in CPL. Mention that
this course does not cover the <exception>, <dns-proxy>, and Socks Authentication
layers as they are seldom used.

In CPL you have seven layer types. This is fewer than what is available in the VPM; however,
there is no loss of functionality. For instance, all the triggers and actions available in the Web
Authentication and Web Access Layers in the VPM are covered under the <proxy> layer in CPL.
Everything that you learned about layers in the VPM applies to CPL layers, including the order in
which they are processed.
Slide 3-5 is a useful reference that allows you to transition easily from VPM-based to CPL-based
rules. In most cases, you will be using <proxy> layers. Below is a summary description of each of
the CPL layers.

<proxy>

Used to list policy rules that control access to proxy services configured on the ProxySG,
which include user authentication and authorization requirements, time of day restrictions,
and content filtering.

<cache>

Used to list policy rules that are evaluated during a cache or proxy transaction.

<forward>

These layers are evaluated only when the current transaction requires an upstream
connection.

<admin>

Used to define policy rules that control access to the Management Console and command line
interface (CLI).

<SSL-Intercept>

48 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 3: Content Policy Language

This layer lists the triggers and properties that define the interception conditions for SSL
connections. In essence, in this layer you define which HTTPS transactions are going to be
monitored. Unless you have at least one policy in this layer, no HTTPS transaction will be
intercepted. If the transaction is not being intercepted the policies in the <SSL> will not apply.

<SSL>

This layer lists the triggers and properties that apply to the connections that are intercepted in
the SSL-Intercept layer.

<exception>

Exception layers are evaluated when an exception property is set, forcing transaction
termination. Policy in an exception layer gives administrators a final chance to modify the
properties (such as headers) of the response (exception) object, just as they get a chance to
modify the properties of an object returned from the origin server or from cache.

<DNS-proxy>

When a client connects to one of the DNS-Proxy service ports configured on the ProxySG, a
DNS-Proxy transaction is created to cover both the request and its associated response. A
DNS-Proxy transaction evaluates policy in <DNS-Proxy> layers only. Policy in other layers
does not affect DNS-Proxy transactions. These layers define policy controlling DNS-Proxy
transactions. Only DNS-Proxy transactions are evaluated against <DNS-Proxy> layers.

Socks Authentication (VPM only)

Determines the method of authentication for accessing the proxy through SOCKS. The actions
and triggers available in this VPM-only layer are available under the <proxy> layer in CPL.

Instructor Edition 49

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Content Policy Language (CPL)


CPL is a combination of:
Rules

Triggers

Properties

Definitions
Actions

6OLGH&RQWHQW3ROLF\/DQJXDJH &3/

Instructors Note: Slide 3-6 lists the components of CPL that are covered in subsequent
pages. Try to avoid too much discussion until the material is covered on the following pages.

The components listed in Slide 3-6 are the building blocks of CPL. They will be discussed in the
next few pages.

It is important that you learn what each of these building blocks does and in which contexts each
can be used.

50 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 3: Content Policy Language

Rule

A policy rule consists of a condition and some


number of property settings
A rule can match or miss

Condition is a Boolean combination of trigger


expressions

6OLGH3ROLF\UXOHV

Instructors Note: Rules are fundamental to enforcing policy on our system. Tell students that
in the next few pages they will see the relationship between the VPM rules used throughout
the class and CPL rule syntax.

Rules are crucial to enforcing policy on the ProxySG system. Remember that rules are contained
within layers. Remember also that the first rule in the layer that matches stops further rule
processing in that layer. Processing then proceeds to the next layer, if any.
In VPM, rules have sources, destination, times, actions, and so forth. The same is true of rules
expressed in CPL.

On the following pages you will learn about conditions, triggers, and properties. Be aware that
conditions containing triggers can become very complex, so care is needed in constructing them.
A sample rule:

<proxy>

category = Adult/Mature Content DENY

Instructor Edition 51

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Triggers

Request (url=)

Response (response.header.Content-Type=)
User (user=, group=)
System state (time=)

6OLGH&3/WULJJHUV

Instructors Note: Slide 3-8 begins the discussion of triggers. Have some sample triggers
ready to show the class in response to questions. The Content Policy Language Guide
contains many examples.

A condition is a Boolean combination of trigger expressions. Triggers are individual tests that can
be made against components of the request (url=), response (response.header.Content-Type=),
related user (user=, group=), or system state (time=).
With a few notable exceptions, triggers test one aspect of request, response, or associated state
against a Boolean expression of values.
The condition is true only if each one of the trigger expressions is true.

CPL triggers have the form trigger_name=pattern_expression.

CPL properties have the form property_name(setting), except for a few imperative gestures,
such as allow and deny.

The text in policy rules is case-insensitive, with a few exceptions that will be identified later.
Triggers are used in rules and in condition definitions.

52 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 3: Content Policy Language

Triggers HTTP

Protocol

Host

Port

Path

File

Extension

Query

http://www.bluecoat.com:81/path.path_path/demo_file.html?sess=1234

url.scheme=

url.host=

url.host.regex=

url.port=

url.path=

url.query=

url.path.regex=

url.query.regex=

url.address=

url.extension=

url.domain=

url=

url.regex=

6OLGH&3/WULJJHUV+773

Instructors Note: Please point out ALL possibilities for tests that can be part of a trigger.
Describe how the url= trigger can match on anything from the protocol scheme to the
query string. Define the difference between url= and url.regex= as described in the table
below. In particular, describe how url.substring tests if the string pattern is a substring of
the URL or component; the substring need not match on a boundary (such as a subdomain or
path directory) within a component.

Carefully note all the components of an HTTP request address that can be used in a trigger test.
You can write trigger expressions to construct very specific conditions in our CPL code.

Note the numerous regex components that allow us to fully use the power of regular
expressions in determining whether a trigger test matches or not. A separate chapter of this book
discusses regular expressions in detail. Regular expressions allow us to match many different
combinations within a URL.
CPL triggers have the form trigger_name=pattern_expression.
For example, you can create a trigger like the one shown below:

url.domain=example.com

Table 3-1: Comparing CPL statements


URL Accessed

CPL Statement

Policy

http://www.bluecoat.com

url=www.bluecoat.com

MATCH

http://www.bluecoat.com

url=bluecoat.com

MISS

http://www.bluecoat.com

url.regex=bluecoat.com

MATCH

http://www.bluecoat.com

url.substring=bluecoat.com

MATCH

http://www.bluecoat.com

url.domain=bluecoat.com

MATCH

Instructor Edition 53

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Properties

6OLGH&3/SURSHUWLHV

Instructors Note: Spend some time defining transactions and giving the students an idea of
the many applications that use the transaction concept.

You learned about transactions in the chapter on System Architecture. A transaction is defined as a
unit of work that cannot be interrupted and must succeed or fail as a unit. Transactions are
considered to be a set of operations that are executed as though they were a single operation with
all or none being the final result of the transaction.
Properties are settings that control transaction processing, such as deny, or the handling of the
object, such as cache(no), indicating that the object is not to be cached locally.

At the beginning of a transaction, all properties are set to their default values. As the policy is
evaluated in sequence, rules that match might set a property to a particular value.

A property retains the final value setting when evaluation ends, and the transaction is processed
accordingly.
Properties that are not set within the policy maintain their default values.

CPL properties have the form property_name(setting), except for a few imperative gestures
such as allow and deny.

54 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 3: Content Policy Language

Named Definitions
Subnet Definitions

Define a list of IP addresses or IP subnet masks


that can be used to test

Condition Definitions

Include any triggers that are legal in the layer


referencing the condition.

Allow for arbitrary Boolean combinations of trigger


expressions
condition= trigger

6OLGH&3/QDPHGGHILQLWLRQV

Instructors Note: Discuss the examples contained in the student section of this page. You
should create and demonstrate a simple CPL policy, which allows or blocks users based on a
subnet definition.

There are various types of named definitions. Each definition is given a user-defined name that is
then used in rules to refer to the definition.
Subnet definitions are used to define a list of IP addresses or IP subnet masks that can be used to
test any of the IP addresses associated with the transaction. An example is the clients address or
the requests destination address.
Here is an example of a subnet definition:

define subnet corporate_subnet


10.10.12.0/24
end

Condition definitions can include any triggers that are legal in the layer referencing the condition.
The condition= trigger is the exception to the rule that triggers can test only one aspect of a
transaction.

Since conditions definitions can include other triggers, condition= trigger can test multiple
parts of the transaction state. Also, condition definitions allow for arbitrary Boolean combinations
of trigger expressions.
Here is an example of a condition definition:

; Deny access to client 1.2.3.4 for any http request through proxy port
;8080.
define condition QA

client.address=1.2.3.4

proxy.port=8080

end

Instructor Edition 55

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Named Definitions
Category Definitions

Extend vendor content categories


Tested using category= trigger

Action Definitions

Are turned on/off for a transaction using action()

Transformer Definitions

Specify a transformation to an HTTP response.


url_rewrite, active_content, javascript

6OLGH&3/QDPHGGHILQLWLRQV

Instructors Note: This slide continues the discussion of named definitions; as before discuss
the examples contained in the students section.

Category definitions are used to extend vendor content categories or to create your own. These
categories are tested (along with any vendor-defined categories) using the category= trigger.

An action takes arguments and is wrapped in a named action definition block. Actions are turned
on or off for a transaction through setting the action( ) property. The action property has
syntax that allows for individual actions to be turned on and off independently. When the action
definition is turned on, any actions it contains operate on their respective arguments.
A transformer definition is a kind of named definition that specifies a transformation that is to be
applied to an HTTP response. There are three types: url_rewrite definitions,
active_content definitions, and javascript definitions.

Here is an example of a category named definition:

define category Grand_Canyon


kaibab.org

www2.nature.nps.gov/ard/parks/grca/

end

Here is an example of an action named definition:

<cache>

url.domain=!my_internal_site.com action.scrub_private_info(yes)

define action scrub_private_info

set( request.header.From, "" )

set( request.header.Referer, "" )

end

Here is an example of a transformer named definition:


define url_rewrite ijk_portal

56 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 3: Content Policy Language

rewrite_url_substring "http://www.ijk.com/" "http://www.server1.ijk.com/"

end

Instructor Edition 57

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Actions

Two types of Actions in CPL

Properties change proxy configuration for this


transaction
Defined Actions change transaction

Common Properties

deny
allow
access_log()
authenticate()

6OLGH&3/DFWLRQV

Instructors Note: This slide gives a brief introduction to actions in CPL. Remind students of
the form of actions used in VPM rules.
An action takes arguments and is wrapped in a user-named action definition block.

When the action definition is called from a policy rule, any actions it contains operate on their
respective arguments. Within a rule, named action definitions are enabled and disabled using the
action( ) property.

Actions appear only within action definitions and they cannot appear in <Admin> layers.

Actions take the following general form: action( argument1, ...)


The allowed syntax for action arguments depends on the action.
There are four types of arguments:

String

Enumeration

Regular expression

Variable substitution

58 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 3: Content Policy Language

Actions

Common Defined Actions

append (header_name, text_string)


delete (header_name)

delete_matching (header_name, regex)


redirect (HTTP_response_code, regex,
new_destination_url)

rewrite (header, regex, replacement)

rewrite (url[.host], regex, replacement)


set (header_name, header_value)

6OLGH&3/DFWLRQV

Instructors Note: This slide gives several examples of defined actions. Mention their
similarities with functions and methods in normal programming languages.

Note that each defined action takes a special set of arguments. Here are more examples:

append()

Appends a new component to the specified header.

delete()

Deletes all components of the specified header.

delete_matching()

Deletes all components of the specified header that contain a substring matching a
regular-expression pattern.

redirect()

Ends the current HTTP transaction and returns an HTTP redirect response to the client by
setting the policy_redirect exception. Use this action to specify an HTTP 3xx response code,
optionally set substitution variables based on the request URL, and generate the new Location
response-header URL after performing variable substitution.

rewrite()

Rewrites the request URL, URL host, or components of the specified header if it matches the
regular-expression pattern. This action is often used in conjunction with the URL rewrite form
of the transform action in a server portal application. There are several forms. Please check
action() reference section of the Content Policy Language Guide.

set()

Sets the specified header to the specified string after deleting all components of the header.

Instructor Edition 59

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Define Actions Example

define action removeUA


delete(request.header.user-agent)
end

<Proxy>
; Remove the user-agent header from all
HTTP requests
action.removeUA(yes)

6OLGH'HILQHDFWLRQVH[DPSOH

Instructors Note: Use this slide to explain the syntax used to create a define action. The
items in bold are the required elements in CPL, the ones in italics represent an arbitrary name
that you can use. The other text is standard CPL code. Point out that there is not a statement
like action.removeUA(no). The reason is simple: If you do not want an action to execute,
you need to create a proper trigger to determine when it should indeed be invoked. The policy
is rather simple and should not be used as it may interfere with the functionalities of some
OCS. Discuss with the students some better way of masking or reducing the amount of
information made available in the user-agent header.

This slide shows a simple example where you have created a defined action. The objective of the
code is to remove completely the user-agent header from any HTTP request made by the
clients. You can improve on this policy; the text here is just for your reference.

Before you can invoke an action, you need to create a defined action with the following structure:

define action action_name


actions...
end

The parameter action_name can be any alphanumeric string (without spaces); you should use a
name which closely describes what the action is going to do.
Once you have declared the action, you can invoke its execution from anywhere in the CPL code;
obviously you cannot invoke it from a layer where the action is not valid. You can control when
the action is actually executed, using any of the triggers available for that layer. The construct to
invoke the execution of a define action is:

action.action_name(yes)

60 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 3: Content Policy Language

Special Characters

user="John Doe" ; value contains a space

deny( "You dont have access to that page!" ) ;


several special chars
user="john.doe" ; quotes not required,
Long lines can be split using \

6OLGH6SHFLDOFKDUDFWHUVLQ&3/

Instructors Note: There is a complete list of special characters in the Content Policy
Language Guide.

Certain characters are considered special by CPL and have meaning as punctuation elements of
the language. For example, = (equal) separates a trigger name from its associated value, and blank
space separates expressions in a rule.
To use a value that contains one of these characters, the value must be quoted with either single ()
or double (") quotation marks, so that the special characters are not interpreted as punctuation.
Text within single quotation marks can include any character other than a single quotation mark.
Text within double quotation marks can include any character other than a double quotation
mark.

Instructor Edition 61

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Synonyms

deny.unauthorized

exception(authorization_failed)

force_deny.unauthorized

force_exception(authorization_failed)

deny

exception(policy_denied)

6OLGH&3/V\QRQ\PV

Instructors Note: Slide 3-17 shows different ways to specify the same operation.

Policy listings are normalized in several ways. First, condition and action definitions that may
appear anywhere in the source will be grouped following the policy rules. Second, the order of the
conditions and properties on a rule may change. This is because the CPL compiler always puts a
deny or allow at the beginning of the rule and orders conditions to optimize evaluation. Finally,
several phrases are synonyms for phrases that are preferred.
In Slide 3-17, the main bullet points show the preferred usage of three operations. The sub-bullets
show the synonyms. For example, deny.unauthorized is the preferred form, and
exception (authorization_failed) is the synonym.

62 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 3: Content Policy Language

Categories: Solutions with Policy

Policy to allow text and block images

<proxy>
category=Adult/Mature Content
url.extension=(jpg, gif) DENY
category=Adult/Mature Content
response.header.content-type=image DENY
category=Adult/Mature Content ALLOW

Deny Sports during work hours

<proxy>
category=Sports time=0800..1800 DENY

6OLGH&DWHJRULHVVROXWLRQVZLWKSROLF\

Instructors Note: You need to use Slide 3-18 to start a conversation with the students. The
top bullet point contains some questionable policies. Ask your students the following
questions:

1) Based on the rules that you see in this slide, does the ProxySG have a default policy of allow
or deny? (ANSWER: deny)

2) Do you really need the policy


category=Adult/Mature Content url.extension=(jpg, gif) DENY
based on the fact the following policy is:
category=Adult/Mature Content response.header.content-type=image
DENY (ANSWER: Not really; the second rule blocks objects based on the image MIME type. A
file with the extension .jpg or .gif will most likely have the MIME type set to image/jpg and
image/gif respectively.)

The first <proxy> layer contains three policies. The idea is to block all .jpg,.gif, and
MIME-type images. The last rule in the first layer allows all traffic from Adult/Mature sites;
however, because of the previous two rules, all images are blocked4.

The rule in the second <proxy> layer simply denies access to sports-related sites during work
hours (8 a.m. to 6 p.m.) Note that time is always expressed using military time (24-hour clock).

Finally, it is worth nothing that the spaces between triggers should be interpreted as the logical
operator AND while the space before the action clause should be interpreted as THEN keyword.
There is an understood IF statement before each rule. So the rule would actually be interpreted as:

IF category=Adult/Mature Content AND url.extension=(jpg, gif)


THEN DENY

etc...

4. Note that flash and other video file formats are not blocked.

Instructor Edition 63

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Categories: Solutions with Policy

Authenticate a site for a work section

<proxy>
category=HR authenticate(HR_Realm)

Deny Access if site is not categorized

<proxy>
category=(drugs, violence, none) DENY

6OLGH&DWHJRULHVVROXWLRQVZLWKSROLF\

Instructors Note: Slide 3-19 contains more examples. Point out that because the category is
a valid trigger in an authentication rule, the categorization is done before authentication.
In the second example, point out how the round parentheses and the comma can be used to
construct a logical OR statement.

The first layer in Slide 3-19 shows how you can authenticate based on a destination. Users trying
to access sites categorized as HR will be authenticated in the HR_Realm realm.
The first example should be interpreted

IF category = HR

THEN authenticate

The second example should be interpreted

IF category = drugs OR violence OR none


THEN deny.

The commas should be interpreted as the logical operator OR in the rule.

64 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 3: Content Policy Language

CPL Substitutions

Rewrite the URL request

Modify HTTP request headers


Modify HTTP response

Substitutions have the form:


$(name)

6OLGH&3/VXEVWLWXWLRQV

Instructors Note: CPL substitutions can be used for a variety of purposes. Explain with some
examples where policy substitution can be used. A lab follows the next slide, which continues
the discussion of CPL substitutions, so be sure to introduce some of the key concepts for that
lab.

CPL Substitutions are variables that are replaced by text strings appropriate to the current policy
transaction at execution time.

The actions used to rewrite the URL request or to modify HTTP request headers or HTTP response
headers often need to reference the values of various elements of the transaction state when
constructing the new URL or header value.
CPL provides support for various substitutions, which will expand at runtime to the indicated
transaction value.
Substitutions have the form: $(name)

For example, the substitution $(user) expands to the authenticated username associated with
the transaction. If policy did not require that user to authenticate, the substitution expands to an
empty string.
Substitutions can also be used directly in the values specified to some CPL properties, such as
when setting text in a message that will be displayed to users.

Instructor Edition 65

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Common CPL Substitutions

$(url)
$(url.host)
$(client.address)
$(user)
$(proxy.name)

=> client requested URL


=> URL hostname
=> Requesting clients IP
=> Authenticated username
=> Proxys hostname

Example:
set(response.header.Referer, $(url.host))

6OLGH&3/VXEVWLWXWLRQV

Instructors Note: Slide 3-21 lists some of the most commonly used CPL substitutions.

In each case, the substitution on the left is defined by the text on the right. For example, $(url) is
the substitution for client requested URL.

Substitution cannot be used in all actions or CPL gestures. You can use most of the substitutions to
create custom notification pages.

66 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 3: Content Policy Language

Instructors Notes for Configuring the Central Policy File Lab


Overview

Configuring the Blue Coat SG appliance to retrieve the Blue Coat Central policy file every
hour.

Computer Hardware and Software Requirements


Table 3-1: Requirements for the Instructor
Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Table 3-1: Requirements for Students


Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

F PuTTY

F Release 0.60

Instructor Edition 67

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

68 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 3: Content Policy Language

Instructors Notes for Creating Sample CPL Policy Lab


Overview

In this lab, you create the following HR-approved policy for company XYZ, Inc.:

Users are authenticated against an IWA realm, even when they are going to be blocked.

Everybody is blocked from accessing hacking sites, with the exception of the IT staff.

Everybody is blocked from accessing pornography Web sites.

When users are blocked, a message appears referring them to an acceptable usage policy page.

Computer Hardware and Software Requirements


Table 3-1: Requirements for the Instructor
Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Table 3-1: Requirements for Students


Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Instructor Edition 69

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

70 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 3: Content Policy Language

Instructors Notes for CPL Policy Using a Flowchart Lab


Overview

You want to allow employees in your company to access news sites, but only one page each day
for each site. For example, each employee can read one page from www.cnn.com, one page from
www.latimes.com, and one page from www.foxnews.com.; however, when employees try to pass
the limit, access is blocked.

Computer Hardware and Software Requirements


Table 3-1: Requirements for the Instructor
Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Table 3-1: Requirements for Students


Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

F Live HTTP Headers

F version 0.13.1

Instructor Edition 71

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

72 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 4: Regular Expressions

Estimated Lesson Time: 20 minutes

Instructors Note: This section describes regular expressions, which many students have
some experience using. Students will find regular expressions very useful in writing policy.
Students also may want to try software that creates and tests regular expressions, such as
Regex Coach and RegexBuddy, both available over the Internet.

Before you start the session, ask your class how familiar are they with regular expressions
(regex). If they are not very familiar with them you may want to supplement the chapter with
additional samples. Make sure that you use examples based on some hands-on experience
writing CPL code.
There are several sample policies in the text of this chapter. Make sure that you cover all of
them and also demonstrate them on your proxy.

The origin of regular expressions lies in automata theory and formal language theory (both part of
theoretical computer science). These fields study computation models (automata) and ways to
describe and classify formal languages. In the 1940s, Warren McCulloch and Walter Pitts described
the nervous system by modeling neurons as small simple automata. In the 1950s and 1960s, the
mathematician Stephen Kleene described these models using his mathematical notation called
regular sets.
In the 1970s, Ken Thompson built regular expression notation into the editor QED, into the
UNIX editor ed and into grep. Ever since that time, regular expressions have been extensively
used in UNIX and UNIX-like utilities such as expr, awk, Emacs, vi, lex, and Perl. Many students of
computer science learned to use regular expressions from these tools.
Henry Spencer wrote regex from which Perl regular expressions were derived. Philip Hazel then
developed pcre (Perl Compatible Regular Expressions), which attempts to closely mimic Perl's
regular expression functionality, and is used by many modern tools such as PHP and Apache.

A regular expression (or regex or RE) is a pattern that is matched against a subject string from left to
right. Most characters stand for themselves in a pattern, and match the corresponding characters
in the subject. The power of regular expressions comes from the ability to include alternatives and
repetitions in the pattern. These are encoded in the pattern by the use of metacharacters, which do
not stand for themselves but instead are interpreted in some special way.

Regular expressions can contain both special and ordinary characters. Most ordinary characters,
like A, a, or 3, are the simplest regular expressions; they simply match themselves. You can
concatenate ordinary characters, so last matches the characters last.
Note:

In this chapter, regular expressions are printed in a Courier font, usually without
quotes, and strings to be matched are in single quotes.

Some characters, like | (vertical bar or pipe) or ( (parenthesis), are special. Special characters,
called metacharacters, either stand for classes of ordinary characters, or affect how the regular
expressions around them are interpreted.

Blue Coat regex differ from the Perl regex. The list below addresses some of the main differences.

Normally space matches space, formfeed, newline, carriage return, horizontal tab, and
vertical tab. Perl 5 no longer includes vertical tab in its set of white-space characters. The \v
escape that was in the Perl documentation for a long time was never in fact recognized.
However, the character itself was treated as white space at least up to 5.002. In 5.004 and 5.005
it does not match \s.

Instructor Edition 73

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

RE ENGINE does not allow repeat quantifiers on lookahead assertions. Perl permits them, but
they do not mean what you might think. For example, (?!a){3} does not assert that the next
three characters are not a. It just asserts that the next character is not a three times.

Capturing subpatterns that occur inside negative lookahead assertions are counted, but their
entries in the offsets vector are never set. Perl sets its numerical variables from any such
patterns that are matched before the assertion fails to match something (thereby succeeding),
but only if the negative lookahead assertion contains just one branch.

Though binary zero characters are supported in the subject string, they are not allowed in a
pattern string because it is passed as a normal C string, terminated by zero. The escape
sequence \0 can be used in the pattern to represent a binary zero.

The following Perl escape sequences are not supported: \l, \u, \L, \U, \E, \Q. In fact these
are implemented by Perls general string handling and are not part of its pattern-matching
engine.

The Perl \G assertion is not supported as it is not relevant to single pattern matches.

RE ENGINE does not support the (?{code}) construction.

There are at the time of writing some oddities in Perl 5.005_02 concerned with the settings of
captured strings when part of a pattern is repeated. For example, matching aba against the
pattern /^(a(b)?)+$/ sets $2 to the value b, but matching aabbaa against
/^(aa(bb)?)+$/ leaves $2 unset. However, if the pattern is changed to
/^(aa(b(b))?)+$/ then $2 (and $3) get set. In Perl 5.004 $2 is set in both cases, and that is
also true of RE ENGINE.

Another as yet unresolved discrepancy is that in Perl 5.005_02 the pattern


/^(a)?(?(1)a|b)+$/ matches the string a, whereas in RE ENGINE it does not. However,
in both Perl and RE ENGINE /^(a)?a/ matched against a leaves $1 unset.

RE ENGINE provides some extensions to the Perl regular expression facilities: Although
lookbehind assertions must match fixed length strings, each alternative branch of a
lookbehind assertion can match a different length of string. Perl 5.005 requires them all to have
the same length.

Note:

When regular expressions are used to match a URL, a space character matches a %20 in
the request URL. However, a %20 in the regular-expression pattern will not match
anything in any request URL, because "%20" is normalized to " " in the subject string
before the regex match is performed.

74 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 4: Regular Expressions

Regular Expressions

Regular expressions compare a substring to a


target string

NET

OATH

OTH

6OLGH5HJXODUH[SUHVVLRQV

Instructors Note: This is a very simple introduction to regular expressions. If you have
students who come from a database background they will expect some sort of wild character
before and after the pattern, in order to match it anywhere in the reference string. For instance,
it is common for student to expect *NET* as the syntax to match NET anywhere it appears.
Regular expressions work with the opposite logic. By default, the pattern is matched anywhere
it appears in the reference string. Make this point very clear.
The slide shows a reference string and three different patterns. The reference string is
onetwothreefour and the patterns are: net, oath, and oth.

You can see that only two of the pattern exists in the reference string. When a pattern exists in the
reference string, you have a match and the regular expression assume the boolean value of TRUE.

Lets assume that you are going to the URL


http://www.bluecoat.com/resources/training/ and then you are going to the URL
http://training.bluecoat.com. You have the the follwing policy on your Blue Coat SG:

<proxy>
url.regex = training DENY

Both URL requests will mach the policy and will be denied. The URL is the reference string and
the word training is the pattern. The pattern matches both reference string.
The following slides cover additional regex syntax, which allows you to better define how to
match the pattern in the reference string.

Instructor Edition 75

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Character Classes
. (period)

Matches any character

\w

Matches a word. A word is anything made of letters,


numbers, and the _ (underscore)

\s

Matches a white space

6OLGH*HQHULFFKDUDFWHUFODVVHV RUW\SHV

Instructors Note: This slide introduces generic character classes (or types). Spend some
time talking about the dot. It matches any character, but only one occurrence of a character.
The other classes are shown here mostly for reference purpose only; they are seldom used in
writing CPL code.

The most important and most frequently used character class is the dot. A dot in the pattern
matches any one character in the subject, including a non-printing character, but not (by default)
newline. (Note that newlines should not be detected when using regular expressions in CPL.) The
handling of dot is entirely independent of the handling of circumflex and dollar, the only
relationship being that they both involve newline characters. Dot has no special meaning in a
character class.
There are several generic character classes (or types) used in regular expressions.

. matches any character except a newline (which is not matched in CPL)

\d matches any decimal digit

\D matches any character that is not a decimal digit

\s matches any white space character

\S matches any character that is not a white space character

\w matches any word character, which is any letter or digit or the underscore character

\W matches any non-word character

Consider the two URLs, http://www.bluecoat.com and http://wwwwbluecoat.com. Consider a


policy like the one below:

<proxy>
url.regex=www.bluecoat.com

The policy matched both URL as the dot in the regex matches any character.

76 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 4: Regular Expressions

Using \
\.com

Need to use the \ because . is a special character

\.com

Matches anything with .com in it


Matches www.bluecoat.com

Matches www.bluecoat.com.sg

6OLGH8VLQJEDFNVODVK ? DVDQHVFDSHFKDUDFWHU

Instructors Note: Continue the conversation from the example in the student section
mentioned in the previous slide. Discuss how you need to have an operator, which tells the
regex engine when to interprete a metacharacter as literal or as an operator.

Regular expressions assign special meaning to several characters. These characters are called
metacharacters to indicate that they are interpreted in some special way when used in the regular
expressions.

When you need to use one of these metacharacters literally in a regular expression, you must place
a backslash (\) in front of it. This allows you to use it without its special meaning. In the example
in Slide 4-3, you want to use the dot or period as is, without its metacharacter value of matching
any single character.

The backslash is called the escape character because it allows the character that follows it to escape
from the world of metacharacters.
For example, analyze the two layers below and note how the dot as a different role:

<proxy>
url.regex=www\.bluecoat\.com ALLOW
<proxy>
url.regex=blueco.t ALLOW

The first policy matches a URL, which contains the string www.bluecoat.com; the second poliy
matches any URL, which containt blueco followed by any one character and a t.

Instructor Edition 77

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Using ^ and $
^www

Matches anything starting with www


Matches www.bluecoat.com
Does not match bluecoat.www.com.sg

\.com$

Matches anything ending with .com


Matches www.bluecoat.com
Does NOT match www.bluecoat.com.sg

6OLGH8VLQJADQG

Instructors Note: This slide describes two special characters, which you will use often when
writing CPL code. Discuss the two following terms: anchored and unanchored. Anchored
refers to a regex, which is trying to match the pattern in a particular part of the reference string,
either at the beginning of the end. Unanchored is a normal regex; this is the default behavior.
In CPL all regex patterns are unanchored, unless otherwise noted. There are some exceptions
mentioned in the student section of the slide, which you should discuss.

In a regular expression you can use the circumflex (^) to match the start of a line and the dollar
sign ($) to match the end of a line.

The circumflex does not need not be the first character of the pattern if a number of alternatives
are involved; however, it should be the first thing in each alternative in which it appears if the
pattern is ever to match that branch. If all possible alternatives start with a circumflex that is, if
the pattern is constrained to match only at the start of the subject it is said to be an anchored
pattern. (There are also other constructs that can cause a pattern to be anchored.)

A dollar sign character is an assertion that is true only if the current matching point is at the end of
the subject string, or immediately before a newline character that is the last character in the string
(by default). The dollar sign need not be the last character of the pattern if a number of alternatives
are involved; however, it should be the last item in any branch in which it appears. The dollar sign
has no special meaning in a character class. Regular expressions use two metacharacters to
represent the beginning and end of the string pattern.
The following policy, for example, is looking for a URL ending with anything but .html, and
denying it.

<proxy>
url.regex=!\.html$ DENY

The policy is of very limited applicability but offers you an idea on how you can create more
powerful CPL code.
Important: Regular expressions in the CPL actions redirect(), rewrite(), and
rewrite() are anchored.

78 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 4: Regular Expressions

Using *, +, and ?
a*

Matches if the target contains zero or more a


bluecoat* matches www.bluecoatttc.com

a+

Matches if the target contains one or more a


x+ matches www.xxx.com

a?

Matches if the target contains zero or one a


blue-?coat matches bluecoat or blue-coat

6OLGH8VLQJ DQG"

Instructors Note: This slide introduces additional metacharacters, which allow you to mach
characters many times. You will use all of the in writing CPL code. You should have some
additional examples ready to discuss with the students. At this point you have enough
information to start doing some interactive excercises.

The regual expression engine allows you to match patterns when they repeat from zero to any
number of times. You can use the metacharacters described below to create complex policies. Note
that the metacharacter affects only the character immediately to the left of itself. If you want the
metacharacter to affect more elements in the pattern, you need to use grouping, which is described
later in this chapter.

Asterisk (*)

The asterisk (*) causes its resulting regular expression to match zero or more repetitions of the
preceding regular expression.

Example: bluecoat* matches www.bluecoat.com. The asterisk operates only on the letter t
because it is the smallest previous regular expression. No grouping was indicated within the
string bluecoat.

Plus Sign (+)

The plus (+) causes its resulting regular expression to match one or more repetitions of the
preceding regular expression.

Example: x+ matches www.xxx.com. It does not match www.bluecoat.com. The purpose of the
plus sign in this example is to match as many consecutive x characters as possible anywhere in the
string.
Note:

The asterisk and the plus sign are called greedy metacharacters because they try to
match as many repetitions as possible.

Instructor Edition 79

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Question Mark (?)

The question mark (?) causes its resulting regular expression to match zero or one repetitions of the
preceding regular expression.
Example: blue-?coat matches www.bluecoat.com or www.blue-coat.com. It does not
match rex.com. The purpose of the question mark in this example is to match exactly zero or one
dash characters (-) in the target string.

Examples

You can create the following policies using the newly introduced metacharacters:

<proxy>

url.regex=!\.html?$ DENY
url.regex=^http://.*/training/ DENY

The two rules above can be translated in English like this:

The first policy denies access to any URL that does not end with htm or html. For instance you
can access http://www.bluecoat.com/resources/techbriefs/index.html but not
http://www.bluecoat.com/downloads/support/tb_skype.pdf. Note that this policy is
very limiting; most web site use style sheets and other advanced objects, which are in essence
pages not ending with .html or .htm; as result most pages will not display properly.

The second policy denies access any URL which starts with http://, followed by any number of
charactes, and then /training/. You can access http://training.bluecoat.com but not
http://www.bluecoat.com/resources/training/index.html

80 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 4: Regular Expressions

Character Sets [a-z]

[123]

Matches www1.bluecoat.com
Does not match www.bluecoat.com

[a-z]+

Matches www.bluecoat.com
Does not match 123.

0x[0-9a-f]+

Matches 0x20 (Hex value for space)

6OLGH&KDUDFWHUVHWV

Instructors Note: Character sets are not used very often in CPL regex; however it might be
useful to have some extra examples of character sets ready to show on the whiteboard if you
think your class is having trouble with the concept.

Character sets can be very useful in regular expressions. Enclosed in square brackets, characters
can be listed individually, or a range of characters can be indicated by giving two characters and
separating them by a -. Ranges operate in ASCII collating sequence. Ranges can also be used for
characters specified numerically, e.g. [\000-\037].
Special characters are not active inside sets. Some examples follow:

[akm$] will match any of the characters a, k, m, or $ as a literal character.

[a-z] will match any lowercase letter.

[a-zA-Z0-9] matches any letter or digit.

Character classes such as \w or \S (defined later in this chapter) are also acceptable inside a range.
If you want to include a ] or a - inside a set, precede it with a backslash.
Characters not within a range can be matched by including a ^ as the first character of the set; ^
elsewhere will simply match the ^ as a literal character.

Instructor Edition 81

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Range Quantifiers {min,max}


\.[a-z]{2}$

Match www.bluecoat.com.sg
Does not match www.bluecoat.com

\.[a-z]{2,3}$

Match www.bluecoat.com.sg
Match www.bluecoat.com
Does not match www.bluecoat.business

6OLGH0LQLPXPDQGPD[LPXPUDQJHTXDOLILHUV

Instructors Note: This slide introduces range qualifiers or repetition specifiers. This slide
may be very useful to create several policies. There are well over 100 registered regional
domains for Google. You cannot create a policy listing all of them but you can point out that
there are only few types of google regional domains:

www.google.com = www.google. plus three characters


www.google.co.uk = www.google. plus five characters (consider the . beteween co and uk)
www.google.it = www.google. plus two characters
www.google.com.au = www.google. plus six characters

So you have www.google. plus a minimum of two to a maximum of six characters.


Discuss this example with your students as another way of creating a better safe search policy
later on.

Curly braces are used in regular expressions to represent range qualifiers or repetition specifiers.
The expression {m,n} causes the resulting regular expression to match from m to n repetitions of
the preceding regular expression, attempting to match as many repetitions as possible.

The expression {m,n}? causes the resulting regular expression to match from m to n repetitions of
the preceding regular expression, attempting to match as few repetitions as possible.

Consider the following policy as an example:

<proxy>
url.host.regex=^www\.google\.[a-z]{2,6} DENY

The policy denies access to any URL, which begins with www.google. and it followed by
anywhere from two to six alphabetical characters. This allows you to cover all the possible
variations of the Google regional domains (www.google.com, www.google.co.uk,
www.google.it, www.google.com.au, etc.).

82 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 4: Regular Expressions

Grouping

[a-z][a-z][0-9]

Matches any two letters followed by a number


Only look for one occurrence of the pattern

^([a-z][a-z][0-9])+$

Matches the pattern two-letters-number one or more


times

6OLGH*URXSLQJSDWWHUQV

Instructors Note: Grouping is an extremely useful tool in creating effective CPL policies. You
need to discuss with the students, that a regular expression does not simply match (or not
match) a pattern in the reference string but also memorizes (or stores) the part of the
reference string matched. This concept is discussed in more detail in Slide 4-10. Discuss in
detail the sample policy that appears in the text.

In order to construct complex regular expressions, you must group items to be matched together.
This may be as simple as concatenating parts to match, or grouping items together in parentheses.
In this manner, very complex regular expressions can be constructed.
Patterns grouped in parentheses are often called subpatterns. Subpatterns can be nested as well as
captured using a back reference. (Discussed in Slide 4-10.)
You can use the grouping to create a policy to control the maximum size of an object that you are
trying to donwload. You need to be aware that this policy does not work for all objects and may
not stop transactions where the object is checked. It is nonetheless a good example of how to use
grouping. The OCS declares the size of an object in the HTTP header Content-length. You can
use this example to limit the size of each object to 10 KB (this is a very low limit)

<proxy>
response.header.content-length = 10000 ALLOW
response.header.content-length =! ^([0-9]){1,3}$ DENY

The first rule in the layer allows anything which is exactly 10,000 bytes, while the second rule
blocks anything which has more than 4 digits in the size. The second rule cover all sizes from 0 to
9,999.

Instructor Edition 83

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Logical OR |
(proxy|cache)

Matches www.proxy.com
Matches www.cache.com

Bluecoat\.(com|net|org)

Matches www.bluecoat.com
Matches www.bluecoat.org
Does not match www.bluecoat.it

6OLGH/RJLFDO25

Instructors Note: The ability to create policies based on the Boolean operator OR allows you
to create simpler policies. As matter of fact, the text on this page shows two policies created
previously in the chapter that have been redone using the OR operator. Discuss the examples.

The regex engine allows you to create policies using the OR Boolean operator. The vertical bar (or
pipe) | is the equivalent of the OR. As soon as the first match is made, the other choices are not
examined further in a given pattern. To match a literal |, remember to use the escape character as
in \|.
Note that in the second bullet point in Slide 4-9, the dot is part of the pattern to be matched; there
is, in fact, the escape character immediately before the dot itself.
Using the OR operator, you can rewrite two of the policies that appear earlier in this chapter. For
example the policy limiting the maximum size of an object to 10,000 bytes becomes:

<proxy>
response.header.content-length =! (^([0-9]){1,3}$| 10000) DENY
The policy used to allow only files wil the extention .HTML or .HTM becomes:

<proxy>
url.regex =!(html|htm)$ DENY

84 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 4: Regular Expressions

References

Use $(1) $(2) $(3) to reference the first, second,


third, etc expressions
Match any sentence containing the same two
words
([a-z]+)\s+$(1)

The expression [a-z]+ is contained within


parentheses
remembered in the back reference $(1)

6OLGH%DFNUHIHUHQFHV

Instructors Note: This slide introduces the complex topic of back references. It is best to
study some examples ahead of time, because students often have problems with this pattern.

In Perl regex, a back reference is a combination of a backslash followed by a integer equal to or


greater than 1. A back reference captures the value of some previous regular expression match.
The combination \1 captures the closest match moving from your current position to the left.
Combinations with higher numbers refer to matches farther to the left. In the Blue Coat CPL
implementation, back references have the format $( ); the first match is $(1), the second $(2), etc.

A back reference matches whatever actually matched the capturing subpattern in the current
subject string, rather than anything matching the subpattern itself. So the following pattern
matches sense and sensibility and response and responsibility, but not sense and
responsibility.

(sens|respons)e and $(1)ibility

In the example above, note that the subpattern captured is contained within the parentheses at the
beginning of the pattern. It does not include the string e and between the closing parenthesis
and the back reference.
You can use back references for several policies. For example, you can get all requests for a certain
site and transform them to request a different site. Everytime a user asks for the site
http://www.bluecoat.com/techlabs/{any page}, you redirect the request to
http://techlabs.bluecoat.com/{any page}

<proxy>
url.regex=^http://www.bluecoat.com/techlabs/.* action.newlocation(yes)
define action newlocation
redirect (307,http://www.bluecoat.com/techlabs/(.*),\
http://techlabs.bluecoat.com/$(1))
end

Instructor Edition 85

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Examples

https://www.google.com/(.*)

Matches everything after www.google.com/

Groups it and makes it available as reference

http://www.google.com/$(1)

Appends to www.google.com everything that was


grouped and referenced in the string above

6OLGH)LQDOH[DPSOHV

Instructors Note: This slide is very important. The use of back references allows you to
create several adavanced CPL policies. In particular, you can use a regular expression to
construct similar a one in the slide for two-ways URL rewrite. The back references are also
used in the Google SafeSearch policy in the lab at the end of this chapter. Makes sure that the
students understand this concept very clearly.

By placing part of a regular expression inside round brackets or parentheses, you can group that
part of the regular expression. This allows you to apply a regex operator, that is, a repetition
operator, to the entire group.

Note that only round brackets can be used for grouping. Square brackets define a character class,
and curly braces are used to represent range qualifiers or repetition specifiers.

Besides grouping part of a regular expression together, round brackets also create a back reference.
A back reference stores the part of the string matched by the part of the regular expression inside
the parentheses.
In the first example above, the goal is to match any character (.) zero or more times. The result is
held in parentheses as a group for later use as a back reference, in this case $(1).

In the second example, everything found in the first example is appended to the end of the string
in the lower example.

86 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 4: Regular Expressions

Instructors Notes for CPL Policy Using Regular Expressions Lab


Overview

In this lab your objective will be to :

Block a new virus with a random pattern

Block all sites containing certain words (sex, drug, news, mail) in the page name or query
string

Redirect all requests made to http://www.bluecoat.com/training/{other pages} to


http://training.bluecoat.com/{other pages}

Computer Hardware and Software Requirements


Table 4-1: Requirements for the Instructor
Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Table 4-1: Requirements for Students


Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Instructor Edition 87

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

88 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 4: Regular Expressions

Instructors Notes for Enabling Safesearch Lab


Overview

Many users of the Google search engine prefer not to have adult sites included in their image
search results. Google SafeSearch is a function that filters out obscene content when you search
for images on Google. The SafeSearch filters check keywords and phrases, URLs, and Open
Directory categories to screen out potentially offensive material.
Googles SafeSearch has three levels:

Use strict filtering (Filters both explicit text and explicit images)

Use moderate filtering (Filters explicit images only default behavior)

Do not filter my search results

Using a Blue Coat SG, a security administrator can configure a policy on the proxy to always
enable the SafeSearch (strict filtering) when a user accesses Google Web site and searches for
images. After you implement this policy, the images that come up in any search for material on
www.google.com are much less offensive.

In this exercise, you enable SafeSearch by adding &safe=on to the Google query string. Note that
the policy includes only Google settings.

Computer Hardware and Software Requirements


Table 4-1: Requirements for the Instructor
Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

F Wireshark

F version 0.99

Table 4-1: Requirements for Students


Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

F Wireshark

F version 0.99

Instructor Edition 89

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

90 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 5: Managing Downloads and Apparent Data Types

Estimated Lesson Time: 20 minutes

Instructors Note: The purpose of this section is to explain why Web downloads are
problematic and how the Blue Coat SG addresses these security issues. In discussing this
chapter, you first need to first build awareness of the potential threats. Then discuss how the
ProxySG offers several tools to control downloads over HTTP. Although antivirus scanning is
not discussed in this section, you should start mentioning it. You should also introduce the idea
of bandwidth management as an alternative to the more rigid choice between a full allow or full
deny.
Point out that file exhumation is a very weak detection strategy because files easily can be
renamed. Discuss, as an example, Windows Metafile Format (WMF) files. The WMF file is a
special image type designed by Microsoft in the 1980s. It allows some executable code to be
embedded in the image. If a process opens the WMF file, the code contained in the file is
executed in the security context associated with the user currently logged on the system.
Windows recognizes WMF files even if you rename them. MIME types can be easily tampered
with as well. Explain how most files types have specific header (and sometimes footers) that
identify them uniquely. This feature allows you to create policies based on the actual file
signature. The feature is called Apparent Data Type because there is a remote, but possible,
chance that a file may be incorrectly recognized as the wrong type.
As always, emphasize the concept that policies can be granularly applied to users, groups, IP
addresses and subnets, categories, and any combination of these elements. Pay particular
attention to the concepts of chunking and content encoding. Compression and chunking are
two significant additions to the HTTP/1.1 protocol.

Sometimes the greatest business and security risks come from within an organization. Left
unchecked, the Internet can hurt productivity and expose companies to potential lawsuits,
especially when objectionable Web content is being accessed. And while most organizations have
taken steps to address the security threat posed by e-mail viruses, the problems arising from
employee Web browsing and downloading have not received as much attention.
As users download seemingly safe content such as music files, they can also unknowingly
download hidden viruses, Trojans, or malware. When you add the time and resources lost while
employees browse and download content, you can see that corporations simply cannot afford to
overlook the problems posed by user downloads.

In this chapter, you will learn how HTTP is used to send data over the Web. Though HTTP is
designed to use Multipurpose Internet Mail Extension (MIME) types, it does not necessarily
transform binary data to text. Base64 encoding is allowed in HTTP but not required. You can
transfer binary data in the data portion on an HTTP response, provided that correct information is
included in the response header and the client supports it.
MIME types are not peculiar to HTTP. They were originally developed to deliver non-text e-mail
attachments but are now used in many other applications as well. The details of MIME types are
defined in RFC 2045 and RFC 2049. MIME types are very important because they can be used to
identify the content type, and block the download, if necessary.
The process of transferring data over HTTP is relatively simple:
1.

The user agent (UA) requests the specific file using one of the allowed methods (most likely
GET).

2.

The origin content server responds (if everything is correct in the request) and specifies:

Instructor Edition 91

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Q The type of file being delivered (text, image, application)


Q The sub-type (for images, jpeg, gif, etc.)
Q The encoding of the data (none, gzip, deflate, etc.)

The ProxySG knows the file that you are requesting, based on the URL presented, and reads the
information in the response header as well as in the response data portion. As result, the ProxySG
can determine which type of file you are attempting to download using any of the following
parameters: file extension, declared MIME type, or file header.

92 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 5: Managing Downloads and Apparent Data Types

HTTP Threats

Malicious software
Spyware, Malware

Bandwidth

Large downloads can clog the network

Productivity

Most downloads are not business relevant

6OLGH+773GRZQORDGWKUHDWV

Instructors Note: This slide introduces the array of issues inherent in downloads over HTTP
and downloads in general. Use this slide to build awareness in students that they need to
control what enters the network and that prevention is the best tool. Mention that Blue
Coat AV and bandwidth management are useful tools in combination with all the features
provided to manage downloads.

The majority of viruses travel the Internet through e-mail; however, spyware, malware, and other
threats are often delivered via HTTP. Improvements in the protocol, and particularly
enhancements in user agents, make it possible to write harmful code that users can download,
completely unaware that they are doing so.
In addition, freeware and shareware software often contain more-or-less hidden code, which
tracks any sort of information about a user and can result in reduced machine and network
performances. Download of large files can cause incremental network degradation.

A complete security policy should include tight control of the file types that uses can download
and the sources from which they can download. The best approach is to block the following file
types: executables, ActiveX, JavaScript, and other scripts. You also should create a white list of
approved sites; this list usually includes download sites for your antivirus vendors, operating
system vendors, and other suppliers of critical software updates.
The rest of the chapter helps you understand how downloads over HTTP operate and how you
can use the ProxySG to control them.

Instructor Edition 93

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

HTTP Downloads

6OLGH+773GDWDWUDQVIHU

Instructors Note: This slide repeats some of the concepts that you may have already
discussed in the previous HTTP sessions. Point out that the top diagram shows the download
of an image in compressed format. Even if the client asks for gzip-encoded content, it is not
likely to receive it for that file format; however, when the client asks for a file that is in text
format, the request for compressed content is accepted. In general, HTTP delivers the files
using the original binary format of the file; however, additional encoding, like compression or
chunking, is often applied. Chunking can be applied to all file types, while compression in
general is applied only to text or other formats that are not naturally compressed.
The slide above shows how different files can be transferred over HTTP and how different
encoding formats can apply.

The top diagram shows a UA asking for a file that most likely is an image file. You cannot be sure
what the file really is; at times, malicious sites host harmful files naming them using extension
reserved for other file types. The OCS replies and specifies that the attached binary data should
represent an image in JPEG format. Again, it is important to use the word should, because an OCS
often declares the MIME type of an attached file solely based on that files extension. The UA, in
the original request, asked for gzip-compressed content, if available. In general, an OCS, even if it
supports compression, will not attempt to compress file formats, like JPEG, which already are
inherently compressed. JPEG is a compression-with-loss format; applying gzip to it may have a
null or even negative effect on the resulting file size.

The bottom diagram shows a UA asking for a file that most like is an image file. The OCS
responds and declares the attached file as an HTML page in text format. However, in this scenario,
the OCS has applied gzip compression to the file and has declared it in the response header. The
presence of the content-encoding header signals to the UA that the file received needs to be
decompressed using gzip. The OCS can apply a different type of encoding, as long as the client has
declared, explicitly or implicitly, that it will accept that encoding.

94 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 5: Managing Downloads and Apparent Data Types

File Type Detection


File extensions

avi, bmp, jpeg, etc.

MIME types

text/html, image/gif, etc.

Apparent Data Type


Initial bytes in a file

6OLGH)LOHW\SHGHWHFWLRQPHWKRGV

Instructors Note: Now that students understand Web downloads, you can introduce the
ProxySG features that help administrators block them. Ensure that students are aware of the
difference between blocking a file extension and blocking a MIME type.

Now that you know the process behind Web downloads, lets talk about how to block them. The
ProxySG provides a high-performance and flexible way to create and enforce user download
policies. You can block by

File extension types: For example, you can configure the ProxySG to block users from
downloading .mp3 files.

MIME types: For example, you can configure the ProxySG to block all (or only some) audio or
image files.

Apparent Data Type: The Apparent Data Type refers to special data located at the beginning of a
file that is used to indicate its type. The ProxySG will scan these data files to determine if the
special data is present.

You can even create policies that specify when and where downloads are blocked. For example,
you can block users from downloading video files from any news sites during work hours.

Instructor Edition 95

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

File Type Detection Ambiguity

6OLGH)LOHW\SHGHWHFWLRQDPELJXLW\

Instructors Note: This slide is crucial to explain how HTTP downloads can represent a threat
to your organization in many ways. Files with a given extension and a well defined MIME type
are not always what they seem to be. In the slide, you should point out how the MIME type
described in the content-type header does not match the actual file type. The MIME is set
to text, but the file quite obviously is a GIF. You should have a file that students can test with
on your Web server.

It is possible, however not very likely, that files are hosted on a server with the incorrect extension.
For example, it is possible that malicious Web sites host executable files but with an extension that
makes them look like another file type. Because, more often than not, the OCS declares the MIME
type of a file solely based on the files extension, you can get a total mismatch between the actual
file and its MIME type. Your browser might even download a certain file with a MIME type that
matches the file extension. However, the file being downloaded could actually be something else.

For instance, you can save a PDF file on an Apache server. Change the extension from .pdf to .txt.
When you attempt to download the file, most likely the associated MIME type will be
text/plain.

The slide shows a GIF image that was renamed, from test.gif to test.txt, and hosted on an
Apache Web server. When the UA issues a GET request for the test.txt file, the OCS generates
a response in which the header declares the MIME type as text/plain (as it should be for a .txt file).
If you take a close look to the packet capture, you can see how the data part clearly contains a GIF
file. (GIF files usually contain the value GIF89 as file header.) You can do the same with an
executable file. If your policies deny access to GIF files based solely on file extension or MIME
type, this particular file would be accepted because it does not match such policies.
The apparent data type, discussed in detail later, allows you to control file downloads using the
information in the file rather than the extension or the MIME type.

Each blocking scheme has its own advantages, and you may need to experiment to see what
works the best for you in your environment. While the Apparent Data Type feature is 100 percent
accurate, it currently blocks only the following file types1: Windows DLL and executable files,
ActiveX controls (.OCX), and Windows cabinet files (.CAB).

1. You can block virtually any file type, but this requires you to write policies in CPL.

96 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 5: Managing Downloads and Apparent Data Types

Apparent Data Type

File types recognized based on the actual data


Example for use: Identify drive-by-installs

Executable with inaccurate MIME-type and extension

Supports for
HTTP

HTTPS

WebFTP

6OLGH$SSDUHQW'DWD7\SH

Instructors Note: Use this slide to explain the concept of apparent data type. Use some real
examples. For instance, open a couple of PDF files with either WordPad or a debugger. Show
that the files begin in the same way. All PDF files being with the following header:
%PDF-1.4 or 25 50 44 46 2D 31 2E 34 in hexadecimal. The first 4 bytes are usually
enough.

Apparent data type is a feature of the ProxySG, which matches a file with its type by analyzing the
actual data stream. You should note that the ProxySG uses the file header only to recognize a file
type. Miscategorization is a rare possibility.
Apparent data type support is available, in a pre-configured way, for the following file types:

Windows .exe

Many executable content and self-extracting installers are distributed as .exe files. The
Windows executable format is a Microsoft standard format called PE (portable executable
format). The ProxySG, in addition to recognizing the Windows PE executable format,
recognizes other executable formats, such as LE (linear executable) and NE (new executable).
Although these are obsolete formats, Windows machines are still capable of running these
executables.

Windows .dll

These files also are PE format files. They are similar to .exe files but do not have a main()
function and need other executable programs to load them up.

ActiveX controls (.ocx)

ActiveX controls are also PE format executables that conform to the Microsoft's COM
(Component Object Model) standard. Spyware vendors use these controls for drive-by
installations on users machines. With low-security settings in the IE browser, users may not
even realize that spyware has been installed on their machines.

Instructor Edition 97

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Windows cabinet files (.cab)

This is a Microsoft archive format. By itself it is not a dangerous format (it is not executable),
but .cab archives are used for distributing ActiveX controls. If an OBJECT block in an HTML
page has reference to a .cab file in the CODEBASE parameter, IE will download the file and
extract the ActiveX component from inside it and install it.

The options in the apparent data type object identify data content associated with Microsoft DOS
and Windows executable files. When used in a deny policy, the purpose of this object is to deny
executable downloads and block drive-by installation of spyware.

If you intercept SSL traffic, using the ProxySG SSL Proxy feature, then apparent data type applies
to HTTPS traffic as well.
Important: Apparent data type triggers are not supported for ICAP transactions.

98 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 5: Managing Downloads and Apparent Data Types

Apparent Data Type Triggers


Apparent Data Type (predefined)

http.response.apparent_data_type = (executable,
cabinet)

Custom defined data Type

http.response.data.4.regex={}"
Allows identification of virtually any file type

6OLGH&3/JHVWXUHV

Instructors Note: This slide describes the CPL gestures associated with this feature.
Discuss the examples listed below.

The http.response.apparent_data_type= tests the apparent type of the HTTP response


data, based on examining the file header. The syntax is as follows:

http.response.apparent_data_type = executable|cabinet
where:

executable is a test for a Windows executable file (.exe)

cabinet is a test for a Windows cabinet file (.cab)

This CPL gesture is available in <cache>, <proxy>, <exception> layers and it applies to all
HTTP transactions (proxy, refresh, pipeline)

Examples

Deny the request if the first few bytes of the response data indicate the file is probably a
Windows executable file.

<proxy>

DENY http.response.apparent_data_type = executable

Deny the request if the first few bytes of the response data indicate that the file is probably a
WMF file:

define condition BC_Response_Data_Pattern_wmf


http.response.data.4.regex.case_sensitive="^\xD7\xCD\xC6\x9A"
http.response.data.6.regex.case_sensitive="^.\x00\x09\x00\x00\x03"
end
condition=BC_Response_Data_Pattern_wmf

FORCE_DENY

Instructor Edition 99

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Combining Features CPL


File Extension

url.extension=.wmf

MIME Types

response.header.Content-Type= "(application|image)/(x-|xms|x-win-|)(metafile|wmf)

Apparent Data Type

http.response.data.4.regex.case_sensitive=
"^\xD7\xCD\xC6\x9A"

6OLGH&RPELQLQJIHDWXUHV

Instructors Note: This slide reviews all the options that the ProxySG offers for controlling file
downloads. Do not forget to mention also file download over IM. You can use the
im.file.path.suffix="wmf" gesture.

This slide offers you a combined view of the three methods that the ProxySG makes available to
you to control file downloads. You can use all of them in combination for maximum protection
and accuracy.

As mentioned before, using file extensions is the least effective, or least accurate, method. MIME
type is fairly reliable. It is clear that apparent data type offers the highest level of accuracy.

100 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 5: Managing Downloads and Apparent Data Types

Apparent Data Types List

This page contains some of the apparent data types for the files that are most likely to represent a
threat to your clients and to your network. They are represented in hexadecimal format, with few
exceptions. You can search on the Internet for more data types. Bear in mind that, at the moment,
the ProxySG supports data type recognition only through the files header.

;;;; ".MSI"

Microsoft installers

http.response.data.8.regex="^\xD0\xCF\x11\xE0\xA1\xB1\x1A\xE1"

;;;; ".gz" or ".gzip" a compressed file format


http.response.data.2.regex="^\x1f\x8b"

;;;; ".bz2" a compressed file format

http.response.data.10.case_sensitive="BZh91AY&SY"

;;;; ".RAR" a compressed file format

http.response.data.4.case_sensitive="Rar!"

;;;; ".ACE" a compressed file format

http.response.data.7.case_sensitive="**ACE**"

;;;; ".hlp" Windows help files

http.response.data.4.regex.case_sensitive="^\?_\x03\x00"

;;;; ".chm" Windows compiled help files

http.response.data.4.case_sensitive="ITSF"

;;;; ".wsh" Windows scripting host files

http.response.data.12.case_sensitive="[ScriptFile]"

;;;; ".hta" Hypertext Application files

http.response.data.15.case_sensitive="HTA:APPLICATION"

;;;; ".wmf" Windows MetaFiles, note two patterns modern and windows v3
styles
http.response.data.4.regex.case_sensitive="^\xD7\xCD\xC6\x9A"

http.response.data.6.regex.case_sensitive="^.\x00\x09\x00\x00\x03"

Instructor Edition 101

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

102 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 5: Managing Downloads and Apparent Data Types

Instructors Notes for Managing Downloads and Blocking WMF File


Remote Code Execution Labs
Overview

Files downloaded from the Internet or sent by e-mail can pose a hazard to the enterprise. Files
may contain viruses or other malware. In addition, allowing staff unlimited ability to surf the
Internet during working hours can reduce productivity and expose employees to materials that
they may find offensive.

The Blue Coat SG appliance enables you to block downloads of selected types of information
based upon various criteria such as URL category, file MIME type, file extension and apparent
data type. The Blue Coat SG appliance also enables you to create exceptions the download
limitations you have set.
A Windows Metafile Format (WMF) file vulnerability was discovered on December 27, 2005.
Microsoft released a patch that addressed the issue on January 5, 2006.

The WMF file is a special image type designed by Microsoft in the 1980s. This file format allows
some executable code to be embedded in the image. If a process opens the WMF file, the code
contained in the file is executed in the security context associated with the user currently logged
on the system.
In this lab you will:

Block Windows Meta Format files from HTTP downloads and IM downloads.

Become familiar with Web Access Layer policy in the Visual Policy Manager (VPM).

Use rules within the layer to block various types of data from being downloaded.

Computer Hardware and Software Requirements


Table 5-1: Requirements for the Instructor
Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Table 5-1: Requirements for Students


Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Instructor Edition 103

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

104 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 6: Policy Tracing

Estimated Lesson Time: 15 minutes

Instructors Note: This section is a key component for the global troubleshooting approach to
the Blue Coat SG. Discuss the two levels of policy tracing: global and per-policy. When
you discuss the global level, be sure to warn the students of the potential severe impact on the
proxy performance. When you discuss the per-policy approach, point out its limited use; the
trace is generated only if the policy is triggered. You need to spend time on the various
examples and work with the students on the lab.

The ProxySG offers you a variety of tools to troubleshoot whatever issue you are dealing with.
Among these tools, policy tracing is one of the easiest to use and one of the most effective.
Two types of policy tracing are available to you:

Global policy tracing


Important:

Be aware of the potential severe impact on performance that this option may
have on a production ProxySG.

Per-rule policy tracing

The following matrix lists all of the Track and column objects and indicates which policy layer they
apply to.
Admin
Auth

Object

Admin
Access

DNS
Access

SOCKS
Auth

Web
Auth

Web
Access

Web
Content

Event Log

E-mail Log

SNMP Objects

Trace

Combined
Objects

Forwarding

Important: A policy-based trace only generates a trace if the rule to which is associated is
triggered.

Policy trace files are available via the Web browser. You can access them directly or via the
Management Console. From the Management Console, select Statistics > Advanced > Policy > List
of policy URLs. You can also directly point your browser to:

https://[ip address of the proxy]:8082/Policy

The global policy trace is available under the file default_trace.html, while the other policy
specific traces are available under whatever name you designated.
Note:

After using a trace to troubleshoot, remove the trace to save log space.

Instructor Edition 105

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Policy Trace

Global Policy Trace

Management Console > Policy > Policy Option


Use for troubleshooting

Selective Policy Trace

VPM > Track > Set > New > Trace


May not be triggered
For more limited troubleshooting

6OLGH$YDLODEOHWUDFHV

Instructors Note: This slide is self-explanatory. Point out that global policy tracing should be
used with caution and only for the minimum amount of time necessary to troubleshoot the
issue. The policy-level trace has a far less severe performance impact.

You can enable global tracing from Management Console. Select Configuration > Policy > Policy
Options, and then click the check box next to Trace all policy execution.

You also can enable global policy tracing from the command-line interface (CLI). From the CLI,
type the following commands:

SGOS>en
Enable Password: *****
SGOS# policy trace all

Use the following command to stop the global tracing:

SGOS# policy trace none

You can enable policy tracing on a per-policy basis. In the Visual Policy Manager, you can set the
track option for a given policy to record the trace information in a custom-defined file (such as
mytrace.html). You have several options for the level of detail that you want in the trace:

No Tracing: The default.

Request Tracing: Generates trace output for the current request. The trace output contains
request parameters (such as URL and client address), the final values of property settings, and
descriptions of all actions taken.

Rule and Request: Generates trace output that displays each rule that was executed.

Verbose Tracing: Generates the same output as Rule and Request, but also lists which rules were
skipped because one or more of their conditions were false, and displays the specific
client.address=10.10.10.1 trace.request(yes) trace.rules(all)

106 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 6: Policy Tracing

Policy Trace

Each transaction is evaluated separately


A page calls for many transactions

Policy traced until a match

Statements past a match are not evaluated

Policy re-evaluated at each checkpoint


Trace does not reflect it

6OLGH3ROLF\WUDFHNH\IDFWRUV

Instructors Note: Use this slide to point out why global policy tracing can generate a
significant performance impact on the ProxySG. Set the students expectations correctly: If a
rule is matched in a layer, the subsequent rules are not evaluated, as you should expect.

Each Web page or resource that you download from the Internet is composed of several objects.
For instance, when you open a complex Web page like cnn.com, your browser is likely to
download more than 50 objects.

Each object processed by the ProxySG has to go through the policy evaluation, and by doing so
generates an entry in the global policy trace (and in the rule-based trace, if the object triggers the
rule).
A policy trace does not show a request being evaluated against a rule that follows in the same
layer as the rule that the request triggered. This behavior is consistent with the built-in logic of
ProxySG: When a rule is matched, policy evaluation for that layer is interrupted and the process
goes to the next layer in the sequence.

At each checkpoint, the policy is evaluated again as new information is available to the ProxySG to
make a decision. This behavior is not reflected in the trace as it may confuse matters.

Instructor Edition 107

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Policy Trace

6OLGH6DPSOHSROLF\WUDFH

Instructors Note: Spend some time on this slide, or generate a new trace during class and
show it live to the students. Point out the start transaction and end transaction
boundaries. Point out the miss statement and the categorization. Mention that the
categorization is shown as soon as you install a content filter vendor even if there are no
policies for it yet. Lastly, point out that each transaction has a unique ID number.

Slide 6-3 shows you the result of a global policy trace. There are a few important aspects that need
to be pointed out.

In the pane marked with the number 1, you can see how the policy shows a miss. This indicates
that the triggers in the rule just evaluated for the object returned a Boolean value of false. As result
no action for that rule was taken.
In the pane marked with the number 2, you can see that the categorization is done for every object.
The categorization appears in the trace as soon as you install and configure a content filter. The
syntax for the categorization is {category name}@{vendor name}.
The process evaluation for each object is separated by the start transaction and end
transaction delimiters.

Many other details of the transaction are visible, among them:

Client IP address and port

Time of the transaction

Full URI

Information about the user agent, which generated the request

108 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 6: Policy Tracing

Policy Trace

6OLGH6DPSOHSROLF\WUDFH

Instructors Note: There are three things to point out in this slide. First, point out that a rule is
triggered. This causes an action (deny) to be taken, which is the second aspect to discuss.
Finally, point out that even if the user is going to http://mail.yahoo.com, there are two
transactions shown. Most modern browsers make two concurrent requests when connecting
to a Web site: one for the requested URI, and one for the favicon.ico, which is the little icon
showing in the link bar of the browser for many sites.

In the trace shown above, a rule is triggered. As mentioned before, you cannot expect the ProxySG
to evaluate and compare any rule following this one, in the same layer. Since the rule has been
triggered, the ProxySG interrupts the processing of that layer and moves to the next one.
This rule denies the connection, so an exception is returned to the user. This is clearly indicated by
the fact that there is a MATCH for a rule, followed by a DENIED.

Note that there are two denied actions even if the user only requested one object. Usually a
browser makes two concurrent requests when first connecting to a Web site: one for the requested
URI, and one for the favicon.ico, which is the little icon showing in the link bar of the browser for
many sites.

Instructor Edition 109

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

110 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 6: Policy Tracing

Instructors Notes for Policy Tracing Lab


Overview

The Blue Coat SG offers several troubleshooting and debugging options. In this lab, you use
policy tracing to determine how the ProxySG appliance interprets your policies. You can set up a
global policy-tracing option and a rule-specific trace. You need to do both.

You have just implemented a new set of policies on the ProxySG appliance; however, the result is
not what you expected. Because you suspect that you may have incorrectly defined the rule, you
set up a global policy trace specific to that rule.

In addition, you are operating in a very secure-minded environment. Your ProxySG appliance is
configured to deny all connections unless otherwise specified. You also have set up a policy that
allows access to only one employment-related site: http://www.jobs.com. You need to make sure
that all requests sent to sites that are categorized in Blue Coat Web Filters Job Search category are
redirected to the Jobs website. Finally, you allow the use of News/Media websites.

Computer Hardware and Software Requirements


Table 6-1: Requirements for the Instructor
Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Table 6-1: Requirements for Students


Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Instructor Edition 111

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

112 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 7: HTTP Details

Estimated Lesson Time: 20 minutes

Instructors Note: This chapter looks at HTTP in more detail to show how administrators can
use HTTP to redirect clients. You should use this opportunity to review the basic HTTP
concepts included in the BCCPA class. Aside from teaching the concepts included in the
chapter, ensure that you provide practical examples of how administrators use redirection,
authentication, and cookies to accomplish a business goal. This chapter is fundamental to
understanding how ProxySG appliance manages authentication in transparent proxy mode
(where HTTP 407 is not available).

As you learned earlier, HTTP is a request/response protocol. The client is limited to a specific set
of request methods and the server has a well-defined set of response codes. This chapter looks at
some of the HTTP 3xx and 4xx responses to understand how they are used for redirection and
authentication. This chapter also reviews basic HTTP concepts and shows how cookies are used to
keep track of state throughout a session.

There are many reasons for learning the ins and outs of HTTP. One of these is to learn how you can
redirect users to a Web page of your choice, regardless of the original URL. Many organizations
need to send out notices to their employees, ensure that employees see the corporate Internet use
policy, or direct the employees first Web request to the corporate intranet Web site. HTTP
redirection enables administrators to meet these requirements.
HTTP authentication, on the other hand, enables administrators to guard protected content, or
limit access to content or systems. This chapter looks at the two layers of HTTP authentication,
Web server authentication and proxy authentication to learn their structure and uses.

Finally, this chapter discusses how cookies are used to provide state for the HTTP protocol, which
does not have a mechanism for remembering information from one request to the next. Basically, a
cookie is server information that is stored on the client. This information can be used by the server
to remember a users preferences, choices, authentication state, or simply to track the users
visits. As you will see, cookies are not the demon that many have made them out to be, and
actually can be useful to you. The ProxySG appliance uses redirection, cookies, and authentication
details are to provide authentication in transparent proxy deployment mode.
Note:

Portions of the following content are from RFC 2616. Copyright (C) The Internet
Society (1999). All Rights Reserved.

Instructor Edition 113

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

HTTP Responses

Special HTTP response codes for redirection


Indicate the requested content is at another URL

Response header Location

Specifies to the browser where to find the requested


content.

Special HTTP response codes for authentication


Specify credentials needed to access a resource

6OLGH+7735HVSRQVHV

Instructors Note: This slide introduces browser redirection. You do not have to spend a lot of
time on this slide, but make sure that students understand that all 3xx codes are redirection
codes, and that each code has a special purpose. Additionally, explain that 4xx codes indicate
an issue with authentication.
All HTTP 3xx status codes indicate some type of redirection. These codes are used to specify
alternative actions that the browser can take to complete a request.

The 302 and 307 status codes indicate that the requested content has been temporarily moved to
the new location. Because the location of the content is subject to change, no new permanent URL
is provided a temporary URL is provided in the Location header but user interaction is usually
not required to retrieve the redirected content.
The 301 status code indicates that the requested content has been moved permanently and that
future references to the resource should use a URI returned in the message.

Because browser redirection behavior did not meet the original RFC requirements, additional 3xx
response codes were added in HTTP/1.1.

All HTTP 4xx status codes indicate that there is an authentication issues. In this chapter, codes 401
and 407 are discussed. If a 401 response is returned, it mean that a client has sent authentication
credentials with the request, but those credentials are incorrect. A 407 response, however, means
that the content being requested requires authentication.

114 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 7: HTTP Details

301 Moved Permanently

6OLGH0RYHG3HUPDQHQWO\

Instructors Note: The 301 response indicates that a connection has been redirected and
that the requested resource has been moved permanently. Modern browsers can read a 301
response message and redirect the request automatically.

The 301 response code indicates that the requested content has been moved permanently. For
instance, you may receive a 301 response if you request a file that has been moved to another
server.

The Location field of the 301 response should contain the new permanent URI. Clients that have
link-editing capabilities should be able to automatically relink references to the Request-URI to
one or more of the new references returned by the server.
However, if the user agent receives a 301 response in response to a request other than GET or
HEAD, it must not automatically redirect the request unless the user can confirm it. That is
because redirecting the request may change the conditions under which the request was made.
According to RFC 2616, some HTTP/1.0 user agents, when automatically redirecting a POST
request after receiving a 301 status code, erroneously change it into a GET request.

Unless the request method was HEAD, the 301 response also should contain a message and a
hyperlink to the new URI(s). This allows the user to access the content if the browser does not
redirect the request automatically to the resources new location.
When a user receives a 301 response, it means that the following has happened:
1.

User asks for http://www.somesite.com/page.htm.

2.

The OCS responds notifying the client that the requested URL was permanently moved to
http://www.someothersite.com/newpage.htm.

3.

When the user requests http://www.somesite.com/page.htm, the client connects directly to


the newer location http://www.someothersite.com/newpage.htm.

Note:

The client does not have to ever connect back to http://www.somesite.com; it can
directly connect to the new URL location
http://www.someothersite.com/newpage.htm.

Instructor Edition 115

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

302 Found

6OLGH)RXQG

Instructors Note: The 302 Found code is important because it is still widely used.
Concentrate on the fact that the code is intended for automatic redirection of Get and Head
requests only.

The 302 Found status code indicates that the requested content is temporarily located at a different
URL. Because the location of the content may continue to change, the client should use the request
URL for future requests. This response is cacheable if indicated by a Cache-Control or Expires
header field.
The 302 Found code was called Moved Temporarily in HTTP/1.0. The reason for the name change
will become clear as you learn more about the 303 and 307 status codes. Basically, the modification
of some 3xx codes and the introduction of new codes in HTTP/1.1 were intended to clarify
browser redirection behavior.
In this case, the temporary URL should be provided in the Location field in the response.
However, only GET and HEAD requests should initiate automatic browser redirection to the new
content. The response should contain a short note with a hyperlink to the new location so the user
can access the content if browser redirection is not automatic.
In the above slide, the behavior is as follows:
1.

The user sends a request to http://www.somesite.com.

2.

The OCS responds, notifying the client that the URL requested was found on
http://www.someothersite.com/temppage.htm.

3.

When the user requests http://www.somesite.com/page.htm, the client connects cannot


connect to the newer location http://www.someothersite.com/temppage.htm but must
connect to the requested URL first.

Note:

The client cannot directly connect to the new URL location


http://www.someothersite.com/temppage.htm; it must verify if the original URL
still responds with a redirect or if the content is now available there again.

116 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 7: HTTP Details

307 Temporary Redirect


Very similar to HTTP 302
Added in HTTP/1.1 RFC

Clarifies some issues with HTTP 302

Clients cannot change the method on the redirected


request

Requires the GET method

User agent must issue a GET request regardless of


the original request method

6OLGH7HPSRUDU\5HGLUHFW

Instructors Note: The 307 code is very similar to the 302 code so you must spend some time
explaining the similarities and differences. The key to discussing the 302, 303, 307 codes is to
make sure that students understand that browser behavior was supposed to follow the RFC,
but did not always do so, as was the case with the 302 code. The RFC states that browsers
should only redirect on a 302, if the original method was GET or HEAD. In practice, most
browsers automatically issued a new GET request, regardless of the original method. To
ensure that administrators can obtain the proper behavior, the 303 and 307 codes were
added. The 307 code triggers the behavior that some browsers erroneously applied to the 302
code. The 303 code is meant to replace the older 302 code.

Although RFC 1945 and RFC 2068 specify that clients are not supposed to change the request
method, most browsers read the temporary URL listed in the Location header of 3xx responses
and issue a new GET request for the content in that location regardless of the original request
method. This is the browser redirection problem that led to the 302 name change. HTTP/1.1
introduced the 303 and 307 codes to clarify and enforce the expected RFC behavior.

The 307 Temporary Redirect status code indicates that the requested content has been temporarily
moved. Since the redirection is temporary, the client should continue to use the original URL for
future requests. This response is only cacheable if indicated by a Cache-Control or Expires header
field.
The temporary URL should be provided in the Location field in the response. Unless the request
method was HEAD, the response should contain a short note with a hyperlink to the new location
(particularly because the 307 code is new for HTTP/1.1 and early browsers might understand the
method).
The 307 status code is very similar to the 302 code. Why, you might ask, does the HTTP
specification include two codes that are essentially the same? The reason is that the popular
browsers did not implement the 302 behavior as specified in the HTTP/1.0 RFC; instead, they
behaved in a manner consistent with the new 303 status code. That is, browsers automatically

Instructor Edition 117

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

initiated a new GET request for the redirected content, even if the original method was not a GET
or HEAD request (which is contrary to what the RFC states). Since browsers still respond to a 302
with the incorrect behavior, the 303 and 307 status codes were introduced to enable administrators
to enforce the RFC behavior.

118 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 7: HTTP Details

401 Unauthorized

6OLGH8QDXWKRUL]HG

Instructors Note: You do not need to spend a great deal of time on this slide. The 401 code
is used for connections that include authentication credentials that are wrong. If a client
attempts to connect to a secured resource, and include invalid credentials with the request, a
401 response will be returned.

Web servers issue the 401 Unauthorized code to clients attempting to access protected content
without the proper authorization credentials. If the request already included authorization
credentials, then the 401 response indicates that authorization has been refused for those
credentials. The 401 response must include a WWW-Authenticate header. The
WWW-Authenticate response-header consists of at least one challenge that indicates the
authentication scheme. Often, the 401 response triggers the browser to prompt the user for a
username and password.

The client caches user credentials separately for each requested resource. For example, the
browser cannot use the credentials cached for a 401 Authentication request from www.a.com, to
respond to a 401 challenge from www.b.com.
In the example above, the steps that occur before a 401 response is sent are shown:
1.

2.

User asks for a URL.

a.

The OCS requests authentication from the client.

b.

The User Agent issues the same HTTP request; this time adds the requested
credentials.

User asks for a different URL.


a.

The OCS requests authentication from the client.

b.

The User Agent issues the same HTTP request; this time adds the requested
credentials.

Note:

The credentials used for one OCS cannot be used for another OCS but can be cached if
connecting back to the same URL.

Instructor Edition 119

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

HTTP 407

6OLGH+773

Instructors Note: This slide introduces the proxy authentication code. The main point to
discuss is that this code is for proxy authentication, and not Web server authentication. These
two levels of authentication can be a complicated subject but you should just make sure that
students understand the general concepts here.

The 407 Proxy Authentication Required code is used to authenticate clients to a proxy. According
to RFC 2616, The ProxySG appliance MUST return a Proxy-Authenticate header field containing
a challenge applicable to the ProxySG appliance for the requested resource. The client MAY repeat
the request with a suitable Proxy-Authorization header field.

The 407 message is usually sent by the ProxySG appliance after receiving a client request that does
not have the proper authorization credentials.
1.

2.

Client asks for a URL; this is the first connection to the ProxySG appliance for that browser
instance.
a.

The ProxySG appliance responds asking for authentication.

b.

Client requests same URL but this time adds the credentials requested.

User asks for a second URL (within the same browser instance). Since it knows of the ProxySG
appliance, which requires authentication; the client issues the request already using the
necessary credentials.

120 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 7: HTTP Details

Cookie Fundamentals

Need to carry information across session

Cookies are a way to create stateful sessions with


HTTP requests and responses RFC 2109

Originally defined by Netscape


Formalized in

RFC 2109 of 1997 (obsolete)


RFC 2965 of 2000 (current)

6OLGH&RRNLH)XQGDPHQWDOV

Instructors Note: This is a very important slide so be sure to take your time covering the
concepts. Students must understand that cookies were created to make up for the fact that
HTTP does not maintain state. Though most students may understand the concept of state, it
is worth describing again. State is simply remembering the details of a transaction from one
request to another. Maintaining user information for hundreds or thousands of users at the
same time would put an incredible load on the server and is not feasible. Cookies allow
servers to remember users by shifting the burden to the browser, which keeps a unique bit of
information that identifies the user. This information has come to be known as a cookie.

HTTP is a stateless protocol, which means that it does not keep track of information from one
request to the next. For example, when you access protected content, the client must authenticate
to the server for every request the server does not remember that it already authorized you.
Cookies were created to keep track of just such user information that is to maintain state
throughout HTTP sessions. As RFC 2965 states, cookies can enable stateful sessions that ...might
be used to create, for example, a shopping cart, in which user selections can be aggregated
before purchase, or a magazine browsing system, in which a user's previous reading affects which
offerings are presented.

Cookies were first introduced by Netscape in 1994 and codified by the IETF in RFC 2109. That RFC
was superseded by RFC 2965, which describes the current cookie standards.
Sessions in which cookies are used have the following key attributes:
1.

Each session has a beginning and an end.

2.

Each session is relatively short-lived.

3.

Either the user agent or the origin server may terminate a session.

4.

The session is implicit in the exchange of state information.

Instructor Edition 121

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Cookie Fundamentals

6OLGH&RRNLH)XQGDPHQWDOV

Instructors Note: This slide illustrates the cookie-setting process. Ensure that students
understand that the Set-Cookie header is just another header added to the HTTP response.
The next slide describes the Set-Cookie header in more detail.

A server sends a cookie to a browser with its response, requesting that the browser include the
cookie in all subsequent requests to the server. The next time the user visits the Web site, the
browser includes the cookie information in the request header. When the Web server receives the
cookie, it is able to track the user and present that users information and/or personal settings.
Slide 7-8 illustrates the cookie setting process:
1.

The client requests content from the server.

2.

The server responds with the requested content. The response includes a Set-Cookie header
that contains some type of user-specific value.

3.

The clients next request includes a Cookie header with the value specified by the server in
Step 2.

A common use of cookies is keeping track of online selections. For example, when you add items
to an online shopping cart, the server is able to keep track of your selections from page to page.
Often, the state information is not contained in the cookie; the cookie includes information that
points to a database entry containing the information.

122 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 7: HTTP Details

Cookie Fundamentals

Set-Cookie: PREF=ID=c295f06bd13033fd:
TM=1111377507:
LM=1111377507:
S=bL0B-I8g3qIBK1Cs;
expires=Sun, 17-Jan-2038 19:14:07
GMT;
path=/;
domain=.google.com\r\n

6OLGH&RRNLH)XQGDPHQWDOV

Instructors Note: This slide gives students a better idea of how an actual cookie is set.
Focus on the Set-Cookie header and optional attributes. If you have time, go over the ways
that the domain and path attributes are used, as these can be used to restrict the places a
cookie is used.

Slide 7-9 shows a typical Set-Cookie transaction. The Set-Cookie header is sent only if the
server wishes the browser to store a cookie. The Set-Cookie line instructs the browser to store
the specified cookie name and value so that it can be sent to the server in each subsequent request.
If the browser supports cookies and cookies are enabled, every successive page request to the
same server contains the cookie.
In addition to setting the cookie name and value, the server can set the cookie expiration date, a
path, a domain name, and whether the cookie is intended only for encrypted connections. The
domain command specifies the servers that are allowed to set or read cookies. The path attribute
further restricts the pages that require a cookie to be sent back to the server. The browser will not
send the cookie for any pages outside the specified path.

A path specified as / indicates that cookies must be sent for requests to the entire domain. If a
path or domain is not specified, the browser assumes the domain and path strings are the same
as those specified in the request.
The Set-Cookie header has the syntax COOKIE_NAME=COOKIE_VALUE. Can you identify the
name of the cookie and its value in the slide above?

Instructor Edition 123

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Cookie Security
Protocol Security

Cookie accepted only for the source domain


Cookie sent only to the domain and resource
for which they were accepted

Browser Implementation

Cookie jars are separate per user


Expiration date control

6OLGH&RRNLH6HFXULW\

Instructors Note: This slide is interesting because it addresses some of the security
concerns that users have had about cookies. Admittedly, some companies (like DoubleClick)
have used cookies to track users Web activity. However, many of the Web features that
everyone now takes for granted depend on cookies.

A server can set cookies only for its own domain. That is, a server in www.foo.com can set a cookie
for foo.com and www.foo.com, but not for www.user.foo.com (unless otherwise specified in the
domain attribute). Clients send cookies only to the domain and resource for which they were
accepted.

If a computer has multiple browser types, each browser will have its own list of cookies. (This list
is called a cookie jar.) Thus, if a user visits a Web site using Netscape and then visits it again using
Internet Explorer (IE), the Web server will not recognize the user because the IE browser does not
have a cookie for that site. In this case, the server sets a new cookie on the IE browser. By the same
token, if a browser has multiple user accounts, each user will have his or her own cookies.

A cookie stays on the users browser until it expires. If an expiration date is not specified, the
cookie is removed once the user quits his or her browser. Most browsers now allow users to delete
cookies, refuse them, or to set explicit expiration times.

124 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 7: HTTP Details

Instructors Notes for VPM HTTP Redirection and VPM Setting


Cookies Labs
Overview

In this lab you understand how HTTP redirection works. You also understand how a cookie is set.

Computer Hardware and Software Requirements


Table 7-1: Requirements for the Instructor
Software

Version

F FireFox

F version 2.0.0.5

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Table 7-1: Requirements for Students


Software

Version

F FireFox

F version 2.0.0.5

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Instructor Edition 125

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

126 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 8: Using Authentication In Transparent Proxy Mode

Estimated Lesson Time: 60 minutes

Instructors Note: This is definitely one of the most complex chapters that you have to teach
in this course. Spend as much time as you need repeating the details and steps of the origin
cookie redirect authentication. You need to start the class by pointing out that authentication,
in transparent proxy mode, is very challenging. The user agent cannot accept an HTTP 407
response for the Blue Coat SG. The user agent is not aware that it is talking to a proxy to
begin with, so proxy style authentication cannot be used. Furthermore, you cannot ask users
to re-authenticate every time they access a new resource (i.e. Web site) on the Internet.
Refer back to the HTTP chapter. Point out the following key aspects of cookies:
Cookies are designed to create state in a stateless protocol like HTTP.
Cookies can be accepted by the user agent only for the domain from which they come.

Finally, remind the students of the effects of HTTP redirection and the modus operandi of
HTTP 401 response code.

Important: Make a clear distinction between user (a human being) and the user agent (a
piece of software).

This chapter discusses the complex details of authentication for transparent proxy deployments.
You should already be familiar with how the ProxySG authenticates users when it is deployed in
explicit mode. In essence, the HTTP protocol has a detailed provision for authenticating users
when the requests are explicitly sent to a proxy (HTTP 407 response code sent by the proxy to the
user agent). Unfortunately, there is no provision for proxy-based authentication when the proxy is
deployed in transparent mode (when the user agent is not aware that it is talking to a proxy).
The HTTP protocol offers only two authentication options:

401 Authenticate: Used by Web servers to require authentication before serving specific
content

407 Proxy Authorization Required: Used by proxy server to authenticate user agent requests

Because 407 is not an option, the ProxySG can only issue a 401-style authentication challenge;
unfortunately, the 401 authentication is resource-specific. From the user agent point of view, a
successful authentication to a HTTP 401 response is valid only for the URI it originates from.

For example, if the user agent receives a 401 challenge from http://www.cnn.com and
successfully authenticates, that authentication token is valid and is re-issued only for the
www.cnn.com domain. When the user agent makes a subsequent request to
http://www.google.com, if it receives a HTTP 401 response it will not send the information it has
cached for the www.cnn.com Web site; the user agent challenges the user again for credentials.

The ProxySG needs to cache the authentication information that it can gather from the response to
a HTTP 401 challenge. Because this type of authentication is resource-specific, the ProxySG
redirects all the requests to a virtual URL. If the user agent can successfully authenticate against the
virtual URL, then the ProxySG can allow the connection request to the intended URL. Because
redirection, as you learned in the previous sections, is transparent to the user, the authentication
process does not appear any different to the user from the explicit proxy authentication scenario.
Only the user agent sees the process as completely different.
The ProxySG uses session-based cookies or, alternatively, persistent cookies, to cache the
authentication information and not challenge the user agent for authentication.

Instructor Edition 127

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Transparent Proxy Authentication


Proxy cannot challenge the user agent
HTTP 407 is ignored

Need indirectly authenticate the user agent


Use HTTP 401 authentication

Cache Authentication Information

Avoid challenging the user agent multiple times

6OLGH&KDOOHQJHVLQWUDQVSDUHQWSUR[\DXWKHQWLFDWLRQ

Instructors Note: Use Slide 8-1 to describe and reiterate what appears in the introduction
section under the instructors note. The fundamental challenge for the ProxySG is to
authenticate the users in a scenario where HTTP 407 is not available, without the user
receiving multiple authentication requests. Show the users what happens if you use Origin
Cookie authentication versus Origin Cookie Redirect.

Slide 8-1 summarizes the concepts outlined in the introduction to this chapter. The ProxySG
cannot use HTTP 407 to request authentication information; the user agent does not believe that
there is a proxy in the midst of the conversation. Therefore, it will reject the request as invalid. The
user experience is that the browser immediately shows the authentication failed exception page.
The URL shown is the one of the requested origin content server, as shown in the screen capture
below.

Figure 8-1: URL of requested OCS

The only alternative is to use the HTTP 401 response, in order to trick the user agent into
supplying the authentication credentials.

Since HTTP 401 is a resource-specific authentication challenge, the ProxySG uses session-based
cookies, or alternatively persistent cookies, to cache the authentication information and not
challenge the user agent for authentication.

128 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 8: Using Authentication In Transparent Proxy Mode

Authentication Surrogate
Redirection

401 can authenticate only one resource at the time

Cookie Surrogate

Successful authentication associated to a cookie

IP Surrogate

Success authentication associated to the


IP address of the UA

6OLGH$XWKHQWLFDWLRQVXUURJDWHV

Instructors Note: Slide 8-2 introduces the concept of authentication surrogate. Start by
telling the students that the default authentication surrogate in an explicit proxy deployment is
the TCP session. The ProxySG authenticates the TCP session; as long as that session is
alive, re-authentication is not necessary. In transparent proxy mode, there is no TCP session
with the ProxySG (as far as the user agent is concerned); the only alternatives are cookies
(which are not always possible) or IP addresses (which present several issues, such as NAT,
TTL, accuracy, etc.). Make sure that you cover all of the advantages and disadvantages of
each approach; at a minimum discuss the ones listed in the student section. You should
discuss some customer experience on this topic (either your customers or your students
experience).

Based on the constraints of the HTTP authentication specification, and the nature of the
transparent proxy approach, the ProxySG needs to use some artificial method to remember when if
a user has already been authenticated.
The ProxySG uses the concept of surrogates. The idea is to assign the authentication flag
(authenticated vs. not authenticated) to a surrogate; because TCP session is not a viable one, the
only alternatives are cookies and IP addresses. Each presents advantages and challenges.

First and foremost, the ProxySG needs to redirect all requests to a common site where
authentication can be verified. Again, remember that HTTP 401 authentication is resource-specific.
By redirecting all requests to a common resource before delivery to the requested URI, the
ProxySG has a chance to authenticate or verify that authentication has already taken place.
The ProxySG identifies the common URL where requests are being redirected as the virtual URL.
By default, the virtual URL is set to http://www.cfauth.com. In general there should not be any
reason to change it; however this parameter is fully configurable and you can set it any other URL,
which meets the following criteria:

Every client can properly DNS resolve the virtual URL to an IP address.

No client should ever need to access the virtual URL.

Instructor Edition 129

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

The requirements are pretty self-explanatory. The virtual URL must resolve to an IP address
because, in transparent proxy deployments, the browser does a DNS lookup on the destination
URL. If the virtual URL does not DNS resolve to an IP address, the browser sends the user an error
message saying that the remote host (in this case the virtual URL) is not available. Finally, the
virtual URL is not reachable by the user population. The ProxySG traps all requests to the virtual
URL and tries to use those request to authenticate the request. If you try to access the virtual URL
from the browser directly, you end up in something similar to an infinite loop. Because all requests
are first redirected to the virtual URL and then to the intended URL, if the final destination URL is
the virtual URL itself, you can immediately see where the issue is.
After the ProxySG performs the redirection to the virtual URL and the HTTP 401 authentication
takes place, the ProxySG needs to associate the successful authentication with a surrogate.

If you allow cookies in your organization, cookie surrogate is a viable option. Even if you allow
the use of cookies in your company, you still need to be aware that if individual users set their user
agents to reject cookies, they will face authentication issues. Similarly, there are several
HTTP-based user agents, which do not support cookies and do not have a provision to support
cookies. In this case you need to find some work-around or use origin IP redirect.
Origin cookie redirect has the following advantages:

Cookies can be session-based; as soon as you close all instances of your browser, you need to
authenticate again.

It is very unlikely that one session may be attributed to a user other then the actual one.

It supports Citrix / Terminal Server environments.

Origin cookie redirect has the following disadvantages:

Cookies are not always allowed by company policies.

Individual users can disable cookies in the user agent.

Not all user agents are cookie-enabled.

Multiple redirections take place per each user request.

Origin IP redirect is the alternative to using cookies as surrogate. In this case, the ProxySG
associates the successful authentication to the IP address of the client from where the request is
coming. IP surrogate is conceptually much easier and lightweight than cookie surrogate. However
the main disadvantages of IP surrogate are:

Authentication credentials are associated to the same IP address for the pre-set TTL time; if
multiple users log on the same IP they cannot be separated.

Requests coming from a NATed IP address are all associated to one user.

It does not support Citrix / Terminal Server environments.

The main advantage of IP surrogates are:

Reduced number of redirects.

They work in all environments.

They support user agents that are not cookie-enabled.

130 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 8: Using Authentication In Transparent Proxy Mode

Cookie Surrogate Authentication

6OLGH&RRNLHVXUURJDWHILUVWDXWKHQWLFDWLRQ

Instructors Note: This slide is usually intimidating. Go over it very slowly. Repeat the steps at
least twice. There are four major steps:
1. The user agent is being redirected and challenged for authentication by the ProxySG.
2. The authentication credentials supplied by the user agent are validated by the
authentication server.
3. The user agent receives the authentication cookies for both the virtual URL and the
destination URL.
4. The ProxySG finally retrieves the content and serves it to the requesting user agent.

After you describe the details of this process, you need to show the Live HTTP Headers trace
in Firefox. Use a relatively simple site like http://www.google.com and an LDAP realm. Remind
the students that NTLM is a challenge/response, multistep authentication process; showing
origin cookie redirect authentication with and NTLM realm is confusing.
You should also show what the different query string parameters contain. You need to have a
base64 converter.
Note: When you are decoding the query string in Step 3, decode only the part after the !
character.

Slide 8-3 shows the sequence of actions that are necessary when a user is first challenged for
authentication in a transparent proxy deployment. Slide 8-4 shows the steps for further user
requests after the first authentication challenge, and Slide 8-5 details what happens then a user
accesses a site that was already visited after the initial authentication.
Note:

Slide 8-3 shows the interaction for an LDAP realm. NTLM authentication, because of
its challenge/response nature, requires more steps.

The authentication proceeds as follows:


1.

The user agent makes a request for the URL http://www.bluecoat.com; note that the GET
request is not proxy style.

Instructor Edition 131

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

2.

The proxy replies with a redirection request to the virtual URL. The additional query string
contains a reminder of what the original request URL was. The redirection request appears to
the user agent as coming from http://www.bluecoat.com.

3.

The user agent DNS resolves the IP address of the virtual URL and attempts to connect.

4.

The ProxySG returns an HTTP 401 response to the user agent. As far as the user agent is
concerned, the request is coming from the virtual URL.

5.

The user agent reissues the same GET request, this time including the authentication
credentials, base64 encoded. The credentials, if you use basic authentication, are passed in
clear text (just base64 encoded); this is not a behavior of the ProxySG but a feature of the HTTP
protocol.

6.

The ProxySG returns a new redirect request to the user agent. At this point, since the
authentication was successful, the ProxySG is trying to place a cookie for the originally
requested URL (in this case http://www.bluecoat.com). The user agent is being redirected to
the original URL; however, the ProxySG included a query string that contains information
about the successful authentication. The response also includes a SET-COOKIE header. This
request appears to the user agent as coming from the virtual URL. Therefore, by placing an
authentication cookie for the virtual URL, ProxySG creates a way to remember that the user
has already authenticated when a new site is being requested. See Slide 8-4 for more details.

7.

The user agent opens the connection to the original URL; note the additional query string that
is included.

8.

The ProxySG returns a final redirection request with a SET-COOKIE header. This request
appears to the user agent as coming from the http://www.bluecoat.com URL. Therefore, by
placing an authentication cookie for the bluecoat.com domain, the ProxySG has a way to
remember that the user has already authenticated when this domain is being requested again.
See Slide 8-5 for more details.

9.

The user agent performs the redirection. Since the cookie is received and accepted, the request
contains the authentication cookie. This cookie notifies the ProxySG that the request has
already been authenticated.

10. Finally, the ProxySG forwards the user agents request to the http://www.bluecoat.com URL,
after it has removed the authorization cookie because it may interfere with the transaction.

132 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 8: Using Authentication In Transparent Proxy Mode

Cookie Surrogate Authentication

6OLGH&RRNLHVXUURJDWHVXEVHTXHQWUHTXHVWV

Instructors Note: This slide describes what happens when the user requests a new site,
which was not previously visited, after the initial authentication. The process was detailed in
Slide 8-3. The key point of this slide is that Step 4 and Step 5 are missing. Point out that now
in Step 3 the initial GET request to the virtual URL contains the authorization cookie. This is the
reason that Steps 4 and 5 are no longer necessary.

In the Slide 8-4, you can see the interaction between the user agent and the ProxySG when the user
agent has already authenticated to the ProxySG, but it is now requests a different site from the one
used to authenticate. Slide 8-4 shows the requested URL as http://www.cacheflow.com; this is
just a sample transaction.
Important: A user agent is considered already authenticated if it can present a valid
authorization cookie when making a GET request to the virtual URL, as shown in
the slide.

When a user agent is already authenticated, the ProxySG does not need to issue a HTTP 401
response; as matter of fact, in the diagram above you can clearly see that Step 4 and Step 5 (as
described in Slide 8-3) are missing.

If this is the first time that the user agent is asking for this domain, it cannot present and
authorization cookie for that domain; for this reason, some redirections are still occurring.

Instructor Edition 133

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Cookie Surrogate Authentication

6OLGH&RRNLHVXUURJDWHUHWXUQWRDSUHYLRXVVLWH

Instructors Note: This slide describes the interactions between the ProxySG and an
authenticated user agent when the latter is making a request for a URL that has been already
visited the requested URL. Point out again the definition of authenticated user agent as
described in the previous page.

Slide 8-5 clearly illustrates the simplicity of the authentication mechanism for requests to sites that
the user has already requested.
If the user agent is able to present the valid authentication cookie to the ProxySG, there is no need
for the proxy to authenticate that request. Note that in Slide 8-5, there is no communication
between the ProxySG and the authentication server.

In an environment using NTLM authentication with BCAAA, you can actually see less load on the
BCAAA for transparent proxy deployment than you would see in explicit mode. While, at least in
theory, a transparent deployment can put the same load on BCAAA as an explicit deployment,
this does not happen in practice.
The BCAAA load (for NTLM) is directly proportional to the frequency of new connections that
need to be authenticated.
For transparent deployments:

A surrogate credential is normally used. authenticate.mode(origin) is rarely used in


forward proxies (it makes more sense in a reverse proxy). This reduces the frequency of new
connection authentications to one per surrogate expire. The default expiration time is 15
minutes, which translates to one authentication request per browser every 15 minutes.

Most browsers talk to origin servers using HTTP/1.1 by default. This enables the use of
persistent connections, which significantly reduces the number of new connections that have
to be authenticated.

For explicit proxies, authenticate.mode(proxy) is the default, so no surrogate is used. When


using explicit proxy, Internet Explorer defaults to HTTP/1.0. HTTP/1.0 does not support
persistent connections. As a result, many more authentication requests are sent to the BCAAA.

134 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 8: Using Authentication In Transparent Proxy Mode

IP Surrogate Authentication

6OLGH,3VXUURJDWH

Instructors Note: You need to point out that IP surrogate may lead, even if rarely, to users
being associated with someone elses traffic. However, it is important to be able to support IP
surrogate, as many user agents do not understand cookies. Point out that this is not a feasible
solution for users behind a NATing device.
IP surrogates can be very useful in scenarios where cookies are not available or are simply
impractical. Often there are user agents that use HTTP as the protocol to communicate with a
server; however, these user agents do not support cookies. If an IT administrator needs to
authenticate requests coming from these user agents, IP surrogate is the only alternative.
The authentication credentials are associate with the IP address of the user agent; after a
custom-defined time to live (TTL) period, the authentication credentials are refreshed.

As long as the requests are made within the defined TTL, there is no further authentication. This
could lead to some requests being associated to the incorrect user. For instance, user A and user B
share the same machine (but have two different login names). User A logs on and start browsing;
he is challenged for authentication. If user B logs on the same machine before the TTL for user A
expires, she is not challenged for authentication and her traffic is recorded under user As login
name. This situation may be infrequent, but you should be aware of it.
In Slide 8-6, you can clearly see how the transaction between the ProxySG and the user agent is
some what simpler, even for the first authentication request, than it was for the cookie surrogate
authentication. Delivering cookies is more complex than it may first appear.

Instructor Edition 135

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Transparent Proxy Settings


Origin Cookie Redirect
Session Cookies
Persistent Cookies

Define the Time To Live (TTL)

Origin IP Redirect
Persistent IP

Define the TTL

6OLGH7UDQVSDUHQWSUR[\VHWWLQJV

Instructors Note: This section lists the different parameters that you can set for transparent
proxy authentication and what the parameter values mean. You should reduce the TTL for the
persistent IP authentication surrogate to 1 minute and show how the system reacts to it and
what the user experiences. Make sure that you access separate and different Web sties each
time you do the test. You should also clear browser cache and cookie jar, as well as the
ProxySG cache.
Slide 8-7 shows the parameters that you can define in the Management Console, relevant to
transparent authentication surrogate credentials.

You can select the transparent proxy method Cookie-based or IP address-based. The default is
Cookie. If you select Cookie, Cookie Type radio buttons are available. Click either Session, for
cookies that are deleted at the end of a session, or Persistent, for cookies that remain on a client
machine until the cookie TTL is reached or the credentials cache is flushed. The default is Session.
If you select Persistent, enter the Cookie TTL. If you choose IP address-based, enter the IP address
TTL. The default for each is 15 minutes.

A value of 0 (zero) for the IP address TTL re-prompts the user for credentials once the specified
cache duration for the particular realm has expired. For authentication modes that make use of IP
surrogate credentials, once the IP address TTL expires the proxy re-challenges all client requests
that do not contain credentials for which an IP surrogate credential cache entry previously existed.
If at this point the client supplied a different set of credentials than previously used to authenticate
for which an entry in the user credential cache still exists the proxy fails authentication. This
is to prevent any another client from potentially gaining network access by impersonating another
user by supplying his or her credentials. However, once the user credential cache entry's TTL has
expired you can supply a different set of credentials than the ones previously used for
authentication.
In this screen you can also control the value for the Virtual URL. The default is www.cfauth.com.
You should change the virtual hostname to something meaningful to you, preferably the IP
address of the ProxySG, unless you are doing secure credentials over SSL. Using the IP address of
the ProxySG enables you to be sure that the correct ProxySG is addressed in a cluster
configuration.

136 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 8: Using Authentication In Transparent Proxy Mode

You can configure the same parameters using the CLI.


1.

At the (config) command prompt, enter the following command:


SGOS#(config) security transparent-proxy-auth method {cookie | ip}

Q If you select cookie-based transparent proxy authentication, enter the following command
to specify persistent cookies or cookies that persist for the current session only:
SGOS#(config) security transparent-proxy-auth cookie {persistent
|session}

Q If you select persistent cookies, enter the following command to specify the minutes that
the cookie persists:
SGOS#(config) security transparent-proxy-auth time-to-live
persistent-cookie minutes

Q If you select IP-based transparent proxy authentication, enter the following command to
specify that the user be re-prompted for credentials after the number of TTL minutes
specified:
SGOS#(config) security transparent-proxy-auth time-to-live ip
minute

2.

To specify the virtual URL for cookie-based authentication, enter the following command:
SGOS#(config) security transparent-proxy-auth cookie virtual-url url

3.

(Optional, if you choose cookie-based) Add the virtual host domain to the DNS service for
your organization so that browsers, when redirected to the virtual URL, can resolve the
hostname in the URL. (If you use the virtual hostname provided by Blue Coat
www.cfauth.com you do not need to add the hostname to the DNS service.)

Important: The settings only affect the default method for authentication if you select
authentication mode to auto. You can force the use of Cookie or IP surrogate
credentials in the VPM (or CPL), regardless of the settings detailed above.

Instructor Edition 137

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Authentication Modes

TCP
connection
Surrogate

Origin
Challenge with
redirection

Form Challenge
with redirection

originorigincookie

formcookie

originorigin-cookiecookieredirect

form-cookie-redirect

origin-ip

form-ip

origin-ip-redirect

form-ip-redirect

Origin
Challenge

proxy

origin

Cookie
Surrogate

IP
Surrogate

Form
Challenge

Proxy
Challenge

proxy-ip

Explicit
Proxy

Reverse Proxy

Transparent Proxy

6OLGH$XWKHQWLFDWLRQPRGHV

Instructors Note: Slide 8-8 shows the different authentication modes, grouped by
deployment option, authentication mode, and surrogate type. The options that are in bold text
and underlined are the modes selected when the authentication is set to Auto.

The left column shows the surrogate types. Point out that TCP Connection is the preferred
one, for it guarantees correct user authentication at all times and works easily with virtually
any user agent. In explicit proxy mode, the default option is to authenticate users using TCP
connections; in transparent proxy mode, the default option is to authenticate users using origin
cookie redirect. In reverse proxy deployments, you should always select the particular
authentication option that you intend to use (origin cookie is recommended). It is difficult for
the proxy to exactly determine that it is operating in reverse proxy mode, rather than in forward
proxy mode.
The different selections are available from the VPM, when you set an Authenticate or Force
Authenticate action in the Web Authentication Layer. You should go over this slide and the
show the VPM and the different options available.

You can control the way the ProxySG interacts with the client for authentication by controlling the
authentication mode. The mode specifies the challenge type and the accepted surrogate credential.
Note:

Challenge type is the kind of challenge (for example, proxy or origin-ip-redirect)


issued. Surrogate credentials are credentials accepted in place of the users real
credentials.

Auto: The default; the mode is automatically selected, based on the request. Chooses among
proxy, origin-IP, and origin-IP-redirect, depending on the kind of connection (explicit or
transparent) and the transparent authentication cookie configuration. For streaming
transactions, authenticate.mode(auto) uses origin mode.

Proxy: The ProxySG uses an explicit proxy challenge. No surrogate credentials are used. This
is the typical mode for an authenticating explicit proxy. In some situations proxy challenges
will not work; origin challenges are then issued.

138 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 8: Using Authentication In Transparent Proxy Mode

Proxy-IP: The ProxySG uses an explicit proxy challenge and the client's IP address as a
surrogate credential. Proxy-IP specifies an insecure forward proxy, possibly suitable for LANs
of single-user workstations. In some situations proxy challenges will not work; origin
challenges are then issued.

Origin: The ProxySG acts like an OCS and issues OCS challenges. The authenticated
connection serves as the surrogate credential.

Origin-IP: The ProxySG acts like an OCS and issues OCS challenges. The client IP address is
used as a surrogate credential. Origin-IP is used to support NTLM authentication to the
upstream device when the client cannot handle cookie credentials. This mode is primarily
used for automatic downgrading, but it can be selected for specific situations.

Origin-cookie: The ProxySG acts like an origin server and issues origin server challenges. A
cookie is used as the surrogate credential. Origin-cookie is used in forward proxies to support
pass-through authentication more securely than origin-ip if the client understands cookies.
Only the HTTP and HTTPS protocols support cookies; other protocols are automatically
downgraded to origin-ip. This mode could also be used in reverse proxy situations if
impersonation is not possible and the origin server requires authentication.

Origin-cookie-redirect: The client is redirected to a virtual URL to be authenticated, and


cookies are used as the surrogate credential. Note that the ProxySG does not support
origin-redirects with the CONNECT method.
Note:

During cookie-based authentication, the redirect to strip the authentication cookie


from the URL is logged as a 307 (or 302) TCP_DENIED.

Origin-IP-redirect: The client is redirected to a virtual URL to be authenticated, and the client
IP address is used as a surrogate credential. Note that the ProxySG does not support
origin-redirects with the CONNECT method.

Form-IP: A form is presented to collect the user's credentials. The form is presented whenever
the user's credential cache entry expires.

Form-Cookie: A form is presented to collect the user's credentials. The cookies are set on the
OCS domain only, and the user is presented with the form for each new domain. This mode is
most useful in reverse proxy scenarios where there are a limited number of domains.

Form-Cookie-Redirect: A form is presented to collect the user's credentials. The user is


redirected to the authentication virtual URL before the form is presented. The authentication
cookie is set on both the virtual URL and the OCS domain. The user is only challenged when
the credential cache entry expires.

Form-IP-redirect: This is similar to form-ip except that the user is redirected to the
authentication virtual URL before the form is presented.

Important: Modes that use an IP surrogate credential are insecure: After a user has
authenticated from an IP address, all further requests from that IP address are
treated as from that user. If the client is behind a NAT, or on a multi-user system,
this can present a serious security problem.

The default value is auto. The values that appear underlined and in bold text in the Slide 8-8,
represent the authentication mode that the ProxySG selects, based on the deployment, when auto
is selected as authentication mode.

Note:

ProxySG cannot easily distinguish between explicit forward proxy requests and
reverse proxy requests. If your ProxySG is operating in reverse proxy mode, you
should not use auto, but select the authentication mode that you prefer.

Instructor Edition 139

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

140 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 8: Using Authentication In Transparent Proxy Mode

Instructors Notes for Transparent Mode Proxy Authentication Lab


Overview

You should show the details of the transparent authentication mechanism using Firefox live HTTP
headers, Notepad, and a base64 decoder. You can find a base64 decoder at
http://makcoder.sourceforge.net/demo/base64.php. Follow the steps below:
1) Configure your system for transparent proxy.

2) Enable authentication using an LDAP realm (ADS with LDAP ok).

3) Clear browser cookie jar, cache, and clear the ProxySG cache (Management Console >
Maintenance > General > Clear the system cache).
4) Start live http header.

5) Go to http://www.google.com.

6) Enter your authentication credentials; do not use your own secure password because it will
appear in clear text.
7) Copy and paste the trace in the live http headers in Notepad.

8) Analyze one query string at the time and decode it with base64 decoder.

Point out clearly to the students that the password appears in clear text because that is the
expected behavior of basic authentication, as defined in the HTTP RFC. It is not a weakness or
vulnerability of the ProxySG.

Computer Hardware and Software Requirements


Table 8-1: Requirements for the Instructor
Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

F Wireshark

F verion 0.99

Table 8-1: Requirements for Students


Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

F Wireshark

F version 0.99

Instructor Edition 141

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

142 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 9: Understanding Kerberos Authentication (Optional)

Estimated Lesson Time: 45 minutes

Instructors Note: The goal of this chapter is to explain Kerberos authentication in general
terms. If the students understand how the authentication works, they can better grasp how to
set up the Blue Coat SG. Kerberos configuration for the ProxySG may seem complex. You
need to use this chapter to make sure that the students understand that the relative difficulty of
enabling Kerberos has to do with how the protocol works and is not a ProxySG issue. You
should be able to show a packet capture of the transactions happening between the different
parties involved in the authentication process. More information is available in the lab. This
chapter discusses the Kerberos authentication as it is implemented in Microsoft Active
Directory, which is not necessarily the same as RFC 1510 or the same as MIT Kerberos v5.
The introduction of RFC 1510 says, Kerberos provides a means of verifying the identities of
principals, (e.g., a workstation user or a network server) on an open (unprotected) network.

Since its inception, the Kerberos protocol was designed to handle authentication in a network
environment, which cannot be assumed to be secure.

Several fundamental differences exist between the Kerberos model and the NTLM (or LAN
Manager) model. The single biggest difference between the two is that in the Kerberos model,
neither server nor clients are assumed to be trusted a priori. Both the client and the server need to
trust a third entity, which is in charge of verifying the identity of each party involved with
authentication. Another difference is the concept of obtaining authentication for a principal. A
client does not require simple authentication but more precisely asks for authentication for a
principal (i.e., a file server or Web server).

The client issues a request to an Authentication Server (AS) for credentials for a specific principal.
The AS replies with an authentication ticket and an encryption key. The client uses the encryption
key to exchange data with the server over a symmetric cipher. The session key sent to the client is
encrypted in the ticket using a key shared between the AS and the client. The ticket contains the
same session key and the client identification. This information is encrypted in the ticket using a
key shared between the AS and the principal for which the client asked to authenticate.
Additional measures are defined in the protocol to void any attempts to use a reply attack.

Instructor Edition 143

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

What is Kerberos?

Three-headed dog guardian of the underworld


in Greek mythology and Dantes Inferno (Cerberus)

Secure and high-performance mutual authentication


protocol designed by M.I.T.
Three main components
Client

Server

Trusted third party

6OLGH.HUEHURVEDFNJURXQG

Instructors Note: This slide introduces the basic concepts in Kerberos. The name of the
mythological three-headed dog is appropriate because there are three components necessary
to implement this authentication protocol. Point out that the Microsoft implementation of
Kerberos may not follow exactly the same parameters as the original MIT version.

You need three components in order to implement Kerberos authentication in your network.
Kerberos is the name of the three-headed dog that guarded the underworld in ancient Greek
mythology. The creature appears in Dantes Inferno under its better-known Latin name, Cerberus.
The three heads in the Kerberos protocol represent:
1.

A client that needs to be authenticated

2.

The Key Distribution Center (KDC), which manages the tickets necessary to access resources
and services on the network

3.

A server hosting the services that users want to access

The domain controllers in Active Directory play the role of the KDC. The KDC processes the
authentication request from the clients and generates the necessary tickets that the clients need to
present to the services and resources on the network in order to get access to them.

144 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 9: Understanding Kerberos Authentication (Optional)

NTLM vs. Kerberos


NTLM

Kerberos

Servers need to authenticate


users to the DC

Servers authenticate users


using credentials presented

Servers are assumed always


to be trusted and genuine

Neither servers nor clients are


trusted a priori

Need to build point-to-point


trust relation between domains

The trust relations are transitive;


all members are trusted

Proprietary protocol

Standard based on M.I.T


Kerberos version 5

6OLGH'LIIHUHQFHVEHWZHHQ17/0DQG.HUEHURV

Instructors Note: This slide is designed to help student transition from the authentication
model in NTLM to Kerberos. Go over each point and try to explain the differences. For
instance, spend some time reminding the students how, in the NTLM model, authentication
credentials are always validated against a DC: The DC receives many authentication
requests. Kerberos uses a different approach (which will be explained later). Clients can
authenticate servers; this option is not available in NTLM. This provides a higher level of
security and prevents spoofing attacks. Finally, use the idea of transitive trust to explain why in
AD, the trusts are by default two-way (native mode only).

Kerberos represents a final break from the old and relatively insecure NT LAN Manager
authentication protocol. If you have an AD forest in native mode, NT LAN Manger is disabled.
Three of the major improvements in Kerberos authentication are:

Increased security

Kerberos uses session keys that have a short time to live between client and server.
Authentication requests are validated using a timestamp verification to prevent reply attacks.
Kerberos uses a stronger cipher than NTLM.

Fewer authentication requests must go through the KDC (DC)

Clients obtain tickets to present to the server. The server does not need to contact the KDC to
authenticate a client.

Clients can authenticate the server they need to access

Mutual authentication is possible with Kerberos. A client can ask a server (or service) to verify
a timestamp message. The message is encrypted with a key that only the KDC and the server
should know. If the server can decrypt the message and show it to the client, then the server is
what it claims to be.

Instructor Edition 145

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Basic Concepts

Two parties know a shared session key


Knowledge of the key confirms identity
Deliver the key securely among partners

Kerberos partners share cryptographic key

Requires symmetric keys


Need for long-term key for secure data exchange
Derived from the users password

6OLGH%DVLFFRQFHSWV

Instructors Note: This is where you need to start diving into Kerberos. You can try an
analogy with digital certificates and PKI but you need to be careful: Kerberos is not a PKI! An
important concept in this model is the use of a key to encrypt a message containing another
key (session key). You can associate the long-term key with the public/private key pair, and
the session key then plays a similar role in both models. The client and the server trust each
other based on the fact that they share the same session key, which was generated by the
KDC.

In Kerberos, the client can connect to the server by presenting proper credentials to the server
where it wants to authenticate. These credentials are obtained from the KDC. The client issues a
request to the KDC for authentication to a given service; if the client request is approved, then the
KDC sends a special message back to the client. This message is called a ticket. The ticket consists
of two parts: One is encrypted with a session key shared between the client and the KDC; the other
is encrypted with the servers long-term key, which is known only to the KDC and the server. (The
client cannot read this area of the ticket.)
The client can extract, from the first part of the ticket, the session key for communication with the
server. The session key is generated by the KDC. A copy of the same session key is stored by the
KDC in the second part of the ticket (encrypted with the servers long term key).
Important: The long-term key is a one-way hash of the users password.

146 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 9: Understanding Kerberos Authentication (Optional)

Ticket Structure

6OLGH.HUEHURVWLFNHW

Instructors Note: The screen capture above shows the field structure of a Kerberos ticket
and also an Ethereal packet capture. Note that this is the ticket that the client presents to the
server; this is not the ticket that the client received from the KDC. You can easily replicate this
packet capture: this is the authentication ticket that the IE browser sends to the ProxySG in
response to an HTTP 401 message.

The slide above shows clearly how the ticket (in this case the one the client presents to the server)
is divided in two parts. The first part is in clear text. The second part is encrypted (using RC4) with
the long-term server key. The second part of the message is exactly the same as it was received by
the client from the KDC. Because it is encrypted with the server long-term key, the client cannot
read its content; only the server can. The table below summarizes the description of each field and
its status.
Table 9-1: Main Ticket Fields
Encrypted

Field Name

Description

No

TKT-VNO

This is the protocol version. Kerberos v5 is the one used here.

No

REALM

Contains the name of the realm where the client authenticated. This
is the same as the server realm; a KDC issues tickets only for server
in its own domain (realm).

No

SNAME

Servers name

Yes

FLAGS

1 bit field (32 byte space, only 9 allocated) each flag can be set to
ON (1) or OFF (0)

Yes

KEY

This is the session key shared by the client and the server.

Yes

CREALM

This is the realm where the client is located. This can be different
than the one of the server. (See Slide 9-9.)

Yes

CNAME

Clients name

Yes

AUTHTIME

Timestamp of the clients initial authentication to the KDC

Instructor Edition 147

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Key Distribution Simplified

6OLGH6LPSOLILHGNH\GLVWULEXWLRQPRGHO

Instructors Note: This slide does not represent how Kerberos really works. You need to
make it very clear to the students that this slide is a great simplification of the process. The
slide depicts is a logical flow of data, rather than an actual one. The next slide describes the
process more accurately.
This slide simplifies the Kerberos authentication and describes it from a logical rather than
functional standpoint.

In this example George (the client) wants to authenticate with Bob (the server). Imagine the
process being divided into three steps:
1.

George asks the Key Distribution Center for a session key to talk to Bob.

2.

The KDC generates a session key and sends it to George encrypted with Georges long-term
key.

3.

The KDC sends the same session key to Bob encrypted with Bobs long-term key.

Once the two parties have received the session key from the KDC, the do not need to have any
further interaction with it. As long as the session key is valid (the time value is configured), the
KDC is no longer involved.
Note:

The reduced need for communication between the client/server and the KDC (DC) is
one of the main advantages of Kerberos over NTLM.

148 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 9: Understanding Kerberos Authentication (Optional)

Session Tickets Actual

6OLGH$FWXDONH\GLVWULEXWLRQPRGHO

Instructors Note: This slide represents the model more accurately than the previous slide.
The main difference is that the KDC never sends the ticket with the session key directly to the
server but sends two pieces of information to the client. Point out the difference and proceed
to the next slide.

The previous slide shows the KDC generating two tickets and sending one to the client and the
other to the server. Logically you can assume that is the process; however, in reality, the KDC does
not send any information to the server.
The actual process is as follows:
1.

George asks the Key Distribution Center for a session key to talk to Bob.

2.

The KDC generates a ticket and sends it to George. The ticket George receives from the KDC is
separated in two parts:

Q The client part, in which the session key is encrypted using the clients long-term key
Q The server part, in which the session key is encrypted using the servers long term-key

3.

George extracts and reads the session key from the client part of the ticket, which he can read
and then sends the rest, the server part, to Bob.

The client can only read the first, or client, part of the response received from the KDC. The part
that it does not understand is sent as-is to the server. Because this part is encrypted with the
servers long-term key, the server has no difficulty reading it.
Because only the server and the KDC know the servers long-term key, the server can trust the
ticket received by the client as authentic and generated directly by the KDC.

You can easily see how in this model, server and client can trust each other and the KDC because
the correct long-term and session keys are known to the appropriate parties.

Instructor Edition 149

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Authentication Service (AS)

6OLGH$XWKHQWLFDWLRQ6HUYLFH

Instructors Note: At this point you need to start detailing the fact that there are actually two
types of tickets: a ticket granting ticket (TGT) and a ticket granting service (TGS). Furthermore
you need to clarify the fact that the client and the KDC will use the client long-term key only
once in a selected (configurable) period of time.

Before discussing the details of the role of the Authentication Service (AS), it is necessary to clarify
that the Kerberos process uses two different types of tickets. The client obtains the first ticket when
it first logs on the network. This ticket is known as Ticket Granting Ticket (TGT). The other type of
ticket is used to obtain a ticket to obtain access to a given resource; this is called Ticket Granting
Service (TGS).
The AS assigns a TGT to the client. The client uses the information in the TGT to obtain a TGS. By
now, you should be able to imagine how the process works:
1.

The client connects to the KDC1 and requests a TGT.

2.

The AS responds with a TGT which consists of two parts:

Q A session key encrypted with the clients long-term key


Q A session key encrypted with the KDC long-term key

3.

The client connects to the KDC, using the session key, to request a TGS. In essence you need to
change the phrase encrypted using the clients long-term key on the previous page, with the
phrase encrypted using the session key.

Now that the difference between TGT and TGS is clear, it is time to detail the authentication steps
and explore some more of the unique security features of Kerberos authentication.
George wants to authenticate and obtain access to a certain service; this is how the process flows:
1.

George logs on by entering his username and password.

2.

The Kerberos client on his machine generates the long-term key, which is a one-way hash
function applied to the password.

1. The AS is one of the roles that the KDC assumes in the Kerberos model.

150 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 9: Understanding Kerberos Authentication (Optional)

3.

The request for a TGS is sent to the KDC. It contains:

Q Username (George in this case)


Q Service name for which the TGS is being requested
Q Logon timestamp encrypted with the clients long-term key

4.

The KDC receives the request and looks up Georges long-term key.

5.

The KDC decrypts timestamp.

6.

The timestamp is verified and must be within a certain tolerance value or the request will be
discarded a tentative reply attack.

7.

The KDC sends George the TGT, which includes the session key for George to talk the KDC,
and the TGT encrypted with the KDC long term key (which contains the same session key).

Note:

Georges long-term session key is used only during the initial request to the KDC.
Once George receives the TGT, it will use the session key for any further
communication with the KDC.

Note:

It is Georges responsibility to manage the session keys both with the KDC and the
server. Neither the server nor the KDC keep any memory of the session key.

Instructor Edition 151

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Ticket-Granting Service

6OLGH7*67LFNHW*UDQWLQJ6HUYLFH

Instructors Note: Use this slide to clarify once and for all that the KDC has two
subcomponents to it:
The AS, which is the Authentication Service (issues the TGT)

The TGS, which generates tickets to access the service that the client requested.

In this slide, the client has already authenticated using the AS and now is requesting access to
a file server. The TGS generates the proper ticket and sends it to the client.

The client needs to have a valid ticket to access a certain resource on the Internet. In this case you
can assume that the client wants to access a file server. The client has authenticated already and it
received the TGT from the AS component of the KDC.
Three steps are necessary for the client to access the file server:
1.

The client sends a request to the TGS component of the KDC. The request contains the TGT
that the client received from the AS. In essence, the request sent by the client is encrypted
using the session key obtained from the AS at the logon time.

2.

The TGS component sends a session key back to the client separated in two components:

Q A session key encrypted with the session key shared between the client and the KDC
Q A session key encrypted with the file servers long-term key

3.

The client connects to the file server presenting the ticket it obtained from the TGS. Because
the ticket is encrypted with the file servers long-term key, which only that server and the
KDC know, the client request is accepted as genuine (of course assuming that the file server
can correctly decrypt the ticket).

152 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 9: Understanding Kerberos Authentication (Optional)

Authentication Multiple Domains

6OLGH5HIHUUDOWLFNHWV

Instructors Note: This slide allows you to introduce and explain the concept that trust
relationships in AD are transitive. (If Domain A trusts Domain B, and Domain B trusts Domain
C, then A and C trust each other as well.) The explanation should be rather simple at this
point. The key concept is in the inter-domain key, which is created when the trust relation is
originally created. This is very similar to a session key between a client and a server. Using
this angle, it should be rather easy to explain this concept.

Users in one domain can access resources in another domain, as long as there is a path of trusts
between the two. In the scenario illustrated above, the client in Domain A wants to access a file
server in Domain B. You can extend the scenario to something more complex as the one shown in
the figure below.

Figure 9-1: Path of trusts

A client in the london.emea.bluecoat.com domain can access any resource in the other domains,
all the way to apac.bluecoat.com domain, which is the most remote.

Instructor Edition 153

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Kerberos uses the concept of referral tickets to allow clients in one domain to obtain access to
resources in another domain. The referral ticket works very similarly to the other tickets that you
have encountered so far.

When a trust relationship is created, a session key is created and shared between each domain
pair. For instance, in the diagram above, there is a session key between london.emea.bluecoat.com
and emea.bluecoat.com, another one between emea.bluecoat.com and bluecoat.com, and finally a
third one between bluecoat.com and apac.bluecoat.com.
In the example illustrated in the slide:
1.

The client in Domain A sends a request to the KDC in Domain A. The request is encrypted
using the session key, which the client shares with that domain. (The client is assumed to have
already authenticated.)

2.

The KDC replies with a TGT (ticket-granting-ticket) for Domain B. As always, one part of the
TGT is encrypted with the session key the KDC in Domain A shares with the client and the
other part is encrypted with the session key, which the KDC in Domain A shares with the
KDC in Domain B. This ticket contains a session key for the client to share with Domain B.

3.

The client now presents the ticket to Domain B. Because that information is encrypted with the
session key that Domain A and Domain B share, Domain B can trust the ticket as authentic
(generated by the KDC who manages the realm where the client is coming from).

4.

The KDC in Domain B issues a TGT to the client. The TGT is divided into two parts:

Q A session key encrypted with the session key shared between the client and the KDC in
Domain B

Q A session key encrypted with the file servers session key, which it shares with the KDC in
Domain B

5.

The client in Domain A can present the TGT to the file server in Domain B. Because the TGT is
encrypted using the session key, which the file server shares with the KDC in Domain B, the
server can accept the request.

Note:

If there are N intermediate domains between the client and the server, the process
operates virtually in the same way. Steps 3 and 4 are repeated N-1 times.

154 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 9: Understanding Kerberos Authentication (Optional)

Service Principal Names (SPN)


SPN identifies a service

Once the service is identified you can authenticate to it

Must be unique in a forest

One SPN is associated with only one account

You need to match a SPN with an Active Directory


account (you can use LocalSystem account)

6OLGH6316HUYLFH3ULQFLSDO1DPHV

Instructors Note: The concept of SPN is extremely important in understanding how to


configure and set up the ProxySG to support Kerberos authentication. Spend some time on
this.

The Service Principal Name (SPN) represents a service that is available for Kerberos
authentication. Only services listed as SPN are available for users/clients to authenticate. The SPN
must be unique in any Active Directory forest. You can associate the SPN to a user account or to a
machine account. In either case, a given SPN can only be associated with one account.
The Windows resource kit contains an executable command that allows a domain administrator to
add, remove, and list SPN in a domain (forest). You can execute the command as shown below
and obtain a list of the options available.

c:\Program Files\Resource Kit>setspn [Enter]


Usage: setspn [switches data] computername

Where "computername" can be the name or domain\name

Switches:

-R = reset HOST ServicePrincipalName


Usage:

setspn -R computername

-A = add arbitrary SPN


Usage:

setspn -A SPN computername

-D = delete arbitrary SPN


Usage:

setspn -D SPN computername

-L = list registered SPNs


Usage:

setspn [-L] computername

For instance, if you have setup a new Web server and you want to use Kerberos authentication,
you need to add it as SPN to the domain where you registered it.

Instructor Edition 155

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

156 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 10: Using Kerberos Authentication

Estimated Lesson Time: 25 minutes

Instructors Note: This chapter focuses on configuring the Blue Coat SG and Blue Coat
Authorization and Authentication Agent (BCAAA) to support Kerberos authentication. Before
you get into the details of the Blue Coat implementation, review the fundamental details of
Kerberos authentication separately from Blue Coat. Verify that the students are familiar with:
The concept of Service Principal Name (SPN) and why you need to create an SPN
The difference between TGT and TGS

Direct authentication between parties in Kerberos, which does not require KDC intervention
If your students are familiar with these concepts, this chapter will be an easy one. Remind the
students that, at any time, the Windows authentication subsystem may decide to downgrade
to NTLM.

The previous chapter discussed the details of Kerberos authentication apart from the ProxySG. In
this chapter, you will explore the system requirements and configuration necessary to support
Kerberos authentication with the ProxySG.
There are several constraints, independent from the ProxySG, that come into play when you
decide to use Kerberos authentication. Kerberos authentication requires:

That the ProxySG be deployed in transparent proxy mode

That Internet Explorer version 6 is the user agent (UA)

The configuration of the Blue Coat Authorization and Authentication Agent (BCAAA) and the
Integrated Windows Authentication (IWA) requires you to follow some rigorous steps.
Unfortunately, the Windows authentication subsystem may decide to downgrade from Kerberos
to NTLM without warning. The chapter gives you some hints on how to verify that the UA and
the ProxySG have successfully negotiated and carried out Kerberos authentication.

If you want to have one or more than one BCAAA machine, you need to make a planning
decision; configuration steps vary depending on the choice you make. Because an SPN can be
associated only with one AD account, running more then once BCAAA requires the agent to run
as a domain user account, rather then as a Local System account. You also need to configure your
DNS and WINS servers to resolve the virtual URL to the IP address of the ProxySG. The virtual
URL that you specify for Kerberos authentication cannot be an IP address. The virtual host must
appear to be part of the Kerberos realm. In other words, the virtual URL must either have no dots,
or it must be a fully qualified DNS name in the same domain as that administered by the AD
server.

Forms authentication modes cannot be used with an IWA realm that allows only NTLM/Kerberos
credentials. If a form mode is in use and the authentication realm is an IWA realm, you receive a
configuration error.
Important: You cannot enable only Kerberos support in an IWA realm. An NTLM challenge
will always be offered as a potential alternative to Kerberos.

Instructor Edition 157

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

General Information
Requirements

SGOS 4.2.x or higher


BCAAA-100 or higher
Internet Explorer 6.x or higher
Transparent proxy deployment

Authentication Modes

Origin-*-redirect (full support)


Origin-* (limited support)

6OLGH6\VWHPUHTXLUHPHQWV

Instructors Note: This is an important slide. You need to clarify the system requirements to
implement Kerberos. Be sure to tell students that IE 7.0 has not been tested and is, at the
moment, not supported. Also quickly remind students of the steps involved in the transparent
authentication and what origin-cookie-redirect means.

Kerberos authentication was introduced in SGOS version 4.2.1.1; earlier versions of SGOS only
support NTLM authentication. The BCAAA for version 4.2.x is not backward compatible, and
earlier versions of BCAAA cannot work with SGOS 4.2.x. The realm name is IWA; Kerberos is one
of the available options.
The two most important requirements are:

The ProxySG must be deployed in transparent mode (bridging, WCCP, Layer 4 switch, default
gateway).

The UA must be Internet Explorer 6.x.

The authentication mode can be set to either origin-cookie-redirect or origin-ip-redirect; limited


support is available for origin-* modes. These modes are more difficult and are only supported in
some situations. The ProxySG can only handle a non-redirecting origin mode if the request is to a
hostname for which BCAAA knows the secret. In a reverse proxy deployment, the BCAAA can
presumably know the secret (since the ProxySG is impersonating the host with its permission).
However the, the ProxySG cannot impersonate an arbitrary host.

The SGOS will automatically downgrade the authenticate.mode() to origin-*-* in a variety of


situations, typically because the client is not capable of handling the desired mode. For example, if
the client cannot handle redirects, origin-cookie-redirect is downgraded to origin-cookie (and may
be further downgraded to origin-ip if the client does not understand cookies). If the ProxySG has to
downgrade the mode from redirecting to non-redirecting, it assumes that the BCAAA does not
know the server's secret and disables Kerberos (for that transaction at least).

158 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 10: Using Kerberos Authentication

General Information
Virtual URL

Define a suitable host name


Update DNS and WINS to resolve it to the Blue Coat SG

Installation of BCAAA

Register the machine as SPN

Realm Configuration

Create IWA realm (includes Kerberos)


Edit upgraded NTLM realms to add Kerberos support

6OLGH,QVWDOODWLRQVWHSV

Instructors Note: Remind the students what an SPN is and why you need to create an SPN
for the virtual URL on the BCAAA machine. You need to have Domain Admin permissions in
order to create the SPN. Upgraded NTLM realms do not have Kerberos authentication
enabled.

Before you do anything else, you need to define the virtual URL for the IWA realm. The virtual
URL must be a simple hostname or a fully qualified domain name that follows the rules on the
first page of this chapter. It must also resolve to the IP address of the ProxySG. Once you have
selected a suitable name for the virtual URL and you have created the necessary entries in your
DNS and WINS servers.
Once you have defined the virtual URL, you can register the SPN for that URL and associate it
with the BCAAA machine (or the account under which BCAAA agent is running; see page 160
and page 161 for more information on this topic).

Finally, you can create and configure the IWA for Kerberos support. If you created the realm as an
IWA realm, Kerberos is enabled by default. If you upgrade an existing NTLM realm, Kerberos is
disabled and you need to turn it on manually.

You can verify the Kerberos settings through the Management Console. Select Configuration >
Authentication > IWA > IWA General and then choose the appropriate realm name from the list.

Figure 10-1: Verifying Kerberos settings

Instructor Edition 159

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Single BCAAA

6OLGH6LQJOH%OXH&RDW$XWKRUL]DWLRQDQG$XWKHQWLFDWLRQ$JHQW

Instructors Note: This is the simplest way of deploying BCAAA to support Kerberos
authentication. You only need to execute the correct setspn command. You can use all of the
default settings during the BCAAA installation and you do not need to perform any
post-installation steps.

If you plan to have only one BCAAA machine, then the SPN can be registered with the NetBIOS
name of the machine on which BCAAA is running. BCAAA runs under Local System (the default
for services), and uses the machines shared secret to communicate with the Key Distribution
Center (KDC) and obtain tickets.

The primary advantage of this approach is convenience: It works with the default settings for
service installation. You just have to register the SPN for the machine. The disadvantage is that
you can have only one BCAAA server for the realm; you cannot have a backup server. This is
because the SPN is tied to the machine, and the browser chooses the SPN based on the URL that it
is fetching.
To set up the SPN you need to execute the command:

setspn -A HTTP/FQDN-of-host <name>, where <name> is the name of the machine (e.g.,
setspn -A HTTP/sg.bluecoat.com bcaaahost)
Note that the handling of the shared secret is done by Windows when the machine joins the
domain; there is no explicit knowledge of the shared secret by SGOS or by BCAAA.

160 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 10: Using Kerberos Authentication

Multiple BCAAAs

6OLGH0XOWLSOH%OXH&RDW$XWKRUL]DWLRQDQG$XWKHQWLFDWLRQ$JHQWV

Instructors Note: You can easily use two different BCAAAs, one as the primary agent and
the other as the secondary agent. Because the SPN can be associated only with one account,
you cannot run the BCAAA under the Local System account. You need to create an AD
account and run the service on all the BCAAA machines under this account. The lab will cover
the additional setup steps that are necessary to implement Kerberos authentication.

You can have more than one machine running BCAAA. You can, in fact, have a primary and a
secondary BCAAA server.

In this scenario, you need to create a service account for the BCAAA service and register the SPN
on the service account. This allows multiple servers to run BCAAA, all using the same account.
Because they are using the same account, they all know the shared secret, and any one can decrypt
the Kerberos ticket. The advantage of this scenario is the ability to have a backup BCAAA server.
The disadvantage is that additional configuration is required on the BCAAA machines. The
scenario is also slightly less secure because the BCAAA account password is shared among
multiple machines. The steps to configure this are (all steps require administrator privileges):
1.

Create a regular user account on the Active Directory server for the purpose of using it by the
BCAAA service.

2.

Give it a password.

3.

Install BCAAA as normal.

4.

Open the properties panel for the BCAAA service, and select the Log-on tab. Change the
account to the one you created in Step 1, and enter the password. When you hit OK, it may
warn you that the account has been given logon as service privileges.

5.

Verify in Local Security Policy's User Rights Assignment folder, that the above-mentioned
user account has been added to the list of the Log on as a service policy.

6.

The user must have modify/write privileges in the BCAAA folder.

7.

If group-based authorization is being done, then:

Instructor Edition 161

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Q Ensure that the user impersonation privilege is set for the SERVICE group. This URL gives
more information on how this is to be done:
http://support.microsoft.com/default.aspx?scid=kb;en-us;831218.

Q Ensure that the Active Directory computer account running BCAAA has the Trust
computer for delegation configuration property enabled.

8.

For all users that are authenticating to the ProxySG using IWA realms, their user accounts in
the Active Directory must have the permission to log onto the machine on which the BCAAA
server is running. This is a setting on the user's account properties. In the account tab is a
button called Log On To. Clicking on that specifies the domain computers can log onto.
The default is All computers. However, if your network setup is to restrict users to only log
onto specific computers in the user's list, then each of those users will need to also have the
name of the host running BCAAA added to this list.

9.

Run setspn -A HTTP/FQDN-of-host <name>, where <name> is the name of the account
created in step 1 (e.g., setspn -A HTTP/sg.bluecoat.com bluecoat\bcaaa)

All these machines now share the same secret with the KDC, and can decrypt service tickets
intended for the service described by the SPN.

162 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 10: Using Kerberos Authentication

Authentication Steps Kerberos

6OLGH$XWKHQWLFDWLRQVWHSV.HUEHURV

Instructors Note: This slide offers a high-level overview of the authentication steps that go
on between the ProxySG and the client when a successful Kerberos based authentication is
taking place. There are three important things that you need to point out to the students:
1) The 401 response must have the NEGOTIATE option. (NTLM and BASIC may also be
present.)
2) There is only one 401 response sent by the client. If you see two, then the system has
downgraded to NTLM. (See page 164 for more details.)
3) The NEGOTIATE reply from the client contains the GSS_API value.

Kerberos authentication requires transparent authentication. In order to successfully authenticate


users in this scenario, the ProxySG redirects all requests to a virtual URL. The client is under the
impression that it is authenticating into the virtual URL and not into a proxy server. (401
authentication is used and not 407.)
If the server (in actuality the ProxySG) supports Kerberos authentication, the 401 response shows
the option NEGOTIATE. Only if your UA receives this header, Kerberos authentication may take
place. The NEGOTIATE header is necessary but not sufficient condition for the process to
complete successfully.

Your UA should reply with the NEGOTIATE value set in the authentication field. If the
authentication subsystem on the client end has accepted the Kerberos authentication, it uses the
GSS_API option in the authorization request that sends to the virtual URL. This is a necessary and
sufficient condition for Kerberos authentication to complete successfully (provided that the
credentials are valid).
The Kerberos authentication requires only one step (contrary to NTLM where there are two
subsequent authentication responses from the server). By analyzing a packet capture, you can
easily see that only one 401 response is sent back to the client by the ProxySG (virtual URL). If you
can see two 401 responses, then the authentication has been downgraded to NTLM.

Instructor Edition 163

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Authentication Steps NTLM

6OLGH$XWKHQWLFDWLRQVWHSV17/0

Instructors Note: This slide offers a high-level overview of the authentication steps that go
on between the ProxySG and the client when the system has downgraded from Kerberos to
NTLM. There are three important things that you need to point out to the students:
1) The 401 response still has the NEGOTIATE option. (NTLM and BASIC may also be
present.)
2) There are two 401 responses sent by the client.

3) The NEGOTIATE reply from the client contains the NTLMSSP_AUTH value.

For any number of reasons, even if the UA receives a 401 response from the ProxySG, which
contains the NEGOTIATE header, the UA can decide to downgrade to NTLM. As mentioned in
the introduction, the IWA does not support Kerberos as the only option. If you select Kerberos,
NTLM is always offered as an alternative.

The sole presence of the NEGOTIATE header does not mean that Kerberos will be used. It simply
means that it can be used.
When a system has downgraded to NTLM, you can observe:

There are two 401 responses sent by the client.

The NEGOTIATE reply from the client contains the NTLMSSP_AUTH value.

The reasons that this happens are diverse and not limited solely to the configuration of the
ProxySG and its various components. It is clear that if you set up the SPN or the virtual URL
incorrectly, then Kerberos authentication cannot take place.

164 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 10: Using Kerberos Authentication

Authentication Steps
Authentication Challenge

HTTP 401 (Origin-*-redirect Style)

Ticket Request to KDC

Client requests a ticket for the virtual URL

Ticket Decrypted by BCAAA

BCAAA machine has the virtual URL registered as a SPN


Blue Coat SG can only impersonate the virtual URL

6OLGH$XWKHQWLFDWLRQVWHSV5HYLHZ

Instructors Note: This is an overview of how the entire process happens. You should work
with the students on this and have them explain to you the key points in this slide. Make sure
that the fundamental concepts about ticket generation, ProxySG deployment, and UA support
are clear and understood.

This slide reviews the sequence of actions that take place during a Kerberos-based authentication.
The process starts when the ProxySG issues a 401 authentication request impersonating the virtual
URL. The client believes that the response is coming from the virtual URL.
The client, using the TGT obtained at logon time, contacts the TGS in the KDC for a ticket to gain
access to the virtual URL. The virtual URL is registered as a SPN and associated with the machine
(or user account) where the BCAAA is running.

The ticket that the client receives from the KDC is encrypted with the session password shared
between the KDC and the BCAAA. The client then sends the ticket to the ProxySG, which cannot
read it. The ProxySG passes the ticket to the BCAAA; the BCAAA can decrypt the ticket and verify
its authenticity and therefore grant access to the client.
It should be very clear at this point why the ProxySG can only impersonate one virtual URL. (The
SPN associates one resource with one account.)
Important: The BCAAA does not need to communicate with the KDC to authenticate the
users credentials.

Instructor Edition 165

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

166 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 10: Using Kerberos Authentication

Instructors Kerberos Lab Notes


Overview

Kerberos authentication requires a properly outfitted network environment and careful planning.
You need to have

An Internal DNS server.

An AD.

Students PCs as members of the AD forest (single sign-on only).

A ProxySG configured to be the default gateway on each student PC. (Bridging mode is
acceptable as well; each students PC is connected directly to a ProxySG, which then connects
to the network.)

Windows Resource kit available at


http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/setspn-o.asp.
An SPN properly configured. (You need to be able to add and remove the SPN registration at
every training session.)

Figure 10-2: Kerberos lab setup

The commands that you need to execute, under a Domain Administrator account, are:

Register the SPN

setspn -A HTTP/<FQDN of virtual URL> <bcaaa machine Netbios name>

Remove the SPN

setspn -D HTTP/<FQDN of virtual URL> <bcaaa machine Netbios name>

Instructor Edition 167

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Computer Hardware and Software Requirements


Table 10-1: Requirements for the Instructor
Software

Version

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Table 10-1: Requirements for Students


Software

Version

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

168 Instructor Edition

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 11: Substitution Realm

Estimated Lesson Time: 20 minutes

Instructors Note: Blue Coat customers frequently want a username to identify the source of
requests; however, they do not want or cannot force all users or applications to respond
appropriately to authentication challenges. This new authentication realm provides a solution.
Important: Policy Substitution realm is not an authentication option; it is username resolution
attempt. Be careful to set expectations correctly.

A Policy Substitution realm provides a mechanism for identifying and authorizing users based on
information available in the request that a client makes to the Blue Coat SG. The amount and
type of information available may change depending on particular proxy deployment (explicit vs.
transparent) and overall network settings (Network Address Translation [NAT], NetBIOS setting,
DNS settings, etc.).
The realm is configured to construct user identity information by using policy substitutions; the
user identity is determined with some of the elements present in the request to the ProxySG, with
the addition of other lookup and query actions.

If authorization data (such as group membership) is needed, the realm can be configured with the
name of an associated authorization realm (LDAP or Local). If an authorization realm is
configured, the fully qualified username is sent to the authorization realms authority to collect
authorization data.
You can use Policy Substitution realms in many situations. For example, a Policy Substitution
realm can be configured to identify the user:

Based on the results of a NetBIOS over TCP/IP query to the client computer

Based on the results of a reverse DNS lookup of the client computer's IP address

Based on the contents of a header in the request. This might be used when a downstream
device is authenticating the user

The Policy Substitution realm is used typically for best-effort user discovery, mainly for logging
and subsequent reporting purposes, without the need to authenticate the user.

The following is an example of how to use substitutions with Policy Substitution realms. Assume
that:

The user susie.smith is logged in to a Windows client computer at IP address 10.25.36.47.

The Windows Messenger service is enabled on the client computer.

The client computer is in the domain AUTHTEAM.

The customer has an LDAP directory in which group information is stored. The DN for a
user's group information is as follows:

cn=username,cn=users,dc=computer_domain,dc=company,dc=com where username is the


name of the user, and computer_domain is the domain to which the user's computer belongs

A login script that runs on the client computer updates a DNS server so that a reverse DNS
lookup for 10.25.36.47 results in "susie.smith.authteam.location.company.com."

Under these circumstances, the following username and full username attributes might be used:

Username: $(netbios.messenger-username)@$(client.address)

Q This results in SUSIE.SMITH@10.25.36.47

Instructor Edition 169

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Full username: cn=$(netbios.messenger-username),cn=users,


dc=$(netbios.computer-domain),dc=company,dc=com

Q This results in cn=SUSIE.SMITH,cn=users, dc=AUTHTEAM,dc=company,dc=com

Username: $(netbios.computer-domain)\$(netbios.messenger-username)

Q This results in AUTHTEAM\SUSIE.SMITH).

Username: $(client.host:label(6)).$(client.host:label(5))

Q This results in SUSIE.SMITH.

Any combination of policy substitutions available from the client request can be combined into
username and fully qualified username.
Important: Username information provided by Substitution realms is not guaranteed. This
is a best-effort approach to username identification. This is not an authentication
process.

170 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 11: Substitution Realm

Policy Substitution Realm Objective


Provide username detection without user
prompting
Monitor by username

Cant force all users and applications to respond


appropriately to authentication challenges

Provide the ability for core proxies to trust edge


proxy authentication

6OLGH6FRSHRIWKH3ROLF\6XEVWLWXWLRQUHDOP

Instructors Note: Make the objective of this realm very clear once again. The ProxySG is
attempting to identify a user; it is not really challenging a user (or a user agent) for
authentication. This feature is for reporting purpose only; it minimizes the number of log
entries where there is no username information.

You may need to use the Substitution realm when it is inconvenient or impractical to challenge a
user or user agents for authentication.

The main objective of this realm is reporting. This realm has a very high probability of returning a
username in association with a client request. However, the username cannot be guaranteed.

This realm can be associated with an authentication realm to retrieve group information. The
ProxySG can lookup the calculated username in LDAP and Local realms to determine the users
group membership.
Note:

Policy Substitution realms do not require an authorization realm. If no authorization


realm is configured, the user is not a member of any group.

The following slides illustrate different scenarios where you can use the Policy Substitution realm.

Instructor Edition 171

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Policy Substitution Realm Overview

6OLGH6XEVWLWXWLRQ5HDOPIXQGDPHQWDOV

Instructors Note: This is the introductory slide. Describe what information is available to the
ProxySG to resolve a username without issuing a challenge (407 or 401 HTTP error).

The ProxySG can identify users by sending back an HTTP 407 error (explicit proxy mode) message
or an HTTP 401 error (transparent proxy mode) message. It also can use X.509 certificate
authentication, but this is beyond the scope of this chapter.
The ProxySG may use information naturally present in a client request in a best-effort attempt to
identify the username of the person making that request.
Every request contains the source IP address of the client (unless it is behind a device which
performs NAT), some request headers, and authentication credentials as required by other
applications.
The ProxySG can use this to query an LDAP directory to retrieve more data about the user;
typically you may want to query the LDAP directory for a group.

172 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 11: Substitution Realm

Deployment Authentication

6OLGH(GJHWRFRUHDXWKHQWLFDWLRQ

Instructors Note: This is an interesting feature. You do not always need to provide the
upstream proxy (core) with user information on a session initiated downstream (edge). In
general, as a best practice, you should log and authenticate users at the edge proxy level.
However, you should not log or challenge for authentication all the connections that the core
proxy receives from the edge proxy. This improves performance and keeps logs consistent.
However, if user information is made available from the edge to the core, this is the best
approach.

The client makes an initial request to the edge proxy. At this point, the edge ProxySG challenges
the user agent for authentication. The client sends request with the proper credentials; if the
credentials are valid, the edge ProxySG places the authenticated username into the upstream
request to the core ProxySG. This information is added in a special header called edge-user.

The core ProxySG can authenticate any request from the edge proxy against a Policy Substitution
realm by reading the addition header information and treat that as the username.

Finally, the fully qualified username is used to check authorization in the LDAP directory, and the
relevant core proxy policy for that user (or group) is applied.

Note:

You can use this realm to create both user-based and group-based policies. You must
associate the Substitution realm with an authentication realm (LDAP or Local) before
you can use group information.

Instructor Edition 173

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Deployment NetBIOS Based

6OLGH1HW%,26EDVHGVXEVWLWXWLRQUHDOP

Instructors Note: Make sure that you point out all of the limitations of this approach. The
main limitation is that users behind a firewall cannot be resolved if the device performs NAT.
Furthermore, NetBIOS can be disabled. Some companies are implementing this configuration
across the board. Finally, point out that you need to configure a Time to Live (TTL) value for
the result of the authentication. You cannot query NetBIOS for all requests from the same
client because it would result in a significant increase in network traffic. However, every time
you rely on TTL, you reduce the accuracy of the username information. (Compare it IP
substitution authentication.)

NetBIOS can provide some detailed information about a user logged on to a Windows system. The
information is made available unless you have disabled the NetBIOS protocol on your
workstations.

When the client initiates a request, the ProxySG sends a NetBIOS name request to retrieve
information about that IP address. For instance, if the clients IP address is 10.25.36.47, the result of
the query is similar to using the command:

C:>nbtstat -a 10.25.36.47

The Substitution realm can also use the computer name along with the domain name (which was
retrieved via NetBIOS) to create a fully qualified username. For instance, using substitutions, you
can create an LDAP user:

cn=$(netbios.messenger-username),cn=users,dc=$(netbios.computer-domain),
dc=company,dc=com)
The ProxySG queries the LDAP server using the string shown above (with the correct values filled
in) and attempts to obtain the groups and attributes of this user.
Based on both the username information produced by NetBIOS and by the LDAP search, the
proper policy is applied to the request.

174 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 11: Substitution Realm

Deployment DNS Based

6OLGH5'16EDVHGVXEVWLWXWLRQUHDOP

Instructors Note: Unless the DNS and the DHCP servers are configured to keep each other
up to date, it is unlikely that a company already uses client scripts or would add these scripts
to enable this feature. This is simply good to have. Talk about but do not push it; NetBIOS is, at
least in general, a better alternative.

You can use the Reverse DNS (RDNS)-based Substitution realm if you can always and correctly
map the DHCP-assigned IP addresses with the appropriate hostname. Some DHCP and DNS
servers can be configured to work in conjunction and keep each other updated; unfortunately, this
is not always the case.

When the DNS and DHCP server do not talk to each other, you need a login script that runs on the
client computer. This script updates the DNS server every time the DHCP issues a new address for
that client machine. This ensures that the RDNS lookup for the IP address is accurate and returns
something like susie.smith.authteam.location.company.com.

If the RDNS lookup returns a usable value, the Policy Substitution realm uses (in this example) the
fourth and fifth portions of the client hostname to create the LDAP look-up string as shown below:

cn=$(client.host:label(5)).$(client.host:label(4)),cn=users,dc=edgecorp,
dc=com)

Once again, the ProxySG has sufficient information to determine group membership for the
calculated user.

Instructor Edition 175

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Important Notes

Best-effort approach

Username resolution cannot be guaranteed


Do not create sensitive policies based on this realm
Gather back-up information before taking disciplinary
actions

Careful when using it in a sequence

May allow users to bypass authentication

6OLGH%HVWSUDFWLFHV

Instructors Note: This realm relieves a real pain point for the customer; however, you need
to discuss with your audience the limitation of the solution. The slide is called Important
Notes, but it could be called Limitations. Its suggestions are designed to minimize the
impact and side effects of the limitations inherent in this approach. Please point out that this is
the best and most technically accurate approach possible to username resolution without
issuing an authentication challenge.

If your main concern is to implement single sign-on, you can place the Substitution realm in a
sequence as first realm or use it alone. This realm has a very high probability of returning a
username.

Finally, especially if you plan disciplinary actions based on the information obtained by the
Substitution realm, collect as much information (evidence) as you can to support the data you get
from the realm. Additional information includes, but is not by all means limited to:

LDAP or Active Directory logs

DHCP Logs

Browser history logs for that user

Cookie jars for that user

176 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 11: Substitution Realm

Instructors Notes for Authentication Configuration Substitution


Realm Lab
Overview

You want to implement a single sign-on environment, but not all of the users can use NTLM. You
have an Active Directory (AD) forest that you can query via LDAP. You do not want the users to
be prompted for any sort of authentication.
By using the Policy Substitution realm, you can use information in the AD to identify and
authorize users. You have Messenger Service enabled on your Windows workstation so that
NetBIOS is likely to return the username of the person currently logged on to a machine

Computer Hardware and Software Requirements


Table 11-1: Requirements for the Instructor
Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Table 11-1: Requirements for Students


Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Instructor Edition 177

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

178 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 11: Substitution Realm

Instructors Notes for CPL Substitutions Lab


Overview

The function known as advanced forwarding enables implementation of a proxy hierarchy with
Blue Coat SG appliances. Advanced forwarding allows implementation of these key features:

Forwarding to an upstream ProxySG appliance based on domain, URL, or IP address

Load balancing of multiple upstream ProxySG appliances

Layer 3, Layer 4 and Layer 7 health checks of the upstream ProxySG appliances.

Computer Hardware and Software Requirements


Table 11-1: Requirements for the Instructor
Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

F PuTTY

F Release 0.60

F Wireshark

F version 0.99

Table 11-1: Requirements for Students


Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

F PuTTY

F Release 0.60

F Wireshark

F version 0.99

Instructor Edition 179

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

180 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 12: Windows SSO

Estimated Lesson Time: 15 minutes

Instructors Note: Point out clearly to the students that the Windows Single Sign-on (SSO)
realm does not issue a 407 or a 401 to authenticate users. In actuality, the realm does not
authenticate the users; it simply tries to associate an IP address to a user name. The
technique used here is similar to what Websense and SurfControl use.

The Windows Single Sign-On (SSO) realm allows you to create and manipulate realm properties,
such as the query type and the number of seconds that credential cache entries from this realm are
valid. However, it also contains the authorization username and the name of the realm that will do
authorization for the Windows SSO realm. The authorization username is a string containing
substitutions that describe how to construct the username for authorization lookups. This can
either be an LDAP fully qualified domain name (FQDN) when the authorization realm is an
LDAP realm or a simple name when local realms are being used for authorization.
Note:

Windows SSO realms never challenge for credentials. If the authorization username
cannot be determined from the configured substitutions, authorization in the
Windows SSO realm fails.

Keep in mind that Windows SSO realms do not require an authorization realm. If no authorization
realm is configured, the user is not considered a member of any group. The effect this has on the
user depends on the authorization policy. If the policy does not make any decisions based on
groups, you do not need to specify an authorization realm. Also, if your policy is such that it
works as desired when all Windows SSO realm users are not in any group, you do not have to
specify an authorization realm.
In a Windows SSO realm, the client is never challenged for authentication. Instead, the Blue Coat
Authentication and Authorization Agent (BCAAA) collects information about the current logged
on user from the domain controller and/or by querying the client machine. Then the IP address of
an incoming client request is mapped to a user identity in the domain. If authorization
information is also needed, then another realm (LDAP or local) must be created.
Important: The Windows SSO realm works reliably only in environments where one IP
address maps to one user. If an IP address cannot be mapped to a single user,
authentication fails. If your environment uses a NAT system, which uses one set
of IP addresses for intranet traffic and a different set for Internet traffic, you
should use a different realm for authentication.

Instructor Edition 181

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Windows SSO

Simpler method to authenticate users


Provides complete transparency

Users do not need to re-authenticate

Similar to Policy Substitution realm

The clients do not receive HTTP/401 or HTTP/407

6OLGH:LQGRZV662RYHUYLHZ

Instructors Note: Windows SSO is available starting in SGOS 4.2.2; this feature allows user
detection without ever challenging users for authentication credentials. Make sure that your
students realize that Windows SSO is a way to recognize (or detect) usernames; it is not true
authentication.

Many Blue Coat SG users look for a simpler method to authenticate users. You may want users to
be able to log on once to their workstations and then not have to worry about authenticating
again. Currently the IWA realm offers single sign-on if the user is logged on a Windows client and
the machine is part of the same domain for which IWA is configured. However, this does not
provide complete transparency because ProxySG still issues a 401 or a 407 HTTP response to the
client, which can result in the UA prompting the user for authentication credentials.

The new Windows SSO realm allows you to set up fully transparent username resolution. Like the
IWA realm, Windows SSO uses BCAAA to authenticate with the Windows network. The ProxySG
maps the IP address of an incoming request to a user identity on the domain.

182 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 12: Windows SSO

Realm Modes

Domain Controller Querying

The domain controller will be queried to identify


users

Direct Client Querying

The client can be queried directly in order to


determine the user currently logged on

Both

Domain query is used first

6OLGH5HDOPPRGHV

Instructors Note: There are two ways in which Windows SSO can resolve a username.
Domain controller querying can be performed by any authenticated user in the domain that
includes the LocalSystem user on the BCAAA machine. By polling the domain controller
frequently, it is possible to determine which users have logged on from which clients. Direct
Client Querying is blocked by the Windows XP SP2 firewall. Logon data can be retrieved on
demand. The BCAAA does not have to poll for the data, or persist the data.

To authenticate a user, the Windows SSO realm uses two methods, either separately or together:

Domain Controller Querying: The domain controller is queried to identify which users are
connecting to, or authenticating with, the domain controller. This can be used to infer the
identity of the user at a particular workstation. Domain controller querying enumerates the
network connections of a given server. Client machines create a network connection to the
domain controller when logging on. By polling the domain controller, it is possible to
determine which users have logged in from which clients.

Client Querying: The client workstation is queried to determine who the client workstation
thinks is logged on. The benefit of Direct Client Querying is that the logon data can be
retrieved on demand. BCAAA does not have to poll for the data, or persist the data. It can also
be used to identify a logon that did not involve a domain controller.

When Domain Controller Querying and Client Querying are both selected, the Domain Controller
Query result is used if it exists and is still within the valid time-to-live as configured in the sso.ini
file. If the Domain Controller Query result is older than the configured time-to-live, the client
workstation is queried.

Note:

In explicit proxy mode, the BCAAA checks on every transaction for the user
associated with a given IP address. To avoid querying the client for every transaction,
you can use IP or cookie surrogate credentials.

Instructor Edition 183

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Deployment Scenario

6OLGH'HSOR\PHQWVFHQDULRV

Instructors Note: Use this slide to describe some of the advantages and disadvantages of
the Windows SSO realm. Also use it to build the list of deployment requirements, which are
detailed in Slide 12-5. The circle around the client on the left of this slide represents a personal
firewall. The line is not solid because it assumes that the firewall is disabled or at least that the
necessary ports for Windows authentication and NetBIOS queries are open.

The deployment options define whether the BCAAA retrieves user information from the domain
controller or the client. Both scenarios have advantages and disadvantages.
Domain controller querying uses the NetSessionEnum Windows API function and constantly
polls the domain controller to retrieve information about currently logged users. Some issues to
consider for this option are:

It requires frequent polling of each domain controller in order to capture all logon events.
Polling needs to occur at least every ten seconds because logon events can be as short as
fifteen seconds.

Users do not have to authenticate through the domain controller. There are two common cases
that avoid the domain controller: cached domain accounts and local accounts.

Direct client querying reads the registry for username information; this provides the most correct
answer to who is logged on to a workstation. Reading the registry can be done by users
authenticated in the domain without special privileges. The main drawbacks are:

It is slower than NetWkstaUserEnum (Domain Query).

Personal firewalls are a challenge (need to open some ports).

Important: Remember that this realm provides username detection and not authentication.

184 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 12: Windows SSO

Authorization Realm

CPL Substitution

Description

$(user.domain)

The Windows domain of the


authenticated user

$(user.name)

The relative username of the


authenticated user.

Connect to other realm

Look-up group information


Optional step

6OLGH*URXSVORRNXSV

Instructors Note: Windows SSO allows you to look up group information for a user. The
information is referenced in one of the existing other realms. Point our clearly that this is an
optional setting. You do not have to configure authorization for the realm. You can use the CPL
substitution to build an NT-like or LDAP username.

You can construct the username in a Windows SSO realm using the CPL substitutions listed in the
slide above. For instance you can have the username constructed as:

$(user.domain)\$(user.name)

The syntax above generates username similar to BLUECOAT\BOB.KENT.

To construct a username, keep in mind that the authorization username attributes is a string that
contains substitutions. When authorization is required for the transaction, the character string is
processed by the substitution mechanism, using the current transaction as input. The resulting
string becomes the users authorization name for the current transaction
Windows SSO realms do not require an authorization realm. If the policy does not make any
decisions based on groups, you do not need to specify an authorization realm.

Instructor Edition 185

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Deployment Notes

6OLGH'HSOR\PHQWQRWHV

Instructors Note: This is a very important slide. You should have already led your students to
come to the conclusions shown here when presenting Slide 12-3. Reiterate that these
limitations apply to the client querying method. Basically, personal firewalls and corporate
(network) firewalls represent a challenge to the success rate of the Windows SSO realm.

The Windows SSO realm uses BCAAA to query domain controllers and/or computers in the
domain. This querying can be blocked by the Windows XP/2003 firewall. If the firewall is active
on a computer that the Windows SSO realm needs to query, then a firewall exception must be
added to the domain policy for that computer.

The Group Policy Management Console can be used to adjust the firewall exceptions for a
domain. It can be downloaded from Microsoft if it is not already available. TCP port 445 must be
enabled on the client for access from the machines running BCAAA. TCP port 445 is used by
SMB/NetBIOS over TCP. On the client, you need to enable one of the following settings:

Allow remote administration exception

Allow file and printer sharing exception

Define port exceptions and add TCP port 445

Also, Windows SSO does not ingrate with NAT because it requires one IP address to map only one
user. In a NAT environment, all clients will appear as one user.
Network firewalls also present a challenge to Windows SSO username detection. While it is easy
to open personal firewalls to exceptions, it can be harder to do so on corporate firewalls for
obvious security reasons.

The Windows SSO realm works reliably in environments where one IP address maps to one user.
There is no workaround for this. When using domain controller querying, the assumption is that
the previous user has logged out if a new user is seen for the same IP address. When using direct
client querying, it is possible to identify multiple users logged onto the same workstation. One
common case for this would be when using Windows Terminal Services. The only option in this
case would be to use a Sequence Realm and authenticate with a different realm if there is more
than one user per IP.

186 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 12: Windows SSO

Neither domain controller querying or direct client querying will work correctly with NAT. In that
case, the administrator should identify the NAT addresses and use a different realm for
authentication.

There is no logout event that can be tracked. Once the User Management changes are available, it
would be possible to allow users to log themselves out but since they are doing SSO, this would
seem wrong and may cause more confusion.
Note:

Windows SSO works best when all users are on the same subnet as BCAAA and there
are no personal firewalls on the clients.

Instructor Edition 187

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Understanding sso.ini File

Before domain controller querying or client querying can be used, the sso.ini file, located in the
same directory as the BCAAA service, must be modified. The installation wizard for the BCAAA
creates the sso.ini file1.

To enable the method of authentication querying you choose, you must modify the sso.ini file
by adding domain controllers you want to query and user accounts you want to ignore.
The sso.ini file is located in Program Files> Blue Coat Systems> BCAAA.

If you are only using one method of querying, you only need configure the specific settings for
that method. If you plan to use both methods to query, you must configure all the settings.

Note:

The changes to the sso.ini file will have no effect until the BCAAA service is
restarted.

To configure the sso.ini file for domain controller querying, you need to follow the steps detailed
below:
1.

Open the file in a text editor.

2.

In the section DCQSetup, un-comment the line: DCQEnabled=1.

3.

In the section DCQDomainControllers, list the domain controllers you want to query or the IP
address ranges of interest.
By default all domain controllers that are in the forest or are trusted are queried. In large
organizations, domain controllers that are not of interest for the ProxySG installation might be
queried. The sso.ini file can be used to list the domain controllers of interest or IP address
ranges of interest.

4.

In the section SSOServiceUsers, list the domain names of users who can access the domain
controller on behalf of the service and mask the identity of the logged-on user.

Listing these users here forces the BCAAA service to ignore them for authentication purposes.

5.

Save the sso.ini file.

To configure the sso.ini file for client querying, you need to follow the steps detailed below:
1.

Open the file in a text editor.

2.

Review the TTL times in the section ClientQuerySetup to be sure they are appropriate for your
network environment.

3.

Update the section SSOServiceUsers to ignore domain users used for services.

4.

Save the sso.ini file.

Note:

Before you use the Windows SSO realm, you must change the BCAAA service to run
as a domain user, and, if using XP clients, update the domain policy to allow the client
query to pass through the firewall.

1. You must have installed BCAAA version 4.2.2.x or higher. Earlier releases do not create the sso.ini file.

188 Instructor Edition

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 13: Advanced Authentication

Estimated Lesson Time: 45 minutes

Instructors Note: This chapter is designed to both dive into the details on how ProxySG
handles the authentication process and as a primer for the Guest Authentication feature
(which is discussed in a separate chapter). The initial part of the chapter is relatively detailed;
in particular you can teach the first three slides definitely at two different levels. You can
quickly scan through them or you can attempt to discuss the minute details; it largely depends
on your class.
Focus on the remaining slides as the concepts illustrate are key to understanding the Guest
Authentication chapter.
Essentially, this chapter explains how ProxySG collects, retains, process, and shows user
information. There are several nuisances about username resolution and group membership
analysis; this chapter is designed to allow the students to understand what they can expect
from user authentication and why.
The complexity pertaining to authentication is that ProxySG is a multi protocol device. A single
user can be using a web browser, have an ftp download going, chatting through IM, and
streaming a video all from the same desktop. The chapter guides the student to understand
how the proxy deals with the different scenarios.
Bear in mind that, although very detailed, the information in this chapter is a simplification of
the actual mechanism, which ProxySG uses to manage authentication.

The main focus of this chapter is to provide the details necessary to understand how ProxySG
determines which users are currently logged in and how an administrator can manage these users.
You can run a query find out which users are currently logged into a ProxySG. The information
details which user(s) are logged in from an IP address, or given a user, which IP addresses she is
using. You cannot just view user information but it is possible to logout a user-through a direct
action or through inactivity.

In general, multiple connections for the same user from the same IP address are considered a
single login. If that user then goes to a second computer and authenticates to the same realm, then
that would be considered a second login.

When it comes to the concept of logging users out, the meaning of logout can be vague. What
should happen if the user is downloading a file through ftp and streaming a video in WMP and
they click a logout link in their browser? Should the download and the stream be terminated? In
other words, should the semantics of a user initiated logout be that all transactions for that user on
that IP address are immediately terminated, or should it be that in progress transactions can
complete and new transactions must be authenticated? ProxySG supports both cases through
policy.
Another power feature of ProxySG, which allows for better management of credentials and user
authentication, is the possibility for administrators to have control over how often the user is
authenticated and to decide when to force the user to type in their username and password rather
than just accept the browsers cached credentials.
Some of the unique features and functionalities of SGOS are:

Better control over credentials


Administrators can require more frequent authentication if the end-user is accessing critical
resources. These features allows the administrator finer control over how often the end-user is
authenticated. The administrator has the option to ignore the cached browser credentials and
force the user to re-enter their credentials.This is very important when you need to control
access to very sensitive resources, like internal server hosting private documents and other
similar situations.

Instructor Edition 189

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

End-user Logout capability


The use of IP surrogate can cause, in very rare and extreme situations a user to be mistaken for
another. For example, if another person used that computer before the credential cache entry
expired for the previous user, the second user would be treated as the original user. Logout
feature solves this. Logout can be manual (user or administrator) or automatic. If there has
been no activity for a pre-determined amount of time, then the user is automatically logged
out.

Login Control
Since it is possible to determine when a user is logged in, it is possible to manage the number
of logins allowed.

Authorization Data Refresh


ProxySG allows the authorization data to be invalidated separately from authentication data.
This allows the authorization data to be refreshed without re authenticating the user.

At the end of this chapter you should really be able to understand how the authentication and the
authorization processes work with a ProxySG appliance.

190 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 13: Advanced Authentication

Authentication and Authorization


Authentication

Determining the users identity. Includes obtaining


credentials and submitting them to authentication
server as need

Authorization

Determining which groups and attributes the identified


user has. Only determines those that are specified in
policy

6OLGH$XWKHQWLFDWLRQDQGDXWKRUL]DWLRQ

Instructors Note: This slide introduces the difference between authentication and
authorization since the ProxySG can manage the two separately, which allows the proxy to
support many realms and different complex authentication and authorization environment. To
simplify the concept, you can state that:
Authentication is the process of determining who you are and
Authorization is the process of determining what you can do.

When you submit your credentials (username and password) for validation, depending on the
authentication realm used in your organization, the process of validating your identity and the
process of determining what you are authorized to do can be two separate processes.

Some realms, like LDAP based ones, allow an organization to build a very complexed and
distributed environment for user authentication and authorization. The two processes can not just
be logically separate but also can be performed at different times and on different systems.
On the other hand, some realms, like IWA do not allow authorization and authentication to take
place separately; they have to happen at the same time.

ProxySG supports a wide, and growing, variety of realms; it is therefore very important that at a
logical level authorization and authentication are managed separately. This allows scalability and
increased functionality in both users management and realms support.

Instructor Edition 191

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Authentication and Authorization

6OLGH$XWKHQWLFDWLRQDQGSROLF\FRQWURO

Instructors Note: Point out that this slide is designed to represent the most generic scenario
and it is not likely to represent the actual scenario for the majority of the students.
Make sure that you explain clearly:
- The authentication and authorization servers are wrapped into a dash-lined rectangle as they
can be (and they are in most cases) just one physical server
- The credential validation and authorization request query most likely happen at the same
time (IWA realm for instance) but they can be split in some other realms
- The ProxySG requests the group-membership information to the realm only if you have
group-based policies.

As mentioned in Slide 13-1, the processes of authorization and authentication can be seen as two
separate processes happening at different times and even on different servers. While this is the
most generic situation, it is not the most common scenario.
Most of the realms, and most of the implementation of authentication and authorization
structures, perform the two processes at the same time and on the same server.

It is necessary for ProxySG to manage the two, at least logically, as two completely separate and
independent events. Regardless of the actual scenario, all of this happens pretty much behind the
scenes and it is completely transparent to the end-user.
The slide shows the VPM and a policy where the source trigger is a user group. This is done to
point out how ProxySG only retrieves group membership information when there is a policy
requiring such information.Unless you have the need to verify group membership for a user,
ProxySG does not retieve this information.

192 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 13: Advanced Authentication

Authentication Model

6OLGH$XWKHQWLFDWLRQ0RGHO

Instructors Note: This slide may appear intimidating at first, however its content is relatively
easy. Make sure, as it is always the case in this detailed diagram, to point out that the slide
represents a very high level simplification of the process and many details have been omitted
as they are proprietary to Blue Coat.
The most important point in the slide is that credentials are cached and that there are two
workers who are in charge of completing the authentication and authorization process.
The AAA worker is not the BCAAA; it is however the component within SGOS which will
communicate with the BCAAA if and when necessary.
Note: Authorization steps a ignored to keep the slide simple. However it is the AAA worker
which will perform the authorization as well as the authentication.
Important: At step 2 it is not the PW which looks for credentials in the cache but the AAA. The
PW simply asks the AAA for credentials validation; it is the AAA which manages the cache.
Questions: When does the ProxySG send a 401 and when a 407 to request users
credentials?
Answer: 401 is used in origin-*-* or form-*-* authentication mode. This is most likely an
transparent or reverse proxy deployment.
407 is used only in proxy mode authentication. This must be an explicit proxy deployment.

The ProxySG uses an elegantly complex authentication process which allows the operating system
to de-couple authentication and authorization, while supporting virtually any type of realm and
credentials.
In order to maximize performances, limit interaction with the authentication services, and to
enhance the user experience, the process can be logically and functionally split in 5 steps detailed
below.
1.

The client requests for an object through the cache. The policy worker (PW) initializes a new
Session and associates the user Guest to the session while it is waiting for the client to submit
the requested credentials. If this request is a new Transaction within a Session, then PW may
or may not initialize a new request for authentication. This depends on the specific PW
requirements.
The PW may use an HTTP 401 or HTTP 407 to ask for credential depending on the specific
settings in the policy.

Instructor Edition 193

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

In HTTP (Explicit) proxy the PW issues an HTTP 407 Proxy Authentication Required
and adds specific realm information like: www-proxy-authenticate: NTLM<CRLF>
www-proxy-authenticate: BASIC realm="BC_Training". This is also known as
authentication negotiation process. IE client always selects NTLM in such case, as it provides
better security. Netscape and Mozilla (FireFox) clients select Basic Authentication challenge.
For transparent proxy authentication as well as reverse proxy authentication, PW issues an
HTTP 401 Unauthorized challenge as indicated above with appropriate NTLM/BASIC
Auth challenges.
The client (browser) pops up the user for credentials (optional, for instance IWA with NTLM
or Kerberos credentials will not) and the appropriate credentials are sent in Authorization
header.
Note:

Note: For Basic Auth and transparent Authentication schemes, the authentication
credentials are included in every request. In this case, there is no need to issue an
authentication challenge to the client.

2.

The PW calls the AAA worker which first looks for the user object in one of its local caches i.e.,
credential cache.In the case of transparent auth, the CFAuth cookie is validated first to
determine the user name and realm and then these credentials are used against the credential
cache.

3.

On a cache miss, the AAA attempts to authenticate the user against the external
authentication service as determined by the realm information.
Group membership information is not always requested but it can be; it depends if it is
requested in the policy or not.
The external authentication sends back the authentication response.
Note:

NTLM authentication is a challenge-response mechanism with three round-trips


between the client and BCAAA agent.

4.

Once the user is successfully authenticated, the credentials are cached (if caching for that type
of credentials is allowed). The information about successful authentication (or failure) is
passed to the PW.

5.

The PW passes the authentication information (failure) to client or allows the ProxySG to
return the requested content (which could be a denied or exception page).

194 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 13: Advanced Authentication

User Login Definition

6OLGH'HILQLWLRQRIXVHU

Instructors Note: The content of this slide is key as it allows you to clearly describe what it is
a user as far as ProxySG is concerned. The definition of a user is important primarily so that
you can understand the licensing implications. Primarily, a user is mapped to one IP address
and not to the number of session it has open; however, depending on the credential surrogate
that you use for the authentication, you can have more than one user logged on a single IP.

The slide describes what can be a relatively common scenario, especially for certain users who
have access to multiple machines like IT people.

Bob is logged on the 172.16.90.130 and 172.16.90.202 workstations. Mary logged on from the
172.16.90.124 PC. Both Mary and Bob access a combination of HTTP and HTTPS resources via a
ProxySG.
You can say that there are 2 user IDs logged into the proxy and three devices. The ProxySG
consider a user the unique 2-tuple made of Username and IP address. So the user in the system
are:
1.

(172.16.90.124; Mary)

2.

(172.16.90.130; Bob)

3.

(172.16.90.202; Bob)

The following slides describe some other situations where the surrogate credentials are used to
make a more significant difference in determining the number of users logged into the proxy.

In case of Slide 13-4, there are no device between the user and proxy which may alter or
masquerade the original source IP; in this scenario the number of user logged in is pretty much
always 3 regardless of the surrogate credentials used.

Instructor Edition 195

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Surrogate Credentials

6OLGH6XUURJDWHFUHGHQWLDOV

Instructors Note: The student should have brushed along the concept of surrogate
credentials in various parts of this or other Blue Coat courses; however a definition of
surrogate credentials was never clearly discussed. Define surrogate credentials as the piece
of information used to map a transaction to a user.

Unless you are in the very specific case of explicitly proxy environment, there is no reference to the
user credentials in an HTTP request. Additionally, you should remember how the HTTP protocol
is stateless and connectionless. In essence, once a request and response pair has taken place, there
is nothing surviving about that transaction in the next one.
After the authentication process there is really no surviving information in the further requests a
client is making. It is then necessary for a proxy, and also for an OCS requesting authentication, to
associate the successful authentication even and the corresponding user ID to some object or
property, generally called surrogate.
You can elect to use three types of surrogates:

Connection: the authentication results is associated to the TCP connection between the client
and the proxy. This can only be used in explicit proxy environment; it requires using HTTP
407 in order to challenge the user for this type of surrogate.When the connection terminates,
authentication information is lost and the user needs to re-authenticate.

IP Address: the authentication result is associated to the source IP address of the client
request. You need to define a time to live (TTL) for this type of surrogate. Shorter TTL means
that the user may be authenticated more often but there is less of a chance of incorrectly
identify users. Longer TTL means that the user is authenticated less often but there can be an
higher chance of incorrectly identify users.

Cookie: the authentication result is associated to a cookie. You can have session cookies or
persistent ones by setting a TTL. Either case cookies are relatively secure as each user profile,
even on a shared machines, must have individual cookie jars. Once the user is authenticated,
the proxy sends back a cookie. As long as the user agent present a valid cookie to the proxy,
the user is not prompted for authentication.

196 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 13: Advanced Authentication

You can use any of the three supported forms of surrogate credentials in explicit proxy
environments; for transparent proxy environments you are limited to IP address or cookie
surrogates.

Additionally, you need to consider that you can use IP address or connections surrogate
credentials with virtually any user agent, not just web browsers. You may use cookie surrogates
only with compatible user agents; typically this restricts the use of this type of surrogate to web
brokers.

Instructor Edition 197

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

User Data Refresh

6OLGH5HIUHVKXVHULQIRUPDWLRQ

Instructors Note: The concepts here a very simple, even if the students note contain a lot of
information, as there is some redundant information about the concepts and limitations behind
surrogate credentials. You can refreshing user data with the following refresh-time options on
the SG appliance:
- Credential refresh time: This option specifies how long a cached username and password
is trusted (do not require rev a lid at ion).
- Surrogate refresh time: This option specifies how long surrogate credentials are trusted in a
particular realm.
- Authorization refresh time: This option specifies how long authorization data, such as
groups and attributes, are trusted

While the realms have the baseline settings for the different refresh times, policy and
administrator actions can override the realm settings. Using the same interface and filters as used
for viewing logins, the administrator can select logins and refresh the authorization data, the
credentials, or the surrogates using the links available on the user login information page.
Refreshing user data might be necessary if users are added to new groups or there is concern
about the actual identity of the user on a long-lived IP surrogate.
Credentials Refresh Time

You can set the credential refresh time with realms that can cache the username and password on
the SG appliance. This is limited to realms that use Basic username and password credentials,
including LDAP, RADIUS, XML, IWA (with Basic credentials), SiteMinder, and COREid.
Note:

The local realm uses Basic credentials but does not need to cache them since they are
stored already on the appliance.

198 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 13: Advanced Authentication

You can use a cached username and password to verify a users credentials without having to
verify the credentials with the offbox authentication server. Essentially, this reduces the load on
the authentication server. For authentication modes that do not use surrogate credentials (that is,
proxy or origin modes), this can greatly reduce the traffic to the authentication server. The
credential refresh time value determines how long a cached username and password is trusted.
After that time has expired, the next transaction that needs credential authentication sends a
request to the authentication server. A password different than the cached password also results in
a request to the authentication server.
One-time passwords are trusted for the credential refresh time. Only when the credential refresh
time expires is the user challenged again.
Surrogate Refresh Time

This value manages how long surrogate credentials are trusted in a particular realm. The
authentication mode determines the type of surrogate that is used. Cookie surrogates are used
with one of the cookie authentication modes; IP address surrogates are used with one of the IP
authentications modes; and the Auto authentication mode attempts to select the best surrogate for
the current transaction. IP address surrogates work with all user agents, but require that each
workstation has a unique IP address; they do not work with users behind a NAT. An IP surrogate
authenticates all transactions from a given IP address as belonging to the user who was last
authenticated at that IP address. When a user is logged out, all surrogates are discarded, along
with the cached credentials and authorization data.
Authorization Refresh Time

Realms (Local, LDAP, Windows SSO, Novell SSO, Certificate, XML, and Policy Substitution) that
can do authorization and authentication separately can use the authorization refresh time value to
manage the load on the authorization server. These realms determine authorization data (group
membership and attribute values) separately from authentication, allowing the time the
authorization data is trusted to be increased or decreased For realms that must authenticate the
user to determine authorization data, the authorization data is updated only when the user
credentials are verified by the authentication server.

Instructor Edition 199

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Inactivity Timer

6OLGH,QDFWLYLW\WLPHU

The idea is to visibly notifying that the user has been logged out. Form based authentication
makes the process pretty obvious under all circumstances (any surrogate credentials) as the
browser cannot cache the credentials submitted in a form.

Instructors Note:
However, if you are not using forms, the user agent can resend the cached credentials without
any user intervention. Only if the credentials are invalid, then the user agent shows the
pop-up window to the client. The solution is to use session based cookies and invalidate the
cookie in a two steps process to make it look like the previous cached credentials were not
valid. This solution work with Firefox and IE and may also work with other advanced
browsers like Opera.
IE has a further complication. One the next challenge it helpfully fills in the last username and
password for the user. If user A has logged out, they will not want user B to be able to log back
in with their credentials. Fortunately, there is an IE specific Java Script function which will
clear all cached credentials and avoid this issue. When the SG has determined that the browser
is presenting old credentials it will respond with a new Log out exception page. This page
includes the special IE Java Script to clear the credentials and displays an exception message
which effectively notifies the user that the session has been logged out. This page is
automatically refreshed, which forces the new challenge.

One of the difficult issues with the concept of log out with Web browsers is managing when users
are visibly challenged for their credentials. If form authentication is being used, there is no
confusion; every time the form is presented, the user is visibly challenged for their credentials.
However, if HTTP authentication is used the browser is allowed to cache the user credentials and
silently provide them to the server. If a user has logged out, future transactions should reject any
cached credentials and visibly challenge the user again in order to verify who is actually at the
workstation.

200 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 13: Advanced Authentication

In order to visibly challenge the user for authentication when you are not using form-based
authentication, you need to use cookie surrogate. You cannot use IP address nor you can use
session based surrogates. Using cookies, you can visibly challenge the users, they are
authenticated using NTLM, Kerberos, or BASIC credentials. The solution is only available for
transparent proxy authentication.The process works as follows:
1.

The main assumption is that if ProxySG encounters a session cookie for a new user, this means
that the user was previously authenticated this user and that the browser is sending cached
credentials. In order to support this assumption, a session cookie is always set, even if
persistent cookies are configured (two cookies are set in this case).

2.

When the ProxySG rejects the cached credentials at they have been expired, the cookie is
modified and the client receives 401

3.

The client resends the cached credentials, this time they do not match what the ProxySG has
so it can send back a 401 saying that the credentials are invalid. For both IWA and BASIC
credentials this forces the browser to visibly authenticate the user.

4.

The next set of credentials are accepted.

5.

ProxySG validates the credentials with server configured in the realm.

Instructor Edition 201

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Inactivity Timer - Connections

6OLGH,QDFWLYLW\WLPHUZLWKFRQQHFWLRQVXUURJDWH

Instructors Note: You can go over this slide very quickly. The idea is to show how it is not
possible to log out a user in a way that it is visible to the user. The browser responds to the
HTTP 401 with cached credentials.
This slide shows the scenarios where the user is explicitly proxied and you are not using
form-based authentication mode.

After receive an HTTP 407 response from the proxy, an explicitly proxied user agent will always
add the user credentials in the every subsequent request. Additionally, most browser do cache the
user credentials for as long as the browser process is running.
When the ProxySG expires the user (logoff), it generates an HTTP 407 response and sends it to the
client. Without any user intervention, the user agent immediately responds to the 407 challenge
with the cached users credentials. as result, even if the user was logged off, unless the browser
session was terminated (user killed all running processes for that user agent), the user does not
have to re-enter the authentication credential.
In this scenario, logging off user is mainly used to keep the license with the necessary limits.

202 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 13: Advanced Authentication

Policy Conditions

6OLGH3ROLF\FRQGLWLRQV

Instructors Note: This slide shows a scenario where the users and the proxy are separated
by a firewall, which performs NAT. Users are authenticated using IP address as surrogates.
This is a scenario that should not happen in the first place as it is bad design to use IP
addresses surrogates; you should consider always only session or cookie surrogates when
there are natting devices between the users and the ProxySG.
There are two main things you need to convey in the slide:
1) The three properties and three conditions to manage user logouts.
2) The reason why IP address surrogate credentials is not a good fit for this type of
environments.

The ProxySG has three different properties that you can use to manage logout and to create very
granular policies. These properties are:

user.login.count
This condition matches the number of times that a specific user is logged in with the current
realm. You can use this condition to ensure that a user can be logged in only at one
workstation. If the condition is combined with the user.login.log_out_other property, old login
sessions on other workstations are automatically logged out.

client.address.login.count
This condition matches the number of different users who are logged into the current IP
address, and you can use it to limit the user number.

user.login.time
This condition matches the number of seconds since the current login started, and you can use
it to limit the length of a login session.

In the scenario represented in the slide, the administrators have made a very poor selection of
surrogate credentials. Since there is a firewall with NAT between then users and the proxy, IP
address surrogate is the worst possible decision as it does not allow the ProxySG to discern
between users. All transactions are associated to the first users who was authenticated.

Instructor Edition 203

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

To fully understand this scenario, you need to remember that the ProxySG identify a user as the
2-tuple (username, IP address) as discussed on page 195. The sequence of events explains the issue
in details and with clarity.
1.

Bob, who is logged on IP address 172.16.90.202, authenticates into the ProxySG. However his
IP address appears as 10.0.1.100 to the proxy because of the NAT taking place on the firewall.

2.

ProxySG associate the surrogate credential IP address 10.0.1.100 to the user Bob.

3.

Within the time frame of the TTL for the surrogate credential, Mary logs in from the IP address
172.16.90.123. Unfortunately her IP address appears as 10.0.1.100 to the proxy because of the
NAT taking place on the firewall.

4.

While you may want or expect the ProxySG to be able to associate Mary as new user, since the
IP address 10.0.1.100 is a valid surrogate credential, her traffic will be associated to the user
Bob.

For both Bob and Mary login:

user.login.count=1

client.address.login.count=1.

client.address.login.count=1

user.login.count=1

which means according to the ProxySG , only Bob is logged on and he appears logged on once.

204 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 13: Advanced Authentication

Policy Conditions - Cookies

6OLGH3ROLF\FRQGLWLRQVZLWKFRRNLHVXUURJDWH

Instructors Note: This slide shows why using cookie surrogates is a much better option
when there is a NAT device between the users and the ProxySG. Since the cookies are not
impacted by NAT, the proxy can discern between two users on the same IP. This is also true
for session surrogate, which of course means you are in an explicit proxy environment.

As mentioned earlier in this chapter, ProxySG allows you to use cookie as surrogate credentials.
Cookies are not impacted by the presence of a device performing NAT and cannot be shared
across user profiles making them both a flexible and secure option for surrogates.

The scenario in Slide 13-10 is the same as Slide 13-9; however in this case the administrator of the
proxy has correctly decided to use cookie surrogates.

To fully understand this scenario, you need to remember that the ProxySG identify a user as the
2-tuple (username, IP address) as discussed on page 195. The sequence of events explains the issue
in details and with clarity.
1.

Bob, who is logged on IP address 172.16.90.202, authenticates into the ProxySG. However his
IP address appears as 10.0.1.100 to the proxy because of the NAT taking place on the firewall.

2.

His successful authentication is associated with an authentication cookie which is sent to his
user agent as part of the authentication process

3.

Mary logs in from the IP address 172.16.90.123. Her IP address appears as 10.0.1.100 to the
proxy because of the NAT taking place on the firewall. However this is not an issue. Mary has
not presented a valid authentication cookie so she is prompted for authentication by the proxy

4.

Mary receives the authentication cookie after the proxy successfully validated her credentials.

ProxySG can distinguish between the users Bob and Mary, even if they appear as coming from the
same IP address. In that case, each of their user.login.counts would be 1, but the
client.address.login.count for 10.0.1.100 would be 2.

Instructor Edition 205

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

206 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 13: Advanced Authentication

Instructors Notes for Advanced Authentication Lab


Overview

This labs walks you through a packet capture performed on the ProxySG. The goals is to show the
Authentication and Authorization steps, which ProxySG performs when there are Group or
Attribute based policies.

Computer Hardware and Software Requirements


Table 13-1: Requirements for the Instructor
Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

F Wireshark

F version 0.99

Table 13-1: Requirements for Students


Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

F Wireshark

F version 0.99

Instructor Edition 207

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

208 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 14: Guest Authentication

Estimated Lesson Time: 30 minutes

Instructors Note: This chapter discusses the ability of ProxySG appliance to allow access to
unauthenticated or unauthorized (or both) users even when there are authentication policies in
place. The chapter walks the students through a detailed understanding of the features and
functionalities that the ProxySG appliance makes available to the administrator. It also
describe the technical details behind them.
In essence the main concept behind guest authentication is to allow the administrator to see
and manage both authentication and authorization errors.
Authentication can succeed even if authorization fails in realms that support split
authentication and authorization (i.e. can specify a separate authorization realm) or those that
are valid authorization realms themselves (e.g. LDAP, Local realms). Realms that do not
support split authentication and authorization (e.g. IWA, SiteMinder, COREid) fail
authentication if authorization fails for any reason. Authorization cannot succeed if
authentication has failed. In those cases, authorization will not be attempted.
ProxySG appliance allows you to deal with:
- Permitting authentication errors
- Permitting authorization errors
- Attempting the next realm in a sequence after a permitted error
- Authenticating as a guest user
- Adding default groups to a user
A realm is specified to authenticate the guest against but it does not actually authenticate the
user against the backend authentication server. Instead it just determines the username using
policy substitution evaluation as needed and marks the user as authenticated and authorized
in the specified realm.
Important: This chapter requires that the students have mastered the concept in the
Advanced Authentication chapter.

For some companies, user authentication and authorization is desirable but not necessarily
required for users to access resources. Administrators for these companies would like a way to
specify that authentication and authorization should be attempted but that some errors should be
permitted such that the users request is allowed to proceed even if the error occurs. There are
numerous reasons why authentication and authorization could fail including invalid credentials
and failure to connect to an external authentication server. Administrators may want the ability to
allow users transactions to continue after an external server failure while at the same time,
terminating the transactions of users that offer invalid credentials.
In addition to the ability to permit errors in authentication and authorization, administrators
would like a way to authenticate users as guest users and assign them to default groups. In some
scenarios, authenticating as a guest is only desired once authentication has been attempted and
failed. One such scenario would be users logging in from public workstations whom do not have
intranet accounts.

This chapter describes how ProxySG appliance provides administrators with a mechanism to
specify that a user transaction should be allowed to proceed instead of being terminated. The
chapter also details how administrators can specify that users be authenticated as guest users and
be assigned to default groups without having to setup guest accounts in their realms and having
users explicitly enter guest credentials.
The ability to permit authentication and authorization errors and the ability to login as a guest
user and be assigned to default groups, which can be used together or separately. Using policy
(VPM or CPL), you can allow a user to log in as a guest user. Guest authentication allows you to
assign a username to a user who would have otherwise been considered unauthenticated.

Instructor Edition 209

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Note:

You can use guest authentication with or without default groups. If you use default
groups, you can assign guest users to groups for tracking and statistics purposes.

In the case of guest authentication, a user is not actually authenticated against the realm, but is:

Assigned the specified guest username.

Marked as authenticated in the specified realm.

Marked as a guest user.

Tracked in access logs.

Since the user is not actually authenticated, the username does not have to be valid in that realm.
Before creating policy for guest authentication:

Determine the circumstances in which guest access is permitted. Guest users are typically
allowed in circumstances where no authentication is needed.

Determine authentication policy. Will the realms attempt to authenticate users firsthand
fallback to guest authentication or authenticate users as guest users without attempting
authentication?

Important: Guest authentication after an authentication challenge causes the client software
(browser) to believe that the credentials offered were valid. The browser will
therefore re-offer the cached credentials on a subsequent challenge even though
they may not be valid.

210 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 14: Guest Authentication

User Identification

Users without valid accounts

Access from public workstations


Vendors or other users without domain account

Authentication Errors

Authentication server not available


Invalid realm configuration

Authorization Errors

Authentication succeeds but no authorization data


available

6OLGH8VHULGHQWLILFDWLRQ

Instructors Note: The authentication and authorization processes can fail for any number of
reasons. There are close to one hundred different documented errors that the authentication
sub-system can process. SGOS makes these errors visible to the administrator as families of
issues or individual issues. Administrators can create very granular rules to handle these
failures. In case of an error, you can decide to take one of three actions:
- Return the error to the client in form of failed authentication / authorization
- Allow the user to proceed unauthenticated
- Allow the user to proceed as guest.
The details of how this process works are described in Slide 14-3 and Slide 14-4.

You can configure policy (VPM or CPL) to attempt user authentication while permitting specific
authentication or authorization errors. The policy can specify that, after certain authentication or
authorization failures, the user transaction should be allowed to proceed and not be terminated.
Authentication and authorization can be permitted to fail if policy has been written to allow
specific failures. The behavior is as follows:

Authentication Failures: After an authentication failure occurs, the authentication error is


checked against the list of errors that policy specifies as permitted.

Q If the error is not on the list, the transaction is terminated.


Q If the error is on the list, the transaction is allowed to proceed although the user is

unauthenticated. Because the transaction is not considered authenticated, the


authenticated=yes policy condition evaluates it as false and the user has no
username, group information, or surrogate credentials. Policy that uses the user, group,
domain, or attribute conditions does not match.

Authorization Failures: After an authorization failure occurs, the authorization error is


checked against the list of errors that policy specifies as permitted.

Q If the error is not on the list, the transaction is terminated.


Q If the error is on the list, the transaction is allowed to proceed and the user is marked as
not having authorization data.

Instructor Edition 211

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Q If a user is successfully authenticated but does not have authorization data, the

authenticated=yes condition evaluates it as true and the user has valid authentication
credentials.

Q The user.authorization_error=any is evaluate to true if user authorization failed,

the user object contains username and domain information, but not group or attribute
information. As a result, policy using user or domain actions still match, but policy using
group or attribute conditions do not.

Before creating policy to permit errors, you must:

Identify the type of access the transactions should be permitted.

Identify under which circumstances transactions can proceed even if authentication or


authorization fails.

Identify which errors correspond to those circumstances.

212 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 14: Guest Authentication

Guest Authentication
Identify a user as a guest

Actual guest account on a backend authentication


server not required

Associate Guest to a realm

User not actually authenticate against the realm


User appears as authenticated and authorized in the
specified realm

6OLGH*XHVW$XWKHQWLFDWLRQ

Instructors Note: Guest authentication allows the administrator to create a policy which
tolerate certain authentication errors and associates the user guest to those transactions. You
need to point out to the students:
- The user guest is a fictitious user, meaning it does not exist in any realm. Do not confuse this
guest account with the built-in (and by default disabled) Guest user in Active Directory
- You can also make the user guest appear to the policy engine as part of a real group in your
realm. Again you do not need to create a user in the realm or take any other action there.
- You need to associate the user guest to a realm; however the user is not authenticated
against this realm. It will appear to the policy engine as authenticated in the realm, which is
logically very different.
Make sure to point out to the students that guest authentication cannot be used in the Admin
Layers and that they should carefully consider which errors to tolerate and which not to.

Guest authentication provides the ability to identify a user as a guest user without having an
actual guest account on a backend authentication server and without having to use the policy
substitution realm <guest> user. A realm is specified to authenticate the guest against but it does
not actually authenticate the user against the backend authentication server. Instead it just
determines the username using policy substitution evaluation as needed and marks the user as
authenticated and authorized in the specified realm.
Regular (non-guest) authentication has priority over guest authentication. If a transaction
encounters an authenticate and authenticate.guest condition, it will attempt the authenticate first.
If the regular authentication fails with a tolerated error though then the transaction will
authenticate as the guest user.
Guest authentication can also be used by itself without any regular authenticate properties
specified.

Using policy (VPM or CPL), you can allow a user to log in as a guest user. Guest authentication
allows you to assign a username to a user who would have otherwise been considered
unauthenticated.

Instructor Edition 213

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Since the user is not actually authenticated, the username does not have to be valid in that realm.
If a transaction matches both a regular authentication action and guest authentication action,
regular authentication is attempted first. This can result in a user challenge before dropping back
to guest authentication. If you inadvertently enter invalid credentials and, therefore, drop back to
guest access, you must log out as guest or close and reopen the browser if using session cookies or
connection surrogates. You then can enter the correct credentials to obtain regular access.
Policy available for guest authentication includes:

authenticate.guest

user.is_guest

authenticated

You can also use default groups with any realm, and they can be used when authorization
succeeds, fails or wasn't attempted at all. Default groups allow you to assign users to groups and
use those groups in reporting and subsequent authorization decisions.
You can use default groups in conjunction with guest users or it can be used with regular user
authentication.

Before creating policy for default groups, you must determine which set of groups are assigned as
default. You can specify a single or multiple groups here. In most cases, only a single group will be
required, but occasionally you might need to assign the user to multiple groups:

For extra reporting abilities.

If the policy is structured in a way that users should receive the same access as if they
belonged in multiple different groups.

Policy available for default groups includes:

group

authorize.add_group

You are not limited to these conditions and properties in creating policy.

214 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 14: Guest Authentication

Tolerating Errors

6OLGH7ROHUDWLQJHUURUV

Instructors Note: This slide describes the detailed sequence of events when you have a
policy to tolerate errors. As you should have already mentioned in Slide 14-1, in essence you
can configure ProxySG appliance to do one of three things when it encounter and
authorization or authentication error:
1) Return the error to the client
2) Allow the transaction to proceed as user Guest
3) Allow the transaction to proceed as unauthenticated
Depending on the error and the destination one of the three options is more appropriate than
the others.
Important: Tolerating errors and guest authentication are separate actions, however guest
authentication generally depends on tolerating errors.

You may have the need to encourage all users to authenticate using valid credentials anytime it is
possible; however you may also want the users to have access to many (if not all) the resources on
the internet if the authentication and authorization process fails.
The slide details, in four simplified steps, how you can configure your ProxySG appliance to
handle these kind of errors. It is important that you realize that the options detailed in the slide
(return error, proceed as guest, or proceed unauthenticated) can be determined based on a variety
of triggers.
1.

The user initiates transaction with a ProxySG appliance, which requires authentication. This is
the first time the user agent attempts to connect to this proxy. The proxy starts the
authentication by returning an HTTP 401 response (the details about transparent
authentication are omitted to keep the slide simple). The user submit the credentials.

2.

ProxySG appliance may or may not connect to the remote authentication server (cached
credentials or authentication simply not really required for that transaction).

3.

ProxySG appliance process the authentication and authorization response from the
authentication sub-system and passes it to the policy engine.

Instructor Edition 215

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

4.

Based on having configured the ProxySG appliance to tolerate errors or not (and which errors
are tolerated compared to the ones resulting from the authentication of the current
transaction) the user may:
a.

Receive an error notifying the unsuccessful authentication or authorization.

b.

Be allowed to proceed either as unauthenticated user or a guest user.

216 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 14: Guest Authentication

Persistent Connections

6OLGH7ROHUDWLQJHUURUVZLWKSHUVLVWHQWFRQQHFWLRQV

Instructors Note: This flowchart intends to describe how to manage a new transaction with
in the context of an existing connection between the user agent and ProxySG appliance. The
bottom right part of the flow chart is identical to the flow char in Slide 14-3. The main idea that
you need to deliver in this slide is that when the ProxySG appliance processes a transaction,
which is part of an existing connections, it looks for an user login object. This is where the
guest account plays a vital role.
Important: If a user has failed authentication, it does not have a surrogate credential and the
subsequent transactions will challenge and attempt to reauthenticate the user.

You can have several different transactions happening within the same connection between your
user agent (ex: your web browser) and the ProxySG appliance.

For every transaction, the first step the authentication process takes is to verify if there is already a
user login object for that connection. This basically means verifying the existence of valid
surrogate credentials for that transaction. If the object already exists, then the user is allowed to
proceed to through the policy processing as that user.
When an existing user login object is not found, then SGOS attempts to verify the users
credentials, initiating the authentication process. If the user submits valid credentials, the user is
allowed to proceed through the policy processing as that user. If valid credentials were not
submitted (or did not verify correctly), then based on the policy tolerating the specific
authentication or authorization issue the transaction can be allowed to proceed.

If you allow the transaction to proceed unauthenticated, then you may end up going through this
process at the next transaction. When you allow the transaction to proceed unauthenticated, the
ProxySG appliance does not have a valid user login object for that connection.

If you allow the connection to proceed as guest, then you will not have to go through this entire
process again. For the remainder of the connection, the user login object will have the value of
guest, will be member of the specified realm in the guest authentication rule you created, and will
be member of the groups you defined in the policy.

Instructor Edition 217

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Managing Password Expiration

6OLGH0DQDJLQJSDVVZRUGH[SLUDWLRQ

Instructors Note: This is a practical example on how to use tolerate errors for more than just
allowing a user to proceed through policy as guest. Using a combination of techniques you
can use your ProxySG appliance to do more than just authenticate users.

This slide demonstrates how to use the ability of SGOS to allow administrator to control
authentication errors for more than just permit users to browse without having to submit valid
credentials. This is an example where the ability to tolerate errors largely improves the overall
user experience.

For instance, you can use ProxySG appliance to enable users to change their password when it is
expired. A proxy, which does not have all of the advanced features of ProxySG appliance will
simply denied access to a user whose password is expired.
By allowing the administrators to granularly control and manage authentication and
authorization errors, you can simply the users experience when browsing.
You can allow the user to change their password in three easy steps:
1.

The user connects to the ProxySG appliance; receives an authentication challenge; and the
user responds by sending the appropriate credentials.

2.

ProxySG appliance validates the credentials with the authentication server; the server
responds with an error informing the ProxySG appliance that the password has expired.

3.

Rather then simply returning an generic authentication failure error to the user, the ProxySG
appliance redirect the user to a web page where the password can be changed.

Entirely within the context of the proxy, the user is able to access the requested resource and
manage the expired password.

218 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 14: Guest Authentication

Canceling Login

6OLGH&DQFHOLQJORJLQSURPSW

Instructors Note: While this is another example on how to use the ability the ProxySG
appliance to tolerate authentication errors, you should use it to better explain how the
ProxySG appliance can notify the user of authentication errors.
Immediately after the user initiates a connection with the proxy, ProxySG appliance responds
with an HTTP 401 (or 407 as applicable). There is data in the HTTP response from the proxy,
which contains a properly formatted HTML page. If the user resets the connection, cancels the
connection, or take other similar actions, the content of the HTML page is displayed to the
user. If the authentication fails after the user has sent credentials, a different notification
(detailing the exact error) is sent back to the client.

You are already very familiar with the concepts behind authentication; at the beginning of a new
connection between the user agent and the proxy, the first GET (or other method) request is always
anonymous. Only after the proxy returns an HTTP 407 (or 401 as applicable), the user agent will
first prompt the user to submit credentials and then send them to the proxy.

The initial HTTP response from the ProxySG appliance requesting authentication contains, in the
data part, a properly formatted HTML page. The page is not seen by the user, if the user submits
the credentials. At the most the user sees a browser pop-up window where to enter the user name
and the password. The user sees the HTML page only if it resets or terminates the connection. The
easiest way to see the page is to click cancel in the browsers pop-up window. This is represented
as step 1 in the slide.
If you want to control what happens after the user cancels the login, you need to modify the
HTML page, which the ProxySG appliance sends with the HTTP 401 and HTTP 407. For instance,
if you want the users who do not have an account (they are likely to cancel the login prompt) to
proceed as guest, you need to embed a link in the first HTML page the ProxySG appliance sends
to the client. When the user cancels the login, the page is displayed. The user can then click on the
link. In the ProxySG appliance, you need to have a policy bypassing authentication for the virtual
URL associated to that link and authenticate the user making the request to that virtual URL as
guest.

Instructor Edition 219

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Sample Policy

Redirect a user to a password change page


after a password expiry

6OLGH6DPSOHSROLF\

Instructors Note: This slide basically shows how to implement the policy, which you
conceptually described in Slide 14-5. While you could implement this policy in VPM, using
CPL makes it more clear and more elegant. You can use this as a basis for an on the fly lab.
Make sure that you have setup an environment where you can change expired passwords
from a web page and that you can easily expire users.

The policy, which was conceptually described in Slide 14-5, is implemented in this slide using
CPL. There are three main components to the policy:
1.

A <proxy> layer (or Web Authentication Layer). You configure ProxySG appliance to
authenticate the user in a realm called MyLDAP; at the same time you also allow the proxy
to tolerate the expired_credentials error (combined object)

2.

A <proxy> layer (or Web Access Layer) where you execute the defined action
redirect_to_password_change_page if the users authentication error is
expired_credentials.

3.

A defined action (or Redirect Action object) called redirect_to_password_change_page


which returns an HTTP 302 response to the client and the header:
Location: http://pwdmgmserver/password_change

Based on this sample policies you can create many other useful ones by controlling the necessary
errors to offer your user the best possible experience when browsing.

220 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 14: Guest Authentication

Best Practices

Carefully determine permitted errors

Advanced URL and access log fields to determine


common errors
https://[proxy-ip]:8082/Auth/Error

6OLGH%HVWSUDFWLVHV

Instructors Note: Tolerating errors is a powerful, yet potentially dangerous tool, if used
incorrectly or irresponsibly. An administrator should want to control very carefully which
authentication and authorization errors to permit. This slide allows you to describe one of a
few advanced URLs, which can be used to better define which errors to permit but also to
better understand possible authentication issues in your organization not necessarily related
to ProxySG appliance.

The ability of allowing ProxySG appliance to tolerate authentication and authorization errors is a
very powerful feature; however, when use incorrectly, it can lead to unwanted effects.

For instance, permitting the error group All, which includes the need_credentials error results
in the user never being challenged and not being able to enter valid credentials. While this
behavior can be is useful for single sign on (SSO) realms that are not supposed to challenge but it
can cause an unwanted behavior for challenged-based realms. Another common error is to specify
the incorrect error group or individual error to permit.

You can use the advanced URL displayed in the slide or the access log fields
x-sc-authentication-error and x-sc-authorization-error can be used to help
determine which errors are actually being encountered in various circumstances.

When you look at the information available under the advanced shown above, you should focus
on the Group Membership values. In this case you have a relatively large number of errors
compared to the total authentication attempts. It is likely you may have some issue not related to
the implementation and deployment of ProxySG appliance. It would be a good practise in this
case to allow for instance the entire group of errors under
general_authentication_failure.

Determine when guest access is permitted. If guests always login from a specific subnet then you
can likely just authenticate them as guest without challenging for credentials using the subnet as
source trigger.

If guest is to be used as a fallback only, then ensure that policy is written such that both the
authenticate and authenticate.guest actions are matched

Instructor Edition 221

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Troubleshooting

User never challenged

Permit Any Errors is the selected option


Verify policy for realms other then SSO

Incorrect users or groups permitted

Refer to the Advanced URLs


Use x-sc-authentication-error and
x-sc-authorization-error in access logging

6OLGH7URXEOHVKRRWLQJ

Instructors Note: The troubleshooting techniques discussed here are relatively basic;
however they allow an administrator to solve the most common issues. Again reinforce how
using the group All is a terribly bad idea.
Explain that no-op is the equivalent of do nothing or no action; this term appears in the
student section of this page.
Also mention to the students that Individual errors must be specified in CPL because of
specific design to make the GUI simpler to manage.

The advanced URL and access log fields are two of the best resources for debugging. Access Log
records are useful for determining whether the user logged in as a regular or guest user.
Policy traces are also very useful to determine which authentications were matched and which
errors were matched (can use the user.authentication_error and
user.authorization_error conditions).

ProxySG appliance supports many authentication errors. You can browse the complete list via the
CLI using the show security authentication-errors command. A detailed description
of the individual errors is available in the advanced URL
The VPM only contains the group of errors available for selection. Individual errors must be
specified in CPL.

Note:

An authenticate.guest action can be matched but will be a no-op if the user is


already successfully authenticated

222 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 14: Guest Authentication

Instructors Notes for Guest Authentication Lab


Overview

This lab uses a complete and advanced policy to fully manage authentication (and authorization)
errors and allows access to un-authenticated users. You have an LDAP realm and you want all
users with valid authentication credentials to be authorized to access the Internet via LDAP
authentication. However, you allow users, who do not have valid credentials, to access limited
resources on the Internet.

Computer Hardware and Software Requirements


Table 14-1: Requirements for the Instructor
Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

F SSH Server

F Open SSH version 4.0

Table 14-1: Requirements for Students


Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

F PuTTY

F Release 0.60

Instructor Edition 223

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

224 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 15:SSL Proxy

Estimated Lesson Time: 20 minutes

Instructors Note: SSL proxy is a very powerful feature, virtually unique to Blue Coat. The
SSL proxy feature opens the door to many possibilities for enhancing security and closing
back doors used to circumvent company policies. Some students may feel uncomfortable with
this functionality. You need to present the information in an appropriate manner. It is up to
students and their organizations to decide whether (and how) to apply SSL proxy functionality.

HTTPS, which is simply HTTP over SSL, was designed to offer secure communication between a
client and a server. HTTPS has helped boost online shopping sales. Unfortunately, HTTPS also
presents a corporate security challenge; malicious internal users and Web sites can retrieve or
distribute inappropriate content over HTTPS.

For example, SSL can be used to distribute spyware and other malware. Because the content of an
SSL transaction is usually known only to the requesting client and the OCS, filtering software fails
to detect it. Furthermore, a malicious Web site can deliver viruses over HTTPS, making them
completely undetectable to any gateway antivirus software.

The SSL proxy terminates forward proxy connections, inspects SSL traffic, determines if the traffic
is safe or approved, and then accepts or drops it. The SSL proxy can be deployed in either explicit
or transparent modes.

You may have privacy concerns about using this feature. To alleviate those concerns, you should
combine your SSL proxy deployment with Blue Coat WebFilter (BCWF) software and a local
database. For example, you can use BCWF to create a policy that allows banking and investment
firm traffic to bypass the SSL proxy. You might also want to create custom lists of approved and
suspicious sites in the local database. Using this list, approved sites can bypass the SSL proxy and,
conversely, use the SSL proxy to inspect traffics from the suspicious sites.
This chapter contains a brief introduction to the fundamental concepts behind SSL. You can find
more detailed information in an appendix at the end of this book.
You should become familiar with the following definitions:

Tunnel/Tunneling: Forwarding bytes back and forth between client and server at the Blue
Coat SG

Intercept/Interception: Decrypting SSL connections at the ProxySG

Certificate Validation: Doing various checks on an SSL certificate. These checks include
verification of the issuer signature, dates, and revocation status

CA: Certificate Authority

Instructor Edition 225

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

SSL Fundamentals

Secure Sockets Layer (SSL) provides a


encrypted tunnel through which other protocols
can pass

SSL uses public-key cryptography to exchange


a symmetric key
HTTPS is HTTP over SSL

6OLGH66/IXQGDPHQWDOV

Instructors Note: This slide is a summary. If you decided to skip the previous slide, pause for
a moment and make sure that your students are familiar with these concepts.

HTTPS is the same protocol as HTTP. However, HTTPS is delivered over an SSL tunnel. Persons or
parties who do not possess the correct session key cannot view any part of the TCP payload. SSL is
used for protocols other than HTTP; it can be used for any application protocol that runs on TCP.
Once you have negotiated the session key over an asymmetric key, you open a secure tunnel using
a symmetric encryption algorithm. (The key used to encrypt is the same key used to decrypt.)
SSL provides end-to-end security between clients and servers. Security includes authentication of
both parties of the connection through certificates, information privacy using encryption, and
message integrity mechanisms. SSL encryption strength can vary. 40-bit, 128-bit, and 256-bit
encryption are available. 128-bit encryption offers 288 times as many possible combinations as
40-bit encryption.
SSL uses asymmetric keys to exchange a symmetric key over an insecure medium such as the
Internet.

To validate a Web sites identity and trustworthiness, SSL certificates are issued. SSL certificates
are issued for a single server in a specific domain and only for verified businesses. SSL
certificates are issued by a trusted authority, such as VeriSign.

226 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 15: SSL Proxy

Certificate Authority

6OLGH&HUWLILFDWH$XWKRULW\ &$

Instructors Note: Ask some questions to gauge the familiarity of your audience with this
subject. If everybody is comfortable with the material, you may want to skip this first section of
the chapter. Ask the students what a CA is. If you get a satisfactory answer, then move on. If
not, make sure the concepts are clear before proceeding.

To have confidence that your information is secure, you need to trust the entities you interact with
on the Web. When you initiate an SSL transaction, the other party sends a certificate with their
credentials. You need to be able to validate the authenticity of the credentials with a separate
entity that you trust.
For example, in the case of passports, immigration officials trust that the passport authorities of
other countries have verified the authenticity of a travelers name and picture on the passport.

On the Internet, the role of the passport authority is filled by Certificate Authorities (CA), which
create the digital certificates used by computers to prove their identity to other computers. CAs
make certificates available to everybody on the Internet. If you can verify a certificate by using the
corresponding CA certificate, you can trust the identity of the sender.
To explain in detail , in slide 3-2 :
1.

The server must obtain a digital certificate and a key ring (private key and public key pair).
1b. The CA publishes its own certificate and public key to all clients so that clients can
authenticate the digital certificates from that CA

2.

Client requests a secure (SSL) connection to the server

3.

The server sends the digital certificate and the public key

4.

The client validates the certificates using the information made available by the CA (note that
the client DOES NOT connect to the CA but maintains a database of trusted CA).

Public and private keypairs are critical elements in securing the conversation. With the ProxySG,
you create a keyring that consists of a public key, which you can distribute to anybody, and a
private key, which you must protect and keep secure. Systems that use a pair of public and private
keys are often called public-key infrastructures (PKI).

Instructor Edition 227

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Anybody can encrypt data for you using the public key. However, you are the only person who
can read the information because you have the private key. When you want to talk to Bob, he uses
your public key to securely send you the session key. The session key is smaller key that is used for
a symmetric cipher between you and Bob. The session key is weaker than the public/private key
but it is faster and changes with every transaction.

If you do not want to apply to a CA for a digital certificate, you can create a self-signed certificate or
use a private CA. Anybody can be a CA; all you need is the appropriate software. Windows
Server allows you to create a private CA or create a self-signed certificate. However, these
certificates are not automatically trusted by other entities. Browsers and other software, which use
SSL connections, have a pre-loaded list of certificates that are used to identify well-known CAs.
You can add (import) a certificate into the relevant software to identify your own CA. For
example, you can create a self-signed certificate with ProxySG. If you want your browsers to trust
it, you have to import the certificate into the browsers trusted list. If you use a self-signed
certificate from another device (such as Windows Server), you can import that certificate into both
the browser and the ProxySG.

228 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 15: SSL Proxy

SSL Fundamentals

Initial connection in plain text


Asymmetric (long) key used for key exchange
Symmetric (short) key used for data transfer

6OLGH.H\H[FKDQJH

Instructors Note: This is an important slide. Students must understand how information is
encrypted by the client and server. Ensure that students know that servers send a public key
to the client for use in encryption, and that the server then uses its private key for decryption.
This method is called asymmetric encryption. It is only performed for key exchange and
negotiation. Once a symmetric encryption method has been negotiated, actual data transfer is
symmetrically encrypted using the negotiated method.

Slide 15-3 illustrates the SSL key exchange process. The key exchange (SSL handshake protocol)
begins with an exchange of messages called the SSL handshake. During the handshake, the server
authenticates itself to the client using public-key encryption techniques. Then, the client and the
server create a set of symmetric keys that they use during that session to encrypt and decrypt data
and to detect if someone has tampered with the data.
The transaction uses two types of data encryption: symmetric and asymmetric. Asymmetric
algorithms use one key for encryption, and a separate key for decryption. Symmetric
cryptography uses the same key for encryption and decryption. The key is agreed upon by both
sides during the transaction and can remain static.

Symmetric key encryption is much faster than public-key encryption, but public-key encryption
provides better authentication techniques a malicious party must crack two separate keys.
The key exchange process is as follows:
1.

The client initiates a server request.

2.

The server sends its public key to the client.

3.

The client selects a symmetric encryption key, encrypts the key using the servers public key,
and sends it to the server.

4.

The server uses its private key to decrypt the clients message, which contains the symmetric
key.

5.

The client requests content from the server.

Instructor Edition 229

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

6.

The server uses the specified symmetric method to encrypt the requested content and returns
it to the client.

7.

The client decrypts the data.

230 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 15: SSL Proxy

SSL Proxy

AV scanning

Content filtering

Control server certificate verification

Apply security policies to all Web traffic


HTTP, HTTPS, IM, etc.

6OLGH3RVVLELOLWLHVRI66/SUR[\

Instructors Note: This slide introduces a few of the possible ways that network
administrators can use the SSL proxy. However, do not discuss how Blue Coat implements the
SSL proxy yet. Use the slide that follows.

The SSL proxy functionality allows the ProxySG to read the content of SSL transactions, regardless
of the strength of the encryption key or the algorithm used.
Because it reads and inspects SSL traffic, ProxySG enables you to monitor where your users are
going, with more granularity than ever before. The SSL proxy also allows you to close some of the
back doors that advanced users exploit to circumvent Web filtering. For example, if you allow
HTTPS traffic without restriction, it is relatively simple for a user to set up a secure proxy on a
static DSL IP, and use that proxy to connect to forbidden Web sites.

Using the SSL proxy, you can scan all content for potential viruses at the gateway level. Previously,
if a user accidentally downloaded a virus through HTTPS, you had to rely solely on the client
software for virus detection.

The SSL proxy expands your ability to create a more secure and compliant network infrastructure.
The Blue Coat SSL proxy allows you to:

Determine what HTTPS traffic to intercept through existing policy conditions, such as
destination IP address and port number. You can also use the hostname in the server
certificate to make the intercept decision.

Validate the server certificate to confirm the identity of the server, and check Certificate
Revocation Lists (CRLs) to be sure the server certificate has not been revoked.

Apply caching, virus scanning and URL filtering policies to intercepted HTTPS traffic.

Instructor Edition 231

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

System Architecture

1. Client sends SSL CLIENT HELLO to Blue Coat SG.


2. Blue Coat SG sends CLIENT HELLO to server.

3. Server sends SERVER CERTIFICATE to Blue Coat SG.


4. Blue Coat SG sends its own certificate to client.

6OLGH66/SUR[\VHWXS

Instructors Note: When discussing the SSL proxy feature, try not to use the word attack or
hacking, or a similar term, to refer to the role of the ProxySG. You can say that ProxySG is, by
design, the policeman in any of your networks user conversations.

You have already configured your network so that the ProxySG is in the middle of every
transaction. The SSL proxy allows the ProxySG to terminate SSL requests from the client, present
its own certificate to the client, and request a public key from the server. Once it has the public key,
it opens a connection with the server, exchanges and decrypts data with the server, and then
re-encrypts the data and sends it to the client.
In this configuration, the client has an SSL session with the ProxySG, and the ProxySG has a
separate SSL session with the OCS. The OCS thinks the proxy is the client. The client assumes that
proxy is actually the server.

The browser on the client site will warn the user that it cannot verify the identity of the OCS. This
warning has purposely not been circumvented. Users should be informed that the traffic over a
supposedly secure connection is possibly being intercepted and decrypted. You can use the Notify
User object in the Action column of the Web Access Layer to notify users that their requests are
being intercepted and monitored. Depending on privacy laws, you might also have to obtain user
consent before intercepting HTTPS traffic.

The SSL proxy can also tunnel HTTPS transactions; it does not have to terminate all of them. For
example, you can set up a policy to tunnel all of the traffic for banking sites; the content is not
analyzed. You can also add user-specific restrictions or bypass options. The SSL Proxy will tunnel
HTTPS traffic by default. However, if you want to tunnel traffic to certain sites and intercept traffic
to others you can use the SSL Intercept Layer and the Set SSL Forward Proxy Action object.

Note:

The SSL proxy continues to validate server certificates even when tunneling HTTPS
traffic.

232 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 15: SSL Proxy

Basic Implementation

6OLGH%DVLF66/SUR[\LPSOHPHQWDWLRQ

Instructors Note: This is an important slide because it enables you to graphically illustrate
the concepts discussed earlier. Make sure that students understand how the ProxySG acts as
both the client and server in SSL transactions.
Slide 15-6 illustrates a basic SSL proxy deployment. As with other proxies, the SSL proxy is
deployed between the client and server.
When a client sends an HTTPS request to the OCS, the following actions happen:
1.

The ProxySG intercepts the request and sends the client its certificate and public key.

2.

The client assumes that it is communicating with the OCS and encrypts its symmetric key
using the SSL proxys public key.

3.

The SSL proxy decrypts the symmetric key, using its private key.

4.

The client requests content from the SSL Proxy.

5.

The SSL proxy receives the request and sends an HTTPS request to the OCS.

6.

The OCS (because it assumes that ProxySG is the client) sends its certificate and public key to
the SSL proxy.

7.

The SSL proxy uses the public key to encrypt its symmetric key and sends it to the server.

8.

The server decrypts the message, using its private key.

9.

The SSL proxy requests content from the OCS.

10. The OCS retrieves the requested content and sends it to the SSL proxy, encrypting it with the
SSL proxys symmetric key.
11. The SSL proxy scans the message for illegal content, encrypts the data using the clients
symmetric key, and delivers it to the client.

Instructor Edition 233

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Sample Policy

The default behavior is not to intercept SSL


traffic
You can selectively intercept traffic

Financial / Banking site -> Do not intercept

HR related / Retirement -> Do not intercept


Other sites - > Intercept

6OLGH6DPSOHSROLF\

Instructors Note: This slide shows the default behavior for the SSL proxy. You can use this
slide to discuss user-sensitive data and privacy so that students are aware of the privacy
concerns that can arise with SSL proxy use.

The default behavior is not to intercept SSL traffic. To allow SSL content to be examined, select the
Intercept as HTTPS radio button in the Add SSL Forward Proxy Object dialog box. When the SSL
proxy intercepts HTTPS connections, it generates a private key and corresponding certificate
dynamically.

It is advisable to protect user privacy for some SSL transactions. For example, you can use filtering
software (for example, BCWF) to create rules to exclude financial, 401k, and other user-sensitive
sites from interception.

234 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 15: SSL Proxy

VPM Layers

SSL Intercept Layer

Triggers and properties to decide tunnel vs. intercept


action

SSL Access Layer

Additional SSL-related triggers and properties

6OLGH66/OD\HUVLQWKH9LVXDO3ROLF\0DQDJHU

Instructors Note: Show the content of this slide interactively. There are two new layers;
create a policy in each one of them.
The Visual Policy Manager (VPM) features two SSL-related layers.

The SSL Intercept Layer has the following columns: Source, Destination, Action Track, and
Comment.
The SSL Layer has the following columns: Source, Destination, Action, Service, Track and
Comment.

Use the SSL Intercept Layer to control which sites are intercepted and also to control the contents
of the certificate presented to the client. Use the SSL Access Layer to control server certificate
validation and other aspects of SSL communication like SSL version, ciphers, etc.
Note:

These layers do not have the Time column because it has no meaningful usage here.
The SSL Intercept Layer does not have a service either (as it is applicable to SSL only).

Instructor Edition 235

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

236 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 15: SSL Proxy

Instructors Lab Notes for SSL Proxy


Overview

Students will configure their ProxySG to intercept HTTPS traffic.

IP Addressing Scheme
Equipment

Students SG

Role

IP Address

Proxy

172.16.90.2x

Computer Hardware and Software Requirements


Table 15-1: Requirements for the Instructor
Software/Hardware

Version/Model

Firefox

Version 2.0.0.5

Internet Explorer

Version 6.0 or above

SGOS

5.2.1.3 build 30166

Windows XP

SP2 build

Table 15-1: Requirements for Students


Software/Hardware

Version/Model

Firefox

Version 2.0.0.5

Internet Explorer

Version 6.0 or above

SGOS

5.2.1.3 build 30166

Windows XP

SP2 build

Desired Results

Students will know that their HTTPS connection has been intercepted when they see the certificate
error message.

Instructor Edition 237

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

238 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 16:Bandwidth Management

Estimated Lesson Time: 45 minutes

Instructors Note: This chapter describes how the Bandwidth Management (BWM) feature
works both from the point of view and the user and the actual architectural implementation.
Slides from 12-1 to 12-7 are relatively simple and descriptive; the last slides in the chapter go
into lots of details. As in instructor you can decide to skip them. You will be reminded again in
the notes for those slides that you can skip them.

Introduce the conversation about BWM as a tool that allows organization to prioritize business
critical traffic without necessarily blocking all non-business related or recreational resources
on the Internet.

BWM assumes particular important at the remote locations, when you usually have more
limited bandwidth and you want to make sure than the most of it is used to access applications
and data at the HQ and not for personal use.
You should also set the expectation at the correct level for this feature. Mostly point out that
ProxySG does not change TCP window size nor artificially delays specifically TCP ACK
packets. The BWM engine in ProxySG uses the concepts behind the Hierarchical Token
Bucket (HTB).

This approach, while it does not guarantee that the limits for bandwidth are respected down to
the byte (a small margin of error is inherited in this process), it is by many considered to be
one of the most elegant and effective.
BWM using HTB relies on four fundamental concepts: priority, maximum, minimum, and
parent-children relationships.

Additionally this chapter compares BWM with Admission Control for multimedia streaming
applications.

Bandwidth Management (BWM) allows you to classify, control and, if required, limit the amount
of bandwidth used by different classes of network traffic flowing into or out of the ProxySG and
destined for single or multiple devices.
Bandwidth management provides the following benefits:

Guarantees that certain traffic classes receive a specified minimum amount of available
bandwidth. (See note below.)

Limits certain traffic classes to a specified maximum amount of bandwidth.

Prioritizes certain traffic classes to determine which classes have priority over other classes for
available bandwidth.

Bandwidth Management relies on user-defined bandwidth classes and policy rules to manage the
available bandwidth coming into or out of the ProxySG appliance. There are four characteristics of
bandwidth classes: minimum bandwidth, maximum bandwidth, priority, and parent designation
(used to configure class hierarchies).
Minimum bandwidth works by guaranteeing a predefined amount of bandwidth (if available on
the network) to the class. Similarly, maximum bandwidth limits the amount of bandwidth that a
particular class may use. Classes can also be prioritized so that certain traffic receives bandwidth
before others. To implement minimums or prioritization, a class hierarchy must be created with a

Instructor Edition 239

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

maximum bandwidth allocation. This allows the appliance to determine how much bandwidth is
too much for a low or medium priority bandwidth class. Creating class hierarchies provides the
most flexibility for Bandwidth Management. Class hierarchies allow administrators to apply
classes at a granular level, taking various criteria into consideration to determine the final
bandwidth allocation allowed.

To determine which class to assign to a particular connection, the ProxySG appliance evaluates the
configured policy to determine if any of the connection attributes match the policy rules assigned
to bandwidth classes. Blue Coat Policy has a rich set of triggers that can be evaluated to classify
traffic flows this comprehensive set of triggers include, but is not limited to, user, group,
destination, protocol, subnet, content-filter category, or DSCP value. By creating classes and
assigning specific types of traffic to them, you can effectively control how the available bandwidth
is used.
An administrator managing a branch office wants to ensure that no more than half of the total
bandwidth available is used for HTTP or FTP traffic to guarantee that other business-critical
applications continue to function. However, when the CEO visits this branch office, she should
have priority over other employees when using this allocated bandwidth. To accomplish this, the
administrator:

Creates a bandwidth class Branch Office and configures the maximum bandwidth to an
amount equal to half of the total available bandwidth.

Creates a policy rule for the Branch Office class, assigning all HTTP and FTP traffic to this
bandwidth class.

Creates two additional bandwidth classes Employees and CEO and sets the appropriate
priorities.

Creates policy rules identifying the CEO and everyone else; these rules assign such traffic to
either the Employees or CEO bandwidth class.

Makes the Branch Office class the parent class of both the Employees and CEO classes.

The administrator now has a bandwidth hierarchy. Bandwidth is limited by the configuration of
the parent class, and the two child classes are prioritized to determine how they share any unused
bandwidth. Because no minimums have been set, the highest priority class has the first
opportunity to use all of the available bandwidth; whatever is left then goes to the next priority
class.

240 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 16: Bandwidth Management

Bandwidth Management (BWM)


Protect performance of key applications

Prevent bandwidth-greedy applications from


impacting other programs
Provide bandwidth for applications that require a persession amount of bandwidth

Balance important, bandwidth-intensive


applications

6OLGH%DQGZLGWKPDQDJHPHQWEHQHILWV

Instructors Note: This is an introductory slide. Remind the students that BWM allows you to
create policies that maximize business critical traffic performance, while having to necessarily
block all other traffic.

In a world where clients, servers, and data all come in different types, treating all network
connections as a single traffic flow does not give administrators the flexibility to ensure that
business-critical applications perform as required. Imagine finding out that the CEO could not
access critical reports because an employee spent his lunch break watching streaming videos.
Using Bandwidth Management, administrators can control network traffic flow so that the
appropriate users, groups, or applications receive the proper network resources.

Bandwidth Management is often used to guarantee access to business-critical applications or Web


sites. For other, more obscure traffic on the network, Bandwidth Management can be used in
conjunction with content-filtering to make bandwidth management decisions based on the type of
sites being accessed. Specifically:

BWM prevents resource-greedy applications such as peer-to-peer and streaming video


from impacting other, more important programs, such as e-mail and client-server
applications.

BWM allows administrators to provide for applications that require a per-session amount of
bandwidth. For instance, multimedia applications may require a certain amount of bandwidth
in order to enable all their features.

BWM enables administrators to balance important bandwidth-intensive protocols and


applications, such as HTTP and instant messaging (IM).

Without BWM, network administrators may be forced to block IM and streaming audio and video.
However, implementing BWM, administrators can allow controlled access to these
less-than-critical but still useful tools.

Instructor Edition 241

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

BWM Hierarchies and Priorities

6OLGH%DQGZLGWKKLHUDUFKLHVDQGSULRULWLHV

Instructors Note: This is easily the most important slide in the chapter as it graphically
shows how ProxySG manages and organized bandwidth classes. The root class is often
implied, meaning that most implementation will only have C1, C2, and C3 as in this example.
However it is a good idea to create a root class and assign to it the actual parameters for your
Internet pipe.

Point out the three following key elements:


1) The priority (from 0 to 7) is only meaningful among siblings. For instance C1a does not have
higher priority (7) than C2 as they are not siblings.
2) The sum of the minimums of all children cannot exceed the min of the parent class
3) The maximum value for the maximum of all the children cannot be higher than the
maximum of the parent.
Unless you create a root bandwidth class, point 2 and 3 are not enforced on the parents (in
this case C1, C2, and C3).

Important: Point out that C1, C2, and C3 are just reference names. You should use meaningful
names. Additionally you can have as many BWM classes as you like at each level

The first step in managing bandwidth is to create bandwidth classes. Each bandwidth class
represents a particular type of network traffic. You create classes either through the Management
Console or the command-line interface (CLI).

Once you have created a bandwidth class, you can write policy through the Visual Policy Manager
(VPM) or CLI. You can guarantee that a class receives a minimum amount of available bandwidth.
You also can limit the amount of bandwidth for the class.
In addition, you can set priorities for different classes for available bandwidth, depending on your
organizations business requirements and network resources.

242 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 16: Bandwidth Management

Note:

In most cases, if you plan to manage the bandwidth of streaming media protocols
such as Windows Media, Real Media, or QuickTime Blue Coat recommends
that you use the ProxySGs streaming features instead of its bandwidth-management
features. You cannot use both at the same time.

Creating a bandwidth class allows you to allocate a portion of available bandwidth to a particular
type of traffic. Putting that class into a bandwidth hierarchy allows you to set priorities for
available bandwidth among multiple classes.
To build a hierarchy, you create one bandwidth class as the parent and then create other
bandwidth classes as the children. Child classes can have children of their own.

The parent node must have the available bandwidth to satisfy the child minimums. If multiple
hierarchies compete for the same available bandwidth, the ProxySG cannot guarantee the
minimums defined for each class.

You can set priorities to give some bandwidth classes precedence over other bandwidth classes.
However, priorities can be set only for sibling classes child classes with the same parent. You
also can set priorities for hierarchies if they have the same parent class.

In order to set priorities, you must set a maximum somewhere in the hierarchy. When a maximum
is set for a class, queues of packets form, waiting to be sent. This gives the ProxySG the
opportunity to apply priority settings. However, if no limit is set, packets are sent as soon as they
arrive, and the ProxySG cannot set priorities.
If there is excess bandwidth, the class with the highest priority gets the first opportunity to use it.
When the highest-priority class uses all the bandwidth it needs or is allowed, the next-highest
class has its turn. If two classes in the same hierarchy have the same priority, they share the excess
bandwidth in proportion to their maximum settings.

In the example shown in Slide 16-2, the company has an E1 pipe to the Internet, which allows a
maximum bandwidth of about 2 Mb/s. The administrator has created three bandwidth classes:
C1, C2, and C3. The sum of the maximum allowed for the three classes is 1.2 Mb/sec.; the
remaining 800Kb/s can be used for the other traffic flowing through the ProxySG at any time.
Indirectly the administrator has defined the maximum available for the traffic which does not fall
into any of the three existing bandwidth classes. Then sum of the minimums available to the three
classes is 662Kb/s. If there is sufficient traffic going through the ProxySG to occupy at least the
minimum per each of the three classes, the maximum bandwidth available for all other traffic will
be 2Mb/s minus 662 Kb/s (about 1.3 Mb/s).
The excess bandwidth, if any, is distributed to the parent classes (C1, C2, and C3) according to
their priority. Each class manages its own excess bandwidth with its children using the relative
priorities among the them. The priority is a parameter meaningful only between siblings. For
instance C3 has the highest priority as a parent class; its definition of priority 1 is not relevant to
the priority definition for C2a, which is 1 as well.

To better understand how the bandwidth is shared among siblings based on priority, you need to
learn about Hierarchical Token Bucket theory (HTB), discuss later in this chapter.
Important: BWM does not reserve bandwidth or guarantee that available bandwidth can
sustain any of the bandwidth minimums configured on the ProxySG. The feature
can only control the traffic flowing through the proxy and prioritize some of the
flows according to configured policy.

Instructor Edition 243

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

BWM Traffic Flow

6OLGH7UDIILFIORZDQGEDQGZLGWKPDQDJHPHQW

Instructors Note: There are 4 types of bandwidth that you can control with ProxySG. You
can control all of them, none of them, or sum of them. Typically, for forward proxy customers,
server inbound is the main priority. For the reverse proxy customers, both client inbound and
client outbound are important. Try to engage the students in a conversation.
Question: What is the one flow that you want to control and why? Discuss the answers.
Important: Most student have a hard time understanding how a forward proxy can control
server inbound. The slides at the end of the chapter help you answering this, but for now just
mention how delaying requests help ProxySG control the amount of data it receives in
response.

ProxySG allows you to control bandwidth in any direction. Using a relatively simple queueing
algorithm, ProxySG can manage inbound and outbound bandwidth without having to modify
critical parameters like the size of the TCP window for a connection, or artificially delay specific
TCP ACK packets. The queueing approach provides broader BWM scheme that covers both TCP
and UDP and also support BWM for inbound and outbound traffic.
To manage the bandwidth classes you create, you need to write policy rules to classify traffic
flows. Flows are defined as a set of packets belonging to the same TCP/UDP connection that
terminates at, originates at, or flows through the ProxySG.
A single request from a client involves two separate connections: one from the client to the
ProxySG and the other from the ProxySG to the origin content server. Within each of these
connections, traffic flows in two directions; therefore, traffic can be classified into one of four
types:

Client inbound: traffic flowing into the ProxySG from a client making a request to a server

Server outbound: traffic flowing out of the ProxySG to a server to transmit the request

Server inbound: traffic flowing back into the ProxySG from a server in response to a client
request

Client outbound: traffic flowing back out of the ProxySG to a client to transmit the response

244 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 16: Bandwidth Management

Each policy rule can apply to only one traffic flow type. However, you can use the same
bandwidth management class in different policy rules so that one class can manage bandwidth for
several types of flows according to different criteria.
If multiple policy rules match a flow and try to classify it into multiple bandwidth classes, the
most recent classification done by policy applies.

Instructor Edition 245

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

BWM Bandwidth Maximums

6OLGH%DQGZLGWKPD[LPXPVHWWLQJ

Instructors Note: Definitely this is the easiest slide to discuss. It is also describing what the
students will be doing in the first lab. The idea behind maximums is very simple: more users
connect to share the same bandwidth class, less bandwidth each user receives. This is not a
problem for most application (maybe for the user it is).

Question: Which protocols are sensitive to time delays and why?


Answer: Protocols based on audio and/or video (VoIP, MMS, etc). This is because the brain
needs to see images at a minimum speed and hear sounds with a maximum allowed delay in
order to understand them.

Setting a maximum for a bandwidth class puts a limit on how much bandwidth is available to that
class. It does not matter how much bandwidth actually is available; a class can never receive more
bandwidth than its maximum.
To keep a bandwidth class from using more than its maximum allotment, the ProxySG queues
packets associated with that class until the bandwidth used is no greater than the specified
maximum.

Maximum settings unlike minimum and priority settings can reduce the flow for a class. The
drawing on the left in Slide 16-4 shows an over-subscribed network. When bandwidth classes are
oversubscribed, traffic continues, but at a slower rate, as shown by the drawing on the right.
However, in extreme cases, connections may fail. Also, with the maximum setting, unused
available bandwidth can go to waste.
Unused bandwidth can go to waste with the maximum-bandwidth setting, while the
minimum-bandwidth settings and priority levels always distributes any unused bandwidth as
long as classes request it. However, priority levels are not meaningful without a maximum
somewhere in the hierarchy. If a hierarchy has no maximums, any class in the hierarchy can
request and receive any amount of bandwidth regardless of its priority level.

246 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 16: Bandwidth Management

Important: The maximum of the maximum for all root level classes, cannot exceed the actual
available bandwidth. Since the ProxySG is not really aware of your actual pipe to
the Internet, you need to ensure consistency at least for the root level. ProxySG
enforces this constraints on the children classes.

Instructor Edition 247

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

BWM Admission Control v. BWM

6OLGH$GPLVVLRQFRQWUROYEDQGZLGWKPDQDJHPHQW

Instructors Note: The question you asked for Slide 12-4 makes sense here. Since MMS
applications are time-delay sensitive, ProxySG offers, in addition to BWM, admission control.
The key difference is that in Admission control, each client is not allowed to go below the
minimum requested. If new users request bandwidth they are denied until other current users
disconnect. You should use Admission Control for business critical application, BWM for
recreational use of MMS.
Important: There is no Admission control for the VoIP protocols.

You can control streaming bandwidth using two different methods: you can use the streaming
features called Admission Control, or you can use the bandwidth management features described
so far. You should not, however, use both methods to control streaming bandwidth. The way that
each method controls bandwidth differs.
Limiting streaming bandwidth using the streaming features works this way: if a new stream
comes in that pushes above the specified bandwidth limit, that new stream is denied. This allows
existing streams to continue to get the same level of quality they currently receive.

Limiting streaming bandwidth using the bandwidth management features works this way: all
streaming traffic for which you have configured a bandwidth limit shares that limit. If a new
stream comes in that pushes above the specified bandwidth limit, that stream is allowed, and the
amount of bandwidth available for existing streams is reduced. This causes streaming players to
drop to a lower bandwidth version of the stream. If a lower bandwidth version of the stream is not
available, players that are not receiving enough bandwidth can behave in an unpredictable
fashion. In other words, if the amount of bandwidth is insufficient to service all of the streams,
some or all of the media players experience a reduction in stream quality.
You should choose admission control instead of bandwidth management when the quality of
streaming data is important, such as during a teleconference. Admission control preserves the
quality of the data by limiting the number of connections while bandwidth management shares
bandwidth to grant additional client requests.
For most circumstances, Blue Coat recommends that you use the streaming features to control
streaming bandwidth rather than the bandwidth management features.

248 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 16: Bandwidth Management

BWM - Minimums

6OLGH0LQLPXPEDQGZLGWKVHWWLQJZLWK3UR[\6*QRWLQEULGJLQJPRGH

Instructors Note: Use this slide to start a conversation with the class. The idea of the slide is
to represent the following:
- The users over HTTP generate at the moment over 1000 Kb/s of traffic
- The other users, not going through the proxy, generate over 700 Kb/s of traffic
- The HTTP bandwidth class has a minimum of 1000 Kb/s
- The maximum pipe to the Internet is 1500 Kb/s

Question: Can ProxySG satisfy the requirement of minimum bandwidth?


Answer: No. Since there is more traffic than the Internet pipe can handle and ProxySG only
has control on the HTTP portion, the traffic will be slowed for all sections. The ProxySG cannot
therefore guarantee the minimum
Question: Where can you re-position the proxy so that minimum settings can be enforced?
Answer: In bridging mode between the core switch and the firewall (Move to the next slide)

Setting a minimum for a bandwidth class guarantees that the class receives at least that amount of
bandwidth, provided that the bandwidth is available. If the available bandwidth is not enough to
cover the minimum, there is no guarantee that classes will receive their minimum bandwidth.

The ProxySG can control only the traffic that flows through it. So if you want to set minimums, it is
a good idea to set your ProxySG in bridging mode.
The drawing in Slide 16-6 shows a ProxySG configured to give a minimum of 1,000 kilobits of
available bandwidth to HTTP traffic flowing through it. Other traffic on the network takes another
700 kilobits of bandwidth. However, because the ProxySG is not acting as a network bridge, it has
no control over the other, non-HTTP traffic.
Because the network has only 1,500 kilobits of bandwidth available, it cannot accommodate both
the HTTP bandwidth class minimum of 1,000 kilobits and the 700 kilobits of other traffic. So both
HTTP traffic and other traffic slow to a total of no more than 1,500 kilobits.

Instructor Edition 249

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

If an internal/leaf node has a minimum defined, the class hierarchy guarantees that this minimum
is guaranteed to the class when there is bandwidth available for the class hierarchy. If there are
multiple hierarchies defined which compete for the same available bandwidth or if the available
bandwidth for a class hierarchy is less then the minimum, BWM cannot guarantee the minimums
defined at each node. So then administrator should be careful not to create class hierarchies, which
share the same network bandwidth if he wants to guarantee minimums.
Important: The sum of the minimums for all root level classes, cannot exceed the actual
available bandwidth. Since the ProxySG is not really aware of your actual pipe to
the Internet, you need to ensure consistency at least for the root level. ProxySG
enforces this constraints on the children classes.

250 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 16: Bandwidth Management

BWM Minimums

6OLGH0LQLPXPEDQGZLGWKVHWWLQJZLWK3UR[\6*LQEULGJLQJPRGH

Instructors Note: There is not much to cover on this slide as it shows the result for the
discussion you already had on Slide 12-6. Reiterate how now the proxy can see all traffic and
even if it is no intercepting it all, it can enforce the minimums on the intercepted traffic.

As discussed in the previous slide, ProxySG can only control the traffic that it processes. If there
are streams of data, which can access the outside world using a path, which does not include the
proxy, then it is obvious that ProxySG cannot affect that bandwidth. Even worse, the bandwidth
that cannot be controlled by the proxy, can void the ProxySG attempts of satisfying the minimum
requirements that you set forth in the definition of a bandwidth class.

By strategically deploying ProxySG in the network where it has the opportunity to observe all the
traffic flowing out of your network, it can satisfy the minimum requirements that you defined.
The ProxySG ships with a pre-defined class hierarchy. The maximum and minimum values for
this bandwidth is set to unlimited, which means that by default there is bandwidth management
for any type of traffic, just classification. You have to change this default hierarchy by adding,
deleting, or modifying classes or at the minimum assign minimum and maximum values, to suit
his Bandwidth Management needs.

Using the example describe in Slide 16-2, at the root level, ProxySG has four buckets, one for each
of the three defined classes C1, C2, and C3 and a fourth one for all other traffic. While ProxySG
does not process (proxy) the traffic which does not match any of the proxy services, it can still
detect and control its flow. All uncategorized traffic and bypassed traffic is allocated to the fourth
bandwidth bucket. At this point ProxySG can control the flow for all traffic and can guarantee the
minimum setting for C1, C2, and C3 even if there is other extraneous traffic flowing though the
proxy.
In the end, if you want the minimum bandwidth settings to be meaningful, you have to deploy
ProxySG in bridging mode. This is Blue Coat recommended deployment; additionally you can
configure you ProxySG to be the default gateway. This deployment option, while practical is not
recommended.

Instructor Edition 251

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

BWM - Architecture

6OLGH%:0DUFKLWHFWXUH

Instructors Note: This is an optional slide. You do not have to go into the details, but if you
want, point out the following key aspects:

1) All inbound and outbound traffic goes through the BWM Queuing algorithm (this helps
answer the questions for Slide 12-7)
2) The policy engine reads the data from the BWM classifier which then passes it back to the
queue.

The administrator uses the Management Console or the CLI to create and configure bandwidth
classes. The administrator also places the classes into a bandwidth class hierarchy and allocates
the maximum, minimum bandwidth and priority for the classes.

Once the bandwidth allotment is done, the administrator uses the Visual Policy Manager which is
accessible through the Management Console or composes Content Policy Language to create
policies for managing the traffic flow for the classes. Each policy rule can only apply to one of four
traffic flow types Client inbound, Client outbound, Server inbound and Server outbound.

The Web Access layer in the Policy engine needs to have knowledge of the BWM classes the
administrator creates so that its BWM policy rules can be evaluated and verified at compile time
for correctness. The BWM component of the ProxySG works between the Network Interface and
the IP layer of the OSI module. When a client makes a HTTP request, the ProxySGs classifier
identifies the traffic and provides actual bandwidth services. The classifier prioritizes the packet, it
places it into a queue. The BWM queuing module uses the classifier to figure out the correct queue
to use for a particular flow. BWM Queuing Module uses the Hierarchical Token Bucket (HTB)
algorithm to classify the packets into various queues.
Analyzing the slide in more details, you can notice how:
1.

The BWM Queuing primarily interacts with the network layers (IP) to control the bandwidth
utilized by the traffic flowing through the SG.

2.

The BWM Classifier allows the Application Proxies to specify the class that a particular
connection belongs to. The queuing module uses the classifier to figure out the correct queue
to use for a particular flow.

252 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 16: Bandwidth Management

3.

The administrator uses GUI or CLI to build and modify Bandwidth Management class
hierarchies.

4.

The Policy Layer will need to have knowledge of the Bandwidth Management classes that are
created by the administrator so that its bandwidth management policy rules can be evaluated
and verified at compile time for correctness.

Instructor Edition 253

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

BWM Tagging Packets

6OLGH%:0SDFNHWGHOLYHU\

Instructors Note: This is an optional slide. The most important role for the BWM engine is to
properly classify the packets based on the classes created. You can use virtually any of the
triggers available in the Web Access Layer to assign bandwidth. You can allocate bandwidth
by user, protocol, category, host, etc. The policy puts the packets in the different classes, then
the queuing engine decide which packet to extract from which class in order to satisfy the
BWM classes requirements.

The ProxySG tags data in order to implement bandwidth management policy. Data is tagged
according to its protocol at the application layer. The BWM Classifier enqueues or separates
packets into the appropriate bandwidth management class according to their application tags. In
the slide, the BWM Classifier sorts packets 1-4. For example, if Class 1 is HTTP, Class 2 is FTP, and
Class 3 isP2P, then the Classifier sorts packets and drops them into respective classes. HTTP
packets 1 & 3 into Class 1, FTP packet 2 in Class 2 and P2P packet 4 in Class 3.
Packets are then put in virtual queues. Each queue is processed using a first-in first-out approach
(FIFO). The Hierarchical Token Bucket (HTB) algorithm in the BWM Queuing module determines
the order in which the packets are sent according to the bandwidth class, policy and the available
bandwidth. Then the packets are de-queued or delivered based on the decision.The rate at which
packets are pulled from each queue is based on the policies. Once the packet is extracted from the
queue, it is inserted into the network.

254 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 16: Bandwidth Management

Hierarchical Token Bucket (HTB)


Classifies packet into various queues
Uses concepts of tokens and buckets

Minimum and maximum bandwidth allocations

Uses priority to distribute excessive bandwidth


Lower priority queues to temporarily borrow currently
unused bandwidth from queues with higher priority

6OLGH+LHUDUFKLFDOWRNHQEXFNHWWKHRU\

Instructors Note: This is an optional slide. The HTB theory is widely used in the Linux and
Unix kernels to manage process priority but it can be used also to manage network traffic. At
the basis of the HTB you have the concept of priority and the ability for children to borrow
bandwidth from the parents based on their relative priority.

Each bandwidth class is seen essentially like a bucket. The bucket is filled with tokens. Only if
there are tokens in the bucket, then the system can extract packets from the queue
representing that BWM class.

The Hierarchical Token Bucket (HTB) theory of traffic shaping helps classify packets into various
queues using criteria set by the system administrator. HTB uses the concepts of tokens and
buckets along with class based bandwidth allocation and filters to allow complex and granular
control over traffic.
In order to control the rate of de-queueing, BWM Queuing generates tokens at a desired rate and
will only dequeue packets or bytes if a token is available. Otherwise packets are deferred.
Delaying packets in this way introduces latency. A bucket contains a number of tokens. The
bucket is filled with tokens according to the rate. Bucket size limits number of instantaneously
available tokens. If the tokens are not used, the bucket fills up. If tokens are used the bucket will
not fill up. So, the rate at which the packets are de-queued depends on the availability of tokens
and the size of the bucket.

Sometimes certain classes with a higher bandwidth allocation will have surplus tokens and there
will be other classes that are starved for tokens. HTBs borrowing mechanism solves this problem.
HTB allows lower priority queues to temporarily borrow currently unused bandwidth from
queues with higher priority.

Instructor Edition 255

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

HTB Borrowing

6OLGH+7%%RUURZLQJFRQFHSW

Instructors Note: This is an optional slide. It is actually pretty simple graphical


representation of the HTB and its ability to borrow token from parents to children.

It also shows you the same tree structure that the ProxySG uses to manage the relationship
between bandwidth classes.

Queues are first organized in a tree with root, inner root and leaf. Each classification inherits
bandwidth restrictions from its parent node. Children classes borrow tokens from their parents
once they have exceeded their rate (minimum bandwidth for a given leaf class). A child class will
continue to attempt to borrow until it reaches the ceiling (the maximum bandwidth for the child
class). Then the child class will queue packet for transmission until more tokens are available.

In order for the borrowing model to work, each class must have an accurate count of the number
of tokens used by itself and all its children. Any token used in a child or leaf class is charged to
each parent class until the root class is reached. Any child class which wishes to borrow a token
will request a token from its parent class, which if it is also over its rate will request to borrow from
its parent class until either a token is located or the root class is reached. So the borrowing of
tokens flows toward the leaf classes and the charging of the usage of tokens flows towards the root
class. Shaping of traffic only occurs in leaf classes. HTB does not delay packets in inner classes.
The bandwidth management subsystem implements a Hierarchical Token Bucket (HTB) algorithm
to share the bandwidth in the class hierarchy. For the HTB algorithm to work correctly, the
bandwidth management subsystem implements certain rules and restrictions for creating a valid
bandwidth management class hierarchy:

Each flow can only belong one bandwidth management class.

Once a flow is classified to belong to a bandwidth class, that class is penalized for all packets
that belong to that flow.

The sum of the minimum bandwidths of all the children of a given parent node should not
exceed the maximum bandwidth defined for the parent or any of his ancestors.

Max on child cannot exceed max on parent.

256 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 16: Bandwidth Management

Instructors Notes for Bandwidth Management Labs


Overview

Bandwidth management allows you to control the amount of bandwidth used by different classes
of network traffic flowing into or out of the Blue Coat SG appliance. By managing bandwidth
you can:

Guarantee that certain classes of traffic receive a minimum amount of available bandwidth.

Limit certain classes of traffic to a maximum amount of bandwidth.

Determine which classes of traffic have priority over other classes.

Protect the performance of key applications.

Note:

The ProxySG appliance does not reserve bandwidth or otherwise guarantee that
available bandwidth can sustain any of the bandwidth limits configured on it. The
ProxySG appliance only shapes various traffic flows passing through it and prioritizes
some flows according to configured policy.

Computer Hardware and Software Requirements


Table 16-1: Requirements for the Instructor
Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Table 16-1: Requirements for Students


Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Instructor Edition 257

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

258 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 17:Managing Streaming Media

Estimated Lesson Time: 20 minutes

Instructors Note: The goal to this chapter is show at a very high level what are the features
and functionalities, which are available in SGOS to better manage streaming media. The two
main concepts that the user needs to understand are: 1. Delivery methods used for multimedia
streaming (MMS) 2. Protocol hand-off from HTTP to MMS In particular point out that ProxySG
can manage MMS over TCP and UDP. At this point you can ask the following:
Question: Besides Streaming, which other UDP based protocol ProxySG can intercept?
Answer: DNS over UDP. Spend some time discussing the difference between a live stream
(when the data is broadcasted live and it not available afterwards) and video-on-demand
(VOD), when the stream comes from a file and can be started by different people at different
times.

Based on the knowledge level in you class you may also discuss briefly the fundamental
concepts behind multicasting. You can use the following paragraph for some basic concepts
about it. IP multicast is designed to allow one source to talk to many destinations over an IP
network. Multicast is used to reach a large and unknown number of recipient minimizing the
amount of traffic that the source generates. Multicast relies on the existing network
infrastructure by efficiently requiring the source to send a packet only onceand allowing other
intermediate devices like switch and routers, to propagate the packets to the various users.
ProxySG supports Microsoft Windows Media, Real Networks RealPlayer, and Apple
QuickTime; however, the various players might experience unexpected behavior dependent
upon certain SGOS configurations and features. Feature sections list such interactivities, as
necessary. For a list of the most current versions of each supported client, Release Notes for
the release you are using in class

At its most basic, streaming media is a form of content delivery. Streaming media is used to
deliver many types of content such as Internet radio, video clips, public address, etc. With
streaming media, video and audio content are delivered over the Internet. This makes it possible
for a client to watch or listen to the content without having to wait for the entire file to download
before it can be played.
Streaming media support on the ProxySG appliance provides the following features:

Streaming media files can be live or prerecorded.

Employs flexible delivery methods: unicast, multicast, HTTP, TCP, and UDP.

Ability to seek, fast-forward, reverse, and pause (video-on-demand only).

Ability to play entire file and control media playback, even before it is downloaded.

Adjust media delivery to available bandwidth, including multi-bit-rate and thinning support.

Using the ProxySG appliance for streaming delivery minimizes bandwidth use by allowing the
ProxySG appliance to handle the broadcast and allows for policy enforcement over streaming use.
The delivery method depends on if the content is live or video-on-demand.
Additionally, there are many ways that the ProxySG appliance can be used to make streaming
media more easily available and less of a burden on your network:

Type of streaming media: live or video-on-demand

Delivery method: unicast or multicast

Instructor Edition 259

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Caching: video-on-demand content can be fully cached or partially cached on the ProxySG
appliance for easy and quick access

Managing bandwidth: through configuration, the administrator can place bandwidth limits
on both the server side and client side

The use of ProxySG appliance allows you to control and maximize the use of streaming media
over your network. Commonly used streaming media content can be managed in such a way that
it is readily available for use.
The ProxySG appliance supports the following streaming media players:

Microsoft Windows Media

RealNetworks RealPlayer

Apple QuickTime

260 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 17: Managing Streaming Media

Managing Streaming Media


Content Types

Live Streams
Video-on-demand

Caching

Content pre-population
Authentication
Partial and complete object caching

6OLGH0DQDJLQJ6WUHDPLQJ0HGLD

Instructors Note: The slide reassumes the concepts that you are going to discuss in the
chapter. Use this slide to cover some of the information that you have in the instructor notes at
the beginning of this chapter. Particularly point out that for MMS, ProxySG does partial and
complete object caching (VOD only).
In the context of the ProxySG appliance, there are two types of streaming media content:

Live Stream: A live stream is a stream of media content that is occurring live. This can include
speeches, sporting event, or concerts. This streams are watched in real time, as they are
happening. Since the live stream happens in real time, it is not cache on the ProxySG
appliance.

Video-on-demand: This type of streaming media content can be accessed at anytime.


Additionally, it can paused, rewound, and fast-forwarded at the control of the viewer. Since
this streaming media content is stored on a media server, it can be cached on the ProxySG
appliance.

The ProxySG appliances ability to cache streaming media content can be used to optimize
bandwidth usage when requesting video and audio materials. With caching, the client potentially
never has to connect to the OCS to access the requested material.

Content pre-population: The ProxySG appliance can be pre-populated with data from an OCS.
This makes it possible for administrators to use server side traffic during off-peak hours,
leaving it available for traffic during business hours.

Authentication: If content that has been cache on the ProxySG appliance, but required
authentication on its OCS, will also require authentication if it is coming from the ProxySG
appliance.

Partial and complete caching: Content can be cached completely or partially on the ProxySG
appliance. Completely cached content makes it possible for the client to access the content
they want without ever having to connect to the OCS. When accessing partially cached
content, the client will receive the cached data from the ProxySG appliance and whatever data
is missing will come from the OCS.

Instructor Edition 261

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Processing Streaming Content

6OLGH3URFHVVLQJ6WUHDPLQJ&RQWHQW

Instructors Note: Use this slide to discuss in details the differences between a live stream
and an VOD. In Slide 17-2, the two users on the bottom are watching the live stream. Since
live streams start and end at the same times for all users, ProxySG can take advantage of
multicasting and download the stream from the source once and then split it internally on the
LAN, with considerable bandwidth saving. You can show the multicasting settings from the
Management Console > Configuration > Proxy Settings > Streaming Proxies.

The two users on the top of the slide are watching VOD; since it is practically impossible that
both users start the stream at the same time, multicasting would not help; however, the
ProxySG still downloads the information only once and then delivers it to all users via unicast.
Again, this behavior results in significant bandwidth savings on the external link and much
improved performances for the users (content served locally).

The ProxySG appliance supports two methods for delivering streaming media: unicast and
multicast. The following describes the behavior of the connections for live and video-on-demand
unicast connections:

Live: A ProxySG appliance can serve many clients through one unicast connection by
receiving the content from the origin server and then splitting that stream to the clients that
request it.This method saves server-side bandwidth and reduces the server load. You cannot
pause or rewind live broadcasts. A live broadcast can be of prerecorded content. A common
example is a company president making a speech to all employees.

Video-on-Demand: An SG appliance can store frequently requested data and distribute it


upon client requests. Because the SG appliance is closer to the client than the origin server, the
data is served locally, which saves firewall bandwidth and increases quality of service by
reducing pauses or buffering during playback. The SG appliance provides higher quality
streams (also dependent on the client connection rate) than the origin server because of its
closer proximity to the end user. VOD content can be paused, rewound, and played back.
Common examples include training videos or news broadcasts.

The ProxySG appliance can take a unicast stream from the OCS and deliver it as a multicast
broadcast. The ProxySG appliance takes a one-to-one connection and splits it into a one-to-many
stream. This allows for saved bandwidth on the server side.

262 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 17: Managing Streaming Media

The ProxySG appliance can support a multitude of multicasting forms such as


multicast-to-unicast, unicast-to-multicast (shown above), and multicast-to-multicast.

Instructor Edition 263

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Large Scale Streaming Delivery

6OLGH/DUJH6FDOH6WUHDPLQJ'HOLYHU\

Instructors Note: This slide shows how you can utilize the many streaming feature offered
by ProxySG not just on a single network but also on your entire WAN. In this case all the 8
different users in the 3 different networks are watching file from the streaming server. These
can be VOD or live streams. Regardless of the type of stream, there are only two unicast
streams leaving the network to the left of the slide; one per each LAN on the right side of the
slide.
Question: How many unicast streams will you have in case of VOD across the WAN, without
the two ProxySG on the right hand side of the slide?
Answer: Six streams.

The slide above is showing how the ProxySG appliance can be used to successfully distribute
streaming media content over a WAN while saving bandwidth.

In this deployment, thanks to the use of ProxySG appliances, there only needs to be one
connections to the origin Media Server. The first ProxySG appliance is able to take the streaming
date from the Media Server and redistribute it as is necessary. The two clients at the connected to
the first ProxySG appliance can access the data through it, instead of directly connecting to the
Media Server.

The two remote locations can also access the streaming media content from the Media Server
through their own ProxySG appliances. The first ProxySG appliance has established a multicast
connection with the ProxySG appliances; it took the single connection from the Media Server and
established two with the other ProxySG appliances. From there, each ProxySG appliance can
stream the content to their individual networks.

264 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 17: Managing Streaming Media

Limiting Bandwidth

6OLGH/LPLWLQJ%DQGZLGWK

Instructors Note: )ProxySG allows you to control the maximum amount of bandwidth utilized
by streaming media using two techniques: Admission control and bandwidth management.
Even if you have not yet discussed the latter in the course (or you will not), simple mention that
in bandwidth management, the amount of bandwidth assigned to MMS is fixed but any user
can join the pool.
More users join the pool, less bandwidth each user has. Since MMS is very sensitive to time
delays, after a certain threshold of users, the stream will degrade to a point where users
cannot see or hear (or both) much Admission control limits both the maximum amount of
bandwidth used by the MMS protocols but also does not allow new users to join once the limit
is reached. Admission control is designed to limit the bandwidth consumed by MMS traffic,
without jeopardizing the performane for the already connected users. .

The ProxySG appliance is able to control the amount of bandwidth on both the server side and
client side. This should be used to limit the amount of bandwidth can be used up when video or
audio content is being streamed. With proper configuration methods, this will enable you to
reduce the amount of bandwidth used for streaming media, leaving it available for other, perhaps
more important, business uses.
Streaming media bandwidth limitations are achieved by configuring the ProxySG appliance to
restrict the total number of bits per second the appliance receives from the origin media servers
and delivers to clients. The configuration options are flexible to allow you to configure streaming
bandwidth limits for the ProxySG appliance, as well as for each streaming media player
(Windows Media, RealPlayer, QuickTime).
Note:

Bandwidth claimed by HTTP, non-streaming protocols, and network infrastructure is


not constrained by this limit. Transient bursts that occur on the network can exceed
the hard limits established by the bandwidth limit options.

After it has been configured, the ProxySG appliance limits streaming access to the specified
limitations. If a client tries to make a request after a limit has been reached, the client receives an
error message.

Instructor Edition 265

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Note:

If a maximum bandwidth limitation has been specified for the ProxySG appliance, the
following behavior can occur. If a Real Media client, followed by a Windows Media
client, requests streams through the same ProxySG appliance and total bandwidth
exceeds the maximum allowance, the Real Media client enters the rebuffering state.
The Windows Media client continues to stream.

266 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 17: Managing Streaming Media

Caching

6OLGH&DFKLQJ

Instructors Note: This is a relatively simple slide. It points out two main concepts: 1.
ProxySG can partially cache VOD files 2. ProxySG cannot cache live streams (which would
make no sense by definition of live stream) Client A requests a fully cached VOD file; this file is
served from the proxy without any significant traffic exchanged with the streaming server.
Client B requests a partially cached VOD file; while the ProxySG serves the part of the file
available in cache, it retrieves, caches, and delivers to the client B the remaining part of the
file.

The ProxySG appliance also has the ability to cache streaming media. This allows for easy access
to streaming media data without having to connect to the OCS. However, it is not possible to
cache data from a live streams.

Once video-on-demand data has been cached on the ProxySG appliance, the clients no longer
have to connect to the OCS to access the data. The video is now stored on the ProxySG appliance
and bandwidth is saved on the server side, since there is no traffic. In the example above, Client A
is requesting streaming data that has been cached on the ProxySG appliance. Since the data was
cached, there is no need to connect to the OCS.

Additionally, the ProxySG appliance can have partially cached video-on-demand. In this instance,
the client will connect to the ProxySG appliance and begin streaming the data from there. Once the
client reached the point where partial data ends, the client will begin to receive data from the OCS;
the stream will continue as though the data was not cached. Bandwidth is reduced here, since the
client does not have to connect to the OCS to stream the entire video file. Unlike Client A, Client B
has requested data that has only been partially cached on the ProxySG appliance. Note that Client
B only has to connect to the ProxySG appliance to retrieve the cached data, but then has to connect
to the OCS to receive the rest of the file.
Clients C and D are requesting live streaming media, therefore, they must connect to the OCS
since the ProxySG appliance cannot cache live data.

Instructor Edition 267

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Cache Content Pre-population

6OLGH&DFKH&RQWHQW3UHSRSXODWLRQ

Instructors Note: Not all VOD is created equal. Some server will always stream the file to the
end user not allowing a download and then play. Others, like the ones served over HTTP,
allow the user to download the file and then play it. While ProxySG can be configured to
pre-populate the cache, the time it takes to download an object depends on how the server
delivers the object. It can be either download time or video play time. You can discuss here the
content commands:

# show content url {url}


to verify the status on an URL in the object store

#(config) content distribute {url}


to pre-fetch a URL and load it in the object store.

The ProxySG appliance can be pre-populated with streaming media content. This allows the
administrator to make the content immediately available. This can be done at anytime, but if done
during off-peak hours, the bandwidth can be reserved for regular business activities.

In the example above, the ProxySG appliance is pre-populating is cache from an HTTP server and
a streaming media server. If the administrator decides to populate the cache from the HTTP server,
the time it takes to populate the ProxySG appliances cache is equivalent to the time it would take
to download the file from the OCS. However, if the administrator is populating the ProxySG
appliance by streaming the video from a media server, the population time will be the same as it
would be to watch the video.
By taking advantage of pre-population, administrators can reduce the amount of overall
bandwidth usage. Clients will no longer need to connect to the OCS to retrieve videos that are
already on the ProxySG appliance.

268 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 17: Managing Streaming Media

Authentication

6OLGH$XWKHQWLFDWLRQ

Instructors Note: This is a relatively simple slide; do not spend too much time on it. Simply
re-iterate that the ProxySG is a very secure appliance and content which requires
authentication on the OCS, even if cached locally, is not served unless the user has
authenticated in the OCS. This is applicable to both fully and partially cached VOD files.

As is true with many other types of secure data, it is often desirable to require authentication for
protection purposes. Often, streaming media content requires authentication because it is only to
be used by certain individuals.
The ProxySG appliance can use its ability to cache streaming media content in conjunction with
authentication. As previously stated, the ProxySG appliance can cache streaming media content.
However, some of this data that is being cached might have required authentication when a
request was sent to the OCS. In order to maintain that security, the ProxySG appliance is able to
require authentication for cached streaming media content.

When a client attempts to access secure streaming media content that has been cached on the
ProxySG appliance, the client will be prompted with a request to authenticate. For example, in the
slide above, the client has requested access to streaming media content that has been cached on the
ProxySG appliance. However, the streaming media content on that Media Server is authenticated.
Therefore, in order to maintain security for that data, even after it has been cached, the client will
be asked to authenticate before the streaming media content can be accessed. Authentication rules
can be applied to fully cached content and partially cached content.

Instructor Edition 269

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Streaming Handoff

6OLGH6WUHDPLQJ+DQGRII

Instructors Note: This is an important slide as you cannot discuss the concept of protocol
hand-off enough times. ProxySG can process MMS traffic in three ways:
1. Native MMS
2. MMS over HTTP. Point out that is not native MMS over port 80 but MMS protocol wrapped
in proper HTTP protocol
3. MMS over SOCKS. Point out that is not native MMS over port 1080 but MMS protocol
wrapped in proper SOCKS protocol ProxySG has three specific protocol workers to handle
MMS, HTTP, and SOCKS.
The MMS worker has specific features and functionalities to manage the streaming traffic as
you have discussed so far. When you have hand-off enabled, the MMS traffic over HTTP or
over SOCKS is first processed by either the HTTP or SOCKS worker, unwrapped, and then
presented to the MMS worker who apply the full set of features. Protocol hand-off requires a
valid MMS license (available free of charge)
Important: The slide should read SOCKS worker over the SOCKS service and NOT HTTP
worker.

Streaming handoff is a process that allows the ProxySG appliance to appropriately MMS traffic, no
matter what protocol the content is being delivered by. For example, in the slide above, there is
streaming media traffic coming over port 1755, the native MMS protocol, therefore no handoff is
required.

However, in common deployments, port 80 is the only port allowing traffic through the firewall.
Unfortunately, the HTTP worker does not know how to handle the MMS data; it is unable to do
any splitting or object caching. In order for appropriate caching, splitting, and application of
policy, protocol handoff is triggered and the HTTP worker give the MMS data to the MMS worker.
Note that the MMS data being sent over SOCKS is also able to participate in streaming handoff;
this action is not limited to traffic sent with HTTP protocol.

270 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 17: Managing Streaming Media

Instructors Notes for Managing Streaming Media Lab


Overview

In this lab, you configure ProxySG appliance to intercept streaming media traffic. You will cap the
maximum gateway bandwidth for the streaming media traffic and then verify the configuration
from the Statistics tab.

Computer Hardware and Software Requirements


Table 17-1: Requirements for the Instructor
Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Table 17-1: Requirements for Students


Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Instructor Edition 271

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

272 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 18:Forwarding

Estimated Lesson Time: 25 minutes

Instructors Note: This chapter describes what forwarding is, how it can be used to achieve
practical benefits, and how students can create viable forwarding directives. In particular, you
need to discuss how to use forwarding for proxy chaining and for reverse proxy.
The key concept in forwarding is that the ProxySG simply changes the destination IP address
in the request it receives.
The main use of forwarding should be proxy chaining; you should suggest using two-way URL
(TWURL) rewrite when implementing reverse proxy. Introduce the idea that TWURL rewrite is
more robust as it modifies all parameters of the transaction and not just the destination IP
address.
Discuss the load balancing options available for forwarding in detail. In particular, host-affinity,
as it may be necessary to use this feature in certain circumstances (try to have some customer
examples ready.)
Toward the end of the chapter you should ask your students at which checkpoint (CI, SO, SI,
CO) do you think forwarding rules are processed?. The correct answer is SO; the ProxySG
needs to know the IP address it has to contact before it connects to the OCS

Forwarding is the ability to send Web requests to other appliances before sending the request to an
origin server. Forwarding allows you to define the host and groups of hosts to which client
requests can be redirected (also known as a proxy hierarchy). Those hosts can be servers or proxies,
including additional Blue Coat SG appliances. The combination of forwarding and the
ProxySG policy engine allows extremely flexible configuration and traffic management.
Forwarding can be summarized as follows: It is a method for sending requests (for the supported
protocols) to a destination other than the IP address specified in the request. You can use
forwarding to organize how Web traffic flows around the network (proxy chaining), or you can
use forwarding to create a basic reverse-proxy scenario.
When you configure forwarding, you can define some load-balancing options. You can also
determine how the ProxySG should act in case the upstream host is unavailable. When you create
a forwarding rule, the ProxySG automatically configures health checks to the upstream host; if the
host fails the health check, the ProxySG drops the request and returns an error to the user. This
behavior is called fail closed and it is the default behavior.

You can modify the default behavior to send the request to the original OCS, ignoring the
forwarding rule. This behavior is called fail open. For instance, if you forward all traffic from the
London ProxySG to the Amsterdam ProxySG in a fail closed configuration, the London users
cannot access the Internet when the Amsterdam ProxySG is unavailable. Conversely, in a fail open
scenario, the London users are able to access the Internet directly (assuming the London location
has Internet access) when the Amsterdam ProxySG in unavailable. In a proxy chaining scenario,
fail open forwarding is probably a better option because failures do not limit Internet access. In a
reverse proxy scenario, fail closed is almost a requirement because there is not much else the proxy
can do when the upstream OCS is not available.

You can forward requests to an individual host or to a group of hosts. You can define which OCS or
proxies are members of which group. Groups allow you to create a load-balancing environment
using only ProxySG appliances. However, you can manage load balancing in several ways:
When you forward requests to a specific host and that host DNS-resolves to multiple IP addresses,
then one of the available load-balancing methods (round-robin, least connections, or none) is
applied to those IP addresses. When you forward to a group, you can load balance using a hash.
When a hash is not used, all the IP addresses of the group are gathered together and the group's
method is applied across the entire set of IP addresses. When a hash is used, you can apply the

Instructor Edition 273

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

hash to the domain name or the full URL. This hash value is used to select one member of the
group. The selected host is treated just as an individual host is treated; the only difference is that
the load-balancing method configured for the group is used for the selected host. Hashing
guarantees that when the ProxySG forwards a request for a host or URL that was previously
requested, that request will go to the same host or proxy that received it before.

Similarly to hashing, you can use host affinity to send a request from the same source to the same
destination. While hashing is based on the destination specified in the request, host affinity is the
attempt to direct multiple connections by a single user to the same group member. Take, for
example, a Web site that uses shopping carts to allow customers to purchase items. The site might
load balance requests across a group of Web servers working in parallel, but only one server in the
group maintains state for a single user. If the user connections are sent to a different server, that
server has no previous state for the user and might start over. Host affinity forces the users
connections to return to the same server until the user is idle for a configurable period of time.
After a configurable period of inactivity, the host affinity times out and users state is lost.

274 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 18: Forwarding

Forwarding Proxy Chaining

6OLGH7\SLFDOIRUZDUGLQJVFHQDULR

Instructors Note: This slide is important because it illustrates the basic concepts of
forwarding. You should emphasize the reasons why forwarding is used because this is not
clear from looking at the slide. Be prepared to describe a typical deployment and why it is
configured the way it is.

Forwarding is sending traffic to a destination other than that specified by DNS resolution. Traffic
is sent upstream to another proxy, as shown in Slide 18-1. Forwarding is often used in proxy
hierarchies in which lower-level proxies must use another proxy for Internet access. Forwarding
can also be used for load-balancing, caching optimization, or redundancy.

Slide 18-1 illustrates a typical forwarding scenario, in which a local ProxySG receives a request
and forwards it to a second ProxySG for content retrieval (or authentication, etc.). The ProxySG
that receives the forwarded request then delivers the requested content from its cache or retrieves
it from the OCS. A forwarding structure like this often results in fewer trips to the origin server
because of the likelihood that the requested content resides in one of the upstream caches.

Instructor Edition 275

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Forwarding Reverse Proxy

6OLGH%DVLFUHYHUVHSUR[\

Instructors Note: This slide shows a very basic reverse-proxy deployment. You should have
already mentioned to your students that this is a very basic reverse proxy deployment, as
TWURL may be necessary in many situations. Nonetheless, this is a good example that
shows how to use forwarding.
Ask why a split DNS is not an option and discuss the answers (think of when there is not host
header in the clients request)

In the deployment shown in Slide 18-2, the ProxySG receives all requests for a specific Web server.
It is common to deploy ProxySG in front of the server to protect your production Web server and
increase performance.

The DNS server resolves the host name of the OCS to the IP address of the ProxySG; when the
proxy receives the clients request, it needs to know where the request should go. While you could
use split DNS (the proxy uses a different DNS than the Internet), this would not allow the
ProxySG to handle client requests that do not have a host header. Forwarding is, in general, a
better solution.
Alternatively, you can use forwarding to send a request, destined for a specific host, to another
host. For example, if your organization has a domain name that is similar to other domain names,
you can forward those requests to the proper domain. The domain www.bluecoat.com is owned
by Blue Coat Systems, for example, but the domain www.bluecoat.nl is not.
To make sure that users see your content, you can create forwarding rules to forward all requests
for www.bluecoat.nl to www.bluecoat.com. In fact, you will do exactly that in the accompanying
lab.

276 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 18: Forwarding

Forwarding Host Types

6OLGH)RUZDUGLQJKRVWUHTXHVWW\SHV

Instructors Note: Because you have already covered this concept when you discussed
explicit proxying, students should already understand why the host type is important. Even so,
you should not skip this slide.

The request style determines the format of the HTTP request forwarded to the upstream device.
You must indicate whether the forwarded host is a server or a proxy because this configures the
ProxySG to format the request correctly. The server variable specifies that the relative path for
URLs should be used in the HTTP header because the next hop is a Web server, and not a proxy
server.
If there is an intervening proxy, the proxy-style request must used. The proxy-style request
includes the entire URL for the same reasons that a browser sends the entire URL to an explicit
proxy. The default request type is proxy-style.

Instructor Edition 277

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Forwarding Options

6OLGH)RUZDUGLQJKRVWGHILQLWLRQ

Instructors Note: This slide is important because the analogy enables students to easily
grasp the required components for a forwarding host definition. You should also make sure
that students understand what directives are and how they are used to create forwarding
configurations.

The forwarding configuration includes directives that create the forwarding hosts and groups and
provide for load balancing and host affinity. Directives are commands that can be used in
installable lists to configure forwarding. Forwarding can be configured through the CLI or by
adding directives to a text file and installing it as an installable list.
When you add forwarding directives to an installable list, you can create and delete the
forwarding host and associate protocols and ports with the host. You can create a maximum of 32
groups, and each group can contain a maximum of 512 hosts. You can create 512 individual hosts
that do not belong to any group.
The options that you must use to create a forwarding host are:

An alias provides a name for this host when referenced in policy (Who): Alias names can be
any text string that makes sense to you. However, the name must not include a space or
special characters.

IP address or Hostname of the host (Where): If a hostname is used instead of an IP address, it


is re-resolved periodically. The DNS re-resolve is needed because the DNS may be in a load
balancing or failover environment.

Supported protocols (What)

Type of host (How)

By default, no protocol is selected if the forwarding host is a server. Protocols are entered using
protocol=tcp_port syntax. You must choose at least one protocol (the port number range is
from 0 to 65535). If only one protocol is configured, the ProxySG configures the default port for
that protocol. You can configure forwarding for HTTP, HTTPS, FTP, MMS, RTSP, and TCP.
Note:

HTTPS protocols are not allowed if the host is a proxy.

278 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 18: Forwarding

The term default-schemes is used to indicate that the forwarding host supports the same
protocol/port pairs as the proxy. If you use default-schemes in the directive, all protocols, along
with their default ports are selected. This directive is only available for proxy hosts.

You can also use default-schemes and then eliminate protocols by editing the protocol you do not
want; for example, http=no. If you do not want to use the default ports for the protocols, you
must also specify them.

The host definition type specifies whether the forwarding host is a server or proxy. As you will see
in the next slide, this distinction is very important because it determines the format of the
forwarded request.
The group-name option is used for forwarding to multiple hosts. You define this configuration
by creating several forwarding hosts and assigning the same group name. The group name can
then be used as a policy alias so that requests are forwarded to the group, rather than to an
individual host.

SSL certificate verification ([ssl-verify-server[=yes|no]]) is similar to the browser


pop-up window that indicates that a certificate is not trusted. This option configures the ProxySG
to validate device certification before using the certificate to create the connection. In other words,
the ProxySG checks to ensure the certificate is signed by a trusted source. If the certificate cannot
be verified, nothing is forwarded. This option can be used to prevent man-in-the-middle attacks
inside the network.

Instructor Edition 279

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Forwarding Host Options


Load-balancing method

[load-balance=no|round-robin|least-connections]

Load-balancing host-affinity

[host-affinity=no|client-ip-address|accelerator-cookie]
[host-affinity-ssl=no|client-ip-address|acceleratorcookie|ssl-session-id]

6OLGH/RDGEDODQFLQJSURSHUWLHV

Instructors Note: While you do not need to spend a lot of time on this slide, you should
ensure that students understand the various types of load-balancing and how they are used.
Host affinity can be confusing so it is helpful to be ready with an example.

Load balancing is a way to split traffic requests among multiple upstream systems or among
multiple IP addresses on a single host. You can configure load balancing using the following
methods:

For individual hosts If a host is DNS-resolved to multiple IP addresses, then that host's
load-balancing method (round-robin, least connections, or none) is applied to those IP
addresses.

For groups, two load balancing choices are available:

Q Apply a load-balancing method to a group. All the IP addresses of all group members are

gathered together, and the group's method is applied across that entire set of IP addresses.

Q Use a hash. If you use a hash for load balancing, you can choose to hash the domain or the
full URL.

If you use a group name, you must configure load balancing (using the load-balancing directive).
The no load-balancing option splits the name space. In other words, Yahoo! will always go to one
host and the Google search engine will always go to another. The round-robin method alternates
which forwarding host is used. The least-connections option monitors the sessions sent to
each proxy and determines how long-lived the session is to identify the next forwarding host.
The host-affinity directive enables you to configure forwarding so that all requests from a specific
client are sent to a specific proxy. Host affinity is closely tied to load balancing behavior; both
should be configured if load balancing is important.
The client-ip-address option forces all requests from the specified IP address to be
forwarded to the same host for the duration of the session.

280 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 18: Forwarding

Forwarding Health Checks

6OLGH)RUZDUGLQJKHDOWKFKHFNSURSHUWLHV

Instructors Note: Many students are probably already familiar with health checks (or
heartbeats as they are sometimes called). After ensuring that students understand what a
health check is, discuss the specifics of the Blue Coat implementation. Its important to note
that administrators do not have to configure health checks; they are automatically created.

The ProxySG can perform health checks on a forwarding host or external server that is providing a
service. The supported server types are HTTP, HTTPS, ICAP, Websense (off-box), SOCKS
gateways, and Layer 3 and Layer 4 forwarding hosts.
Based on the health check type, the ProxySG periodically verifies the health status, and thus the
availability, of the host. When the ProxySG performs a health check on one or more hosts, it
determines whether the host is up and available to fill a content request. A positive health check
indicates a functional end-to-end connection and that the host is healthy and able to return a
response. The time interval between checks is configurable.

If the initial health check is unsuccessful, the ProxySG retries, using the number of attempts set in
the health check failure count.

When there are multiple forwarding hosts, health checks are vital to ProxySG efficiency. The
ProxySG forwards requests to healthy hosts and not to unavailable hosts, resulting in faster
content fill requests. With a single forwarding host, health checking is also important to determine
whether the host is available.
Note:

When a forwarding host or SOCKS gateway is created, it is automatically registered


for health checks. Similarly, when a forwarding host or SOCKS gateway is deleted, it
is removed from the health check registry.

Instructors Note: Discuss the differences between the health-check actions and why you
might want to configure one type over another.

When configuring the forwarding health check, you can select from the following types of checks:

Instructor Edition 281

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

HTTP

HTTPS

Layer 3 (ICMP)

Layer 4 (TCP connection)

You can view a list of health check statistics by accessing the following URL:
https://<ProxySG_IP:8082/HC/Statistics>

282 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 18: Forwarding

Instructors Notes for Creating a Forwarding Rule Lab


Overview

The site www.bluecoat.nl is a registered Web site but is not the property of Blue Coat Systems1. You
want to create a policy to show the actual content of www.google.com when users attempt to
access www.bluecoat.nl.
You can achieve this goal by creating either a forwarding rule or a redirect rule. This lab shows
both solutions.

Computer Hardware and Software Requirements


Table 18-1: Requirements for the Instructor
Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Table 18-1: Requirements for Students


Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

1. This information is correct and accurate at the time this lab is written.

Instructor Edition 283

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

284 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 19: Reverse Proxy Implementation

Estimated Lesson Time: 30 minutes

Instructors Note: This chapter builds upon the reverse proxy concepts that students learned
previously. You should review the benefits of a reverse proxy and then provide students with
the configuration best practices outlined in the following pages. While the information is not
technically challenging, it is important that your students gain an understanding of the
information.

As you learned earlier, a reverse proxy is a proxy that acts as a front end to one or more Web
servers, typically to improve performance. Clients use the reverse proxy to access the back-end
Web servers.
Reverse proxying with the Blue Coat SG provides the following advantages:

The ProxySG terminates the session with the client (even for SSL connections) and establishes
another session with the Web server, thereby off-loading this process from the Web server.

The Web server sees only the IP address of the ProxySG.

Granular policies with authentication, authorization and logging can be implemented.

The ProxySG has built-in DOS (Denial of Service), protecting the Web servers from these types
of attacks.

The server identity can be hidden by the ProxySG.

Increased performance with caching provides an improved Web experience.

The ProxySGs flexible advanced-forwarding architecture, coupled with caching, provides


organizations a best-of-breed solution to leverage their network infrastructure.
Note:

To fully implement a production reverse proxy deployment, you must configure the
two-way URL rewrite (TWURL) feature. For more information, see the TWURL
chapter in this book.

Instructor Edition 285

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Reverse Proxy Deployments

6OLGH7\SHVRIUHYHUVHSUR[\GHSOR\PHQWV

Instructors Note: This slide shows the two basic ways that a reverse proxy can be deployed.
You can have the clients connect directly to the ProxySG or you can place the proxy in the
DMZ. You should also discuss the option in which the traffic in the DMZ is routed to the
ProxySG using a Layer 4 switch. The client can resolve the host name of the server to three
possible IP address: the external IP address of the proxy (bottom diagram), the external IP
address of the firewall mapped to the IP address of the proxy in the DMZ (top diagram), or the
external IP address of the firewall mapped to the IP address of the Web server (top diagram,
where the Layer 2 switch is substituted with a Layer 4 switch).

You can place your ProxySG, for reverse proxy, in several places on the network. One option is not
necessarily better than the other: You need to evaluate which solution makes you most
comfortable and achieves the best balance between performance and security.

The top diagram in the slide shows a deployment in which the ProxySG is in the DMZ. The host
name of your Web server resolves to an IP address, which the firewall then maps to the actual IP
address of the ProxySG. All traffic goes from the clients on the Internet to the ProxySG through the
firewall.

You can easily modify this configuration and replace the Layer 2 switch, shown in the top
diagram, with a Layer 4 switch. In this scenario, the host name of your Web server resolves to an
IP address, which the firewall then maps to the actual IP address of your Web server in the DMZ.
The Layer 4 switch transparently redirects then traffic destined to the Web server to the ProxySG.
This is a fairly common scenario; the Layer 4 switch allows you to easily load-balance multiple
ProxySG appliances and multiple Web servers. No DNS or firewall configuration is required if you
have the Web server in place before you install the ProxySG.
The bottom diagram shows a configuration in which the ProxySG has two interfaces, one directly
on the Internet. A routable, public IP address is assigned to that interface. The host name of your
Web server resolves to the IP address for the external interface of the ProxySG. The internal
interface is connected to the DMZ, where the actual Web server is located. Implementing this
configuration requires you to make DNS changes; however, it allows you to off-load all the traffic
to your Web server from the firewall.

286 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 19: Reverse Proxy Implementation

Forwarding for Reverse Proxy

Allow the proxy to services requests for


front-ended Web servers

Forwarding hosts must be defined as server


style
Protocol support must be specific (defaultschemes not allowed)

Protocol conversions (HTTPS<-->HTTP) are


automatic

6OLGH5HYHUVHSUR[\FRQVLGHUDWLRQV

Instructors Note: Spend some time explaining each of the points in the slide. It is important
that students understand why these configurations are recommended.

The purpose of the reverse proxy is to service requests for back-end Web servers. To redirect
requests to the reverse proxy, you must either set up DNS so that the world believes that the IP
address of the proxy is actually that of the Web server, or you must implement some type of Layer
4 or WCCP redirection. While explicit proxying is the less-expensive solution, many companies
choose to implement a device-oriented redirection scheme.
To relay requests from the proxy to the correct Web server, you must set up advanced forwarding
rules. When creating forwarding rules for reverse proxies, consider the following:

The forwarding hosts must be defined as server. The server variable specifies that the
relative path for URLs should be used in the HTTP header because the next hop is a Web
server, not a proxy server.

The default-schemes variable is not allowed for Web servers so you must explicitly specify
the supported protocols and ports.

SSL transactions are performed only between the client and the ProxySG. The ProxySG then
communicates with the back-end server over HTTP.

Instructor Edition 287

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Forwarding for Reverse Proxy

6OLGH)RUZDUGLQJUXOHVDQGH[SOLFLWUHYHUVHSUR[\LQJ

Instructors Note: This slide illustrates the typical explicit reverse proxy request flow. The
important concept here is that all requests contain the proxy IP address. Therefore, the proxy
must have a way to determine where to forward the request. This is where forwarding rules
come in.

Slide 19-3 shows a client requesting content from an explicit reverse proxy that is accelerating the
Web server www.site.com. When the client does a DNS lookup for www.site.com, the DNS server
returns the proxy IP address.
However, when the proxy receives a GET request with its own IP address, it must know where to
forward the request. This is why you must create a forwarding rule to forward the request to the
back-end server.

288 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 19: Reverse Proxy Implementation

Forwarding for Reverse Proxy

6OLGH7UDIILFIORZDQGEDQGZLGWKPDQDJHPHQW

Instructors Note: This slide illustrates the typical SSL reverse proxy request flow. Stress the
benefits of performing SSL only between the client and the proxy. Because the server
communicates only with the proxy, the proxy uses standard HTTP.

To help alleviate the strain SSL places on general-purpose Web servers, ProxySG appliances have
integrated full SSL capabilities. Blue Coat has specifically designed the ProxySG to accelerate and
scale high traffic Web sites. By adding SSL processing, the ProxySG appliances offload the origin
server from the delivery of secure objects and the managing and processing of SSL sessions.

Slide 19-4 shows a client sending an HTTPS request to a reverse proxy that is accelerating the Web
server www.site.com. Note that the SSL transaction occurs only between the client and the proxy.
The proxy terminates the HTTPS request, performs the key exchange (public key and master key),
and then sends the request to the back-end server.

Blue Coat secure proxy appliances can triple a Web sites throughput and cut user response times
by 5080 percent. This allows a Web site to serve more content and process more transactions
through the existing server infrastructure. The ProxySG appliances can negotiate 1040 times
more new SSL connections than a standard Web server; supporting up to 800 new SSL sessions per
second, and up to 11,000 maximum existing connections. The Blue Coat appliances support
processing both HTTP (public) content and HTTPS (encrypted) content.
ProxySG appliances ship with validation certificates from all major Certificate Authorities (CAs),
which validate the origin server certificates. Customers can then add their own certificates for
each original domain. Blue Coat appliances support all major CAs for origin server certificates.

Instructor Edition 289

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Reverse-Proxy Policy
Default policy of DENY

ALLOW only recognized hostnames

Modify caching if proxy behavior should vary


from client behavior
VPM = Web Content Layer

6OLGH(QVXULQJWKDWDSUR[\LVQRWRSHQ

Instructors Note: This slide is very important. Do not skip it. If students incorrectly configure
their proxies, they might deploy open proxies. Stress the dangers of open proxies and
describe the configuration recommendations for blocking access to all but trusted clients and
hosts.

An open proxy is a proxy server that has not been configured to disallow connections from
unfamiliar clients. In other words, the proxy accepts requests from any IP address and will
connect to any resource on behalf of those clients. Open proxies are often blacklisted; once a proxy
has been blacklisted, it is very difficult to get it removed from the list of untrustworthy sites.
To avoid having an open proxy, you should do the following:

Set a default policy of DENY. This means that you must create rules to explicitly allow clients
to connect to the proxy.

Allow only recognized hostnames. Allow connections only to the Web sites and paths that you
know to be valid.

Modify the proxy caching behavior such that the proxy overrides some client requests.
Because you control the Web server content, you can safely ignore client requests for fresh
content (forced reload) and serve the content from the cache (when fresh).

290 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 19: Reverse Proxy Implementation

Reverse-Proxy Policy

Forwarding policy should match for all permitted


requests
Set HTTP proxy behavior profile to portal
Ignores browser forced reload attempts
Trust server expiration headers

6OLGH)RUZDUGLQJSROLF\IRUUHYHUVHSUR[\

Instructors Note: This slide presents final configuration recommendations for deploying a
reverse proxy. You might want to spend some time elaborating on the portal proxy profile so
that students are not concerned that they are violating standard HTTP behavior.

When setting up forwarding policies, ensure that they are valid that is, permitted requests
should initiate the same correct action.

It is also a good idea to set the HTTP proxy profile to portal. Setting the profile to portal causes
the proxy to ignore client-forced reload attempts and to trust server expiration headers. Because
you own the Web server in this case, you know when content is fresh and can trust the validity of
the server expiration headers. When you set the profile to portal, the proxy is configured to:

Substitute GET for IMS (if modified since)

If the time specified by the If-Modified-Since: header in the clients conditional request
is greater than the last modified time of the object in the cache, it is a strong indication that the
copy in the cache is stale. If so, HTTP proxy does a conditional GET to the OCS, based on the
last modified time of the cached object.

Substitute GET for PNC (Pragma no cache)

Typically, if a client sends an HTTP GET request with a Pragma: no-cache or


Cache-Control: no-cache header (for convenience, both are hereby referred to as PNC), a
cache must consult the OCS before serving the content. This means that HTTP proxy always
re-fetches the entire object from the OCS, even if the cached copy of the object is fresh. Because
of this, PNC requests can degrade proxy performance and increase server-side bandwidth
utilization. However, if the Substitute Get for PNC setting is enabled, then the PNC header
from the client request is ignored (HTTP proxy treats the request as if the PNC header is not
present at all).

Substitute GET for HTTP 1.1 Conditionals

If the Substitute Get for HTTP 1.1 Conditionals setting is enabled, HTTP proxy ignores the
following Cache-Control: conditions from the client request:

Instructor Edition 291

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Q
Q
Q
Q
Q

"max-stale" [ "=" delta-seconds ]


"max-age" "=" delta-seconds

"min-fresh" "=" delta-seconds


"must-revalidate"

"proxy-revalidate"

Substitute GET for IE (Internet Explorer)

Some versions of Internet Explorer issue the Accept: */* header instead of the Pragma:
no-cache header when you click Refresh. When an Accept header has only the */* value,
HTTP proxy treats it as a PNC header if it is a type-N object. You can control this behavior of
HTTP proxy with the Substitute GET for IE Reload setting. When this setting is enabled, the
HTTP proxy ignores the PNC interpretation of the Accept: */* header.

Never refresh before expiration

Applies only to cached type-T objects.1 When this setting is enabled, the ProxySG does not
asynchronously revalidate such objects before their specified expiration time. When this
setting is disabled, such objects, if they have sufficient relative popularity, can be
asynchronously revalidated and can, after a sufficient number of observations of changes,
have their estimates of expiration time adjusted accordingly.

Never serve after expiration

Applies only to cached type-T objects. If this setting is enabled, an object is synchronously
revalidated before being served to a client, if the client accesses the object after its expiration
time. If this setting is disabled, the object is served to the client and, depending on its relative
popularity, might be asynchronously revalidated before it is accessed again.

1. Type-T: The OCS specifies explicit expiration time.

292 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 19: Reverse Proxy Implementation

Instructors Notes for Reverse Proxy HTTPS to HTTP Proxy Lab


Overview

You need to configure your ProxySG appliance to be the resolved host for
https://www.bluecoat.com. ProxySG appliance will handle the SSL connection with the clients
and connect to the back-end Web server over HTTP.

Computer Hardware and Software Requirements


Table 19-1: Requirements for the Instructor
Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Table 19-1: Requirements for Students


Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Instructor Edition 293

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

294 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 20: Two-Way URL Rewrite

Estimated Lesson Time: 30 minutes

Instructors Note: In this chapter, you will need to use examples to clearly explain how
TWURL functions. Make sure that the students understand that TWURL is not required. (You
should have done a lab already where reverse proxy worked properly without the TWURL.) If
you can guarantee that the Web site is well-designed in every section, TWURL is not
necessary. You should strongly advise your students to use TWURL anytime they implement a
reverse proxy solution.

In order to complete a successful implementation of a reverse proxy deployment, you need to


ensure consistency and accuracy of the links served by the Blue Coat SG to the client and
consistency and accuracy of the headers from the ProxySG to the server.

It is possible that the internal Web sever contains internal links, or that the relative paths of links
and objects do not resolve correctly. For instance, if your Web server has an internal non-routable
IP address, all of the relative links could potentially refer to that IP; if the ProxySG executes a
simple forwarding without checking the portability of the link, the user who receives the content
will not be able to follow those links.

In the slides that follow, you can see an example of a simple reverse proxy implementation. The
domain www.bluecoat.nl resolves to the IP address of a ProxySG. The ProxySG forwards the
requests for www.bluecoat.nl to www.bluecoat.com. Bear in mind that www.bluecoat.com is also
DNS resolvable.

In one slide, you can see that the links served from www.bluecoat.nl point to www.bluecoat.com;
the two-way URL rewrite (TWURL) is not implemented. When the user follows a link, the content
now comes directly from the www.bluecoat.com site and no longer from the ProxySG that is
acting as reverse proxy for www.bluecoat.nl. In the following slide you see how the links for the
content served from www.bluecoat.com point to www.bluecoat.nl. When the user follows the link,
the request goes to the ProxySG and not directly to www.bluecoat.com.
The circumstances under which two-way URL rewrite is required are unpredictable and often
impossible to foresee a priori. However, you should always use it, unless you are absolutely
confident you do not have to.
Note:

The site www.bluecoat.nl does exist; however, it is not the property of Blue Coat and
is not served by a ProxySG. The site is just used as an example in reference to the
previous lab on reverse proxy.

Instructor Edition 295

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Two-Way URL Rewrite The Problem


Forwarding rules change the destination IP
Links are not modified
Headers are not modified

Badly designed Web sites may contain:

Local references
(<img src=http://172.16.10.100/logo.gif>)

Local links
(<A HREF=http://172.16.10.100/page2.htm>)

6OLGH:K\LPSOHPHQW7:85/

Instructors Note: This slide prepares the foundation for why you need to implement TWURL.
It basically explains visually what appears in the introduction to the chapter in the student
section.

A forwarding rule alone does not modify any parameter of the clients request or any parameter of
the servers response. You can imagine that the destination IP address is changed from the DNS
resolved one to the one that you defined.
Links and headers are not changed; this can have unpredictable and often unwanted effects on
what the client receives.

296 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 20: Two-Way URL Rewrite

Two-Way URL Rewrite The Solution

The Blue Coat SG receives a request from a client


for a Web page that is inside a server portal
It rewrites the requested URL from client form to server
form
It sends the rewritten request to the server

When the server sends back a response

The Blue Coat SG rewrites URLs inside the response


from server form back to client form

6OLGH7:85/WKHVROXWLRQ

Instructors Note: This is again an introductory slide on how to fix the issues concerning
poorly written HTML code or inconsistent URL references in the content served.

The idea behind TWURL is accuracy and consistency of the content served to the client. In the
small figure below, you can see an example of how TWURL can fix poor HTML code. The client on
the left requests content from www.site.com; the site is front ended by a ProxySG. The ProxySG
modifies both the request received from the client by adapting the headers, and, in the same way,
adjusts the server responses so that the client only receives resolvable links.

Figure 20-1: How TWURL fixes poor HTML code

Instructor Edition 297

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Two-Way URL Rewrite TWURL

Need to change the host header and the possible links

6OLGH+HDGHUVPRGLILFDWLRQ

Instructors Note: Slide 20-3 and Slide 20-4 graphically illustrate the problem, which TWURL
solves. Slide 20-3 shows a pretty unrealistic situation; however, it is a first look into the issue.
Start explaining how virtual hosts work (from the standpoint of the Web server), because it
may help the student understand Slide 20-4, which follows.

In this example the ProxySG is configured to forward the requests for www.test.com to the site
www.example.com. There is no TWURL configured on the ProxySG.

You can see from the slide that the HOST header in the client request refers to www.test.com;
because there is not a TWURL policy, the host header still refers to www.test.com when it is
received by the www.example.com site. Most Web servers should safely ignore this header, unless
the server is running more than one site on the same IP address. In the case of virtual hosts (more
servers on the same IP), the host header is key in handling the Web requests and deliver the correct
content.

298 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 20: Two-Way URL Rewrite

Two-Way URL Rewrite TWURL

6OLGH7:85/ZLWKYLUWXDOKRVWV

Instructors Note: Slide 20-4 shows a more realistic situation than the one in Slide 20-3. The
host www.siteB.com resolves to the external IP address of the ProxySG; then the forwarding
rule sends the request to the internal site, whose hostname is actually internalsiteB. Point out
clearly that the default Web site associated to the IP address 172.16.90.100 is internalsiteA.
You also need to remind the students that when a Web server receives a request for a site that
does not exist, it should serve the default Web site. In this case, even if the client requests
www.siteB.com, it will receive the content from the internalsiteA, which is not what it wanted.
Additional Note: Ask the students which content the client will receive in a situation like this
(no TWURL).

The situation shown in Slide 20-4 is more realistic than the situation in Slide 20-3. A client wants to
retrieve content from www.siteB.com; this site is actually front-ended by a ProxySG. The proxy
does not have any TWURL policy. The client connects to the external IP address of the ProxySG;
the request is then forwarded to the Web server, which contains the requested data. The server has
an internal IP address and hosts two different Web sites: internalsiteA (the default one) and
internalsiteB (the one being requested in this example).
Based on the information above, what content will the client receive from the proxy (internalsiteA
or internalsiteB)? Discuss the question with the instructor. Hint: the request headers are not
modified by the ProxySG.

Instructor Edition 299

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Two-Way URL Rewrite TWURL

The forwarding rule does not include TWURL


The links in the page are inconsistent
Browser assumes content from www.bluecoat.nl
Links point to www.bluecoat.com

6OLGH)RUZDUGLQJZLWKRXW7:85/

Instructors Note: Slide 20-5 shows the content received by a client that is connecting to the
site through a reverse proxy without any TWURL policy. Point out that to the user agent, the
source appears to be www.bluecoat.nl (look in the top portion of the window); however, the
links refer to www.bluecoat.com.

In Slide 20-5 you can clearly see what happens when you apply a forwarding rule to the incoming
requests without adding a TWURL policy. Of course, you need to use TWURL only when you are
using forwarding rules for an implementation of reverse proxy.

Note that the user agent assumes that the content is coming from www.bluecoat.nl (as you can see
from the reference in the window); however, the links still point to www.bluecoat.com.

300 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 20: Two-Way URL Rewrite

Two-Way URL Rewrite TWURL

The forwarding rule includes TWURL


The links in the page are consistent

Browser assumes content from www.bluecoat.nl


Links point to www.bluecoat.nl

6OLGH)RUZDUGLQJZLWK7:85/

Instructors Note: Slide 20-6 shows the content received by a client that is connecting to the
site through a reverse proxy with TWURL policy. Point out that to the user agent, the source
appears to be www.bluecoat.nl (look in the top portion of the window); consistent with the GET
request, the links refer to www.bluecoat.nl.

In Slide 20-6 you can clearly see what happens when you apply a forwarding rule to the incoming
requests when you have a TWURL policy. Of course, you need to use TWURL only when you are
using forwarding rules for an implementation of reverse proxy.

Note that the user agent assumes that the content is coming from www.bluecoat.nl (as you can see
from the reference in the window); consistent with this assumption, the links all point to
www.bluecoat.nl.

Instructor Edition 301

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

TWURL Syntax
CPL Syntax:

<proxy>
action.action_name(yes)

define action action_name


transform transformer_id
end

define url_rewrite transformer_id


[caseless]
rewrite_url_substring "client_url_substring" "server_url_substring"
rewrite_url_prefix "client_url_substring" "server_url_substring"
end

6OLGH7:85/&3/V\QWD[

Instructors Note: Describe the syntax very quickly. You can return to this slide after you are
done with the CPL chapter. Spend no more than five minutes detailing the sequence of
commands.

The command define url_rewrite, defines rules for rewriting URLs in HTTP responses. The URLS
are either embedded in tags within HTML, CSS, JavaScript, or ASX documents, or they are
contained in HTTP response headers. In addition to rewriting URLS, you can also rewrite
arbitrary JavaScript. This transformer takes effect only if it is also invoked by a transform action in
a define action definition block, and that block is in turn called from an action( ) property.

For each URL found within an HTTP response, a url_rewrite transformer first converts the URL
into absolute form, then finds the first rewrite_url_substring or rewrite_url_prefix statement
whose server_url_substring matches the URL being considered. If such a match is found, then that
substring is replaced by the client_url_substring. Matching is always case-insensitive.
The command transform invokes an active_content, JavaScript, or URL_rewrite transformer. The
invoked transformer takes effect only if the transform action is used in a define action definition
block, and that block is in turn enabled by an action( ) property.
Note:

Note: Any transformed content is not cached, in contrast with content that has been
sent to a virus scanning server. This means the transform action can be safely
triggered based on any condition, including client identity and time of day. The
syntax is:
transform transformer_id

where transformer_id is a user-defined identifier for a transformer definition block.


This identifier is not case-sensitive.

302 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 20: Two-Way URL Rewrite

TWURL and Policy Checkpoints

6OLGH7:85/DQGFKHFNSRLQWV

Instructors Note: This slide shows where ProxySG executes each specific statement
needed to implement TWURL. You need to discuss how it is possible to determine the
checkpoints, even without inside knowledge:
- The rewrite of the request must happen before SO (when the client connects) but also before
possible cache hits to avoid serving the cached content for the original URL and not the
rewritten one; therefore rewrite URL prefix happens at CI
- The rewrite of the response must happen after SI but also after possible caching hits,
therefore can only happen at CO.
Important: ProxySG handle the execution of the required actions at the correct checkpoint
without any user intervention. Make it clear to the students that they do not have to worry
about ensure proper execution of action at specific checkpoints.
Slide 20-8 shows the code necessary to create, using TWURL, a rule that allows the clients to
request the site www.bluecoat.nl while actually receving the content from the site
www.bluecoat.com.

The diagram shows the code necessary to implement TWURL next to the checkpoint where
ProxySG exectutes the requested actions. As mentioned before there are several more checkpoint
than the one discussed in this course; the actions necessary to implement TWURL are executed on
the specified checkpoint or on checkpoint close enough to the one discussed in the slide.

You can clearly see from the slide and from the syntaxt on Slide 20-7, there are two sections in the
code: One performs the headers and content modification, the other the actual modification of the
request, so that ProxySG connects to the rewritten URL and not to the one originally requested by
the client.

Often the syntax of TWURL is confusing because you have one action which has a component that
is applied to a request and one to the response. You need to keep in mind that request and
response are two components of the same transaction, so the action is applied to the entire
transaction.
The complete code is shown below.

Instructor Edition 303

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

<Proxy>
url=http://www.bluecoat.nl/ action.portal(yes)

define url_rewrite P
rewrite_url_prefix "http://www.bluecoat.nl/" "http://www.bluecoat.com/"
end
define action portal
rewrite( url,
"http://www.bluecoat.nl/(.*)","http://www.bluecoat.com/$(1)" )
transform P
end
Heres how this policy works:
1.

The <Proxy> layer performs two-way url rewrite on the request if the request matches a
client url for the server portal. If ProxySG receives an HTTP request for the host
www.bluecoat.nl then it executes the action portal. This action has to components:

rewrite action which effectively instructs ProxySG to fecth a different URL than the
one requested

transform action which changes the response received by the ProxySG

2.

The rewrite() action rewrites the request URL, URL host, or components of the specified
header if it matches the regular-expression pattern. Only the host and port are available for
rewriting by the URL or URL host form when the client browser is using a proxy for an
HTTPS connection and the CONNECT or TUNNEL method is used. This is because the URL
path is encrypted and unavailable for rewriting.

3.

The define url_rewrite definition, defines rules for rewriting URLs in HTTP responses.
The URLS are either embedded in tags within HTML, CSS, JavaScript, or ASX documents, or
they are contained in HTTP response headers. In addition to rewriting URLS, you can also
rewrite arbitrary JavaScript. This transformer takes effect only if it is also invoked by a
transform action in a define action definition block, and that block is in turn called from an
action( )property.

Important: You do not need to have a forwarding rule if you implement the TWURL with
the CPL code shown above.

304 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 20: Two-Way URL Rewrite

Instructors Notes for Two Way URL Rewrite Lab


Overview

A server portal provides controlled access to a Web server or collection of Web servers. When a
ProxySG appliance is configured as a server portal, it performs two-way URL rewrite between a
set of external client URLs and a set of internal server URLs.

When the ProxySG appliance receives a request from an external client for an internal Web page, it
rewrites the requested URL, changing it from client form to server form, and then sends the
rewritten request to the internal server. When the server returns a response, the ProxySG
appliance rewrites the URL, changing it from server form back into client form.
In this lab, you configure the ProxySG appliance to perform TWURL for a pair of URLs that have
similar appearance by writing a new policy. You also edit the host file on your PC to act as an
external client so you can test the new policy

Computer Hardware and Software Requirements


Table 20-1: Requirements for the Instructor
Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Table 20-1: Requirements for Students


Software

Version

F FireFox

F version 2.0.0.5

F Internet Explorer

F version 6.0 or above

F SGOS

F 5.2.1.3; build 30166

F Windows XP

F SP2 build

Instructor Edition 305

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

306 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 21:Failover

Estimated Lesson Time: 15 minutes

Instructors Note: The Blue Coat SG allows you to create failover scenarios in a variety
of ways. In this chapter, describe both basic and advanced configurations. If you have any
specific implementation examples, discuss them here. Even if the slides do not cover the
topic, spend some time reminding the students that load-balancing using PAC files, DNS
round robin, WCCP, or Layer 4 switches represents the most effective solution. By definition,
failover implies a solution where not all of the devices are active at the same time. You can,
however, create a combination of load-balancing and failover, using the information discussed
in Slide 21-3.
When implementing failover, or even load balancing, remember that ProxySG appliances do
not automatically share policies. You must either manually configure the devices that
participate in the failover to have the same policies or use Blue Coat Director. Alternatively,
you might discuss how to transfer policy files across multiple devices; however, there are
several risks involved, as you might not properly transfer all of the required information.

Using failover, ProxySG offers the capability to implement a redundant configuration. Failover
allows a second ProxySG appliance to take over if a first appliance fails, providing redundancy to
the network through a master/backup relationship. In normal operations, the master (the machine
whose IP address matches the group name) owns the address. The master sends keepalive
messages (advertisements) to the backups. If the backups do not receive advertisements at the
specified interval, the backup with the highest configured priority takes over for the master. When
the master comes back online, the master takes over from the backup again.
The Blue Coat failover implementation resembles the Virtual Router Redundancy Protocol (VRRP)
with the following exceptions:

A configurable IP multicast address is the destination of the advertisements.

The advertisement interval is included in protocol messages and is learned by the peers.

A virtual router identifier (VRID) is not used.

Virtual MAC addresses are not used.

MD5 is used for authentication at the application level.

Masters are elected, based on the following factors:

If the failover mechanism is configured for a physical IP address, the machine owning the
physical address has the highest priority. This is not configurable.

If a machine is configured as a master using a virtual IP address, the master has a priority that
is higher than the backups.

When a backup takes over because the master fails, an event is logged in the event log. Using IP
address failover, you can create a redundant network for any explicit proxy configuration. If you
require transparent proxy configuration, you can create software bridges to use failover. Using a
pool of IP addresses to provide redundancy and load balancing, Blue Coat migrates these IP
addresses among a group of machines. The Blue Coat failover solution, SGRP, uses an
active/passive approach. SGRP is a fairly basic solution. All proxies in the failover group share a
Virtual IP address (VIP) and are assigned a priority.

Instructor Edition 307

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Important: While the IP address of the master ProxySG can be used as the VIP, use a neutral
IP address for the VIP so that you can access each machine individually. A
neutral IP address is one that is not being used by either machine.

The proxy with the highest priority is the called the master. The other proxies are all backups.
Though all proxies monitor the VIP and can answer requests, only the master replies to Address
Resolution Protocol (ARP) requests for the VIP. If the master fails, the backup with the highest
priority becomes the master. When the proxy that failed comes back online, it resumes the role of
master. This failover method is very similar to the Virtual Router Redundancy Protocol (VRRP).
You can also create failover configuration, when the ProxySG are deployed in bridging mode.
There are two options available to you to create failover in bridging mode:

Parallel Failover

Two or more ProxySG are placed between two Layer 2 switches, with one interface attached to
each of the switches.

Serial Failover

Two or more ProxySG are connected one after the other, with one network interface of the first
proxy connected to the switch, and the other interface connected with a cross-over cable to the
other proxy.

308 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 21: Failover

Failover Basics and Configuration


Blue Coat SG provides failover similar to
Nokias VRRP

Two or more proxies are configured with a


virtual IP address

The master unit makes periodic multicast


announcements
If two announcements are missed, the standby
assumes the shared virtual IP

6OLGH)DLORYHUIXQGDPHQWDOV

Instructors Note: Spend some time talking about VIPs. More information is provided later in
the chapter but it is important that students understand that concept of VIP so they can
understand how failover works. Once students understand how failover works, you can
explain configuration. When you discuss failover configuration options, you can use them to
reinforce failover concepts that you have previously covered. Inform students that lengthening
the advertisement interval results in slower takeover. That is, while you can decrease the
number of packets sent across the network by lengthening the advertisement time, you also
lengthen the time it takes for the backup to take over when the master has failed.

The Blue Coat failover implementation resembles the Virtual Router Redundancy Protocol (VRRP)
with the following exceptions:

A configurable IP multicast address is the destination of the advertisements.

The advertisement interval is included in protocol messages and is learned by the backups.

A virtual router identifier (VRID) is not used.

Virtual MAC addresses are not used.

MD5 is used for authentication at the application level.

To configure failover, two or more ProxySG appliances are configured to share a VIP. In normal
operations, the master (the machine whose IP address matches the group name) owns the IP
address and answers all the ARPs. The master sends keepalive messages (multicast
advertisements) to the backups. If the backups do not receive advertisements at the specified
interval, the backup with the highest configured priority takes over for the master. When the
master comes back online, the master takes over from the backup again.

When a backup takes over because the master fails, an event is logged in the event log. No e-mail
notification is sent.
The same VIP can be assigned to as many proxies as necessary. You can also back up one proxy
with another by setting up multiple VIPs.

Instructor Edition 309

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

You can create a failover group using either a new IP address or an existing IP address. If the
group has already been created, you cannot change the new IP address without deleting the group
and starting over. When you configure failover, consider the following options:

New IP: IP address of VIP to take place in failover.

Existing IP: Physical interface of existing VIP.

Enable: Activates failover configuration. The enable option specifies whether this group is
active or inactive. Select enabled to enable the failover group.

Multicast Address: Specifies where the master/failover advertisements are sent. The Multicast
Address option refers to a Class D IP address that is used for multicast. It is not a virtual IP
address. The multicast address has the form of 224.xxx.xxx.xxx. The multicast IP address
must be the same for all members of the failover group; the proxies listen for multicast
advertisements on that IP address.
Note:

Class D IP addresses are reserved for multicast. A Class D IP address has a first bit
value of 1, second bit value of 1, third bit value of 1, and fourth bit value of 0. The
other 28 bits identify the group of computers that receive the multicast message.

Relative Priority: Weight of that system in failover group. Relative Priority refers to a range from
1-255 that is assigned to systems in the group. 255 is reserved for the system whose failover
group ID equals the real IP address.

Master: Identifies the system with the highest priority; for example, the appliance to be used as
the master.

Advertisement Interval: Refers to the length of time in seconds between advertisements sent by
the group master. The default is 40 seconds. If the group master fails, the backup with the
highest priority takes over (after approximately three times the interval value). Set this value
to control the failover time of the group.

Group Secret: Used to hash the information sent out in the multicast advertisement so that
someone cannot spoof the master. This secret must be the same for all members in the failover
group. The default secret is secret.

310 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 21: Failover

Basic Configuration

6OLGH%DVLFIDLORYHUGHSOR\PHQW

Instructors Note: Use this slide to go over the concepts you talked about on the previous
page. Make sure that students understand that this is an explicit proxy deployment with a
Layer 2 switch. All requests are sent to the shared VIP. You can implement failover for
transparent deployments as well. Discuss the fact that the policies are not automatically
synchronized. You need to make sure that the policies are the same on each proxy. Mention
Director.

Slide 21-2 illustrates the simplest failover configuration. In this example, the client is configured to
send requests through a Layer 2 switch to the VIP shared by the ProxySG appliances, which are
configured as explicit proxies.
The master ProxySG receives the client requests and periodically sends multicast keepalive
messages to the network. In essence, the master ProxySG answers to all ARP requests to the VIP.
The backup unit, is connected to the network but does answer to any ARP requests. While the
master is active, you can access the backup unit only through the backup IP address directly.

As mentioned before, the master sends out a multicast periodically (you might have issues with
certain switchesthis creates an environment where both units are trying to be the master). If the
master does not send two consecutive multicast keepalive announcements, the backup takes over
for the master and services client requests. When the backup takes over, it starts replying to the
ARP requests for the VIP. Additionally the backup sends gratuitous ARP messages, which notify
that the IP has now moved over to this device.

Whenever you configure VIP, you must have all of the ProxySG running the same exact set of
policies. Because a different proxy can start handling the traffic at anytime, ensure that each proxy
handles the traffic in a consistent manner. ProxySG appliances participating in a failover
configuration do not automatically synchronize policies. You must manually reproduce policies
on all the ProxySG in the failover group, or you can use Director.
Important: While the failover VIP address can be the same address as that assigned to the
master, Blue Coat recommends assigning a separate IP address to the master and
backup, and have them share a third VIP for failover.

Instructor Edition 311

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Advanced Configuration

6OLGH$GYDQFHGIDLORYHU

Instructors Note: The standard failover configuration does not allow you to maximize the
fact that you have two or more ProxySG. This slide shows a pretty common implementation
where you can have both failover and load-balancing. Each ProxySG acts both as a master
and as a backup. You should combine DNS round-robin and this failover configuration to
create an environment combining load balancing with high availability.

The basic failover configuration discussed in the previous slide, suffers from a major drawback:
only one machine is active at any given time. Using only one ProxySG does not maximize your
investment. You can create a double failover configuration. The basic idea is pretty simple:

Define two separate VIP

Assign each ProxySG to be the master for one VIP and backup for the other VIP

Configure your PAC file to use a virtual name for the ProxySG

Configure your DNS server to resolve the hostname of the ProxySG to each of the VIP
alternatively (DNS round-robin)

The same caveats discussed for the simple failover configuration, continue to be true for this more
advanced configuration. In particular you need to make sure that the proxies involved in the
failover have the exact same policies running. If the policies are not absolutely identical, the users
will experience inconsistent behaviors when accessing the Internet.
You can scale this configuration to any number of ProxySG; you need to have has many VIP as
you have ProxySG; you also need to set the priority in which they take over each other.

312 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 21: Failover

Parallel Bridging

6OLGH3DUDOOHOEULGJLQJ

Instructors Note: Parallel bridging is an interesting solution that combines failover with easy
transparent proxy deployment. There are few issues that you need to point out to the students
about this solution:
You are not taking full advantage of having two ProxySG in your network.
Requires loop-detection, which is available only in SGOS 5.1.x or higher.
Requires software bridging.
The ProxySG provides bridging functionality by two methods:

Software (or dynamic): the bridge is constructed using a set of installed interfaces. Within each
logical bridge, interfaces can be assigned or removed.

Hardware (or pass-through): the bridge uses a 10/100 dual interface Ethernet adapter. This
type of bridge provides pass-through support.

Bridging supports the Spanning Tree Protocol (STP). STP is a link management protocol that
prevents bridge loops in a network that has redundant paths that can cause packets to be bridged
infinitely without ever being removed from the network. STP ensures that a bridge, when faced
with multiple paths, uses a path that is loop-free. If that path fails, the algorithm recalculates the
network and finds another loop-free path. The administrator can enable or disable spanning tree
participation for the interface.
In parallel failover mode, two ProxySG systems are deployed side by side on redundant paths. In
parallel failover, the back-up does not actively bridge any packets unless the master fails. If the
master fails, the back-up takes over the master IP address and begins bridging.

Blue Coat recommends that you enable loop-detection (STP) if you have parallel bridging enabled.
Failure to do so may have unpredictable results on the stability of your network infrastructure.
Note:

Parallel bridging can be implemented only by using hardware bridging. Software


bridging cannot be used.

Instructor Edition 313

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Note:

Bridge interfaces cannot be used in WCCP configurations. If the configuration


includes bridge interfaces, you will receive the following error if you attempt to load
the WCCP configuration file:
Interface 0:0 is member of a bridge

314 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 21: Failover

Serial Bridging

6OLGH6HULDOEULGJLQJ

Instructors Note: The same notes discussed before apply to serial bridging failover;
however loop-detection, and consequently SGOS 5.1.x, is not required. Point out again that
this is still an active-passive configuration where you can only use one ProxySG at the time.
There is not load-balancing available in this configuration. You should discourage it.

In serial failover mode, the backup proxy is inline and continuously bridges packets, but does not
perform any other operations to the bridged traffic unless the master fails. If the master fails, the
backup takes over the master IP address and applies policy, etc. A serial configuration is shown in
the slide above.

In this scenario loop-detection is not necessary. But you still loose the advantage of having
multiple ProxySG appliances: You have failover but not load balancing. This feature, while simple
to install and configure is not particularly advisable, as yields limited gains to the overall
infrastructure.
Note:

Serial bridging can be implemented only by using hardware bridging. Software


bridging cannot be used.

Instructor Edition 315

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

316 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 21: Failover

Instructors Notes for Implementing Failover Lab


Overview

Students will work in pairs to simulate failover from the master to the slave of the failover group.

IP Addressing Scheme
Equipment

Role

IP Address

Students SG with Odd


IP Address

Master

172.16.90.21,
172.16.90.23,
172.16.90.25,
172.16.90.27,
172.16.90.29

Students SG with Even


IP Address

Backup

172.16.90.22,
172.16.90.24,
172.16.90.26,
172.16.90.28,
172.16.90.30

Computer Hardware and Software Requirements


Table 21-1: Requirements for the Instructor
Software/Hardware

Version/Model

Firefox

Version 2.0.0.5

Internet Explorer

Version 6.0 or above

SGOS

5.2.1.3 build 30166

Windows XP

SP2 build

Table 21-1: Requirements for Students


Software/Hardware

Version/Model

Firefox

Version 2.0.0.5

Internet Explorer

Version 6.0 or above

SGOS

5.2.1.3 build 30166

Windows XP

SP2 build

Desired Results

A continuous ping to the VIP will time out before resuming when simulating failover of master to
slave in a failover group.

Instructor Edition 317

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

318 Instructor Edition

Blue Coat Education and Training Services BCCPP Course v 3.0.3

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 22:Access Logging Advanced Topics

Estimated Lesson Time: 45 minutes

Instructors Note: This chapter focuses on two important advanced topics in access logging:
log formats and security. This page and the next offer a brief review of access logging before
beginning new material. It is important to review the SSL protocol and the concepts behind
digital certificates and PKI before teaching this section.

This chapter is divided in two main sections. The beginning of the chapter describes in details log
types and log formats. You should spend enough time on these two concepts to make sure the
students understand the difference. The most important log type is the one called main, as it is
used for HTTP and other protocols. For better performances with Blue Coat Reporter, main should
always use the bcreportermain_v1 log format.
Remind the students how to read the variables used to define the log format by drawing the
following diagram:
Client (C) ----> Proxy Server (S) ----> Remote Server (R)
Use as example the following variables:

- CS-category: the categorization for the client request URL to the proxy

- RS(content-type): the file type sent from the OCS (remote server) to the proxy

Important: Discuss how the proxy may indeed modify many of the values when processing data
from the client to the proxy (CS) and then sending it to the remote server (SR) and vice versa.

The second part of the chapter discusses two seldom used features of the access log, which
nonetheless are very important for security conscious customers. ProxySG allows you to sign and
encrypt log files using PKI.

To sign access log you can create a self-signed certificate using the ProxySG; however for
encrypting the access logs you need to have a way of creating the private and public keys pair
outside the proxy. You can use a variety of software suites; if you decide to do the lab, you should
briefly discuss OpenSSL.

Instructor Edition 319

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Understanding Access Logs


Defining Access Log

Selecting log types and log formats

Understanding access log fields


Detailed transaction information
Custom Access logs

Troubleshooting using access log


Useful links
Access logging filters

6OLGH8QGHUVWDQGLQJ$FFHVV/RJV

Instructors Note: Use the slide to cover what you discuss in the first part of the chapter.
Particularly prepare the students how to use Access logging feature for advanced
troubleshooting. You may show the Access logging tail short cut for the main access log at:
https://{proxysg IP}:8082/Accesslog/tail/main

Blue Coat Systems has a number of resources to provide diagnostic information.The most widely
used ones are logs. Different types of logs are available on the ProxySG:

Access logs: Access logging allows you to track Web usage for the entire network or specific
information on user or department usage patterns. These logs and reports can be made
available in real-time or on a scheduled basis. Access logs record client requests to the
ProxySG. Reports can be made of these logs and their information analyzed.

Event logs: Contain information of activity on the ProxySG. Used to view administrators
actions and the status of the machine.You can configure the ProxySG to log system events as
they occur. Event logging allows you to specify the types of system events logged, the size of
the event log, and to configure Syslog monitoring. The ProxySG can also notify you by e-mail
if an event is logged.

Policy trace logs: A policy trace can provide debugging information on policy transactions. This
is helpful, even when policy is not the issue. A policy trace log records policy-related events in
each layer.

By using these three types of logs, you can gain a detailed view of what occurs on a ProxySG. To
create access logs, you can choose an existing format or create a custom format. Pre-defined
formats are include NCSA, Squid, SurfControl, Websense, and W3C ELFF (default). You can
create other formats using custom or ELFF format strings. A log facility is a separate log that
supports a single log format. You associate a protocol with the log facility and add configurable
information to it, such as an upload schedule. Four log facilities are available: im, main, p2p, and
streaming. For instance, you can assign HTTP and HTTPS to the main log facility using the W3C
ELFF format. When you enable access logging, by default you enable logging for all protocols
unless you see the word none next to a protocol in the Management Console. This means no log
format is associated with that protocol.

320 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 22: Access Logging Advanced Topics

By configuring an upload client, you can transfer access logs from the ProxySG to the repository
from where you will run reports. The ProxySG supports four types of upload clients: FTP client
(default), HTTP client, custom client, and Websense client. The appliance also supports secure FTP
and HTTPS. The upload schedule allows you to configure the frequency of access logging upload
to a remote server.
You can also create a logging policy that will help you manage the access logs you set up. You can
create policy either through the Visual Policy Manager (VPM) or by using Content Policy
Language (CPL). You can use the Reporter tool to analyze your log files.

Instructor Edition 321

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Log Types and Formats


Main

Used by default by HTTP Proxy


Uses bcreportermain_v1 format; supports PVC

CIFS

Used by default by CIFS proxy


Uses bcreportercifs_v1 format

SSL

Used by default by SSL and HTTPS forward proxies


Uses bcreporterssl_v1 format

6OLGH/RJW\SHVDQGIRUPDWV

Instructors Note: . The slide shows the three most commonly used log types and the best
log format you should associate to these log types when using Blue Coat Reporter, in order to
obtain maximum performances. Read the first few variables used to create the three log
formats; it is important that the students learn how to decipher the meaning of each log entry.
Mention that if you are using SmartFilter, SurfControl, or Websense, you may want to use their
reporting tools as well. If you use reporting tools other than Blue Coat Reporter, you need to
use the specific log format for that vendor.

Content is logged under its own special format in access logs. A majority of content is HTTP
content and uses the Main log type. Blue Coat has its propreitary format for such content and the
ProxySG uses the bcreportermain_v1 format to log this content. Similarly, CIFS content, which
comprises mostly intranet access uses the bcreportercifs_v1 format, and secure content like
SSL and HTTPS uses the bcreporterssl_v1 format. The fields that are under every format are
described below:

bcreportermain_v1 format:

date time time-taken c-ip cs-username cs-auth-group x-exception-id scfilter-result cs-categories cs(Referer) sc-status s-action cs-method
rs(Content-Type) cs-uri-scheme cs-host cs-uri-port cs-uri-path cs-uriquery cs-uri-extension cs(User-Agent) s-ip sc-bytes cs-bytes x-virus- id

bcreportercifs_v1 format:

date time c-ip c-port r-ip r-port x-cifs-uid x-cifs-tid x-cifs-fid xcifs-method x-cifs-server x-cifs-share x-cifs-path x-cifs-orig-path xcifs-client-bytes-read x-cifs-server-bytes-read x-cifs-bytes-written
x-client-connection-bytes x-server-connection-bytes x-server-adnconnection-bytes x-cifs-client-read-operations x-cifs-client-writeoperations x-cifs-client-other-operations x-cifs-server-operations saction x-cifs-error-code cs-username cs-auth-group s-ip

bcreporterssl_v1 format:

322 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 22: Access Logging Advanced Topics

date time time-taken c-ip cs-username cs-auth-group x-exception-id scfilter-result cs-categories sc-status s-action cs-method rs(ContentType) cs-uri-scheme cs-host cs-uri-port cs-uri-extension cs(User- Agent)
s-ip sc-bytes cs-bytes x-virus-id x-rs-certificate-observed- errors
x-rs-connection-negotiated-cipher-strength x-rs-certificate- hostname
x-rs-certificate-hostname-category

The bcreportermain_v1 format also supports the Page View Combiner (PVC). This feature
combines multiple HTTP requests that are associated with a single Web page into a single log line.
When a user browses to a Web page, that page often sends out request for more content either
from the same server or from different servers. Rather than regarding each of these requests as
separate requests, the PVC combines all of these related page requests into one. This reduces the
number of database entries from the original log file and improves report generation performance.
A log format simply indicates the type of log being used. The ProxySG supports several different
existing, or pre-defined formats:

ELFF (W3C Extended Log File Format):

ELFF is a log format defined by the W3C that contains information about Windows Media and
RealProxy logs and is general enough to be used with any protocol. The W3C Extended Log
File Format (ELFF) is a subset of the Blue Coat Systems format. Each field is described using a
text string. When using an ELFF or custom format, a blank field is represented by a dash
character. Unlike the Blue Coat custom format, ELFF does not support character strings and
require a space between fields.

NCSA common log format:

The NCSA common log format contains one line for each request and contains only basic
HTTP access information. This format cannot be modified. The format of each log entry is
shown below:

remotehost rfc931 authuser [date] request status bytes

SQUID-compatible format:

The SQUID-compatible format contains one line for each request and is a log type designed
for cache statistics. This format cannot be modified. For SQUID-1.1,the format is:

time elapsed remotehost code/status bytes method URL rfc931


peerstatus/peerhost type

SmartReporter, an ELFF log format compatible with the SmartFilter Reporter tool.

SurfControl, a log format compatible with the SurfControl Reporter tool.The SurfControl log
format includes fully-qualified usernames when an NTLM realm provides authentication. The
simple name is used for all other realm types.

Websense, a log format compatible with the Websense Reporter tool.

bcreportermain_v1: This is a reserved format that cannot be edited.

bcreporterssl_v1: This is a reserved format that cannot be edited. It only contains fields that
do not reveal private or sensitive information, unlike the bcreportermain_v1 format. In
addition, a number of other ELFF-type log formats are also pre-defined: im, main, p2p,
streaming. It also is possible to create newELFF and custom log formats.

Instructor Edition 323

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Sample Log

1. Log file header

Valid log files must have an header

2. Log entry

First entry separated from header by empty line

6OLGH6DPSOHORJ

Instructors Note: The slide discusses some key points about the structure of an access log.
The file shown in the slide is a main access log using bcrepotermain_v1 format. You need to
point out few important elements: 1) the header must exists in all log files. If the header is
missing, the Blue Coat Reporter does not process the file and the data it contains. You may fix
a log file by manually copying and pasting the headers from a properly formatted log file. 2) An
empty line separates the header and the data. 3) Point out that the #Remark header contains
the serial number and the IP address of the proxy, which created it; this is important
information when you are troubleshooting a multi-proxy environment.
Question: What is the IP address of the client making the request? What is the requested
URL?
Answer: Client IP is 156.160.20.11; URL is http://www.ig.com.br
Question: Is the content coming from the proxy cache? (difficult question)
Answer: Yes. The sc-status is 304, which is the response to a GET IF-MODIFIED-SINCE
(GIMS) when the content did not change. Additionally you can see that the s-action is
TCP_HIT (discussed in more details on Slide 22-7).

This slide presents a sample log as seen in an access log file. Every log file should have a header.
The header lists information regarding the version of the ProxySG, the date and time of the log,
and the fields that are present in the access log.

The header is followed by the log entries that are separated from the header by an empty line. Log
entries contain detailed information about the date, time, and the content that was accessed by a
client. These log entries make up the final log file that can then be digitally signed, encrypted and
uploaded onto the management console.
You can manually recreate the header if you have log files which would otherwise be valid.

Header-less files may appear when you switch log formats without interrupting access logging
first.

Important: It is important for log files to have valid headers. Blue Coat Reporter does not
process log files without valid headers.

324 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 22: Access Logging Advanced Topics

Access Logging- Custom Format

6OLGH$FFHVV/RJJLQJFXVWRPIRUPDW

Instructors Note: This slide discusses the custom format available for creating a log format.
A complete list is available in the ProxySG (ProxySG) Configuration and Management Guide.
Not much to cover in this slide. Just re-iterate what the meaning of C (client), S (ProxySG),
and R (Remote Server) are. You should discuss the examples, which appear in the student
section.

The ProxySG can create access logs with any one of six formats. Four of the six are reserved
formats and cannot be configured. However, you can create additional logs using custom format
strings. Custom formats are a series of space delimited fields and each field is described using a
text string.
The different field types in a custom format are:

identifier: A field type unrelated to specific party such as date or time.

prefix-identifier: Describes information related to a party or a transfer, such as c-ip


(clients IP) or sc-bytes (how many bytes were sent from the server to the client).

prefix(header):Describes a header data field. The valid prefixes are:


c=client

s=server (ProxySG)
r=remote (OCS)

sr=server to remote
cs=client to server
sc=server to client

rs=remote to server

Custom format allows any combination of characters and format fields. Multiple spaces are
compressed to a single space in the actual access log.

Instructor Edition 325

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Log Field Samples 1 of 2

6OLGH/RJ)LHOG6DPSOHV

Instructors Note: There are few interesting things to point out in this slide. You should
discuss all of them in form of questions.
Question: What is the username authenticated in the proxy?
Answer: student01

Question: Which domain is NOT being requested? (difficult question)


Answer: www. cnn.com as it appears as the Referer, which means it is NOT the log for a
request to www.cnn.com (however the user requested www.cnn.com, which then contains
references to external resources)
Question: What is a cache miss or a cache hit?
Answer: It is a cache miss

Reports are compiled based on the information contained in the access logs. The contents of an
access log are determined by the log field names (which determine what data types are captured
during the SG appliance logging process).
The ELFF format, which is a subset of the Blue Coat systems format, contains fields described
using a text string. The different types of fields include identifier, prefix-identifier, and
prefix-header.

Some log fields correlate to absolute data such as URLs, while others derive information from
access log variables such as browsing time.

Administrators can gain a lot of valuable information from the log fields. The fields shown in the
slide above have been described as follows:

date: GMT date in YYYY-MM-DD format

time: GMT time in HH:MM:SS format

time-taken: Specifies the time taken in milliseconds to process the request

c-ip: Specifies the IP address of the client

326 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 22: Access Logging Advanced Topics

cs-username: Specifies the relative username of the client authenticated to the proxy

cs-auth-group: Specifies one group that the user belongs to. If the user belongs to multiple
groups, the group logged is determined by the Group Log Order configuration specified in the
VPM. If a Group Log Order is not sepcified, an arbitrary group is logged. Note that only
groups referenced by policy are considered

x-exception-id: Identifies the exception resolved. It is left blank if the transaction has not
been terminated

sc-filter-result: Provides the content-filtering result. The field can specify Denied,
Proxied or Observed

cs-categories: Specifies all the content categories of the request URL

cs(Referer): Specifies the URL from the Request header

sc-status: Specifies the protocol status code from the appliance to the client

s-action: Describes the action that the appliance took to process the request. TCP_MISS
means that the requested object was not in the cache

You will find description of some more actions on the following page.

Instructor Edition 327

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Log Field Samples 2 of 2

6OLGH/RJ)LHOG6DPSOHV

Instructors Note: There are few interesting things to point out in this slide. You should
discuss all of them in form of questions.
Question: What is the IP address of the ProxySG?
Answer: 172.16.90.20

Question: What is the requested URL?


Answer: http://i.l.cnn.net/cnn/.element/css/2.0/main.css/

Question: What is really being requested? (difficult HTML question)


Answer: A style sheet.

The slide above represents another section of sample log fields. It mostly consists of client to
server prefixes that occur during a transaction. Note that apart from providing client and server
information, access logs also keep a record if a virus was detected in the transaction.

cs-method: Specifies the request method used from the client to the appliance

rs(Content-Type): Describes the information in the response header and specifies the
content type

cs-uri-scheme: Specifies the scheme from the log URL

cs-host: Specifies the host name from the clients requested URL. If rewrite policies are used,
this fields value is derived from the log URL.

cs-uri-port: Specifies the port from the log URL

cs-uri-path: Describes the path from the log URL. Does not include the query

cs-uri-query: Specifies the query from the log URl

cs-uri-extension: Specifies the document extension from the log URL

cs(User Agent): Specifies request header : User Agent

s-ip: Specifies the IP address of the appliance on which the client established its connection

328 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 22: Access Logging Advanced Topics

sc-bytes: Specifies the number of bytes sent from the appliance to the client

cs-bytes: Specifies the number of bytes sent from the client to the appliance

x-virus-id: Identifies a virus if one was detected

Using these pointers, you can ascertain information that is specified in access logs. More fields can
get added depending on the client-server transaction.

Instructor Edition 329

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Transaction Information

6OLGH7UDQVDFWLRQ,QIRUPDWLRQ

Instructors Note: You may want to discuss this slide actually earlier in the chapter, so that it
is easier for the students to answer some of the questions about the status of the transaction
or you can use it as a summary. Focus on the three main actions: TCP_MISS: The object is
cacheable but not available in cache at the moment TCP_NC_MISS: The object is
non-cacheable, therefore it is not in cache and will not be cached one retrieved. TCP_HIT: The
object is cacheable and it is available on the ProxySG.
Important: All content which contains a ? in the URL (query string) is consider dynamic
content and not worth caching. This is the most common example of non-cacheable content.

This slide describes the transaction that occurs between a client and a server and how access logs
keep a record of information that was served from a cache or entirely from the RAM, or when the
information was obtained from the origin server. The transaction is described below:

When the client first requests information (object) the ProxySG checks with the cache to see if the
requested object can be served from there. If the object is present in the cache, then TCP_HIT is
recorded in the access log and the object is sent to the client. If the object was entirely present in the
RAM, it is served from the RAM and TCP_MEM_HIT is recorded in the server action field in the
access log.
If the object was present in the cache but the virus-scanner-tag-id did not match the current
scanner tag, the object is rescanned by sending it to the ProxyAV. The server action field in the
access log then records the action as TCP_RESCAN_HIT. The object is sent to the client after the
virus scanning.

If the requested object is not found in the cache or the RAM, the request is sent to the origin server
to retrieve the object. If the requested object was not present in cache at all, the action is recorded
as TCP_MISS. Usually when objects are obtained from the origin server, the ProxySG saves a copy
in its cache. If the object returned from the origin server is non-cacheable, the action is saved as
TCP_NC_MISS. To speed up delivery of requested objects, the ProxySG can serve cached objects
while requesting for fresher content from the origin server. In this case, the action gets recorded in
the access log as TCP_PARTIAL_MISS.

330 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 22: Access Logging Advanced Topics

Actions are also logged in the access log when objects are delivered to the client. When the obejct
is successfully delivered to the client, the action is logged as ALLOWED. When policies in the
ProxySG deny the object from being delivered to the client, the action is logged as DENIED. When
access to the requested object is denied by a filter, the action is logged as TCP_DENIED.

Instructor Edition 331

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

Access Logging Encryption

6OLGH$FFHVV/RJJLQJHQFU\SWLRQ

Instructors Note: Slide 22-8 introduces the topic of securing access logs. Do not spend a lot
of time here; the next slides discuss the topic in greater detail. However, it is important to make
sure students understand the difference between signing and encrypting before proceeding to
the next slide.

To ensure greater security, you can configure the ProxySG to digitally sign and encrypt access logs.
To encrypt access log files, you must first place an external certificate on the ProxySG. You can
import an X.509 certificate into ProxySG to use for encrypting data. The ProxySG derives a session
key from the public key in the external certificate and uses it to encrypt the log. When an access
log is encrypted, two access log files are produced: an ENC file (extension .enc), which is the
encrypted access log file, and a DER file (extension .der), which contains the ProxySG session
key and other information.
You need four things to decrypt an encrypted access log:

the ENC file

the DER file

the external (public key) certificate

the corresponding private key

To decrypt an encrypted access log, you must concatenate the DER and ENC files (with the DER
file in front of the ENC file) and use a program such as OpenSSL for decrypting. For example, use
the following UNIX command and a tool such as OpenSSL to concatenate the DER and ENC files
and decrypt the resulting file:
cat path/filename_of_DER_file path/filename_of_ENC_file | openssl smime-decrypt
-inform DER -binary -inkey path/filename_of_private_key -recip
path/filename_of_external_certificate -out path/filename_for_decrypted_log_file

You can also download a script based on the OpenSSL tool for decrypting.

Go to: https://download.bluecoat.com/release/SG4/files/accesslog_decrypt.zip.

332 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 22: Access Logging Advanced Topics

Access Logging Digital Signing

6OLGH$FFHVV/RJJLQJGLJLWDOVLJQLQJ

Instructors Note: The idea behind signing logs is to make sure that the data is actually
coming from a specific ProxySG and is not spurious information uploaded by a malicious user.
Without the signing option, a malicious user could upload fake data to the FTP server, making
reports useless. Digital signing is very important for companies that must adhere to strict
compliance rules (for example HIPPA and SOX in the U.S.).

You can digitally sign access logs to certify that a particular ProxySG wrote and uploaded the
particular log file. Signing is supported for both content types text and gzipand for both
upload typescontinuous and periodic. Each log file has a signature file associated with it that
contains the certificate and the digital signature for verifying the log file. The signature file has the
same name as the access log file but with a .sig extension; that is, filename.log.sig, if the access
log is a text file, or filename.log.gzip.sig, if the access log is a gzip file.
You can digitally sign your access log files with or without encryption. If the log is both signed
and encrypted, the signing operation is done first, meaning that the signature is calculated on the
unencrypted version of the file. You must decrypt the log file before verifying the file. Keep in
mind that attempting to verify an encrypted file fails. When you create a signing keyring (which
must be done before you enable digital signing), keep in mind the following:

The keyring must include a private key and a corresponding x.509 certificate.

The certificate purpose must be set for smime signing. If the certificate purpose is set to
anything else, you cannot use the certificate for signing.

Add the %c parameter in the filenames format string to identify the keyring used for signing.

If encryption is enabled along with signing, the %c parameter expands to


keyringName_Certname.

Note:

Digital Signing is disabled by default. The signing feature is not available for custom
or Websense clients.

Instructor Edition 333

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

If the file whose digital signature you want to verify is also encrypted, you must decrypt the file
prior to verifying the signature.You can use a program such as OpenSSL to verify the signature.
For example, use the following command in OpenSSL:

openssl smime -CAfile cacrt -verify -in filename.sig -content filename.log -inform

DER -out logFile

The table below explains what the terms in the above Open SSL command stand for.

Table 22-1: OpenSSL commands to verify digital signature


cacrt

The CA certificate used to issue the certificate in the signature file.

filename.sig

The file containing the digital signature of the log file.

filename.log

The log file generated after decrypting. If the access log is a gzip file, it
contains a .gz extension.

logFile

The filename that is generated after signature verification.

334 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 22: Access Logging Advanced Topics

Access Logging- Statistics

6OLGH$FFHVV/RJJLQJVWDWLVWLFV

Instructors Note: Briefly show this slide and mention that you can see a lot of information
about the ProxySG status in the Advanced URLs available in the Management Console or
directly as shortcut URL. Open a web browser and point it to: https://{proxysg
IP}:8082/Accesslog/tail .Show the different links available there and focus on the main
access log type. Discuss how you can set the refresh time using the format:
/Accesslog/tail/<logName>?<refresh_time>

Access-log statistics can be viewed from the Management Console Statistics>Access Logging tab or
the CLI show access-log statistics [log_name] command, although not all statistics you can
view in the Management Console are available in the CLI. You can also view some access log
statistics by navigating to Statistics>Advanced and clicking Access Log.

Statistics you can view from Statistics>Advanced on the Management Console include:

Show list of all logs: The access log manages multiple log objects internally. These are put

together as one logical access log file when the file is uploaded. The show list shows the
available internal log objects for easy access. To download part of the access log instead of the
whole log file, click on the individual log object shown in the list. The latest log object can be
identified by its timestamp.

Show access log statistics: The statistics of an individual access log is shown.

Show statistics of all logs: The statistics of all the access logs on the system are displayed in a

single list.

Show last N bytes in the log: The last N bytes in the log are shown.

Show last part of log every time it changes: A stream of the latest log entries is shown on the

page as they are written in the system.

Show access log tail with optional refresh time: A refresh from the browser displays the latest

log entries.

Show access log objects: The statistics of individual access log objects are displayed.

Show all access log objects: The statistics of all access log object are displayed in a single list.

Instructor Edition 335

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

The Log Size tab on the Management Console displays current log statistics:

whether the log is being uploaded

the current size of all access log objects

disk space usage

last modified time

estimated size of the access log file, once uploaded.

The ProxySG displays the current access logging status on the Management Console. This
includes separate status information about:

the writing of access log information to disk

the client the ProxySG uses to upload access log information to the remote server.

336 Instructor Edition

.
Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s
Chapter 23: Web Cache Communication Protocol (WCCP)

Estimated Lesson Time: 30 minutes

Instructors Note: This chapter describes how WCCP works between ProxySG and Cisco
WCCP-capable router to achieve transparent proxy. Differences between WCCP version 1
and WCCP version 2 are clearly highlighted with different deployment scenarios given. Spend
ample time discussing the advantages WCCP version 2 has over WCCP version 1. For
example the support for multiple routers and the ability to support other protocols such as FTP
and streaming.

Todays networks require proxy services in order to secure inbound and outbound
communications. Therefore, communications need to be intercepted by the proxy services in order
to apply a secure policy.
The Web Cache Communication Protocol (WCCP) was developed by Cisco Systems and specifies
interactions between one or more routers (or Layer 3 switches) and one or more Web caches.
The purpose of the interaction is to establish and maintain a transparent redirection of selected
types of traffic flowing through a router. The selected traffic is redirected to Web caches, such as
the ProxySG, with the aim of optimizing resource usage and lowering response times.
The main benefits of using WCCP are:

Q Scalability: With no reconfiguration overhead, redirected traffic can be automatically


distributed to up to 32 appliances.

Q Redirection safeguards: If no appliances are available, redirection stops and the router
forwards traffic to the original destination address.

WCCP has two versions, version 1 and version 2, both of which are supported by Blue Coat.
However, only one protocol version can be active on the SG appliance at a time. The active WCCP
protocol set up in the SG configuration must match the version running on the WCCP router.
A WCCP-capable router operates in conjunction with the appliances to transparently redirect
traffic to a set of caches that participate in the specified WCCP protocol. IP packets are redirected
based on fields within each packet. For instance, WCCP version 1 only redirects destination TCP
port 80 (default HTTP traffic) IP packets. WCCP version 2 allows you to redirect traffic from other
ports and protocols.
If you use WCCP version 2, you can balance the load on the caches in a service group. When a
router receives an IP packet for redirection, it hashes fields within the packet to yield an index
within the hash table. The packet is forwarded to the owner SG appliance for servicing. The
amount of redirection hash tables assigned to each SG appliance can be altered to provide a form
of load balancing between caches in a service group.

A hash table is configured by a dynamically elected SG appliance participating in service group,


enabling the simultaneous interception of multiple protocols on multiple ports. You can configure
up to 100 dynamic or standard service groups. A single service can intercept up to eight port
numbers.

Instructor Edition 337

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

What is WCCP ?

Web Cache Communication Protocol by Cisco


Available on Cisco Routers and L3 Switches

Works with Blue Coat SG to achieve transparent


proxy

6OLGH:&&3,QWURGXFWLRQ

Instructors Note: Make sure that students understand what transparent proxy is. Point out to
students that in transparent proxy, clients do not know there is a proxy in the path. Lead the
students to discuss about the characteristics of transparent proxy, the various ways of
implementing transparent proxy and the advantages of using it.

WCCP was first described in the Internet-Drafts of IETF on June 1999 by Cisco Systems. WCCP is
supported on various models of Cisco Routers and Cisco L3 Switches. Specifically, WCCP Version
1 is supported in IOS 11.1 and above while WCCP version 2 requires the equipment to have at
least IOS 12.0(3) .

The Web Cache Control Protocol (WCCP ) feature allows redirection of web traffic transparently to
a Blue Coat Proxy SG with no configuration on the clients. WCCP also offers proxy load balancing
to as many as 32 SG appliances with very minimal configuration.
ProxySG and routers become aware of one another and form a service group using management
packets defined in WCCP. Once the service group has been established, one of the ProxySGs is
designated to determine the load assignments among other ProxySGs. All ProxySGs periodically
communicate with the home router to verify WCCP protocol synchronization and ProxySG
availability within the service group. In return, the home router responds to each ProxySG with
information as to which appliances are available in the service group.
Note:

Blue Coat recommends that WCCP-compliant caches from different vendors be kept
separate and that only one vendors routers be used in a service group.

338 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 23: Web Cache Communication Protocol (WCCP)

WCCP Overview

6OLGH&OLHQWV+7735HTXHVWDUHEHLQJUHGLUHFWHGE\:&&3SURWRFRO

Instructors Note: Explain to students that WCCP is used to redirect requests from the router
to the ProxySG so that policies configured on the ProxySG can be enforced.

As the request from clients user agent arrived at the router, the router will intercept the request
and forward it to the ProxySG .
Generally there are two ways the request can be intercepted and forwarded to router.

GRE: Generic Routing Encapsulation is the default forwarding method performed by the
router. Using GRE, redirected packets are encapsulated in a new IP packet with a GRE header.

L2 MAC Rewrite: Using L2 MAC rewrite, redirected packets are not encapsulated, instead the
MAC address of the target cache replaces the packets destination MAC address. This way of
directing packets saves you the overhead of creating the GRE packet at the router and
decoding it at the cache. Also, it saves network bandwidth that would otherwise be consumed
by the GRE header. The caveat in L2 MAC rewrite however, requires that both the ProxySG
and the WCCP-capable router to be in the same broadcast domain.

If you want to continue using GRE, there is no configuration needed. However, to use L2 MAC
rewrite, you must add forwarding-type L2 option to the SG configuration file.
Note:

WCCP is also known as Web Cache Control Protocol and Web Cache Coordination
Protocol in some IETF Internet-Drafts.

Instructor Edition 339

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

WCCP Overview
WCCP version 1

Support port 80 http traffic only


Single router deployment

WCCP version 2

Support for other ports and protocols


For e.g., HTTP, HTTPS, FTP
Multiple routers deployment
Multicast interaction

6OLGH7KHWZRYHUVLRQVRI:&&3

Instructors Note: Highlight to the students the differences between WCCP version 1 and
WCCP version 2 and make sure they understand the limitations of WCCP version 1.

In WCCP version 1, the WCCP-configured home router transparently redirects TCP port 80
packets to a maximum of 32 appliances. One of the caches participating in the WCCP service
group is automatically elected to configure the home routers redirection tables. This way, caches
can be transparently added and removed from the WCCP service group without requiring
operator intervention. WCCP version 1 supports only single service group.
WCCP version 2 offers the same capabilities as version 1, but with greater support for more than
just HTTP traffic. WCCP version 2 is more suitable in a multiple router deployment as it allows
multicast exchange packets to discover both the router and the ProxySG.
Note:

WCCP version 2 is enabled by default when you name a WCCP service group.
Version 1 requires a specific enable command. For example if you do not explicitly
configure the Blue Coat SG to run any version, version 2 is selected by default. In
event you are having older version of IOS router which only supports WCCP version
1, you will have to add wccp version 1 command in the configuration file.

340 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 23: Web Cache Communication Protocol (WCCP)

WCCP Version 1 Deployment

6OLGH:&&39HUVLRQ'HSOR\PHQW6FHQDULR

Instructors Note: Highlight to the students that WCCP version 1 does not require
configuration of port number as it only supports TCP port 80 (HTTP). Note that WCCP does
not perform protocol detection and thus non HTTP traffic with destination port 80 will also be
redirected.

In WCCP Version 1, the Blue Coat SG is configured with the address of the single router under the
home-router command. When a WCCP-capable router receives an IP packet, the router
examines the packet header to see if it has destination port 80 in the TCP header. Upon seeing
packets with destination port 80, router will redirects it to ProxySG.
1.

A clients user agent sends HTTP request to the original content server (OCS).

2.

The router will intercept all packets having destination port 80 on the TCP header and
redirects it to ProxySG either by using GRE encapsulation or L2 redirect method.

3.

ProxySG processes and applies configured policy, and if the clients request is not denied,
fetches the web objects from the OCS.

Instructor Edition 341

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

WCCP Version 2 Deployment

6OLGH:&&39HUVLRQ'HSOR\PHQW6FHQDULR

Instructors Note: Highlight to the students that intercepting traffic on other TCP ports require
additional configuration on the ProxySG. For example, to intercept HTTP, FTP, Real Network
and Windows Streaming, you will have to add port 80, 21, 554, 1755, 0 0 0 0. Take note that
the 4 ending zeros are there because a single configured service group can intercept up to
eight port numbers.

WCCP Version 2 requires that each Blue Coat SG be aware of all the routers in the service group.
Optionally, Version 2 can use multicast packet exchange for discovery. Configuring a multicast
address on a WCCP-capable router provides reduced WCCP traffic and the ability to easily add
and remove caches and routers from a service group without having to reconfigure all service
group members.
The following sequence of events explains how WCCP Version 2 works:
1.

Each ProxySG sends Here_I_AM packets to the configured list of routers. Routers will build a
view (list) of all Blue Coat SG that is visible.

2.

Clients may send request to different routers on different departments.

3.

The WCCP-capable routers will redirect any configured TCP traffic to the ProxySG. For
example:

Q Port 21 (FTP)
Q Port 554 (Real Networks and Quick Time)
Q Port 1755 (Windows Media Streaming)

4.

ProxySG processes and applies configured policy, and if the clients request is not denied,
fetches the web objects from the original content server.

342 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 23: Web Cache Communication Protocol (WCCP)

WCCP Packet Exchange

6OLGH:&&33DFNHW([FKDQJH

Instructors Note: Tell the students that the router increments the value of the Received_ID
field each time it sends a I_SEE_YOU to the ProxySG and expects to receive the same value
back in the Received_ID field of the next HERE_I_AM from the ProxySG. This technique is
mainly used as a form of acknowledgement.
The following explains the packet exchange used in WCCP discovery process:
1.

ProxySG sends a HERE_I_AM packet periodically to the configured WCCP-capable router.

2.

Router replies with an I_SEE_YOU message to verify the connectivity between the router and
the ProxySG.

3.

The ProxySG joins the WCCP-capable router by periodically unicasting or multicasting


HERE_I_AM packet at a fixed interval. The source IP address of the HERE_I_AM uniquely
identifies the Blue Coat Proxy SG. The router sends an I_SEE_YOU packet back to the SG in
response to each HERE_I_AM it receives.

To specify the address of the WCCP-capable router in the service group, you can use one of the
following method:
1.

Unicast : The IP addresses of the router is explicitly defined in the ProxySG.

For example : home-router 10.1.1.1

2.

Multicast : A single multicast address is configured on all ProxySG.

For example : home-router 224.1.1.1

Important: The valid multicast addresses supported by ProxySG are in the range of 224.0.0.0
to 239.255.255.255. The routers will also have to be configured to listen to the
same earlier configured multicast address by using ip wccp group-listen
command.

Instructor Edition 343

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Blue Coat Education and Training Services BCCPP Course v 3.0.3

WCCP Configuration

6OLGH:&&3FRQILJXUDWLRQVQDSVKRWVIURP3UR[\6*

Instructors Note: Point out that there are various ways of configuring WCCP in the ProxySG.
If time permits, take the initiative to demonstrate the different ways a configuration can be
entered into the ProxySG.

You can create a configuration file customized for your environment through the Command Line
Interface (CLI) or through a text file. The CLI enables the WCCP on the SG appliance immediately;
the drawback is that if any information changes, you must recreate the whole file using the CLI.
With a text file, if any information changes, you can change the individual line; the drawback is
that you must download the file again from an HTTP server to the ProxySG.
The following are two examples of the WCCP configuration in the ProxySG:
1.

Redirecting HTTP Only

To redirect HTTP traffic only, use the following commands in the WCCP settings editor on the SG
appliance.
wccp enable

wccp version 2

service-group web-cache

home-router 10.254.0.193
interface 0
end

In this example, WCCP version 2 is used, the service-group is configured to intercept HTTP traffic
and 10.254.0.193 is the IP address of the Cisco router.

344 Instructor Edition

Pr
Fo ope
r R rty
efe of
re Blu
nc e
e O Co
nly at
. S Edu
tric ca
tly tio
NO n a
T nd
for Tr
Di ain
str ing
ibu S
tio erv
n. ice
s

Chapter 23: Web Cache Communication Protocol (WCCP)

2.

Redirecting HTTP and Streaming

To redirect HTTP and Streaming protocol, you must use WCCP version 2 and the following
configuration can be used.

wccp enable

wccp version 2

service-group 10
priority 1
protocol 6

service-flags destination-port-hash
service-flags ports-defined
ports 80 554 1755 0 0 0 0 0
interface 0

home-router 10.254.0.193
home-router 10.254.0.194
end

In this configuration, traffic is being redirecting to the following TCP ports:

Q 80 (HTTP)
Q 554 (Real Networks and Quick Time)
Q 1755 (Windows Media Streaming)

10.254.0.193 and 10.254.0.194 are the IP address of the two participating routers.

To configure WCCP-capable router to redirect HTTP only, use the following commands in the
Cisco routers:
Router#config terminal

Router(config)#ip wccp web-cache


Router(config)#interface f0/0

Router(config-if)#ip wccp web-cache redirect out

To configure WCCP-capable router to redirect HTTP and streaming traffic, use the following
commands:
Router#config terminal

Router(config)#ip wccp 10

Router(config)#interface f0/0

outer(conf