Name: ProxySG

Text: Blue Coat® Systems
ProxySG™

Configuration and Management Guide

Version SGOS 4.1.4

Blue Coat ProxySG Configuration and Management Guide

Contact Information
Blue Coat Systems Inc.
420 North Mary Ave
Sunnyvale, CA 94085-4121
http://www.bluecoat.com/support/index.html
bcs.info@bluecoat.com
support@bluecoat.com
http://www.bluecoat.com
For concerns or feedback about the documentation: documentation@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. 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.
Document Number: 231-02778
Document Revision: SGOS 4.1.4—03/15/06

ii

Copyrights

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 User's
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):
> 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

iii

Blue Coat ProxySG Configuration and Management Guide

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.
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 , 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.

iv

Copyrights

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
3) ssh-keygen was contributed by David Mazieres under a BSD-style license.
Copyright 1995, 1996 by David Mazieres . 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
@author Antoon Bosselaers
@author Paulo Barreto
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

v

Blue Coat ProxySG Configuration and Management Guide

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 and Tim J. Hudson .
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 Young's, 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:
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

vi

Copyrights

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.
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

vii

Blue Coat ProxySG Configuration and Management Guide

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 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

viii

Contents
Contact Information
Third Party Copyright Notices
Chapter 1: Introducing the ProxySG
Web Security Solution ......................................................................................................................................23
New Features in this Release ...........................................................................................................................28
Security Services ................................................................................................................................................32
Protocols Supported..........................................................................................................................................32
Supported Browsers..........................................................................................................................................33
Upgrade and Upgrade Enhancements...........................................................................................................33
Where to Go From Here ...................................................................................................................................33
About the Document Organization ................................................................................................................39
Related Blue Coat Documentation..................................................................................................................41
Document Conventions....................................................................................................................................42
Chapter 2: Licensing
About Licensing.................................................................................................................................................43
Licensable Components....................................................................................................................................43
About the Trial Period ......................................................................................................................................44
About License Expiration.................................................................................................................................45
Obtaining a WebPower Account.....................................................................................................................46
Registering the Hardware ................................................................................................................................46
Installing a License Key File ............................................................................................................................48
Viewing License Information ..........................................................................................................................51
Updating a License............................................................................................................................................53
Automatically Updating a License .................................................................................................................53
Chapter 3: Accessing the ProxySG
Before You Begin: Understanding Modes .....................................................................................................55
Accessing the ProxySG .....................................................................................................................................56
Accessing the Management Console Home Page ........................................................................................57
Changing the Logon Parameters.....................................................................................................................59
Configuring the SSH Console..........................................................................................................................63
Chapter 4: Configuring the System
Section A: Global Configurations
Configuring the ProxySG Name .....................................................................................................................70
Configuring the Serial Number.......................................................................................................................71
Configuring the System Time..........................................................................................................................71

ix

Blue Coat ProxySG Configuration and Management Guide

Network Time Protocol.................................................................................................................................... 73
Configuring HTTP Timeout ............................................................................................................................ 75
Section B: Archive Configuration
Sharing Configurations .................................................................................................................................... 76
Archiving a Configuration............................................................................................................................... 79
Troubleshooting ................................................................................................................................................ 81
Section C: Adapters
About Adapters ................................................................................................................................................. 83
Network Interface States .................................................................................................................................. 83
Configuring an Adapter................................................................................................................................... 83
About the Settings Button................................................................................................................................ 85
Detecting Network Adapter Faults ................................................................................................................ 86
Section D: Software and Hardware Bridges
About Bridging.................................................................................................................................................. 88
About the Pass-Through Adapter .................................................................................................................. 88
ProxySG Prerequisites ...................................................................................................................................... 89
Setting Bandwidth Management for Bridging ............................................................................................. 89
Configuring a Software Bridge ....................................................................................................................... 90
Configuring Failover ........................................................................................................................................ 93
Static Forwarding Table Entries...................................................................................................................... 93
Section E: Gateways
About Gateways................................................................................................................................................ 95
ProxySG Specifics.............................................................................................................................................. 95
Switching to a Secondary Gateway ................................................................................................................ 96
Defining Static Routes ...................................................................................................................................... 97
Section F: Using RIP
Installing RIP Configuration Files ................................................................................................................ 102
Configuring Advertising Default Routes .................................................................................................... 105
Section G: DNS Servers
ProxySG Specifics............................................................................................................................................ 107
Configuring Split DNS Support.................................................................................................................... 108
Changing the Order of DNS Servers............................................................................................................ 109
Unresolved Host Names (Name Imputing)................................................................................................ 110
Changing the Order of DNS Name Imputing Suffixes ............................................................................. 110
Caching Negative Responses ........................................................................................................................ 111
Section H: Attack Detection
Configuring Attack-Detection Mode for the Client ................................................................................... 112
Configuring Attack-Detection Mode for a Server or Server Group ........................................................ 116
Section I: Using a Bypass List
Using the Local Bypass List........................................................................................................................... 118
Using the Central Bypass List ....................................................................................................................... 119

x

Contents

Creating and Installing Local or Central Bypass Lists............................................................................... 119
Using Policy to Configure Dynamic Bypass Lists...................................................................................... 123
Section J: Installing WCCP Settings
Section K: Virtual IP Addresses
Section L: Configuring Failover
About Failover................................................................................................................................................. 134
Configuring Failover ...................................................................................................................................... 135
Viewing Statistics ............................................................................................................................................ 138
Section M: TCP/IP Configuration
RFC-1323........................................................................................................................................................... 139
TCP NewReno ................................................................................................................................................. 140
ICMP Broadcast Echo Support...................................................................................................................... 140
ICMP Timestamp Echo Support ................................................................................................................... 140
TCP Window Size ........................................................................................................................................... 140
PMTU Discovery ............................................................................................................................................. 141
TCP Time Wait ................................................................................................................................................ 142
Viewing the TCP/IP Configuration ............................................................................................................. 142
Chapter 5: Managing Port Services
Section A: Managing Multiple Management Consoles
Managing the HTTPS Console (Secure Console) ....................................................................................... 144
Managing the HTTP Console ........................................................................................................................ 147
Managing the SSH Console ........................................................................................................................... 148
Managing the Telnet Console........................................................................................................................ 149
Section B: Creating and Editing Services
About Service Attributes................................................................................................................................ 153
Managing the DNS-Proxy.............................................................................................................................. 154
Managing the Endpoint Mapper Proxy....................................................................................................... 157
Managing the FTP Service ............................................................................................................................. 158
Managing HTTP Services .............................................................................................................................. 160
Managing the HTTPS Service........................................................................................................................ 161
Managing Instant Messaging Protocols....................................................................................................... 164
Managing Streaming Protocols ..................................................................................................................... 165
Managing SOCKS Services ............................................................................................................................ 166
Managing TCP Tunneling Services .............................................................................................................. 167
Managing the Telnet Shell Proxy Service .................................................................................................... 169
Chapter 6: Configuring Proxies
About Explicit and Transparent Proxy ........................................................................................................ 173
Section A: Configuring Explicit Proxies
Creating an Explicit Proxy Server................................................................................................................. 175
Configuring the FTP Proxy............................................................................................................................ 176
Configuring FTP Connection Welcome Banners........................................................................................ 182

xi

Blue Coat ProxySG Configuration and Management Guide

Managing HTTP Proxy .................................................................................................................................. 183
Understanding HTTP Terms ......................................................................................................................... 185
Configuring Refresh Bandwidth for the HTTP Proxy............................................................................... 186
Setting Default HTTP Proxy Policy .............................................................................................................. 188
Choosing the HTTP Proxy Profile ................................................................................................................ 192
Configuring HTTP for Bandwidth Gain...................................................................................................... 199
Viewing HTTP Settings through the CLI .................................................................................................... 201
Understanding HTTP Compression............................................................................................................. 202
Troubleshooting HTTP Proxy Issues ........................................................................................................... 210
Configuring a SOCKS Proxy ......................................................................................................................... 213
Understanding Shell Proxies ......................................................................................................................... 217
Section B: Transparent Proxies
Configuring the Transparent Proxy Hardware .......................................................................................... 224
Understanding IP Forwarding...................................................................................................................... 226
Creating a Transparent Proxy Service ......................................................................................................... 226
Chapter 7: Using Secure Services
Section A: HTTPS Termination Overview
Public Keys and Private Keys........................................................................................................................ 230
Certificates........................................................................................................................................................ 230
Keyrings............................................................................................................................................................ 231
Cipher Suites Supported by SGOS ............................................................................................................... 232
Server Gated Cryptography and International Step-Up ........................................................................... 233
Understanding SSL Client ............................................................................................................................. 233
Section B: Configuring HTTPS Termination
Creating a Keyring .......................................................................................................................................... 235
Deleting an Existing Keyring and Certificate ............................................................................................. 239
Managing Certificate Signing Requests....................................................................................................... 239
Managing Server (SSL) Certificates.............................................................................................................. 243
Troubleshooting Certificate Problems ......................................................................................................... 249
Section C: Managing the SSL Client
Creating an SSL Client.................................................................................................................................... 250
Associating a Keyring and Protocol with the SSL Client .......................................................................... 251
Setting the SSL Negotiation Timeout ........................................................................................................... 255
Section D: Configuring HTTP or HTTPS Origination to the Origin Content Server
Creating Policy for HTTP and HTTPS Origination ................................................................................... 258
Section E: Advanced Configuration
Importing an Existing Keypair and Certificate........................................................................................... 259
About Certificate Chains................................................................................................................................ 261
Importing a CA Certificate ............................................................................................................................ 262
Creating CA Certificate Lists......................................................................................................................... 265

xii

Contents

Chapter 8: Security and Authentication
Section A: Controlling Access to the ProxySG
Limiting Access to the ProxySG Appliance ................................................................................................ 271
About Password Security............................................................................................................................... 272
Limiting User Access to the ProxySG—Overview..................................................................................... 273
Moderate Security: Restricting Management Console Access Through the Console Access Control List
(ACL) ........................................................................................................................................................ 275
Maximum Security: Administrative Authentication and Authorization Policy ................................... 277
Section B: Controlling Access to the Internet and Intranet
Using Authentication and Proxies................................................................................................................ 283
Using SSL with Authentication and Authorization Services ................................................................... 289
Creating a Proxy Layer to Manage Proxy Operations............................................................................... 289
Chapter 9: Using Authentication Services
Understanding Realms................................................................................................................................... 299
SSL Between the ProxySG and the Authentication Server ....................................................................... 299
Section A: NTLM Realm Authentication and Authorization
How Blue Coat Works with NTLM.............................................................................................................. 301
Creating an NTLM Realm ............................................................................................................................. 301
NTLM Servers.................................................................................................................................................. 302
Defining NTLM Realm General Properties................................................................................................. 304
Creating the CPL ............................................................................................................................................. 306
Tips and Boundary Conditions..................................................................................................................... 306
Section B: LDAP Realm Authentication and Authorization
Overview .......................................................................................................................................................... 308
Creating an LDAP Realm .............................................................................................................................. 309
LDAP Servers .................................................................................................................................................. 311
Defining LDAP Base Distinguished Names ............................................................................................... 314
LDAP Search & Groups Tab (Authorization and Group Information) .................................................. 318
Customizing LDAP Objectclass Attribute Values...................................................................................... 321
Defining LDAP General Realm Properties.................................................................................................. 322
Creating the CPL ............................................................................................................................................. 324
Section C: RADIUS Realm Authentication and Authorization
Creating a RADIUS Realm............................................................................................................................. 326
Defining RADIUS Realm Properties ............................................................................................................ 327
Defining RADIUS Realm General Properties ............................................................................................. 329
Creating the CPL ............................................................................................................................................. 332
Configuring the ProxySG as a Session Monitor ......................................................................................... 333
Creating the CPL ............................................................................................................................................. 337
Section D: Local Realm Authentication and Authorization
Creating a Local Realm .................................................................................................................................. 338
Changing Local Realm Properties ................................................................................................................ 339

xiii

Blue Coat ProxySG Configuration and Management Guide

Defining the Local User List .......................................................................................................................... 342
Creating the CPL ............................................................................................................................................. 348
Section E: Certificate Realm Authentication
How Certificate Realm Works ...................................................................................................................... 350
Creating a Certificate Realm.......................................................................................................................... 351
Defining a Certificate Realm ......................................................................................................................... 352
Defining Certificate Realm General Properties .......................................................................................... 353
Revoking User Certificates ............................................................................................................................ 355
Creating the Certificate Authorization Policy ............................................................................................ 356
Tips.................................................................................................................................................................... 357
Section F: Netegrity SiteMinder
Understanding SiteMinder Interaction with Blue Coat ............................................................................ 358
Participating in a Single Sign-On (SSO) Scheme ........................................................................................ 360
Creating a SiteMinder Realm ....................................................................................................................... 361
Configuring SiteMinder Servers ................................................................................................................... 365
Defining SiteMinder Server General Properties......................................................................................... 368
Creating the CPL ............................................................................................................................................. 372
Section G: Oblix COREid
Understanding COREid Interaction with Blue Coat ................................................................................. 374
Configuring the COREid Access System..................................................................................................... 374
Additional COREid Configuration Notes ................................................................................................... 375
Configuring the ProxySG Realm .................................................................................................................. 375
Participating in a Single Sign-On (SSO) Scheme ........................................................................................ 376
Creating a COREid Realm ............................................................................................................................. 377
Configuring Agents ........................................................................................................................................ 378
Configuring the COREid Access Server ...................................................................................................... 380
Configuring the General COREid Settings.................................................................................................. 383
Creating the CPL ............................................................................................................................................. 384
Section H: Policy Substitution Realm
How Policy Substitution Realms Work ....................................................................................................... 386
Creating a Policy Substitution Realm .......................................................................................................... 388
Defining a Policy Substitution Realm .......................................................................................................... 389
Defining Policy Substitution Realm General Properties ........................................................................... 391
Tips and Boundary Conditions..................................................................................................................... 392
Creating the Policy Substitution Policy ....................................................................................................... 393
Section I: Sequence Realm Authentication
Adding Realms to a Sequence Realm........................................................................................................... 395
Creating a Sequence Realm ........................................................................................................................... 395
Adding Realms to a Sequence Realm........................................................................................................... 396
Defining Sequence Realm General Properties ........................................................................................... 398
Tips.................................................................................................................................................................... 400
Section J: Forms-Based Authentication
Understanding Authentication Forms......................................................................................................... 401

xiv

Contents

Creating and Editing an Authentication Form ........................................................................................... 403
Setting Storage Options.................................................................................................................................. 407
Using CPL with Forms-Based Authentication............................................................................................ 409
Tips and Boundary Conditions..................................................................................................................... 410
Section K: Managing the Credential Cache
Limitations ....................................................................................................................................................... 412
Chapter 10: Bandwidth Management
Bandwidth Management Terms ................................................................................................................... 413
Bandwidth Management Overview............................................................................................................. 414
Configuring Bandwidth Allocation.............................................................................................................. 419
Using Policy to Manage Bandwidth............................................................................................................. 425
Chapter 11: External Services
Section A: ICAP
Supported ICAP Servers ................................................................................................................................ 438
ICAP v1.0 Features.......................................................................................................................................... 438
About Content Scanning ................................................................................................................................ 439
Installing the ICAP Server ............................................................................................................................. 441
Creating an ICAP Service .............................................................................................................................. 441
Deleting an ICAP Service............................................................................................................................... 446
Customizing ICAP Patience Text ................................................................................................................. 446
Creating ICAP Policy...................................................................................................................................... 451
Managing Virus Scanning.............................................................................................................................. 457
Access Logging................................................................................................................................................ 458
References......................................................................................................................................................... 459
Section B: Websense
Creating a Websense Service......................................................................................................................... 460
Deleting a Websense Service ......................................................................................................................... 462
Section C: Service Groups
Creating a Service Group............................................................................................................................... 464
Deleting a Service Group or Group Entry................................................................................................... 466
About Weighted Load Balancing.................................................................................................................. 466
Section D: Displaying External Service and Group Information
Chapter 12: Health Checks
About General Health Checks....................................................................................................................... 471
Configuring Service-Specific Health Checks .............................................................................................. 472
About Global Forwarding and SOCKS Gateway Health Checks ............................................................ 475
Configuring Global Health Checks .............................................................................................................. 476
Pausing or Resuming Global Health Checking .......................................................................................... 477
Chapter 13: Managing Policy Files
About Policy Files ........................................................................................................................................... 479

xv

Blue Coat ProxySG Configuration and Management Guide

Creating and Editing Policy Files ................................................................................................................. 482
Managing the Central Policy File ................................................................................................................. 487
Viewing Policy Files ....................................................................................................................................... 489
Chapter 14: The Visual Policy Manager
Section A: About the Visual Policy Manager
System Requirements ..................................................................................................................................... 495
Launching the Visual Policy Manager ......................................................................................................... 496
About the Visual Policy Manager User Interface ....................................................................................... 497
About VPM Components............................................................................................................................... 500
The Set Object Dialog ..................................................................................................................................... 502
The Add/Edit Object Dialog ......................................................................................................................... 504
Online Help...................................................................................................................................................... 504
Section B: Policy Layer and Rule Object Reference
About the Reference Tables ........................................................................................................................... 506
Administration Authentication Policy Layer Reference ........................................................................... 506
Administration Access Policy Layer Reference.......................................................................................... 506
DNS Access Policy Layer Reference............................................................................................................. 507
SOCKS Authentication Policy Layer Reference ......................................................................................... 507
Web Authentication Policy Layer Reference .............................................................................................. 508
Web Access Policy Layer Reference ............................................................................................................. 508
Web Content Policy Layer Reference........................................................................................................... 511
Forwarding Policy Layer Reference ............................................................................................................. 512
Section C: Detailed Object Column Reference
Source Column Object Reference.................................................................................................................. 514
Destination Column Object Reference ......................................................................................................... 526
Service Column Object Reference................................................................................................................. 532
Time Column Object Reference .................................................................................................................... 537
Action Column Object Reference.................................................................................................................. 539
Track Object Column Reference ................................................................................................................... 567
Comment Object Reference ........................................................................................................................... 570
Using Combined Objects ............................................................................................................................... 570
Centralized Object Viewing and Managing................................................................................................ 573
Creating Categories ........................................................................................................................................ 575
Restricting DNS Lookups .............................................................................................................................. 577
Restricting Reverse DNS Lookups ............................................................................................................... 578
Setting the Group Log Order......................................................................................................................... 578
Section D: Managing Policy Layers and Files
How Policy Layers, Rules, and Files Interact.............................................................................................. 581
Installing Policies ............................................................................................................................................ 583
Managing Policy Files .................................................................................................................................... 584
Installing VPM-Created Policy Files ............................................................................................................ 585
Viewing the Policy/Created CPL ................................................................................................................. 587

xvi

Contents

Section E: Tutorials
Tutorial—Creating a Web Authentication Policy ...................................................................................... 590
Tutorial—Creating a Web Access Policy ..................................................................................................... 595
Chapter 15: Advanced Policy
Section A: Blocking Pop Up Windows
About Pop Up Blocking ................................................................................................................................. 604
Limitations ....................................................................................................................................................... 604
Recommendations........................................................................................................................................... 604
Section B: Stripping or Replacing Active Content
About Active Content..................................................................................................................................... 606
About Active Content Types ......................................................................................................................... 606
Section C: Modifying Headers
Section D: Defining Exceptions
Built-in Exceptions .......................................................................................................................................... 610
User-Defined Exceptions ............................................................................................................................... 614
About Exception Definitions ......................................................................................................................... 614
About the Exceptions Hierarchy................................................................................................................... 616
About the Exceptions Installable List........................................................................................................... 616
Creating or Editing Exceptions ..................................................................................................................... 618
Viewing Exceptions ........................................................................................................................................ 621
Section E: Managing Peer-to-Peer Services
About Peer-to-Peer Communications .......................................................................................................... 623
The Blue Coat Solution................................................................................................................................... 623
Policy Control .................................................................................................................................................. 624
Proxy Authentication ..................................................................................................................................... 625
Access Logging................................................................................................................................................ 625
Chapter 16: Streaming Media
Section A: About Streaming Media
Streaming Media Overview........................................................................................................................... 628
Streaming Media Protocols............................................................................................................................ 629
Streaming Media Player Support ................................................................................................................. 631
Streaming Media Authentication ................................................................................................................. 632
Streaming Media Caching Behavior............................................................................................................. 634
Section B: Configuring Streaming Media
Limiting Bandwidth ....................................................................................................................................... 637
Configuring the Refresh Rate ........................................................................................................................ 642
Configuring HTTP Handoff .......................................................................................................................... 642
Forwarding Client Logs to the Media Server.............................................................................................. 643
Configuring Media Server Authentication Type (Windows Media) ...................................................... 644
About Multicast Streaming............................................................................................................................ 644
Managing Multicast Streaming for Windows Media ................................................................................ 646

xvii

Blue Coat ProxySG Configuration and Management Guide

Managing Multicast Streaming for Real Media.......................................................................................... 649
Managing Simulated Live Content (Windows Media) ............................................................................. 650
ASX Rewriting (Windows Media)................................................................................................................ 652
About Fast Streaming (Windows Media).................................................................................................... 655
Section C: Windows Media Player
Configuring Windows Media Player ........................................................................................................... 656
Limitations ....................................................................................................................................................... 657
Windows Media Access Log Formats.......................................................................................................... 658
Section D: RealPlayer
Configuring RealPlayer.................................................................................................................................. 659
Real Media Access Log Formats ................................................................................................................... 661
Limitations and Known Issues...................................................................................................................... 661
Section E: QuickTime Player
Configuring QuickTime Player..................................................................................................................... 662
QuickTime Access Log Formats ................................................................................................................... 662
Limitations ....................................................................................................................................................... 662
Access Log Format .......................................................................................................................................... 663
Chapter 17: Instant Messaging
About Securing Instant Messaging............................................................................................................... 665
Recommended Deployments ........................................................................................................................ 665
About the Instant Messaging Protocol Services ......................................................................................... 665
About HTTP Proxy Support.......................................................................................................................... 666
About Instant Messaging Reflection ............................................................................................................ 666
IM Reflection Diagrams ................................................................................................................................. 666
About Instant Messaging Proxy Authentication ........................................................................................ 670
Securing AOL Encryption Capability .......................................................................................................... 670
Instant Message Proxies ................................................................................................................................. 671
Configuring Instant Messenger Clients ....................................................................................................... 674
VPM Examples ................................................................................................................................................ 677
Statistics ............................................................................................................................................................ 678
Related Material .............................................................................................................................................. 678
Chapter 18: Content Filtering
Overview .......................................................................................................................................................... 679
Selecting Category Providers ........................................................................................................................ 680
Configuring a Local Database ....................................................................................................................... 684
Configuring Blue Coat Web Filter ............................................................................................................... 689
Configuring i-FILTER..................................................................................................................................... 697
Configuring InterSafe ..................................................................................................................................... 700
Configuring Optenet ...................................................................................................................................... 703
Configuring Proventia Web Filter ................................................................................................................ 706
Configuring SmartFilter ................................................................................................................................. 709
Configuring SurfControl................................................................................................................................ 716
Configuring Websense ................................................................................................................................... 719

xviii

Contents

Configuring Webwasher URL Filter ............................................................................................................ 725
Scheduling Automatic Downloads for Third-Party Vendors................................................................... 728
How to Apply Policy to Categorized URLs ................................................................................................ 729
Using Content-Filtering Vendors with ProxySG Policies ......................................................................... 732
Tips.................................................................................................................................................................... 735
Chapter 19: Configuring the Upstream Networking Environment
Understanding Forwarding........................................................................................................................... 737
Understanding Forwarding Terminology................................................................................................... 739
Configuring Forwarding................................................................................................................................ 740
Using Forward Directives and Installable Lists ......................................................................................... 751
SOCKS Gateway Configuration.................................................................................................................... 757
Internet Caching Protocol (ICP) Configuration.......................................................................................... 765
Using Policy to Manage Forwarding ........................................................................................................... 771
Chapter 20: Access Logging
Section A: Overview
Understanding Facilities ................................................................................................................................ 778
Understanding Protocols and Formats ........................................................................................................ 779
Understanding Access Logging Terms........................................................................................................ 780
Enabling or Disabling Access Logging ........................................................................................................ 781
Section B: Creating and Editing Log Formats
Creating a Custom or ELFF Log Format ..................................................................................................... 783
Section C: Creating an Access Log Facility
Section D: Editing an Existing Log Facility
Section E: Associating a Log Facility with a Protocol
Disabling Access Logging for a Particular Protocol .................................................................................. 795
Section F: Configuring Global Settings
Section G: Configuring the Upload Client
Encrypting the Access Log ............................................................................................................................ 799
Importing an External Certificate ................................................................................................................. 799
Digitally Signing Access Logs ....................................................................................................................... 801
Disabling Log Uploads................................................................................................................................... 805
Decrypting an Encrypted Access Log .......................................................................................................... 805
Verifying a Digital Signature......................................................................................................................... 806
Editing Upload Clients................................................................................................................................... 806
Section H: Configuring the Upload Schedule
Testing Access Log Uploading...................................................................................................................... 822
Viewing Access-Log Statistics ....................................................................................................................... 824
Using Access Logging with Policy Rules .................................................................................................... 824
Example: Using VPM to Prevent Entries Matching a Source IP Address from Being Logged ........... 824

xix

Blue Coat ProxySG Configuration and Management Guide

Chapter 21: Maintaining the ProxySG
Restarting the ProxySG .................................................................................................................................. 829
Restoring System Defaults............................................................................................................................. 831
Purging the DNS Cache ................................................................................................................................. 834
Clearing the System Cache ............................................................................................................................ 834
Upgrading the ProxySG ................................................................................................................................. 835
Managing ProxySG Systems ......................................................................................................................... 838
Event Logging and Notification.................................................................................................................... 842
Configuring SNMP ......................................................................................................................................... 848
Disk Reinitialization ....................................................................................................................................... 852
Deleting Objects from the ProxySG.............................................................................................................. 853
Chapter 22: Statistics
Selecting the Graph Scale............................................................................................................................... 855
General Statistics ............................................................................................................................................. 855
System Usage Statistics .................................................................................................................................. 860
HTTP/FTP History Statistics ........................................................................................................................ 864
IM History Statistics ....................................................................................................................................... 868
P2P History Statistics...................................................................................................................................... 870
Streaming History Statistics .......................................................................................................................... 873
SOCKS History Statistics................................................................................................................................ 877
Shell History Statistics .................................................................................................................................... 880
Resources Statistics ......................................................................................................................................... 880
Efficiency Statistics.......................................................................................................................................... 883
Contents Statistics ........................................................................................................................................... 887
Event Logging.................................................................................................................................................. 888
Bandwidth Management Statistics ............................................................................................................... 889
Access-Log Statistics ....................................................................................................................................... 893
Failover Statistics............................................................................................................................................. 897
Advanced Statistics......................................................................................................................................... 898
Appendix A: Using the Authentication/Authorization Agent
Installing the BCAAA Service on a Windows or Windows NT System................................................. 902
Installing the BCAAA Service on a Solaris System.................................................................................... 909
Troubleshooting Authentication Agent Problems ..................................................................................... 910
Common BCAAA Event Messages .............................................................................................................. 910
Appendix B: Access Log Formats
Custom or W3C ELFF Format....................................................................................................................... 919
SQUID-Compatible Format ........................................................................................................................... 922
NCSA Common Access Log Format ............................................................................................................ 924
Fields Available for Creating Access Log Formats .................................................................................... 926
Appendix C: Using WCCP
Overview .......................................................................................................................................................... 957

xx

Contents

Quick Start........................................................................................................................................................ 959
Configuring a WCCP Version 2 Service on the Router ............................................................................. 960
Creating a ProxySG WCCP Configuration File .......................................................................................... 967
Examples .......................................................................................................................................................... 975
Troubleshooting: Home Router .................................................................................................................... 979
Tips.................................................................................................................................................................... 983
Appendix D: RIP Commands
net ...................................................................................................................................................................... 985
host .................................................................................................................................................................... 985
RIP Parameters ................................................................................................................................................ 986
ProxySG-Specific RIP Parameters................................................................................................................. 987
Using Passwords with RIP ............................................................................................................................ 988
Appendix E: Diagnostics
Diagnostic Reporting (Service Information) ............................................................................................... 990
Packet Capturing (the PCAP Utility) ........................................................................................................... 998
Core Image Restart Options ........................................................................................................................ 1004
Diagnostic Reporting (Heartbeats) ............................................................................................................. 1005
Diagnostic Reporting (CPU Monitoring)................................................................................................... 1007
Appendix F: Using Blue Coat Director to Manage Multiple Appliances
How Director Works with ProxySG .......................................................................................................... 1009
Backing Up a ProxySG’s SSL Settings........................................................................................................ 1013
Creating Profiles............................................................................................................................................ 1013
Creating Overlays ......................................................................................................................................... 1014
Director Documentation .............................................................................................................................. 1014
Index

xxi

Blue Coat ProxySG Configuration and Management Guide

xxii

Chapter 1: Introducing the ProxySG

Blue Coat® Systems ProxySG™ Appliance represents the latest in perimeter defense for securing and
controlling Web-based content and applications. The Blue Coat ProxySG is designed to integrate
protection and control functions for Internet and intranet traffic without sacrificing performance and
employee productivity.
The ProxySG series of proxy appliances is designed specifically to manage and control user
communication over the Internet. Acting on behalf of the user and the application, the ProxySG does
not replace existing perimeter security devices; rather, it complements them by giving organizations
the ability to control communications in a number of ways that firewalls and other externally focused
devices cannot.

Web Security Solution
The Blue Coat ProxySG provides a point of integration, control, and acceleration for enterprise Web
security applications, including:


Layered security approach with content-level protection to combat Web-based threats using port
80.



Abundant policy controls wrapped in performance-based hardware and a custom operating
system to give organizations visibility and control over employee Web communications.



A preventative spyware defense that combines multiple techniques in a high-performance
solution acceptable for Web-based business communications.



Integrated reverse proxy caching and SSL support to offload content delivery and encryption
tasks from Web servers, reducing server bottlenecks and enhancing Web site performance and
scalability.



Control over which users are allowed to use Instant Messaging, and which IM protocols are
allowed, what features are to be enabled, to whom users can IM or chat with (inside the company
or outside the company), what time of the day they can IM, and how logging is managed.



Immediate and dynamic Peer-to-Peer (P2P) control, allowing an administrator to identify, log, and
block P2P traffic.



Integrated caching, content positioning, bandwidth savings, and bandwidth management to
provide superior performance for controlling Web content.



Control over Windows Media, RealTime, and QuickTime video and audio streams as the file is
being downloaded over the Internet.



Prevention of the spread of viruses and other malicious code by using the Blue Coat ProxyAV™
Appliance in conjunction with the Blue Coat ProxySG. The ProxySG with ProxyAV integration is a
high-performance Web anti-virus (AV) solution.

23

Blue Coat ProxySG Configuration and Management Guide



Control over the type of content retrieved by the ProxySG. You can also filter requests made by
clients. If you use Blue Coat Web Filter (BCWF), a highly effective content filtering service that
quickly learns and adapts to the working set of its users, you can also use a network service that
dynamically examines and categorizes Web pages as they are requested.

Ease of Deployment
The ProxySG is specifically designed to increase security and reduce costs associated with central,
regional, and branch office Web protection. For example, the SG200 and SG400 platforms easily drop in
to remote environments where technical support staff is not always available, and features simple
installation and remote management.
Other platforms also feature a simple-to-manage system that installs in minutes with little ongoing
maintenance. In addition, they also provide configuration restoration that allows system
configuration to be archived, including all system settings, filtering and policies; removable,
hot-swappable disk drives for true fault tolerance, and are field serviceable and upgradeable.

Policy and Management Architecture
Networking environments have become increasingly complex, with a variety of security and access
management issues. Enterprises face challenges in configuring products and ensuring the result
supports enterprise policies. Policies enhance ProxySG features, such as authentication and virus
scanning, allowing you to manage Web access specific to the enterprise’s needs.
Blue Coat policies provide:


Fine-grained control over various aspects of ProxySG behavior.



Multiple policy decisions for each request.



Multiple actions triggered by a particular condition.



Bandwidth limits.



Authentication awareness, including user and group configuration.



Flexibility of user-defined conditions and actions.



Convenience of predefined common actions and transformations.



Support for multiple authentication realms.



Configurable policy event logging.



Built-in debugging.

The ProxySG uses policies and system configuration together to provide the best possible security for
your network environment.
Blue Coat's unique architecture allows for scalable decision making. Effectively turning on multiple
combinations of granular policy requires a unique level of performance.
Blue Coat's flexible logging features, coupled with integrated authentication and identification
capabilities, give organizations the power to monitor Web access for every user in the network at any
time, regardless of where they are. Internet access traffic flowing through the ProxySG gives
administrators and managers the ability to audit Web traffic as needed.

24

Chapter 1: Introducing the ProxySG

Content Filtering
As the number of users and the total amount of traffic grows, policy enforcement demands higher
performance to provide adequate end-user quality of experience. To satisfy the management level and
scalability that enterprise traffic demands, ProxySG Appliances have emerged as a new layer of
infrastructure that provide the performance and manageability required for enterprise-wide
policy-based content filtering.
SGOS 4.1offers a dynamic categorization service if you use the Blue Coat Web Filter (BCWF). The
BCWF categorization service is an Internet service, available from designated service points with
high-bandwidth connections and dedicated hardware. It analyzes data externally so that content
(offensive, distasteful, or perhaps even potentially a legal liability) never enters the network.

Figure 1-1: Content Filtering

The ProxySG enforces Internet access policies based on:


Content categories (gambling, sex, etc.)— Besides BCWF, which includes a database and a
dynamic categorization service, databases from leading third-party filtering vendors are offered.



Content type and protocols (HTTP, FTP, streaming, MIME type, etc.)—Adds the ability to block
certain types of content transported on certain types of protocols.



Identity (user, group, network)—Customize policy based on who the users are regardless of
location.



Network conditions—Customize based on real-time conditions.

Content and Virus Scanning
When integrated with a supported Internet Content Adaptation Protocol (ICAP) server such as the
Blue Coat ProxyAV appliance, Blue Coat provides content scanning and filtering. ICAP is an evolving
protocol that allows an enterprise to dynamically scan and change Web content. Content scanning
includes actions like sending a given request for content to an ICAP server for virus scanning or
malicious mobile code detection.
To eliminate threats to the network and to maintain caching performance, the ProxySG sends objects
to the integrated ICAP server for evaluation and saves the scanned objects in its object store. With
subsequent content requests, the ProxySG serves the scanned object rather than rescanning the same
object for each request.

25

Blue Coat ProxySG Configuration and Management Guide

Figure 1-2: Content and Virus Scanning

The ProxySG blocks viruses from Web content behind and in front of the firewall. Blue Coat
architecture is optimized to handle Web requests and responses that require scanning for potentially
malicious mobile code and viruses. The ProxySG uses ICAP to vector responses to supported virus
scanning servers to deliver unmatched flexibility and performance in scanning Web content.

Spyware
Spyware leverages multiple vectors, making silver bullet defenses using coarse-grained controls
useless and unproductive and impeding critical Web-based business communications. No single
technique can filter out spyware and adware to defend against the threat.
Blue Coat combines multiple techniques in a high-performance solution acceptable for Web-based
business communications. Latency is minimal and the protection layers are comprehensive to stop,
block, and scan spyware. With Blue Coat, you can:


stop spyware installations;



block spyware Web sites;



scan for spyware signatures;



detect desktop spyware and target for cleanup.

Figure 1-3: Preventing Spyware

For information on using the ProxySG and ProxyAV together, refer to the Blue Coat ProxyAV
Configuration and Management Guide.

26

Chapter 1: Introducing the ProxySG

Instant Messaging
Instant Message (IM) usage in an enterprise environment creates security concerns because, regardless
of how network security is configured, IM connections can be made from any established protocol,
such as HTTP or SOCKS, on any open port. Because it is common for coworkers to use IM to
communicate, especially in remote offices, classified company information can be exposed outside the
network. Viruses and other malicious code can also be introduced to the network from file sharing
through IM clients.
The ProxySG serves as an IM proxy, both in transparent and explicit modes. You can control IM
actions by allowing or denying IM communications and file sharing based on users (both employee
identities and IM handles), groups, file types and names, and other triggers. You can also log and
archive all IM chats.
Using policy, administrators can quickly deploy sophisticated IM usage policies that integrate with
existing authentication directories through LDAP, NTLM and Radius.

Figure 1-4: Controlling Instant Messaging

Peer-to-Peer
The very nature of the Peer-to-Peer (P2P) client architecture is to evade firewalls and general network
security. Additionally, blocking a P2P client at the firewall has proved to be extremely difficult
because:


port blocking, as a means to controlling P2P, is very limited.



P2P packets cannot be classified simply by looking at packet headers such as an IP address and
port number.

Blue Coat ProxySG Appliances provide a powerful platform for immediate and dynamic P2P control.

Integrated Reverse Proxy
ProxySG Appliances are easily configured for reverse proxy mode, providing optimized Web server
acceleration and featuring a high RAM-to-disk ratio and a built-in Secure Sockets Layer (SSL)
encryption/decryption processor. This processor can manage 10 to 40 times more secure sessions than
a standard Web server, allowing the appliances to accelerate the delivery of both public (HTTP) and
private (HTTPS) content. The product is packaged in a compact 1U form factor (ProxySG 400 and
ProxySG 800 models) a major advantage in space-constrained data centers, or a 4U form factor
(ProxySG 8000) that allows for modular expansion of network interface cards, SSL cards, processors,
and RAM.

27

Blue Coat ProxySG Configuration and Management Guide

The ProxySG system software is easily tuned for the workload of high traffic Web sites. This
environment is characterized by a finite amount of site content accessed by many remote users, often
resulting in flash crowds. The ProxySG Appliances allow efficient scaling of Web farms to address
flash or peak periods of traffic, and includes advanced features such as protection against
Denial-of-Service attacks and dynamic content acceleration.

Bandwidth Management
Bandwidth management 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. Network
resource sharing (or link sharing) is accomplished using a bandwidth-management hierarchy where
multiple traffic classes share available bandwidth in a controlled manner.
You can also create policies to constrain who can use certain media types, and how much of it. For
example, you can allow your executives to view high-bandwidth streaming media, but only allow the
accounting group to view streams up to 56k on corporate sites.
With Blue Coat, you can limit access based on user, group, network address, and the time of day. You
can also prevent all access to the Internet except for a group of users who need access to do their jobs,
effectively freeing bandwidth for mission-critical needs.

New Features in this Release
Blue Coat has long been the leader in proxy appliances. For SGOS 4.1.x, Blue Coat built upon this
leadership by adding:


New Authentication Realms



Enhancements to Access Logging



Bandwidth Management



CPU Monitoring



HTTP Object Compression



SOCKS Compression and Endpoint Mapper proxy



Content Filtering vendors



Enhancements to the Blue Coat Patience Page



New policy to support new SGOS 4.x features

For information on each of these features, continue with the following sections.

28

Chapter 1: Introducing the ProxySG

New Authentication Realms
In 4.x, two new authentication realms are available, bringing the total to eleven:


Oblix COREid: With Oblix COREid (formerly NetPoint), the ProxySG acts as a custom
AccessGate. The ProxySG supports authentication with Oblix COREid v6.5 and v7.0.



Policy Substitution: A Policy Substitution realm provides a mechanism for identifying and
authorizing users based on information in the request to the ProxySG. The realm uses information
in the request and about the client to identify the user. The realm is configured to construct user
identity information by using policy substitutions.

For more information on these realms, see "Section G: Oblix COREid" on 374 and "Section H: Policy
Substitution Realm" on 386".

Access Logging
Access Logging has added several new features in SGOS 4.1.x:


A switch to enable or disable access logging on a global basis, both through the Management
Console (Access Logging>General>Global Settings) and the CLI.



A P2P format and log to support the new P2P functionality.



Signed access logs that certify that a specific ProxySG generated and uploaded a specific log file.



New substitutions to support SGOS 4.x functionality. (For more information on new substitutions,
refer to the Blue Coat SGOS 4.x Upgrade Guide.)

For information on access logging, see Chapter 20: “Access Logging” on page 777.

Bandwidth Management
Bandwidth Management is used to classify, control, and if required, limit the amount of bandwidth
used by a class (a unit of bandwidth allocation) of network traffic flowing in or flowing out of the
proxy. Network resource sharing (or link sharing) is accomplished in a hierarchical method where
multiple traffic classes share the available bandwidth in a controlled manner. The hierarchy specifies
how excess bandwidth is shared between the classes.
For more information on Bandwidth Gain Management, see Chapter 10: “Bandwidth Management”
on page 413.

29

Blue Coat ProxySG Configuration and Management Guide

Content Filtering
Blue Coat Web Filter (BCWF) is a highly effective content filter that can quickly learn and adapt to the
working set of its users. Also, BCWF provides a network service that can dynamically examine and
categorize Web pages as they are requested. This dynamic real-time categorization enhances both the
accuracy and freshness of the BCWF filtering solution.
You can evaluate BCWF free during the SG trial period (60 days). The evaluation is available to new
users of ProxySG as well as those upgrading from SGOS v3.x to SGOS v4.x.
For more information on BCWF, see"Configuring Blue Coat Web Filter" on page 689.
Also new in this release are three new third-party content filtering vendors—InterSafe, Optenet, and
Webwasher. For more information, see "Configuring InterSafe" on page 700, "Configuring Optenet" on
page 703, or "Configuring Webwasher URL Filter" on page 725.

CPU Monitoring
You can enable CPU monitoring to see the percentage of CPU being used by specific functional
groups. CPU monitoring is disabled by default.
You can also view CPU monitoring statistics through Statistics>Advanced>Diagnostics.
For more information, see "Diagnostic Reporting (CPU Monitoring)" on page 1007.

HTTP Object Compression
With compression, the HTTP proxy forwards the supported compression algorithm (either deflate or
gzip) from the client’s request (Accept-Encoding: request header) to the server as is, and attempts to
send compressed content to client whenever possible. This allows the ProxySG to send the response as
is when the server sends compressed data, including non-cacheable responses. Any unsolicited
encoded response is treated as an error.
Whether and where you use compression depends upon three resources: server-side bandwidth,
client-side bandwidth, and ProxySG CPU. If server-side bandwidth is more expensive in your
environment than CPU, always request compressed content from the OCS. However, if CPU is
comparatively expensive, configure the ProxySG to ask the OCS for the same compressions that the
client asked for and to forward whatever the server returns.
For more information on compression, see "Understanding HTTP Compression" on page 202.

SOCKS Compression and Endpoint Mapper Proxy
Compression over SOCKS is supported for TCP/IP tunnels, which can compress the data transferred
between the branch (downstream proxy) and main office (upstream proxy), reducing bandwidth
consumption and improving latency. For information on enabling SOCKS compression,
see"Understanding SOCKS Compression" on page 213.
To intercept Microsoft RPC traffic and create dynamic TCP tunnels, create an Endpoint Mapper proxy
at the remote office (the downstream proxy). Traffic to port 135 is transparently redirected to this
service using bridging or L4 switch or WCCP. For information on creating and enabling an Endpoint
Mapper proxy service, see "Managing the Endpoint Mapper Proxy" on page 157.

30

Chapter 1: Introducing the ProxySG

When configuration is complete, you can set policy to forward TCP traffic through a SOCKS gateway.
You can do this through the layer using either the VPM or CPL. For more information, see
"Using Policy to Control the SOCKS Proxy" on page 216.

Patience Page
The ProxySG allows you to customize the patience pages that are displayed when HTTP clients
experience delays as Web content is scanned.
In SGOS 4.1.x, patience page behavior has been modified to


Refresh every five seconds, using Javascript.



Update the status bar every second with patience page information.



Manage a popup blocker. If a popup blocker is active, the patience page initiates the download of
the scanned object when the root window gets the final patience page. The final patience page also
updates the status bar to indicate that the scan is complete.

For information on using patience pages, see Chapter 11: “External Services” on page 437.

Policy
A number of properties (actions) and conditions (source) have been added to support the new features
in SGOS 4.1.x. (For a complete list of new CPL and VPM objects, refer to the Blue Coat SGOS 4.x
Upgrade Guide.)

VPM Object Naming
Objects that can be named by the user no longer start with "_" (underscore character). The underscore
character is now used internally to prevent name collisions between objects that can be named by the
user and internally generated names.

Exception Pages
A number of built-in exception pages have been added to SGOS 4.1.x to send information back to the
user under operational contexts that are known to occur. New exception pages include:




HTML Notification


notify



notify_missing_cookie

HTTP Compression


transformation_error



unensupported_encoding

31

Blue Coat ProxySG Configuration and Management Guide

Documentation References


Chapter 14: “The Visual Policy Manager” on page 493



Chapter 13: “Managing Policy Files” on page 479



Blue Coat SGOS 4.x Upgrade Guide



Blue Coat ProxySG Content Policy Language Guide

Security Services
The Blue Coat ProxySG allows you to control content, instant messaging, and file sharing. In SGOS
4.x, Blue Coat has also added increased support for:


P2P



SSL Key Management

For information on each of these features, continue with the following sections.

P2P
The ProxySG recognizes P2P activity relating to P2P file sharing applications. By constructing policy,
you can control, block, and log P2P activity and limit the bandwidth consumed by P2P traffic.
For more information, see Chapter 15:"Section E: Managing Peer-to-Peer Services" on 623.

SSL Key Management
In this release, SSL key management has been extended to interact more efficiently with Blue Coat
Director.
Director allows you to configure a ProxySG and then push that configuration out to as many ProxySG
Appliances as you need. Director also allows you to delegate network and content control to multiple
administrators.
For information on using SSL key management with Director, refer to the Blue Coat Director
Configuration and Management Guide.

Protocols Supported
Blue Coat ProxySGs are multi-protocol. For administrative purposes, you can connect to the Blue Coat
ProxySG Appliances through the:


HTTPS-Console: This is the default protocol used by the Management Console. It is configured
and enabled by default.



SSH-Console: This is the default protocol for connecting to the ProxySG through the CLI. It is
configured and enabled by default.

If you prefer and are in a secure environment, you can use the HTTP-Console or Telnet-Console for
administrative access to the system.

32

Chapter 1: Introducing the ProxySG

Note:

HTTP-Console and Telnet-Console are security risks. They should not be used for
administrative access in insecure situations.

Supported Browsers
The ProxySG Management Console supports Microsoft® Internet Explorer 6, Netscape®
Communicator 7.2, and Firefox 1.0.
The Management Console uses the Java Runtime Environment. Because of security concerns, you
should use JRE 1.5.0 (also called J2SE 5.0) if you plan to access external Internet sites.

Upgrade and Upgrade Enhancements
For information on doing upgrades or downgrades, or for restoring default system settings, refer to
the Blue Coat SGOS 4.x Upgrade Guide.

Where to Go From Here
The following sections describe the top-level tasks you need to carry out to customize the ProxySG to
your environment. The tasks are shown in the order of a typical deployment:

Placing the ProxySG in a Network
To install a ProxySG into a network, the network must be set up to present the ProxySG with traffic to
control.


Explicit Proxy: All the ProxySG needs is IP address connectivity to the network; browsers must be
configured to point to the ProxySG through a PAC file.



Transparent Proxy: The majority of networks use transparent proxy. Transparent proxying occurs
when the ProxySG receives traffic destined for Origin Content Servers (OCS) and terminates the
traffic, then initiates the same request to the OCS.


Bridging: With this configuration, you do not have to make router or L4 switch configuration
changes. The ProxySG is placed inline on a segment of the network where all outgoing traffic
flows; one Ethernet interface is connected to the internal network, the other Ethernet interface
is connected to the Internet. The ProxySG terminates all traffic on the service ports in which
the proxy has been configured and sends the request to the outside OCS. All other traffic is
bridged between the two Ethernet interfaces.
Note that this configuration, without using policy controls, can lead to an open proxy. An open
proxy results when traffic is allowed on the outside (Internet) interface because users are
accessing internal Web servers behind the proxy.



WCCP: If the site has Cisco routers, WCCP can be used to direct certain TCP/IP connections
to the ProxySG. TCP/IP ports to forward to the ProxySG are communicated between ProxySG
appliances and the Cisco routers. Typically, this is enforced on the outgoing interface on the
Cisco router.

33

Blue Coat ProxySG Configuration and Management Guide



L4 switching: Similar to WCCP, the L4 switch is configured to forward traffic for specific
TCP/IP ports to the attached ProxySG.

Initial Setup
The ProxySG must be initially configured before it operates on a network. This can be done through
the front panel (if applicable) or the serial console. The initial setup sets not only the IP address, but
enable and console passwords. Once completed, the ProxySG can be managed through the serial
console, SSH, or HTTPS at port 8082. Information on setting up the ProxySG is in the Quick Start
Guide and Installation Guide for your platform.

Simple Policy
The default policy on new ProxySG appliances is to deny everything. To test initial setup, you can
create a policy of ALLOW, along with changing access logging to log to the default logs. If the
ProxySG is correctly set up, Web browsers can surf the Internet and all transactions are logged. Once
the ProxySG setup is verified, the policy should again be set to DENY, unless otherwise required.
If the policy is set to allow everything and a bridged configuration is used, clients can send a
connection request for any port, including e-mail, using the proxy to send spam. This is called an open
proxy and usually results in performance slowdowns (among other things).
To prevent the ProxySG from becoming an open proxy in a bridged configuration if you must use an
ALLOW configuration, add the following policy to the end of the local policy:
define subnet Trusted_Clients
10.0.0.0/8
end subnet
define subnet Trusted_Servers
216.52.23.0/24
end subnet

client.address = Trusted_Clients OK ; Policy below applies
proxy.address = Trusted_Servers OK ; Policy below applies
FORCE_DENY ; Force a denial for everything else

; Add other allow or deny rules here
; Example: Allow all traffic not denied above
ALLOW

Implementing Policies
Once the basic system is set up, you need to decide which controls—policies— to put in place.
Typically, the following are configured on the system:


34

Proxy caching (HTTP, FTP, Streaming)



Authentication/single sign-on



Access control policy



Content filtering

Chapter 1: Introducing the ProxySG



Web anti-virus

Implementing policies is a two-step process:


Configure the feature; for example, choose Blue Coat Web Filter or another content filtering
vendor, enable it, and schedule downloads of the database.



Create policy through the graphical Visual Policy Manager (VPM) or through the Content Policy
Language (CPL).

Managing the ProxySG
Once the configuration and policy on the ProxySG are set, you should know how to evaluate the
current operating state. This can include reviewing event log messages, utilizing SNMP, or diagnostics
such as CPU utilization.


Archive a configuration file: "Archiving a Configuration" on page 75



Upgrade the system: "Upgrading the ProxySG" on page 885



Set up event logging: "Event Logging and Notification" on page 892



Configure SNMP: "Configuring SNMP" on page 898



Understand Diagnostics: Appendix E: "Diagnostics" on page 1039

Managing the ProxyAV
The ProxySG with ProxyAV™ integration is a high-performance Web anti-virus (AV) solution. For
most enterprises, Web applications and traffic are mission-critical, representing 90% of the total
Internet traffic.
By deploying the ProxySG/ProxyAV solution, you gain performance and scalability (up to 250+ Mbps
HTTP throughput), along with Web content control.
For information on managing the ProxyAV, refer to the Blue Coat ProxyAV Configuration and
Management Guide.

Troubleshooting
Use the access logs, event logs, and packet captures to check connections and view traffic passing
through the ProxySG. Use policy tracing to troubleshoot policy. Note that policy tracing is global; that
is, it records every policy-related event in every layer. Turning on policy tracing of any kind is
expensive in terms of system resource usage and slows down the ProxySG's ability to handle traffic.


Policy tracing: For information on using policy tracing, see "Policy Tracing" on page 516.



Access Logs: For information on configuring and using access logs, see Chapter 20: "Access
Logging" on page 827.



Event logs: For information on using event logs, see "Event Logging and Notification" on
page 892.



Packet capture: For information on using the PCAP utility, see "Packet Capturing (the PCAP
Utility)" on page 1048.

35

Blue Coat ProxySG Configuration and Management Guide

Task Tables
The tables below refer to the sections in the manuals that describe the top-level tasks to customize the
ProxySG to your environment. The tables are listed in alphabetical order (for example, access logging,
authentication, bridging, caching, and so on).
Table 1.1: Access Logging
Task

Reference

Configure access logging with
• Blue Coat Reporter
• SurfControl Reporter
• Websense Reporter

• Blue Coat Reporter: Chapter 3, “Creating the First
Profile,” Blue Coat Reporter Configuration and Management
Guide
• SurfControl Reporter: "Using SurfControl Reporter with
SGOS 4.x" on page 719
• Websense Reporter: "Configuring Websense" on page 719

Table 1.2: Anti-Virus
Task

Reference

Block Web viruses using ProxyAV

"Section A: ICAP" on page 438; Blue Coat ProxyAV
Configuration and Management Guide

Set up anti-virus filtering

Blue Coat ProxyAV Configuration and Management Guide

Table 1.3: Authentication
Task

Reference

Achieve single sign-on with NTLM

"Section A: NTLM Realm Authentication and
Authorization" on 301

Select the right authentication mode

"Understanding Authentication Modes" on page 283

Install the Blue Coat
authentication/authorization agent to work
with IWA (formerly NTLM)

Appendix A: "Using the Authentication/Authorization
Agent" on page 901

Configure authentication to work with an
existing authentication service

Chapter 9: “Using Authentication Services” on page 291

Set up authentication schemes and use them in
policy

Chapter 8: “Security and Authentication” on page 261

Table 1.4: Bridging

36

Task

Reference

Configure bridging (hardware or software)

"Section D: Software and Hardware Bridges" on page 88

Chapter 1: Introducing the ProxySG

Table 1.4: Bridging
Allow those from outside a bridged deployment
to get to internal servers

"Defining Static Routes" on page 97

Table 1.5: Caching
Task

Reference

Disable caching

"Configuring Refresh Bandwidth for the HTTP Proxy" on
page 186

Table 1.6: HTTP
Task

Reference

Redirect HTTP with WCCP

"Standard HTTP Redirection" on page 975

Table 1.7: HTTPS
Task

Reference

Create a transparent HTTPS service

"Managing the HTTPS Service" on page 161

Table 1.8: Instant Messaging
Task

Reference

Allow, block, and control the supported Instant
Messaging clients

Chapter 17: “Instant Messaging” on page 651

Table 1.9: Management
Task

Reference

Get the Management Console to work

Chapter 3: “Accessing the ProxySG” on page 49

Manage the System:
• License the system

• Chapter 2: “Licensing” on page 37

• Back up the configuration

• "Archiving a Configuration" on page 79

• View statistics

• Chapter 22: “Statistics” on page 841

 Resources

• "Resources Statistics" on page 880

 Efficiency

• "Efficiency Statistics" on page 883

• SNMP monitoring

• "Configuring SNMP" on page 848

37

Blue Coat ProxySG Configuration and Management Guide

Table 1.10: Policy
Task

Reference

Set up authentication schemes and use them in
policy

Chapter 8: “Security and Authentication” on page 261

Limit network access and configuring
compliance pages

"Section B: Controlling Access to the Internet and Intranet"
on page 283

Block unwanted content

"How to Apply Policy to Categorized URLs" on page 729

Change policy default

"Transaction Settings: Deny and Allow" on page 481

Write policy using the Visual Policy Manager
(VPM)

"Section E: Tutorials" on page 589

Write policy using the Content Policy Language
(CPL)

Blue Coat ProxySG Content Policy Language Guide

Table 1.11: Proxies
Task

Reference

Determine the best type of proxy for the
environment

Chapter 6: “Configuring Proxies” on page 165

Set up HTTPS Reverse Proxy

"Section D: Configuring HTTP or HTTPS Origination to the
Origin Content Server" on 256

Get traffic to the proxy

Chapter 6: “Configuring Proxies” on page 165

Table 1.12: Reporter, Blue Coat
Task

Reference

Make Blue Coat Reporter work with access
logging

"Section G: Configuring the Upload Client" on 798; Blue
Coat Reporter: Chapter 3, “Creating the First Profile,” Blue
Coat Reporter Configuration and Management Guide

Use Scheduler to set up report generation

Chapter 3, “Using Scheduler,” in the Blue Coat Reporter
Configuration and Management Guide

Generate specific reports for specific people

Blue Coat Reporter Configuration and Management Guide

Table 1.13: Reporter, SurfControl

38

Task

Reference

Configure SurfControl Reporter

" Using SurfControl Reporter with SGOS 4.x" on 719

Chapter 1: Introducing the ProxySG

Table 1.14: Reporter, Websense
Task

Reference

Configure Websense Reporter

"Configuring Websense" on page 719

Table 1.15: Services
Task

Reference

Create a port service

"Section B: Creating and Editing Services" on page 152

Table 1.16: Streaming
Task

Reference

Control streaming protocols

Chapter 16: “Streaming Media” on page 613

Table 1.17: WCCP
Task

Reference

Configure WCCP for multiple ports

"Creating a Configuration File" on page 970

Redirect HTTP with WCCP

"Standard HTTP Redirection" on page 975

Configure the home-router IP

"Router Configuration" on page 975

Configure multiple home-routers

"Creating a Configuration File" on page 970

Configure a multicast address as the proxy's
home router

"Configuring a WCCP Version 2 Service on the Router" on
page 960

About the Document Organization
This document is organized for easy reference, and is divided into the following sections and chapters:
Table 1.18: Document Organization
Chapter Title

Description

Chapter 1 – Introducing the ProxySG

This chapter discusses the ProxySG Security Solution and
new features and enhancements in SGOS 3.x. It also covers
document conventions.

Chapter 2 – Licensing

Several features must be licensed to be used beyond the
evaluation trial date. This chapter describes which features
require licenses and how to download licenses.

39

Blue Coat ProxySG Configuration and Management Guide

Table 1.18: Document Organization (Continued)

40

Chapter Title

Description

Chapter 3 – Accessing the ProxySG

This chapter explains how to log in to the ProxySG CLI and
Web-based Management Console; how to change the
administrator username, password, privileged-mode
password; and how to make a secure connection using SSH
and HTTPS.

Chapter 4 – Configuring the System

Instructions on setting the ProxySG name and system time,
configuring the network adapter, load balancing, and FTP
port services, and specifying DNS servers. This chapter also
describes how to track client IP addresses using server-side
transparency or virtual IP addresses.

Chapter 5 – Managing Port Services

This chapter describes port services configurable on the
ProxySG, including several kinds of Management Consoles,
such as HTTPS, HTTP, SSH, and Telnet Consoles, and
application proxies such as Instant Messenger (IM), SOCKS,
FTP, MMS, and RTSP, HTTP and HTTPS.

Chapter 6 – Configuring Proxies

Explicit and Transparent proxies are discussed in this
chapter, as well as the recommended types of proxy.

Chapter 7 – Using Secure Services

HTTPS termination, including SSL, Certificates, keyrings,
and keypairs are discussed in this chapter.

Chapter 8 – Security and Authentication

Enabling and maintaining security on the ProxySG is
discussed in this chapter.

Chapter 9 – Using Authentication Services

Blue Coat supports six kinds of authentication, discussed
here: LDAP, NTLM, RADIUS, Local (formerly UNIX),
Certificate (which allows you to authenticate using
certificates), and Sequence (which allows you to
authenticate using multiple authentication servers).

Chapter 10 – Bandwidth Management

Managing the amount of bandwidth used by different
classes of network traffic is discussed in this chapter.

Chapter 11 – External Services

ICAP and Websense off-box are described in this chapter.

Chapter 12 – Health Checks

The health of services, such as SOCKS, ICAP, and
forwarding services, is discussed in this chapter.

Chapter 13 – Managing Policy Files

Four policy files are used to manage policy: Central, Local,
Visual Policy Manager, and Forwarding. This chapter
discusses how to manage them.

Chapter 14 – The Visual Policy Manager

This chapter contains a reference guide and several tutorials
for using the Visual Policy Manager.

Chapter 15 – Advanced Policy

This chapter discusses using features such as pop-up ad
blocking, managing active content, and creating exceptions.

Chapter 16 – Streaming Media

This chapter discusses streaming, including the new RTSP
proxy.

Chapter 1: Introducing the ProxySG

Table 1.18: Document Organization (Continued)
Chapter Title

Description

Chapter 17 – Instant Messaging

How to configure and use the ProxySG’s instant messaging
capabilities is discussed in this chapter.

Chapter 18 – Content Filtering

This chapter discusses how to configure and use the
ProxySG’s content filtering capabilities, as well as
configuring and using content filtering vendors to work
with the ProxySG.

Chapter 19– Configuring the Upstream
Networking Environment

This chapter discusses how to control upstream interaction
with the ProxySG.

Chapter 20 – Access Logging

Log formats, upload clients, upload schedules, and
protocols are discussed in this chapter.

Chapter 21 – Maintaining the ProxySG

This chapter discusses upgrading the system and
configuring event logs, SMNP, STMP, heartbeats, and core
images.

Chapter 22 – Statistics

This chapter discusses viewing various kinds of
statistics—system usage, efficiency, resources, and logs of all
kinds.

Appendix A – Using the Authentication/
Authorization Agent

The ProxySG BCAAA agent is discussed in this appendix.

Appendix B – Access Log Formats

ELFF, SQUID, NCSA/Common, and custom logs are
discussed in this appendix.

Appendix C – Using WCCP

Configuring and using a WCCP router with the ProxySG is
discussed in this appendix.

Appendix D – RIP Commands

Commands supported for the Routing Information Protocol
(RIP) configuration text file are discussed in the appendix.

Appendix E – Diagnostics

Determining and resolving ProxySG problems are discussed
in this appendix.

Appendix F – Using Blue Coat Director to
Manage Multiple ProxySG Appliances

Discusses how Blue Coat Director works with multiple
ProxySG Appliances.

Related Blue Coat Documentation


Blue Coat 6000 and 7000 Installation Guide



Blue Coat 200 Series Installation Guide



Blue Coat 400 Series Installation Guide



Blue Coat ProxySG 800 Series Installation Guide



Blue Coat ProxySG 8000 Series Installation Guide



Blue Coat ProxySG Content Policy Language Guide

41

Blue Coat ProxySG Configuration and Management Guide



Blue Coat ProxySG Command Line Reference

Document Conventions
The following section lists the typographical and Command Line Interface (CLI) syntax conventions
used in this manual.
Table 1.19: Typographic Conventions

42

Conventions

Definition

Italics

The first use of a new or Blue Coat-proprietary term.

Courier font

Command line text that appears on your administrator
workstation.

Courier Italics

A command line variable that is to be substituted with a literal
name or value pertaining to the appropriate facet of your network
system.

Courier Boldface

A ProxySG literal to be entered as shown.

{ }

One of the parameters enclosed within the braces must be
supplied

[ ]

An optional parameter or parameters.

|

Either the parameter before or after the pipe character can or must
be selected, but not both.

Chapter 2: Licensing

This chapter describes the ProxySG licensing behavior.

About Licensing
SGOS 4.x features a global licensing system for the ProxySG. License key files are issued on a
per-appliance basis. One license key file includes all of the component licenses for whichever ProxySG
features you have elected to use.
Note:

When your ProxySG order was completed, you received an e-mail that contains serial
numbers for licensable components. Those numbers are required for the procedures in
this chapter.

Licensable Components
There are three types of licensable components:


Required—The SGOS 4 Base; these features are required on the ProxySG.



Included—Additional SGOS 4.x features, which are provided by Blue Coat.



Optional— Any additional (purchased) features.

When the license key file is created, it consists of all three components. The following table lists the
ProxySG licensable components, categorized by type.
Table 2.1: Licensable Components
Type

Component

Description

Required

SGOS 4 Base

The ProxySG operating system, plus base features: HTTP, FTP, TCP-Tunnel,
SOCKS, and DNS proxy.

Included

3rd Party Onbox
Content Filtering

Allows use with third-party vendor databases: Intersafe, Optenet, Proventia,
SmartFilter, SurfControl, Websense, and Webwasher.

Included

Websense
Offbox Content
Filtering

For Websense off-box support only.

Included

ICAP Services

External virus and content scanning with ICAP servers.

Included

Bandwidth
Management

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.

43

Blue Coat ProxySG Configuration and Management Guide

Table 2.1: Licensable Components (Continued)
Type

Component

Description

Included

Windows Media
Standard

MMS proxy; no caching or splitting; content pass-through. Full policy control
over MMS.

Included

Real Media
Standard

RTSP proxy; no caching or splitting; content pass-through. Full policy control
over RTSP.

Included

Apple QuickTime
Basic

RTSP proxy; no caching or splitting; content pass-through. Full policy control
over RTSP.

Included

Netegrity
SiteMinder

Allows realm initialization and user authentication to SiteMinder servers.

Included

Oblix COREid

Allows realm initialization and user authentication to COREid servers.

Included

Peer-to-Peer

Allows you to recognize and manage peer-to-peer P2P activity relating to P2P
file sharing applications.

Included

Compression

Allows reduction to file sizes without losing any data.

Optional

SSL

SSL Termination; includes an SSL termination card to be installed on the
appliance.

Optional

IM

• AOL Instant Messaging: AIM proxy with policy support for AOL Instant
Messenger.
• MSN Instant Messaging: MSN proxy with policy support for MSN Instant
Messenger.
• Yahoo Instant Messaging: Yahoo proxy with policy support for Yahoo
Instant Messenger.

Optional

Windows Media
Premium

• MMS proxy; content caching and splitting.
• Full policy control over MMS.
• When the maximum concurrent streams is reached, all further streams are
denied and the client receives a message.

Optional

Real Media
Premium

• RTSP proxy; content caching and splitting.
• Full policy control over RTSP.
• When the maximum concurrent streams is reached, all further streams are
denied and the client receives a message.

About the Trial Period
Blue Coat provides a trial period. The initial system boot-up triggers the 60-day trial period, during
which you can evaluate the ProxySG functionality. For the first 60 days, all licensable components are
active and available to use. Furthermore, when a license is installed during the trial period (or while
using a demo license), components that are not part of that license remain available and active during
the trial period.

44

Chapter 2: Licensing

Note:

The ProxySG Licensing feature has slight changes from SGOS 3.x. The Blue Coat SGOS 4.x
Upgrade Guide (in Chapter 2) describes licensing behavior concerning an upgrade to SGOS
4.x from SGOS 3.x.

Each time you navigate to the Management Console home page or click the Maintenance>Licensing tab,
a pop-up dialog appears warning you that the trial period expires in so many days (a text message is
displayed on a Telnet, SSH, or serial console). If you require more time to explore the ProxySG
features, a demo license is available; refer to your reseller or contact Blue Coat Sales.
The trial period streaming and IM licenses are no-count licenses—unlimited streams and IM clients
are accessible.
Upon installing licenses after or during the trial period, the Base SGOS, Instant Messaging (IM),
Windows Media basic, and Real Media premium licenses are also unlimited, but Windows Media
premium and IM licenses impose user limits established by each license type.
Note:

If you invoke the restore-defaults command after you have installed licenses, and the
serial number of your system is configurable (older boxes only), the licenses fail to install
and you return to the trial period (if any time is left).

About License Expiration
At the end of the trial or demo period or, subsequently, when any normally licensed component
expires, components that have not been licensed do not process requests. A license expiration
notification message is logged in the Event Log (see "Viewing the Event Log" on page 888 for
information).
If a license expires, users might not receive notification, depending upon the application they are
using. Notifications do occur for the following:


HTTP (Web browsers)—An HTML page is displayed stating the ProxySG license has expired.



SSL—An exception page appears when an HTTPS connection is attempted.



Instant Messaging clients—Users do not receive a message that the ProxySG license has expired.
Any IM activity is denied, and to the user it appears that the logon connection has failed.



FTP clients—If the FTP clients supports it, a message is displayed stating the ProxySG license has
expired.



Streaming media clients—If the Windows Media Player, RealPlayer, or QuickTime player version
supports it, a message is displayed stating the ProxySG license has expired.

You can still perform ProxySG configuration tasks through the Management Console, CLI, SSH
console, serial console, or Telnet connection. Although the component becomes disabled, feature
configurations are not altered. Also, policy restrictions remain independent of component availability.

45

Blue Coat ProxySG Configuration and Management Guide

Obtaining a WebPower Account
Before you can generate the license key file, you must have a Blue Coat WebPower user account and
register the ProxySG.
If you do not have a WebPower account or forgot your account information, perform the following
procedure.
To Obtain a WebPower Account
1.

Select Maintenance>Licensing>Install.

2.

In the License Administration field, click Register/Manage. The License Configuration and
Management Web page appears (ignore the dialog at this time).

3.

Perform one of the following:


To obtain a new account, click the link for Need a WebPower User ID. Enter the information as
prompted.



To obtain your current information for an existing information, click the link for Forgot your
password.

Registering the Hardware
This section describes how to enter the appliance serial number and register the appliance with Blue
Coat.

System Serial Number Prerequisite
Each ProxySG serial number is the appliance identifier used to assign a license key file. The ProxySG
contains an EEPROM with the serial number encoded. The ProxySG recognizes the serial number
upon system boot-up.
The serial number is visible by navigating to Configuration>General>Identification.

The License Warning Dialog
When you first access the ProxySG Management Console, or when you select
Maintenance>Licensing>Install, a License Warning dialog appears.

46

Chapter 2: Licensing

Figure 2-1: License Warning dialog: Hardware not registered

You cannot install a license key until the hardware has been registered. The License Warning field
indicates this status.
If you know the hardware has been manually registered, select Hardware has been manually registered
and click Close. The system searches for the last instance and value of hardware registration. Proceed
to "Installing a License Key File" on page 48.

Registering the ProxySG
This section describes how to register the ProxySG.
To Register the Hardware
1.

If the License Warning dialog is not displayed, select Maintenance>Licensing. The License Warning
dialog appears.

2.

Select Register hardware with Blue Coat automatically.

3.

Enter your WebPower username and password.

4.

Click Proceed. The Registration Status field displays relative information.
The ProxySG connects to the Blue Coat License Self-Service page. The next step is to obtain and
install the license key file that allows access to the ProxySG features you require.

47

Blue Coat ProxySG Configuration and Management Guide

Installing a License Key File
This section describes how to register the ProxySG with Blue Coat and install the license key file.

Creating a License Key File
The License Self-Service Web page allows you to create a license key file.

Figure 2-2: The License Self-Service Web page

Upon purchasing the ProxySG from Blue Coat or a reseller, you received an e-mail that contains
license serial numbers. These serial numbers are required to create the license key file.
To Create a License Key File
1.

In the first field under Add a new software solution to this appliance, enter the serial number for the
SGOS 4.x base license.

2.

In the subsequent fields, enter the serial numbers for any optional licenses you obtained (for
example, Compression and IM).

Figure 2-3: Entering license serial numbers

48

Chapter 2: Licensing

3.

Click Apply.
A license key file, which contains either just the base license or the base combined with optional
licenses, is generated and is ready to be downloaded and installed.

Downloading the License Key File
Downloading the license key file is accomplished by using the automatic installation feature or by
receiving the key through e-mail and manually installing it from a Web server or a local file.

Automatic License Installation
If the ProxySG has Internet access, you can use the automatic license installation feature to retrieve
and install the license from Blue Coat.
To Automatically Obtain and Install the License from the Management Console
1.

Select Maintenance>Licensing>Install.

2.

In the License Key Automatic Installation field, click Retrieve. The Request License Key dialog appears.

Figure 2-4: Requesting a License

3.

Enter your Blue Coat WebPower user ID and password.

4.

Click Send Request.
The ProxySG fetches the license associated with the serial number that is displayed.

5.

The Installation Status field displays relevant information. When installation is complete, click
Results; examine the results and click OK; click Close. The ProxySG is now licensed.

49

Blue Coat ProxySG Configuration and Management Guide

Manual License Installation
If the ProxySG does not have Internet access, Blue Coat can send you the license in an e-mail. The file
can then be installed from a Web server or a local directory.
To Manually Obtain and Install the License
1.

Select Maintenance>Licensing>Install.

2.

Click Register/Manage. A new window opens to the Blue Coat ProxySG Registration page. This
Web page provides instructions for requesting that the license (associated to the ProxySG by the
serial number) be sent through e-mail.

3.

When the e-mail arrives, save the attached license file on a Web server or to a local file.

4.

In the License Key Manual Installation field, select one of the following from the drop-down list and
click Install:
Note:


A message is written to the event log when you install a list through the ProxySG.

Remote URL—If the file resides on a Web server. The Install License Key dialog displays.

Figure 2-5: Installing a License from a Web Server

Enter the URL path and click Install. The Installation Status field displays relevant information.
When installation is complete, click Results; examine the results, close the window, and click
OK. Click Apply.


50

Local File—If the file resides in a local directory. The Upload and Install File window opens.

Chapter 2: Licensing

Figure 2-6: Uploading a License from a Local File

Enter a path to the license file or click Browse and navigate to the file. Click Install. A results
window opens. Examine the license installation results; close the window. Click Close. Click Apply.
The ProxySG license is now installed. All features that you subscribed to are fully operational.

Viewing License Information
You can review the validity and expiration date of any licensed feature.
To View the License Information through the Management Console
Select Maintenance>Licensing>View.

51

Blue Coat ProxySG Configuration and Management Guide

Figure 2-7: Viewing License Information

Each licensable component is listed, along with its validity and its expiration date.
Note:

To view the most current information, click Refresh Data.

You can also highlight a license component and click View Details. A dialog appears displaying more
detailed information about that component. For example, a streaming component displays the
maximum number of streams allowed.

Disabling the Components Running in Trail Mode
You might decide to not let users access ProxySG features that are currently running in trial mode.
To disable trial mode components from the Management Console:
1.

On the View License tab, select Trial Components are enabled: Disable.

2.

Click Apply.

3.

Click Refresh Data. All licenses that are in trial mode switch from Yes to No. Users cannot use these
features. Furthermore, they do not receive nag dialogs warning of license expiration.
Also notice that this option text changes to Trial Components are disabled: Enabled. Repeat this
process to re-enable trial licenses.

To disable trial mode components from the CLI:
At the enable prompt, enter the following command:
SGOS# licensing disable-trial

To re-enable:
SGOS# licensing enable-trial

52

Chapter 2: Licensing

Updating a License
After the initial license installation, you might decide to use another feature that requires a license. For
example, you currently support Windows Media, but want to add Real Media support. The license
must be updated to allow this support.
To update a license through the Management Console
1.

Select Maintenance>Licensing>Install.

2.

Click Register/Manage.

3.

Follow the instructions on the Blue Coat License Self-Service Web page.

4.

If using the automatic license installation feature, click Update; otherwise, manually install the
license as described in "Manual License Installation" on page 50.

To update a license through the CLI
At the enable prompt, enter the following command:
SGOS# licensing update-key

Automatically Updating a License
The license automatic update feature allows the ProxySG to contact the Blue Coat licensing Web page
31 days before the license is to expire. If a new license has been purchased and authorized, the license
is automatically downloaded. The ProxySG continues to contact the Web site up to 30 days after the
license is set to expire. Outside the above license expiration window, the ProxySG performs this
connection once every 30 days to check for new license authorizations. This feature is enabled by
default.
To Configure the License Auto-Update Feature through the Management Console
1.

Select Maintenance>Licensing>Install.

2.

Select Use Auto-Update.

3.

Click Apply.

To Configure the License Auto-Update Feature through the CLI
At the (config) prompt, enter the following command:
SGOS# (config) license-key path url
SGOS# (config) license-key auto-update {enable | disable}

Note:

If the automatic license update fails and you receive a Load from Blue Coat error,
you must log on to your License Management account:
https://services.bluecoat.com/eservice_enu/licensing/mgr.cgi. Click Update
License Key.

53

Blue Coat ProxySG Configuration and Management Guide

54

Chapter 3: Accessing the ProxySG

The Blue Coat Systems ProxySG uses the Secure Shell (SSH) and HTTPS protocols to securely access
the ProxySG CLI and Management Console. Both SSHv1 and SSHv2 are enabled by default, and host
keys have already been created on the ProxySG.
All data transmitted between the client and the ProxySG using SSH/HTTPS is encrypted.
During initial configuration, you assigned the ProxySG a username and password and a
privileged-mode (enabled/configuration) password. These passwords are always stored and
displayed hashed.
This chapter discusses:


"Before You Begin: Understanding Modes"



"Accessing the ProxySG"



"Accessing the Management Console Home Page"



"Changing the Logon Parameters"



"Configuring the SSH Console"

Important: This chapter assumes that you have completed the first-time setup of the ProxySG
using either the front panel or serial console, and that the appliance is running on the
network. These steps must be completed before accessing the appliance.
You can manage the ProxySG by logging on to and using one of the following:


An SSH session to access the CLI.



The Management Console graphical interface.

You can also use a serial console to access the CLI.
Note:

To use a Telnet session, you must use a serial console connection until you have
configured Telnet for use. (For security reasons Blue Coat does not recommend using
Telnet).

Before You Begin: Understanding Modes
SGOS 4.x supports different levels of command security:


Standard, or unprivileged, mode is read-only. You can see but not change system settings and
configurations. This is the level you enter when you first access the CLI.

55

Blue Coat ProxySG Configuration and Management Guide



Enabled, or privileged, mode is read-write. You can make immediate but not permanent changes
to the ProxySG, such as restarting the box. This is the level you enter when you first access the
Management Console.



Configuration is a mode within the enabled mode. From this level, you can perform permanent
changes to the ProxySG configuration.

If you use the Management Console, you are in configuration mode when you are completely logged
on to the system.
If you use the CLI, you must enter each level separately:
Username: admin
Password:
SGOS> enable
Enable Password:
SGOS# configure terminal
Enter configuration commands, one per line. End with CTRL-Z.
SGOS#(config)

For detailed information about the CLI and the CLI commands, refer to the Blue Coat ProxySG
Command Line Reference.
Note:

Although most administrator tasks can be performed using either the Management
Console or the CLI, there is the occasional task that can only be done using one of the two:
these are specified in the manual.

Accessing the ProxySG
You can access the ProxySG through either the CLI or the Management Console. By default, SSHv2
(CLI) and HTTPS (Management Console) are used to connect to the appliance.
The SSH and HTTPS ports are configured and enabled. For SSH, you can use either version 1 or
version 2 (with password or RSA client key authentication).

Accessing the CLI
If you use the CLI, you can use SSHv2 to access the ProxySG, but you cannot use SSHv1 or Telnet
without additional configuration.
Note:

Enabling the Telnet-Console introduces a security risk, so it is not recommended.

To use SSHv1, you must first create an SSHv1 host key. For more information on creating SSH host
keys, see "Configuring the SSH Console" on page 63.
To log on to the CLI, you must have:

56



the account name that has been established on the ProxySG



the IP address of the ProxySG

Chapter 3: Accessing the ProxySG



the port number (8082 is the default port number)

You must log on from your SSH client.

Accessing the Management Console
The Management Console is a graphical Web interface that allows you to manage, configure, monitor,
and upgrade the ProxySG from any location.
In the Web browser, enter HTTPS, the ProxySG IP address, and port 8082 (the default management
port). For example, if the IP address configured during first-time installation is 10.25.36.47, enter the
URL https://10.25.36.47:8082 in the Web browser.
The Management Console consists of a set of Web pages and Java applets stored on the ProxySG. The
appliance acts as a Web server on the management port to serve these pages and applets. From the
ProxySG home page on the appliance, you can access the management applets, statistics applets, and
documentation. The Management Console is supported with a complete online help facility to assist
you in defining the various configuration options.
Note:

If, when you access the Management Console home page, you get a “host mismatch” or
an “invalid certificate” message, you need to recreate the security certificate used by the
HTTPS-Console. For information on changing the security certificate, see "Managing the
HTTPS Console (Secure Console)" on page 144.

Accessing the Management Console Home Page
When you access the Management Console home page (see "Accessing the Management Console" on
page 57), you are prompted to log on to the box.

Logging On
Each time you access the Management Console, you must log on.

Figure 3-1: Logon Dialog


The Site is the IP address of the ProxySG to which you are logging on.



The Realm is a configurable name that can be anything you choose. The ProxySG IP address is the
default. For more information on configuring the realm name, see "Changing the ProxySG Realm
Name" on page 61.

57

Blue Coat ProxySG Configuration and Management Guide



The User Name is the name of the account you are using on this ProxySG. The name must already
exist. It cannot be created here.



The Password is the password for the account you are using. It cannot be changed here.

You can change the username and password for the console through the Management Console or the
CLI. See "Changing the Logon Parameters" on page 59.
Note:

All successful and failed logon attempts are logged to the ProxySG event log.

Logging Out
Once you have logged on, you do not have to log on again unless you exit the current session or the
session times out. The session timeout period, with a default of 900 seconds (15 minutes), is
configurable.
Thirty seconds before the session times out, a warning dialog displays. Click the Keep Working button
or the X in the upper-right-corner of the dialog box to keep the session alive.
Note:

The Keep Working button saves your changes to the current applet. You cannot work in
other applets without logging back on to the ProxySG.

Figure 3-2: Automatic Logout Warning

If you do not click Keep Working or the X in the upper-right-hand corner within the thirty-second
period, you are logged out. You must log back on to access the Management Console.

Figure 3-3: Logout Dialog

Click the hyperlink to log back on to the ProxySG.
Note:

58

If no applet is running when the session times out (you are on the Management Console
home page), you are logged out without seeing the logout warning dialog. You might not
be aware that you are logged out until you try to access an applet. You must enter the
logon information again.

Chapter 3: Accessing the ProxySG

Changing the Logon Parameters
You can change the console username and password, the console realm name (which displays when
you log on to the ProxySG), and the auto-logout timeout (in seconds; the default is 900 seconds.)
The Management Console requires a valid administrator username and password to have full
read-write access; you do not need to enter a privileged-mode password as you do when using the
CLI. A privileged-mode password, however, must already be set.
Note:

To prevent unauthorized access to the ProxySG, only give the console username and
password to those who administer the ProxySG.

Changing the Username and Password through the Management Console
You can change either the username or the password without changing both.

Changing the Username through the Management Console
The console account username was assigned during initial setup of the system. You can change the
username at any time.
To Change the Username through the Management Console
1.

Select Configuration>Authentication>Console Access>Console Account.
The Console Account tab displays.

Figure 3-4: Console Account Tab

Note:

Changing the Console Account username or password causes the Management Console
to refresh and log back on using the new information. Note that each parameter must be
changed and individually refreshed. You cannot change both parameters at the same time.

59

Blue Coat ProxySG Configuration and Management Guide

2.

Enter the username of the administrator or administrator group who is authorized to view and
revise console properties.
Only one console account exists on the ProxySG. If you change the console account username, that
username overwrites the existing console account username.
The console account username can be changed to anything that is not null and contains no more
than 64 characters.

3.

Click Apply.
After clicking Apply, an Unable to Update configuration error is displayed. The username change was
successfully applied, but the configuration could not be fetched from the ProxySG, as the
username offered in the fetch request is still the old username.

4.

Refresh the screen. You are then challenged for the new username.

To Change the Password through the Management Console
The console password and privileged-mode password were defined during initial configuration of the
system. The console password can be changed at any time through the Management Console. The
privileged-mode, or enabled-mode, password can only be changed through the CLI or the serial
console.
1.

Select Configuration>Authentication>Console Access>Console Account.
The Console Account tab displays.

2.

Click Change Password.

Figure 3-5: Setting or Changing a Password

3.

Enter and re-enter the console password that is used to view and edit configuration information.
The password must be from 1 to 64 characters long. As you enter the new password, it is obscured
with asterisks. Click OK.
Note:

4.

60

This does not change the enabled-mode password. You can only change the
enabled-mode password through the CLI.

Refresh the screen, which forces the ProxySG to re-evaluate current settings. When challenged,
enter the new password.

Chapter 3: Accessing the ProxySG

5.

(Optional) Restrict access by creating an access control list or by creating a policy file containing
layer rules. For more information, see "Moderate Security: Restricting Management
Console Access Through the Console Access Control List (ACL)" on page 275.

Changing the Username and Password through the CLI
To Change the Console Account Username or Password, Privileged-Mode Password, and the
Front-Panel PIN through the CLI
1.

Open a terminal session with the ProxySG and enter the current username and password as
prompted.

2.

At the command prompt, enter the following command:
SGOS> enable

3.

Enter the privileged-mode password when prompted.

4.

At the command prompt, enter the following commands (note that usernames and passwords can
each be from 1 to 64 characters in length, but that passwords need to be in quotes):
SGOS# configure terminal
SGOS#(config) security username username

This command specifies the administrator username.
SGOS#(config) security password “password”
-orSGOS#(config) security hashed-password hashed_password

These commands specify the administrator console password.
SGOS#(config) security enable-password “password”
-orSGOS#(config) security hashed-enable-password hashed_password

These commands specify the administrator privileged-mode password. The ProxySG hashes
the password if you enter it in clear text.
5.

(Optional, for maximum security. Note that these commands are not available if the ProxySG does
not have a front panel.) At the command prompt, change the ProxySG front panel PIN:
SGOS#(config) security front-panel-pin pin
-orSGOS#(config) security hashed-front-panel-pin hashed_pin

6.

(Optional) Restrict access by creating an access control list or by creating a policy file containing
layer rules. For more information, see Section A: “Controlling Access to the ProxySG” on
page 271.

Changing the ProxySG Realm Name
The realm name displays when you log on to the ProxySG Management Console. The default realm
name is the connection used to access the ProxySG, usually the IP address of the system.

61

Blue Coat ProxySG Configuration and Management Guide

To Change the Realm Name through the Management Console
1.

Select Configuration>Authentication>Console Access>Console Account.
The Console Account tab displays.

2.

Enter a new realm name.
The new realm name displays the next time you log on to the ProxySG Management Console.

3.

Click Apply.

To Change the Realm Name through the CLI
1.

At the (config) prompt, enter the following command to change the name from the default.
SGOS#(config) security management display-realm name

The new realm name displays the next time you log on to the ProxySG Management Console.
2.

(Optional) View the results. As the show security command displays lengthy output, only the
relevant section is displayed in the following example:
SGOS#(config) show security
Account:
Username:
"admin"
Hashed Password: $1$aWMpN$/dsvVrZK6R68KH8r2SQxt/
Hashed Enable Password: $1$P4lpm$ZqFXg4J4A/T.ORgUbr0B/1
Hashed Front Panel PIN: "$1$GGSf2$lEhLm9oITgny9PDF2kVFp."
Management console display realm name: ""
Management console auto-logout timeout: Never

You can negate the security management display-realm values by entering no before the
command; for example, security management no display-realm.

Changing the ProxySG Timeout
The timeout is the length of time a session persists before you are logged out. The default timeout is
900 seconds (15 minutes).
To Change the Timeout through the Management Console
1.

Select Configuration>Authentication>Console Access>Console Account.
The Console Account tab displays.

2.

Either deselect Enforce auto-logout (which eliminates auto-logout entirely) or change the
auto-logout timeout from its default of 900 seconds (15 minutes) to another time (in seconds). This
is the allowable time on the ProxySG before the current session times out. Acceptable values are
between 300 and 86400 seconds (5 minutes to 24 hours).
If you change the timeout value, the change takes effect on the next refresh of any applet on the
Management Console.

3.

62

Click Apply.

Chapter 3: Accessing the ProxySG

To Change the Timeout through the CLI
1.

To change the timeout from its default of 900 seconds (15 minutes), enter:
SGOS#(config) security management auto-logout-timeout seconds

The change takes effect on the next refresh of any applet in the Management Console. Acceptable
values are between 300 and 86400 seconds (5 minutes to 24 hours).
2.

(Optional) View the results. As the show security command displays lengthy output, only the
relevant section is displayed in the following example:
SGOS#(config) show security
Account:
Username:
“admin”
Hashed Password: $1$a2zTlEE$1b88R3SXUTXS.zO7lh8db0
Hashed Enable Password: $1$xQnqGerX$LU65b20trsIAF6yJox26L.
Hashed Front Panel PIN: "$1$ThSEiB1v$seyBhSxtTXEtUGDZ5NOB1/"
Management console display realm name: "Aurora"
Management console auto-logout timeout: Never

You can negate the security management auto-logout-timeout values by entering no
before the command; for example, security management no auto-logout-timeout.

Configuring the SSH Console
By default, the ProxySG uses Secure Shell (SSH) and password authentication so administrators can
access the ProxySG CLI or Management Console securely. SSH is a protocol for secure remote logon
over an insecure network. No action is required unless you want to change the existing SSH host key,
disable a version of SSH, or import RSA host keys. Only one SSH service is allowed on the ProxySG.
To disable the SSH port, see "Managing the SSH Host Connection" below.

Managing the SSH Host Connection
You can manage the SSH host connection through either the Management Console or the CLI.
To Manage the SSH Connection through the Management Console
Note:

1.

Only one SSH Console can be enabled at a time. By default, both SSHv1 and SSHv2 are
enabled and assigned to port 22. You do not need to create a new host key unless you
want to change the existing configuration.

Select Configuration>Services>SSH Console>SSH Host.
The SSH Host tab displays.

63

Blue Coat ProxySG Configuration and Management Guide

Figure 3-6: SSH Host Tab

2.

To delete either SSHv1 or SSHv2 support on the ProxySG, click the appropriate Delete button.
The change is made on the ProxySG instantly.
Important:

Do not delete both versions. This disables the SSH Console. Even if you add SSHv1
or SSHv2 client keys back, you will have to enable the service through
Configuration>Services>Service Ports.

The SSH host tab redisplays with the appropriate host key deleted.
3.

To add SSHv1 or v2 support, select the Create checkbox for the version you want. Remember that
if both versions are deleted, you must re-enable the SSH service on port 22.

4.

The SSH host key displays in the appropriate pane.

To Manage SSH Host Keys through the CLI
Note:

Only one SSH Console can be enabled at a time. By default, both SSHv1 and SSHv2 are
enabled and set up on port 22. You do not need to create a new host key unless you want
to change the existing configuration. In fact, you cannot create a new host key unless you
delete one of the existing client keys.

You must set up RSA client keys to connect to the ProxySG using RSA. To set up RSA client keys, see
"Managing the SSH Client" below.
1.

From the (config) prompt of the ProxySG, enter the following commands to create a host key.
SGOS#(config) services
SGOS#(config services) ssh-console
SGOS#(config services ssh-console) create host-keypair [sshv1 | sshv2]

The client key, either SSHv1 or SSHv2 or both, is created, depending on which client key was
previously deleted.

64

Chapter 3: Accessing the ProxySG

2.

(Optional) View the results.
SGOS#(config services ssh-console) view host-public-key [sshv1 | sshv2]
1024 35
190118975106704546356706163851813093052627858203406609264841510464285480824
068799445880489701889675368436600545643174140823440610328520806007156774811
989754027101280816905716431491183274963949027032871437205903863441301419664
1366408168414061584835486361481236628643756053169543839452802141370496747163
3977037
ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAIEA2rSeDb3vhr78AFmd7TbdtziYfUQybaDxdMBbSLuyJVgwVbq+
tIvS4L6kDsTuFYGVR8Cg74Xqsj2kO6iwo71YGwdUnDXEzIFBwl0nvS4LkV2UINUwbuP0R0hD4Dt
jVTKsURrOHbTxcXkFipplDwFPDiCKOIqLm4ypcaC/Pj+Juq0=

3.

To disable SSH, enter:
SGOS#(config services ssh-console) delete host-keypair [sshv1 | sshv2]

Deleting both of the client keys disables the SSH service on port 22, which then must be
re-enabled before you can use SSH Console services again, even if you re-create the host
keys.

Managing the SSH Client
You can have multiple RSA client keys on the ProxySG to allow for actions such as logging on to the
ProxySG from different locations. You cannot create an RSA client key through the appliance, only
through an SSH client. Many SSH clients are commercially available for UNIX and Windows.
Once you have created an RSA client key following the instructions of your SSH client, you can import
the key onto the ProxySG using either the Management Console or the CLI.

Understanding OpenSSH.pub Format
Blue Coat supports the OpenSSH.pub format. Keys created in other formats will not work.
An OpenSSH.pub public key is similar to the following:
ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAIEAwFI78MKyvL8DrFgcVxpNRHMFKJrBMeBn2PKcv5oAJ2qz+uZ7
hiv7Zn43A6hXwY+DekhtNLOk3HCWmgsrDBE/NOOEnDpLQjBC6t/T3cSQKZjh3NmBbpE4U49rPdu
iiufvWkuoEiHUb5ylzRGdXRSNJHxxmg5LiGEiKaoELJfsDMc= user@machine

One of the public key format examples (this one created by the SSH client) is similar to the following:
---- BEGIN SSH2 PUBLIC KEY ---Comment: “[1024-bit rsa, user.name@machine, Wed Feb 19 2003 19:2\8:09]”
AAAAB3NzaC1yc2EAAAADAQABAAAAgQCw52JeWr6Fv4kLkzbPZePvapCpaTadPYQwqsGnCIYdf1W
e7/8336EmzV918G1jb/VT1SI1tM1Ku1BTal7uWAi+aUBGKLlYuyhCTo03IZFMnsQC7QYzY1y3ju
fUP3H0be52fg7n7p7gNZR11yzWhVei1vIKiyVKpjqiq6hxCbMb2Q==
---- END SSH2 PUBLIC KEY ----

The OpenSSH.pub format appends a space and a user ID to the end of the client key.
The user ID for the key must be unique. Because the ProxySG manages the keys through the user, no
two can be the same.
Other caveats:

65

Blue Coat ProxySG Configuration and Management Guide



1024 bits is the maximum supported key size.



An ssh-rsa prefix must be present.



Trailing newline characters must be removed from the key before it is imported.

To Import RSA Client Keys through the Management Console
1.

From your SSH client, create a client key and copy it to the clipboard.
Note:

2.

The above step must be done with your SSH client. The ProxySG cannot create client
keys.

Select Configuration>Services>SSH Console>SSH Client.
The SSH Client tab displays.

Figure 3-7: SSH Client Tab

3.

Click Import to import a new host key.
The Import Client Key dialog displays.

Figure 3-8: Import Client Key Dialog

66

Chapter 3: Accessing the ProxySG

4.

Specify whether the client key is associated with an existing user or a new user, and enter the
name.

5.

Paste the RSA key that you previously created with an SSH client into the Client key field. Ensure
that a key ID is included at the end. Otherwise, the import fails.

6.

Click OK.
The SSH Client tab reappears, with the fingerprint of the imported key displayed.

Figure 3-9: SSH Client with Imported Client Key

To Import a Client Key through the CLI
1.

From your SSH client, create a client key and copy it to the clipboard.

2.

From the (config) prompt, enter the following commands to import a client key.
SGOS#(config) services
SGOS#(config services) ssh-console
SGOS#(config ssh-console) import client-key user_name
Paste client key here, end with “...” (three periods)
ssh-rsaAAAAB3NzaC1yc2EAAAABIwAAAIEAtAy+axsx0iwroFN7B9qSJYjfVbsxPfyC0aoZpSMBd
g97/oiFozDXPhrRmPI3c42EiVdJtVo65r0Aerpu4ybCYVeq6MjRwdsszaezY+VdqtfyYVptC6V1
7Pmj2erw4+A9AggKHTp56BBCm3mEPQDdVW7J6QBrJ+U1ClFS/sMcbV8=laptop@GLYPH
...
ok

3.

(Optional) View the results.
SGOS#(config services ssh-console) view client-key username
user_ID@PC 45:5C:3F:5F:EA:65:6E:CF:EE:4A:05:58:9A:C5:FB:4F
user_ID@LAPTOP 61:ED:79:23:F5:2A:1A:6D:84:81:A0:5B:25:36:C7:5F

Note:

If you have upgraded from an older version ProxySG, and you want to view a previously
imported client key, you might not need to enter a username.

67

Blue Coat ProxySG Configuration and Management Guide

68

Chapter 4: Configuring the System

This chapter describes how to configure various ProxySG system configurations, such as setting the
time, configuring adapters, and creating software bridges.
This chapter contains the following sections:


"Global Configurations"



"Archive Configuration"



"Adapters"



"Software and Hardware Bridges"



"Gateways"



"Defining Static Routes"



"Using RIP"



"DNS Servers"



"Attack Detection"



"Using a Bypass List"



"Installing WCCP Settings"



"Virtual IP Addresses"



"Configuring Failover"



"TCP/IP Configuration"

During initial configuration, Interface 0 was configured by default. The NTP server was defined to
keep the system time correct. You also optionally configured a bridge, a gateway, and a DNS server.
These configurations require no further modification. These procedures are provided if you need to
configure other adapters in the system or if you need to change a configuration occurs.

69

Blue Coat ProxySG Configuration and Management Guide

Section A: Global Configurations

Section A: Global Configurations
The ProxySG global configurations include: defining the ProxySG name and serial number, setting the
time, and configuring NTP for your environment.
The following topics are discussed in this section:


"Configuring the ProxySG Name"



"Configuring the Serial Number"



"Configuring the System Time"



"Network Time Protocol"



"Configuring HTTP Timeout"

Configuring the ProxySG Name
You can assign any name to a ProxySG. A descriptive name helps identify the system.
To Set the ProxySG Name through the Management Console
1.

Select Configuration>General>Identification.
The Identification tab displays.

Figure 4-1: General Identification Tab

2.

In the Unique name for this ProxySG Appliance field, enter a ProxySG name.

3.

Click Apply.

To Set the ProxySG Name through the CLI
At the (config) command prompt, enter the following command:
SGOS#(config) hostname name

70

Chapter 4: Configuring the System

Section A: Global Configurations

Configuring the Serial Number
The ProxySG serial number assists Blue Coat Systems Customer Support when analyzing
configuration information, including heartbeat reports. This number is found on the ProxySG. Once
the serial number is entered, the ProxySG does not verify the validity of the number, only that it is
numeric.
Note:

If the EPROM contains the ProxySG serial number, you cannot manually enter a serial
number.

To Enter the Serial Number through the Management Console
1.

Select Configuration>General>Identification.
The Identification tab displays.

2.

In the Serial Number field, enter the serial number.

3.

Click Apply.

To Enter the Serial Number through the CLI
At the (config) command prompt, enter the following command:
SGOS#(config) serial-number serial_number

Displayed Information
The serial number is visible on the Management Console home page. and is displayed using the show
serial-number command. If the serial number was entered through the Management Console or the
CLI, it is appended with (configured) to indicate a manual entry.

Configuring the System Time
To manage objects, the ProxySG must know the current Universal Time Coordinates (UTC) time,
which is the international time standard and is based on a 24-hour clock.
By default, the ProxySG attempts to connect to an NTP server to acquire the UTC time. The appliance
ships with a list of NTP servers available on the Internet, and attempts to connect to them in the order
they appear in the NTP server list on the NTP tab. If the appliance cannot access any of the listed NTP
servers, you must manually set the UTC time.
To Set UTC Time through the Management Console
1.

Select Configuration>General>Clock>Clock.
The Clock tab displays.

71

Blue Coat ProxySG Configuration and Management Guide

Section A: Global Configurations

Figure 4-2: General Clock Tab

2.

Verify that Enable NTP is selected.

3.

To set your local time, select a time zone from the Timezone drop-down list.
Once the local time zone is selected, event logs record the local time instead of GMT.

4.

Click Acquire UTC time.

5.

Click Apply.

To Set UTC Time through the CLI
At the enable prompt, enter the following command:
SGOS# acquire-utc

If NTP is disabled, an error is displayed.
To Manually Set UTC Time through the Management Console
1.

Select Configuration>General>Clock>Clock.
The Clock tab displays.

2.

De-select Enable NTP.
The UTC time and date fields become editable when NTP is disabled.

3.

To set your local time, select a time zone from the Timezone drop-down list.
Once the local time zone is selected, event and access logs record the local time instead of GMT.

72

4.

Click Pause in the upper-right-hand corner to stop the system clock.

5.

Enter the current UTC time and date in the UTC time and date fields.

6.

Click Resume to start the system clock.

7.

Click Apply.

Chapter 4: Configuring the System

Section A: Global Configurations
To Manually Set UTC Time through the CLI
1.

At the (config) command prompt, enter the following commands
SGOS#(config)
SGOS#(config)
SGOS#(config)
SGOS#(config)
SGOS#(config)
SGOS#(config)

2.

clock
clock
clock
clock
clock
clock

day 1-31
hour 0-23
minute 0-59
month 1-12
second 0-59
year year

(Optional) View the results.
SGOS#(config) show clock
2003-08-28 22:50:56+00:00UTC
2003-08-28 22:50:56+00:00UTC

Network Time Protocol
The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to
another server or reference time source, such as a radio or satellite receiver or modem. There are more
than 230 primary time servers, synchronized by radio, satellite and modem.
The ProxySG ships a list of NTP servers available on the Internet, and attempts to connect to them in
the order they appear in the NTP server list on the NTP tab. You can add others, delete NTP servers,
and reorder the NTP server list to give a specific NTP server priority over others.
The ProxySG uses NTP and the Universal Time Coordinates (UTC) to keep the system time accurate.
You can add and reorder the list of NTP servers the ProxySG uses for acquiring the time through the
Management Console. The reorder feature is not available through the CLI.
To Add an NTP Server through the Management Console
1.

Select Configuration>General>Clock>NTP.
The NTP tab displays.

73

Blue Coat ProxySG Configuration and Management Guide

Section A: Global Configurations

Figure 4-3: General Clock NTP Tab

2.

Click New to add a new server to the list.

3.

Enter either the domain name or IP address of the NTP server and click OK.

4.

Click Apply.

To Add an NTP Server through the CLI
1.

At the (config) command prompt, enter:
SGOS#(config) ntp server domain_name
SGOS#(config) ntp interval minutes
SGOS#(config) ntp enable

2.

(Optional) View the results.
SGOS#(config) show ntp
NTP is enabled
NTP servers:
ntp.bluecoat.com
ntp2.bluecoat.com
Query NTP server every 60 minutes

3.

To remove a server from the NTP server list:
SGOS#(config) ntp no server domain_name

To Change the Access Order through the Management Console
NTP servers are accessed in the order displayed. You can organize the list of servers so the preferred
server appears at the top of the list. This feature is not available through the CLI.
1.

Select Configuration>General>Clock>NTP.
The NTP tab displays.

74

2.

Select an NTP server to promote or demote.

3.

Click Promote entry or Demote entry as appropriate.

Chapter 4: Configuring the System

Section A: Global Configurations
4.

Click Apply.

Configuring HTTP Timeout
You can configure various network receive timeout settings for HTTP transactions. You can also
configure the maximum time that the HTTP proxy waits before reusing a client-side or server-side
persistent connection. You must use the CLI to configure these settings.
To Configure the HTTP Receive Timeout Setting through the CLI
At the (config) command prompt, enter the following command:
SGOS#(config) http receive-timeout {client | refresh | server} #_seconds

where:
client

#_seconds

Sets the receive timeout for client to #_seconds. The
default is 120 seconds.

refresh

#_seconds

Sets receive timeout for refresh to #_seconds. The default
is 90 seconds.

server

#_seconds

Sets receive timeout for server to #_seconds. The default
is 180 seconds.

To Configure the HTTP Persistent Timeout Setting through the CLI
At the (config) command prompt, enter the following command:
SGOS#(config) http persistent-timeout {client | server} #_seconds

where:
client

#_seconds

The maximum amount of time the HTTP proxy waits
before closing the persistent client connection if another
request is not made. The default is 360 seconds.

server

#_seconds

The maximum amount of time the HTTP proxy waits
before closing the persistent server connection if that
connection is not re-used for any subsequent request
from the proxy. The default is 900 seconds.

75

Blue Coat ProxySG Configuration and Management Guide

Section B: Archive Configuration

Section B: Archive Configuration
Blue Coat allows you to both use an existing configuration (modified to include only general
parameters, not system-specific settings) to quickly set up a newly-manufactured ProxySG and to
save the running configuration off-box for archival purposes.
This section discusses:


"Sharing Configurations"



"Archiving a Configuration"

Sharing Configurations
You can share configuration between two ProxySG Appliances. You can take a post-setup configuration
file (one that does not include those configuration elements created in the setup console) from an
already-configured ProxySG and push it to a newly-manufactured system.
Note:

Blue Coat Director allows you to push configuration from one ProxySG to multiple
ProxySG Appliances at the same time. For more information on using Director, see
Appendix F: “Using Blue Coat Director to Manage Multiple Appliances” on page 1009.

The new configuration is applied to the existing configuration, changing any existing values. This
means, for instance, that if the new configuration creates a realm called RealmA and the existing
configuration has a realm called RealmB, the combined configuration includes two realms, RealmA and
RealmB.
You can use either the Management Console or the CLI to create a post-setup configuration file on one
ProxySG and push it to another.
Note:

You cannot push configuration settings to a newly manufactured system until you have
completed initial setup of the system.

To Create and Push a Configuration to a Newly Manufactured ProxySG through the Management
Console
From the already configured ProxySG:
1.

Select Configuration>General>Archive.
The Archive Configuration tab displays.

76

Chapter 4: Configuring the System

Section B: Archive Configuration

Figure 4-4: Archive Configuration Tab

2.

In the View Current Configuration panel, select the configuration from the drop-down list that you
want to use for the newly-manufactured machine:


Configuration - post setup: This displays the configuration on the current system, minus any

configurations created through the setup console, such as the hostname and IP address. It also
includes the installable lists.


Configuration - brief: This displays the configuration on the current system, but does not include

the installable lists.


Configuration - expanded: This is the most complete snapshot of the system configuration, but it

contains system-specific settings that should not be pushed to a new system.


Results of Configuration Load: This displays the results of the last configuration pushed to the

system.
3.

View the configuration you selected by clicking View. You can also view the file by selecting Text
Editor in the Install Configuration panel and clicking Install.

4.

Save the configuration. You can save the file two ways:


Save it as a text file on your local system. This is advised if you want to re-use the file.



Copy the contents of the configuration. (You will paste the file into the Text Editor on the
newly-manufactured system.)

From the newly-manufactured ProxySG:
1.

Launch the Management Console in a new browser window.

2.

Select Configuration>General>Archive.

3.

The Archive Configuration tab displays.

4.

In the Install Configuration panel, select either Local File or Text Editor from the drop-down list
(depending on whether you saved the file to your system or just copied it to the clipboard) and
click Install.

77

Blue Coat ProxySG Configuration and Management Guide

Section B: Archive Configuration


If you saved the file to your system, browse to the location of the Local File, highlight the file,
and click Install. The configuration is installed, and the results screen displays.



If you copied the contents of the file, paste it into the Text Editor and click Install. The
configuration is installed, and the results screen displays.
Note:

5.

A message is written to the event log when you install a list through the ProxySG.

Click Close.

Important: For information on restoring passwords, databases, and certificate keys, see
"Troubleshooting" on page 81.
To Create and Push a Configuration to a Newly Manufactured ProxySG through the CLI
From the already configured ProxySG:
1.

From the enable prompt (#), determine which configuration you want to use for the new system.
The syntax is:
show configuration post-setup | brief | expanded

where:
Configuration - post setup

This displays the configuration on the current system, minus any
configurations created through the setup console, such as the
hostname and IP address. It also includes the installable lists.

Configuration - brief:

This displays the configuration on the current system, but does not
include the installable lists.

Configuration - expanded

This is the most complete snapshot of the system configuration, but it
contains system-specific settings that should not be pushed to a new
system.

SGOS# show configuration post-setup

The selected configuration displays on the screen.
2.

Save the configuration. You can save the file two ways:


Copy the contents of the configuration to the clipboard. (Paste the file into the terminal on the
newly-manufactured system.)



Save it as a text file on a download FTP server accessible to the ProxySG. This is advised if you
want to re-use the file.

From the newly-manufactured ProxySG, do one of the following:

78



If you saved the configuration to the clipboard, go to the (config) prompt and paste the
configuration into the terminal.



If you saved the configuration on the FTP server:

Chapter 4: Configuring the System

Section B: Archive Configuration
At the enable command prompt, enter the following command:
SGOS# configure network “url”

where url must be in quotes and is fully-qualified (including the protocol, server name or
IP address, path, and filename of the configuration file). The configuration file is
downloaded from the server, and the ProxySG settings are updated.
Note:

If you rename the archived configuration file so that it does not contain any spaces,
the quotes surrounding the URL are unnecessary.

The username and password used to connect to the FTP server can be embedded into the
URL. The format of the URL is:
ftp://username:password@ftp-server

where ftp-server is either the IP address or the DNS resolvable hostname of the FTP server.
If you do not specify a username and password, the ProxySG assumes that an anonymous
FTP is desired and thus sends the following as the credentials to connect to the FTP server:
username: anonymous
password: proxy@

Archiving a Configuration
In the rare case of a complete system failure, restoring a ProxySG to its previous state is simplified by
loading an archived system configuration from an FTP or TFTP server. The archive, taken from the
running configuration, contains many system settings differing from system defaults, along with any
installable lists configured on the ProxySG.
Archive and restore operations must be done through the CLI.
Note:

You can archive a system configuration to an FTP or TFTP server that allows either
anonymous logon or requires a specific username and password. Likewise, to restore a
system configuration, the server storing the archive can be configured either to allow
anonymous logon or to require a username and password.

To Prepare to Archive a System Configuration
1.

Obtain write permission to a directory on an FTP server. This is where the archive will be stored.
The system configuration must be stored using FTP.

2.

At the (config) command prompt, enter the following commands:
SGOS#(config) archive-configuration protocol {ftp | tftp}
SGOS#(config) archive-configuration host host_name

where host_name is the IP address of the server.

79

Blue Coat ProxySG Configuration and Management Guide

Section B: Archive Configuration

Note:

TFTP does not require a password, path, or username.

SGOS#(config) archive-configuration password password
-orSGOS#(config) archive-configuration encrypted-password encrypted-password

where password is the password (or encrypted password) used to access the server.
SGOS#(config) archive-configuration path path

where path is the directory on the server where the archive is to be stored, relative to the
preset FTP directory.
SGOS#(config) archive-configuration filename-prefix filename

where filename can contain % strings that represent the information in the upload filename.
If you do not use the filename command, the ProxySG creates a name with a timestamp and
the filename SG_last-ip-octet_timestamp. For % string substitutions, see "Fields
Available for Creating Access Log Formats" on page 926.
SGOS#(config) archive-configuration username username

where username is the username used to access the server.
Example Session
SGOS#(config)
ok
SGOS#(config)
ok
SGOS#(config)
ok
SGOS#(config)
ok
SGOS#(config)
ok

Note:

archive-configuration host 10.25.36.47
archive-configuration password access
archive-configuration username admin1
archive-configuration path ftp://archive.server/stored
archive-configuration protocol ftp

To clear the host, password, or path, type the above commands using empty
double-quotes instead of the variable. For example, to clear the path, enter
archive-configuration path “”.

To Archive a System Configuration through the CLI
At the enable command prompt, enter the following command:
SGOS# upload configuration

To Restore a System Configuration through the CLI
At the enable command prompt, enter the following command:
SGOS# configure network “url”

80

Chapter 4: Configuring the System

Section B: Archive Configuration
where url must be in quotes and is fully-qualified (including the protocol, server name or
IP address, path, and filename of the configuration file). The configuration file is
downloaded from the server, and the ProxySG settings are updated.
Note:

If you rename the archived configuration file so that it does not contain any spaces,
the quotes surrounding the URL are unnecessary.

The username and password used to connect to the FTP server can be embedded into the URL. The
format of the URL is:
ftp://username:password@ftp-server

where ftp-server is either the IP address or the DNS resolvable hostname of the FTP server.
If you do not specify a username and password, the ProxySG assumes that an anonymous FTP is
desired and thus sends the following as the credentials to connect to the FTP server:
username: anonymous
password: proxy@

Troubleshooting
When pushing a shared configuration or restoring an archived configuration, keep in mind the
following issues:


Encrypted passwords (login, enable, and FTP) cannot be decrypted by a device other than that on
which it was encrypted. If you were sharing a configuration, these encrypted passwords were
probably already created before the configuration was pushed to the system.



If the content filtering database has not yet been downloaded, any policy that references
categories is not recognized.



The following passwords must be re-created (if you use the application specified):





administrator console passwords (not needed for shared configurations)



privileged-mode (enable) passwords (not needed for shared configurations)



the front-panel PIN (recommended for limiting physical access to the system)



access log FTP client passwords (primary, alternate)



archive configuration FTP password



RADIUS primary and alternate secret



LDAP search password



SmartFilter download password



WebSense3 download password



SNMP read, write, and trap community strings



RADIUS and TACACS+ secrets for splash pages

A full download of the content filtering database must be done.

81

Blue Coat ProxySG Configuration and Management Guide

Section B: Archive Configuration


SSH certificate keys must be imported.



SSL certificate keys must be imported

In addition, you should make sure the system is functioning whenever you add a feature. For
example, make sure the system works after basic configuration; then, after you add authentication,
recheck the system.

82

Chapter 4: Configuring the System

Section C: Adapters

Section C: Adapters
This section describes ProxySG network adapters and the adapter interfaces.
Note:

In Blue Coat documentation, the convention for adapters and their interfaces (the
connections on the adapter) is Adapter 0, Interface 0, or 0:0.

This section discusses:


"About Adapters"



"Network Interface States"



"Configuring an Adapter"



"About the Settings Button"



"Detecting Network Adapter Faults"

About Adapters
ProxySG Appliances ship with one or more network adapters installed on the system, each with one
or more interfaces. You can change interface parameters or configure additional adapters in the
appliance. You can also accept or reject inbound connections, change link settings in the event the
system did not correctly determine them, and configure the browser for proxy settings.

Network Interface States
As you select adapters from the picklist, the Adapter panel (Configuration>Network>Adapters) displays
the state of the configured adapter and its interfaces. When you initially set up the ProxySG, you
optionally configured Adapter 0, Interface 0. If your system has only one adapter, you can skip this
section. If your system shipped with other adapters, you can configure them through these
procedures.

Configuring an Adapter
The following procedure describes how to configure an adapter. Repeat the process if the system has
additional adapters.
To Configure a Network Adapter through the Management Console
1.

Select Configuration>Network>Adapters>Adapters.
The Adapters tab displays.
Note:

Different ProxySG models have different adapter configurations, and the appearance of
the Adapters tab varies accordingly.

83

Blue Coat ProxySG Configuration and Management Guide

Section C: Adapters

Figure 4-5: Network Adapters Tab

2.

Select an adapter from the Adapter drop-down list.
Notice that in the Interfaces field, a message displays stating whether the interface belongs to a
bridge. For more information about network bridging, see "Software and Hardware Bridges" on
page 88.

3.

(Optional) If you have a dual interface adapter, select an interface from the drop-down list.

4.

Enter the IP address and subnet mask for the interface into the IP address for interface x and Subnet
mask for interface x fields (where interface x refers to the interface selected in the Interfaces
drop-down list.)

5.

(Optional) To configure link settings, restrict inbound connections, or set up browser proxy
behavior for the adapter, select the adapter (under Interfaces) and click Settings. Enter any changes
and click OK to close the Settings dialog.
Note:

6.

The default is to permit all inbound connections. Link settings are automatically
determined and should not need to be modified. The browser default is to use the proxy’s
default PAC file. (See "About the Settings Button" below for more information on link
settings and inbound connections.)

Click Apply.

To Configure a Network Adapter through the CLI
At the (config) command prompt, enter the following commands:
SGOS#(config) interface fast-ethernet interface_number

where interface_number is 0, 1, or n, up to one number less than the number of adapters in
the system.
SGOS#(config interface interface_#:0) ip-address ip_address
SGOS#(config interface interface_#:0) subnet-mask subnet
SGOS#(config interface interface_#:0) exit

84

Chapter 4: Configuring the System

Section C: Adapters

About the Settings Button
The Settings button in the Interfaces field allows you to restrict inbound connections on the selected
adapter, and to choose manual or automatic configuration of the adapter link settings.
The default for Inbound connections is to permit all incoming connections. The link settings are
automatically determined and should not normally require modification.
Note:

Rejecting inbound connections improperly, or manually configuring link settings
improperly, can cause the ProxySG to malfunction. Make sure that you know the correct
settings before attempting either of these. If the ProxySG fails to operate properly after
changing these settings, contact Blue Coat Support.

Rejecting Inbound Connections
The default setting allows inbound connections on all network adapters.
To Reject Inbound Connections through the Management Console
1.

Select Configuration>Network>Adapters>Adapters.
The Adapters tab displays.

2.

Select an adapter from the Adapter drop-down list.

Figure 4-6: Settings for Individual Network Adapters

3.

Click Settings.

4.

To allow inbound connections, select the Accept inbound connections radio button. To reject
inbound connections, select Reject inbound connections.

5.

Click OK to close the Settings dialog.

85

Blue Coat ProxySG Configuration and Management Guide

Section C: Adapters
6.

Click Apply.

To Reject Inbound Connections through the CLI
At the (config) command prompt, switch to the interface submode to enter the following
commands:
SGOS#(config) interface interface_#
SGOS#(config interface interface_#:0) no accept inbound
SGOS#(config interface interface_#:0) exit

Manually Configuring Link Settings
By default, the ProxySG automatically determines the link settings for all network adapters. If the
device incorrectly identifies the network adapter, you can manually configure the link settings.
To Manually Configure Link Settings through the Management Console
1.

Select Configuration>Network>Adapters>Adapters.
The Adapters tab displays.

2.

Select an adapter from the Adapters drop-down list.

3.

Click Settings.

4.

Select Manually configure link settings.

5.

Select Half or Full duplex.

6.

Select the correct network speed.

7.

Click OK to close the Advanced Settings dialog.

8.

Click Apply.

To Manually Configure Link Settings through the CLI
At the (config) command prompt, enter the following commands:
SGOS#(config) interface fast-ethernet
SGOS#(config interface interface_#:0)
SGOS#(config interface interface_#:0)
SGOS#(config interface interface_#:0)

interface_#
full-duplex | half-duplex
speed 10 | 100 | 1gb
exit

Setting Up Proxies
To set up proxies, see "Configuring Proxies" on page 173.

Detecting Network Adapter Faults
The ProxySG can detect whether the network adapters in an appliance are functioning properly. If the
appliance finds that an adapter is faulty, it stops using it. When the fault is remedied, the ProxySG
detects the functioning adapter and uses it normally.
To determine whether an adapter is functioning properly:

86

Chapter 4: Configuring the System

Section C: Adapters
1.

Check whether the link is active (that is, a cable is connected and both sides are up).

2.

Check the ratio of error packets to good packets: both sent and received.

3.

Check if packets have been sent without any packets received.

If an adapter fault is detected, and the adapter has an IP address assigned to it, the ProxySG logs a
severe event. When an adapter does not have an IP address, the appliance does not log an entry.

87

Blue Coat ProxySG Configuration and Management Guide

Section D: Software and Hardware Bridges

Section D: Software and Hardware Bridges
This section describes the ProxySG hardware and software bridging capabilities. The following topics
are discussed:


"About Bridging"



"About the Pass-Through Adapter"



"ProxySG Prerequisites"



"Setting Bandwidth Management for Bridging"



"Configuring a Software Bridge"



"Configuring Failover"



"Static Forwarding Table Entries"

About Bridging
Network bridging through the ProxySG provides transparent proxy pass-through and failover
support. This functionality allows ProxySG Appliances to be deployed inline in environments where
L4 switches and WCCP-capable routers are not feasible options.
The ProxySG provides bridging functionality by two methods:


Software—A software, or dynamic, bridge is constructed using a set of installed interfaces. Within
each logical bridge, interfaces can be assigned or removed.



Hardware—A hardware, or pass-through, bridge uses a 10/100 dual interface Ethernet adapter.
This type of bridge provides pass-through support.

About the Pass-Through Adapter
A pass-through adapter is a 10/100 dual interface Ethernet adapter designed by Blue Coat to provide
an efficient fault-tolerant bridging solution. If this adapter is installed on a ProxySG, SGOS detects the
adapter upon system bootup and automatically creates a bridge—the two Ethernet interfaces serve as
the bridge ports. If the ProxySG is powered down or loses power for any reason, the bridge fails open;
that is, Web traffic passes from one Ethernet interface to the other. Therefore, Web traffic is
uninterrupted, but does not route through the appliance.
Important: This scenario creates a security vulnerability.
Once power is restored to the ProxySG, the bridge opens and Web traffic is routed to the appliance
and thus is subject to that appliance’s configured features, defined policies, and content scanning
redirection instructions.
Note:

88

Bridging supports only failover; it does not support load balancing.

Chapter 4: Configuring the System

Section D: Software and Hardware Bridges
The following figure provides an example of how the ProxySG indicates that an installed adapter is a
pass-through adapter.

Figure 4-7: Pass-through Adapter

Note:

The adapter state is displayed on Configuration>Network>Adapters>Adapters.

ProxySG Prerequisites
Before configuring a software bridge, the following conditions must be satisfied:


Adapters—The adapters must of the same type. Although the software does not restrict you from
configuring bridges with adapters of different types (10/100 or GIGE, for example), the resultant
behavior is unpredictable.



IP addresses—If the bridge already has an IP address configured, IP addresses must be removed
from any of adapter interfaces to be added. If the bridge does not have an IP address configured,
the bridge can inherit the IP address from the first interface to be added.

Setting Bandwidth Management for Bridging
After you have created and configured a bandwidth management class for bridging (see Chapter 10:
“Bandwidth Management” on page 413), you can manage the bandwidth used by all bridges.
Note:

Before you can manage the bandwidth for bridging, you must first create a
bandwidth-management class configured for bridging. See Chapter 10: “Bandwidth
Management” on page 413 for information about creating and configuring the
bandwidth class.

To Configure Bandwidth Management for Bridging through the Management Console
1.

Select Configuration>Network>Adapters>Bridges.
The Bridges tab displays.

89

Blue Coat ProxySG Configuration and Management Guide

Section D: Software and Hardware Bridges

Figure 4-8: Bridges Tab

2.

In the Bridging Bandwidth Class drop-down menu, select a bandwidth management class to manage
the bandwidth for bridging, or select to disable bandwidth management for bridging.

3.

Click Apply.

To Configure Bandwidth Management for Bridging through the CLI
1.

At the (config) command prompt, enter the following commands:
SGOS#(config) bridge
SGOS#(config bridge) bandwidth-class bw_class_name

where bw_class_name designates the name of the bandwidth class that you have created and
configured to manage the bandwidth for software bridging.
2.

(Optional) To disable bandwidth management for software bridging, enter the following
command:
SGOS#(config bridge) no bandwidth-class

Configuring a Software Bridge
This section describes how to use the Management Console or the CLI to link adapters and interfaces
to create a network bridge.
To Create and Configure a Software Bridge through the Management Console
1.

Select Configuration>Network>Adapters>Bridges.
The Bridges tab displays.

2.

90

In the Software Bridges area, click Create.

Chapter 4: Configuring the System

Section D: Software and Hardware Bridges
3.

In the New Bridge Name field of the dialog that appears, enter a name for the bridge, up to 16
characters; click OK.

4.

In the Bridge IP Address field, enter the IP address of the interface you previously configured (see
"Configuring an Adapter" on page 83).

5.

In the Bridge Subnet Mask field, enter the subnet mask of the interface.

6.

To add a port to the bridge:
a.

In the Ports field, click New; the Create port for bridge dialog appears.

b.

From the drop-down lists, select a port number and adapter interface number; click OK.

c.

By default, link settings are automatically sensed. To change the Duplex and Speed
options, click Link Settings, select Manually configure link settings, and change as required.

d. Click OK.
7.

Further customize the bridge:
a.

In the Software Bridges field, click Settings; the Settings for bridge dialog appears.

b.

In the Security field, the default is to accept inbound connections on this interface. To
disallow inbound connections, select Reject inbound connections.

c.

The default browser instruction is to use the browser’s default PAC file. To instruct the
browser to use a proxy or other PAC file type, make a selection from the list in the Browser
Configuration field.

d. Click OK.
8.

Click Apply.

The Bridge Settings options allow you to clear bridge forwarding table and clear bridge statistics.
To Create or Edit a Software Bridge through the CLI
1.

To create a new software bridge, enter the following commands at the (config) command
prompt:
SGOS#(config) bridge
SGOS#(config bridge) create bridge_name

where bridge_name designates the name of the new bridge. The limit is 16 characters.
2.

To edit the configuration of an existing software bridge, enter the following commands:
SGOS#(config bridge) edit bridge_name

where bridge_name designates the name of the bridge that you want to configure. The
prompt changes to a submode for that bridge.
SGOS#(config bridge bridge_name) ip-address ip_address

where ip_address designates the IP address of the adapter interface you previously
configured (see "Configuring an Adapter" on page 83).
SGOS#(config bridge bridge_name) subnet-mask subnet_mask

where subnet_mask designates the subnet mask of the interface you previously configured.
3.

To configure a port on a bridge, enter the following commands (repeat to add more ports):
SGOS#(config bridge bridge_name) port port_number

91

Blue Coat ProxySG Configuration and Management Guide

Section D: Software and Hardware Bridges
where port_number identifies a port on the interface. This changes the prompt to a submode
for that port number on that bridge.


To attach port to an interface or change the Duplex and Speed options, enter the following
commands:
SGOS#(config bridge bridge_name port port_number) attach-interface
interface_number
SGOS#(config bridge bridge_name port port_number) {full-duplex |
half-duplex}
SGOS#(config bridge bridge_name port port_number) speed {10 | 100 | 1gb}

where:
attach-interface

interface_number

Attaches an interface for this port.

full-duplex

Configures this port for full duplex.

half-duplex

Configures this port for half duplex.

speed

10 | 100 | 1gb

Configures speed for this port.

SGOS#(config bridge bridge_name port port_number) exit
SGOS#(config bridge bridge_name)



By default, link settings are automatically sensed. To perform an auto-sense, enter the
following command:
SGOS#(config bridge bridge_name port port_number) link-autosense



Return to the bridge_name submode:
SGOS#(config bridge bridge_name port port_number) exit
SGOS#(config bridge bridge_name)

4.

To specify the maximum transmission unit (MTU), enter the following command:
SGOS#(config bridge bridge_name) mtu-size size

where size is a value from 72 to 1500.
5.

The default is to accept inbound connections on this interface. To disallow inbound connections,
enter the following command:
SGOS#(config bridge bridge_name) no accept-inbound

6.

The default browser instruction is to use the browser’s default PAC file. To instruct to use a proxy
or other PAC file type, enter the following command:
SGOS#(config bridge bridge_name) instructions {proxy | default-pac |
central-pac url | accelerated-pac}

where:
proxy

Use a proxy.

default-pac

Use the Blue Coat default PAC file.

central-pac

92

url

Use the PAC file specified at the given URL.

Chapter 4: Configuring the System

Section D: Software and Hardware Bridges
accelerated-pac

Use the proxy’s accelerated PAC file.

Configuring Failover
You can configure failover for software bridges, but not for hardware bridges. Failover is
accomplished by creating virtual IP addresses on each proxy, creating a failover group, and attaching
the bridge configuration. One of the proxies must be designated with a higher priority (a master
proxy).
Example
The following example creates a bridging configuration with one bridge on standby.
Note:



This deployment requires a hub on both sides of the bridge or a switch capable of port
mirroring.

ProxySG A—software bridge IP address: 10.0.0.2. Create a virtual IP address and a failover
group, and designate this group the master.
ProxySG_A#(config) virtual-ip address 10.0.0.4
ProxySG_A#(config) failover
ProxySG_A#(config failover) create 10.0.0.4
ProxySG_A#(config failover) edit 10.0.0.4
ProxySG_A#(config failover 10.0.0.3) master
ProxySG_A#(config failover 10.0.0.3) priority 100
ProxySG_A#(config failover 10.0.0.3) interval 1



ProxySG B—software bridge IP address: 10.0.0.3. Create a virtual IP address and a failover
group.
ProxySG_B#(config) virtual-ip address 10.0.0.4
ProxySG_B#(config) failover
ProxySG_B#(config failover) create 10.0.0.4
ProxySG_B#(config failover) edit 10.0.0.4
ProxySG_B#(config failover 10.0.0.3) priority 100
ProxySG_B#(config failover 10.0.0.3) interval 1



In the bridge configuration on each ProxySG, attach the bridge configuration to the failover group:
ProxySG_A#(config bridge bridge_name) failover 10.0.0.4
ProxySG_B#(config bridge bridge_name) failover 10.0.0.4

Static Forwarding Table Entries
Certain firewall configurations require the use of static forwarding table entries. Failover
configurations use virtual IP (VIP) addresses and virtual MAC (VMAC) addresses. When a client
sends an ARP request to the firewall VIP, the firewall replies with a VMAC (which can be an Ethernet
multicast address); however, when the firewall sends a packet, it uses a physical MAC address, not
the VMAC.

93

Blue Coat ProxySG Configuration and Management Guide

Section D: Software and Hardware Bridges
The solution is to create a static forwarding table entry that defines the next hop gateway that is on the
correct side of the bridge.
To Create a Static Forwarding Table Entry through the CLI
1.

At the (config) prompt, enter the following commands:
SGOS#
SGOS#
SGOS#
SGOS#

2.

(config) bridge
(config bridge) edit bridge_name
(config bridge bridge_name) port port_number
(config bridge_name port port_number) static-fwtable-entry mac_address

Add up to 256 entries per bridge.

To Clear a Static Forwarding Table Entry through the CLI
At the (config) prompt, enter the following commands:
SGOS# (config) bridge
SGOS# (config bridge) edit bridge_name
SGOS# (config bridge bridge_name) clear-fwtable

94

Chapter 4: Configuring the System

Section E: Gateways

Section E: Gateways
A key feature of the ProxySG is the ability to distribute traffic originating at the appliance through
multiple gateways. You can also fine tune how the traffic is distributed to different gateways. This
feature works with any routing protocol (such as static routes or RIP).
Note:

Load balancing through multiple gateways is independent from the per-interface load
balancing the ProxySG automatically does when more than one network interface is
installed.

This section discusses:


"About Gateways"



"ProxySG Specifics"



"Switching to a Secondary Gateway"



"Defining Static Routes"

About Gateways
During the initial setup of the ProxySG, you optionally defined a gateway (a device that serves as
entrance and exit into a communications network) for the ProxySG.
By using multiple gateways, an administrator can assign a number of available gateways into a
preference group and configure the load distribution to the gateways within the group. Multiple
preference groups are supported.
The gateway specified applies to all network adapters in the system.

ProxySG Specifics
Which gateway the ProxySG chooses to use at a given time is determined by how the administrator
configures the assignment of preference groups to default gateways. You can define multiple
gateways within the same preference group. A ProxySG can have from 1 to 10 preference groups. If
you have only one gateway, it automatically has a weight of 100.
Initially, all gateways in the lowest preference group are considered to be the active gateways. If a
gateway becomes unreachable, it is dropped from the active gateway list, but the remaining gateways
within the group continue to be used until they all become unreachable, or until an unreachable
gateway in a lower preference group becomes reachable again. If all gateways in the lowest preference
group become unreachable, the gateways in the next lowest preference group become the active
gateways.

95

Blue Coat ProxySG Configuration and Management Guide

Section E: Gateways
In addition to a preference group, each gateway within a group can be assigned a relative weight
value from 1 to 100. The weight value determines how much bandwidth a gateway is given relative to
the other gateways in the same group. For example, in a group with two gateways, assigning both
gateways the same weight value, whether 1 or 100, results in the same traffic distribution pattern. In a
group with two gateways, assigning one gateway a value of 10 and the other gateway a value of 20
results in the ProxySG sending approximately twice the traffic to the gateway with a weight value of
20.

Switching to a Secondary Gateway
When a gateway goes down, the ProxySG takes from 120 to 180 seconds to determine that the
gateway is unreachable. At that point, the ProxySG switches to a secondary gateway if one is
configured.
The ProxySG continues to check failed gateways once a minute using Address Resolution Protocol
(ARP). The gateways are declared unreachable after three attempts. When a preferred gateway comes
back on line, however, it might take up to 180 seconds for the ProxySG to confirm the preferred
gateway is reachable and to switch back to that gateway.
These times are not user-configurable.
To Configure Multiple Gateway Load Balancing through the Management Console
1.

Select Configuration>Network>Routing>Gateways.
The Gateways tab displays.

Figure 4-9: Network Routing Gateways Tab and Add List Item Dialog

96

2.

Click New.

3.

Enter the IP address, group, and weight for the gateway into the Add list item dialog that appears.

4.

Click OK.

5.

Repeat steps 2 to 4 until IP addresses, groups, and weights have been defined for all of your
gateways.

Chapter 4: Configuring the System

Section E: Gateways
6.

Click Apply.

To Configure Multiple Gateway Load Balancing through the CLI
1.

At the (config) command prompt, enter the following command:
SGOS#(config) ip-default-gateway ip_address preference_group weight

The first value is the IP address of the gateway, the second value is the preference group,
and the third value is the relative weighting for this gateway. For example, to use the
gateway 10.25.36.1, the preference group 1, and the relative weighting 100, enter:
ip-default-gateway 10.25.36.1 1 100

2.

Repeat until all IP addresses, groups, and weights of your IP gateways have been defined.

3.

(Optional) View the results.
SGOS#(config) show ip-default-gateway
Default IP gateways
Gateway
Weight
Group
10.25.36.1
100
1

Defining Static Routes
The ProxySG can be configured to use static routes, a manually-configured route that specifies the
transmission path a packet must follow, based on the packet’s destination address. A static route
specifies a transmission path to another network.
Note:

You are limited to 10,000 entries in the static routes table.

You can install the routing table several ways.


Using the ProxySG Text Editor, which allows you to enter settings (or copy and paste the contents
of an already-created file) directly onto the appliance.



Creating a local file on your local system; the ProxySG can browse to the file and install it.



Using a remote URL, where you place an already-created file on an FTP or HTTP server to be
downloaded to the ProxySG.



Using the CLI inline static-route-table command, which allows you to paste a static route
table into the ProxySG.



Using the CLI static-routes command, which requires that you place an already-created file on
an FTP or HTTP server and enter the URL into the ProxySG.

The routing table is a text file containing a list of IP addresses, subnet masks, and gateways. The
following is a sample router table:
10.25.36.0
10.25.37.0
10.25.38.0

255.255.255.0
255.255.255.0
255.255.255.0

10.25.46.57
10.25.46.58
10.25.46.59

When a routing table is loaded, all requested URLs are compared to the list and routed based on the
best match.

97

Blue Coat ProxySG Configuration and Management Guide

Section E: Gateways
To Install a Routing Table through the Management Console
1.

Select Configuration>Network>Routing>Routing.
The Routing tab displays.

Figure 4-10: Network Routing Tab

2.

From the drop-down list, select the method used to install the routing table; click Install.


Remote URL:
Enter the fully-qualified URL, including the filename, where the routing table is located. To
view the file before installing it, click View. Click Install. To view the installation results, click
Results; close the window when you are finished. Click OK.

Figure 4-11: Specifying the Remote Location of a Routing Table



Local File:
Click Browse to bring up the Local File Browse window. Browse for the file on the local
system. Open it and click Install. When the installation is complete, a results window opens.
View the results and close the window.

98

Chapter 4: Configuring the System

Section E: Gateways

Figure 4-12: Specifying the Local Location of a Routing Table



Text Editor:
The current configuration is displayed in installable list format. You can customize it or delete
it and create your own. Click Install. When the installation is complete, a results window
opens. View the results, close this window, and click Close.

99

Blue Coat ProxySG Configuration and Management Guide

Section E: Gateways

Figure 4-13: Creating a Static Routing Table on the ProxySG

3.

Click Apply.

Installing a Routing Table Through the CLI
To install a routing table through the CLI, you can use the inline command to install the table
directly, or enter a path to a remote URL that has an already-created text file ready to download.
When entering input for the inline command, you can correct mistakes on the current line using the
key. If you detect a mistake in a line that has already been terminated using the
key, you can abort the inline command by typing . If the mistake is detected after you
terminate input to the inline command, type the same inline command again, but with the correct
configuration information. The corrected information replaces the information from the last inline
command.
The end-of-input marker is an arbitrary string chosen by the you to mark the end of input for the
current inline command. The string can be composed of standard characters and numbers, but
cannot contain any spaces, punctuation marks, or other symbols.
Take care to choose a unique end-of-input string that does not match any string of characters in the
configuration information.

100

Chapter 4: Configuring the System

Section E: Gateways
To Install a Routing Table through the CLI
Do one of the following:


To paste a static route table directly into the CLI, enter the following command at the (config)
command prompt, then paste the table on the line after the first end-of-file marker:
SGOS#(config) inline static-route-table end-of-file_marker
paste static routing table
eof
ok



To enter the static route table manually, enter the following command, then enter each IP
address/subnet on the second line, following the first end-of-file marker:
SGOS#(config) inline static-route-table end-of-file_marker
10.25.36.0
255.255.255.0
10.25.46.57
10.25.37.0
255.255.255.0
10.25.46.58
10.25.38.0
255.255.255.0
10.25.46.59
eof
ok



To enter a path to a remote URL where you have placed an already-created static route table, enter
the following commands at the (config) command prompt:
SGOS#(config) static-routes path url
SGOS#(config) load static-route-table

101

Blue Coat ProxySG Configuration and Management Guide

Section F: Using RIP

Section F: Using RIP
The Routing Information Protocol (RIP) is designed to select the fastest route to a destination. RIP
support is built into the ProxySG, and is configured by created and installing an RIP configuration text
file onto the ProxySG.
Blue Coat’s RIP implementation also supports advertising default gateways. Default routes added by
RIP are treated the same as the static default routes; that is, the default route load balancing schemes
apply to the default routes from RIP as well.
This section discusses


"Installing RIP Configuration Files"



"Configuring Advertising Default Routes"

Installing RIP Configuration Files
(No RIP configuration file is shipped with the appliance.) For commands that can be entered into the
RIP configuration file, see Appendix D: "RIP Commands" on page 985.
Once you have created an RIP configuration file, you can install it several ways:


Using the ProxySG Text Editor, which allows you to enter settings (or copy and paste the contents
of an already-created file) directly onto the appliance.



Creating a local file on your local system; the ProxySG can browse to the file and install it.



Using a remote URL, where you place an already-created file on an FTP or HTTP server to be
downloaded to the ProxySG.



Using the CLI inline rip-settings command, which allows you to paste the RIP settings into
the CLI.



Using the CLI rip commands, which require that you place an already-created file on an FTP or
HTTP server and enter the URL into the CLI. You can also enable or disable RIP with these
commands.

To Install an RIP Configuration File through the Management Console
Note:

1.

When entering RIP settings that will change current settings (for instance, when
switching from ripv1 to ripv2), disable RIP before you change the settings; re-enable RIP
when you have finished.

Select Configuration>Network>Routing>RIP.
The RIP tab displays.

102

Chapter 4: Configuring the System

Section F: Using RIP

Figure 4-14: Network Routing RIP Tab

2.

To display the current RIP settings, routes, or source, click one or all of the View RIP buttons.

3.

In the Install RIP Setting from the drop-down list, select the method used to install the routing table;
click Install.


Remote URL:
Enter the fully-qualified URL, including the filename, where the routing table is located. To
view the file before installing it, click View. Click Install. To view the installation results, click
Results; close the window when you are finished. Click OK.

Figure 4-15: Specifying the Remote Location of a RIP Configuration File



Local File:
Click Browse to display the Local File Browse window. Browse for the file on the local system.
Open it and click Install. When the installation is complete, a results window opens. View the
results and close the window.

103

Blue Coat ProxySG Configuration and Management Guide

Section F: Using RIP

Figure 4-16: Specifying the Local Location of a RIP File



Text Editor:
The current configuration is displayed in installable list format. You can customize it or delete
it and create your own. Click Install. When the installation is complete, a results window
opens. View the results, close the window, and click OK.

Figure 4-17: Creating an RIP file on the ProxySG

104

4.

Click Apply.

5.

Select Enable RIP.

6.

Click Apply.

Chapter 4: Configuring the System

Section F: Using RIP

Installing RIP Files through the CLI
Note:

When entering RIP settings that will change current settings (for instance, when
switching from ripv1 to ripv2), disable RIP before you change the settings; re-enable RIP
when you have finished.

To Disable/Enable RIP through the CLI
Enter the following command at the (config) command prompt:
SGOS#(config) rip {disable | enable}

To Install an RIP Configuration through the CLI
Do one of the following:


To enter a path to a remote URL where you have placed an already-created RIP configuration file,
enter the following commands at the (config) command prompt:
SGOS#(config) rip path url
SGOS#(config) load rip-settings



To paste an RIP configuration directly into the CLI, enter the following command at the (config)
command prompt:
SGOS#(config) inline rip-settings end-of-file_marker

At this point you can paste RIP settings into the inline command, or you can enter
values for specific settings. When you finish, enter your end-of-file text.
Example
SGOS#(config) inline rip-settings eof
ripv2
ripv1_out
no_rdisc eof
ok

Configuring Advertising Default Routes
Default routes advertisements are treated the same as the static default routes; that is, the default
route load balancing schemes also apply to the default routes from RIP.
By default, RIP ignores the default routes advertisement. You can change the default from disable to
enable and set the preference group and weight through the CLI only. This feature is not available
through the Management Console.
To Enable and Configure Advertising Default Gateway Routes
1.

At the (config) command prompt:
SGOS#(config) rip default-route enable
SGOS#(config) rip default-route group group_number
SGOS#(config) rip default-route weight weight_number

105

Blue Coat ProxySG Configuration and Management Guide

Section F: Using RIP
Where group_number defaults to 1, and weight_number defaults to 100, the same as the static
default route set by the ip-default-gateway command.
2.

(Optional) To view the default advertising routes, enter:
SGOS#(config) show rip default-route
RIP default route settings:
Enabled:
Yes
Preference group:
3
Weight:
30

106

Chapter 4: Configuring the System

Section G: DNS Servers

Section G: DNS Servers
During first-time installation of the ProxySG, you configured the IP address of a single primary
Domain Name Service (DNS) server. Using the Configuration>Network>DNS tab, you can change this
primary DNS server at any time, and you can also define additional primary DNS servers and one or
more alternate DNS servers.
This section discusses:


"ProxySG Specifics"



"Configuring Split DNS Support"



"Changing the Order of DNS Servers"



"Unresolved Host Names (Name Imputing)"



"Changing the Order of DNS Name Imputing Suffixes"



"Caching Negative Responses"

ProxySG Specifics
If you have defined more than one DNS server, the ProxySG uses the following logic to determine
which servers will be used to resolve a DNS host name and when to return an error to the client:


The ProxySG first sends requests to DNS servers in the primary DNS server list.



Servers are always contacted in the order in which they appear in a list.



The next server in a list is only contacted if the ProxySG does not receive a response from the
current server.



If none of the servers in a list returns a response, the ProxySG returns an error to the client.



The ProxySG only sends requests to servers in the alternate DNS server list if a server in the
primary list indicates that a DNS host name cannot be resolved.
If a DNS server returns any other error (other than an indication that a DNS host name could not
be resolved), the ProxySG returns the error to the client.
If a server in both the primary and alternate DNS server lists are unable to resolve a DNS host
name, an error is returned to the client.

The ProxySG always attempts to contact the first server in the primary DNS server. If a response is
received from this server, no attempts are made to contact any other DNS servers in the primary list.
If the response from the first primary DNS server indicates a name error, the ProxySG sends a DNS
request to the first alternate DNS server, if one is defined. If no alternate DNS servers have been
defined, an error is returned to the client indicating a name error. If the first alternate DNS server is
unable to resolve the IP address, a name error is returned to the client, and no attempt is made to
contact any other DNS servers in either the primary or alternate DNS server lists.
If a response is not received from any DNS server in a particular DNS server list, the ProxySG sends a
DNS request to the next server in the list. The ProxySG returns a name error to the client if none of the
servers in a DNS server list responds to the DNS request.

107

Blue Coat ProxySG Configuration and Management Guide

Section G: DNS Servers

Note:

The alternate DNS server is not used as a failover DNS server. It is only used when DNS
resolution of primary DNS server returns name error. If a timeout occurs when looking
up the primary DNS server, no alternate DNS server is contacted.

If the ProxySG receives a negative DNS response (a response with an error code set to Name Error), it
caches that negative response. You can configure the ProxySGs negative response time-to-live value.
(A value of zero disables negative caching.) If the ProxySG is not configured (the default), the
ProxySG caches the negative response and uses the TTL value from the DNS response to determine
how long it should be cached.

Configuring Split DNS Support
Customers with split DNS server configuration (for example, environments that maintain private
internal DNS servers and external DNS servers) might choose to populate an Alternate DNS server
list as well as the Primary DNS server list. In the ProxySG, the internal DNS servers are placed in the
Primary list, while external DNS servers (with the Internet information) populate the Alternate list.
Complete the following procedures to configure Primary and Alternate DNS servers.
To Add a Primary DNS Server through the Management Console
1.

Select Configuration>Network>DNS>DNS.
The DNS tab displays.

Figure 4-18: Network DNS Tab and Add List Item Dialog

108

2.

Click New.

3.

Enter the IP address of the DNS server in the dialog that appears and click OK.

4.

Click Apply.

Chapter 4: Configuring the System

Section G: DNS Servers
To Add a Primary DNS Server through the CLI
At the (config) command prompt, enter the following command:
SGOS#(config) dns server ip_address

To Add an Alternate DNS Server through the Management Console
1.

Select Configuration>Network>DNS>DNS.
The DNS tab displays.

2.

Select Alternate DNS in the drop-down list.

3.

Click New.

4.

Enter the IP address of the DNS server in the dialog that appears and click OK.

5.

Click Apply.

To Add an Alternate DNS Server through the CLI
1.

At the (config) command prompt, enter the following command:
SGOS#(config) dns alternate ip_address

2.

Repeat until alternate DNS servers have been defined.

Changing the Order of DNS Servers
The ProxySG uses DNS servers in the order displayed. You can organize the list of servers so that the
preferred servers appear at the top of the list. This functionality is not available through the CLI.
To Change the Order of DNS Servers through the Management Console
1.

Select Configuration>Network>DNS>Imputing.
The Imputing tab displays.

Figure 4-19: Network DNS Imputing Tab

109

Blue Coat ProxySG Configuration and Management Guide

Section G: DNS Servers
2.

Select the DNS server to promote or demote.

3.

Click Promote entry or Demote entry as appropriate.

4.

Click Apply.

Unresolved Host Names (Name Imputing)
Name imputing allows the ProxySG to resolve host names based on a partial name specification.
When the ProxySG submits a host name to the DNS server, the DNS server resolves the name to an IP
address. The ProxySG queries the original host name before checking imputing entries unless there is
no period in the host name, in which case imputing is applied first. The ProxySG tries each entry in
the name-imputing list until the name is resolved or it comes to the end of the list. If by the end of the
list the name is not resolved, the ProxySG returns a DNS failure.
For example, if the name-imputing list contains the entries company.com and com, and a user submits
the URL http://www.eedept, the ProxySG resolves the host names in the following order.
http://www.eedept
http://www.eedept.company.com
http://www.eedept.com

To Add Names to the Imputing List through the Management Console
1.

Select Configuration>Network>DNS>Imputing.
The Imputing tab displays.

2.

Click New to add a new name to the imputing list.

3.

Enter the name in the dialog that appears and click OK.

4.

Click Apply.

To Add Names to the Imputing List through the CLI
1.

At the (config) command prompt, enter the following command:
SGOS#(config) dns imputing suffix

For example, to use company.com as the imputing suffix, enter dns-imputing company.com.
2.

Repeat until all imputing suffixes have been entered.

Changing the Order of DNS Name Imputing Suffixes
The ProxySG uses imputing suffixes in the order displayed. You can organize the list of suffixes so the
preferred suffix appears at the top of the list. This functionality is only available through the
Management Console. You cannot configure it through the CLI.
To Change the Order DNS Name Imputing Suffixes through the Management Console
1.

Select Configuration>Network>DNS>Imputing.
The Imputing tab displays.

2.

110

Select the imputing suffix to promote or demote.

Chapter 4: Configuring the System

Section G: DNS Servers
3.

Click Promote entry or Demote entry as appropriate.

4.

Click Apply.

Caching Negative Responses
By default, the ProxySG caches negative DNS responses sent by a DNS server. You can configure the
ProxySG to set the time-to-live (TTL) value for a negative DNS response to be cached. You can also
disable negative DNS response caching.
Note:

The ProxySG generates more DNS requests when negative caching is disabled.

Both type A and type PTR DNS responses are affected by negative caching.
This functionality is only available through the CLI. You cannot configure DNS negative caching
through the Management Console.
To Configure Negative Caching TTL Values
From the (config) prompt:
SGOS#(config) dns negative-cache-ttl-override seconds

where seconds is any integer between 0 and 600.
Setting the TTL value to 0 seconds disables negative DNS caching; setting the TTL setting to a
non-zero value overrides the TTL value from the DNS response.
To Restore Negative Caching Defaults
From the (config) prompt):
SGOS#(config) dns no negative-cache-ttl-override

111

Blue Coat ProxySG Configuration and Management Guide

Section H: Attack Detection

Section H: Attack Detection
The ProxySG can reduce the effects of distributed denial of service (DDoS) attacks and port scanning,
two of the most common virus infections.
A DDoS attack occurs when a pool of machines that have been infected with a DDoS-type of virus
attack a specific Web site. As the attack progresses, the target host shows decreased responsiveness
and often stops responding. Legitimate HTTP traffic is unable to proceed because the ProxySG is still
waiting for a response from the target host.
Port scanning involves viruses attempting to self-propagate to other machines by arbitrarily trying to
connect to other hosts on the Internet. If the randomly selected host is unavailable or behind a firewall
or does not exist, the ProxySG continues to wait for a response, thus denying legitimate HTTP traffic.
The ProxySG prevents attacks by limiting the number of simultaneous TCP connections from each
client IP address and either does not respond to connection attempts from a client already at this limit
or resets the connection. It also limits connections to servers known to be overloaded.
You can configure attack detection for both clients and servers or server groups, such as
http://www.bluecoat.com. The client attack-detection configuration is used to control the behavior of
virus-infected machines behind the ProxySG. The server attack-detection configuration is used when
an administrator knows ahead of time that a virus is set to attack a specific host.
This feature is only available through the CLI. You cannot use the Management Console to enable
attack detection.
This section discusses:


"Configuring Attack-Detection Mode for the Client"



"Configuring Attack-Detection Mode for a Server or Server Group"

Configuring Attack-Detection Mode for the Client
To Enter Attack-Detection Mode for the Client
From the (config) prompt, enter the following commands:
SGOS#(config) attack-detection
SGOS#(config attack-detection) client

The prompt changes to:
SGOS#(config client)

To Change Global Settings
The following defaults are global settings, used if a client does not have specific limits set. They do not
need to be changed for each IP address/subnet if they already suit your environment:

112



client limits enabled: true



client interval: 20 minutes



block-action: drop (for each client)

Chapter 4: Configuring the System

Section H: Attack Detection


connection-limit: 100 (for each client)



failure-limit: 50 (for each client)



unblock-time: unlimited



warning-limit: 10 (for each client)

To Change the Global Defaults
Remember that enable/disable limits and interval affect all clients. The values cannot be changed for
individual clients. Other limits can be modified on a per-client basis.
Note:

If you edit an existing client’s limits to a smaller value, the new value only applies to new
connections to that client. For example, if the old value was 10 simultaneous connections
and the new value is 5, existing connections above 5 are not dropped.

SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config

client)
client)
client)
client)
client)
client)
client)
client)

enable-limits | disable-limits
interval minutes
block ip_address [minutes] | unblock ip_address
default block-action drop | send-tcp-rst
default connection-limit integer_between_1_and_65535
default failure-limit integer_between_1_and_500
default unblock-time minutes_between_10_and_1440
default warning-limit integer_between_1_and_100

where:
Toggles between enabled and disabled. The default is
disabled. This is a global setting and cannot be modified
for individual clients.

enable-limits |
disable-limits

interval

integer

Indicates the amount of time, in multiples of 10 minutes,
that client activity is monitored. The default is 20. This is a
global setting and cannot be modified for individual
clients.

block | unblock

ip_address
[minutes]

Blocks a specific IP address for the number of minutes
listed. If the optional minutes argument is omitted, the
client is blocked until explicitly unblocked. Unblock
releases a specific IP address.

default
block-action

drop |
send-tcp-rst

Indicates the behavior when clients are at the maximum
number of connections or exceed the warning limit: drop
the connections that are over the limit or send TCP RST
for connections over the limit. The default is drop. This
limit can be modified on a per-client basis.

default
connection-limit

integer

Indicates the number of simultaneous connections
between 1 and 65535. The default is 100. This limit can be
modified on a per-client basis.

113

Blue Coat ProxySG Configuration and Management Guide

Section H: Attack Detection
default
failure-limit

integer

Indicates the maximum number of failed requests a client
is allowed before the proxy starts issuing warnings.
Default is 50. This limit can be modified on a per-client
basis.

default
unblock-time

minutes

Indicates the amount of time a client is blocked at the
network level when the client-warning-limit is exceeded.
Time must be a multiple of 10 minutes, up to a maximum
of 1440. The default is unlimited. This limit can be
modified on a per-client basis.

default
warning-limit

integer

Indicates the number of warnings sent to the client before
the client is blocked at the network level and the
administrator is notified. The default is 10; the maximum
is 100. This limit can be modified on a per-client basis.

To Create and Edit a Client IP Address through the CLI
1.

Make sure you are in the attack-detection client submode.
SGOS#(config) attack-detection
SGOS#(config attack-detection) client
SGOS#(config client)

2.

Create a client.
SGOS#(config client) create client ip_address or ip_address_and_length

3.

Move to edit client submode.
SGOS#(config client) edit client_ip_address

The prompt changes to:
SGOS#(config client ip_address)

4.

Change the client limits as necessary.
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config

client
client
client
client
client

ip_address)
ip_address)
ip_address)
ip_address)
ip_address)

block-action drop | send-tcp-rst
connection-limit integer_between_1_and_65535
failure-limit integer_between_1_and_65535
unblock-time minutes
warning-limit integer_between_1_and_65535

where:

114

block-action

drop |
send-tcp-rst

Indicates the behavior when the client is at the maximum
number of connections: drop the connections that are over
the limit or send TCP RST for the connection over the
limit. The default is drop.

connection-limit

integer

Indicates the number of simultaneous connections
between 1 and 65535. The default is 100.

failure-limit

integer

Indicates the behavior when the specified client is at the
maximum number of connections: drop the connections
that are over the limit or send TCP RST for the connection
over the limit. The default is 50.

Chapter 4: Configuring the System

Section H: Attack Detection
unblock-time

minutes

Indicates the amount of time a client is locked out at the
network level when the client-warning-limit is exceeded.
Time must be a multiple of 10 minutes, up to a maximum
of 1440. The default is unlimited.

warning-limit

integer

Indicates the number of warnings sent to the client before
the client is locked out at the network level and the
administrator is notified. The default is 10; the maximum
is 100.

To View the Specified Client Configuration
Enter the following command from the edit client submode:
SGOS#(config client ip_address)
Client limits for 10.25.36.47:
Client connection limit:
Client failure limit:
Client warning limit:
Blocked client action:
Client connection unblock time:

view
700
50
10
Drop
unlimited

To View the Configuration for all Clients
1.

Exit from the edit client submode:
SGOS#(config client ip_address) exit

2.

Use the following syntax to view the client configuration:
view | blocked | connections | statistics

To View All Settings
SGOS#(config client) view
Client limits enabled:
Client interval:

true
20 minutes

Default client limits:
Client connection limit:
100
Client failure limit:
50
Client warning limit:
10
Blocked client action:
Drop
Client connection unblock time:
unlimited
Client limits for 10.25.36.47:
Client connection limit:
Client failure limit:
Client warning limit:
Blocked client action:
Client connection unblock time:

700
50
10
Drop
unlimited

115

Blue Coat ProxySG Configuration and Management Guide

Section H: Attack Detection
To View the Number of Simultaneous Connections to the ProxySG
SGOS#(config client) view connections
Client IP
Connection Count
127.0.0.1
1
10.9.16.112
1
10.2.11.133
1

To View the Number of Blocked Clients
SGOS#(config client) view blocked
Client
Unblock time
10.11.12.13
2004-07-09 22:03:06+00:00UTC
10.9.44.73
Never

To View Client Statistics
SGOS#(config client) view statistics
Client IP
Failure Count
10.9.44.72
1

Warning Count
0

To Disable Attack-Detection Mode for all Clients
SGOS#(config client) disable-limits

Configuring Attack-Detection Mode for a Server or Server Group
You can create, edit, or delete a server. A server must be created before it can be edited. You can treat
the server as an individual host or you can add other servers, creating a server group. All servers in
the group have the same attack-detection parameters, meaning that if any server in the group gets the
maximum number of simultaneous requests, all servers in the group are blocked.
To Create a Server or Server Group
1.

At the (config) prompt, enter the following commands:
SGOS#(config) attack-detection
SGOS#(config attack-detection) server

The prompt changes to:
SGOS#(config server)

2.

Create the first host in a server group, using the fully qualified domain name:
SGOS#(config server) create hostname

To Edit a Server or Server Group
At the (config server) prompt, enter the following commands:
SGOS#(config server) edit hostname

The prompt changes to (config server hostname).
SGOS#(config server hostname) {add | remove} hostname
SGOS#(config server hostname) request-limit integer_from_1_to_65535

116

Chapter 4: Configuring the System

Section H: Attack Detection
where:
The name of a previously created server or server group. When
adding a hostname to the group, the hostname does not have to
be created. The host that was added when creating the group
cannot be removed.

hostname

add | remove

hostname

Adds or removes a server from this server group.

request-limit

integer

Indicates the number of simultaneous requests allowed from this
server or server group. The default is 1000.

To View the Server or Server Group Configuration
SGOS#(config server hostname) view
Server limits for hostname:
Request limit:
1500

117

Blue Coat ProxySG Configuration and Management Guide

Section I: Using a Bypass List

Section I: Using a Bypass List
A bypass list can be used to completely skip all ProxySG processing of requests sent to specific
destination hosts or subnets. This prevents the appliance from enforcing any policy on these requests
and disables any caching of the corresponding responses, so it should be used with care. A bypass list
allows traffic to pass through to sites as-is when servers at the site are not properly adhering to
protocol standards or when the processing in the ProxySG is otherwise causing problems.
The bypass list contains IP addresses, subnet masks, and gateways. When a request matches an IP
address and subnet mask specification in the bypass list, the request is sent to the designated gateway
and is not processed by the ProxySG.
Note:

Because a bypass list bypasses Blue Coat policy, bypass lists should be used sparingly
only for specific situations.

Blue Coat supports three types of bypass lists: local list, central list, and policy-based (dynamic
bypass) list. The bypass lists all work together, or you can just create and maintain one.
Note:

The Local List and Central List are not the same as the Local Policy file and the Central
Policy file.

This section discusses:


"Using the Local Bypass List"



"Using the Central Bypass List"



"Creating and Installing Local or Central Bypass Lists"



"Using Policy to Configure Dynamic Bypass Lists"

Using the Local Bypass List
The local bypass list is one you create and maintain on your network. You can use a local bypass list
alone, or in conjunction with a central list.
The gateways specified in the bypass list must be on the same subnet as the ProxySG. The local bypass
list limit is 10,000 entries.
The local bypass list contains a list of IP addresses, subnet masks, and gateways. It can also define the
default bypass gateway to be used by both the local bypass list and central bypass list. The gateways
specified in the bypass list must be on the same subnet as the ProxySG. When you download a bypass
list, the list is stored in the appliance until it is replaced by downloading a new list.
Note:

Because a bypass list bypasses Blue Coat policy, bypass lists should be used sparingly
only for specific situations.

The following is a sample of a local bypass list:

118

Chapter 4: Configuring the System

Section I: Using a Bypass List
;define the default gateway for the local and central bypass list
BYPASS_GATEWAY 10.25.46.57
;define addresses to bypass
;IP address
subnet
gateway (or use default gateway)
10.25.36.47
255.255.255.255
10.25.36.48
255.255.255.255
10.25.0.0
255.255.255.0
10.25.46.58

If you do not specify the bypass_gateway and you do not designate the gateway in the address
specification, the ProxySG forwards the request to the default gateway defined in the network
configuration.
For installation procedures for the local bypass list, see "Creating and Installing Local or Central
Bypass Lists" on page 119.

Using the Central Bypass List
The central bypass list is usually a shared list of addresses that is used by multiple ProxySG
Appliances. Since each ProxySG Appliance can be located on a different subnet and can be using
different gateways, the central bypass list should not contain any gateway addresses.
The gateway used for matches in the central bypass list is the gateway specified by the
bypass_gateway command in the local bypass list. If there is no bypass_gateway option, the ProxySG

uses the default gateway defined by the network configuration.
Note:

Because a bypass list bypasses Blue Coat policy, bypass lists should be used sparingly
only for specific situations.

You can create your own central bypass list to manage multiple ProxySG Appliances, or you can use
the central bypass list maintained by Blue Coat Technical Support at:
https://download.bluecoat.com/release/SG4/files/CentralBypassList.txt

Note:

The central bypass list is limited to 10,000 entries.

You can select whether to download the list automatically when it changes or to receive an e-mail
notifying you of the update. By default, neither is enabled.
For installation procedures for the central bypass list, continue with the next section.

Creating and Installing Local or Central Bypass Lists
You can install the local and central bypass lists several ways


Use the ProxySG Text Editor, which allows you to enter the lists (or copy and paste the contents of
an already-created file) directly onto the ProxySG through the Management Console (see the
instructions below).



Create a local file on your local system; use the Management Console to browse to the file and
install it (see the instructions below).

119

Blue Coat ProxySG Configuration and Management Guide

Section I: Using a Bypass List


Use a remote URL, where you place an already-created file on an FTP or HTTP server to be
downloaded to the ProxySG. This can be done through either the Management Console or the CLI
(see the instructions below).



Use the CLI inline bypass-list {central | local} command, which allows you to paste the
configurations onto the ProxySG (see the instructions below). For more information on using the
CLI inline command, see "Using the Local Bypass List" on page 118 or "Using the Central Bypass
List" on page 119.

To Install Bypass Lists through the Management Console
1.

Select Configuration>Network>Advanced>Bypass List.
The Bypass List tab displays.

Figure 4-20: Bypass List Tab

2.

To view the current bypass list or the source for the current bypass list before installing it, click
Bypass List or Source.

3.

(Optional) If installing the central bypass list, you can select whether to download the list
automatically when it changes, or be sent an e-mail notifying you of the update. By default,
neither is enabled.

4.

Select a method to install the file for either the local or central bypass list; click Install.


Remote URL:
Enter the fully-qualified URL, including the filename, where the routing table is located. To
view the file before installing it, click View. Click Install. View the installation status that
displays; click OK.

120

Chapter 4: Configuring the System

Section I: Using a Bypass List

Figure 4-21: Specifying the Remote Location of a Local Bypass List Configuration File



Local File:
Click Browse to bring up the Local File Browse window. Browse for the file on your local
system. Open it and click Install. When the installation is complete, a results window opens.
View the results, close the window, and click Close.

Figure 4-22: Specifying the Local Location of a Local Bypass List



Text Editor:
The current configuration is displayed in installable list format. You can customize it or delete
it and create your own. Click Install. When the installation is complete, a results window
opens. View the results, close the window, and click Close.

121

Blue Coat ProxySG Configuration and Management Guide

Section I: Using a Bypass List

Figure 4-23: Creating a Local Bypass List on the ProxySG

5.

Click Apply.

To Install an Already-Existing Bypass List through the CLI
At the (config) command prompt, enter the following commands:
SGOS#(config) bypass-list {local-path | central-path} url
SGOS#(config) load bypass-list {local | central}

To Install a Bypass List through the CLI inline Command
At the (config) command prompt, enter the following command:
SGOS#(config) inline bypass-list {local | central} end-of-file_marker

At this point you can paste in local or central configuration files, or you can enter values
for specific settings, such as server_bypass_threshold, max_dynamic_bypass_entry
or dynamic_timeout. When you finish, enter your end-of-file string.
Example
SGOS#(config) inline bypass-list local eof
max_dynamic_bypass_entry 20000
server_bypass_threshold 30
dynamic_timeout 100 eof
ok

122

Chapter 4: Configuring the System

Section I: Using a Bypass List

Using Policy to Configure Dynamic Bypass Lists
Dynamic bypass, available through policy (VPM or CPL), can automatically compile a list of
requested URLs that return various kinds of errors. The policy-based bypass list is maintained in the
Forward Policy file or Local Policy file.
Note:

Because a bypass list bypasses Blue Coat policy, bypass lists should be used sparingly
only for specific situations.

Dynamic bypass keeps its own (dynamic) list of which connections to bypass, where connections are
identified by both source and destination rather than just destination. Dynamic bypass can be based
on any combination of policy triggers. In addition, some global settings in HTTP configuration can be
used to selectively enable dynamic bypass based on specific HTTP response codes. Once 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 lists.
With dynamic bypass, the ProxySG adds dynamic bypass entries containing the specific
source/destination IP pair for sites that have returned an error to the appliance’s local bypass list. For
a configured period of time, further requests for the error-causing URLs are sent immediately to the
origin content server (OCS), saving the ProxySG processing time. 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 URL has ended, the ProxySG removes the URL from the
bypass list. On the next client request for the URL, the ProxySG attempts to contact the OCS. If the
OCS still returns an error, the URL is once again added to the local bypass list for the configured
dynamic bypass timeout. If the URL does not return an error, the request is handled in the normal
manner.

Limitations


Dynamic bypass applies to transparent proxy connections only.



Dynamic bypass entries are lost when the ProxySG is restarted or the static bypass file is
reinstalled.



No filtering checks are performed on client requests that match entries in the dynamic bypass list.



Requests to sites that are put into the dynamic bypass list bypass future policy evaluation. If a site
that requires forwarding policy to reach its destination is populated into the bypass list, the site
might be inaccessible.



Sites requiring that client accesses always be subjected to ProxySG filtering considerations must
either use the appliance in explicit proxy mode or leave dynamic bypass functionality disabled.

123

Blue Coat ProxySG Configuration and Management Guide

Section I: Using a Bypass List

Configuring Dynamic Bypass
Dynamic bypass is disabled by default. Enabling and fine-tuning dynamic bypass is a two-step
process:


Edit or create a local bypass list, adding the desired dynamic bypass timeout and threshold
parameters.



Use the CLI to enable dynamic bypass and set the types of errors that cause dynamic bypass to
add an entry to the bypass list.

Adding Dynamic Bypass Parameters to the Local Bypass List
The first step in configuring dynamic bypass is to edit the local bypass list to set the
server_bypass_threshold, max_dynamic_bypass_entry, or dynamic_timeout values.

Note:

This step is optional because the ProxySG uses default configurations if you do not
specify them in the local bypass list. 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_bypass_threshold value defines the maximum number of entries in the
dynamically generated portion of the local bypass list before the ProxySG consolidates
client–server pair entries into a single server entry. 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
dynamic_timeout.



The max_dynamic_bypass_entry defines the maximum number of total dynamic bypass entries.
The range is 1 to 50,000. The default value is 16,000. When the number of entries exceeds the
max_dynamic_bypass_entry value, the oldest entries are removed to make way for new entries.



The dynamic_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 6000. 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.
To Enable Dynamic Bypass and Trigger Events through the CLI
At the (config) command prompt, enter the following commands:
SGOS#(config) dynamic-bypass enable
SGOS#(config) dynamic-bypass trigger trigger_event

where trigger_event can be any item in listed in Table 4.1, below.

124

Chapter 4: Configuring the System

Section I: Using a Bypass List
Enabling dynamic bypass causes the following warning to appear:
WARNING:
Requests to sites that are put into the dynamic bypass list will bypass
future policy evaluation. This could result in subversion of on-box policy.
The use of dynamic bypass is cautioned.
Table 4.1: Values for the Dynamic-Bypass Trigger Event
Event

Description

all

Enables all dynamic bypass triggers.

non-http

Enables dynamic bypass for non-HTTP responses.

connect-error

Enables dynamic bypass for any connection failure to the origin content server, including
timeouts.

receive-error

Enables dynamic bypass for when a TCP connection to an origin content server succeeds,
but the cache does not receive an HTTP response.

400

Enables dynamic bypass for HTTP 400 responses.

401

Enables dynamic bypass for HTTP 401 responses.

403

Enables dynamic bypass for HTTP 403 responses.

405

Enables dynamic bypass for HTTP 405 responses.

406

Enables dynamic bypass for HTTP 406 responses.

500

Enables dynamic bypass for HTTP 500 responses.

502

Enables dynamic bypass for HTTP 502 responses.

503

Enables dynamic bypass for HTTP 503 responses.

504

Enables dynamic bypass for HTTP 504 responses.

Example
For instance, the following command will enable connection error events:
SGOS#(config) dynamic-bypass trigger connect-error

Bypassing Connection and Receiving Errors
In addition to HTTP code triggers, you can configure the ProxySG to trigger dynamic bypass for
connection and receiving errors.
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. In this instance, the
ProxySG bypasses any connection attempts from the client to this IP address. By default, the timeout
duration is 20 seconds, and the retry count is 3. These parameters are not configurable. Both the
timeout duration and the retry attempt, whichever occurs first, triggers connect-error.

125

Blue Coat ProxySG Configuration and Management Guide

Section I: Using a 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. In this
instance, the appliance bypasses any attempts from the client to this IP address. Server timeouts can
also trigger receive-error. The default timeout value is 180 seconds, which can be changed (see
"Configuring HTTP Timeout" on page 75).

Disabling Dynamic Bypass Triggers
Disabling one or more specific dynamic bypass triggers is an easy way to customize which errors
cause a dynamic bypass entry to be created. For example, if you want all error events except 401
responses to create a dynamic bypass entry, you can enable all triggers and then disable only the
401-event trigger.
To Disable One or More Dynamic Bypass Triggers through the CLI
At the (config) command prompt, enter the following command:
SGOS#(config) dynamic-bypass no trigger event

where event can be any item listed above in Table 4.1.
To Clear the Dynamic Bypass List through the CLI
At the (config) command prompt, enter the following command:
SGOS#(config) dynamic-bypass clear

To Disable Dynamic Bypass through the CLI
At the (config) command prompt, enter the following command:
SGOS#(config) dynamic-bypass disable

Viewing the Dynamic Bypass List
You can view the dynamic bypass list several ways:
To Display the Dynamic Bypass List through the CLI
At the (config) command prompt, enter the following command:
SGOS#(config) show bypass-list

To Display the Dynamic Bypass List through the Management Console
In a Web browser, enter the following URL:
https://ip_address_of_ProxySG:8082/TCP/IP-bypass

To View the Current Dynamic Bypass Configuration through the CLI
At the (config) command prompt, enter the following command:
SGOS#(config) show dynamic-bypass

126

Chapter 4: Configuring the System

Section I: Using a Bypass List
To Disable Dynamic Bypass through the CLI
At the (config) command prompt, enter the following command:
SGOS#(config) dynamic-bypass disable

127

Blue Coat ProxySG Configuration and Management Guide

Section J: Installing WCCP Settings

Section J: Installing WCCP Settings
The ProxySG can be configured to participate in a WCCP (Web Cache Control Protocol) scheme,
where a WCCP-capable router collaborates with a set of WCCP-configured ProxySG Appliances to
service requests.
Before you can install the WCCP configurations, you must create a WCCP configuration file for the
ProxySG. The ProxySG does not ship with a default WCCP configuration file.
You can install the WCCP settings several ways:


Using the ProxySG Text Editor, which allows you to enter settings (or copy and paste the contents
of an already-created file) directly onto the appliance.



Creating a local file on your local system; the ProxySG can browse to the file and install it.



Using a remote URL, where you place an already-created file on an FTP or HTTP server to be
downloaded to the ProxySG.



Using the CLI inline wccp-settings command, which allows you to paste the WCCP settings
into the CLI.



Using the CLI wccp command, which requires that you place an already-created file on an FTP or
HTTP server and enter the URL into the CLI.

For more information about WCCP, see Appendix C: "Using WCCP" on page 957.
To Install WCCP Settings through the Management Console
1.

Select Configuration>Network>Advanced>WCCP.
The WCCP tab displays.

Figure 4-24: Network Advanced WCCP Tab

2.

From the drop-down list, select the method used to install the WCCP settings; click Install.


128

Remote URL:

Chapter 4: Configuring the System

Section J: Installing WCCP Settings
Enter the fully-qualified URL, including the filename, where the WCCP file is located. To
view the file before installing it, click View. Click Install. Viewing the installation status that
displays; click OK.

Figure 4-25: Specifying the Remote Location of a WCCP Settings File



Local File:
Click Browse to display the Local File Browse window. Browse for the file on the local system.
Open it and click Install. When the installation is complete, a results window opens. View the
results, close the window, and click Close.

Figure 4-26: Specifying the Local Location of a WCCP Settings File



Text Editor:
The current configuration is displayed in installable list format. You can customize it or delete
it and create your own. Click Install. When the installation is complete, a results window
opens. View the results, close the window, and click Close.

129

Blue Coat ProxySG Configuration and Management Guide

Section J: Installing WCCP Settings

Figure 4-27: Creating a WCCP Settings File on the ProxySG

3.

Click Apply.

To Install WCCP settings through the CLI
Do one of the following:


To enter WCCP settings directly onto the ProxySG, enter the following commands at the
(config) command prompt:
SGOS#(config) inline wccp-settings end-of-file_marker
wccp enable
wccp version 2
service-group 9
priority 1
protocol 6
service-flags destination-ip-hash
service-flags ports-defined
ports 80 21 1755 554 80 80 80 80
interface 6
home-router 10.16.18.2
forwarding l2
eof

Note:

130

For detailed instructions on configuring an WCCP file, see Appendix C: "Using
WCCP" on page 957.

Chapter 4: Configuring the System

Section J: Installing WCCP Settings


To enter a path to a remote URL where you have placed an already-created static route table, enter
the following commands at the (config) command prompt:
SGOS#(config) wccp path url

where url is a fully qualified URL, including the filename, where the configuration file is
located.
SGOS#(config) load wccp-settings
SGOS#(config) wccp enable

131

Blue Coat ProxySG Configuration and Management Guide

Section K: Virtual IP Addresses

Section K: Virtual IP Addresses
Virtual IP (VIP) addresses are addresses assigned to a system that are recognized by other systems on
the network. Up to 255 VIPs can be configured on each ProxySG. They have several uses:


Assign multiple identities to a system on the same or different network, partitioning the box in to
separate logical entities for resource sharing or load sharing.



Create an HTTPS Console to allow multiple, simultaneous, secure connections to the system.



Direct authentication challenges to different realms.



Set up failover among multiple ProxySG s on the same subnet.

For information on creating an HTTPS Console, see "Creating and Editing Services" on page 152; for
information on using VIPs with authentication realms, see Chapter 9: “Using Authentication Services”
on page 299; to use VIPs with failover, see "Configuring Failover" on page 134.
To Create a VIP through the Management Console
1.

Select Configuration>Network>Advanced>VIPs.
The VIPs tab displays.

Figure 4-28: Network Advanced VIPs Tab

2.

Click New.
The Add VIP dialog displays.

3.

Enter the virtual IP address you want to use. It can be any IP address, except a multicast address.
(A multicast address is a group address, not an individual IP address.)
Note:

132

You cannot create a VIP address that is the IP address used by the origin content server.
You must assign a different address on the ProxySG, and use DNS or forwarding to point
to the origin content server's real IP address.

Chapter 4: Configuring the System

Section K: Virtual IP Addresses
4.

Click OK; click Apply.

The VIP address can now be used.
To Create a VIP through the CLI
At the (config) command prompt, run the virtual IP address command:
SGOS#(config) virtual address ip_address
ok

To Delete a VIP through the CLI
Note that VIP addresses are deleted silently. If you are using a VIP for a service, the service will no
longer work once the VIP is deleted.
SGOS#(config) virtual no address ip_address
ok

To Clear All VIP Addresses in the System
SGOS#(config) virtual clear
ok

To View All the VIPs in the System
SGOS#(config) show virtual
Virtual IP addresses:
SGOS#(config) accelerated-pac path 10.25.36.47
10.9.36.47
10.25.36.48
10.25.36.47

133

Blue Coat ProxySG Configuration and Management Guide

Section L: Configuring Failover

Section L: Configuring Failover
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. For
information on creating software bridges, see "About Bridging" on page 88.
Note:

If you use the Pass-Through adapter for transparent proxy, you must create a software
bridge rather than configuring failover. For information on using the Pass-Through
adapter, see "About the Pass-Through Adapter" on page 88.

Using a pool of IP addresses to provide redundancy and load balancing, Blue Coat migrates these IP
addresses among a group of machines.
This section discusses:


"About Failover"



"Configuring Failover"



"Viewing Statistics"

About Failover
Failover allows a second machine to take over if a first machine fails, providing redundancy to the
network through a master/slave 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 slaves. If the slaves do not receive advertisements at the specified interval, the
slave with the highest configured priority takes over for the master. When the master comes back
online, the master takes over from the slave 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 advertisements’ interval is included in protocol messages and is learned by the slaves.



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 have 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 slaves.

When a slave takes over because the master fails, an event is logged in the event log. No e-mail
notification is sent.

134

Chapter 4: Configuring the System

Section L: Configuring Failover

Configuring Failover
Before you begin, be aware that software bridges must already exist before you can use them to
configure failover. For information on configuring bridges, see "Adapters" on page 83.
You also need to decide which machine is the master and which machines are the slaves, and whether
you want to configure explicit proxy or transparent proxy network.
When configuring the group, the master and all the systems in the group must have exactly the same
failover configuration except for priority, which is used to determine the rank of the slave machines. If
no priority is set, a default priority of 100 is used. If two ProxySG Appliances have equal priority, the
one with the highest physical address ranks higher.
To Configure Failover through the Management Console
1.

Go to Configuration>Network>Advanced>Failover.
The Failover tab displays.

Figure 4-29: Network Advanced Failover Tab

2.

Click New.
The Add Failover Group dialog displays.

135

Blue Coat ProxySG Configuration and Management Guide

Section L: Configuring Failover

Figure 4-30: Add Failover Group Dialog

3.

In the Add Failover Group dialog that appears, fill in the fields as appropriate:


Create a 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.



The enabled option specifies whether this group is active or inactive. Select enabled to enable
the failover group.



Multicast address refers to a Class D IP address that is used for multicast. It is not a virtual 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 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.

4.

136



(Optional) Master identifies the system with the highest priority.



(Optional) Advertisement Interval refers to the length of time between advertisements sent by
the group master. The default is 40 seconds. Once the group master has failed, the slave with
the highest priority takes over (after approximately three times the interval value). The
failover time of the group can be controlled by setting this value.



(Optional, but recommended) Group Secret refers to a password shared only with the group.

Click OK; click Apply.

Chapter 4: Configuring the System

Section L: Configuring Failover
To Configure Failover through the CLI
1.

At the (config) command prompt, enter the following commands:
SGOS#(config) failover
SGOS#(config failover) create group_address

The IP address does not have to exist.
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
-orSGOS#(config
SGOS#(config

failover) edit group_address
failover group_address) multicast-address multicast_address
failover group_address) master
failover group_address) priority number
failover group_address) interval seconds
failover group_address) secret secret
failover group_address) encrypted-secret encrypted_secret
failover group_address) enable

where:

2.

group_address

Refers to the IP address or VIP address that is monitored by this group.
Once the group has been named, you cannot change the name. To
change the name, you must delete the group and start over.

multicast-address
multicast_address

Refers to a multicast address where the master sends the keepalives
(advertisements) to the slave systems.

master

(Optional) Identifies the system to be used as the master.

no

Negates these settings: multicast-address, priority, interval, secret, and
master.

priority number

(Optional) Refers to the rank of slave systems. The range is from 1 to
254. (The master system, the one whose IP address matches the group
address, gets 255.) Output of show config and show failover
might differ when the master system is also the holder of the physical
IP address.

interval seconds

(Optional) Refers to the time between advertisements from the master
to the multicast address. The default is 40 seconds. Entering no
interval resets the interval to the default time of 40 seconds.

secret secret
-orencrypted-secret
encrypted_secret

(Optional but recommended) Refers to a password shared only with
the group. You can create a secret, which then is hashed, or you can
provide an encrypted secret.

enable | disable

Enables or disables failover on the ProxySG.

(Optional) View the results.
SGOS#(config) show failover configuration group_address
Failover Config
Group Address: 10.25.36.47
Multicast Address
: 224.1.2.3
Local Address
: 10.9.17.159

137

Blue Coat ProxySG Configuration and Management Guide

Section L: Configuring Failover
Secret
: none
Advertisement Interval: 40
Priority
: 100
Current State
: DISABLED
Flags
: V M

Three flags exist, set as you configure the group.
V—Specifies the group name is a virtual IP address.
R—Specifies the group name is a physical IP address
M—Specifies this machine can be configured to be the master if it is available

3.

(Optional) You can view Failover Group Statistics
These are all integers/counters that count various events.
SGOS#(config) show failover statistics
Failover Statistics
Advertisements Received
: 0
Advertisements Sent
: 194
States Changes
: 2
Bad Version
: 0
Bad Packet
: 0
Bad Checksum
: 0
Packet Too Short
: 0
Bad Packet Header
: 0
Invalid Group
: 0

Viewing Statistics
To view statistics on failover, see "Failover Statistics" on page 897

138

Chapter 4: Configuring the System

Section M: TCP/IP Configuration

Section M: TCP/IP Configuration
Use the TCP/IP configuration options to enhance the performance and security of the ProxySG.
Except for IP Forwarding (see "Understanding IP Forwarding" on page 226), these commands are only
available through the CLI.


RFC-1323: Enabling RFC-1323 support enhances the high-bandwidth and long-delay operation of
the ProxySG over very high-speed paths, ideal for satellite environments.



TCP NewReno: Enabling TCP NewReno support improves the fast recovery of the ProxySG.



ICMP Broadcast Echo: Disabling the response to these messages can limit security risks and
prevent an attacker from creating a distributed denial of service (DDoS) to legitimate traffic.



ICMP Timestamp Echo: Disabling the response to these messages can prevent an attacker from
being able to reverse engineer some details of your network infrastructure.



TCP Window Size: configures the amount of unacknowledged TCP data that the ProxySG can
receive before sending an acknowledgement.



PMTU Discovery: Enabling PMTU Discovery prevents packets from being unable to reach their
destination because they are too large.

To view the TCP/IP configuration, see "Viewing the TCP/IP Configuration" on page 142.
This section discusses


"RFC-1323"



"TCP NewReno"



"ICMP Broadcast Echo Support"



"ICMP Timestamp Echo Support"



"TCP Window Size"



"PMTU Discovery"



"TCP Time Wait"



"Viewing the TCP/IP Configuration"

RFC-1323
The RFC-1323 TCP/IP option enables the ProxySG to use a set of extensions to TCP designed to
provide efficient operation over large bandwidth-delay-product paths and reliable operation over
very high-speed paths, including satellite environments. RFC-1323 support can only be configured
through the CLI, and is enabled by default.
To Enable or Disable RFC-1323 Support through the CLI
At the (config) command prompt, enter the following command:
SGOS#(config) tcp-ip rfc-1323 {enable | disable}

139

Blue Coat ProxySG Configuration and Management Guide

Section M: TCP/IP Configuration

TCP NewReno
NewReno is a modification of the Reno algorithm. TCP NewReno improves TCP performance during
fast retransmit and fast recovery when multiple packets are dropped from a single window of data.
TCP NewReno support is disabled by default.
To Enable or Disable TCP NewReno Support through the CLI
At the (config) command prompt, enter the following command:
SGOS#(config) tcp-ip tcp-newreno {enable | disable}

ICMP Broadcast Echo Support
Disabling the ICMP broadcast echo command can prevent the ProxySG from participating in a Smurf
Attack. A Smurf attack is a type of Denial-of-Service (DoS) attack, where the attacker sends an ICMP
echo request packet to an IP broadcast address. This is the same type of packet sent in the ping
command, but the destination IP is broadcast instead of unicast. If all the hosts on the network send
echo reply packets to the ICMP echo request packets that were sent to the broadcast address, the
network is jammed with ICMP echo reply packets, making the network unusable. By disabling ICMP
broadcast echo response, the ProxySG does participate in the Smurf Attack.
This setting is disabled by default.
To Enable or Disable ICMP Broadcast Echo Support through the CLI
At the (config) command prompt, enter the following command:
SGOS#(config) tcp-ip icmp-bcast-echo {enable | disable}

For more information on preventing DDoS attacks, see "Attack Detection" on page 112.

ICMP Timestamp Echo Support
By disabling the ICMP timestamp echo commands, you can prevent an attacker from being able to
reverse engineer some details of your network infrastructure.
For example, disabling the ICMP timestamp echo commands prevents an attack that occurs when the
ProxySG responds to an ICMP timestamp request by accurately determining the target's clock state,
allowing an attacker to more effectively attack certain time-based pseudo-random number generators
(PRNGs) and the authentication systems on which they rely.
This setting is disabled by default.
To Enable or Disable ICMP Timestamp Echo Support through the CLI
At the (config) command prompt, enter the following command:
SGOS#(config) tcp-ip icmp-timestamp-echo {enable | disable}

TCP Window Size
Adjusting the TCP window-size regulates the amount of unacknowledged data that the ProxySG
receives before sending an acknowledgement.

140

Chapter 4: Configuring the System

To Configure the TCP Window Size through the CLI
At the (config) command prompt, enter the following command:
SGOS#(config) tcp-ip window-size window_size

where window_size indicates the number of bytes allowed before acknowledgement (the
value must be between 8192 and 4194304).

PMTU Discovery
PMTU (Path Maximum Transmission Unit) is a mechanism designed to discover the largest packet
size sent that is not fragmented anywhere along the path between two communicating ProxySG
Appliances that are not directly attached to the same link. A ProxySG doing PMTU sets the
Do-Not-Fragment bit in the IP header when transmitting packets. If fragmentation becomes
necessary before the packets arrive at the second ProxySG, a router along the path discards the packets
and returns an ICMP Host Unreachable error message, with the error condition of
Needs-Fragmentation, to the original ProxySG. The first ProxySG then reduces the PMTU size and
re-transmits the transmissions.
The discovery period temporarily ends when the ProxySG’s estimate of the PMTU is low enough that
its packets can be delivered without fragmentation or when the ProxySG stops setting the
Do-Not-Fragment bit. Five minutes later (this value is configurable), rediscovery is used to see if the
transmittable packet size has changed.
Following discovery and rediscovery, the size of the packets that are transferred between the two
communicating nodes dynamically adjust to a size allowable by the path, which might contain
multiple segments of various types of physical networks.
PMTU is disabled by default.
A ProxySG that is not running PMTU might send packets larger than that allowed by the path,
resulting in packet fragmentation at intermediate routers. Packet fragmentation affects performance
and can cause packet discards in routers that are temporarily overtaxed.
To Configure PMTU Discovery through the CLI
Note:

PMTU discovery can only be configured through the CLI. It is not available through the
Management Console.

At the (config) command prompt, enter the following commands:
SGOS#(config) tcp-ip pmtu-discovery enable | disable
SGOS#(config) tcp-ip pmtu-discovery expire-period seconds
SGOS#(config) tcp-ip pmtu-discovery probe-interval seconds

where
tcp-ip
pmtu-discovery

enable | disable

Allows you to enable PMTU discovery. The
default is disabled.

141

Blue Coat ProxySG Configuration and Management Guide

expire-period
seconds

Determines the time, in seconds, when PMTU
rediscovery takes place after receiving the
ICMP Host Unreachable – Needs
Fragmentation error message. The default
is 600 seconds.

probe-interval seconds

Determines the time, in seconds, when the
next PMTU rediscovery takes place following
a previous consecutive successful expansion
of the PMTU value. The default is 120
seconds.

TCP Time Wait
When a TCP connection is closed (such as a user entering “quit” for an FTP session), the TCP
connection remains in the TIME_WAIT state for twice the Maximum Segment Lifetime (MSL) before
completely removing the connection control block.
The TIME_WAIT state allows an end point (one end of the connection) to remove remnant packets
from the old connection, eliminating the situation where packets from a previous connection are
accepted as valid packets in a new connection.
The MSL defines how long a packet can remain in transit in the network. The value of MSL is not
standardized; the default value is assigned according to the specific implementation.
To change the MSL value, enter the following commands at the (config) command prompt:
SGOS#(config) tcp-ip tcp-2msl seconds

where seconds is the length of time you chose for the 2MSL value.

Viewing the TCP/IP Configuration
To view the TCP/IP configuration:
SGOS#(config) show tcp-ip
RFC-1323 support:
TCP Newreno support:
IP forwarding:
ICMP bcast echo response:
ICMP timestamp echo response:
Path MTU Discovery:
PMTU expiration period:
PMTU probe interval:
TCP 2MSL timeout
TCP window size:

142

enabled
disabled
disabled
disabled
disabled
enabled
600 seconds
120 seconds
120 seconds
65535 bytes

Chapter 5: Managing Port Services

This chapter describes port services that are configurable on the ProxySG. These services run on the
ProxySG, and include Management Consoles such as HTTPS, HTTP, SSH, and Telnet Consoles, and
application proxies such as Instant Messenger (IM), SOCKS, FTP, MMS, and RTSP, HTTP and HTTPS.
Other proxy services, like ICAP and Websense, are remote to the ProxySG and are discussed in
Chapter 11: “External Services” on page 437.
This chapter discusses


"Managing Multiple Management Consoles"



"Creating and Editing Services"

This chapter does not discuss configuration of some of the port services that are enabled here. The
following are discussed in Chapter 6: “Configuring Proxies” on page 173:


FTP Proxy



HTTP Proxy



SOCKS Proxy



Shell Proxies (Telnet)

143

Blue Coat ProxySG Configuration and Management Guide

Section A: Managing Multiple Management Consoles

Section A: Managing Multiple Management Consoles
The ProxySG ships with a number of already existing consoles designed to manage the system and
communication with the system:


HTTP and HTTPS Consoles: These consoles are designed to allow you access to the ProxySG. The
HTTPS Console is created and enabled; the HTTP Console is created by default but not enabled
because it is less secure than HTTPS.



SSH Console: This console is created and enabled by default, allowing you access to the ProxySG
through the CLI with your SSH service.



Telnet Console: This console is created but is disabled by default because of security concerns. You
must enable the service before you can access the ProxySG through a Telnet client (not
recommended).

Managing the HTTPS Console (Secure Console)
The HTTPS Console provides secure access to the Management Console through the HTTPS protocol.
You can create multiple management HTTPS consoles, allowing you to simultaneously access the
Management Console using any IP address belonging to the box as well as any of the ProxySG’s
virtual IP (VIP) addresses. The default is HTTPS over port 8082.
The ProxySG ships with an HTTPS Console already created and enabled. You do not need to create
other HTTPS Consoles unless you need them for other purposes.
An HTTPS Console and an HTTPS service are not the same. The HTTPS Console is for accessing the
ProxySG. An HTTPS service allows secure access to other systems.
Note:

Another difference between the HTTPS Console and an HTTPS service is that an SSL
termination license is required for an HTTPS service. If the ProxySG has no valid license
for SSL termination, you get an exception page when you attempt to connect to the
HTTPS service.
You can set up and use the HTTPS Secure Console without an SSL termination license.
For information on licensing, see Chapter 2: “Licensing” on page 43.

Creating a new HTTPS Console port requires three steps, discussed in the following sections:

144



Selecting a keyring (a keypair and a certificate that is stored together)



Selecting an IP address and port on the system that the service will use, including virtual IP
addresses



Putting the keyring and service together into an HTTPS Console

Chapter 5: Managing Port Services

Section A: Managing Multiple Management Consoles

Selecting a Keyring
The ProxySG ships with a default keyring that can be reused with each HTTPS service that you create.
You can also create your own keyrings for other purposes.
To use the default keyring, accept the default keyring through the Management Console. If using the
CLI, enter default for the keyring ID when using the services https-console create command.
Note:

When using certificates for the HTTPS Console or for HTTPS termination services that are
issued by Certificate Signing Authorities that are not well-known, see "Creating
Self-Signed SSL Certificates" on page 244.
If you get “host mismatch” errors or if the security certificate is called out as invalid,
create a different certificate and use it for the HTTPS Console.

For information on creating a keypair and a certificate to make a keyring, see "Configuring HTTPS
Termination" on page 234.

Selecting an IP Address
You can use any IP address on the ProxySG for the HTTPS Console service, including virtual IP
addresses. To create a virtual IP address, see "Virtual IP Addresses" on page 132.

Enabling the HTTPS Console Service
The final step in editing or creating an HTTPS Console service is to select a port and enable the
service.
To Create or Edit an HTTPS Console Port Service through the Management Console
1.

Select Configuration>Services>Service Ports.

Figure 5-1: Service Ports Tab

145

Blue Coat ProxySG Configuration and Management Guide

Section A: Managing Multiple Management Consoles
2.

Do one of the following:


To create a new HTTPS Console port service, click New; the Add Service dialog appears. Select
HTTPS-Console from the Protocol drop-down list.



To edit an existing HTTPS Console port service, highlight the HTTPS Console and click Edit;
the Edit Service dialog appears.

Continue with the next step.

Figure 5-2: HTTPS-Console Add Service Dialog

3.

The default IP address value is . To limit the service to a specific IP address, select the IP
address from the drop-down list. It must already exist.

4.

Identify the port you want to use for this service.

5.

In the Keyring drop-down list, select any already created keyring that is on the system. The system
ships with a default keyring that is reuseable for each HTPPS service.
Note:

6.

(Optional) In the SSL Versions drop-down list, select the version to use for this service. The default
is SSL v2/v3 and TLS v1.

7.

Click OK; click Apply.
Note:

146

The configuration-passwords-key keyring that shipped with the ProxySG does not
contain a certificate and cannot be used for HTTPS Consoles.

For information on creating keyrings and client certification lists, see "Configuring
HTTPS Termination" on page 234.

Chapter 5: Managing Port Services

Section A: Managing Multiple Management Consoles
To Create Another HTTPS Console Port Service through the CLI
1.

At the (config) command prompt, enter the following commands:
SGOS#(config) services
SGOS#(config services) https-console
SGOS#(config services https-console) create [ip_address:] port [keyring_id]

If you do not specify a keyring, the default is used.
SGOS#(config services https-console) attribute cipher-suite ip_address:port

2.

(Optional) View the results:
SGOS#(config services https-console) view
Port:
8082
IP: 0.0.0.0
Type: https-console
Keyring: default
Properties: explicit, enabled
Cipher suite:
RC4-MD5:RC4-SHA:DES-CBC3-SHA:DES-CBC3-MD5:RC2-CBC-MD5:RC4-64-MD5:DES-CBC-SHA
:DES-CBC-MD5:EXP1024-RC4-MD5:EXP1024-RC4-SHA:EXP1024-RC2-CBC-MD5:EXP1024-DES
-CBC-SHA:EXP-RC4-MD5:EXP-RC2-CBC-MD5:EXP-DES-CBC-SHA:
+SSLv2:+SSLv3+LOW:+SSLv2+LOW:+EXPOHTTP

Note:

To create client-certification lists and keyrings, see
"Configuring HTTPS Termination" on page 234. To set the cipher-suite to the ciphers you
want to use, see "Changing the Cipher Suites of the SSL Client" on page 252.

Managing the HTTP Console
The HTTP Console is meant to allow you to access the ProxySG if you require a less secure
environment. The default HTTP Console is already configured; you must enable it before it can be
used.
You can create and use more than one HTTP Console as long the IP address and the port do not match
the existing HTTP Console settings.
To Create or Edit an HTTP Console Port Service through the Management Console
1.

Select Configuration>Services>Service Ports.

2.

Do one of the following:


To create a new HTTP-Console port service, click New; the Add Service dialog appears. Select
HTTP-Console from the Protocol drop-down list.



To edit an existing HTTP-Console port service, highlight the HTTP-Console and click Edit; the
Edit Service dialog appears.

147

Blue Coat ProxySG Configuration and Management Guide

Section A: Managing Multiple Management Consoles

Figure 5-3: HTTP-Console Add Service Dialog

In either case, continue with the next step.
3.

The default IP address value is . To limit the service to a specific IP address, select the IP
address from the drop-down list. It must already exist.

4.

Identify the port you want to use for this service.

5.

Click OK; click Apply.

To Create or Edit an HTTP Console Port Service and Enable It through the CLI
1.

At the (config) command prompt, enter the following commands:
SGOS#(config) services
SGOS#(config services) http-console
SGOS#(config services http-console) create [ip_address:]port

2.

(Optional) View the results:
SGOS#(config services http-console) view
Port:
8085 IP: 0.0.0.0
Type: http-console
Properties: enabled

Managing the SSH Console
The SSH Console is created and enabled by default. Only one SSH Console can exist on the ProxySG.
If you inadvertently deleted the SSHv1 and SSHv2 host keys from the system at the same time, you
automatically disabled the SSH Console and must enable the SSH Console after you create a host key.
For information on managing SSH, see "Configuring the SSH Console" on page 63.
To Edit an SSH Console Service through the Management Console
1.

Select Configuration>Services>Service Ports.

2.

To edit the existing SSH-Console port service, highlight the SSH-Console and click Edit.
The Edit Service dialog appears.

148

Chapter 5: Managing Port Services

Section A: Managing Multiple Management Consoles

Figure 5-4: SSH-Console Add Service Dialog

3.

The default IP address value is all. To limit the service to a specific IP address, select the IP address
from the drop-down list.

4.

In the Port field, specify a port number; select Enable.

5.

Click OK; click Apply.

To Create an SSH Port Service through the CLI
1.

At the (config) command prompt, enter the following commands:
SGOS#(config) services
SGOS#(config services) ssh-console
SGOS#(config services ssh-console) create [ip_address:]port
SGOS#(config services ssh-console) enable [ip_address:]port

2.

(Optional) View the results:
SGOS#(config services ssh-console) view
Port:
22
IP: 0.0.0.0 Type: ssh-console
Properties: enabled

Managing the Telnet Console
The Telnet Console allows you to connect to and manage the ProxySG using the Telnet protocol.
Remember that Telnet is an insecure protocol that should not be used in insecure conditions. By
default, only SSH is created and enabled.
Blue Coat Systems recommends against using Telnet because of the security hole it creates.
Note:

If you do enable the Telnet Console, be aware that you cannot use Telnet everywhere in
the CLI. Some modules, such as SSL, respond with the error message:
Telnet sessions are not allowed access to ssl commands.

149

Blue Coat ProxySG Configuration and Management Guide

Section A: Managing Multiple Management Consoles
To Create or Edit a Telnet Console Port Service through the Management Console
Before you begin, verify that no Telnet service exists on the default telnet port (23). If it does exist,
delete it and apply the changes before continuing. If you also want a Telnet service, you can re-create
it later (use a different port). For information on the Telnet service, see"Managing the Telnet Shell
Proxy Service" on page 169.
1.

Select Configuration>Services>Service Ports.

2.

Do one of the following:


To create a new Telnet-Console port service, click New; the Add Service dialog appears. Select
Telnet-Console from the Protocol drop-down list.



To edit an existing Telnet-Console port service, highlight the Telnet-Console and click Edit; the
Edit Service dialog appears.

In either case, continue with the next step.

Figure 5-5: Telnet Console Edit Service Dialog

3.

Select Telnet protocol from the drop-down list.

4.

The default IP address value is all. To limit the service to a specific IP address, select the IP address
from the drop-down list.

5.

In the Port field, specify a port number; 23 is the default.
Note:

To use the Telnet shell proxy and retain the Telnet Console, you must change the port
number on one of them. Only one service is permitted on a port. For more information on
the Telnet shell proxy, see "Understanding Telnet Shell Proxies" on page 219.

6.

Select Enabled.

7.

Click OK; click Apply.

To Create or Edit a Telnet Port Service through the CLI
1.

At the (config) command prompt, enter the following commands:
SGOS#(config) services
SGOS#(config services) telnet-console
SGOS#(config services telnet-console) create [ip_address:]port

150

Chapter 5: Managing Port Services

Section A: Managing Multiple Management Consoles
2.

(Optional) View the results.
SGOS#(config services telnet-console) view
Port:
23
IP: 0.0.0.0
Type: telnet-console
Properties: enabled

151

Blue Coat ProxySG Configuration and Management Guide

Section B: Creating and Editing Services

Section B: Creating and Editing Services
Proxy services define the ports for which ProxySG will terminate incoming requests. A variety of
attributes for each service can also be defined. Each service can be applied to all IP addresses or
limited to a specific address. A number of default services are predefined. Additional services can be
defined on other ports.
You can create as many services as you require, keeping in mind that every newly created service uses
up resources.
Note:

When multiple non-wildcard services are created on a port, all of them must be of the
same service type (a wildcard service is one that is listening for that port on all IP
addresses). This means that if you have multiple IP addresses, and you specify IP
addresses for a port service, you cannot specify a different protocol if you define the same
port on another IP address. For example, if you define HTTP port 80 on one IP address,
you can only use the HTTP protocol on port 80 for other IP addresses.
Also note that wildcard services and non-wildcard services cannot both exist at the same
time on a given port.

The following table lists the available ProxySG services, including their attributes and default status.
The defaults are for a new ProxySG. If you have an upgraded appliance, the settings do not change.
Table 5.1: Proxy Port Services
Proxy Service

Default Port

Status

Configuration Discussed

DNS-Proxy

53 (both transparent and explicit)

Disabled

"Managing the DNS-Proxy"

EPMapper

135 (both transparent and explicit)

Disabled

"Managing the Endpoint Mapper
Proxy"

FTP

21 (transparent and explicit

Disabled

"Managing the FTP Service"

HTTP

80 (transparent and explicit)
8080 (explicit only)

Enabled

"Managing HTTP Services"

HTTP-Console

8081

Disabled

"Managing the HTTP Console"

Disabled

"Managing the HTTPS Service"

HTTPS

152

HTTPS-Console

8082

Enabled

"Managing the HTTPS Console
(Secure Console)"

MSN-IM

1863 (transparent and explicit) and
6891 (transparent and explicit)

Disabled

"Managing Instant Messaging
Protocols"

Yahoo-IM

5050 (transparent and explicit) and
5101 (transparent and explicit)

Disabled

"Managing Instant Messaging
Protocols"

AOL-IM

5190 (transparent and explicit)

Disabled

"Managing Instant Messaging
Protocols"

Chapter 5: Managing Port Services

Section B: Creating and Editing Services
Table 5.1: Proxy Port Services (Continued)
Proxy Service

Default Port

Status

Configuration Discussed

MMS

1755 (transparent and explicit)

Disabled

"Managing Streaming Protocols"

RTSP

554 (transparent and explicit)

Disabled

"Managing Streaming Protocols"

SOCKS

1080

Disabled

"Managing SOCKS Services"

SSH-Console

22

Enabled

"Managing the SSH Console"

Not Created

"Managing TCP Tunneling
Services"

TCP-Tunnel

Telnet-Console

23

Not Created

"Managing the Telnet Console"

Telnet shell
proxy

23

Disabled

"Managing the Telnet Shell Proxy
Service"

Note:

If HTTP is configured to be explicit, Internet Explorer version 6.0 users accessing FTP sites
over HTTP must disable the browser setting Enable folder view for FTP sites. To access this
attribute in Internet Explorer, select Tools>Internet Options, click the Advanced tab, deselect
Enable folder view for FTP sites, and click OK.

About Service Attributes
The service attributes define the parameters the ProxySG uses for a particular service.
Note:

For all service types except HTTPS, a specific listener cannot be posted on a port if the
same port has a wildcard listener of any service type already present.

The following table describes the attributes; however, depending on the protocol, not all attributes are
available.
Table 5.2: Attributes
Attribute

Description

Explicit

Enables or disables explicit attribute for the port. (Explicit allows connections to a
ProxySG IP address.)
Note: If DNS redirection is used to direct traffic to the ProxySG, the explicit flag on
its services must be enabled, as these connections will be routed through DNS to
the ProxySG’s IP address.

Transparent

Enables or disables transparent-proxy attribute for port. (This allows connections to
any IP address other than those belonging to the ProxySG.)

153

Blue Coat ProxySG Configuration and Management Guide

Section B: Creating and Editing Services
Table 5.2: Attributes
Attribute

Description

Authenticate-401

All transparent and explicit requests received on the port always use transparent
authentication (cookie or IP, depending on the configuration). This is especially
useful to force transparent proxy authentication in some proxy-chaining scenarios.

Send client IP

Enables or disables sending of client's IP address instead of the ProxySG's IP
address. For more information, see the section on tracking client IP addresses using
server-side transparency.

Note:

If you use the CLI to create a service, specify 0.0.0.0 to define that the service listens on
all IP addresses; specify the individual IP address to limit the service to one IP address.

Managing the DNS-Proxy
When a DNS-Proxy service is enabled, it listens on port 53 for both explicit and transparent DNS
domain query requests. By default, the service is created but not enabled.
The DNS-Proxy does a lookup of the DNS cache to determine if requests can be answered. If yes, the
ProxySG responds. If not, the DNS-Proxy forwards the request to the DNS server list configured on
the ProxySG. (To configure the DNS server list, see Configuration>Network>DNS.)
Note:

The ProxySG is not a DNS server. It does not perform zone transfers, and recursive
queries are forwarded to other name servers.

Through policy, you can configure the list of resolved domain names (the resolving name list) the
DNS-Proxy uses. The domain name in each query received by the ProxySG is compared against the
resolving name list. Upon a match, the ProxySG checks the resolving list. If a domain name match is
found but no IP address was configured for the domain, the ProxySG sends a DNS query response
containing its own IP address. If a domain name match is found with a corresponding IP address, that
IP address is returned in a DNS query response. All unmatched queries are sent to the name servers
configured on the ProxySG.
To Create or Edit a DNS-Proxy Service through the Management Console

154

1.

Select Configuration>Services>Service Ports.

2.

Click New or Edit; the Add (or Edit) Service dialog appears.

3.

Select DNS-Proxy from the Protocol drop-down list.

Chapter 5: Managing Port Services

Section B: Creating and Editing Services

Figure 5-6: DNS-Proxy Add Service Dialog

4.

The default IP address value is All. To limit the service to a specific IP address, select the IP address
from the drop-down list.

5.

In the Port field, 53 displays; you can change it to any unused port.

6.

Select Enabled.

7.

In the Attributes field, select Transparent, Explicit, Send-client-IP (spoofing), or all three. Explicit is the
default.
Note:

8.

The Send-client-IP attribute allows the ProxySG to pretend to be a client, allowing the
origin content server to see the client’s IP address. If an alternate path exists for traffic
returning from the Internet to the client, the Send-client-IP attribute does not work.

Click OK; click Apply.

To Create or Edit a DNS-Proxy Service through the CLI
1.

At the (config) command prompt, enter the following commands to set the value returned to the
client before configuring the DNS service:
SGOS#(config) services
SGOS#(config services) dns
SGOS#(config services dns) create ip_address:port

2.

If you do not need to change the defaults, you have completed the procedure. To change the
attributes, enter the following command:
SGOS#(config services dns)attribute {explicit | transparent | send-client-ip}
{enable | disable} [ip_address:] port

155

Blue Coat ProxySG Configuration and Management Guide

Section B: Creating and Editing Services
where:
attribute

explicit |
transparent |
send-client-ip enable
[ip_address:] port

Give the DNS proxy explicit and transparent
attributes, and create IP spoofing (where the ProxySG
pretends to be a client so the OCS can see the client’s IP
address).
Note: The Send-client-IP attribute allows the ProxySG
to pretend to be a client, allowing the origin content
server to see the client’s IP address. If an alternate path
exists for traffic returning from the Internet to the
client, the Send-client-IP attribute does not work.

enable

3.

[ip_address:] port

Enable the new DNS proxy.

(Optional) View the results:
SGOS#(config services dns)view
Port:
53
IP: 0.0.0.0
Type: dns
Properties: transparent, explicit, enabled
Port:
54
IP: 0.0.0.0
Type: dns
Properties: transparent, enabled

Creating a Resolving Name List
You can create the resolving name list that the DNS proxy uses to resolve domain names. This
procedure can only be done through policy. (For a discussion on using the layer, refer to
the Blue Coat ProxySG Content Policy Language Guide.)
Each name resolving list entry contains a domain-name matching pattern. The matching rules are:


test.com matches only test.com and nothing else.



.test.com matches test.com, www.test.com and so on.



“.” matches all domain names.

An optional IP address can be added, which allows the DNS proxy to return any IP address if the DNS
request's name matches the domain name suffix string (domain.name).
To create a resolving name list, create a policy, using the layer, that contains text similar
to the following:

dns.request.name=www.example.com dns.respond.a(vip)
-or
dns.request.name=.example.com dns.respond.a(vip)
-or
dns.request.name=www.example.com dns.respond.a(10.1.2.3)

Note:

156

You can also create a resolving name list using VPM. For more information on using the
DNS-Proxy layer in VPM, see "Web Content Policy Layer Reference" on page 511.

Chapter 5: Managing Port Services

Section B: Creating and Editing Services

Managing the Endpoint Mapper Proxy
The Endpoint Mapper proxy accelerates Microsoft RPC traffic (applications that use dynamic port
numbers) between branch and main offices, automatically creating TCP tunnels to ports where RPC
services are running. The Endpoint Mapper proxy can be used in both explicit and transparent mode.
Endpoint Mapper works by intercepting and tunnelling RPC traffic in the branch office (downstream
proxy). The tunneled data is compressed and forwarded to the main office (upstream proxy). The
upstream proxy, using SOCKS gateways, decompresses the traffic and forwards it to RPC server. (For
information on SOCKS compression, see "Understanding SOCKS Compression" on page 213.)
Note:

Only Microsoft RPC version 5.0 is supported. Traffic for unsupported Microsoft RPC
versions is passed through the ProxySG without processing.

For information on using SOCKS proxy and Endpoint Mapper together, refer to the Blue Coat ProxySG
Deployment Guide: Accelerating Performance for Remote Offices.
By default, the service is created but not enabled.
To Create or Edit Endpoint Mapper Service through the Management Console
1.

Select Configuration>Services>Service Ports.

2.

Click New or highlight the existing Endpoint Mapper proxy service and click Edit; the Add (or
Edit) Service dialog appears.

3.

Select EndpointMapper from the Protocol drop-down list.

Figure 5-7: Endpoint Mapper Edit Service Dialog

157

Blue Coat ProxySG Configuration and Management Guide

Section B: Creating and Editing Services
4.

The default IP address value is All. It cannot be changed.

5.

In the Port field, 135 displays. Port 135 is the standard port for Microsoft RPC traffic.

6.

Select Enabled.

7.

In the Attributes field, select Send-client-IP, if necessary. Explicit and Transparent attributes are not user
configurable.
Note:

8.

The Send-client-IP attribute allows the ProxySG to pretend to be a client, allowing the
origin content server to see the client’s IP address. If an alternate path exists for traffic
returning from the Internet to the client, the Send-client-IP attribute does not work.

Click OK; click Apply.

To Create or Edit an Endpoint Mapper Proxy Service through the CLI
1.

At the (config) command prompt, enter the following commands to create a new Endpoint
Mapper proxy service. If you want to edit the existing Endpoint Mapper proxy, skip to step 2.:
SGOS#(config) services
SGOS#(config services) epmapper
SGOS#(config services epmapper) create port

2.

To enable the Endpoint Mapper proxy service or enable the send-client-ip attribute, enter the
following commands:
SGOS#(config services epmapper) enable port
SGOS#(config services epmapper) attribute send-client-ip {enable | disable}
port

where:
attribute

send-client-ip enable port

Enable sending the client's IP address instead of
the ProxySG's IP address.
Note: If an alternate path exists for traffic
returning from the Internet to the client, the
Send-client-IP attribute does not work.

enable

3.

port

Enable the new Endpoint Mapper proxy. Port
135 is the standard port for Microsoft RPC
traffic.

(Optional) View the results:
SGOS#(config services epmapper) view
Port:
135
IP: 0.0.0.0
Type: epmapper
Properties: transparent, explicit, disabled

Managing the FTP Service
To configure the native FTP proxy, see "Configuring the FTP Proxy" on page 176.

158

Chapter 5: Managing Port Services

Section B: Creating and Editing Services
To Create or Edit an FTP Port Service through the Management Console
1.

Select Configuration>Services>Service Ports.

2.

Click New or Edit; the Add (or Edit) Service dialog appears.

3.

Select FTP from the Protocol drop-down list.

Figure 5-8: FTP Edit Service Dialog

4.

The default IP address value is all. To limit the service to a specific IP address, select the IP address
from the drop-down list.

5.

In the Port field, specify a port number; select the Enabled checkbox.

6.

In the Attributes field, both Explicit and Transparent are selected. You can de-select one of them if
necessary

7.

Click OK; click Apply.

To Create an FTP Service through the CLI
1.

At the (config) command prompt, enter the following commands:
SGOS#(config) services
SGOS#(config services) ftp
SGOS#(config services ftp) create [ip_address:]port
SGOS#(config services ftp) attribute passive-mode {enable | disable}
-orSGOS#(config services ftp) attribute {explicit | transparent} {enable |
disable} [ip_address:]port

2.

(Optional) View the results.
10.9.17.159 - Blue Coat SG3000#(config services ftp) view
Port:
21
IP: 0.0.0.0
Type: ftp
Properties: transparent, enabled, passive-allowed

159

Blue Coat ProxySG Configuration and Management Guide

Section B: Creating and Editing Services

Managing HTTP Services
Two HTTP services exist by default and are enabled, one with explicit and transparent attributes on
port 80 and one with explicit attributes on port 8080. You can change the attributes or create other
HTTP ports if needed.
To Create or Edit an HTTP Port Service through the Management Console
1.

Select Configuration>Services>Service Ports.

2.

Click New or highlight the service and click Edit; the Add (or Edit) Service dialog appears.

3.

Make sure HTTP is selected from the Protocol drop-down list.

Figure 5-9: HTTP Edit Service Dialog

4.

The default IP address value is all. To limit the service to a specific IP address, select the IP address
from the drop-down list.

5.

In the Port field, specify a port number; be sure Enabled is selected.

6.

In the Attributes field, select all that apply: Explicit, Transparent, Authenticate-401, or Send-client-IP.
Note:

7.

The Send-client-IP attribute allows the ProxySG to pretend to be a client, allowing the
origin content server to see the client’s IP address. If an alternate path exists for traffic
returning from the Internet to the client, the Send-client-IP attribute does not work.

Click OK; click Apply.

To Create an HTTP Service through the CLI
Two HTTP services exist and are enabled on the ProxySG. If you need to create another at a different
port in addition to the services already existing on the system, complete the following steps:
At the (config) command prompt, enter the following commands:

160

Chapter 5: Managing Port Services

Section B: Creating and Editing Services
SGOS#(config) services
SGOS#(config services) http
SGOS#(config services http) create [ip_address:]port
SGOS#(config services http) attribute {authenticate-401 | explicit |
send-client-ip | transparent} {enable | disable} [ip_address:]port
-orSGOS#(config services http) attribute {connect | head} {enable | disable
{drop | error}} [ip_address:]port

Note:

The Send-client-IP attribute allows the ProxySG to pretend to be a client, allowing the
origin content server to see the client’s IP address. If an alternate path exists for traffic
returning from the Internet to the client, the Send-client-IP attribute does not work.

To view the results:
SGOS#(config services http) view
Port:
8080
IP: 0.0.0.0
Type: http
Properties: explicit, enabled
Port:
80
IP: 0.0.0.0
Type: http
Properties: transparent, explicit, enabled

Managing the HTTPS Service
The HTTPS service is not configured or enabled by default when the ProxySG ships. You can
configure and use multiple HTTPS services.
To Create an HTTPS Port Service through the Management Console
1.

Select Configuration>Services>Service Ports.

2.

Click New; the Add Service dialog appears.

3.

Select HTTPS from the Protocol drop-down list.

161

Blue Coat ProxySG Configuration and Management Guide

Section B: Creating and Editing Services

Figure 5-10: HTTPS Add Service Dialog

4.

To select or add an IP address, do one of the following:


To select a local address, specify a real IP address from the IP drop-down list. All is not a
selection option.



To add a non-local IP address, first select the Transparent attribute, then enter a non-local IP
address that is not bound to the ProxySG.

5.

In the Port field, specify a port number; select Enable.

6.

In the Attributes field, select all that apply: Explicit, Transparent, Send-client-IP, Verify-client, or
Forward-client-cert. The Send-client-IP attribute allows the ProxySG to pretend to be a client,
allowing the origin content server to see the client’s IP address.
Note:

If the ProxySG HTTPS service is configured to require a client certificate (if the
Verify-client checkbox is selected), information from the client certificate is extracted
and put into a header that is included in the request when it is forwarded to the OCS.
The name of the header is Client-Cert. The header contains the certificate serial
number, subject, validity dates and issuer (all as name=value) pairs. The actual
certificate itself is not forwarded.

7.

162

In the Keyring drop-down list, select any already-created keyring that is on the system. The system
ships with a default keyring that can be reused for each HTTPS service. Keep in mind that the
default certificate associated with the default keyring is self-signed and might not be trusted by all
clients.

Chapter 5: Managing Port Services

Section B: Creating and Editing Services

Note:

The configuration-passwords-key keyring that shipped with the ProxySG does not
contain a certificate and cannot be used for HTTPS services.

8.

In the SSL Versions drop-down list, select the version that you want to use for this service. The
default is SSL v2/v3 and TLS v1.

9.

In the CA-Cert Lists drop-down list, select the list (already created) for the HTTPS service to use.

10. Click OK; click Apply.
Note:

To create client-certification lists and keyrings, see "Configuring HTTPS Termination" on
page 234.

To Create an HTTPS Service through the CLI
1.

At the (config) command prompt, enter the following commands:
SGOS#(config) services
SGOS#(config services) https
SGOS#(config services https) create ip_address:port keyring
SGOS#(config services https) attribute ccl list_name ip_address:port
-orSGOS#(config services https) attribute cipher-suite ip_address:port
-orSGOS#(config services https) attribute {forward-client-cert | send-client-ip
| verify-client} {enable | disable} ip_address:port
-orSGOS#(config services https) attribute ssl-protocol-version {sslv2 | sslv3 |
tlsv1 | sslv2v3| sslv2tlsv1 | sslv3tlsv1 | sslv2v3tlsv1} ip_address:port

Note:

If the ProxySG HTTPS service is configured to require a client certificate (if you enter
the command SGOS#(config services https) attribute verify-client
enable ip_address:port), information from the client certificate is extracted and
put into a header that is included in the request when it is forwarded to the OCS.
The name of the header is Client-Cert. The header contains the certificate serial
number, subject, validity dates and issuer (all as name=value) pairs. The actual
certificate itself is not forwarded.

2.

(Optional) View the results:
SGOS#(config services https) view
Port:
1000
IP: 10.9.17.159
Keyring: default
Properties: explicit, enabled
SSL Protocol version: SSLv2v3TLSv1
CA Certificate List: not configured

Type: https

163

Blue Coat ProxySG Configuration and Management Guide

Section B: Creating and Editing Services
Cipher suite:
RC4-MD5:RC4-SHA:DES-CBC3-SHA:DES-CBC3-MD5:RC2-CBC-MD5:RC4-64-MD5:DES-CBC-SHA
:DES-CBC-MD5:EXP1024-RC4-MD5:EXP1024-RC4-SHA:EXP1024-RC2-CBC-MD5:EXP1024-DES
-CBC-SHA:EXP-RC4-MD5:EXP-RC2-CBC-MD5:EXP-DES-CBC-SHA:+SSLv2:+SSLv3+LOW:+SSLv
2+LOW:+EXPO

Managing Instant Messaging Protocols
Supported instant messaging (IM) services are present by default with the transparent and explicit
attributes selected and listening on all IP addresses; none of them are enabled. The explicit attribute is
not user-configurable.
To Create or Enable an AOL, Yahoo, or MSN Port Service through the Management Console
1.

Select Configuration>Services>Service Ports.

2.

Click New or highlight the service you want and select Edit; the Add (or Edit) Service dialog
appears.

3.

Select the IM service you want to create or edit from the Protocol drop-down list.

4.

The default port is determined by the protocol:

5.



AOL— Port 5190



Yahoo—Ports 5050 and 5101



MSN—1863 and 6891

Click OK; click Apply.

To Manage an Instant Messaging Service through the CLI
1.

At the (config) command prompt, enter the following commands:
SGOS#(config) services
SGOS#(config services) aol-im | msn-im | yahoo-im
SGOS#(config services protocol) create port
SGOS#(config services protocol) attribute send-client-ip {enable | disable}
port

Note:

164

The send-client-IP attribute allows the ProxySG to pretend to be a client, allowing the
origin content server to see the client’s IP address. If an alternate path exists for traffic
returning from the Internet to the client, the Send-client-IP attribute does not work.

Chapter 5: Managing Port Services

Section B: Creating and Editing Services
2.

(Optional) View the results:
SGOS#(config services aol-im) view
Port:
5190 IP: 0.0.0.0
Type: aol-im
Properties: transparent, explicit, enabled
SGOS#(config services aol-im) exit
SGOS#(config services) yahoo-im
SGOS#(config services yahoo-im) view
Port:
5050 IP: 0.0.0.0
Type: yahoo-im
Properties: transparent, explicit, enabled

Managing Streaming Protocols
MMS and RTSP services are configured on the system, but are disabled by default. To enable the
default MMS and RTSP service, follow the steps below.
To Enable an MMS or RTSP Port Service through the Management Console
1.

Select Configuration>Services>Service Ports.

2.

Click New to create a new MMS or RTSP port service or highlight the existing service and click
Edit.
The Add (or Edit) Service dialog appears.

3.

Select MMS or RTSP from the Protocol drop-down list.

4.

The default IP address value is All. To limit the service to a specific IP address, select the IP address
from the drop-down list.

5.

In the Port field, specify a port number; select Enabled.

6.

In the Attributes field, select the attributes you want the service to have.

7.

Click OK; click Apply.

To Enable an MMS or RTSP Service through the CLI
1.

At the (config) command prompt, enter the following commands:
SGOS#(config) services
SGOS#(config services) {mms | rtsp}
SGOS#(config services protocol) create [ip_address:]port
SGOS#(config services protocol) attribute {explicit | send-client-ip |
transparent} {enable | disable} [ip_address:]port

Note:

The send-client-IP attribute allows the ProxySG to pretend to be a client, allowing the
origin content server to see the client’s IP address. If an alternate path exists for traffic
returning from the Internet to the client, the Send-client-IP attribute does not work.

165

Blue Coat ProxySG Configuration and Management Guide

Section B: Creating and Editing Services
2.

(Optional) View the results:
SGOS#(config services mms) view
Port:
1755
IP: 0.0.0.0
Type: mms
Properties: transparent, explicit, enabled
SGOS#(config services mms) exit
SGOS#(config services)rtsp
SGOS#(config services rtsp) view
Port:
554
IP: 0.0.0.0
Type: rtsp
Properties: transparent, explicit, enabled

Managing SOCKS Services
By default, a SOCKS service is configured with explicit attribute on port 1080, but not enabled. You
can create additional SOCKS services.
To enable a SOCKS port service, complete the steps below. To configure SOCKS gateway forwarding,
see "SOCKS Gateway Configuration" on page 757.
Note:

The version of SOCKS used is controlled through policy. For example, to use only
SOCKSv5:
client.protocol=socks
ALLOW socks.version=4 deny
DENY

To Create or Edit a SOCKS Port Service through the Management Console

166

1.

Select Configuration>Services>Service Ports.

2.

Click New to create a new SOCKS service or select Edit to enable the existing service; the Add (or
Edit) Service dialog appears.

3.

Select SOCKS from the Protocol drop-down list.

Chapter 5: Managing Port Services

Section B: Creating and Editing Services

Figure 5-11: SOCKS Edit Service Dialog

4.

The default IP address value is All. To limit the service to a specific IP address, select the IP address
from the drop-down list.

5.

In the Port field, specify a port number; select Enable.

6.

Click OK; click Apply.

To Create a SOCKS Port Service through the CLI
1.

At the (config) command prompt, enter the following commands:
SGOS#(config) services
SGOS#(config services) socks
SGOS#(config services socks) create [ip_address:]port
SGOS#(config services socks) enable [ip_address:]port

2.

(Optional) View the results:
SGOS#(config services socks) view
Port:
1080
IP: 10.25.36.48 Type: socks
Properties: explicit, enabled

Managing TCP Tunneling Services
Tunneling, or port forwarding, is a way to forward TCP traffic. Any application protocol running over
TCP can be tunneled using this service. Client-server applications carry out any authentication
procedures just as they do when TCP tunneling is not involved.
SGOS uses a tcp:// scheme for TCP-tunnel transactions instead of HTTPS because SGOS does not
actually know that it is HTTPS that is being tunneled.
You can use the SOCKS proxy in conjunction with TCP tunnels to compress and accelerate the
tunnelled traffic. For information on using the SOCKS proxy, see "Configuring a SOCKS Proxy" on
page 213.

167

Blue Coat ProxySG Configuration and Management Guide

Section B: Creating and Editing Services
Both explicit and transparent TCP tunneling are supported. Which one you use depends 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 address, port, host, and domain.
Note:

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

You can use the Management Console or the CLI to create a transparent TCP tunneling protocol.
When a TCP-Tunnel service is created, it is by default an explicit service and automatically enabled.
To Create a Transparent or Explicit TCP-Tunnel Port Service through the Management Console
1.

Select Configuration>Services>Service Ports.

2.

Click New; the Add Service dialog appears.

3.

Select TCP-Tunnel from the Protocol drop-down list.
The Add Service dialog displays.

Figure 5-12: TCP-Tunnel Add Service Dialog

168

4.

The default IP address value is All. To limit the service to a specific IP address, select the IP address
from the drop-down list.

5.

In the Port field, specify a port number; select Enabled.

6.

If you are configuring a transparent TCP-Tunnel service, make sure Transparent is selected in the
Attributes field; if you are configuring an explicit TCP-Tunnel service, verify Explicit is selected.

7.

Click OK; click Apply.

Chapter 5: Managing Port Services

Section B: Creating and Editing Services
To Create a TCP-Tunnel Transparent or Explicit Port Service through the CLI
1.

At the (config) prompt, enter the following commands to create a transparent or explicit service:
SGOS#(config) services
SGOS#(config services) tcp-tunnel
SGOS#(config services tcp-tunnel) create [ip_address:]port

where ip_address is the IP address of the ProxySG (use 0.0.0.0 to indicate all available IP
addresses), and port is the number of the port the ProxySG listens to. You must choose a port
that is not configured for any other service.
2.

Enable the service to be transparent or explicit. By default, the port service is explicit.
SGOS#(config services tcp-tunnel) attribute {explicit | transparent} {enable
| disable} [ip_address:]port

3.

(Optional) View the results.
SGOS#(config services tcp-tunnel) view
Port:
7080
IP: 0.0.0.0
Type: tcp-tunnel
Properties: transparent, explicit, enabled

If you created a transparent TCP-Tunnel service, the procedure is complete. If you created an explicit
TCP-Tunnel service, you must configure a forwarding destination port.
To Configure a Forwarding Destination Port through the CLI
1.

Create a forwarding destination port, where the ProxySG directs traffic.
SGOS#(config services tcp-tunnel) exit
SGOS#(config services) exit
SGOS#(config) forwarding
SGOS#(config forwarding) create host_alias ip_address tcp=port

2.

(Optional) View the results:
SGOS#(config forwarding) view
Forwarding Groups: (* = host unresolved)
No forwarding groups defined.
Individual Hosts: (* = host unresolved)
Host_Alias 10.25.36.47 tcp=port_number

Managing the Telnet Shell Proxy Service
On a new system, Telnet proxy service is configured and disabled on port 23. On an upgrade, Telnet
proxy service is not created.
To Enable or Create a Telnet Proxy Service through the Management Console
Important: To use Telnet to manage the ProxySG, create a Telnet-Console rather than a Telnet
service. The Telnet service allows you to use Telnet for outbound connections, and
the ProxySG functions as Shell proxy in that situation. For more information on the
Telnet-Console, see "Managing the Telnet Console" on page 149.
1.

Select Configuration>Services>Service Ports.

169

Blue Coat ProxySG Configuration and Management Guide

Section B: Creating and Editing Services
2.

Click New if you are creating a new Telnet service; highlight the Telnet service and click Edit if you
are enabling an existing Telnet service;
The Add or Edit Service dialog appears.

Figure 5-13: Creating a Telnet Service

3.

In the Protocol drop-down list, select Telnet.

4.

The default IP address value is all. To limit the service to a specific IP address, select the IP address
from the drop-down list.

5.

In the Port field, specify a port number; select Enable. Port 23 is the default.
Important:

6.

In the Attributes field, select Transparent, Explicit, Send-client-IP (spoofing), or all three. Explicit is the
default.
Note:

7.

170

You can have only one service on a port, so you must choose a port number for
the Telnet service that is different from the port chosen for the Telnet Console.

The send-client-IP attribute allows the ProxySG to pretend to be a client, allowing the
origin content server to see the client’s IP address. If an alternate path exists for traffic
returning from the Internet to the client, the Send-client-IP attribute does not work.

Click OK; Click Apply.

Chapter 5: Managing Port Services

Section B: Creating and Editing Services
To Enable or Create a Telnet Proxy Service through the CLI
Note:

The explicit attribute is enabled by default and the transparent and
send-client-ip attributes are disabled by default. Note also that only one service can
use a port, so if you have Telnet-Console enabled on Port 23, you must choose a different
port number for the Telnet shell proxy.

From the (config) prompt, enter the following commands:
SGOS#(config) services
SGOS#(config services) telnet
SGOS#(config services telnet) create [ip_address:]port
SGOS#(config services telnet) attribute {explicit | transparent |
send-client-ip} enable [ip_address:]port
SGOS#(config services telnet) enable [ip_address:]port

where:
create

[ip_address:] port

Create a Telnet shell proxy service at the (optional)
address and port number.

attribute

explicit |
transparent |
send-client-ip enable
[ip_address:] port

Assign the Telnet shell proxy explicit and transparent
attributes, and create IP spoofing (where the ProxySG
pretends to be a client so the OCS can see the client’s IP
address).
Note: The Send-client-IP attribute allows the ProxySG
to pretend to be a client, allowing the origin content
server to see the client’s IP address.If an alternate path
exists for traffic returning from the Internet to the
client, the Send-client-IP attribute does not work.

enable

[ip_address:] port

Enable the new Telnet shell proxy.

To view the results:
SGOS#(config services telnet) view
Port:
23
IP: 0.0.0.0
Type: telnet
Properties: transparent, explicit, disabled
Port:
24
IP: 10.25.36.47 Type: telnet
Properties: explicit, enabled

171

Blue Coat ProxySG Configuration and Management Guide

Section B: Creating and Editing Services

172

Chapter 6: Configuring Proxies

A proxy filters traffic, monitors Internet and intranet resource usage, blocks specific Internet and
intranet resources for individuals or groups, and enhances the quality of Internet or intranet user
experiences.
A proxy also serves as an intermediary between a Web client and a Web server and can require
authentication to allow identity-based policy and logging for the client. The rules used to authenticate
a client are based on the policies created and implemented through your existing security framework,
such as LDAP, RADIUS, and NTLM, and are further discussed in "Using Authentication Services" on
page 299.
Explicit/Transparent proxy specifies the mode the client requests get to the proxy.


Explicit—The default, requiring software configuration for both browser and service.



Transparent—Requires a Layer-4 switch or a WCCP-compliant router. You can also transparently
redirect requests through a ProxySG by setting the workstation’s gateway to the ProxySG IP
address. You can also use the ProxySG software bridge to transparently proxy requests.
Some software configuration on the ProxySG is also required to allow the appliance to know what
traffic to intercept.

You might also configure both proxy types, depending on the services you require.
This chapter contains the following topics:


"About Explicit and Transparent Proxy"



"Creating an Explicit Proxy Server"



"Configuring the Transparent Proxy Hardware"

About Explicit and Transparent Proxy
Whether you select explicit or transparent proxy deployment is determined by factors such as network
configuration, number of desktops, desired user experience, and desired authentication approach.
Note:

While you must configure proxying to do authentication, verify the proxy is configured
correctly and is functioning before adding authentication to the mix. Many network or
other configuration problems can appear similar to authentication errors.

173

Blue Coat ProxySG Configuration and Management Guide

Understanding Explicit Proxy
In an explicit proxy configuration, the client (browser) is explicitly configured to use a proxy server.
The browser is given the IP address and port number of the proxy service (the ProxySG). It is also
possible to configure the browser to download the proxy settings from a Web server. This is called a
Proxy Auto-Configuration (PAC) file. When a user makes a request, the browser connects to the proxy
service and sends the request. Because the browser knows it is talking to a proxy, the browser
provides the proxy server with the destination server.
The proxy service accepts the explicit connection to it, and fetches the request from the browser. The
request identifies the desired origin content server (OCS) and the resource on that server. The proxy
service uses this information to contact the OCS if necessary.
The disadvantage to explicit proxy is that each desktop must be properly configured to use the proxy,
which might not be feasible in a large organization.

Understanding Transparent Proxy
When transparent proxy is enabled, the client (browser) does not know the traffic is being processed
by a machine other than the OCS. The browser believes it is talking to the OCS, so the request is
formatted for the OCS and the proxy determines for itself the destination server based on information
in the request, such as the destination IP address in the packet, or the Host: header in the request.
To enable the ProxySG to intercept traffic sent to it, you must create a service and define it as
transparent. The service is configured to intercept traffic for a specified port, or for all IP addresses on
that port. A transparent HTTP proxy, for example, typically intercepts all traffic on port 80 (all IP
addresses).
To make sure that the appropriate traffic is directed to the ProxySG, deploy hardware such as a
Layer-4 switch or a WCCP router, or the ProxySG appliance’s software bridge that can redirect
selected traffic to the appliance. Traffic redirection is managed through polices you create on the
redirection device.
For detailed information on explicit proxies, continue with the next section; for detailed information
on transparent proxies, continue with "Transparent Proxies" on page 224.

174

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies

Section A: Configuring Explicit Proxies
You can configure several different explicit proxy servers and services:


Native FTP—See "Configuring the FTP Proxy" on page 176.



HTTP Proxy—See "Managing HTTP Proxy" on page 183.



SOCKS—See "Configuring a SOCKS Proxy" on page 213.



Shell Proxies—See "Customizing Policy Settings for Shell Proxies" on page 218

For information on creating an explicit proxy server, regardless of type, continue with "Creating an
Explicit Proxy Server".

Creating an Explicit Proxy Server
If your network does not use transparent proxy, clients on the network must configure their browsers
to use either an explicit proxy server or a Proxy Auto-Configuration (PAC) file. The ProxySG
generates client instructions that describe how to configure Microsoft Internet Explorer, Netscape
Communicator, and other browsers based on instructions selected by the ProxySG administrator. You
can configure client instructions for each network adapter in the ProxySG with the
Configuration>Network>Adapters>Interface>Settings button.
After selecting client instructions, the ProxySG administrator directs clients to go to the ProxySG
home page and follow the instructions in the Browser Configuration section. The ProxySG detects the
browser installed on the client and displays the appropriate instructions.

Using the ProxySG as an Explicit Proxy
To use the ProxySG as an explicit proxy and use services such as SOCKS or FTP, you must provide
custom instructions to clients instructing them how to configure their browsers to use the ProxySG as
a proxy server.
This is a two-step process, requiring that you add the proxy IP address to the browser and also
instruct the ProxySG which adapter interface uses the proxy IP address.
Before the proxy can be used, you must:


Configure the proxy server.



Enable the explicit proxy (whether a service or a server).

The browsers described here are Internet Explorer 6.0 and Netscape 6.2. If you have different browsers
or different versions of Internet Explorer or Netscape, refer to the vendor documentation for
information on configuring proxies.
From Internet Explorer
1.

Select Tools>Internet Options>Connections>LAN Settings.

2.

Select Use a proxy server.

175

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies
3.

Enter the IP address and port number for the proxy, or click Advanced to set proxy server IP
addresses and port numbers for services such as HTTP, FTP, and SOCKS. (Configure HTTPS
through the Secure field.)

4.

Click OK to exit the Advanced Settings tab, then continue to click OK until you exit the Tools menu.

From Netscape
1.

Select Edit>Preferences>Advanced>Proxies.

2.

Select Manual proxy configuration.

3.

Enter proxy server IP addresses and port numbers for services such as HTTP, FTP, SOCKS and
SSL.

4.

Click OK.
Note:

Explicit proxy allows a redundant configuration using IP address failover among a cluster
of machines. For information on creating a redundant configuration for failover, see
"Configuring Failover" on page 134.

Configuring Adapter Proxy Settings
Once the explicit proxy is configured on the browser, decide which adapter interfaces listen for which
service. Each adapter interface can listen for only one IP address; you can configure multiple proxies
on one ProxySG using the same IP address.
To Provide Configuration Instructions through the Management Console
1.

Select Configuration>Network>Adapters.

2.

Select an adapter and the correct interface and click Settings.

3.

Select Using a proxy.

4.

Click OK to close the Settings dialog.

5.

Click Apply.

To Provide Configuration Instructions through the CLI
At the (config) command prompt, enter the following commands:
SGOS#(config) interface fast-ethernet interface_#
SGOS#(config interface interface_#) instructions proxy

Configuring the FTP Proxy
In previous SGOS releases, connections to FTP origin content servers were only accomplished over
HTTP. SGOS 4.x supports Native FTP proxy.

176

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies

Note:

As in previous releases, FTP requests sent through the HTTP proxy are still valid.

Configuring an FTP proxy requires ProxySG configuration and specific configuration of the FTP
client. The service must be enabled on the ProxySG before it can be used.
Data connections initiated by an FTP client to an FTP server are known as passive mode data
connections. This type of connection is useful in situations where an FTP server is unable to make a
connection to an FTP client because the client is located behind a firewall or other similar device
where outbound connections from the client are allowed, but inbound connections to the client are
blocked.
This functionality allows administrators to select how the ProxySG responds to a request from an FTP
client for a passive mode data connection (PASV command). This functionality does not affect HTTP
requests for FTP objects (for example, those originating from browsers that are explicitly proxied to a
ProxySG).
If the FTP server responds that it supports PASV, but the ProxySG is unable to connect because of a
firewall blocking the port, the ProxySG only attempts a PORT command. Some FTP clients do not
open a passive mode data connection to an IP address that is different from the IP address used for the
control connection.
Disabling passive mode data connections on the ProxySG servicing requests from this type of FTP
client might provide a more acceptable response to the end user.
When passive mode data connections are disabled, the ProxySG returns a response to the FTP client
indicating that the server does not support passive mode. The FTP client software controls any
messages displayed to the end user as a result of this response from the ProxySG.
Limitations


Internet Explorer does not support proxy authentication for Native FTP.



The ProxySG FTP proxy does not support exceptions.

Understanding FTP Spoofing
Using policy, you can spoof the IP addresses for FTP data connections in both transparent and explicit
deployments, for both active and passive modes; certain deployments are subject to limitations. The
client and server-side policies are:


ftp.match_client_data_ip(yes)—Matches the source IP address of the ACTIVE data
connection with the destination IP address of the control connection (client side).



ftp.match_server_data_ip(yes)—Matches the source IP address of the PASV data connection
with the source IP address of the ProxySG control connection (server side).

Note:

To always use the ProxySG physical IP address (no spoofing), define policy as
ftp.match_[client | server]_data_ip(no).

177

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies
The following points describe the various data flow scenarios:


Outbound client data connection (ProxySG to client)—When the client issues a PORT command,
the ProxySG opens a data connection to the FTP client with the source IP address of whatever
destination IP address the client used when opening the control connection.



Inbound client data connection (client to ProxySG)—When the client issues a PASV command, the
ProxySG returns the IP address and port to which client makes a data connection.


Explicit—The ProxySG returns the destination IP address of the control connection; this can
be a physical or virtual ProxySG IP address.



Transparent—The ProxySG returns the IP address of the physical adapter on which the
control connection arrived.



Outbound server data connection (ProxySG to FTP server)—When the ProxySG issues a PASV
command upstream, the server returns an IP address and port to connect to. The ProxySG then
opens a data connection to the server with the same source IP address it used to open the control
connection. This address is defined by the reflect_ip property.



Inbound server data connection (FTP server to ProxySG)—When the ProxySG issues a PORT
command, the ProxySG provides the IP address and port number to which the server makes a
data connection.


The ProxySG sends the control connection’s source IP address if that IP is a local ProxySG
(virtual or physical) IP address; or



The ProxySG sends the IP address of the physical adapter that was used to make the outgoing
control connection.

FTP Server Limitations
Consider the following limitations when defining FTP spoofing policy:


IIS and WS_FTP servers do not support PASV data connections with a source IP address that is
different from the source IP address of the control connection.



IIS and WS_FTP servers do not support ACTIVE data connections with a destination IP address
that differs from the source IP address of the control connection.

Configuring the ProxySG for Native FTP Proxy
This section describes how to configure the ProxySG through the Management Console and the CLI.
To Configure Native FTP Proxy through the Management Console
1.

178

Select Configuration>Services>FTP Proxy.

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies

Figure 6-1: FTP Proxy Tab

2.

Select Allow caching of FTP objects. The default is enabled.

3.

Determine the amount of time in percentage of how long since the object was last modified. The
default is 10%.

4.

Enter an amount, in hours, that the object remains in the cache before becoming eligible for
deletion. The default is 24 hours.

5.

Select Allow use of PASV mode to clients. The default is enabled.

To Configure Native FTP Proxy through the CLI
1.

At the (config) command prompt, enter the following commands:
SGOS#(config) caching
SGOS#(config caching) max-cache-size 18
SGOS#(config caching) ftp
SGOS#(config caching ftp) enable
SGOS#(config caching ftp) type-m-percent 20
SGOS#(config caching ftp) type-n-initial 12

where:
max-cache-size

megabytes

The maximum size, in megabytes, of the largest object that
can stored on the ProxySG. The max-cache-size value
sets the maximum object size for both HTTP and FTP.
Enables or disables the caching of FTP objects.

enable | disable
type-m-percent

percent

Time to live for objects with a last-modified time.

type-n-initial

hours

Time to live for objects without a last-modified time.

179

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies
2.

(Optional) View the result.
SGOS#(config caching ftp) view
Caching FTP objects is enabled
FTP objects with last modified date, cached for 20% of last modified time
FTP objects without last modified date, initially cached for 12 hours

3.

(Optional) Change the default login syntax. The default syntax is Raptor. The ProxySG also
supports the Checkpoint authentication syntax. The supported Checkpoint formats are:


remoteuser@proxyuser@host (in USER command) for explicit FTP.



remotepass@proxypass (in PASS command) for explicit FTP.



remoteuser@proxyuser (in USER command) for transparent FTP.



remotepass@proxypass (in PASS command) for transparent FTP.

Enter the following command to change the login syntax:
SGOS# (config) ftp login-syntax {raptor | checkpoint}

Note:

Neither proxy authentication for transparent FTP nor proxy chaining are supported with
the Checkpoint syntax.

Enabling the FTP Service
By default, an FTP service is already created with explicit and transparent attributes, but it is disabled.
You must enable the FTP port before it can be used.
To Create and Enable a Native FTP Port Service through the Management Console
1.

Select Configuration>Services>Service Ports.

2.

Click New; the Add Service dialog appears.

Figure 6-2: FTP Add Service Dialog

180

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies
3.

In the Protocol drop-down list, select FTP.

4.

The default IP address value is All. To limit the service to a specific IP, select the IP from the
drop-down list.

5.

In the Port field, specify a port number; select Enabled.

6.

Select the FTP attributes, as required: Explicit, Transparent, or both.

7.

Click OK; Click Apply.

To Create a Native FTP Port Service through the CLI
1.

At the (config) command prompt, enter the following commands:
SGOS#(config) services
SGOS#(config services) ftp
SGOS#(config services ftp)
SGOS#(config services ftp)
SGOS#(config services ftp)
SGOS#(config services ftp)

2.

create [ip_address:]port
attribute passive-mode {enable | disable}
attribute explicit enable [ip_address:]port
attribute transparent enable [ip_address:]port

(Optional) View the results.
SGOS#(config services ftp) view
Port:
25
IP: 0.0.0.0
Type: ftp
Properties: transparent, explicit, enabled, passive-allowed

Configuring FTP Clients
FTP clients must be configured as follows:


Enable firewall.



Select USER with no logon.



For proxy authentication, select USER remoteID@remoteHost fireID and specify a proxy username
and password.

Example
The following graphic demonstrates configuring a WSFtp client.

181

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies

Figure 6-3: Configuring the WSFtp Client for Native FTP

Configuring FTP Connection Welcome Banners
You can customize banners that usually describe the policies and content of the FTP server displayed
to FTP clients. Without modification, the ProxySG sends a default banner to newly-connected FTP
clients: Welcome to Blue Coat FTP. However, you might not want users to know that a Blue Coat
ProxySG exists on the network. A default banner can be defined in the Management Console or the
CLI, but other banners defined for specific groups can be created in policy layers.
Note:

Configurable banners can only be displayed when FTP is explicit through the ProxySG. In
transparent deployments, the banner is sent to the client when proxy authentication is
required; otherwise, the banner is forwarded from the FTP server.

To Define the Default FTP Banner through the Management Console
1.

Select Configuration>Services>FTP Proxy.

2.

In the Welcome Banner field, enter a line of text that is displayed on FTP clients upon connection. If
the message length spans multiple lines, the ProxySG automatically formats the string for
multiline capability.

3.

Click Apply.

Figure 6-4: Configuring an FTP Connection Welcome Banner

182

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies
To Define the Default FTP Banner through the CLI
At the (config) prompt, enter the following command:
#SGOS#(config) ftp
#SGOS#(config) ftp welcome-banner "message"

To Create Policy that Overrides the Default Banner
Add the following property to a policy:

ftp.welcome_banner "message"

If entering text that spans more than one line, use $(crlf) for line breaks.

Managing HTTP Proxy
By default, an HTTP proxy service, with both explicit and transparent attributes set, is enabled on
port 80. To change the attributes of the proxy service or create new HTTP proxy services, see
"Managing HTTP Services" on page 160.
The HTTP proxy is the first line of defense for the ProxySG, controlling all traffic that arrives on
port 80 to the ProxySG. To control that traffic and improve performance, you can:


Set default caching policies to configure the length of time an object or negative response is
cached, whether objects are always revalidated before being served, whether server certificates
are verified by default, and how headers are parsed. For more information, see "Setting Default
HTTP Proxy Policy" on page 188.



Configure the HTTP proxy as a server accelerator. For more information, see "Choosing the HTTP
Proxy Profile" on page 192.



Set a limit to the maximum bandwidth the ProxySG is allowed to use for refreshing objects in the
background. For more information, see "Configuring Refresh Bandwidth for the HTTP Proxy" on
page 186.



Compress and decompress content. For more information, see "Understanding HTTP
Compression" on page 202.
Note:

Use of the compression feature is a trade-off among three resources: server-side
bandwidth, client side-bandwidth, and CPU. If server-side bandwidth is expensive
compared to CPU, always request compressed content from the OCS. If CPU is
comparatively expensive, then the ProxySG should ask the server for the compression
formats that the client asked for and forward whatever the server returns.

The HTTP proxy is designed to control Web traffic, providing:


Security



Authentication



Virus Scanning and Patience Pages



Performance

183

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies


Default HTTP Proxy Policy



HTTP Proxy Caching Profiles



Byte-Range Support



Refresh Bandwidth



Compression

This chapter deals with HTTP proxy performance. See also:


Chapter 8: “Security and Authentication” on page 269 to learn about controlling access to the
ProxySG, Internet, intranet, and making decisions based on user identity.



"Forms-Based Authentication" on page 401 for information about using Web forms for
authentication.



See "About Content Scanning" on page 439 for information about virus scanning and sending
patience pages to explain the delays that can occur when scanning for viruses before serving data.

Configuring HTTP Proxy Performance
Understanding Default HTTP Proxy Policy
Using the ProxySG Management Console or CLI, you can configure global defaults that determine
HTTP proxy caching policy, such as the maximum size of cacheable objects, the length of time that
negative responses remain in the cache, whether the ProxySG revalidates each object before serving it,
whether the server certificate is verified by default, and how headers are parsed.
For information about setting default policy for HTTP proxy caching, see "Setting Default HTTP
Proxy Policy" on page 188.

HTTP Proxy Acceleration Profiles
You have a choice of three profiles to use for the ProxySG:


Normal (the default setting) acts as a client-accelerator, and is used for enterprise deployments



Portal acts as a server accelerator, and is used for Web-hosting



Bandwidth Gain is used for ISP deployments

For information on HTTP profiles, see "Choosing the HTTP Proxy Profile" on page 192.

Byte-Range Support
If a client makes a request using the Range: HTTP header, the ProxySG serves the requested portions
of the file from the cache if byte-range support is enabled (the default). If byte range support is
disabled, all such requests are forwarded to the origin content server and the response is not cached.
For information on using byte-range support to determine how the ProxySG handles byte-range
requests, see "Configuring HTTP for Bandwidth Gain" on page 199.

184

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies

Refresh Bandwidth
Refresh bandwidth refers to server-side bandwidth used for all forms of asynchronous refresh activity.
The default configuration is to allow the ProxySG to manage refresh bandwidth. The ProxySG
manages the bandwidth in order to preserve the maximum freshness of accessed objects. However,
sometimes the automatic refresh bandwidth amount is too high. It is not unusual for refresh
bandwidth to spike up occasionally, depending on access patterns at the time. If necessary, you can
impose a limit on refresh bandwidth. To limit the refresh bandwidth to a specified amount, you must
disable automatic management of the bandwidth and explicitly set a bandwidth limit. Setting the
refresh bandwidth amount too low can lower the estimated freshness of objects in the cache. If you set
the refresh bandwidth amount to zero, the ProxySG does not do active refresh at all.
For information about configuring refresh bandwidth, see "Configuring Refresh Bandwidth for the
HTTP Proxy" on page 186.

Compression
Compression is disabled by default. If compression is enabled, the HTTP proxy forwards the
supported compression algorithm (either deflate or gzip) from the client’s request
(Accept-Encoding: request header) to the server as is, and attempts to send compressed content to
client whenever possible. This allows the ProxySG to send the response as is when the server sends
compressed data, including non-cacheable responses. Any unsolicited encoded response is forwarded
as is to the client.
For more information on compression, see "Understanding HTTP Compression" on page 202.

Understanding HTTP Terms


Asynchronous Adaptive Refresh (AAR)—This allows the ProxySG to keep cached objects as fresh
as possible, thus reducing response times. The AAR algorithm allows HTTP proxy to manage
cached objects based on their rate of change and popularity: an object that changes frequently
and/or is requested frequently is more eligible for asynchronous refresh compared to an object
with a lower rate of change and/or popularity.



Asynchronous Refresh Activity—Refresh activity that does not wait for a request to occur, but that
occurs asynchronously from the request.



Bandwidth Gain—A measure of the difference in client-side and server-side Internet traffic
expressed in relation to server-side Internet traffic. It is managed in two ways: you can enable or
disable bandwidth gain mode or you can select the Bandwidth Gain profile (this also enables
bandwidth gain mode). See "Configuring the HTTP Proxy Profile" on page 197 for information
about configuring bandwidth gain.



Byte-Range Support—The ability of the ProxySG to respond to byte-range requests (requests with
a Range: HTTP header).



Cache-hit—An object that is in the ProxySG and can be retrieved when an end user requests the
information.



Cache-miss—An object that can be stored but has never been requested before; it was not in the
ProxySG to start, so it must be brought in and stored there as a side effect of processing the
end-user's request. If the object is cacheable, it is stored and served the next time it is requested.

185

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies


Compression—An algorithm that reduces a file’s size but does not lose any data. The ability to
compress or decompress objects in the cache is based on policies you create. Compression can
have a huge performance benefit, and it can be customized based on the needs of your
environment: Whether CPU is more expensive (the default assumption), server-side bandwidth is
more expensive, or whether client-side bandwidth is more expensive.



Freshness—A percentage that reflects the objects in the ProxySG cache that are expected to be
fresh; that is, the content of those objects is expected to be identical to that on the OCS (origin
content server).



Maximum Object Size—The maximum object size stored in the ProxySG. All objects retrieved that
are greater than the maximum size are delivered to the client but are not stored in the ProxySG.



Negative Responses—An error response received from the OCS when a page or image is
requested. If the ProxySG is configured to cache such negative responses, it returns that response
in subsequent requests for that page or image for the specified number of minutes. If it is not
configured, which is the default, the ProxySG attempts to retrieve the page or image every time it
is requested.



Refresh Bandwidth—The amount of bandwidth used to keep stored objects fresh. By default, the
ProxySG is set to manage refresh bandwidth automatically. You can configure refresh bandwidth
yourself, although Blue Coat does not recommend this.



Variants—Objects that are stored in the cache in various forms: the original form, fetched from the
OCS; the transformed (compressed or uncompressed) form (if compression is used). If a required
compression variant is not available, then one might be created upon a cache-hit. (Note:
policy-based content transformations are not stored in the ProxySG.)

Configuring Refresh Bandwidth for the HTTP Proxy
The ProxySG uses as much bandwidth as necessary for refreshing to achieve the desired access
freshness.
The amount of bandwidth used varies depending on client demands. If you determine that the
ProxySG is using too much bandwidth (by reviewing the logged statistics and examining current
bandwidth used shown in the Refresh bandwidth field), you can specify a limit to the amount of
bandwidth the ProxySG uses to try to achieve the desired freshness. Be aware, however, that if you
limit the amount of bandwidth the ProxySG can use, you might prohibit the ProxySG from achieving
the desired freshness. If the refresh bandwidth configuration remains at the recommended
default—Let the ProxySG Appliance manage refresh bandwidth (recommended) in the Management
Console or SGOS#(config caching) refresh automatic in the CLI—then the ProxySG uses
whatever bandwidth is available in its efforts to maintain 99.9% estimated freshness of the next access.
To Set Refresh Bandwidth through the Management Console
1.

186

Select Configuration>Services>HTTP Proxy>Freshness.

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies

Figure 6-5: Freshness Tab

The Refresh bandwidth field displays the refresh bandwidth options. The default setting is to allow
the ProxySG to manage refresh bandwidth automatically.
Important:
2.

Blue Coat strongly recommends that you not change the setting from the default.

Do one of the following:



To turn off automatic bandwidth refresh, select Limit refresh bandwidth to (not recommended).
Enter a new value into the kilobits/sec field, if necessary.
To return the ProxySG to automatic bandwidth refresh, select Let the ProxySG Appliance
manage refresh bandwidth (recommended).

3.

Click Apply.

To Set Refresh Bandwidth through the CLI
1.

To disable automatic bandwidth refresh (not recommended), enter the following commands at the
(config) command prompt:
SGOS#(config) caching
SGOS#(config caching) refresh no automatic

2.

(Optional) To adjust the kilobit/sec refresh bandwidth value, enter the following commands:
Note:

Adjusting the refresh bandwidth value has no effect if you do not also turn off the
automatic refresh bandwidth option (you must perform Step 1). You can skip Step 2 if the
refresh bandwidth value is acceptable (200 Kbps is the default).

SGOS#(config) caching
SGOS#(config caching) refresh bandwidth kbps

187

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies
3.

To return the ProxySG to automatic bandwidth refresh (recommended), enter the following
commands:
SGOS#(config) caching
SGOS#(config caching) refresh automatic

4.

(Optional) View the (truncated) results:
SGOS#(config caching) view
Refresh:
Estimated access freshness is 100.0%
Let the ProxySG Appliance manage refresh bandwidth
Current bandwidth used is 0 kilobits/sec

To view all HTTP settings, see "Viewing HTTP Settings through the CLI" on page 201.

Setting Default HTTP Proxy Policy
Using the ProxySG Management Console or CLI, you can configure global defaults that determine
HTTP proxy policy, such as the maximum size of cacheable objects, the length of time that negative
responses remain in the cache, whether the ProxySG revalidates each object before serving it, whether
the server certificate is verified by default, and how headers are parsed.
Other policy can be controlled only by using Blue Coat Content Policy Language (CPL). This section is
about using the Management Console or CLI to set default HTTP proxy policy; see "Creating a Proxy
Layer to Manage Proxy Operations" on page 289 for information about using CPL to configure HTTP
proxy caching.
Note:

Tolerant HTTP request parsing can only be done through the CLI; it is not available
through the Management Console.

To Set HTTP Default Proxy Policy through the Management Console
1.

188

Select Configuration>Services>HTTP Proxy>Policies.

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies

Figure 6-6: Policies Tab

2.

Fill in the fields as appropriate:


In the Do not cache objects larger than field, enter the maximum object size to cache. The default
is 1024 MB. This configuration determines the maximum object size to store in the ProxySG.
All objects retrieved that are greater than the maximum size are delivered to the client but are
not stored in the ProxySG.



In the Cache negative responses for field, enter the number of minutes the ProxySG stores
negative responses. The default is 0, meaning that the ProxySG does not cache negative
responses and always attempts to retrieve the object.
The OCS might send a client error code (4xx HTTP response) or a server error code (5xx HTTP
response) as a response to some requests. If the ProxySG is configured to cache such negative
responses, it returns that response in subsequent requests for that page or image for the
specified number of minutes. If it is not configured, which is the default, the ProxySG
attempts to retrieve the page or image every time it is requested.
If you enter a number of minutes into this field, then the response times improve, but you
could receive negative responses to requests that might otherwise have been served for that
period of time.



To always verify that each object is fresh upon access, select the Always check with source before
serving object checkbox. Enabling this setting has a significant impact on performance because
HTTP proxy revalidates requested cached objects with the OCS before serving them to the
client, resulting in a negative impact on response times and bandwidth gain. Therefore, do not
enable this configuration unless absolutely required.



If you communicate with an OCS through HTTPS and want the server’s certificate to be
verified by the ProxySG, verify that Verify server certificate for secure connections is selected.



The default is to parse HTTP meta tag headers in HTML documents if the MIME type of the
object is text/HTML. The function of all meta tags is same as the corresponding HTTP
headers.

189

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies
To disable meta-tag parsing, remove the check from the checkbox for:


Parse “cache-control” meta tag

The following sub-headers are parsed when this checkbox is selected: private,
no-store, no-cache, max-age, s-maxage, must-revalidate, proxy-revalidate.

3.



Parse “expires” meta tag



Parse “pragma-no-cache” meta tag

Click Apply.

To Set HTTP Proxy Default Policy through the CLI
1.

At the (config) command prompt, enter the following commands:
SGOS#(config) caching
SGOS#(config caching)
SGOS#(config caching)
SGOS#(config caching)
-orSGOS#(config caching)

max-cache-size megabytes
negative-response minutes
always-verify-source
no always-verify-source

where:
max-cache-size

megabytes

The maximum size, in megabytes, of the largest object
that can stored on the ProxySG. The
max-cache-size sets the maximum object size for
both HTTP and FTP.

negative-response

minutes

The amount of time, in minutes, that the ProxySG
remembers that an object is not stored.
Ensures that every object is always fresh upon access.
This has a significant impact on performance because
HTTP proxy revalidates requested cached objects with
the OCS before serving them to the client, resulting in
a negative impact on response times and bandwidth
gain. Therefore, do not enable this configuration item
unless absolutely required.

always-verifysource

no

Note:

2.

always-verify
source

If you use HTTPS, you might want to change the verify-server certificate from the default
of enabled to suppress verification of the OCS certificate (step 2).

(Optional) To enable or disable the verify-server certificate setting, enter one of the following
commands:
SGOS#(config caching) exit

190

The default setting. This tells the ProxySG never to
check objects on the source before serving them to the
client.

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies
SGOS#(config) http ssl-verify-server
-orSGOS#(config) http no ssl-verify-server

3.

(Optional) To enable or disable meta-tag parsing (parsing is enabled by default), enter one of the
following commands:
SGOS#(config services) exit
SGOS#(config) http parse meta-tag {cache-control | expires | pragma-no-cache}
-orSGOS#(config) http no parse meta-tag {cache-control | expires |
pragma-no-cache}

To view all HTTP settings, see "Viewing HTTP Settings through the CLI" on page 201.
Tips on Parsing Meta Tags


If ICAP response modification is occurring, the response body modified by the ICAP server is not
parsed.



Relevant HTTP meta tags must appear within the first 256 bytes of the HTTP object body. If the
meta tag does not appear within the first 1000 bytes, it is ignored.

Tips on Using Meta Tags With Policy


The following CPL properties can be used in the layer to control meta tag processing for
HTTP proxy, HTTP refresh, and HTTP pipeline transactions:
http.response.parse_meta_tag.Pragma.no-cache(yes|no)
http.response.parse_meta_tag.Cache-Control(yes|no)
http.response.parse_meta_tag.Expires(yes|no)



VPM support for this feature is not available.

Understanding Tolerant HTTP Request Parsing
By default, the ProxySG blocks malformed HTTP requests, returning a 400 Invalid Request error. The
tolerant HTTP request parsing flag causes certain types of malformed requests to be processed instead
of being rejected.
By default, a header line not beginning with a or space character must consist of a header name
(which contains no or space characters), followed by a colon, followed by an optional value, or
an error is reported. With tolerant request parsing enabled, a request header name is allowed to
contain or space characters, and if the request header line does not contain a colon, then the
entire line is taken as the header name.
A header containing one or more or space characters, and nothing else, is considered
ambiguous. Blue Coat does not know if this is a blank continuation line or if it is the blank line that
signals the end of the header section. By default, an ambiguous blank line is illegal, and an error is
reported. With tolerant request parsing enabled, an ambiguous blank line is treated as the blank line
that signals the end of the header section.

191

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies
To Enable the HTTP Tolerant Request Parsing Flag through the CLI
Note:

This feature is only available through the CLI. It cannot be set through the Management
Console.

From the (config) prompt, enter the following command to enable tolerant HTTP request parsing
(the default is disabled):
SGOS#(config) http tolerant-request-parsing

To disable HTTP tolerant request parsing, enter the following command:
SGOS#(config) http no tolerant-request-parsing

To view all HTTP settings, including http tolerant-request-parsing if it is enabled, see "Viewing
HTTP Settings through the CLI" on page 201.

Choosing the HTTP Proxy Profile
You can select from among three profiles for the HTTP proxy, depending on your needs, and you can
also create a customized profile from the three available.
The three profiles are:


Normal, which acts as a client-accelerator and is used for enterprise deployments



Portal, which acts as a server accelerator and is used for Web-hosting



Bandwidth, which is used for ISP deployments

Table 6.1 shows the configuration for each profile. For a description of each configuration setting, see
Table 6.2 on page 194.
Table 6.1: Normal, Portal and Bandwidth Gain Profiles

192

Configuration

Normal Profile

Portal Profile

Bandwidth Gain

Pipeline embedded objects in client requests

Enabled

Disabled

Disabled

Pipeline embedded objects in prefetch requests

Enabled

Disabled

Disabled

Pipeline redirects for client requests

Enabled

Disabled

Disabled

Pipeline redirects for prefetch requests

Enabled

Disabled

Disabled

Cache expired objects

Enabled

Disabled

Enabled

Bandwidth Gain Mode

Disabled

Disabled

Enabled

Substitute GET for IMS (if modified since)

Disabled

Enabled

Enabled

Substitute GET for PNC (Pragma no cache)

Disabled

Enabled

Does not change

Substitute GET for HTTP 1.1 conditionals

Disabled

Enabled

Enabled

Substitute GET for IE (Internet Explorer) reload

Disabled

Enabled

Does not change

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies
Table 6.1: Normal, Portal and Bandwidth Gain Profiles
Configuration

Normal Profile

Portal Profile

Bandwidth Gain

Never refresh before expiration

Disabled

Enabled

Enabled

Never serve after expiration

Disabled

Enabled

Does not change

When a ProxySG is first manufactured, it is set to a Normal profile. Depending on your needs, you can
use the Bandwidth Gain profile or the Portal profile. You can also combine needed elements of all three
profiles.

Using the Normal Profile
Normal is the default profile and can be used wherever the ProxySG is used as a normal forward
proxy. This profile is typically used in enterprise environments, where the freshness of objects is more
important than controlling the use of server-side bandwidth. The Normal profile is the profile that
most follows the HTTP standards concerning object revalidation and staleness. Additionally,
prefetching (pipelining) of embedded objects and redirects is enabled, which reduces response time
for clients.

Using the Portal Profile
When configured as a server accelerator, the ProxySG improves object response time to client requests,
scalability of the OCS site, and overall Web performance at the OCS. A server accelerator services
requests meant for an OCS as if it is the OCS itself.
Because an OCS can actually consist of many servers—a single Web server or an entire server
farm—they are identified by domain name or IP address. To the ProxySG, the domain name or IP
address is treated as the OCS, regardless of how many back-end Web servers might be installed.

Using the Bandwidth Gain Profile
The Bandwidth-Gain profile is useful wherever server-side bandwidth is an important resource. This
profile is typically used in Internet Service Provider (ISP) deployments. In such deployments, the
freshness of the object is not as important as controlling the use of server-side bandwidth. The
Bandwidth-Gain profile enables various HTTP configurations that can increase page response times
and the likelihood that stale objects are served, but that reduces the amount of server-side bandwidth
required.

Understanding HTTP Object Types
HTTP proxy categorizes HTTP objects into three types:


Type-T: The OCS specifies explicit expiration time.



Type-M: Expiration time is not specified; however, the last modified time is specified by the OCS.



Type-N: Neither expiration nor last modified time has been specified.

193

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies
The ProxySG’s asynchronous adaptive refresh (AAR) algorithm is normally applied to all three types
of HTTP objects. To maximize the freshness of the next access to objects in the ProxySG’s cache,
asynchronous revalidations are performed on those objects in accordance with their relative
popularity and the amount of time remaining before their estimated time of expiration. Estimated
expiration times vary as object content changes are observed during such asynchronous revalidations.
This happens even for type-T objects because the expiration times of type-T objects are not always
perfectly managed by Webmasters of content servers. However, for situations where such
management can be trusted, certain configuration items exist to reduce speculative revalidation of
type-T objects. In the following section, the terms revalidation and refresh mean the same thing—to
assess the freshness of an object by sending a conditional GET request to the object’s OCS.

Understanding HTTP Proxy Profile Configuration Components
Table 6.2 gives a definition of the customizable HTTP proxy profile settings. Both the Management
Console field and CLI (config) command text is included.
Table 6.2: Description of Profile Configuration Components in the Management Console and CLI

194

Management Console
Checkbox Field

CLI (config)
Command

Definition

Pipeline embedded
objects in client request

http [no] pipeline
client requests

This configuration item applies only to HTML
responses. When this setting is enabled, and the object
associated with an embedded object reference in the
HTML is not already cached, HTTP proxy acquires
the object’s content before the client requests the
object. This improves response time dramatically. If
this setting is disabled, HTTP proxy does not acquire
embedded objects until the client requests them.

Pipeline redirects for
client request

http [no] pipeline
client redirects

When this setting is enabled, and the response of a
client request is one of the redirection responses (such
as 301, 302, or 307 HTTP response code), then HTTP
proxy pipelines the object specified by the Location
header of that response, provided that the redirection
location is an HTML object. This feature improves
response time for redirected URLs. If this setting is
disabled, HTTP proxy does not pipeline redirect
responses resulting from client requests.

Pipeline embedded
objects in prefetch
request

http [no] pipeline
prefetch requests

This configuration item applies only to HTML
responses resulting from pipelined objects. When this
setting is enabled, and a pipelined object’s content is
also an HTML object, and that HTML object has
embedded objects, then HTTP proxy also pipelines
those embedded objects. This nested pipelining
behavior can occur three levels deep at most. If this
setting is disabled, HTTP proxy does not engage in
nested pipelining behavior.

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies
Table 6.2: Description of Profile Configuration Components in the Management Console and CLI (Continued)
Management Console
Checkbox Field

CLI (config)
Command

Definition

Pipeline redirects for
prefetch request

http [no] pipeline
prefetch
redirects

When this setting is enabled, HTTP proxy pipelines
the object specified by a redirect location returned by
a pipelined response. If this setting is disabled, HTTP
proxy does not try to pipeline redirect locations
resulting from a pipelined response.

Substitute Get for IMS

http [no]
substitute
if-modified-since

If the time specified by the If-Modified-Since:
header in the client’s 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.
To control this aspect of the ProxySG’s treatment of
the If-Modified-Since: header, disable the
Substitute Get for IMS setting. When this setting is
disabled, a client time condition greater than the last
modified time of the object in the cache does not
trigger revalidation of the object.
However, not all objects necessarily have a
last-modified time specified by the OCS.

Substitute Get for HTTP
1.1 conditionals

http [no]
substitute
conditional

HTTP 1.1 provides additional controls to the client
over the behavior of caches concerning the staleness
of the object. Depending on various
Cache-Control: headers, the ProxySG can be
forced to consult the OCS before serving the object
from the cache. For more information about the
behavior of various Cache-Control: header
values, refer to RFC 2616.
If the Substitute Get for HTTP 1.1 Conditionals setting
is enabled, HTTP proxy ignores the following
Cache-Control: conditions from the client request:
• "max-stale" [ "=" delta-seconds ]
• "max-age" "=" delta-seconds
• "min-fresh" "=" delta-seconds
• "must-revalidate"
• "proxy-revalidate"

195

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies
Table 6.2: Description of Profile Configuration Components in the Management Console and CLI (Continued)

196

Management Console
Checkbox Field

CLI (config)
Command

Definition

Substitute Get for PNC

http [no]
substitute
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 IE
reload

http [no]
substitute
ie-reload

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

http [no]
strict-expiration
refresh

Applies only to cached type-T objects. 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

http [no]
strict-expiration
serve

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.

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies
Table 6.2: Description of Profile Configuration Components in the Management Console and CLI (Continued)
Management Console
Checkbox Field

CLI (config)
Command

Definition

Cache expired objects

http [no] cache
expired

Applies only to type-T objects. When this setting is
enabled, type-T objects that are already expired at the
time of acquisition is cached (if all other conditions
make the object cacheable). When this setting is
disabled, already expired type-T objects become
non-cacheable at the time of acquisition.

Enable Bandwidth Gain
Mode

bandwidth-gain
{disable | enable}

This setting controls both HTTP-object acquisition
after client-side abandonment and AAR
(asynchronous adaptive refresh) revalidation
frequency.
• HTTP-Object Acquisition
When Bandwidth Gain mode is enabled, if a client
requesting a given object abandons its request,
then HTTP proxy immediately abandons the
acquisition of the object from the OCS, if such an
acquisition is still in progress. When bandwidth
gain mode is disabled, the HTTP proxy continues
to acquire the object from the OCS for possible
future requests for that object.
• AAR Revalidation Frequency
Under enabled bandwidth gain mode, objects that
are asynchronously refreshable are revalidated at
most twice during their estimated time of
freshness. With bandwidth gain mode disabled,
they are revalidated at most three times. Not all
asynchronously refreshable objects are guaranteed
to be revalidated.

Configuring the HTTP Proxy Profile
You can configure the profile you want from either the Management Console or the CLI.
To Configure the HTTP Proxy Profile through the Management Console
1.

Select Configuration>Services>HTTP Proxy>Acceleration Profile.
The Acceleration Profile tab displays (Normal is the default profile). Text appears at the bottom of
this tab indicating which profile is selected. If you have a customized profile, this text does not
appear.

197

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies

Figure 6-7: Acceleration Profile Tab

Important:

2.

If you have a customized profile and you click one of the Use Profile buttons, no
record of your customized settings remains. However, once the ProxySG is set
to a specific profile, the profile is maintained in the event the ProxySG is
upgraded.

To select a profile, click one of the three profile buttons (Use Normal Profile, Use Bandwidth Gain
Profile, or Use Portal Profile).
The text at the bottom of the Acceleration Profile tab changes to reflect the new profile.
Note:

You can customize the settings, no matter which profile button you select.

3.

(Optional) To customize the profile settings, select or deselect any of the checkboxes (see Table 6.2
on page 194 for information about each setting).

4.

Click Apply.

To Configure the HTTP Proxy Profile through the CLI
1.

At the (config) command prompt, enter the profile you want:
SGOS#(config) profile {normal | portal | bwgain}

2.

(Optional) Use the following commands to customize the profile settings (see Table 6.2 on
page 194 for information about these settings):
SGOS#(config)
SGOS#(config)
SGOS#(config)
SGOS#(config)
SGOS#(config)
SGOS#(config)

198

http
http
http
http
http
http

[no]
[no]
[no]
[no]
[no]
[no]

pipeline client requests
pipeline client redirects
pipeline prefetch requests
pipeline prefetch redirects
substitute if-modified-since
substitute conditional

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies
SGOS#(config)
SGOS#(config)
SGOS#(config)
SGOS#(config)
SGOS#(config)
SGOS#(config)

3.

http [no] substitute pragma-no-cache
http [no] substitute ie-reload
http [no] strict-expiration refresh
http [no] strict-expiration serve
http [no] cache expired
bandwidth-gain {disable | enable}

(Optional) View the settings. (This example assumes you have selected the Portal profile.)
SGOS#(config) show profile
SG is currently using the Normal Profile
Pipeline client requests:
Enabled
Pipeline client redirects:
Enabled
Pipeline prefetch requests:
Enabled
Pipeline prefetch redirects:
Enabled
Substitute Get "if-modified-since": Disabled
Substitute Get "pragma: no-cache":
Disabled
Substitute HTTP 1.1 Conditional Get: Disabled
Substitute Internet Explorer reload: Disabled
Never refresh before expiration:
Disabled
Never serve after expiration:
Disabled
Cache expired objects:
Enabled
Bandwidth gain mode:
Disabled

You can view all HTTP settings. See "Viewing HTTP Settings through the CLI" on page 201 for more
information.

Configuring HTTP for Bandwidth Gain
In addition to the configuration items related to top-level profiles, other configurable items also affect
bandwidth gain. You can set the top-level profile and adjust various related configuration items to fine
tune ProxySG for your needs (see "Configuring the HTTP Proxy Profile" on page 197), and you can
provide additional fine-tuning with the following configuration items:


Byte-range support



Revalidate pragma-no-cache

Byte-range requests can be made with a PNC header. To serve these requests from the cache, enable
the revalidate PNC setting (see "Understanding Revalidate Pragma-No-Cache" below).

Understand Byte-Range Support
If a client requests a byte range using the Range: HTTP header, the ProxySG serves the requested
portions of the file from the cache if byte-range support is enabled (the default). If byte range support
is disabled, all such requests are forwarded in a non-cacheable way to the origin content server.
Byte-range configuration can significantly affect bandwidth gain where heavy use of range requests is
expected. Download managers (such as NetAnts®) typically use byte-range requests heavily.

199

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies
With byte-range support enabled, if the object is already cached and does not need to be reloaded
from the OCS, the ProxySG serves the byte-range request from the cache only. But if the object is not in
the cache, or if a reload of the object is required, the ProxySG might treat the byte-range request as if
byte-range support is disabled and serve the object from the cache. It is important to note that HTTP
proxy never caches partial objects, even if byte-range support is enabled.
If byte-range support is disabled, HTTP treats all byte-range requests as non-cacheable. Such requests
are never served from the cache, even if the object exists in the cache. The client’s request is sent
unaltered to the OCS and the response is not cached. Thus a byte-range request has no effect on the
cache if byte-range support is disabled.
HTTP proxy categorizes the range requests in following three categories when byte-range support is
enabled:


Type-1: 0-N: Range request for first N bytes of the object



Type-2: N-M: Range request from N bytes to M bytes of the object



Type-3: -N: Range request for last N bytes of the object

If the object does not exist in the cache, and a byte-range request is received with the first range being
type-1 or type-2, and the start byte of the first requested range is within 14336 bytes (hard coded
threshold), then the entire object is retrieved from the OCS and cached in the ProxySG. Even though
HTTP proxy retrieves the entire object from the OCS, it sends an appropriate byte-range response to
the client. If the object does not exist in the cache, and if the first range in the request is not of type-1 or
type-2, or if the start byte of the first requested range is beyond 14336 bytes, then the client’s request is
sent unaltered to the OCS and the response is not cached.
If the object exists in the cache, and if a range request with an effective PNC (the PNC header is not
substituted or revalidated—see "Understanding Revalidate Pragma-No-Cache" below) is made, and
the first range in the request is either type-3 or type-1 or 2 with a start byte offset greater than 14336
bytes, then, even if the object exists in the cache, the transaction is made non-cacheable (the request is
sent to the OCS without any modification and the response is not cached). If an object exists in the
cache and a byte-range request is made without the PNC header, then the byte-range response is
satisfied from the cache.
Most download managers make byte-range requests with a PNC header. To serve such requests from
the cache, the revalidate pragma-no-cache option should be configured along with byte-range support
(see "Understanding Revalidate Pragma-No-Cache" below).
To Configure Byte-Range Support through the CLI
Note:

Enabling or disabling byte-range support can only be configured through the CLI.

To enable or disable byte-range support, enter one of the following commands at the (config)
command prompt:
SGOS#(config) http byte-ranges
-orSGOS#(config) http no byte-ranges

To view all HTTP settings, see "Viewing HTTP Settings through the CLI" on page 201.

200

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies

Understanding Revalidate Pragma-No-Cache
The pragma-no-cache (PNC) header in a client’s request can affect the efficiency of the proxy from a
bandwidth gain perspective (this behavior is described in Table 6.2 in the Substitute Get for PNC
configuration description). If you do not want to completely ignore PNC in client requests (which you
can do by using the Substitute Get for PNC configuration), you can lower the impact of the PNC by
enabling the revalidate-pragma-no-cache setting. When the revalidate-pragma-no-cache
setting is enabled, a client’s non-conditional PNC-GET request results in a conditional GET request
sent to the OCS if the object is already in the cache. This gives the OCS a chance to return the 304 Not
Modified response, thus consuming less server-side bandwidth, because it has not been forced to return
full content even though the contents have not actually changed. By default, the revalidate PNC
configuration is disabled and is not affected by changes in the top-level profile. When the Substitute
Get for PNC configuration is enabled (see "Configuring the HTTP Proxy Profile" for configuration
information), the revalidate PNC configuration has no effect.
To Configure the Revalidate PNC Setting through the CLI
Note:

The revalidate pragma-no-cache setting can only be configured through the CLI.

To enable or disable the revalidate PNC setting, enter one of the following commands at the (config)
command prompt:
SGOS#(config) http revalidate-pragma-no-cache
-orSGOS#(config) http no revalidate-pragma-no-cache

To view all HTTP settings, see "Viewing HTTP Settings through the CLI" below.

Viewing HTTP Settings through the CLI
You can view the existing HTTP settings by entering the following command:
SGOS#(config) show http
Supported protocol version: HTTP 1.1
Caching options:
Cache authenticated data: enabled
Cache expired objects:
enabled
Cache personal pages:
disabled
Strip From Headers:
disabled
Byte range support:
enabled
Force NTLM on proxy IE:
disabled
Rewrite redirects for XP: disabled
Revalidate "pragma: no-cache":
disabled
WWW redirect if host not found:
enabled
Force explicit expirations:
Never refresh before:
disabled
Never serve after:
disabled
Add headers:
"Front-end-https":
disabled
"Via":
disabled
"X-forwarded-for":
disabled

201

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies
"Client-ip":
disabled
Parsing options:
HTML meta tag "Cache-Control":
enabled
HTML meta tag "Expires":
enabled
HTML meta tag "Pragma: no-cache": enabled
Persistent connections:
Client connections:
enabled
Server connections:
enabled
Pipeline:
Client requests:
enabled
Client redirects:
enabled
Prefetch requests:
enabled
Prefetch redirects:
enabled
Substitute simple Get for:
Get "if-modified-since": disabled
Get "pragma: no-cache":
disabled
HTTP 1.1 Conditional get: disabled
Internet Explorer reload: disabled
Proprietary header extensions:
Blue Coat extensions:
disabled
FTP proxy:
Url path is:
absolute from root
Configuration/access log uploads: will use PASV
Persistent connection timeouts:
Server:
900
Client:
360
Receive timeouts:
Server:
180
Client:
120
Refresh:
90
Https:
ssl-verify-server:
enabled
tolerant-request-parsing: enabled

Understanding HTTP Compression
Compression reduces a file size but does not lose any data. Whether you should use compression
depends upon three resources: server-side bandwidth, client-side bandwidth, and ProxySG CPU. If
server-side bandwidth is more expensive in your environment than CPU, always request compressed
content from the origin content server (OCS). However, if CPU is comparatively expensive, the
ProxySG should instead be configured to ask the OCS for the same compressions that the client asked
for and to forward whatever the server returns.
The default configuration assumes that CPU is costlier than bandwidth. If this is not the case, you can
change the ProxySG behavior.

202

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies

Note:

Decompression, content transformation, and recompression increases response time by a
small amount because of the CPU overhead. (The overhead is negligible in most cases.)
RAM usage also increases if compression is enabled.
Compression might also appear to adversely affect bandwidth gain. Because compression
results in a smaller file being served to the client than was retrieved by the ProxySG from
the origin content server, bandwidth gain statistics reflect such requests/responses as
negative bandwidth gain.

Compression is disabled by default. If compression is enabled, the HTTP proxy forwards the
supported compression algorithm (gzip and deflate) from the client’s request (Accept-Encoding:
request header) to the server as is, and attempts to send compressed content to client whenever
possible. This allows the ProxySG to send the response as is when the server sends compressed data,
including non-cacheable responses. Any unsolicited encoded response is forwarded to the client as is.
Note:

If compression is not enabled, the ProxySG does not compress the content if the server
sends uncompressed content. However, the ProxySG continues to uncompress content if
necessary to apply transformations.
Any unsolicited encoded response is forwarded to the client as is.

Compression is controlled by policy only.

Understand Compression Behavior
The ProxySG compression behavior is detailed in the tables below.
Note:

A variant is the available form of the object in the cache—compressed or uncompressed.
The Content-Encoding: header Identity refers to the uncompressed form of the content.

Compression increases the overall percentage of cacheable content, increasing the hit rate in terms of
number of objects served from the cache.
For cache-hit compression behavior, see Table 6.3 below. For cache-miss compression behavior, see
Table 6.4 on page 204.
Table 6.3: Cache-Hit Compression Behavior
Accept-Encoding:
in client request

Variant Available when
the Request Arrived

Variant Stored as a
Result of the Request

Content-Encoding: in
ProxySG response

Identity

Uncompressed object

None

Identity

Identity

No uncompressed object

Uncompressed

Identity

gzip compressed

gzip

gzip compressed
gzip, deflate

Uncompressed object

203

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies
Table 6.3: Cache-Hit Compression Behavior (Continued)
Accept-Encoding:
in client request

Variant Available when
the Request Arrived

Variant Stored as a
Result of the Request

Content-Encoding: in
ProxySG response

gzip, deflate

Uncompressed object

None

gzip

None

deflate

deflate compressed

deflate

gzip compressed
gzip, deflate

Uncompressed object
deflate compressed

deflate

No uncompressed object
gzip compressed

(This is effectively a cache-miss.
The ProxySG does not convert
from gzip to deflate.)

Table 6.4: Cache-Miss Compression Behavior
Accept-Encoding:
in client request

Accept-Encoding:
in ProxySG
request

Content-Encoding:
in server response

Generated variants

Content-Encoding:
in ProxySG
response

Identity

Identity

Identity

uncompressed object

Identity

gzip, deflate

gzip, deflate

Identity

uncompressed object

gzip

gzip-compressed
gzip, deflate

gzip, deflate

gzip

No uncompressed
object

gzip

gzip-compressed
gzip, deflate,
compress

gzip, deflate

gzip

No uncompressed
object

gzip

gzip-compressed
gzip, deflate

gzip, deflate

compress (illegal
response)

compress

compress

Compression Exceptions


The ProxySG issues a transformation_error exception (HTTP response code 403), when the
server sends an unknown encoding and the ProxySG is configured to do content transformation.



The ProxySG issues an unsupported_encoding exception (HTTP response code 415 Unsupported Media Type) when the ProxySG is unable to deliver content due to configured
policy.

The messages in the exception pages can be customized. For information on using exception pages,
see "Section D: Defining Exceptions".

204

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies

Configuring Compression
Compression behavior can only be configured through policy—VPM or CPL.

Using VPM to Configure Compression Behavior
Three objects can be used to configure compression and compression levels through VPM:


Client HTTP Compression object: Allows you to determine the behavior when the client wants
the content in a different form than is in the cache.



Server HTTP compression object: Allows you to enable or disable compression and to set options.



HTTP compression level object: Allows you to set a compression level of low, medium, or high.

Complete the following steps to manage HTTP server, client compression, and compression levels.
To Add or Edit Client Compression
1.

2.

Create a Web Access Layer:


Select Configuration>Policy>Visual Policy Manager; click Launch.



Select Policy>Add Web Access Layer from the menu of the Blue Coat VPM window that appears.



Type a layer name into the dialog that appears and click OK.

Add an Action object:


Right click on the item in the Action column; select Set.



Click New in the Set Action Object dialog that appears; select Set Client HTTP Compression.
The Add Client HTTP Compression Object dialog displays.

Figure 6-8: Add Client HTTP Compression Object Dialog



Select the compression options you want to use; click OK.



Click OK again; close the VPM window and click Yes in the dialog to save your changes.

205

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies
To Add or Edit Server Compression
1.

2.

Create a Web Access Layer:


Select Configuration>Policy>Visual Policy Manager; click Launch.



Select Policy>Add Web Access Layer from the menu of the Blue Coat VPM window that appears.



Type a layer name into the dialog that appears and click OK.

Add an Action object:


Right click on the item in the Action column; select Set.



Click New in the Set Action Object dialog that appears; select Set Server HTTP Compression.
The Add Server HTTP Compression Object dialog displays.

Figure 6-9: Add Server HTTP Compression Object Dialog



Select compression options; click OK.



Click OK again; close the VPM window and click Yes in the dialog to save your changes.

Using VPM to Set HTTP Compression Levels
You can control the compression level based on any transaction condition (such as the client IP
address, the hostname, request/response headers, and the like).
To Set Compression Levels
1.

2.

Create a Web Access Layer:


Select Configuration>Policy>Visual Policy Manager; click Launch.



Select Policy>Add Web Access Layer from the menu of the Blue Coat VPM window that appears.



Type a layer name into the dialog that appears and click OK.

Add an Action object:


Right click on the item in the Action column; select Set.



Click New in the Set Action Object dialog that appears; select Set HTTP Compression Level.
The Add HTTP Compression Level Object dialog displays.

206

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies

Figure 6-10: Set HTTP Compression Level



Select the compression level needed; click OK.



Click OK again; close the VPM window and click Yes in the dialog to save your changes.

Using Policy to Configure Compression Behavior
Compression and decompression are allowed if compression is enabled. If compression is not
enabled, neither compression nor decompression are allowed.
Policy controls the compression or decompression of content on the ProxySG. If compression is turned
off, uncompressed content is served to the client if a compressed variant is not available. If
decompression is turned off, an uncompressed version is fetched from the OCS if the variant does not
exist and the client requested uncompressed content.
Note:

The ProxySG decompresses the content if transformation is to be applied, even if the
compression is not enabled.

You can use server-side or client-side controls to manage compression through policy, as described in
the following table.
Table 6.5: Compression Properties
Compression Properties

Meaning

http.allow_compression(yes | no)

Allow the ProxySG to compress content on
demand if needed.

http.allow_decompression(yes | no)

Allow the ProxySG to decompress content on
demand if needed.

http.compression_level(low | medium | high)

Set the compression level to be low (1), medium
(6), or high (9). Low is the default.

http.server.accept_encoding(client)

Turn on only client encodings

http.server.accept_encoding(identity)

Turn off all encodings

http.server.accept_encoding(all)

Turn on all supported encodings, including the
client’s encodings.

207

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies
Table 6.5: Compression Properties (Continued)
Compression Properties

Meaning

http.server.accept_encoding(gzip, deflate)

Send specific encodings (order sensitive)

http.server.accept_encoding(gzip, client)

Send specific encodings (order sensitive)

http.server.accept_encoding.gzip(yes | no)

Add/remove an encoding

http.server.accept_encoding[gzip, deflate,
identity](yes | no)

Add/remove a list of encodings

http.server.accept_encoding.allow_unknown
(yes | no)

Allow/disallow unknown encodings.

http.client.allow_encoding(identity);

Allow no encodings (send uncompressed).

http.client.allow_encoding(client);

Allow all client encodings. This is the default.

http.client.allow_encoding(gzip, deflate);

Allow fixed set of encodings.

http.client.allow_encoding(gzip, client);

Allow fixed set of encodings.

http.client.allow_encoding.gzip(yes | no);

Add/remove one encoding

http.client.allow_encoding[gzip, deflate,
identity](yes | no);

Add/remove list of encodings

Default Behavior
By default, Blue Coat sends the client’s list of the accept encoding algorithms, except for unknown
encodings. If compression is not enabled, the default overrides any configured CPL policy.
If Accept-Encoding request header modification is used, it is overridden by the compression
related policy settings shown in Table 6.5. The Accept-Encoding header modification can continue
to be used if no compression policies are applied, or if compression is not enabled. Otherwise, the
compression-related policies override any Accept-Encoding header modification, even if the
Accept-Encoding header modification appears later in the policy file.
Adding encoding settings with client-side controls depend on if the client originally listed that
encoding in its Accept-Encoding header. If so, these encodings are added to the list of candidates to
be delivered to the client. The first cache object with an Accept-Encoding match to the client-side list
is the one that is delivered.
Suggested Settings for Compression


If client-side bandwidth is expensive in your environment, use the following policy:

http.client.allow_encoding(client)
http.allow_compression(yes)



208

If server-side bandwidth is expensive in your environment, compared to client-side bandwidth
and CPU:

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies
http.server.accept_encoding(all)
http.server.accept_encoding.allow_unknown(no); default
http.allow_compression(yes)
http.allow_decompression(yes)


If CPU is expensive in your environment, compared to server-side and client-side bandwidth:
http.server.accept_encoding(client);If no content transformation policy is
configured
http.server.accept_encoding(identity);If some content transformation policy
is configured
http.allow_compression(no); default
http.allow_decompression(no); default

Limitations


Policy-based content transformations are not stored as variant objects. If content transformation is
configured, it is applied on all cache-hits, and objects might be compressed all the time at the end
of such transformation if they are so configured.



The variant that is available in the cache is served, even if the client requests a compression choice
with a higher qvalue. For example, if a client requests Accept-encoding: gzip;q=1,
deflate;q=0.1, and only a deflate-compressed object is available in the cache, the deflate
compressed object is served.



The HTTP proxy ignores Cache-Control: no-transform directive of the OCS. To change this,
write policy to disallow compression or decompression if Cache-Control: no-transform
response header is present.



The ProxySG treats multiple content encoding (gzip, deflate or gzip, gzip) as an unknown
encoding. (These strings indicate the content has been compressed twice.)



The gzip and deflate formats are treated as completely separate and are not converted from one to
the other.



Blue Coat recommends using gzip encoding (or allowing both gzip and deflate) when using
the HTTP compression feature.



If the ProxySG receives unknown content encoding and if content transformation is configured
(such as popup blocking), an error results.



If the origin server provides compressed content with a different compression level then that
specified in policy, the content is not re-compressed.



If the ProxySG compressed and cached content at a different compression level than the level
specified in a later transaction, the content is not re-compressed.



Parsing of container HTML pages occurs on the server side, so pipelining (prefetching) does not
work when the server provides compressed content.



Compressing a zip file breaks some browser versions, and compressing images does not provide
added performance. For a current list of content types that are not compressed, refer to the
Release Notes.

209

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies


All responses from the server can be compressed, but requests to the server, such as POST
requests, cannot.



Only 200 OK responses can be compressed.

Troubleshooting HTTP Proxy Issues
This section discusses problems you might encounter using the HTTP proxy.

Using Explicit HTTP Proxy with Internet Explorer
Internet Explorer does not allow OCS NTLM authentication through a ProxySG when explicitly
proxied. To correct this, Blue Coat added a Proxy-Support: Session-based-authentication
header that is sent by default when the ProxySG receives a 401 authentication challenge from
upstream when the client connection is an explicit proxy connection.
For older browsers or if both the ProxySG and the OCS do NTLM authentication, the Proxy-Support
header might not work. In this case, you can disable the header and instead enable NTLM-force,
which converts the 401-type server authentication challenge to a 407-type proxy authentication
challenge, supported by Internet Explorer. The ProxySG also converts the resulting
Proxy-Authentication headers in client requests to standard server authorization headers, which
allows an OCS NTLM authentication challenge to pass through when Internet Explorer is explicitly
proxied through the ProxySG.

Disabling the Proxy-Support Header
You can control the header using header modification policy. Suppression or modification of the
Proxy-Support custom header keeps the ProxySG from sending this default header. Use either the
Visual Policy Manager (VPM) or CPL to disable the header through policy. For complete information
on using VPM, see Chapter 14: “The Visual Policy Manager” on page 493.
Note:

To suppress the Proxy-Support header globally, use the http force-ntlm command to
change the option. To suppress the header only in certain situations, continue with the
procedures below.

To Suppress Proxy-Support Header through VPM
To suppress the header using VPM, create a new Web Access Layer. Then:
1.

Right click in the Action field to see the drop-down list; select Set.
The Existing Action Object dialog displays.

2.

Click New to see the drop-down list; select Control Response Header.
The Add Control Response Header Object dialog displays.

210

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies

Figure 6-11: Add Control Response Header Object

3.

Fill in the fields as follows:


Name: Enter a meaningful name. This name displays in the Existing Action Objects dialog.



Show: Select Custom from the drop-down list.



Header Name: Enter Proxy-Support.



Make sure the Suppress radio button is selected.

4.

Click OK.

5.

Scroll to the bottom of the Add Control Response Header Object dialog to see the Proxy-Support
header.

6.

Click OK.

To Suppress Proxy-Support Header through CPL
Use CPL to define the Proxy-Support custom header object and to specify what action to take. The
example below uses Proxy-Support as the action name, but you can choose any name meaningful to
you. The result of this action is to suppress the Proxy-Support header

action.Proxy-Support(yes)
define action Proxy-Support
delete(response.x_header.Proxy-Support)
end action Proxy-Support

Enabling or Disabling NTLM Authentication for Internet Explorer Clients
The following procedure forces Internet Explorer clients explicitly-proxied through a ProxySG to
participate in NTLM authentication. This CLI setting is global, affecting all clients. You can also use
VPM or CPL to provide granular control for NTLM authentication. (See "To Force NTLM
Authentication through VPM" on page 212 and "To Force NTLM Authentication through CPL" on
page 212.) These commands should only be used if the Proxy-support header is not suitable for the
situation.

211

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies

Note:

These procedures can only be done through the CLI. The Management Console is not
available.

Do one of the following (note that the default is http no force-ntlm):


To force NTLM authentication for Internet Explorer clients, enter the following command at the
(config) command prompt:
SGOS#(config) http force-ntlm



To disable NTLM authentication for Internet Explorer clients, enter the following command at the
(config) command prompt:
SGOS#(config) http no force-ntlm

To view all HTTP settings, see "Viewing HTTP Settings through the CLI" on page 201.
To Force NTLM Authentication through VPM
To use VPM to force NTLM authentication, create a new Web Access Layer. Then:
1.

Right click in the Action field to see the drop-down list; select Set.
The Existing Action Object dialog displays.

2.

Scroll to the Force NTLM for Server Auth static object; select it.

3.

Click OK.

To Force NTLM Authentication through CPL
Global configuration of NTLM authentication behavior is set through the CLI command http
force-ntlm (the default is http no force-ntlm). The http.force_ntlm_for_server_auth( ) CPL
property can be used to override the global settings for a particular subset.
To create a rule to force NTLM authentication for explicitly proxied Internet Explorer clients, first
define the action, then define the rule.
This example implements the following policies:


All clients from the “ForceNTLM_subnet” have Force-NTLM turned on. These clients do not use
the Proxy-Support header.



Requests for all other hosts have Force-NTLM turned off. These hosts use the Proxy-Support
header.
define subnet ForceNTLM_subnet
10.10.0.0/16
end

client.address=ForceNTLM_subnet http.force_ntlm_for_server_auth(yes)
http.force_ntlm_for_server_auth(no)
end

212

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies

Configuring a SOCKS Proxy
While SOCKS servers are generally used to provide firewall protection to an enterprise, they also can
be used to provide a generic way to proxy any TCP or UDP protocols. The ProxySG supports both
SOCKSv4/4a and SOCKSv5; however, because of increased username and password authentication
capabilities and compression support, Blue Coat recommends that you use SOCKS v5.
Note:

For Blue Coat compatibility with SOCKS clients, check with customer support.

Understanding SOCKS Compression
Compression over SOCKS is supported for TCP/IP tunnels, which can compress the data transferred
between the branch (downstream proxy) and main office (upstream proxy), reducing bandwidth
consumption and improving latency.
TCP tunnels are created by posting a listener on a static port for protocols that have a well-known
port; applications that use dynamic port numbers are handled through the Endpoint Mapper proxy
that automatically creates TCP tunnels to ports where Microsoft RPC services are running. (For
information on using the Endpoint Mapper proxy, see "Managing the Endpoint Mapper Proxy" on
page 157.)
Except for enabling the SOCKS proxy, no configuration is required on the main office ProxySG to
support SOCKS compression. However, configuration is required on the branch ProxySG to forward
data through the SOCKS gateway. You can use policy or the socks-gateway CLI options to enable
SOCKS compression globally. Using policy, you can enable or disable compression on a
per-connection basis on either the client side or the server side.
If SOCKS compression is enabled and the upstream SOCKS gateway does not support it, the
connection fails.
Note:

Enabling compression on TCP tunnels impacts performance and should be done only
when the ProxySG is sized correctly to handle the incremental CPU load.

In a typical deployment, you will:


Create an Endpoint Mapper proxy at the remote office (the downstream proxy) that intercepts
Microsoft RPC traffic and creates dynamic TCP tunnels. Traffic to port 135 is transparently
redirected to this service using bridging or L4 switch or WCCP. For information on creating and
enabling an Endpoint Mapper proxy service, see "Managing the Endpoint Mapper Proxy" on
page 157.



Create any other TCP tunnel proxies you need at the remote office: SMTP, DNS, and the like. For
information on configuring TCP tunnels, see "Managing TCP Tunneling Services" on page 167.



Create a SOCKS gateway at the remote office and enable compression for that gateway. This
SOCKS gateway points to a SOCKS proxy located at the main office location (the upstream proxy,
the core of the network). For information on creating a SOCKS gateway and enabling SOCKS
compression, see "SOCKS Gateway Configuration" on page 757.

213

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies


Set policy to forward TCP traffic through that SOCKS gateway. You can do this through the
layer using either the VPM or CPL. For more information, see "Using Policy to Control
the SOCKS Proxy" on page 216.

Note:

In cases where more than two proxies exist in the chain and intermediate proxy nodes are
configured to do compression, the traffic is forwarded as is. If the intermediate proxy is
not configured to do compression, traffic is decompressed before being forwarded to the
next proxy.

For more information on deploying SOCKS compression and Endpoint Mapper proxy, refer to the
Blue Coat ProxySG Deployment Guide: Accelerating Performance for Remote Offices.

Creating and Configuring the SOCKS Service
Complete the following steps to create a SOCKS proxy and to configure SOCKS-proxy connection and
timeout values.
To Create a SOCKS Proxy Server through the Management Console
1.

Select Configuration>Services>SOCKS Proxy.

Figure 6-12: SOCKS Proxy Tab

2.

214

Fill in the option fields (described below) as needed. The defaults are displayed and should be
sufficient for most purposes.
Max-Connections

connections

Set maximum allowed SOCKS client connections. The default
of 0 indicates an infinite number of connections are allowed.

Connection timeout

seconds

Set maximum time to wait on an outbound CONNECT.

Bind timeout on
accept

seconds

Set maximum time to wait on an inbound BIND.

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies
Minimum idle timeout

seconds

Specifies the minimum timeout after which SOCKS can
consider the connection for termination when the max
connections are reached.

Maximum idle timeout

seconds

Specifies the max idle timeout value after which SOCKS should
terminate the connection.

To Configure the SOCKS Proxy through the CLI
1.

At the (config) command prompt, enter the following commands:
SGOS#(config) socks-proxy accept-timeout seconds | connect-timeout seconds |
max-connections number | max-idle-timeout seconds | min-idle-timeout seconds

2.

(Optional) View the results.
SGOS#(config) show socks-proxy
max-connections: 0
accept-timeout: 120
connect-timeout: 120
min-idle-timeout: 7200
max-idle-timeout: 0

Enabling the SOCKS Proxy
Note that a SOCKS port is already configured on port 1080 and enabled.
To Edit an Existing SOCKS Port Service through the Management Console
1.

Select Configuration>Services>Service Ports.

2.

Highlight the SOCKS server.

3.

Click Edit; the Edit Service dialog appears.

Figure 6-13: SOCKS Add Service Dialog

4.

In the Protocol drop-down list, select SOCKS.

215

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies
5.

The default IP address value is all. To limit the service to a specific IP, select the IP from the
drop-down list.

6.

In the Port field, specify a port number; select Enable.

7.

Click OK; Click Apply.

To Edit an Existing SOCKS Port Service through the CLI
1.

At the (config) command prompt, enter the following commands:
SGOS#(config) services
SGOS#(config services) socks
SGOS#(config services socks) enable [ip_address:]port

2.

(Optional) View the results:
SGOS#(config services socks) view
Port:
1080
IP: 10.9.87.85
Properties: explicit, enabled

Type: socks

Using Policy to Control the SOCKS Proxy
Once the basic configuration for the SOCKS proxy has been set through the Management Console or
the CLI, you can use policy to control the SOCKS proxy.
Note:



SOCKS compression requires that a SOCKS gateway be set up with SOCKS compression
enabled. You can either use policy to configure a gateway for SOCKS compression, or you
can configure SOCKS compression while you are configuring the SOCKS gateway. To
configure the SOCKS gateway, see "SOCKS Gateway Configuration" on page 757

To use SOCKS version 5, which allows you to use a SOCKS username/password and SOCKS
compression, you must set the version through policy. SOCKS version 4 does not support
compression.


If using VPM, go to the Forwarding layer, select Source>Set Source Object>New>SOCKS Version.



If using CPL. enter the following:
client.protocol=socks
ALLOW socks.version=5
DENY



To use SOCKS compression, you must request SOCKS compression through policy.


216

If using VPM:


For global outbound connections (the downstream proxy or branch office location): go to
the Forwarding layer, select Source>Set Source Object>New>SOCKS Gateway Compression
Object. (Request compression is enabled by default.)



For global inbound connections (the upstream proxy or the main office location): go to the
Web Access Layer, select Action>New>SOCKS Compression Object. (Allow compression is
enabled by default.)

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies


If using CPL:


For global outbound connections (the downstream proxy or branch office location):

client.protocol=tcp socks_gateway(socks_gateway_alias)
socks_gateway.request_compression(yes|no|default)

where default refers to the current configuration.
To enable SOCKS compression on a per-connection basis, use a policy similar to the
following:

client_address=ip_address
socks_gateway.request_compression(yes|no|default)



For global inbound connections (the upstream proxy or the main office location):

socks.method=CONNECT socks.allow_compression(yes|no)

Allow compression is enabled by default.

Understanding Shell Proxies
Shell proxies are those that provide a shell allowing a client to connect to the ProxySG. In this version,
only a Telnet shell proxy is supported.
Using a shell proxy, you can:


terminate a Telnet protocol connection either transparently or explicitly.



authenticate users either transparently or explicitly.



view the access log.



enforce policies specified by CPL.



communicate though an upstream SOCKS gateway and HTTP proxy using the CONNECT
method.

Within the shell, you can configure the prompt and various banners using CPL $substitutions. You
can also use hard-coded text instead of CPL substitutions (available substitutions are listed in the table
below). The syntax for a CPL substitution is:
$(CPL_property)
Table 6.6: Substitutions Available at New Connection Time
proxy.name or
appliance.name

Configured name of the ProxySG.

proxy.address

IP address of the appliance on which this connection is accepted.

proxy.card

Adapter number of the appliance on which this connection is accepted.

client.protocol

This is "telnet".

217

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies
Table 6.6: Substitutions Available at New Connection Time (Continued)
client.address

IP address of the client.

proxy.primary_address or
appliance.primary_address

Primary address of the proxy, not where the user is connected.

release.id

SGOS version.

Customizing Policy Settings for Shell Proxies
To manage a shell proxy through policy, you can use the conditions, properties, and actions list below.
For information on using CPL to manage shell proxies, refer to the Blue Coat ProxySG Content Policy
Language Guide.
Conditions:
All time and date related triggers

proxy.address=

All exception related triggers

proxy.card=

All server_url triggers

proxy.port=

All url triggers

client.protocol=

All authentication related triggers

user-defined conditions

category=

client.protocol=telnet

client.address=

url.scheme=telnet

Properties:
allow, deny, force_deny

force_exception(exception_id[, details])

action.action_name{yes|no)

forward(alias_list | no)

All trace() properties

forward.fail_open(yes | no)

All access_log() properties

reflect_ip(auto|no|client|vip|ip-address)

All log.xxx() properties

socks_gateway(alias_list | no)

access_server(yes|no)

socks_gateway.fail_open(yes | no)

authenticate.force(yes|no)

telnet.prompt(no | string)

authenticate(realm)

telnet.realm_banner(no | string)

exception(exception_id[, details])

telnet.welcome_banner(no | string)

The banner strings support $-sign substitutions.

218

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies
Actions:
rewrite(url.host, host_regex_pattern,
replacement_pattern)

log_message()

rewrite(url, url_regex_pattern,
replacement_pattern)

notify_email(subject, body)

set(url_port, port_number)

notify_snmp(message)

Boundary Conditions for Shell Proxies


A hardcoded timeout of five minutes is enforced from the acceptance of a new connection until
destination information is provided using the Telnet command.



If proxy authentication is enabled, users have three chances to provide correct credentials.



Users are not authenticated until destination information is provided.



Users can only enter up to an accumulated 2048 characters while providing the destination
information. (Previous attempts count against the total number of characters.)



Connection to an upstream HTTP proxy is not encouraged.



If connections from untrustworthy IP address or subnet are not desired, then a
client IP/subnet-based deny policy must be written.

Understanding Telnet Shell Proxies
The Telnet shell proxy allows you to manage a Telnet protocol connection to the ProxySG. Using the
Telnet shell proxy, you can do:


Explicit termination without proxy authentication, where you explicitly connect, through Telnet,
to the ProxySG hostname or IP address. In this case, the ProxySG provides a shell.



Explicit termination with proxy authentication, where after obtaining the destination host and
port information from user, the ProxySG challenges for proxy credentials. Once the correct proxy
credentials are provided and authenticated, the ProxySG makes an upstream connection and goes
into tunnel mode. In this case, the ProxySG provides a shell.



Transparent termination without proxy authentication, where the ProxySG intercepts Telnet
traffic through an L4 switch, software bridge, or any other transparent redirection mechanism.
From the destination address of TCP socket, the ProxySG obtains OCS contact information and
makes the appropriate upstream connection, either directly or through any configured proxy. For
more information on configuring a transparent proxy, see "Transparent Proxies" on page 224.



Transparent termination with proxy authentication, where, after intercepting the transparent
connection, the ProxySG challenges for proxy credentials. Once the correct proxy credentials are
provided and authenticated, the ProxySG makes an upstream connection and goes into tunnel
mode. For more information on configuring a transparent proxy, see "Transparent Proxies" on
page 224.

Once in the shell, the following commands are available:

219

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies


help: Displays available commands and their effects.



telnet : Makes an outgoing telnet connection to specified server. The colon (:)
between server and port can be replaced with a space, if preferred.



exit: Terminates the shell session.

Creating a Telnet Shell Proxy Service
On a new system, Telnet proxy service is configured but disabled on port 23. On an upgrade, a Telnet
proxy service is not created.
To enable or create a Telnet proxy service, use Services>Service Ports on the Management Console, or
config>services>telnet from the CLI. For more information, see "Managing the Telnet Shell Proxy
Service" on page 169.

Customizing Welcome and Realm Banners and Prompt Settings
You can configure banners for the Telnet shell and the realm and set the prompt that users see when
entering the shell.
To Customize Telnet Shell Proxy Settings through the Management Console
1.

Select Configuration>Services>Shell Proxies>Telnet Proxy Settings.

Figure 6-14: Telnet Proxy Settings

220

2.

To set the maximum concurrent connections, select Limit Max Connections. Enter the number of
maximum concurrent connections allowed for this service. Allowed values are between 1 and
65535.

3.

Set the banner settings:

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies
a.

To set the Welcome banner message (users see this when they enter the shell), click
View/Edit next to the Welcome Banner. The Edit Welcome Banner dialog displays. (If you
do not want this banner displayed, remove the text.)

Figure 6-15: Editing Welcome Banner Properties.

Change the banner as necessary. The $(client.protocol) text is a CPL variable indicating
that Telnet is the protocol. You do not have to use a variable. (For a list of available
$substitutions, see "Substitutions Available at New Connection Time" on page 217.) When
finished, click OK. Click Apply.
b.

To set the realms banner message (users see this help message just before they see the
Username prompt for proxy authentication), click View/Edit next to the Realms Banner. The

Edit Realms Banner dialog displays. (If you do not want this banner displayed, remove
the text.)

Figure 6-16: Editing Realm Banner Properties

Change the banner as necessary. The $(realm) text is a CPL variable indicating the name of
the realm. You do not have to use a variable. (For a list of available substitutions, see
"Substitutions Available at New Connection Time" on page 217.) When finished, click OK.
Click Apply.

221

Blue Coat ProxySG Configuration and Management Guide

Section A: Configuring Explicit Proxies
c.

To set the prompt, click View/Edit next to the Prompt line. The Prompt dialog displays.

Figure 6-17: Editing the Prompt

Change the banner as necessary. The default is $(client-protocol)>, where
$(client-protocol) is Telnet. You do not have to use a variable. (For a list of available
substitutions, see "Substitutions Available at New Connection Time" on page 217.) When
finished, click OK. Click Apply.
To Customize Telnet Shell Proxy Settings through the CLI
You can use CPL substitutions when creating welcome and realm banners and Telnet prompts. For a
list of available CPL substitutions, see "Substitutions Available at New Connection Time" on page 217.
1.

From the (config) prompt, enter the following commands:
SGOS#(config) shell max-connections number
SGOS#(config) shell welcome-banner welcome-banner-string (Enclose string in
quotes if string includes spaces)
SGOS#(config) shell realm-banner realm-banner-string (Enclose string in
quotes if string includes spaces)
SGOS#(config) shell prompt prompt-string (Enclose string in quotes if string
includes spaces)

where:

2.

max-connections

number

Allowed values are between 1 and 65535.

welcome-banner

string

The text a user sees when the shell is entered. You can hide this
banner by using shell no welcome-banner.

realm-banner

string

The text a user sees when the realm is entered. You can hide this
banner by using shell no welcome-banner.

prompt

string

The prompt a user sees when the shell is entered. You can hide
the prompt by using shell no prompt.

(Optional) To view the shell settings:
SGOS#(config) show shell
max-connections:
Unlimited
prompt:
Telnet #
realm-banner:
Enter credentials for realm Test
welcome-banner:
Welcome to Blue Coat Telnet shell proxy

222

Chapter 6: Configuring Proxies

Section A: Configuring Explicit Proxies
To hide the shell’s settings:
SGOS#(config)
SGOS#(config)
SGOS#(config)
SGOS#(config)

shell
shell
shell
shell

no
no
no
no

welcome-banner
realm-banner
prompt
max-connections

Boundary Conditions for Telnet Shell Proxies


Telnet credential exchange is in plaintext.



A Telnet proxy cannot be used to communicate with non-Telnet servers (such as Web servers on
port 80) because Telnet proxies negotiate Telnet options with the client before a server connection
can be established.

223

Blue Coat ProxySG Configuration and Management Guide

Section B: Transparent Proxies

Section B: Transparent Proxies
To use transparent proxy, you must:


Configure the network to redirect client requests



Create a transparent proxy service

Configuring the Transparent Proxy Hardware
For transparent proxy to work, you must use one of the following:


ProxySG Pass-Through card



ProxySG software bridge



Layer-4 switch



WCCP

Configuring the Pass-Through Card for Hardware Bridging
The Blue Coat Pass-Through card is a device that enables a bridge, using its two adapters, so that
packets can be forwarded across it. However, if the system crashes, the Pass-Through card becomes a
network: the two Ethernet cables are connected so that traffic can continue to pass through without
restriction.
Configure a transparent service on the bridge's IP address just like for any other IP address, and it
intercepts traffic as usual.
The differences are:


Forwards traffic: it does not intercept without enabling global IP packet forwarding.



Proxies for requests on either adapters, so if you have connected one side of the bridge to your
Internet connection, you must be careful.

Configuring the ProxySG for Software Bridging
Blue Coat supports a software or dynamic bridge that is constructed using a set of installed adapters.
Keep in mind the following about software bridges:


The adapters must of the same type. Although the software does not restrict you from configuring
bridges with adapters of different types (10/100 or GIGE), the resultant behavior is unpredictable.



IP addresses—If any of the adapter interfaces to be added to the bridge already have IP addresses
assigned to them, those IP addresses must be removed.

To set up a software bridge, see "Configuring a Software Bridge" on page 90.

224

Chapter 6: Configuring Proxies

Section B: Transparent Proxies

Configuring a Layer-4 Switch for Transparent Proxy
In Transparent Proxy Acceleration, as traffic is sent to the OCS, any traffic sent on TCP port 80 is
redirected to the ProxySG Appliances by the Layer 4 switch. The benefits to using a Layer 4 switch
include:


Built-in failover protection. In a multi-ProxySG setup, if one ProxySG fails, the Layer 4 switch can
route to the next ProxySG.



Request partitioning based on IP address instead of on HTTP transparent proxying. (This feature
is not available on all Layer 4 switches.)



ProxySG bypass prevention. You can configure a Layer 4 device to always go through the Blue
Coat ProxySG machine even for requests to a specific IP address.



ProxySG bypass enabling. You can configure a Layer 4 device to never go through the ProxySG.

The following are generic directions for configuring transparent proxy using a Layer 4 switch and
ProxySG Appliances. The steps to perform depend on the brand of Layer 4 switch. Refer to the Layer
4 switch manufacturer’s documentation for details.
To Set up Transparent Proxy Using a Layer-4 Switch and the ProxySG
From the Layer 4 switch:
1.

Configure the Layer 4 switch according to the manufacturer's instructions.

2.

Configure for global transparent cache switching (TCS). With global TCS, incoming traffic from all
devices attached to all ports of the Layer-4 switch is redirected to the ProxySG. Assign an IP
address, default gateway, and subnet mask to the Layer-4 switch.

3.

Configure TCS using a global policy, enabling redirection for all ports.

4.

Identify one or more ProxySG Appliances.

5.

Create a device server group.

6.

Apply the ProxySG name to the device group.

7.

Configure Ethernet interface 2.

8.

Disable the redirection policy for the port to which the ProxySG is connected.

9.

Configure Ethernet interface 4.

10. Disable the redirection policy for the port to which the router is connected.
11. (Optional) Configure the Layer-4 switch for server load balancing.
12. Save the Layer-4 switch configuration.
From the ProxySG:


Define the appropriate IP configurations per the instructions in the Installation Guide that
accompanied the ProxySG.



Test the new network configuration.

225

Blue Coat ProxySG Configuration and Management Guide

Section B: Transparent Proxies

Configuring WCCP for Transparent Proxy
WCCP is a Cisco®-developed protocol that allows you to establish redirection of the traffic that flows
through routers.
The main benefits of using WCCP are:


Scalability—With no reconfiguration overhead, redirected traffic can be automatically distributed
to up to 32 ProxySG Appliances.



Redirection safeguards—If no ProxySG Appliances are available, redirection stops and the router
forwards traffic to the original destination address.

For information on using WCCP with a Blue Coat ProxySG, see Appendix C: “Using WCCP” on
page 957.

Understanding IP Forwarding
IP Forwarding is a special type of transparent proxy. The ProxySG is configured to act as a gateway.
The gateway is configured so that if a packet is addressed to the gateway’s adapter, but not to its IP
address, the packet is forwarded toward the final destination. (If IP forwarding is turned off, the
packet is rejected as being mis-addressed).
By default, IP forwarding is set to off (disabled) to maintain a secure network.
To Enable IP Forwarding through the Management Console
1.

Select Configuration>Network>Routing>Gateways.

2.

Select the Enable IP forwarding checkbox.

3.

Click Apply.

To Enable IP Forwarding through the CLI
At the (config) command prompt, enter the following command:
SGOS#(config) tcp-ip ip-forwarding enable

Important: When IP forwarding is enabled, be aware that all ProxySG ports are open and all the
traffic coming through them is not subjected to policy, with the exception of the
ports explicitly defined (Configuration> Services>Service Ports).

Creating a Transparent Proxy Service
As noted earlier, Blue Coat recommends that you ignore authentication until the proxy service is
configured and running.
The below example uses HTTP. Note that two HTTP services are already configured and enabled on
SGOS 4.x.

226

Chapter 6: Configuring Proxies

Section B: Transparent Proxies
To Create a Transparent HTTP Port Service through the Management Console
1.

Select Configuration>Services>Service Ports.

2.

Click New; the Add Service dialog appears.

Figure 6-18: HTTP Add Service Dialog

3.

In the Protocol drop-down list, select HTTP.

4.

The default IP address value is all. To limit the service to a specific IP, select the IP from the
drop-down list.

5.

In the Port field, specify a port number; select Enable.

6.

In the Attributes field, select Transparent.

7.

Click OK; Click Apply.

To Create a Transparent HTTP Port Service through the CLI
At the (config) command prompt, enter the following commands:
SGOS#(config) services
SGOS#(config services) http
SGOS#(config services http) create [ip_address:]port
SGOS#(config services http) attribute transparent enable [ip_address:]port
SGOS#(config services http) enable [ip_address:]port

Example
SGOS#(config services http)attribute transparent enable 80

To View the Results
SGOS#(config services http) view
Port:
8080
IP: 0.0.0.0
Properties: explicit, enabled
Port:
80
IP: 0.0.0.0
Properties: transparent, enabled

Type: http
Type: http

227

Blue Coat ProxySG Configuration and Management Guide

Section B: Transparent Proxies

228

Chapter 7: Using Secure Services

Secure services allow you to provide the maximum security level for your enterprise. Maximum
security is provided by using:


SSH (with optional RSA authentication).



HTTPS instead of HTTP for secure communication over insecure channels.



A method of authenticating (identifying your users) and authorizing (limiting what a user can
do).

Configuring secure services requires creating and using keypairs and certificates to verify trusted
hosts.
This chapter discusses:


"Section A: HTTPS Termination Overview"



"Section B: Configuring HTTPS Termination"



"Section C: Managing the SSL Client"



"Section D: Configuring HTTP or HTTPS Origination to the Origin Content Server"



"Section E: Advanced Configuration"

229

Blue Coat ProxySG Configuration and Management Guide

Section A: HTTPS Termination Overview

Section A: HTTPS Termination Overview
Offloading SSL processing from the origin server (referred to as HTTPS termination), allows a large
number of requests to be processed very quickly from the ProxySG.
The HTTPS termination implementation:


Combines hardware-based SSL acceleration with full caching functionality.



Establishes and services incoming SSL sessions.



Provides SSL v2.0, v3.0, and TLSv1 protocol support.

A common scenario in using HTTPS termination, which connects the client to the ProxySG, is in
conjunction with HTTPS origination, which is used to connect the ProxySG to the origin content server
(OCS).
Before discussing the specifics of how a ProxySG accelerates HTTPS requests, it is important to
understand securing data using HTTPS. There are several RFCs and books on the public key
cryptographic system (PKCS). This discussion of the elements of PKCS is relevant to their
implementation in SGOS.
The key concepts to understand are:


Public keys and private keys



Certificates



Keyrings



Cipher Suites



SSL client

Public Keys and Private Keys
The intended recipient of encrypted data generates a private/public keypair, and publishes the public
key, keeping the private key secret. The sender encrypts the data with the recipient's public key, and
sends the encrypted data to the recipient. The recipient uses the corresponding private key to decrypt
the data.
For two-way encrypted communication, the endpoints can exchange public keys, or one endpoint can
choose a symmetric encryption key, encrypt it with the other endpoint's public key, and send it.

Certificates
Two major kinds of certificates are used with SGOS:

230



Server (SSL) Certificates



Self-Signed Certificates

Chapter 7: Using Secure Services

Section A: HTTPS Termination Overview

Server (SSL) Certificates
Server certificates are used to authenticate the identity of a server. A certificate is electronic
confirmation of the owner of a public key is who he or she really claims to be and thus holds the
private key corresponding to the public key in the certificate. The certificate contains other
information, such as its expiration date.
The association between a public key and a particular server is done by generating a certificate
signing request using the server's public key. A certificate signing authority verifies the identity of the
server and generates a signed certificate. The resulting certificate can then be offered by the server to
clients who can recognize the CA's signature and trust that the server is who it claims to be. Such use
of certificates issued by CAs has become the primary infrastructure for authentication of
communications over the Internet.
ProxySG Appliances come with many popular CA certificates already installed. You can review these
certificates using the Management Console or the CLI. You can also add certificates for your own
internal certificate authorities.
CA certificates installed on the ProxySG are used to verify client certificates (when browsers are
configured to offer them during negotiation) and are also required to verify secure servers in
communication with the ProxySG.

Self-Signed Certificates
A self-signed certificate is a certificate that you create and authorize yourself that has no official
guarantees or authority in the real world. It is mainly used for intranet security.
Any server certificate can contain a common name with wildcard characters.
Wildcard certificates during HTTPS termination are supported. Microsoft’s implementation of
wildcard certificates is as described in RFC 2595, allowing an * (asterisk) in the leftmost-element of the
server's common name only. For information on wildcards supported by Internet Explorer, refer to the
Microsoft knowledge base, article: 258858.
Note:

Another kind of certificate is called an external certificate. An external certificate is an
X.509 certificate created outside the ProxySG for the purpose of encrypting data, such as
access logs, with a public key on the ProxySG so that it can only be decrypted by someone
off-box who has the corresponding private key. When you import an external certificate to
the ProxySG, you can use it to encrypt your access logs so that only those with the
appropriate security credential can decrypt them. See "Configuring the Upload Client" on
page 798 for information about encrypting access logs.

Keyrings
A keyring contains a public/private keypair. It can also contain a certificate signing request or a
signed certificate.

231

Blue Coat ProxySG Configuration and Management Guide

Section A: HTTPS Termination Overview

Cipher Suites Supported by SGOS
A cipher suite is an object that specifies the algorithms used to secure an SSL connection. When a
client makes an SSL connection to a server, it sends a list of the cipher suites that it supports. The
server compares this list with its own supported cipher suites and chooses the first cipher suite
proposed by the client that they both support. Both the client and server then use this cipher suite to
secure the connection.
Note:

You can delete cipher suites that you do not trust.

All cipher suites supported by the ProxySG use the RSA key exchange algorithm, which uses the
public key encoded in the server's certificate to encrypt a piece of secret data for transfer from the
client to server. This secret is then used at both endpoints to compute encryption keys.
By default, the ProxySG is configured to allow SSLv2 and v3 as well as TLSv1 traffic. The cipher suites
available to use differ depending on whether you configure SSL for version 2, version 3, TLS, or a
combination of these.
Table 7.1: SGOS Cipher Suites Shipped with the ProxySG
SGOS Cipher #

Cipher Name

Strength

Exportable

Description

1

RC4-MD5

Medium

No

128-bit key size.

2

RC4-SHA

Medium

No

128-bit key size.

3

DES-CBC3-SHA

High

No

168-bit key size.

4

DES-CBC3-MD5

High

No

168-bit key size.

5

RC2-CBC-MD5

Medium

No

128-bit key size.

6

RC4-64-MD5

Low

No

64-bit key size.

7

DES-CBC-SHA

Low

No

56-bit key size.

8

DES-CBC-MD5

Low

No

56-bit key size.

9

EXP1024-RC4-MD5

Export

Yes

56-bit key size.

10

EXP1024-RC4-SHA

Export

Yes

56-bit key size.

11

EXP1024-RC2-CBC-MD5

Export

Yes

56-bit key size.

12

EXP1024-DES-CBC-SHA

Export

Yes

56-bit key size.

13

EXP-RC4-MD5

Export

Yes

40-bit key size.

14

EXP-RC2-CBC-MD5

Export

Yes

40-bit key size.

15

EXP-DES-CBC-SHA

Export

Yes

40-bit key size.

Cipher Suite configuration is discussed in "Associating a Keyring and Protocol with the SSL Client" on
page 251.

232

Chapter 7: Using Secure Services

Section A: HTTPS Termination Overview

Server Gated Cryptography and International Step-Up
Due to US export restrictions, international access to a secure site requires the site negotiate
export-only ciphers. These are relatively weak ciphers ranging from 40-bit to 56-bit key lengths, and
are vulnerable to attack.
Server Gated Cryptography (SGC) is a Microsoft extension to the certificate that allows the client
receiving the certificate to first negotiate export strength ciphers, followed by a re-negotiation with
strong ciphers. Netscape has a similar extension called International Step-up.
The ProxySG supports both SGC and International Step-up in its SSL implementation. There are,
however, known anomalies in Internet Explorer's implementation that can cause SSL negotiation to
fail. Refer to the following two documents for more detail and check for recent updates on the
Microsoft support site.
http://support.microsoft.com/support/kb/articles/Q249/8/63.ASP
http://support.microsoft.com/support/kb/articles/Q244/3/02.ASP

To take advantage of this technology, the ProxySG supports Verisign’s Global ID Certificate product.
The Global ID certificate contains the extra information necessary to implement SGC and
International Step-up.
Note:

When requesting a Global ID certificate, be sure to specify bluecoat as the server.

Understanding SSL Client
The SSL client is used to determine the protocol of outgoing HTTPS connections. The protocol must be
specified when a ProxySG obtains content from the origin server using an encrypted connection.
The ProxySG uses one SSL client. The role of the SSL client is to:


Determine which certificate can be presented to origin servers by associating a keyring with the
SSL client.



Identify the protocol version the ProxySG uses in negotiations with origin servers.



Identify the cipher suites used.

233

Blue Coat ProxySG Configuration and Management Guide

Section B: Configuring HTTPS Termination

Section B: Configuring HTTPS Termination
To configure HTTPS termination, complete the following tasks:


Create a keyring. A default keyring is shipped with the system and is used for accessing the
management console. Create other keyrings for each SSL service. (See "Creating a Keyring" on
page 235.)
Note:

You can also import keyrings. For information on importing keyrings, see "Importing an
Existing Keypair and Certificate" on page 259.



(Optional) Create Certificate Signing Requests (CSRs) that can be sent to Certificate Signing
Authorities (CAs).



Import server certificates from CA authorities for external use and associate them with the
keyring. (See "Managing Server (SSL) Certificates" on page 243.)
-or-



Create certificates for internal use and associate them with the keyring. (See "Deleting an Existing
Keyring and Certificate" on page 239.)



Create the HTTPS Service. The keyring should contain the server certificate to present to clients
connecting to this service. For general information on enabling services, see Chapter 5:
“Managing Port Services” on page 143. For specific information on enabling the HTTPS Service,
see "Managing the HTTPS Service" on page 161.)
Note:

If connections will be forwarded upstream using HTTPS, you can configure the SSL client
appropriately. You can also set the SSL configuration timeout period, if the default is not
satisfactory. For information on managing the SSL client, see "Managing the SSL Client"
on page 250.

Do these steps in order.
Note:

These steps must be done with a serial console or SSH connection.

Before you begin, you should be familiar with the following terms:
CA Certificates

This is a certificate that has been given out by a CA identifying the authority and what
public key to use to verify certificates signed by them. CA certificates are used to verify
certificates presented by clients during HTTPS termination or to verify certificates
presented by servers during HTTPS origination.
You only need this certificate if the ProxySG is obtaining data through an encrypted
source.

CA-Certificate
Lists

234

CA-Certificate lists allow you to associate a specific CA certificate (or a list of CA
certificates) with the HTTPS service you create.

Chapter 7: Using Secure Services

Section B: Configuring HTTPS Termination
Certificates

Regular certificates are presented by the ProxySG as server certificates when doing
HTTPS Termination or as client certificates when doing HTTPS origination.
A certificate can be created (self-signed) or imported from another machine. Certificates
and CA Certificates are imported differently on the ProxySG and have different purposes.

Certificate Signing
Authority (CA)

CAs receive Certificate Signing Requests and create certificates from the information and
the keypair provided. The certificate is then returned to the originator, who can import it
into the ProxySG.

Certificate Signing
Request (CSR)

CSRs are used to send a keypair and critical information to a Certificate Signing
Authority. You can use Blue Coat to create a CSR or you can create a CA Certificate
off-line.
The CSR is then sent to a Certificate Signing Authority, which provides a signed
certificate after verifying the requester's identity.

SSL Client

Only one SSL client can be used on the ProxySG, and only one keyring can be associated
with it. If a keyring is associated with the SSL client and you change the association, the
old association is overwritten by the new.

HTTPS Service

A service on which the ProxySG listens for Web requests sent through the HTTPS
protocol.

Keyring

A keyring holds a public and private keypair, and can be used when configuring secure
connections on the ProxySG. When a keyring is created, it only contains a keypair. You
can associate a certificate with this keyring. If you have multiple certificates, you can
configure multiple keyrings and associate the certificates and the keyrings.

Creating a Keyring
The ProxySG ships with two keyrings already created:


default



configuration-passwords-key

The default keyring contains a certificate and an automatically-generated keypair. The default key is
intended for securely accessing the ProxySG management console. Create an additional keyring for
each https service defined.
Note:

A keyring is not re-usable. If you use multiple certificates, you must create multiple
keyrings.

You must associate a keyring with the SSL client if the ProxySG is obtaining content through HTTPS
from an origin content server (OCS) that requires a client certificate to be presented. If the OCS
requires a client certificate and no keyring is associated with the SSL client, the connections fails. For
information on associating a keyring with the SSL client, "Managing the SSL Client" on page 250.
The configuration-passwords-key keyring contains a keypair but does not contain a certificate. It is
a keyring created for encrypting passwords in the show config command and should not be used for
other purposes.

235

Blue Coat ProxySG Configuration and Management Guide

Section B: Configuring HTTPS Termination
To Create a Keyring through the Management Console
1.

Select Configuration>SSL>Keyrings>SSL Keyrings.

Figure 7-1: SSL Keyring Tab

2.

Click Create; the Create Keyring dialog appears.

Figure 7-2: Create Keyring Dialog

3.

236

Fill in the dialog window as follows:


Keyring Name: Give the keyring a meaningful name to you.



Select the show option you need:


Show keypair allows the keys, and everything in the keys, to be exported.



Do not show keypair prevents the keypair from being exported.

Chapter 7: Using Secure Services

Section B: Configuring HTTPS Termination


Show keypair to director is a keyring viewable only if Director is issuing the command using

a SSH-RSA connection.
Note:



The choice of show/show-director/no-show has implications for whether keyrings
are included in profiles and backups created by Director. For more information, refer
to Blue Coat Director User Guide.

Select the key length in the Create a new ______ -bit keyring field. A length of 1024 bits is the
maximum (and default). Longer keyrings provide better security, but with a slight
performance expense on the ProxySG. Be aware that the maximum key length allowed for
international export might be different than the default. For deployments reaching outside the
U.S., determine the maximum key length allowed for export.
Click OK. The keyring is created with the name you chose. It does not have a certificate
associated with it yet. To associate a certificate, see "Associating a Keyring and Protocol with
the SSL Client" on page 251
-or-



Select the Import keyring radio button.
The grayed-out Keyring field becomes enabled, allowing you to paste in an already existing
private key. The certificate associated with this private key must be imported separately. For
information on importing a certificate, see "Deleting an Existing Keyring and Certificate" on
page 239.
If the private key that is being imported has been encrypted with a password, select Keyring
Password and enter the password into the field.
Note:

4.

The only way to retrieve a keyring's private key from the ProxySG is by using
Director or the command line —it cannot be exported through the management
console.

Click OK.

To Create an SSL Keyring through the CLI
At the (config) command prompt, enter the following commands to create an SSL keyring:
SGOS#(config) ssl
SGOS#(config ssl) create keyring {show | show-director | no-show} keyring_id
[key_length]

237

Blue Coat ProxySG Configuration and Management Guide

Section B: Configuring HTTPS Termination
where:
show |
show-director
| no-show

• show: Allows the keys, and everything in the keys, to be exported.
• show-director: Prevents the keypair from being exported.
• no-show: A keyring viewable only if Director is issuing the command using a
SSH-RSA connection.
Note: The choice of show/show-director/no-show has implications for
whether keyrings are included in profiles and backups created by Director. For
more information, refer to Blue Coat Director User Guide.

keyring_id

The name, meaningful to you, of the keyring.

key_length

Longer keypairs provide better security, but with a slight performance expense
on the ProxySG appliance. The default key length used in SGOS and most
US-based servers is 1024, which is the maximum key length. Be aware that the
maximum key length allowed for international export might be different than the
default. For deployments reaching outside of the US, determine the maximum
key length allowed for export.

To View the Results of a New Keyring through the CLI
Note:

This example shows the default keyring.

SGOS#(config ssl) view keyring
KeyringID: default
Is private key showable? yes
Have CSR? no
Have certificate? yes
Is certificate valid? yes
CA: Blue Coat SG110
Expiration Date: Dec 16 22:37:30 2013 GMT
Fingerprint: AA:E2:34:DB:5D:06:A7:FF:D8:69:BE:0D:12:FC:34:D5
KeyringID: configuration-passwords-key
Is private key showable? yes
Have CSR? no
Have certificate? no

To View a Keypair
Note:

This example shows the default keypair, unencrypted.

SGOS#(config ssl) view keypair [des | des3 | unencrypted] [keyring_id]
[password]
-----BEGIN RSA PRIVATE KEY----MIICWwIBAAKBgQC6t/IhFTYuyczvEN/wT4dcJl3Ar/aEKs/CjL9DPG+ND79sscFe
tfzmLrjBvxJmZYnim6VEMtKb0qH37YQjXwtQFqYAdWe+yKS6kqJ+Rky/mgHX8awL
RvijFlBkLYMG2SOa1YphOTg/v/dPm28TyJ5ZcavM5Atdpa+RRGPPDR1YQwIDAQAB
AoGAE4TVL/Yqsttvq/Ikptd5e/2awWDjsU9UZq8V825m7uUdirxOTZtSs7FgqQhT
YRbuQh0pOqbhc16ihetza8sswGXJe7YYF7d2zQAfwDsvSTcsVu1mXQmdhddItGuv

238

Chapter 7: Using Secure Services

Section B: Configuring HTTPS Termination
+nZWVMqP/tQIk/NtRhp6IJ2qg4Mu3yEVfDEeHP1Um2nGPbECQQDltYIaoiLW27sa
+O7Rzl2geVoVvdROjKg0g0gyT65tRCgqyGv6AXI1+gWl1TcP5rhOlB9XX3i0wiUp
HejKsompAkEA0BbQNCRXUXZTPyK6R6JaHE0Ji8SSXtLCUN9RZrChdjGc263D6/IV
/jqpqkLLR2qSibmKDX1ADmYAP9U18ta+CwJAecPBd8TCmwpXIHEch3LRBqPNMQEz
bX/6GfwNZT3/xEQA1szvD9N8a0hhfgqL6Y3v3Rd/lZ0yKv9PG4CTSf9iIQJAL7Jq
+uixkxyaLEibhjvyh7Yoz/64xj9tBviJQg6Ok/b/S2NjGzwcSm/L4Bj7W11URXlf
6YOiISrEN915RjZuzQJAYUlytdCj7pM2nziyO7jrWnY8MmIod3+kHlQajoV/OI6Q
Z5gaJ2nLOwicSlSY4MFewHavvRS18yI9JP2q1+6Y/g==
-----END RSA PRIVATE KEY-----

Notes


If you want to view the keypair in an encrypted format, you can optionally specify des or des3
before the keyring_id, along with an optional password. If the optional password is provided on
the command line, the CLI does not prompt for a password. You can also use ““ to specify an
empty password to make the command non-interactive.



If the optional password is not provided on the command line, the CLI asks for the password
(interactive). If you specify either des or des3, you are prompted.



To view the keypair in unencrypted format, select either the optional keyring_id or use the
unencrypted command option.



You cannot view a keypair over a Telnet connection because of the risk that it could be
intercepted.

Deleting an Existing Keyring and Certificate
To Delete a Keyring and the Associated Certificate through the Management Console
1.

Select Configuration>SSL>Keyrings>SSL Keyrings.

2.

Highlight the name of the keyring that you want to delete.

3.

Click Delete.
The Confirm delete dialog appears.

4.

Click OK in the Confirm delete dialog.

To Delete a Keyring and the Associated Certificate through the CLI
From the (config) prompt, enter the following commands:
SGOS#(config) ssl
SGOS#(config ssl) delete keyring keyring_id

Managing Certificate Signing Requests
While you must create certificate signing requests (CSR) to get a certificate signed by a Certificate
Authority, CSRs are also used for the configuration of certificates that are sent out to clients or servers
for external validation.

239

Blue Coat ProxySG Configuration and Management Guide

Section B: Configuring HTTPS Termination

Creating a CSR
To Create a CSR through the Management Console
1.

Select Configuration>SSL>SSL Keyrings>SSL Certificates.

2.

From the drop-down list, select the keyring for which you need a signed certificate.

3.

From the Certificate Signing Request tab, click the Create button.
The Create Certificate-signing-request dialog displays.

Figure 7-3: Create Certificate-Signing-Request Dialog

4.

Fill in the fields as appropriate:


State/Province—Enter the state or province where the machine is located.



Country Code—Enter the two-character ISO code of the country.



City/Locality—Enter the city.



Organization—Enter the name of the company.



Unit—Enter the name of the group that is managing the machine.



Common Name—Enter the URL of the company.



Challenge—Enter a 4-16 character alphanumeric challenge.



E-mail Address—The e-mail address you enter must be 40 characters or less. A longer e-mail

address will generate an error.


Company—Enter the name of the company.

5.

The Create tab displays the message: Creating....

6.

Click OK.

Creating a CSR through the CLI
You have a choice of using the interactive or non-interactive create command.

240

Chapter 7: Using Secure Services

Section B: Configuring HTTPS Termination

Note:

Director uses non-interactive commands in profiles and overlays to create certificate
signing requests.
For more information on Director, refer to the Blue Coat Director Configuration and
Management Guide.)

To create a CSR using the:


interactive create signing-request command: continue with the next section.



non-interactive create signing-request command: skip to "To Create a Signing Request
Non-interactively Using Create Commands" on page 242.

To Create a CSR Interactively using Create Commands
1.

At the (config) command prompt, enter the following commands to create an SSL CSR:
SGOS#(config) ssl
SGOS#(config ssl) create signing-request keyring_id
Country code []: US
State or province []: CA
Locality or city []: SV
Organization name []: Blue Coat
Organization unit []: Docs
Common name []: www.bluecoat.com
Email address []: test@bluecoat.com
Challenge []: test
Company name []: Blue Coat
ok

where:
Country code

At the country code prompt, enter the two-character ISO code of the
country.

State or province

Name of the state or province where the machine is located.

Locality or city

Name of the town where the machine is located.

Organization name

Name of the company.

Organization unit

Name of the group within the company.

Common name

Verify the Common name is the same as the domain name of the Web
site being terminated. If the Common name and site domain name do
not match, a client browser generates a warning whenever the
ProxySG terminates an HTTPS request for that site. The use of
wildcards is supported in the Common name.

Email address

The e-mail address you enter must be 40 characters or less. A longer
e-mail address generates an error

Challenge

At the challenge prompt, enter a 4-16 character alphanumeric secret.

241

Blue Coat ProxySG Configuration and Management Guide

Section B: Configuring HTTPS Termination
Company name

2.

Name of the company.

View the results.
SGOS#(config ssl) view signing-request keyring_id
-----BEGIN CERTIFICATE REQUEST----MIIBVDCCAQ4CAQAwgYcxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTELMAkGA1UEBxMCU1YxEjAQ
BgNVBAoTCUJsdWUgQ29hdDENMAsGA1UECxMERG9jczEZMBcGA1UEAxMQd3d3LmJsdWVjb2F0LmN
vbTEgMB4GCSqGSIb3DQEJARYRdGVzdEBibHVlY29hdC5jb20wTDANBgkqhkiG9w0BAQEFAAM7AD
A4AjEAobHjK0AsnKV0TcsntWCdfTaNyCgwNDXffxT5FwM0xkzQi0pCSku27CJXn7TahrKRAgMBA
AGgMTAUBgkqhkiG9w0BCQcxBxMFdGVzdAAwGQYJKoZIhvcNAQkCMQwWCkJsdWUgQ29hdAAwDQYJ
KoZIhvcNAQEEBQADMQBooZfEnzZT2WMMiu3oT9EP3CdtddOTtdBImWUXPdHJGfm1vEJ7HI0cE0W
71JP6pUY=
-----END CERTIFICATE REQUEST-----

To Create a Signing Request Non-interactively Using Create Commands
At the (config) command prompt, enter the following commands to create a signing request:
SGOS#(config) ssl
SGOS#(config ssl) create signing-request keyring_id [attribute_value]
[attribute_value]

where the following attribute and value pairs are accepted:
Mandatory:
• cn common_name
• challenge at_least_four_characters
Optional:
• c 2_character_country_code
• o organization_name
• ou organizational_unit
• email e-mail_id
• state state or province
• city locality or city
• company company_name

Notes:

242



If you do not specify any attributes, the interactive mode is assumed, meaning that the CSR
cannot be created by Director in profiles or overlays.



The name of the attribute is predefined and the value of the attribute is a string. The value can be
quoted if it contains white space or other special characters.



You must specify the name and value together; the order of appearance of multiple name value
pairs does not matter. If you omit an attribute, an empty string is assumed for the value of the
attribute.

Chapter 7: Using Secure Services

Section B: Configuring HTTPS Termination
Example:
#(config ssl) create signing-request keyring_id cn bluecoat challenge test
c US state CA company bluecoat

Viewing a Certificate Signing Request
The main reason to view a certificate signing request is so that it can be copied for submission to the
Certificate Signing Authority. You can view the certificate signing request either through the
Management Console or the CLI.
To View a Certificate Signing Request through the Management Console
1.

Select Configuration>SSL>SSL Keyrings>SSL Certificates.

2.

From the drop-down list, select the keyring for which you have created a certificate signing
request.
The certificate signing request displays in the Certificate Signing Request window and can be
copied for submission to a Certificate Signing Authority.

To View a Certificate Signing Request through the CLI
At the (config) command prompt, enter the following commands to create a signing request:
SGOS#(config) ssl
SGOS#(config ssl) view signing-request keyring_id

The certificate signing request displays and can be copied for submission to a Certificate
Signing Authority

Managing Server (SSL) Certificates
Server (SSL) certificates can be obtained two ways:


Created on the ProxySG as a self-signed certificate



Imported after receiving the certificate from the signing authority

If you plan to use server (SSL) certificates (issued by well-known Certificate Authorities), you can
obtain the keypair and Certificate Signing Requests (CSRs) off box and send them to the Certificate
Authority for signing. You can also create self-signed SSL certificates for internal use.
Once the signed request is returned to you from the CA, you can import the certificate into the
ProxySG. To create a Blue Coat CSR, see "Creating a CSR" on page 240.
Note:

If you have a CA certificate that is not on the ProxySG default CA certificate list, you
might receive the following message when attempting to connect to a Web site:
Network Error (ssl_failed)
A secure SSL session could not be established with the Web Site:.

You must import the CA Certificate before the ProxySG can trust the site.

243

Blue Coat ProxySG Configuration and Management Guide

Section B: Configuring HTTPS Termination
To create a SSL self-signed certificate on the ProxySG using a Certificate Signing Request, continue
with the next section.
Note:

You can also create a self-signed certificate just by pressing the Create button on the
Configuration>SSL>Keyrings>SSL Certificates pane.

To import an SSL Certificate, skip "Importing a Server Certificate" on page 248.

Creating Self-Signed SSL Certificates
The ProxySG ships with a self-signed certificate, associated with the default keyring. Only one
certificate can be associated with a keyring. If you have multiple services, you require one keyring for
each certificate.

Adding a Self-Signed SSL Certificate
Self-signed certificates are generally meant for intranet use, not Internet.
To Create a Self-Signed Certificate through the Management Console
1.

Select Configuration>SSL>Keyrings>SSL Certificates.

Figure 7-4: SSL Certificates Tab

2.

Select the keyring for which you want to add a certificate in the keyring drop-down list.

3.

Click Create in the Certificate tab.
The Create Certificate dialog displays.

244

Chapter 7: Using Secure Services

Section B: Configuring HTTPS Termination

Figure 7-5: Create Certificate Dialog

4.

Fill in the fields as appropriate:


State/Province—Enter the state or province where the machine is located.



Country Code—Enter the two-character ISO code of the country.



City/Locality—Enter the city.



Organization—Enter the name of the company.



Unit—Enter the name of the group that is managing the machine.



Common Name—A common name should be the one that contains the URL with client access

to that particular origin server.


Challenge—Enter a 4-16 character alphanumeric challenge.



E-mail Address—The e-mail address you enter must be 40 characters or less. A longer e-mail

address will generate an error.

5.

Company—Enter the name of the company.

The Create tab displays the message: Creating.....

To Create a Self-Signed SSL Certificate through the CLI
You can create a self-signed certificate two ways: interactively or non-interactively.
Note:

Director uses non-interactive commands in profiles and overlays to create self-signed
certificates.

To create a certificate using the:


interactive version of the create certificate command: continue with the next section.



non-interactive version of the create certificate command: skip to "To Create a Self-Signed
SSL Certificate Non-interactively Using Create Commands" on page 247.

245

Blue Coat ProxySG Configuration and Management Guide

Section B: Configuring HTTPS Termination

Note:

If you want the certificate to be part of a profile or overlay, the keyring must be configured
as showable.

To Create a Self-Signed SSL Certificate Interactively Using Create Commands
1.

At the (config) command prompt, enter the following commands to interactively create a
self-signed certificate.
SGOS#(config ssl) create certificate keyring_id
Country code []: US
State or province []: CA
Locality or city []: SV
Organization name []: Blue Coat
Organization unit []: Docs
Common name []: www.bluecoat.com
Email address []: test@bluecoat.com
Challenge []: test
Company name []: Blue Coat
ok

where:

2.

Country code

At the Country code prompt, enter the two-character ISO code of the
country.

State or province

Name of the state or province where the machine is located.

Locality or city

Name of the town where the machine is located.

Organization name

Name of the company.

Organization unit

Name of the group within the company.

Common name

Verify the Common name is the same as the domain name of the Web site
being terminated. If the Common name and site domain name do not
match, a client browser generates a warning whenever the ProxySG
terminates an HTTPS request for that site. The use of wildcards is
supported in the Common name.

Email address

The e-mail address you enter must be 40 characters or less. A longer
e-mail address will generate an error

Challenge

At the Challenge prompt, enter a 4-16 character alphanumeric secret.

Company name

Name of the company.

View the certificate.
SGOS#(config ssl) view certificate keyring_id
-----BEGIN CERTIFICATE----MIIB3zCCAZmgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBhzELMAkGA1UEBhMCVVMxCzAJBgNVBAgT
AkNBMQswCQYDVQQHEwJTVjESMBAGA1UEChMJQmx1ZSBDb2F0MQ0wCwYDVQQLEwREb2NzMRkwFwY
DVQQDExB3d3cuYmx1ZWNvYXQuY29tMSAwHgYJKoZIhvcNAQkBFhF0ZXN0QGJsdWVjb2F0LmNvbT

246

Chapter 7: Using Secure Services

Section B: Configuring HTTPS Termination
AeFw0wMzAzMDQyMTA2NThaFw0wMzA0MDMyMTA2NThaMIGHMQswCQYDVQQGEwJVUzELMAkGA1UEC
BMCQ0ExCzAJBgNVBAcTAlNWMRIwEAYDVQQKEwlCbHVlIENvYXQxDTALBgNVBAsTBERvY3MxGTAX
BgNVBAMTEHd3dy5ibHVlY29hdC5jb20xIDAeBgkqhkiG9w0BCQEWEXRlc3RAYmx1ZWNvYXQuY29
tMEwwDQYJKoZIhvcNAQEBBQADOwAwOAIxAK+AGYRMbnjyGr7U0oZUYdslO6y8uQnxq2PV6qCr4Q
BpN1Vqyr1Fi7ZEaw0lyMs5FwIDAQABMA0GCSqGSIb3DQEBBAUAAzEAe8zoYW0igTcGRGG7sBpca
U95J907ZVm8qSU/PQfx1IrDzKdRSQPO9Gs1I8MqXi0D
-----END CERTIFICATE-----

To Create a Self-Signed SSL Certificate Non-interactively Using Create Commands
Note:

If you want the keyring to part of an overlay or profile, the keyring must be configured as
showable.

At the (config) command prompt, use the following syntax to create a self-signed certificate
SGOS#(config ssl) create certificate keyring-id [attribute_value]
[attribute_value]

where any or all of the following attribute and value pairs are accepted:
Mandatory:
• cn common_name
• challenge at_least_four_characters
Optional:
• c 2_character_country_code
• o organization_name
• ou organizational_unit
• email e-mail_id
• state state or province
• city locality or city
• company company_name

Notes:


If you do not specify any attributes, the interactive mode is assumed, meaning that the self-signed
certificate cannot be created by Director in profiles or overlays.



The name of the attribute is predefined and the value of the attribute is a string. The value can be
quoted if it contains white space or other special characters.



You must specify the name and value together; the order of appearance of multiple name value
pairs does not matter. If you omit an attribute, an empty string is assumed for the value of the
attribute.

Example:
SGOS#(config ssl) create certificate keyring-id cn bluecoat challenge test
c US state CA company bluecoat

247

Blue Coat ProxySG Configuration and Management Guide

Section B: Configuring HTTPS Termination

Importing a Server Certificate
A server certificate is sent to you by a Certificate Signing Authority after receiving the Certificate
Signing Request. The certificate request is created either off box or with the signing request you
created through the SSL >Keyrings>SSL Certificates. To create an SSL signing request, follow the
instructions in "Creating a CSR" on page 240. After the server certificate is signed by a Certificate
Signing Authority and returned, it can be imported by completing the steps below.
Importing a Server Certificate
1.

Copy the certificate to your clipboard. Be sure to include the “Begin Certificate” and “End
Certificate” statements.

2.

Go to Configuration>SSL>Keyrings>SSL Certificates.
The SSL Certificates pane displays.

Figure 7-6: SSL Certificates Pane

3.

Select the keyring that this certificate will be associated with.

4.

In the certificate panel, click Import.
The Import Certificate dialog displays.

248

Chapter 7: Using Secure Services

Section B: Configuring HTTPS Termination

Figure 7-7: SSL Import Certificate Dialog

5.

Paste the certificate you copied into the dialog. Click OK.
The certificate should display in the SSL Certificates Pane, associated with the keyring you
selected earlier.

Troubleshooting Certificate Problems


If the client does not trust the Certificate Signing Authority that has signed the ProxySG
Appliance’s certificate, an error message similar to the following appears in the event log:
2004-02-13 07:29:28-05:00EST "CFSSL:SSL_accept error:14094416:SSL
routines:SSL3_READ_BYTES:sslv3 alert certificate unknown" 0 310000:1
../cf_ssl.cpp:1398

This commonly occurs when you use the HTTPS-Console service on port 8082, which uses a
self-signed certificate by default. When you access the Management Console over HTTPS, the
browser displays a pop-up that says that the security certificate is not trusted and asks if you want
to proceed. If you select No instead of proceeding, the browser sends an unknown CA alert to the
ProxySG.
You can eliminate the error message one of two ways:





If this was caused by the Blue Coat self-signed certificate (the certificate associated with the
default keyring), import the certificate as from a trusted Certificate Signing Authority in
Internet Explorer.



Import a certificate on the ProxySG that is signed by a well-known Certificate Signing
Authority and use that for HTTPS Console access and HTTPS termination.

If the ProxySG’s certificate is not accepted because of a host name mismatch or it is an invalid
certificate, you can correct the problem by creating a new certificate and editing the
HTTPS-Console service to use it. For information on editing the HTTPS-Console service, see
"Managing the HTTPS Console (Secure Console)" on page 144.

249

Blue Coat ProxySG Configuration and Management Guide

Section C: Managing the SSL Client

Section C: Managing the SSL Client
The SSL client:


Determines which certificates can be presented to origin servers if the secure server requires the
ProxySG to present a certificate.



Identifies the protocol the ProxySG uses in negotiations with origin servers.



Identifies the cipher suites to be used with the certificate.

You can change the protocol and the cipher suites used.
You must associate a keyring with the SSL client if the ProxySG is obtaining content through HTTPS
from an origin content server (OCS) that requires a client certificate to be presented. If the OCS
requires a client certificate and no keyring is associated with the SSL client, the connections fails. For
information on creating a keyring, see "Creating a Keyring" on page 235.

Creating an SSL Client
The ProxySG is configured with a default SSL client.
Note:

Only one SSL client can be created on a ProxySG.

Creation of the SSL client means that for every HTTPS connection to the destination server, the
ProxySG picks the parameters needed for negotiating the SSL connection from the SSL-client
configuration. Thus, multiple SSL connections to different HTTPS destination servers can be
supported with a single SSL-client configuration. This is similar to a browser where one configuration
is used to negotiate multiple connections with different hosts.
When the ProxySG is acting as an SSL client (SSL origination), SSL sessions are re-used until the server
forces a fresh handshake or until the same session ID has been used 255 times.
If you just need to change the protocol, the cipher suites, or the keyring associated with the SSL client,
you do not need to recreate the client. Continue with "Associating a Keyring and Protocol with the
SSL Client" on page 251 or "Changing the Cipher Suites of the SSL Client" on page 252.
To Create the SSL Client through the CLI
SGOS#(config ssl) create ssl-client default
defaulting protocol to SSLv2v3TLSv1
defaulting associated keyring-id to default
ok

To Delete the SSL Client through the CLI
SGOS#(config ssl) delete ssl-client default
ok

250

Chapter 7: Using Secure Services

Section C: Managing the SSL Client

Associating a Keyring and Protocol with the SSL Client
The SSL client, called default, already exists on the ProxySG. Keyrings that are not used to
authenticate encrypted connections do not need to be associated with the SSL client.
Important: Only one keyring can be associated with the SSL client at a time.
To Associate a Keyring with the SSL Client and Change the Protocol Version through the Management
Console
1.

Select Configuration>SSL>SSL Client.

Figure 7-8: SSL Client

2.

To use the SSL client, verify Use SSL Client is selected.

3.

Only keyrings with certificates can be associated with the SSL client, displayed in the Keyring
drop-down list. Select the keyring used to negotiate with origin content servers through an
encrypted connection.

4.

You can change the SSL Versions default from SSLv2v3TLSv1 to any other protocol listed in the
drop-down list.

5.

Click Apply.

To Associate a Keyring and Protocol with the SSL Client through the CLI
1.

To associate a keyring with the SSL client, enter the following commands at the (config)
command prompt:
SGOS#(config) ssl
SGOS#(config ssl) edit ssl-client default
SGOS#(config ssl ssl-client default) keyring-id keyring_id
SGOS#(config ssl ssl-client default) protocol {sslv2 | sslv3 | tlsv1 |
sslv2v3 | sslv2tlsv1 | sslv3tlsv1 | sslv2v3tlsv1}

251

Blue Coat ProxySG Configuration and Management Guide

Section C: Managing the SSL Client

Note:

To configure the ProxySG to accept only SSL version 3 traffic, for example, use the
sslv3 parameter. To configure the ProxySG to accept SSL version 2 and version 3
traffic, use the sslv2v3 parameter.

2.

View the results. The results also show the current value of the cipher suites, which is discussed in
"Changing the Cipher Suites of the SSL Client" on page 252.
SGOS#(config ssl ssl-client default) view
SSL-Client Name

Keyring Name

Protocol

default

default

SSLv2v3TLSv1

Changing the Cipher Suites of the SSL Client
The cipher suite sets the encryption method used by the ProxySG. As the encryption key strength is
determined by the signed certificate, configuring a higher cipher suite than defined by the certificate
has no affect. Conversely, the cipher suite configuration must be high enough to accommodate
certification encryption values.
This can only be done through the CLI.
To Change the Cipher Suite of the SSL Client through the CLI
The default is to use all ciphers.
You have a choice of using the interactive or non-interactive create command.
Note:

Director uses non-interactive commands in profiles and overlays to create cipher suites.
For more information on Director, refer to the Blue Coat Director Configuration and
Management Guide.)

To change the cipher suites used through the:


interactive command: continue with the next procedure.



non-interactive command: skip to "To Change the Cipher Suites Non-interactively" on page 254.

To Change the Cipher Suites using the Interactive Cipher-Suites Command:
Note that the Use column in the set cipher-suite output below indicates that the default is to use
all ciphers.
1.

Choose the cipher suites you want to use at the prompt.
SGOS#(config) ssl
SGOS#(config ssl) edit ssl-client default
SGOS#(config ssl ssl-client default) cipher-suite

252

Chapter 7: Using Secure Services

Section C: Managing the SSL Client
SSL-Client Name
-------------default
Cipher#
------1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Use
--yes
no
no
no
no
no
no
no
no
no
no
no
no
no
no

Keyring Name
-----------default

Protocol
-----------SSLv2v3TLSv1

Description
-------------------RC4-MD5
RC4-SHA
DES-CBC3-SHA
DES-CBC3-MD5
RC2-CBC-MD5
RC4-64-MD5
DES-CBC-SHA
DES-CBC-MD5
EXP1024-RC4-MD5
EXP1024-RC4-SHA
EXP1024-RC2-CBC-MD5
EXP1024-DES-CBC-SHA
EXP-RC4-MD5
EXP-RC2-CBC-MD5
EXP-DES-CBC-SHA

Strength
-------Medium
Medium
High
High
Medium
Low
Low
Low
Export
Export
Export
Export
Export
Export
Export

Select cipher numbers to use, separated by commas: 1,3,4
ok

2.

(Optional) View the results. Notice the change in the Use column.
SGOS#(config ssl ssl-client default) view
SSL-Client Name
--------------default
Cipher#
------1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Use
--yes
no
yes
yes
no
no
no
no
no
no
no
no
no
no
no

Keyring Name
-----------default
Description
-------------------RC4-MD5
RC4-SHA
DES-CBC3-SHA
DES-CBC3-MD5
RC2-CBC-MD5
RC4-64-MD5
DES-CBC-SHA
DES-CBC-MD5
EXP1024-RC4-MD5
EXP1024-RC4-SHA
EXP1024-RC2-CBC-MD5
EXP1024-DES-CBC-SHA
EXP-RC4-MD5
EXP-RC2-CBC-MD5
EXP-DES-CBC-SHA

Protocol
-----------SSLv2v3TLSv1
Strength
-------Medium
Medium
High
High
Medium
Low
Low
Low
Export
Export
Export
Export
Export
Export
Export

253

Blue Coat ProxySG Configuration and Management Guide

Section C: Managing the SSL Client
To Change the Cipher Suites Non-interactively
Enter the following commands:
SGOS#(config) ssl
SGOS#(config ssl) edit ssl-client default
SGOS#(config ssl ssl-client default) cipher-suite cipher-suite cipher-suite

where [cipher-suite] can be any combination of the following:
1. rc4-md5
2. rc4-sha
3. des-cbc3-sha
4. des-cbc3-md5
5. rc2-cbc-md5
6. rc4-64-md5
7. des-cbc-sha
8. des-cbc-md5
9. exp1024-rc4-md5
10.exp1024-rc4-sha
11.exp1024-rc2-cbc-md5
12.exp1024-des-cbc-sha
13.exp-rc4-md5
14.exp-rc2-cbc-md5
15.exp-des-cbc-sha

Notes:


If you do not specify any attributes, the interactive mode is assumed, meaning that the cipher
suites cannot be used by Director in profiles or overlays.



Multiple cipher suites can be specified on the command line.

Example
SGOS#(config ssl ssl-client default) cipher-suite rc4-md5 des-cbc3-md5
exp1024-rc4-md5 exp-des-cbc-sha
ok
SGOS#(config ssl ssl-client default) view
SSL-Client Name
Keyring Name
Protocol
-----------------------------------default
default
SSLv2v3TLSv1
Cipher#
------1
2
3
4
5
6
7
8
9
10

254

Use
--no
no
no
no
no
no
no
no
no
no

Description
-------------------RC4-MD5
RC4-SHA
DES-CBC3-SHA
DES-CBC3-MD5
RC2-CBC-MD5
RC4-64-MD5
DES-CBC-SHA
DES-CBC-MD5
EXP1024-RC4-MD5
EXP1024-RC4-SHA

Strength
-------Medium
Medium
High
High
Medium
Low
Low
Low
Export
Export

Chapter 7: Using Secure Services

Section C: Managing the SSL Client
11
12
13
14
15

no
no
no
no
yes

EXP1024-RC2-CBC-MD5
EXP1024-DES-CBC-SHA
EXP-RC4-MD5
EXP-RC2-CBC-MD5
EXP-DES-CBC-SHA

Export
Export
Export
Export
Export

Troubleshooting Server Certificate Verification
Server certificate verification can be disabled for all upstream hosts or specific upstream hosts. The
ProxySG, by default, verifies the SSL certificate presented by the upstream HTTPS server. However, it
fails to negotiate the SSL connection if SSL certificate verification fails.
The two most common causes of server certificate verification failure are:


The absence of a suitable CA certificate on the ProxySG. Ensure that the ProxySG is configured
with the relevant CA certificates to avoid unwanted verification failures. The default behavior can
be changed by using the http ssl-verify-server option.
If a forwarding host of type HTTPS server is being used, you can override the default behavior by
changing the ssl-verify-server option on a per-host basis.



The server is using a self-signed certificate. In this case, you need to change the keyring to one that
has a CA certificate.

Setting the SSL Negotiation Timeout
The SSL negotiation timeout value dictates the time a ProxySG waits for a new SSL handshake to
complete. This value applies to both HTTPS termination and SSL origination.
You can change the default SSL negotiation timeout value if the default, 300 seconds, is not sufficient
for your environment. This value can only be changed through the CLI; it cannot be set from the
Management Console.
To change the HTTPS termination timeout period, enter the follow commands from the command
prompt:
SGOS#(config) ssl
SGOS#(config ssl) view ssl-nego-timeout
300
SGOS#(config ssl) ssl-nego-timeout seconds

255

Chapter 7: Using Secure Services

Section E: Advanced Configuration

Section E: Advanced Configuration
This section includes the following topics:


"Importing an Existing Keypair and Certificate"



"About Certificate Chains"



"Importing a CA Certificate"



"Creating CA Certificate Lists"

Importing an Existing Keypair and Certificate
If you have a keypair and certificate from another system, you can import it for use on a different
system. You can also import a certificate chain containing multiple certificates in a single operation.
Use the inline certificate command to import multiple certificates through the CLI.
If you are importing a keyring and one or more certificates onto a ProxySG, first import the keyring,
followed by the related certificates. The certificates contain the public key from the keyring, and the
keyring and certificates are related.
To Import a Keyring through the Management Console
1.

Copy the already-created keypair onto the clipboard.

2.

Select Configuration>SSL>Keyrings>SSL Keyrings.

3.

Click Create.
The Create Keyring dialog appears.

Figure 7-10: Import a Keyring

4.

Fill in the dialog window as follows:

259

Blue Coat ProxySG Configuration and Management Guide

Section E: Advanced Configuration


Keyring Name: Give the keyring a meaningful name to you.



Select the show option:


show: Keyrings created with this attribute can be included as part of a profile or overlay
pushed by Director.



show-director: Keyrings created with this attribute can be included as part of a profile

or overlay pushed by Director.




no-show: Keyrings created with this attribute cannot be part of a profile. The no-show
option is provided as additional security for environments where the keys will never be
used outside of the particular ProxySG.

Select the keyring length in the Create a new ______ -bit keyring field. A length of 1024 bits is the
maximum (and default). Longer keypairs provide better security, but with a slight
performance expense on the ProxySG. Be aware that the maximum key length allowed for
international export might be different than the default. For deployments reaching outside of
the US, determine the maximum key length allowed for export.
Click OK. The keyring, containing a keypair, is created with the name you chose. It does not
yet have an associated certificate associated. To associate a certificate, see "Deleting an
Existing Keyring and Certificate" on page 239.
-or-



Select the Import keyring radio button.
The grayed-out Keyring field becomes enabled, allowing you to paste in the already existing
keypair. The certificate associated with this keypair must be imported separately.
If the keypair that is being imported has been encrypted with a password, select Keyring
Password and enter the password into the field.

5.

Click OK.

To Import a Certificate and Associate it with a Keyring through the Management Console
1.

Copy the certificate onto the clipboard.

2.

Select Configuration>SSL>Keyrings>SSL Certificates and select the keyring that you just imported
from the Keyring drop-down list.

3.

Click Import in the Certificate field.

4.

Paste the certificate into the Import Certificate dialog that appears. Be sure to include the
----BEGIN CERTIFICATE---- and -----END CERTIFICATE---- statements.

5.

Click OK.

To Import a Keyring through the CLI Using Inline Commands

260

1.

Copy the keyring to the clipboard.

2.

At the (config) command prompt, enter the following commands:

Chapter 7: Using Secure Services

Section E: Advanced Configuration
SGOS#(config) ssl
SGOS#(config ssl) inline {keyring show | show-director | no-show} keyring_id
eof
Paste keypair here
eof

where:


Show allows the keys, and everything in the keys, to be exported.



no-show prevents the keypair from being exported.



show-director is a keyring viewable only if Director is issuing the command using a

SSH-RSA connection.
Note:



The choice of show/show-director/no-show has implications for whether keyrings
are included in profiles and backups created by Director. For more information, refer
to the Blue Coat Director User Guide.

eof: End-of-file marker. This can be anything, as long as it does not also appear in the
inline text. (If it appears in the inline text, the inline command completes at that point.)

To Import a Certificate and Associate it with a Keyring through the CLI
Note:

The keyring you want to associate with the certificate must already be on this ProxySG.
The key and certificate must be imported onto the ProxySG in PEM (base64 encoded text)
format.

1.

Copy the certificate or certificate chain to the clipboard. Be sure to include the ----BEGIN
CERTIFICATE---- and -----END CERTIFICATE---- statements.

2.

At the (config) command prompt, enter the following commands:
SGOS#(config) ssl
SGOS#(config ssl) inline certificate keyring_id eof
Paste certificate here
eof

About Certificate Chains
A certificate chain is one that requires that the certificates form a chain where the next certificate in the
chain validates the previous certificate, going up the chain to the root, which is signed by a
well-known root certificate provider. However, expiration is done at the single certificate level and is
checked independently of the chain verification. Each certificate in the chain must not have expired
for the entire chain to be valid. You can import a certificate chain containing multiple certificates in a
single operation.
The valid certificate chain can be presented to a browser. To get the ProxySG to present a valid
certificate chain, the keyring for the HTTPS service must be updated.

261

Blue Coat ProxySG Configuration and Management Guide

Section E: Advanced Configuration
The ProxySG Appliance's CA-certificate list must also be updated if the ProxySG uses HTTPS to
communicate with the origin server and if the ProxySG is configured, through the
ssl-verify-server option, to verify the certificate (chain) presented by HTTPS server. If the
ProxySG uses HTTP to communicate with the origin server, updating the CA-certificate list has no
effect.

Importing a CA Certificate
A CA Certificate is a certificate that verifies the identity of a Certificate Authority. The certificate is
used by the ProxySG to verify server certificates and client certificates.
To Import an Approved CA Certificate through the Management Console
1.

Copy the certificate to the clipboard.

2.

Select Configuration>SSL>CA Certificates>CA Certificates.
The CA Certificates tab displays, with its list of existing CA certificates.

Figure 7-11: CA Certificates

3.

Click Import.
The Import CA Certificate dialog displays.

262

Chapter 7: Using Secure Services

Section E: Advanced Configuration

Figure 7-12: Import CA Certificate Dialog

4.

Paste the signed CA Certificate into the Import CA Certificate field.

5.

Click OK.

6.

When the certificate displays in the Certificate tab, click Apply.

To View a CA Certificate through the Management Console
1.

Select Configuration>SSL>CA Certificates>CA Certificates.

2.

Select the certificate you want to view.

3.

Click View.
The certificate displays.

Figure 7-13: View CA Certificate

4.

Examine the contents and click Close.

To Delete a CA Certificate through the Management Console
1.

Select Configuration>SSL>CA Certificates>CA Certificates.

2.

Select the certificate to delete.

3.

Click Delete.

263

Blue Coat ProxySG Configuration and Management Guide

Section E: Advanced Configuration
4.

Click OK.

5.

Click Apply.

To Import a CA Certificate through the CLI Using Inline Commands
1.

Copy the certificate to the clipboard.

2.

At the (config) command prompt, enter the following commands:
SGOS#(config) ssl
SGOS#(config ssl) inline ca-certificate ca_certificate_name eof
Paste certificate here
eof

3.

(Optional) You can view the certificate you just imported, a summary of the just-imported
certificate, or a summary of all CA Certificates.
a.

To view the certificate you just imported:
SGOS#(config ssl) view ca-certificate ca_certificate_name
-----BEGIN CERTIFICATE----MIIEJzCCA5CgAwIBAgIEN35hxjANBgkqhkiG9w0BAQQFADCBgzELMAkGA1UEBhMC
VVMxLTArBgNVBAoTJEZpcnN0IERhdGEgRGlnaXRhbCBDZXJ0aWZpY2F0ZXMgSW5j
LjFFMEMGA1UEAxM8Rmlyc3QgRGF0YSBEaWdpdGFsIENlcnRpZmljYXRlcyBJbmMu
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDcwMzE4NDczNFoXDTE5MDcw
MzE5MTczNFowgYMxCzAJBgNVBAYTAlVTMS0wKwYDVQQKEyRGaXJzdCBEYXRhIERp
Z2l0YWwgQ2VydGlmaWNhdGVzIEluYy4xRTBDBgNVBAMTPEZpcnN0IERhdGEgRGln
aXRhbCBDZXJ0aWZpY2F0ZXMgSW5jLiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCB
nTANBgkqhkiG9w0BAQEFAAOBiwAwgYcCgYEA3xwUHgm5v6RAciCZebaEIvTXhZLF
BCToBy4C5BeVBTeVdj38seUPhw5iuSwwlybhCxVnAKYV3uiNy5XsAlhSwEdlM0xW
nwofBMA3UIFXut/68mtn68vQgA/ZV5UQZXsGRVjrrrRe45MVK5m8tikv+0KfRysu
TOs0KDKZDu//b6ECAQOjggGmMIIBojARBglghkgBhvhCAQEEBAMCAAcwgawGA1Ud
HwSBpDCBoTCBnqCBm6CBmKSBlTCBkjELMAkGA1UEBhMCVVMxLTArBgNVBAoTJEZp
cnN0IERhdGEgRGlnaXRhbCBDZXJ0aWZpY2F0ZXMgSW5jLjFFMEMGA1UEAxM8Rmly
c3QgRGF0YSBEaWdpdGFsIENlcnRpZmljYXRlcyBJbmMuIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MQ0wCwYDVQQDEwRDUkwxMCsGA1UdEAQkMCKADzE5OTkwNzAzMTg0
NzM0WoEPMjAxOTA3MDMxODQ3MzRaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBSm
uCDJFkuPT1wMw8PumA0+fu5WVTAdBgNVHQ4EFgQUprggyRZLj09cDMPD7pgNPn7u
VlUwDAYDVR0TBAUwAwEB/zA7BgNVHSUENDAyBggrBgEFBQcDAQYIKwYBBQUHAwIG
CCsGAQUFBwMDBggrBgEFBQcDBAYIKwYBBQUHAwgwGQYJKoZIhvZ9B0EABAwwChsE
VjQuMAMCBJAwDQYJKoZIhvcNAQEEBQADgYEAEObEaCOpbLeXSbFzNp3+v3KiDhLC
KlEGH2mTlDARNYVOqHkG43FVPBxWYx5Ee2qBwjB1bN7z8gzDTsp/ycbAX1/vxAZi
qk/6EN4yzOAu/2rixcdFKXU5+YxZC8ZrmQSYWsy6v7F4ApGqtoeAO1cUWzz8zAPK
hqGZqDpta2V+Ubg=
-----END CERTIFICATE-----

b.

To view a summary of the certificate you just imported.
SGOS#(config ssl) view summary ca-certificate ca_certificate_name
CA Certificate ID: ca_certificate_name
Is certificate valid? yes
CA: First Data Digital Certificates Inc.
Expiration Date: Jul 03 19:17:34 2019 GMT
Fingerprint: 70:B5:7C:48:81:95:3E:80:DC:28:9B:BA:EF:1E:E4:85

264

Chapter 7: Using Secure Services

Section E: Advanced Configuration
c.

To view summaries of all CA Certificates on the ProxySG:
SGOS#(config ssl) view summary ca-certificate

A long list of certificates are displayed, each with the summary information displayed
above.

Creating CA Certificate Lists
A CA certificate list can refer to any subset of the available CA Certificates on the ProxySG. When
configuring an HTTPS service to do HTTPS termination, this list can be specified to restrict the set of
certificate authorities that are trusted to validate client certificates presented to that service.
The default is that no list is configured; all certificates are used in authentication.
To Create a CA-Certificate List through the Management Console
1.

Select Configuration>SSL>CA Certificates>CA Certificate Lists.

Figure 7-14: SSL CA-Certificates Lists Dialog

The current CA-Certificate lists display in the pane.
2.

Click New to create a new list.
The Create CA Certificate List dialog displays.

265

Blue Coat ProxySG Configuration and Management Guide

Section E: Advanced Configuration

Figure 7-15: Create CA Certificate List Dialog

3.

Enter a name meaningful to you for the list in the CA-Certificate List Name field.

4.

To add CA Certificates to the list, highlight the certificate and click Add. You cannot add a
certificate to a certificate list if it is not already present.

5.

To remove CA Certificates from the list, highlight the certificate in the Add list and click Remove.

6.

Click OK; click Apply.

To Create CA-Certificate Lists through the CLI
1.

At the (config) command prompt, view the CA certificates already existing on the system. You
cannot add a certificate to a certificate list if it is not already present.
SGOS#(config) ssl
SGOS#(config ssl) view summary ca-certificate

All the CA Certificates on the system display.
2.

Enter the followings commands to create a list and add existing certificates to the list you just
generated.
SGOS#(config ssl) create ccl list_name
SGOS#(config ssl) edit ccl list_name

The prompt changes, putting you in ccl submode.
SGOS#(config ssl ccl list_name) add ca_cert_name

3.

Repeat the above command until you have entered all the needed certificates. You can have more
than one CA-Certificate list. Each list can have an unlimited number of certificates.

4.

(Optional) View the list.
SGOS#(config ssl ccl list_name) view
CA Certificate ID: VRSN_Secure_Server_CA
Is certificate valid? yes
CA: RSA Data Security, Inc.
Expiration Date: Jan 07 23:59:59 2010 GMT
Fingerprint: 74:7B:82:03:43:F0:00:9E:6B:B3:EC:47:BF:85:A5:93
CA Certificate ID: DeutscheTelekom

266

Chapter 7: Using Secure Services

Section E: Advanced Configuration
Is certificate valid? yes
CA: Deutsche Telekom AG
Expiration Date: Jul 09 23:59:00 2019 GMT
Fingerprint: 9B:34:0D:1A:31:5B:97:46:26:98:BC:A6:13:6A:71:96
CA Certificate ID: CWHKT_SecureNetA
Is certificate valid? yes
CA: C&W HKT SecureNet CA Class A
Expiration Date: Oct 15 23:59:00 2009
Fingerprint: E2:D5:20:23:EC:EE:B8:72:E1:2B:5D:29:6F:FA:43:DA

To Delete a CA Certificate through the CLI
At the (config) command prompt, enter the following commands:
SGOS#(config) ssl
SGOS#(config ssl) delete ca-certificate ca_certificate_name

267

Blue Coat ProxySG Configuration and Management Guide

Section E: Advanced Configuration

268

Chapter 8: Security and Authentication

Enterprise-wide security begins with security on the ProxySG itself, and continues with controlling
user access to the Intranet and Internet.
Table 8.1 defines some common security and authentication terms.
Table 8.1: Security and Authentication Terms
Term

Definition

proxy

Caches content, filters traffic, monitors Internet and intranet resource usage,
blocks specific Internet and intranet resources for individuals or groups, and
enhances the quality of Internet or intranet user experiences.
A proxy can also serve as an intermediary between a Web client and a Web server
and can require authentication to allow identity based policy and logging for the
client.
The rules used to authenticate a client are based on the policies you create on the
ProxySG, which can reference an existing security infrastructure—LDAP,
RADIUS, NTLM, and the like, discussed in more detail in Chapter 9: “Using
Authentication Services” on page 299.

explicit proxy

A configuration in which the browser is explicitly configured to communicate
with the proxy server for access to content.
This is the default for the ProxySG, and requires configuration for both browser
and the interface card.

transparent proxy

A configuration in which traffic is redirected to the ProxySG without the
knowledge of the client browser. No configuration is required on the browser, but
network configuration, such as an L4 switch or a WCCP-compliant router, is
required.

forward proxy

A proxy server deployed close to the clients and used to access many servers. A
forward proxy can be explicit or transparent.

reverse proxy

A proxy that acts as a front-end to a small number of pre-defined servers,
typically to improve performance. Many clients can use it to access the small
number of predefined servers.

SSL

A standard protocol for secure communication over the network. Blue Coat
recommends using this protocol to protect sensitive information.

authentication

The process of identifying a specific user.

authorization

The permissions given to a specific user.

269

Blue Coat ProxySG Configuration and Management Guide

Table 8.1: Security and Authentication Terms (Continued)
Term

Definition

realms

A realm is a named collection of information about users and groups. The name is
referenced in policy to control authentication and authorization of users for access
to Blue Coat Systems ProxySG services. Multiple authentication realms can be
used on a single ProxySG. Realm services include NTLM, LDAP, Local, and
RADIUS. For detailed information on realms, see Chapter 9: “Using
Authentication Services” on page 299.

serial console

A device that allows you to connect to the ProxySG when it is otherwise
unreachable, without using the network. It can be used to administer the ProxySG
through the CLI. You must use the CLI to use a serial console.
Anyone with access to the serial console can change the administrative access
controls, so physical security of the serial console is critical.

SSH and HTTPS are the recommended (and default) methods for managing access to the ProxySG.
SSL is the recommended protocol for communication between the ProxySG and a realm's off-box
authentication server.
This chapter contains the following sections:

270



"Controlling Access to the ProxySG"



"Controlling Access to the Internet and Intranet"

Chapter 8: Security and Authentication

Section A: Controlling Access to the ProxySG

Section A: Controlling Access to the ProxySG
You can control access to the ProxySG several ways: by limiting physical access to the system, by
using passwords, restricting the use of console account, through per-user RSA public key
authentication, and through Blue Coat Content Policy Language (CPL). How secure the system needs
to be depends upon the environment.
This section contains:


"Limiting Access to the ProxySG Appliance"



"About Password Security"



"Limiting User Access to the ProxySG—Overview"



"Moderate Security: Restricting Management Console Access Through the Console Access
Control List (ACL)"



"Maximum Security: Administrative Authentication and Authorization Policy"

Limiting Access to the ProxySG Appliance
You can limit access to the ProxySG appliance by:


Restricting physical access to the system and by requiring a PIN to access the front panel.



Restricting the IP addresses that are permitted to connect to the ProxySG CLI.



Requiring a password to secure the Setup Console.

These methods are in addition to the restrictions placed on the console account (a console account user
password) and the Enable password. For information on using the console account, see "Changing the
Username and Password through the Management Console" on page 43.
By using every possible method (physically limiting access, limiting workstation IP addresses, and
using passwords), the ProxySG is very secure.
This section discusses:


"Requiring a PIN for the Front Panel"



"Limiting Workstation Access"



"Securing the Serial Port"

Requiring a PIN for the Front Panel
On systems that have a front panel display, you can create a four-digit PIN to protect the system from
unauthorized use. The PIN is hashed and stored. You can only create a PIN from the command line.
To create a front panel PIN, after initial configuration is complete:
From the (config) prompt:
SGOS#(config) security front-panel-pin PIN

where PIN is a four-digit number.

271

Blue Coat ProxySG Configuration and Management Guide

Section A: Controlling Access to the ProxySG
To clear the front-panel PIN, enter
SGOS#(config) security front-panel-pin 0000

Limiting Workstation Access
During initial configuration, you have the option of preventing workstations with unauthorized IP
addresses from accessing the CLI. If this option is not enabled, all workstations are allowed to access
the CLI. You can also add allowed workstations later to the access control list (ACL). (For more
information on limiting workstation access, see "Moderate Security: Restricting Management Console
Access Through the Console Access Control List (ACL)" on page 275.)

Securing the Serial Port
If you choose to secure the serial sort, you must provide a Setup Console password that is required to
access the Setup Console in the future.
Once the secure serial port is enabled:


The Setup Console password is required to access the Setup Console.



An authentication challenge (username and password) is issued to access the CLI through the
serial port.

To recover from a lost Setup Console password, you can:


Use the Front Panel display to either disable the secure serial port or enter a new Setup Console
password.



Use the CLI restore-defaults factory-defaults command to delete all system settings. For
information on using the restore-defaults factory-defaults command, see
"Factory-Defaults" on page 831.



Use the reset button (if the appliance has a reset button) to delete all system settings.

To enable the secure serial port, refer to the Installation Guide for your platform.

About Password Security
In the ProxySG, the console administrator password, the Setup Console password, and Enable
(privileged-mode) password are hashed and stored. It is not possible to reverse the hash to recover the
plaintext passwords.
In addition, the show config and show security CLI commands display these passwords in their
hashed form. The length of the hashed password depends on the hash algorithm used so it is not a
fixed length across the board.
Passwords that the ProxySG uses to authenticate itself to outside services are encrypted using
triple-DES on the appliance, and using RSA public key encryption for output with the show config
CLI command. You can use a third-party encryption application to create encrypted passwords and
copy them into the ProxySG using an encrypted-password command (which is available in several
modes and described in those modes). If you use a third-party encryption application, verify it
supports RSA encryption, OAEP padding, and Base64 encoded with no new lines.

272

Chapter 8: Security and Authentication

Section A: Controlling Access to the ProxySG
These passwords, set up during configuration of the external service, include:


Access log FTP client passwords (primary, alternate)—For configuration information, see "Editing
the FTP Client" on page 806



Archive configuration FTP password—For configuration information, see "Archive
Configuration" on page 76



RADIUS primary and alternate secret—For configuration information, see "Defining RADIUS
Realm Properties" on page 327



LDAP search password—For configuration information, see "LDAP Search & Groups Tab
(Authorization and Group Information)" on page 318



Content filter download passwords—For configuration information, see Chapter 18: “Content
Filtering” on page 679

Limiting User Access to the ProxySG—Overview
When deciding how to give other users read-only or read-write access to the ProxySG, sharing the
basic console account settings is only one option. The following summarizes all available options:
Note:

If Telnet Console access is configured, Telnet can be used to manage the ProxySG with
behavior similar to SSH with password authentication.
SSL configuration is not allowed through Telnet, but is permissible through SSH.
Behavior in the following sections that applies to SSH with password authentication also
applies to Telnet. Use of Telnet is not recommended because it is not a secure protocol.



Console account—minimum security
The console account username and password are evaluated when the ProxySG is accessed from
the Management Console through a browser and from the CLI through SSH with password
authentication. The Enable (privileged-mode) password is evaluated when the console account is
used through SSH with password authentication and when the CLI is accessed through the serial
console and through SSH with RSA authentication. The simplest way to give access to others is
sharing this basic console account information, but it is the least secure and is not recommended.
To give read-only access to the CLI, do not give out the Enable (privileged-mode) password.



Console access control list—moderate security
Using the access control list (ACL) allows you to further restrict use of the console account and
SSH with RSA authentication to workstations identified by their IP address and subnet mask.
When the ACL is enforced, the console account can only be used by workstations defined in the
console ACL. Also, SSH with RSA authentication connections are only valid from workstations
specified in the console ACL (provided it is enabled).

273

Blue Coat ProxySG Configuration and Management Guide

Section A: Controlling Access to the ProxySG
After setting the console account username, password, and Enable (privileged-mode) password,
use the CLI or the Management Console to create a console ACL. See "Moderate Security:
Restricting Management Console Access Through the Console Access Control List (ACL)" on
page 275.


Per-user RSA public key authentication—moderate security
Each administrator’s public keys are stored on the appliance. When connecting through SSH, the
administrator logs in with no password exchange. Authentication occurs by verifying knowledge
of the corresponding private key. This is secure because the passwords never go over the network.
This is a less flexible option than CPL because you cannot control level of access with policy, but it
is a better choice than sharing the console credentials.



Blue Coat Content Policy Language (CPL)—maximum security
CPL allows you to control administrative access to the ProxySG through policy. If the credentials
supplied are not the console account username and password, policy is evaluated when the
ProxySG is accessed through SSH with password authentication or the Management Console.
Policy is never evaluated on direct serial console connections or SSH connections using RSA
authentication.


Using the CLI or the Management Console GUI, create an authentication realm to be used for
authorizing administrative access. For administrative access, the realm must support BASIC
credentials—for example, LDAP, RADIUS, Local, or NTLM with BASIC credentials enabled.
For more information on realms, see Chapter 9: “Using Authentication Services” on page 299.



Using the Visual Policy Manager, or by adding CPL rules to the Local or Central policy file,
specify policy rules that: (1) require administrators to log in using credentials from the
previously-created administrative realm, and (2) specify the conditions under which
administrators are either denied all access, given read-only access, or given read-write access.
Authorization can be based on IP address, group membership, time of day, and many other
conditions. For more information, see "Defining Policies Using the Visual Policy Manager" on
page 278.



To prevent anyone from using the console credentials to manage the ProxySG, set the console
ACL to deny all access (unless you plan to use SSH with RSA authentication). For more
information, see "Moderate Security: Restricting Management Console Access Through the
Console Access Control List (ACL)" on page 275. You can also restrict access to a single IP
address that can be used as the emergency recovery workstation.

The following chart details the various ways administrators can access the ProxySG console and the
authentication and authorization methods that apply to each.
Table 8.2: ProxySG Console Access Methods/Available Security Measures
Security Measures Available

Username and password evaluated
(console-level credentials)

274

Serial Console

SSH with
Password
Authentication

3

SSH with RSA
Authentication

Management
Console

3

Chapter 8: Security and Authentication

Section A: Controlling Access to the ProxySG
Table 8.2: ProxySG Console Access Methods/Available Security Measures (Continued)

3

Console Access List evaluated

CPL Layer evaluated

3

3(if console

(if console
credentials are
offered)

credentials are
offered)

3(see Note 1
below)

3(see Note 2
below)

Enable password required to enter
privileged mode (see Note 2 below)

3

3

3

CLI line-vty timeout command
applies.

3

3

3

Management Console Login/Logout

3

Note 1: When using SSH (with a password) and credentials other than the console account, the enable
password is actually the same as the login password. The privileged mode password set during
configuration is used only in the serial console, SSH with RSA authentication, or when logging in with
the console account.
Note 2: In this case, user credentials are evaluated against the policy before executing each CLI
command. If you log in using the console account, user credentials are not evaluated against the
policy.

Moderate Security: Restricting Management Console Access Through
the Console Access Control List (ACL)
The ProxySG allows you to limit access to the Management Console and CLI through the console
ACL. An ACL, once set up, is enforced only when console credentials are used to access either the CLI
or the Management Console, or when an SSH with RSA authentication connection is attempted. The
following procedure specifies an ACL that lists the IP addresses permitted access.
To Create an ACL through the Management Console
1.

Select Configuration>Authentication>Console Access>Console Access.

275

Blue Coat ProxySG Configuration and Management Guide

Section A: Controlling Access to the ProxySG

Figure 8-1: Console Access Tab

2.

(Optional) To add a new address to the ACL, click New.
The Add List Item dialog is displayed.

Figure 8-2: Add List Item Dialog

a.

In the IP/Subnet fields, enter a static IP address.

b.

In the Mask fields, enter the subnet mask. To restrict access to an individual workstation,
enter 255.255.255.255.

c.

Click OK to add the workstation to the ACL and return to the Console Access page.

d. Repeat step 2 to add other IP addresses.

276

3.

(Optional) To remove a source address from the ACL, select the address to remove from the
Console Access page and click Delete.

4.

(Optional) To change a source IP address, select the IP address to revise and click Edit. See step 2,
above, for details.

5.

To impose the ACL defined in the list box, select Enforce ACL for built-in administration. To allow
access to the CLI or Management Console using console account credentials from any
workstation, deselect the checkbox. The ACL is ignored.

Chapter 8: Security and Authentication

Section A: Controlling Access to the ProxySG

Important:

6.

Before you enforce the ACL, verify the IP address for the workstation you are using
is included in the list. If you forget, or you find that you mistyped the IP address,
you must correct the problem using the serial console.

Click Apply.

To Create an ACL through the CLI
1.

At the (config) command prompt, enter the following command to add workstation IP
addresses to the ACL:
SGOS#(config) security allowed-access add ip_address [subnet_mask]

Note:

If you omit the subnet mask, the default subnet mask of 255.255.255.255 is
assumed.

2.

Repeat step 1 for each workstation that you need to add to the console access list.

3.

At the (config) command prompt, enter the following command to enforce the ACL created in
step 1
SGOS#(config) security enforce-acl enable

Only those workstation IP addresses added to the ACL are able to use the Management
console account to administer the ProxySG. Verify that the IP address for the workstation you
are using is included in the list.
4.

To disable the ACL and open through the access to the console account user, enter the following
command:
security enforce-acl disable

5.

To remove an IP address and subnet mask from the ACL, enter the following command:
SGOS#(config) security allowed-access remove ip_address [subnet_mask]

Note:

If you omit the subnet mask, the default subnet mask of 255.255.255.255 is
assumed.

Maximum Security: Administrative Authentication and Authorization
Policy
The ProxySG permits you to define a rule-based administrative access policy. This policy is enforced
when accessing:


the Management Console through http or https



the CLI through SSH when using password authentication



the CLI through telnet

277

Blue Coat ProxySG Configuration and Management Guide

Section A: Controlling Access to the ProxySG


the CLI through the serial port if the secure serial port is enabled

These policy rules can be specified either by using the VPM or by editing the Local policy file. Using
policy rules, you can deny access, allow access without providing credentials, or require
administrators to identify themselves by entering a username and password. If access is allowed, you
can specify whether read-only or read-write access is given. You can make this policy contingent on IP
address, time of day, group membership (if credentials were required), and many other conditions.
Serial-console access is not controlled by policy rules. For maximum security to the serial console,
physical access must be limited.
SSH with RSA authentication also is not controlled by policy rules. You can configure several settings
that control access: the enable password, the console ACL, and per-user keys configured through the
Configuration>Services>SSH>SSH Client page. (If you use the CLI, SSH commands are under
config>services>ssh-console.)

Defining Administrator Authentication and Authorization Policies
The ProxySG uses CPL to define policies, including administrator, authentication, and authorization
policies. CPL also allows you to give administrator privileges to users in any external authentication
service.
The following summarizes the steps required to define Administrator Authentication and
Authorization policies on the ProxySG:


(Optional) If you need to give administrative access to existing users or groups, create and
configure the authentication realm. See Chapter 9: “Using Authentication Services” on page 299
for details on configuring authentication realms.



Define the policies in the appropriate policy file where you keep the Layer layers and
rules.



Load the policy file on the ProxySG.

When you define such policies, make sure you define them in the appropriate policy file(s). For more
information on policy files and how they are used, see Chapter 14: “The Visual Policy Manager” on
page 493.

Defining Policies Using the Visual Policy Manager
To define policies through the Management Console, use the Visual Policy Manager. When you use
the VPM, policies are configured in CPL and saved in the VPM policy file. For examples of
Administrator authentication or authorization policy CPL, continue with the next section. The VPM is
described in detail in Chapter 14: “The Visual Policy Manager” on page 493.

278

Chapter 8: Security and Authentication

Section A: Controlling Access to the ProxySG

Defining Policies Directly in Policy Files
To define policies manually, type CPL rules directly in one of the two policy files, Central or Local.
Important: Do not manually enter CPL rules directly into the VPM file. The file becomes
corrupted.
For specific information on creating policies within the policy files, refer to the Blue Coat ProxySG
Content Policy Language Guide.
Following are the CPL elements that can be used to define administrator policies for the ProxySG.
To Define Administrator Policies by Editing a Policy File:
1.

Open the policy file in a text editor.

2.

Define the policies, using the correct CPL syntax.

3.

Save the file.

4.

Load the policy file (see "Creating and Editing Policy Files" on page 482).

Admin Transactions and Layers
Admin transactions execute layers. Only a restricted set of conditions, properties, and actions
are permitted in layers. Table 8.3 lists the conditions permitted in the layer:
Table 8.3: Layer Conditions
Network Connection Conditions
client_address=ip_address
[.subnetmask]

Tests for a match between ip_address and the IP address of the
client transaction source.

proxy.port=number

Tests for a match between number and the port number for which
the request is destined.

proxy.address=ip_address

Tests for a match between ip_address and the IP address of the
network interface card for which the request is destined.

proxy.card=number

Tests for a match between number and the ordinal number
associated with the network interface card for which the request is
destined.

General Conditions
condition=condition.label

Tests if the specified defined condition is true.

release.id=

Tests the ProxySG release id.

279

Blue Coat ProxySG Configuration and Management Guide

Section A: Controlling Access to the ProxySG
Table 8.3: Layer Conditions (Continued)
Date/Time Conditions

280

date[.utc]=[date | date…date]

Tests for a match between date and the date timestamp associated
with the source of the transaction. date specifies a single date of the
form YYYY-MM-DD or an inclusive range, as in
YYYY-MM-DD…YYYY-MM-DD. By default, date is calculated based on
local time. To calculate year based on the Coordinated Universal
Time, include the .utc qualifier

year[.utc]=[year | year…year]

Tests for a match between year and the year timestamp associated
with the source of the transaction. year specifies a single Gregorian
calendar year of the form YYYY or an inclusive range of years, as in
YYYY…YYYY. By default, year is calculated based on local time. To
calculate year based on the Coordinated Universal Time, include
the .utc qualifier.

month[.utc]=[month |
month…month]

Tests for a match between month and the month timestamp
associated with the source of the transaction. month specifies a
single Gregorian calendar month of the form MM or an inclusive
range of months, as in MM…MM. By default, month is calculated based
on local time. To calculate month based on the Coordinated
Universal Time, include the .utc qualifier.

weekday[.utc]=[number |
number…number]

Tests for a match between weekday and the weekday timestamp
associated with the source of the transaction. weekday specifies a
single day of the week (where Monday=1, Tuesday=2, and
Sunday=7) or an inclusive range of weekdays, as in
number…number. By default, weekday is calculated based on local
time. To calculate weekday based on the Coordinated Universal
Time, include the .utc qualifier.

day[.utc]=[day | day…day]

Tests for a match between day and the day timestamp associated
with the source of the transaction. day specifies a single Gregorian
calendar day of the month of the form DD or an inclusive range of
days, as in DD…DD. By default, day is calculated based on local time.
To calculate day based on the Coordinated Universal Time, include
the .utc qualifier.

hour[.utc]=[hour | hour…hour]

Tests for a match between hour and the hour timestamp associated
with the source of the transaction. hour specifies a single Gregorian
hour of the form HH (00, 01, and so forth, through 23) or an inclusive
range of hours, as in HH…HH. By default, hour is calculated based
on local time. To calculate hour based on the Coordinated Universal
Time, include the .utc qualifier.

minute[.utc]=[minute |
minute…minute]

Tests for a match between minute and the minute timestamp
associated with the source of the transaction. minute specifies a
single Gregorian minute of the form MM (00, 01, and so forth,
through 59) or an inclusive range of minutes, as in MM…MM. By
default, minute is calculated based on local time. To calculate minute
based on the Coordinated Universal Time, include the .utc qualifier.

Chapter 8: Security and Authentication

Section A: Controlling Access to the ProxySG
Table 8.3: Layer Conditions (Continued)
time[.utc]=[time | time…time]

Tests for a match between time and the time timestamp associated
with the source of the transaction. time specifies military time of the
form TTTT (0000 through 2359) or an inclusive range of times, as in
TTTT…TTTT. By default, time is calculated based on local time. To
calculate time based on the Coordinated Universal Time, include
the .utc qualifier.

Authorization Conditions
attribute.name =value

Tests if the current transaction is authorized in a RADIUS or LDAP
realm, and if the authenticated user has the specified attribute with
the specified value. This trigger is unavailable if the current
transaction is not authenticated

authenticated={yes | no}

Tests if authentication was requested and the credentials could be
verified.

group=group_name

If authenticate=yes, the group condition tests the source of the
transaction for membership in the specified group_name.

has_attribute.name=boolean

Tests if the current transaction is authorized in an LDAP realm and if
the authenticated user has the specified LDAP attribute.

realm=realm_name

If authenticate=yes, the realm condition tests the source of the
transaction for membership in the specified realm name.

user=username

If authenticate=yes, the user condition tests the source of the
transaction for the expected username.

user.domain=
windows_domain_name

(This condition is NTLM-realm specific.) If authenticate=yes,
the user_domain condition tests whether the realm type is NTLM
and whether the domain component of the username is the expected
domain name.

Read-only or Read-write Conditions
admin_access=read | write

read tests whether the source of the transaction has read-only
permission for the ProxySG console. write tests whether the source
has read-write permission.
When an Administrator logs into the CLI, the ProxySG executes an
transaction that includes the condition
admin_access=read. If the transaction is ultimately allowed (all
conditions have been met), the user will have read-only access to
configuration information through the CLI. Further, when that user
executes the CLI enable command, or logs into the Management
Console, the ProxySG executes an transaction with
admin_access=write. If the transaction is allowed, the user will
have read-write access within the CLI or the Management Console.

281

Blue Coat ProxySG Configuration and Management Guide

Section A: Controlling Access to the ProxySG
Table 8.4 lists the properties permitted in the layer:
Table 8.4: Layer Properties
Properties
deny

Refuse service to the source of the transaction.

authenticate(realm_name)

Requests authentication of the transaction source for the
specified realm.

authenticate.force( )

If yes is specified then forces authentication even if the
transaction is denied. This results in the user information
being available for logging. If no, then early denial without
authentication is possible.

allow

Permit further service to the source of the transaction.

log.suppress.field-id ( )

Controls suppression of the specified field-id in all
facilities

log.suppress.field-id[log_list]( )

Controls suppression of the specified field-id in the
specified facilities.

log.rewrite.field-id( )

Controls rewrites of a specific log field in all facilities.

log.rewrite.field-id[log_list]
( )

Controls rewrites of a specific log field in a specified list of
log facilities.

Table 8.5 lists the actions permitted in the layer:
Table 8.5: Layer Actions
Actions
notify_email( )

Sends an e-mail notification to the list of recipients specified in the
Event Log mail configuration when the transaction terminates.

notify_snmp( )

The SNMP trap is sent when the transaction terminates.

Example Policy Using CPL Syntax
To authenticate users against an LDAP realm, use the following syntax in the Local Policy file:

authenticate(LDAP_Realm)

group="cn=Administrators,cn=Groups,dc=bluecoat,dc=com" allow

This authenticates users against the specified LDAP realm. If the users are successfully authenticated
and belong to group Administrators, they are allowed to administer the ProxySG.

282

Chapter 8: Security and Authentication

Section B: Controlling Access to the Internet and Intranet

Section B: Controlling Access to the Internet and Intranet
Once the ProxySG is secure, you can limit access to the Internet and intranet. It is possible to control
access to the network without using authentication. You only need to use authentication if you want
to use identity-based access controls.
This section contains:


"Using Authentication and Proxies"



"Using SSL with Authentication and Authorization Services"



"Creating a Proxy Layer to Manage Proxy Operations"

Using Authentication and Proxies
Authentication means that the ProxySG requires proof of user identity in order to make decisions
based on that identity. This proof is obtained by sending the client (a browser, for example) a
challenge—a request to provide credentials. Browsers can respond to different kinds of credential
challenges:


Proxy-style challenges—Sent from proxy servers to clients that are explicitly proxied. In HTTP, the
response code is 407.
An authenticating explicit proxy server sends a proxy-style challenge (407/Proxy-Authenticate)
to the browser. The browser knows it is talking to a proxy and that the proxy wants proxy
credentials. The browser responds to a proxy challenge with proxy credentials
(Proxy-Authorization: header). The browser must be configured for explicit proxy in order for it
to respond to a proxy challenge.



Origin-style challenges—Sent from origin content servers (OCS), or from proxy servers
impersonating a OCS. In HTTP, the response code is 401 Unauthorized.
In transparent proxy mode, the ProxySG uses the OCS authentication challenge (HTTP 401 and
WWW-Authenticate)—acting as though it is the location from which the user initially requested a
page. A transparent proxy, including a reverse proxy, must not use a proxy challenge, because the
client might not be expecting it.

Once the browser supplies the credentials, the ProxySG authenticates them.

Understanding Authentication Modes
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 user’s real credentials.

283

Blue Coat ProxySG Configuration and Management Guide

Section B: Controlling Access to the Internet and Intranet


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 do not
work; origin challenges are then issued.


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 do 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. 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. The ProxySG does not support origin-redirects with the
CONNECT method.



SG2: The mode is selected automatically, based on the request, and uses the SGOS 2.x-defined

rules.

284



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.

Chapter 8: Security and Authentication

Section B: Controlling Access to the Internet and Intranet


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.
For more information on using authentication modes, see the Blue Coat ProxySG Content Policy
Language Guide.

Setting the Default Authenticate Mode Property
Setting the authentication.mode property selects a challenge type and surrogate credential
combination. In auto mode, explicit NTLM uses connection surrogate credentials. In sg2 mode,
explicit NTLM uses IP surrogate credentials.
To Configure the NTLM Default Authenticate Mode Settings
At the (config) command prompt, enter the following commands:
SGOS#(config) security default-authenticate-mode {auto | sg2}

Understanding Origin-Style Redirection
Some authentication modes redirect the browser to a virtual authentication site before issuing the
origin-style challenge. This gives the user feedback as to which credentials are required, and makes it
possible to (but does not require) send the credentials over a secure connection.
Since browser requests are transparently redirected to the ProxySG, the appliance intercepts the
request for the virtual authentication site and issues the appropriate credential challenge. Thus, the
challenge appears to come from the virtual site, which is usually named to make it clear to the user
that ProxySG credentials are requested.
If authentication is successful, the ProxySG establishes a surrogate credential and redirects the
browser back to the original request, possibly with an encoded surrogate credential attached. This
allows the ProxySG to see that the request has been authenticated, and so the request proceeds. The
response to that request can also carry a surrogate credential.
To provide maximum flexibility, the virtual site is defined by a URL. Requests to that URL (only) are
intercepted and cause authentication challenges; other URLs on the same host are treated normally.
Thus, the challenge appears to come from a host that in all other respects behaves normally.

285

Blue Coat ProxySG Configuration and Management Guide

Section B: Controlling Access to the Internet and Intranet

Note:

Sharing the virtual URL with other content on a real host requires additional
configuration if the credential exchange is over SSL.

You can configure the virtual site to something that is meaningful for your company. The default,
which requires no configuration, is www.cfauth.com. See "Configuring Transparent Proxy
Authentication" on page 286 to set up a virtual URL for transparent proxy.

Tip: Using CONNECT and Origin-Style Redirection
You cannot use the CONNECT method with origin-style redirection or form redirect modes. An error
message similar to the following is displayed:
Cannot use origin-redirect for CONNECT method (explicit proxy of https URL)

Instead, you can add policy to either bypass authentication on the CONNECT method, or use proxy
authentication. For example:

allow http.method=CONNECT authenticate.mode(proxy) authenticate(ldap)
allow authenticate(cert) authenticate.mode(origin-cookie-redirect)

Selecting an Appropriate Surrogate Credential
IP surrogate credentials are less secure than cookie surrogate credentials and should be avoided if
possible. If multiple clients share an IP address (such as when they are behind a NAT firewall or on a
multi-user system), the IP surrogate mechanism cannot distinguish between those users

Configuring Transparent Proxy Authentication
The following sections provide general instructions on configuring for transparent proxy
authentication.
In addition to configuring transparent proxy authentication, you must also enable a transparent proxy
port before the transparent proxy is functional. To enable a transparent proxy port, see "Creating and
Editing Services" on page 152.
To Set Transparent Proxy Options through the Management Console
1.

286

Select Configuration>Authentication>Transparent Proxy.

Chapter 8: Security and Authentication

Section B: Controlling Access to the Internet and Intranet

Figure 8-3: Transparent Proxy Tab

2.

Select the transparent proxy method—Cookie-based or IP address-based. The default is Cookie.
If you select Cookie, the 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 (Time To Live) is reached or the credentials cache is flushed. The
default is Session.
If you select Persistent Cookies, enter the Cookie TTL. If you choose IP address-based, enter the
IP address TTL. The default for each is 15 minutes.
Note:

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 to potentially gain 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
previously used for authentication.

287

Blue Coat ProxySG Configuration and Management Guide

Section B: Controlling Access to the Internet and Intranet

Note:

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 expires, you can supply a
different set of credentials than previously used for authentication.

3.

Select the Virtual URL. The default is www.cfauth.com. Blue Coat recommends you 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.

4.

Click Apply.

To Set Transparent Proxy Options through the CLI
1.

At the (config) command prompt, enter the following command:
SGOS#(config) security transparent-proxy-auth method {cookie | ip}

a.

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}

b.

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

c.

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

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.
2.

(Optional step for single ProxySG scenarios, only needed if specifying a different virtual URL than
supplied by Blue Coat—www.cfauth.com) To specify the virtual URL for cookie-based
authentication, enter the following command:
SGOS#(config) security transparent-proxy-auth cookie virtual-url url

3.

288

(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.)

Chapter 8: Security and Authentication

Section B: Controlling Access to the Internet and Intranet

Using SSL with Authentication and Authorization Services
Blue Coat recommends that you use SSL during authentication to secure your user credentials. Blue
Coat now supports SSL between the client and the ProxySG and between the ProxySG to LDAP and
NTLM authentication servers.

Using SSL Between the Client and the ProxySG
To configure SSL for to use origin-cookie-redirect or origin-ip-redirect challenges, you must:


Specify a virtual URL with the HTTPS protocol (for example, https://virtual_address.



Create a keyring and certificate on the ProxySG.



Create an HTTPS service to run on the port specified in the virtual URL and to use the keyring
you just created.

Note:

You can use SSL between the client and the ProxySG for origin-style challenges on
transparent or explicit connections (SSL for explicit proxy authentication is not
supported).

In addition, if you use a forward proxy, the challenge type must use redirection; it cannot be an origin
or origin-ip challenge type.
When redirected to the virtual URL, the user is prompted to accept the certificate offered by the
ProxySG (unless the certificate is signed by a trusted certificate authority). If accepted, the
authentication conversation between the ProxySG and the user is encrypted using the certificate.
Note:

If the hostname does not resolve to the IP address of the ProxySG, then the network
configuration must redirect traffic for that port to the appliance. Also, if you use the IP
address as the virtual hostname, you might have trouble getting a certificate signed by a
CA-Certificate authority (which might not be important).

For information on creating a keyring and a certificate, see "Configuring HTTPS Termination" on
page 234.
You can use SSL between the ProxySG and NTLM and LDAP authentication servers. For more
information, see Chapter 9: “Using Authentication Services” on page 299.

Creating a Proxy Layer to Manage Proxy Operations
Once hardware configuration is complete and the system configured to use transparent or explicit
proxies, use CPL or VPM to provide on-going management of proxy operations.

289

Blue Coat ProxySG Configuration and Management Guide

Section B: Controlling Access to the Internet and Intranet

Using CPL
Below is a table of all commands available for use in proxy layers of a policy. If a condition, property,
or action does not specify otherwise, it can be used only in layers. For information on
creating effective CPL, refer to the Blue Coat ProxySG Content Policy Language Guide.
Table 8.6: Layer Conditions

290

Layer Conditions

Meaning

admin.access=

Tests the administrative access requested by the current transaction. Can
also be used in layers.

attribute.name=

Tests if the current transaction is authenticated in a RADIUS or LDAP
realm, and if the authenticated user has the specified attribute with the
specified value. Can also be used in layers.

authenticated=

Tests if authentication was requested and the credentials could be verified;
otherwise, false. Can also be used in layers.

bitrate=

Tests if a streaming transaction requests bandwidth within the specified
range or an exact match. Can also be used in layers.

category=

Tests if the content categories of the requested URL match the specified
category, or if the URL has not been categorized. Can also be used in
layers.

client_address=

Tests the IP address of the client. Can also be used in layers.

client.connection.
negotiated_cipher=

Test the cipher suite negotiated with a securely connected client. Can also
be used in layers.

client.connection.
negotiated_cipher.
strength=

Test the cipher strength negotiated with a securely connected client. Can
also be used in layers.

client.host=

Test the hostname of the client (obtained through RDNS). Can also be used
in , , and layers.

client.host.has_name=

Test the status of the RDNS performed to determine 'client.host'. Can also
be used in , , and layers.

client_protocol=

Tests true if the client transport protocol matches the specification. Can also
be used in layers.

condition=

Tests if the specified defined condition is true. Can be used in all layers.

console_access=

(This trigger was formerly admin=yes|no.) Tests if the current request is
destined for the admin layer. Can also be used in and
layers.

content_management=

(This trigger was formerly content_admin=yes|no.) Tests if the current
request is a content-management transaction. Can also be used in
and layers.

Chapter 8: Security and Authentication

Section B: Controlling Access to the Internet and Intranet
Table 8.6: Layer Conditions (Continued)
date[.utc]=

Tests true if the current time is within the startdate..enddate range,
inclusive. Can be used in all layers.

day=

Tests if the day of the month is in the specified range or an exact match.
Can be used in all layers.

exception.id=

Indicates that the requested object was not served, providing this specific
exception page.
Can also be used in layers.

ftp.method=

Tests ftp request methods against any of a well-known set of FTP methods.
Can also be used in and layers.

group=

Tests if the authenticated condition is set to yes, the client is authenticated,
and the client belongs to the specified group. Can also be used in
layers.

has_attribute.name=

Tests if the current transaction is authenticated in an LDAP realm and if the
authenticated user has the specified LDAP attribute. Can also be used in
layers.

hour=

Tests if the time of day is in the specified range or an exact match. Can be
used in all layers.

http.method=

Tests HTTP request methods against any of a well known set of HTTP
methods. Can also be used in and layers.

http.method.regex=

Test the HTTP method using a regular expression. Can also be used in
layers.

http.request_line.regex=

Test the HTTP protocol request line. Can also be used in
layers.

http.request.version=

Tests the version of HTTP used by the client in making the request to the
ProxySG. Can also be used in and layers.

http.response_code=

Tests true if the current transaction is an HTTP transaction and the
response code received from the origin server is as specified. Can also be
used in and layers.

http.response.version=

Tests the version of HTTP used by the origin server to deliver the response
to the ProxySG. Can also be used in and layers.

http.transparent_
authentication=

This trigger evaluates to true if HTTP uses transparent proxy
authentication for this request. Can also be used in and
layers.

im.buddy_id=

Tests the buddy_id associated with the IM transaction. Can also be used
in layers.

im.chat_room.conference=

Tests whether the chat room associated with the transaction has the
conference attribute set. Can also be used in layers.

291

Blue Coat ProxySG Configuration and Management Guide

Section B: Controlling Access to the Internet and Intranet
Table 8.6: Layer Conditions (Continued)

292

im.chat_room.id=

Tests the chat room ID associated with the transaction. Can also be used in
layers.

im.chat_room.invite_
only=

Tests whether the chat room associated with the transaction has the
invite_only attribute set. Can also be used in layers.

im.chat_room.type=

Tests whether the chat room associated with the transaction is public or
private. Can also be used in layers.

im.chat_room.member=

Tests whether the chat room associated with the transaction has a member
matching the specified criterion. Can also be used in layers.

im.chat_room.voice_
enabled=

Tests whether the chat room associated with the transaction is voice
enabled. Can also be used in layers.

im.client=

Test the type of IM client in use. Can also be used in ,
, and layers.

im.file.extension=

Tests the file extension. Can also be used in layers.

im.file.name=

Tests the file name (the last component of the path), including the
extension. Can also be used in layers.

im.file.path=

Tests the file path against the specified criterion. Can also be used in
layers.

im.file.size=

Performs a signed 64-bit range test. Can also be used in
layers.

im.message.reflected

Test whether IM reflection occurred. Can also be used in
and layers.

im.message.route=

Tests how the IM message reaches its recipients. Can also be used in
layers.

im.message.size=

Performs a signed 64-bit range test. Can also be used in
layers.

im.message.text.
substring=

Performs a signed 64-bit range test. Can also be used in
layers.

im.message.opcode=

Tests the value of an opcode associated with an im.method of
send_unknown or receive_unknown.

im.message.type=

Tests the message type. Can also be used in layers.

im.method=

Tests the method associated with the IM transaction. Can also be used in
and layers.

im.user_id=

Tests the user_id associated with the IM transaction. Can also be used in
layers.

live=

Tests if the streaming content is a live stream. Can also be used in
layers.

Chapter 8: Security and Authentication

Section B: Controlling Access to the Internet and Intranet
Table 8.6: Layer Conditions (Continued)
minute=

Tests if the minute of the hour is in the specified range or an exact match.
Can be used in all layers.

month=

Tests if the month is in the specified range or an exact match. Can be used
in all layers.

proxy.address=

Tests the IP address of the network interface card (NIC) on which the
request arrives. Can also be used in layers.

proxy.card=

Tests the ordinal number of the network interface card (NIC) used by a
request. Can also be used in layers.

proxy.port=

Tests if the IP port used by a request is within the specified range or an
exact match. Can also be used in layers.

raw_url

Test the value of the raw request URL. Can also be used in
layers.

raw_url.host

Test the value of the 'host' component of the raw request URL. Can also be
used in layers.

raw_url.path

Test the value of the 'path' component of the raw request URL. Can also be
used in layers.

raw_url.pathquery

Test the value of the 'path and query' component of the raw request URL.
Can also be used in layers.

raw_url.port

Test the value of the 'port' component of the raw request URL. Can also be
used in layers.

raw_url.query

Test the value of the 'query' component of the raw request URL. Can also
be used in layers.

realm=

Tests if the authenticated condition is set to yes, the client is authenticated,
and the client has logged into the specified realm. an also be used in
layers.

release.id=

Tests the ProxySG release ID. Can be used in all layers.

request.header_address.
header_name=

Tests if the specified request header can be parsed as an IP address. Can
also be used in layers.

request.header.header_
name=

Tests the specified request header (header_name) against a regular
expression. Can also be used in layers.

request.header.header_
name.count

Test the number of header values in the request for the given header_name.
Can also be used in layers.

request.header.header_
name.length

Test the total length of the header values for the given header_name. Can
also be used in layers.

request.header.Referer.
url.host.has_name=

Test whether the Referer URL has a resolved DNS hostname. Can also be
used in layers.

293

Blue Coat ProxySG Configuration and Management Guide

Section B: Controlling Access to the Internet and Intranet
Table 8.6: Layer Conditions (Continued)
request.header.Referer.
url.is_absolute

Test whether the Referer URL is expressed in absolute form. Can also be
used in layers.

request.raw_headers.
count

Test the total number of HTTP request headers. Can also be used in
layers.

request.raw_headers.
length

Test the total length of all HTTP request headers. Can also be used in
layers.

request.raw_headers.
regex

Test the value of all HTTP request headers with a regular expression. Can
also be used in layers.

request.x_header.header_
name.count

Test the number of header values in the request for the given
header_name. Can also be used in layers.

request.x_header.header_
name.length

Test the total length of the header values for the given header_name. Can
also be used in layers.

response.header.header_
name=

Tests the specified response header (header_name) against a regular
expression. Can also be used in layers.

response.x_header.
header_name=

Tests the specified response header (header_name) against a regular
expression. Can also be used in layers.

server_url[.case_
sensitive|.no_lookup]=

Tests if a portion of the requested URL exactly matches the specified
pattern. Can also be used in layers.

socks.accelerated=

Controls the SOCKS proxy handoff to other protocol agents.

socks.method=

Tests the protocol method name associated with the transaction. Can also
be used in and layers.

socks.version=

Switches between SOCKS 4/4a and 5. Can also be used in
and layers.

streaming.content=

(This trigger has been renamed from streaming.) Can also be used in
, , and layers.

time=

Tests if the time of day is in the specified range or an exact match. Can be
used in all layers.

tunneled=

294

url.domain=

Tests if the requested URL, including the domain-suffix portion, matches
the specified pattern. Can also be used in layers.

url.extension=

Tests if the filename extension at the end of the path matches the specified
string. Can also be used in layers.

url.host=

Tests if the host component of the requested URL matches the IP address or
domain name. Can also be used in layers.

url.host.has_name

Test whether the request URL has a resolved DNS hostname. Can also be used in
layers

Chapter 8: Security and Authentication

Section B: Controlling Access to the Internet and Intranet
Table 8.6: Layer Conditions (Continued)
url.is_absolute

Test whether the request URL is expressed in absolute form. Can also be
used in layers

url.host.is_numeric=

This is true if the URL host was specified as an IP address. Can also be used
in layers.

url.host.no_name=

This is true if no domain name can be found for the URL host. Can also be
used in layers.

url.host.regex=

Tests if the specified regular expression matches a substring of the domain
name component of the request URL. Can also be used in
layers.

url.host.suffix=

Can also be used in layers.

url.path=

Tests if a prefix of the complete path component of the requested URL, as
well as any query component, matches the specified string. Can also be
used in layers.

url.path.regex=

Tests if the regex matches a substring of the path component of the request
URL. Can also be used in layers.

url.port=

Tests if the port number of the requested URL is within the specified range
or an exact match. Can also be used in layers.

url.query.regex=

Tests if the regex matches a substring of the query string component of the
request URL. Can also be used in layers.

url.regex=

Tests if the requested URL matches the specified pattern. Can also be used
in layers.

url.scheme=

Tests if the scheme of the requested URL matches the specified string. Can
also be used in layers.

user=

Tests the authenticated user name of the transaction. Can also be used in
layers.

user.domain=

Tests if the authenticated condition is set to yes, the client is authenticated,
the logged-into realm is an NTLM realm, and the domain component of
the user name is the specified domain. Can also be used in layers.

weekday=

Tests if the day of the week is in the specified range or an exact match. Can
be used in all layers.

year=

Tests if the year is in the specified range or an exact match. Can be used in
all layers.

Table 8.7: Layer Properties
Layer Properties

Meaning

action.action_label( )

Selectively enables or disables a specified define action block. Can also be
used in layers.

295

Blue Coat ProxySG Configuration and Management Guide

Section B: Controlling Access to the Internet and Intranet
Table 8.7: Layer Properties (Continued)
allow

Allows the transaction to be served. Can be used in all layers except
and layers.

always_verify( )

Determines whether each request for the objects at a particular URL must
be verified with the origin server.

authenticate( )

Identifies a realm that must be authenticated against. Can also be used in
layers.

authenticate.force( )

Either disables proxy authentication for the current transaction (using the
value no) or requests proxy authentication using the specified
authentication realm. Can also be used in layers.

authenticate.form( )

When forms-based authentication is in use, authenticate.form ( ) selects the
form used to challenge the user.

authenticate.mode(auto)
authenticate.mode(sg2)

Setting the authentication.mode property selects a challenge type and
surrogate credential combination. In auto mode, explicit NTLM uses
connection surrogate credentials. In sg2.mode, explicit NTLM uses IP
surrogate credentials.

authenticate.redirect_
stored_requests

Sets whether requests stored during forms-based authentication can be
redirected if the upstream host issues a redirecting response.

bypass_cache( )

Determines whether the cache is bypassed for a request.

check_authorization( )

In connection with CAD (Caching Authenticated Data) and CPAD
(Caching Proxy Authenticated Data) support,
check_authorization( ) is used when you know that the upstream
device will sometimes (not always or never) require the user to
authenticate and be authorized for this object. Can also be used in
layers.

delete_on_abandonment( )

If set to yes, then if all clients requesting an object close their connections
prior to the object being delivered, the object fetch from the origin server is
abandoned. Can also be used in layers.

deny

Denies service. Can be used in all layers except and
layers.

dynamic_bypass( )

Used to indicate that a particular transparent request should not be
handled by the proxy, but instead be subjected to our dynamic bypass
methodology.

exception( )

Indicates not to serve the requested object, but instead serve this specific
exception page.
Can be used in all layers except layers.

296

ftp.server_connection( )

Determines when the control connection to the server is established.

ftp.welcome_banner( )

Sets the welcome banner for a proxied FTP transaction.

http.client.recv.timeout

Sets the socket timeout for receiving bytes from the client.

Chapter 8: Security and Authentication

Section B: Controlling Access to the Internet and Intranet
Table 8.7: Layer Properties (Continued)
http.request.version( )

The http.request.version( ) property sets the version of the HTTP
protocol to be used in the request to the origin content server or upstream
proxy. Can also be used in layers.

http.response.parse_meta_
tag.
Cache-Control( )

Controls whether the 'Cache-Control' META Tag is parsed in an HTML
response body. Can also be used in layers.

http.response.parse_meta_
tag. Expires

Controls whether the 'Expires' META Tag is parsed in an HTML response
body. Can also be used in layers.

http.response.parse_meta_
tag. Pragma.no-cache

Controls whether the 'Pragma: no-cache' META Tag is parsed in an HTML
response body. Can also be used in layers.

http.response.version( )

The http.response.version( ) property sets the version of the
HTTP protocol to be used in the response to the client's user agent.

http.server.recv.
timeout( )

Sets the socket timeout for receiving bytes from the upstream host. Can
also be used in layers.

im.block_encryption

Prevents the encryption of AOL IM messages by modifying messages
during IM login time.

im.reflect

Sets whether IM reflection should be attempted.

im.strip_attachments( )

Determines whether attachments are stripped from IM messages.

im.transport

Sets the type of upstream connection to make for IM traffic.

log.suppress.field-id( )

The log.suppress.field-id( ) controls suppression of the specified
field-id in all facilities (individual logs that contain all properties for that
specific log in one format). Can be used in all layers.

log.suppress.field-id
[log_list]( )

The log.suppress.field-id [log_list]( ) property controls
suppression of the specified field-id in the specified facilities. Can be used
in all layers.

log.rewrite.field-id( )

The log.rewrite.field-id( ) property controls rewrites of a specific
log field in all facilities. Can be used in all layers.

log.rewrite.field-id
[log_list]( )

The log.rewrite.field-id [log_list]( ) property controls
rewrites of a specific log field in a specified list of log facilities. Can be used
in all layers.

reflect_ip( )

Determines how the client IP address is presented to the origin server for
explicitly proxied requests. Can also be used in layers.

request.filter_service( )

Websense is the built in service name for the off-box content filtering
service. Can also be used in layers.

request.icap_service( )

Determines whether a request from a client should be processed by an
external ICAP service before going out.

shell.prompt

Sets the prompt for a proxied Shell transaction.

297

Blue Coat ProxySG Configuration and Management Guide

Section B: Controlling Access to the Internet and Intranet
Table 8.7: Layer Properties (Continued)
shell.realm_banner

Sets the realm banner for a proxied Shell transaction.

shell.welcome_banner

Sets the welcome banner for a proxied Shell transaction.

socks.accelerate( )

The socks.accelerate property controls the SOCKS proxy handoff to
other protocol agents.

socks.authenticate( )

The same realms can be used for SOCKS proxy authentication as can be
used for regular proxy authentication.

socks.authenticate.
force( )

The socks.authenticate.force( ) property forces the realm to be
authenticated through SOCKS.

Table 8.8: Layer Actions

298

Layer Actions

Meaning

log_message( )

Writes the specified string to the ProxySG event log. Can be used in all
layers except .

notify_email( )

Sends an e-mail notification to the list of recipients specified in the Event
Log mail configuration. Can be used in all layers.

notify_snmp( )

The SNMP trap is sent when the transaction terminates. Can be used in all
layers.

redirect( )

Ends the current HTTP transaction and returns an HTTP redirect response
to the client.

transform

Invokes the active content or URL rewrite transformer.

Chapter 9: Using Authentication Services

Determining and configuring the type of security (such as LDAP, local list, and NTLM) to implement
on your network (authorization) is a critical part of managing enterprise security.

Understanding Realms
The ProxySG provides a flexible authentication architecture that supports multiple services with
multiple backend servers (for example, LDAP directory servers together with NT domains with no
trust relationship) within each authentication scheme with the introduction of the realm.
A realm authenticates and authorizes users for access to ProxySG services using either explicit proxy or
transparent proxy mode, discussed in "Configuring Proxies" on page 173.
Multiple authentication realms can be used on a single ProxySG. Multiple realms are essential if the
enterprise is a managed service provider or the company has merged with or acquired another
company. Even for companies using only one protocol, multiple realms might be necessary, such as
the case of a company using an LDAP server with multiple authentication boundaries. You can use
realm sequencing to search the multiple realms all at once.
A realm configuration includes:


Realm name.



Authentication service—(NTLM, LDAP, RADIUS, Local, Certificate, Sequences, Netegrity
SiteMinder®, Oblix COREid™, Policy Substitution).



External server configuration—Backend server configuration information, such as host, port, and
other relevant information based on the selected service.



Authentication schema—The definition used to authenticate users.



Authorization schema—The definition used to authorize users for membership in defined groups
and check for attributes that trigger evaluation against any defined policy rules.



One-time passwords are supported for RADIUS realms only.

SSL Between the ProxySG and the Authentication Server
SSL communication between the ProxySG and LDAP and NTLM authentication servers is supported.
In addition, you can also use SSL between the client and the ProxySG. For more information on using
SSL between the client and the ProxySG, see "Using SSL Between the Client and the ProxySG" on
page 289.
Configuring a realm to use SSL between the ProxySG and the authentication server is performed on a
per-realm basis. Part of the SSL configuration is specifying whether to verify the server's certificate. If
the server certificate is to be verified, then the server's certificate must be signed by a Certificate
Authority that the ProxySG trusts, and the common name in the server certificate must match the
server host as specified in the realm configuration.

299

Blue Coat ProxySG Configuration and Management Guide

The realms use the default SSL client defined on the ProxySG for SSL communications to the
authentication servers.
Note:

If the browser is configured for on-line checking of certificate revocation, the status check
must be configured to bypass authentication.

The chapter contains the following sections:

300



"NTLM Realm Authentication and Authorization"



"LDAP Realm Authentication and Authorization"



"RADIUS Realm Authentication and Authorization"



"Local Realm Authentication and Authorization"



"Certificate Realm Authentication"



"Netegrity SiteMinder"



"Oblix COREid"



"Policy Substitution Realm"



"Sequence Realm Authentication"



"Forms-Based Authentication"



"Managing the Credential Cache"

Chapter 9: Using Authentication Services

Section A: NTLM Realm Authentication and Authorization

Section A: NTLM Realm Authentication and Authorization
Windows NT LAN Manager (NTLM) is the authentication protocol used on Windows NT networks.
NTLM is a Microsoft-proprietary protocol that authenticates users and computers based on an
authentication challenge and response. When an NTLM realm is used and a resource is requested by
the client from the ProxySG, the appliance contacts the user's or computer's account domain to verify
identity and then requests an access token. The access token is generated by the domain controller and
passed to (and if valid, accepted by) the ProxySG.
Refer to the Microsoft Web site for detailed information about the NTLM protocol and a list of which
versions of the Microsoft operating systems use NTLM.
This section discusses the following topics:


"How Blue Coat Works with NTLM"



"Creating an NTLM Realm"



"NTLM Servers"



"Defining NTLM Realm General Properties"



"Creating the CPL"

How Blue Coat Works with NTLM
Blue Coat uses a proprietary NTLM agent to better manage NTLM connections.
For NTLM, a single BCAAA (Blue Coat Authentication and Authorization Agent) can support
multiple ProxySG Appliances; however, only one agent is permitted per realm.
Important: You cannot use CAASNT with SGOS 3.2 and higher.
BCAAA must be installed on a domain controller or member server. If the server where the BCAAA is
installed and its domain have a trust relationship with other domains, the user is authenticated
automatically by the other domains.

Creating an NTLM Realm
To create an NTLM realm, you must provide at least the primary host of the NTLM server for that
realm.
To Create an NTLM Realm through the Management Console
1.

Select Configuration>Authentication>NTLM>NTLM Realms.

301

Blue Coat ProxySG Configuration and Management Guide

Section A: NTLM Realm Authentication and Authorization

Figure 9-1: NTLM Realms Tab

2.

Click New; the Add NTLM Realm dialog displays.

Figure 9-2: Add NTLM Realm

3.

In the Realm name field, enter a realm name. The name can be 32 characters long and composed of
alphanumeric characters and underscores. The name must start with a letter.

4.

Identify the primary server host. You must enter a valid host or an error message is generated.

5.

(Optional) The default port is 16101. You can change the port number if the primary server is
listening on a different port.

6.

Click OK; click Apply.

NTLM Servers
Once you have created an NTLM realm, you can use the NTLM Servers page to change the current
default settings.
1.

302

Select Configuration>Authentication>NTLM>NTLM Servers.

Chapter 9: Using Authentication Services

Section A: NTLM Realm Authentication and Authorization

Figure 9-3: NTLM Servers Tab

2.

From the Realm Name drop-down list, select the NTLM realm for which you want to change server
properties.

3.

You must have defined at least one NTLM realm (using the NTLM Realms page) before attempting
to set NTLM server properties. If the message Realms must be added in the NTLM Realms tab
before editing this tab is displayed in red at the bottom of this page, you do not currently
have any NTLM realms defined

4.

Specify the host and port for the primary NTLM server. The default port is 16101.

5.

(Optional) Specify the host and port for the alternate NTLM server. The default port is 16101.

6.

(Optional) Under SSL Options, click the SSL enable checkbox to enable SSL.

7.

(Optional) By default, if SSL is enabled, the BCAAA certificate is verified. If you do not want to
verify the BCAAA certificate, deselect this checkbox.

8.

In the Timeout Request field, type the number of seconds the ProxySG allows for each request
attempt before timing out. (The default request timeout is 60 seconds.)

9.

Click Apply. Repeat the above steps for additional NTLM realms, up to a total of 40.

To Create and Define an NTLM Realm through the CLI
1.

At the (config) prompt, enter the following command to create an NTLM realm:
SGOS#(config) security ntlm create-realm realm_name primary_host
[primary_port]

where:
realm_name

The name of the NTLM realm.

primary_host

The host for the primary NTLM server.

primary_port

The port for the primary NTLM server. The default port is 16101.

303

Blue Coat ProxySG Configuration and Management Guide

Section A: NTLM Realm Authentication and Authorization
2.

To redefine the NTLM realm configuration for the realm you just created, enter the following
commands:
SGOS#(config) security ntlm edit-realm realm_name
SGOS#(config ntlm realm_name) primary-server primary_host [primary_port]

and optionally,
SGOS#(config ntlm realm_name) alternate-server alternate_host
[alternate_port]

where:

3.

primary_host

The host for the primary NTLM server.

primary_port

The port for the primary NTLM server. The default port is 16101.

alternate_host

The host for the alternate NTLM server.

alternate_port

The port for the alternate NTLM server. The default port is 16101.

To enable SSL for this realm and to have the BCAAA certificate verified, enter:
SGOS#(config ntlm realm_name) ssl enable
SGOS#(config ntlm realm_name) ssl-verify-server enable

Defining NTLM Realm General Properties
The NTLM General tab allows you to specify the display name, whether to support Basic and NTLM
credentials, the credential cache duration and a virtual URL.
To Configure General Settings through the Management Console
1.

Select Configuration>Authentication>NTLM>NTLM General.

Figure 9-4: NTLM General Tab

304

Chapter 9: Using Authentication Services

Section A: NTLM Realm Authentication and Authorization
2.

From the Realm Name drop-down list, select the NTLM realm for which you want to change
properties.
Note:

You must have defined at least one NTLM realm (using the NTLM Realms tab) before
attempting to set NTLM general properties. If the message Realms must be added in
the NTLM Realms tab before editing this tab is displayed in red at the bottom of
this page, you do not currently have any NTLM realms defined.

3.

If needed, change the NTLM realm display name. The default value for the display name is the
realm name. The display name cannot be longer than 128 characters and it cannot be null.

4.

You can enable or disable support for Basic credentials in the realm by selecting or deselecting the
Allow Basic credentials checkbox
Note:

At least one Basic or NTLM credential must be supported. Also, if the NTLM realm is part
of a sequence realm and is not the first realm in the sequence with try NTLM authentication
only once enabled that Basic credentials cannot be disabled in the NTLM realm.

5.

You can enable or disable support for NTLM credentials in the realm by selecting or deselecting
the Allow NTLM credentials checkbox. At least one of Basic or NTLM credentials must be supported.

6.

Specify the length of time, in seconds, that user and administrator credentials received from the
NTLM server are cached. Credentials can be cached for up to 3932100 seconds. The default cache
duration is 900 seconds (15 minutes).
Note:

7.

If you specify 0, traffic is increased to the NTLM server because each authentication
request generates an authentication and authorization request to the server. You can
specify a virtual URL based on the individual realm. For more information on the virtual
URL, see “Understanding Origin-Style Redirection” on page 285.

Click Apply.

To Configure General Settings through the CLI
At the (config) command prompt, enter the following commands to configure general settings:
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config

ntlm
ntlm
ntlm
ntlm
ntlm

realm_name)
realm_name)
realm_name)
realm_name)
realm_name)

cache-duration seconds
credentials-basic enable | disable
credentials-ntlm enable | disable
display-name name
virtual-url URL

where:
cache-duration

seconds

Specifies the length of time in seconds that user and
administrator credentials received from the NTLM server are
cached. Credentials can be cached for up to 3932100 seconds.
The default value is 900 seconds (15 minutes).

305

Blue Coat ProxySG Configuration and Management Guide

Section A: NTLM Realm Authentication and Authorization
credentialsbasic

enable |
disable

Enables or disables Basic credential support.

credentialsntlm

enable |
disable

Enables or disables NTLM credential support.

display-name

name

The default value for the display name is the realm name. The
display name cannot be longer than 128 characters and it
cannot be null.

virtual-url

URL

The URL to redirect to when the user needs to be challenged
for credentials. see Chapter 8: “Security and Authentication”
on page 269 for more details.

Creating the CPL
You can create CPL policies now that you have completed NTLM realm configuration. Be aware that
the examples below are just part of a comprehensive authentication policy. By themselves, they are not
adequate for your purposes.
The examples below assume the default policy condition is allow. On new SGOS 4.x systems, the
default policy condition is deny.
Note:



Refer to the Blue Coat ProxySG Content Policy Language Guide for details about CPL and
how transactions trigger the evaluation of policy file layers.

Every NTLM-authenticated user is allowed access the ProxySG.

authenticate(NTLMRealm)



Group membership is the determining factor in granting access to the ProxySG.

authenticate(NTLMRealm)

group=”Domain\internetusers”
deny

Tips and Boundary Conditions

306



Forms authentication modes cannot be used with an NTLM realm that allows only NTLM
credentials, a Policy Substitution realm, or a Certificate realm. If a form mode is in use and the
authentication realm is any of them, you will receive a configuration error.



For Windows Internet Explorer and Firefox (1.02 and higher) NTLM users who want true
single-sign-on (allowing Internet Explorer to provide your credentials automatically when
challenged), you must set the virtual URL to a hostname that is resolvable to the IP address of the
ProxySG by the client machines. Dots (for example, 10.1.1.1) are not allowed.

Chapter 9: Using Authentication Services

Section A: NTLM Realm Authentication and Authorization
To define the information in Internet Explorer, navigate to Internet Options>Security>Local
intranet>Sites>Advanced...>Web sites. (For XP, navigate to Internet Options>Security>Internet>Custom
Level, then select Automatic logon with current username and password.)
For Windows Internet Explorer 6.x, add the virtual host address to Internet Options>Privacy>Web
Sites>Managed Web Sites>Always Allow

307

Blue Coat ProxySG Configuration and Management Guide

Section B: LDAP Realm Authentication and Authorization

Section B: LDAP Realm Authentication and Authorization
Many companies and organizations use the Lightweight Directory Access Protocol (LDAP) as the
directory protocol of choice, enabling software to find an individual user without knowing where that
user is located in the network topography.
This section discusses the following topics:


"Overview"



"Creating an LDAP Realm"



"LDAP Servers"



"Defining LDAP Base Distinguished Names"



"LDAP Search & Groups Tab (Authorization and Group Information)"



"Customizing LDAP Objectclass Attribute Values"



"Defining Sequence Realm General Properties"



"Creating the CPL"

Overview
Blue Coat supports both LDAP v2 and LDAP v3, but recommends LDAP v3 because it uses Transport
Layer Security (TLS) and SSL and SSL to provide a secure connection between the ProxySG and the
LDAP server.
An LDAP directory, either version 2 or version 3, consists of a simple tree hierarchy. An LDAP
directory might span multiple LDAP servers. In LDAP v3, servers can return referrals to others
servers back to the client, allowing the client to follow those referrals if desired.
Directory services simplify administration; any additions or changes made once to the information in
the directory are immediately available to all users and directory-enabled applications, devices, and
ProxySG Appliances.
The ProxySG supports the use of external LDAP database servers to authenticate and authorize users
on a per-group or per-attribute basis.
LDAP group-based authentication for the ProxySG can be configured to support any
LDAP-compliant directory including:


Microsoft Active Directory Server



Novell NDS/eDirectory Server



Netscape/Sun iPlanet Directory Server



Other

The ProxySG also provides the ability to search for a single user in a single root of an LDAP directory
information tree (DIT), and to search in multiple Base Distinguished Names (DNs).
You can configure a LDAP realm to use SSL when communicating to the LDAP server.

308

Chapter 9: Using Authentication Services

Section B: LDAP Realm Authentication and Authorization
Configuring LDAP involves the following steps:


Creating a realm (up to 40) and configuring basic settings.



Configuring an LDAP server



Defining LDAP Base Distinguished Names



Defining Authorization and Group information



Configuring general LDAP realm settings



Creating policy

Creating an LDAP Realm
To Create an LDAP Realm through the Management Console
1.

Select Configuration>Authentication>LDAP>LDAP Realms.

Figure 9-5: LDAP Realms Tab

2.

Click New; the Add LDAP Realm dialog displays.

309

Blue Coat ProxySG Configuration and Management Guide

Section B: LDAP Realm Authentication and Authorization

Figure 9-6: Add LDAP Realm

3.

In the Real name field, enter a realm name. The name can be 32 characters long and composed of
alphanumeric characters and underscores. The name must start with a letter.

4.

From the Type of LDAP server drop-down list, select the specific LDAP server.

5.

Specify the host and port for the primary LDAP server. The host must be entered. The default port
number is 389.

6.

In the User attribute type field, specify the default user attribute type for the type of LDAP server.

7.

Microsoft Active Directory Server

sAMAccountName=

Novell NDS/eDirectory Server/Other

cn=

Netscape/iPlanet Directory Server

uid=

Click OK; click Apply.

To Create an LDAP Realm through the CLI
At the (config) command prompt, enter the following command to create an LDAP realm:
SGOS#(config) security ldap create-realm {ad | iplanet | nds | other}
realm_name [base_dn] primary_host [primary_port]

where:

310

ad | iplanet | nds
| other

The type of LDAP realm to create. ad specifies a Microsoft Active
Directory realm; iplanet specifies a Netscape/Sun iPlanet realm; nds
specifies a Novell NDS/eDirectory realm; other specifies a realm of any
other type.

realm_name

The name of the new LDAP realm.

Chapter 9: Using Authentication Services

Section B: LDAP Realm Authentication and Authorization
base_dn

The distinguished name (DN) used as the unique key for the LDAP group
database; the distinguished name of the key entry and all entries below it
in the directory tree. You can specify additional Base DNs after the realm
has been created. For example: ou=insidesales, o=toolsdivision.
A Base DN can be up to 128 characters long. (In Netscape/iPlanet
Directory Server, Base DN is also known as the Root DN.) See Table 9.1
for sample DN entries.
At least one base DN is required for authentication to succeed, although
you can create a realm without a base DN.

primary_host

The host for the primary LDAP server.

primary_port

The port for the primary LDAP server. The default port is 389.

LDAP Servers
Once you have created an LDAP realm, you can use the LDAP Servers page to change the current
default settings.
To Edit LDAP Server Properties through the Management Console
Note that the default values exist. You do not need to change these values if the default settings are
acceptable.
1.

Select Configuration>Authentication>>LDAP>LDAP Servers.

Figure 9-7: LDAP Servers Tab

2.

From the Realm Name drop-down list, select the LDAP realm for which you want to change server
properties.

311

Blue Coat ProxySG Configuration and Management Guide

Section B: LDAP Realm Authentication and Authorization

Note:

You must have defined at least one LDAP realm (using the LDAP Realms tab) before
attempting to set LDAP server properties. If the message Realms must be added in
the LDAP Realms tab before editing this tab is displayed in red at the bottom
of this page, you do not currently have any LDAP realms defined.

3.

From the Type of LDAP server drop-down list, select the specific LDAP server.

4.

From the LDAP Protocol Version drop-down list, select v2 for LDAP v2 support. LDAP v3 is the
default.
If you use LDAP v3, you can select Follow referrals to allow the client to follow referrals to other
servers. (This feature is not available with LDAP v2.) The default is Disabled.

5.

Specify the host and port for the primary LDAP server. The host must be entered. The default port
number is 389.

6.

(Optional) Specify the host and port for the alternate LDAP server. The default port is 389.

7.

(Optional) Under SSL Options, select Enable SSL to enable SSL. You can only select this option if
you are using LDAP v3.

8.

(Optional) By default, if SSL is enabled, the LDAP server certificate is verified. If you do not want
to verify the server certificate, disable this setting.

9.

(Optional) Change the timeout request for the server from its default of 60 seconds.

10. Click Apply. Repeat the above steps for additional LDAP realms, up to a total of 40.
To Edit LDAP Server Properties through the CLI
1.

From the (config) prompt, enter the following commands to modify LDAP realm authentication
properties:
SGOS#(config) security ldap edit-realm realm_name
SGOS#(config ldap realm_name) primary-server host [port]

and, optionally:
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config

312

ldap
ldap
ldap
ldap
ldap
ldap
ldap
ldap
ldap
ldap

realm_name)
realm_name)
realm_name)
realm_name)
realm_name)
realm_name)
realm_name)
realm_name)
realm_name)
realm_name)

alternate-server host [port]
distinguished-name base-dn clear
distinguished-name base-dn add base_DN
protocol-version {2 | 3}
referrals-follow {enable | disable}
spoof-authentication {none | origin | proxy}
ssl {disable | enable}
ssl-verify-server {disable | enable}
validate-authorized-user {disable | enable}
default-group-name group_name

Chapter 9: Using Authentication Services

Section B: LDAP Realm Authentication and Authorization
SGOS#(config ldap realm_name) no default-group-name
SGOS#(config ldap realm_name) exit
SGOS#(config ldap realm_name) timeout seconds

where
alternate-server

host [port]

The host for the secondary LDAP server.
The port can also be added, if you need it
to be other than the default (389).

distinguished name
base-dn

clear | add base_DN

Clears the existing base DN or adds the
specified base_DN. The distinguished
name (DN) used as the unique key for
the LDAP group database; the
distinguished name of the key entry and
all entries below it in the directory tree.
You can specify additional base DNs
after the realm has been created. For
example: ou=insidesales,
o=toolsdivision. A base DN can be
up to 128 characters long. (In
Netscape/iPlanet Directory Server, Base
DN is also known as the Root DN.) See
Table 9.1 for sample DN entries.
At least one base DN is required for
authentication to succeed, although you
can create a realm without a base DN.

protocol-version

2 | 3

The LDAP version you want to use.
LDAP v3 is the default, allowing you to
use the referrals-follow argument
and to use SSL.

referrals-follow

enable | disable

Allows the client to follow referrals to
other servers. This argument is not
available if you use LDAP v2.

spoof-authentication

none | origin |
proxy

Enables/disables the forwarding of
authenticated credentials to the origin
content server or for proxy
authentication. You can only choose one.
• If set to origin, the spoofed header is
an Authorization: header.
• If set to proxy, the spoofed header is a
Proxy-Authorization: header.
• If set to none, no spoofing occurs.
Flush the entries for a realm if the
spoof-authentication value is changed to
ensure that the spoof-authentication
value is immediately applied.

313

Blue Coat ProxySG Configuration and Management Guide

Section B: LDAP Realm Authentication and Authorization
ssl

enable | disable

Enables or disables SSL. This argument is
not available if you use LDAP v2.

ssl-verify-server

enable | disable

By default, if SSL is enabled, the LDAP
server certificate is verified. To not verify
the server certificate, disable this setting.

validate-authorizeduser

enable | disable

When validate-authorized-user is
enabled, an authorization (not
authentication) request will verify that
the user exists in the LDAP server. If the
user does not exist, the authorization
request fails (authentication requests
always require the user to exist).
When validate-authorized-user is
disabled, no user existence check is made
for an authorization request. If the user
does not exist, the authorization request
succeeds.

default-group-name

group_name

Clears the default group name.

no default-group-name
timeout

2.

If the validate-authorized-user
command is disabled and a
default-group-name is configured, the
default-group-name is used as the group
name for non-existent users.

seconds

Changes the timeout request for the
server from its default of 60 seconds.

(Optional) View the configuration (results shown are truncated):
SGOS#(config ldap realm_name)
Realm name:
Display name:
Server type:
Protocol version:
Follow referrals:
Case sensitivity:
User attribute type:
Base DNs:
Primary server host:
Primary server port:
...

view
ldap_1
testee
Other
3
disabled
disabled
cn
ou=insidesales
10.9.16.85
389

Defining LDAP Base Distinguished Names
The ProxySG allows you to specify multiple Base Distinguished Names (DNs) to search per realm,
along with the ability to specify a specific branch of a Base DN.
A Base DN identifies the entry that is starting point of the search. You must specify at least one
non-null base-DN for LDAP authentication to succeed.

314

Chapter 9: Using Authentication Services

Section B: LDAP Realm Authentication and Authorization
You must enter complete DNs. Table 9.1 lists some examples of distinguished name attributes.
Table 9.1: Distinguished Name Attributes
DN Attribute Syntax

Parameter Description

c=country

Country in which the user or group resides. Examples: c=US, c=GB.

cn=common name

Full name of person or object defined by the entry. Examples:
cn=David Smith, cn=Administrators, cn=4th floor
printer

mail=e-mail address

User or group e-mail address.

givenName=given name

User's first name.

l=locality

Locality in which the user or group resides. This can be the name of a
city, country, township, or other geographic regions. Examples:
l=Seattle, l=Pacific Northwest, l=King County.

o=organization

Organization to which the user or group is a member. Examples:
o=Blue Coat Inc, o=UW.

ou=organizational unit

Unit within an organization. Examples: ou=Sales, ou=IT,
ou=Compliance.

st=state or province

State or province in which the user or group resides. Examples:
st=Washington, st=Florida.

userPassword=password

Password created by a user.

streetAddress=street address

Street number and address of user or group defined by the entry.
Example: streetAddress= 420 North Mary Avenue
Sunnyvale, California 94085-4121.

sn=surname

User's last name.

telephoneNumber=telephone

User or group telephone number.

title=title

User's job title.

uid=user ID

Name that uniquely identifies the person or object defined by the
entry. Examples: uid=ssmith, uid=kjones.

To Define Searchable LDAP Base DNs through the Management Console
1.

Select Configuration>Authentication>LDAP>LDAP DN.

315

Blue Coat ProxySG Configuration and Management Guide

Section B: LDAP Realm Authentication and Authorization

Figure 9-8: LDAP DN Tab

2.

From the Realm Name drop-down list, select the LDAP realm for which you want to change DN
properties.
Note:

3.

You must have defined at least one LDAP realm (using the LDAP Realms tab) before
attempting to set LDAP server properties. If the message Realms must be added in the
LDAP Realms tab before editing this tab is displayed in red at the bottom of this
page, you do not currently have any LDAP realms defined.

In the User attribute type field, the ProxySG has entered the default user attribute type for the type
of LDAP server you specified when creating the realm.
Microsoft Active Directory Server

sAMAccountName=

Novell NDS/eDirectory Server/Other

cn=

Netscape/iPlanet Directory Server

uid=

If you entered information correctly when creating the realm, you do not need to change the User
attribute type in this step. If you do need to change or edit the entry, do so directly in the field.
4.

Enter as many Base DNs as you need for the realm. Assume, for example, that Sample_Company
has offices in New York and Lisbon, each with its own Base DN.

Figure 9-9: Simplified Directory Information Trees

316

Chapter 9: Using Authentication Services

Section B: LDAP Realm Authentication and Authorization
To specify entries for the Base DNs field, click New, enter the Base DN, and click OK. Repeat for
multiple Base DNs. To search all of Sample_Company, enter o values:

Figure 9-10: Searching SampleCompany

To search the manufacturing organizations, rather than starting at the top, enter ou and o values:

Figure 9-11: Searching Part of SampleCompany

You can add, edit, and delete Base DNs for a ProxySG to search. You can also select an individual
DN and move it up or down in the list with the Promote and Demote buttons. The ProxySG
searches multiple DNs in the order listed, starting at the top and working down.
5.

Click Apply to save the changes.

To Define One or More Searchable LDAP Base DNs through the CLI
1.

To define a Base DN, enter the following command:
SGOS#(config ldap realm_name) distinguished-name base-dn add base-dn

where base-dn is a string up to 128 characters long in the format appropriate to the type
of LDAP server represented by the realm name. The base-dn should be the
Fully-Qualified Domain Name (FQDN) of the base of the search.
Repeat this step for each additional Base DN you want added to the list. Entries in the list
start with the first Base DN created; subsequent additions are appended to the list. The
list is searched from the top down.
2.

(Optional) To remove a Base DN:
SGOS#(config ldap realm_name) distinguished-name base-dn remove base_dn

3.

(Optional) To remove all Base DNs and clear the list:
SGOS#(config ldap realm_name) distinguished-name base-dn clear

4.

(Optional) To move a Base DN up or down in the list of Base DNs:
SGOS#(config ldap realm_name) distinguished-name base-dn {promote | demote}
base_dn

where promote moves the specified Base DN up one level in the list and demote moves it
down one level. You must issue the command for each level you want to move the Base
DN.

317

Blue Coat ProxySG Configuration and Management Guide

Section B: LDAP Realm Authentication and Authorization

LDAP Search & Groups Tab (Authorization and Group Information)
After creating an LDAP realm, providing at least the required fields of the LDAP server for that realm,
and defining base DNs for the realm, you must define authorization properties for each LDAP realm
you created.
Note:

Authorization decisions are completely handled by policy. The groups that the ProxySG
looks up and queries are derived from the groups specified in policy in group=
conditions, attribute= conditions, and has Attribute conditions. If you do not have any
of those conditions, then Blue Coat does not look up any groups or attributes to make
policy decisions based on authorization.

To Define LDAP Realm Authorization Properties through the Management Console
1.

Select Configuration>Authentication>LDAP>LDAP Search & Groups.

Figure 9-12: LDAP Search & Groups Tab

2.

From the Realm Name drop-down list, select the LDAP realm for which you want to specify
authorization information.
Note:

3.

318

You must have defined at least one LDAP realm (using the LDAP Realms tab) before
attempting to set LDAP Search & Group properties. If the message Realms must be
added in the LDAP Realms tab before editing this tab is displayed in red at the
bottom of this page, you do not currently have any LDAP realms defined.

Specify whether to allow anonymous search or to enforce user authentication before allowing a
search.

Chapter 9: Using Authentication Services

Section B: LDAP Realm Authentication and Authorization
Some directories require a valid user to be able to perform an LDAP search; they do not allow
anonymous bind. (Active Directory is one such example.) For these directories, you must specify a
valid fully-qualified distinguished username and the password that permits directory access
privileges. (For example, cn=user1,cn=users,dc=bluecoat,dc=com is a possible fully-qualified
distinguished name.)
To permit users to anonymously bind to the LDAP service, select Anonymous Search Allowed. For
example, with Netscape/iPlanet Directory Server, when anonymous access is allowed, no
username or password is required by the LDAP client to retrieve information.
The LDAP directory attributes available for an anonymous client are typically a subset of those
available when a valid user distinguished name and password have been used as search
credentials.
To enforce user authentication before binding to the LDAP service, deselect Anonymous Search
Allowed, and set the Search User DN and Search User Password. Enter a user distinguished name in
the Search User DN field. This username can identify a single user or a user object that acts as a
proxy for multiple users (a pool of administrators, for example). A search user distinguished
name can be up to 512 characters long.
You can set or change the user password by clicking Change Password. This password can be up to
64 alphanumeric characters long.
You might want to create a separate user (such as Blue Coat, for example) instead of using an
Administrator distinguished name and password.
The Dereference level field has four values—always, finding, never, searching—that allow you to
specify when to search for a specific object rather than search for the object’s alias. The default is
Always.
4.

Group Information
Membership type and Membership attribute: The ProxySG enters the appropriate default:


Microsoft Active Directory:
Membership type: user
Membership attribute type: memberOf



Netscape/Sun iPlanet:
Membership type:group
Membership attribute typeuniqueMember



Novell NDS eDirectory/Other
Membership type:user
Membership attribute type:member

Username type to lookup: Select either FQDN or Relative. Only one can be selected at a time.

5.



Relative can only be selected in the membership type is Group.



FQDN indicates that the lookup is done only on the user object. FQDN can be selected when the
membership type is either Group or User.

Click Apply.

319

Blue Coat ProxySG Configuration and Management Guide

Section B: LDAP Realm Authentication and Authorization
To Define LDAP Realm Authorization Properties through the CLI
1.

Define the search criteria for the LDAP realm:
SGOS#(config ldap realm_name) search {anonymous {disable | enable} |
dereference {always | finding | never | searching} | password password |
encrypted-password encrypted_password | user-dn user_dn}

where:
anonymous

disable |
enable

If disabled, users are not permitted to anonymously bind to the
LDAP service.
If enabled, users are permitted to anonymously bind to the
LDAP service. When anonymous access is allowed, no
password is required by the LDAP client to retrieve
information, however, one can be specified, if extra security is
desirable.
The LDAP directory attributes available for an anonymous
client are typically a subset of those available to clients that have
been authenticated through a user distinguished name and
password.

dereference

always |
finding |
never |
searching

Sets dereference options.
always dereference aliases is the default.
finding dereferences aliases only during name resolution.
searching dereferences aliases only after name resolution.
never means that aliases are never dereferenced.

password |
encryptedpassword

password |
encrypted_
password

Specifies the user password (or encrypted password) associated
with the user distinguished name. The non-encrypted (or
plain-text) password can be up to 64 alphanumeric characters
long.
The primary use of the encrypted-password command is to
allow the ProxySG to reload a password that it encrypted. You
can choose to use a third-party encryption application. The
encrypted password is encrypted using RSA with OAEP
padding, and is Base64 encoded with no newlines.

user-dn

2.

user_dn

Specifies a user distinguished name. This username can identify
a single user or a user object that acts as a proxy for multiple
users (a pool of administrators, for example). Search user
distinguished name can be up to 512 characters long.

To define LDAP realm membership properties:
SGOS#(config ldap realm_name) membership-attribute membership_attribute

where membership_attribute is the name of the attribute that has the group information.
(For Active Directory, the attribute name is memberOf. For iPlanet, the attribute name is
uniquemember. For Novell Directory service, the attribute name is member.)

320

Chapter 9: Using Authentication Services

Section B: LDAP Realm Authentication and Authorization
SGOS#(config ldap realm_name) membership-type {group | user}

where group specifies that this realm is composed of individual members belonging to a
group defined elsewhere, and user specifies that this realm is composed of individual
disparate members whose only link to each other is membership in this group.
SGOS#(config ldap realm_name) membership-username (full | relative)

where full specifies that the user's FQDN is used during membership lookups, and
relative specifies that the user's relative username is used during membership lookups.
Only one can be selected at a time.

Customizing LDAP Objectclass Attribute Values
The objectclass attributes on an LDAP object define the type of object an entry is. For example, a user
entry might have an objectclass attribute value of person while a group entry might have an
objectclass attribute value of group.
The objectclass attribute values defined on a particular entry can differ among LDAP servers. The
objectclass attribute values are attribute values only, they are not DNs of any kind.
Currently, the objectclass attribute values are used by Blue Coat during a VPM browse of an LDAP
server. If an administrator wants to browse the groups in a particular realm, the ProxySG searches the
LDAP server for objects that have objectclass attribute values matching those in the group list and
in the container list. The list of objectclass attribute values in the container list is needed so that
containers that contain groups can be fetched and expanded correctly.
To Customize LDAP Objectclass Attribute Values through the Management Console
1.

Select Configuration>Authentication>LDAP>LDAP Objectclasses.

Figure 9-13: LDAP Objectclasses Tab

2.

From the Realm name drop-down list, select the LDAP realm whose objectclasses you want to
modify.

3.

From the Object type drop-down list, select the type of object: container, group, or user.

321

Blue Coat ProxySG Configuration and Management Guide

Section B: LDAP Realm Authentication and Authorization
4.

To create or edit an object for the specified objectclass, click New or Edit. (The only difference is
whether you are adding or editing an objectclass value.)
The Add/Edit Objectclass Value dialog displays.

Figure 9-14: Add Objectclass Value

5.

Enter or edit the objectclass, and click OK; click Apply. For example, objectclass=organization.

To Customize LDAP Objectclass Attribute Values through the CLI
At the (config) prompt, enter the following command to configure general settings:
SGOS#(config ldap realm_name) objectclass container {add
container_objectclass | clear | remove container_objectclass}
SGOS#(config ldap realm_name) objectclass group {add group_objectclass |
clear | remove group_objectclass}
SGOS#(config ldap realm_name) objectclass user {add user_objectclass | clear
| remove user_objectclass}

where:
container

{add | remove}
container_objectclass |
clear

Adds/removes container objectclass values
from the list (these values are used during VPM
searches of the LDAP realm), or clears all values
from the container objectclass list.

group

{add | remove}
group_objectclass |
clear

Adds/removes group objectclass values from
the list (these values are used during VPM
searches of the LDAP realm), or clears all values
from the group objectclass list.

user

{add | remove}
Adds/removes user objectclass values from the
user_objectclass | clear list (these values are used during VPM searches
of the LDAP realm), or clears all values from the
user objectclass list.

Defining LDAP General Realm Properties
The LDAP General page allows you to indicate whether an LDAP server is configured to expect
case-sensitive usernames and passwords, the length of time that credentials are cached, the display
name, and if you want to use a special virtual host for this realm.
To Configure General LDAP Settings through the Management Console
1.

322

Select Configuration>Authentication>LDAP>LDAP General.

Chapter 9: Using Authentication Services

Section B: LDAP Realm Authentication and Authorization

Figure 9-15: LDAP General Tab

2.

From the Realm Name drop-down list, select the LDAP realm for which you want to change
properties.
Note:

You must have defined at least one LDAP realm (using the LDAP Realms tab) before
attempting to set LDAP general properties. If the message Realms must be added in
the LDAP Realms tab before editing this tab is displayed in red at the bottom of
this page, you do not currently have any LDAP realms defined.

3.

If needed, give the LDAP realm a display name. The default value for the display name is the
realm name. The display name cannot be longer than 128 characters and it cannot be null.

4.

If the LDAP server is configured to expect case-sensitive usernames and passwords, select Case
sensitive.

5.

Specify the length of time in seconds that user and administrator credentials received from the
LDAP server are cached. Credentials can be cached for up to 3932100 seconds. The default value is
900 seconds (15 minutes).
Note:

6.

If you specify 0, this increases traffic to the LDAP server because each authentication
request generates an authentication and authorization request to the server.

You can specify a virtual URL based on the individual realm. For information on the virtual URL,
see “Understanding Origin-Style Redirection” on page 285.

323

Blue Coat ProxySG Configuration and Management Guide

Section B: LDAP Realm Authentication and Authorization
To Configure General LDAP Settings through the CLI
At the (config) prompt, enter the following command to configure general settings:
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config

ldap
ldap
ldap
ldap
ldap

realm_name)
realm_name)
realm_name)
realm_name)
realm_name)

cache-duration seconds
case-sensitive {enable | disable}
virtual-url URL
display-name display_name
rename new_realm_name

where:
cache-duration

seconds

Specifies the length of time in seconds that user and
administrator credentials received from the LDAP server are
cached. Credentials can be cached for up to 3932100 seconds.
The default value is 900 seconds (15 minutes).
If you specify 0, cached user and administrator credentials
are not re-used.

case-sensitive

enable |
disable

Enable this setting if the LDAP server is configured to expect
case-sensitive usernames and passwords.

virtual-url

URL

The URL to redirect to when the user needs to be challenged
for credentials. See Chapter 8: “Security and Authentication”
on page 269.

display-name

display_
name

The default value for the display name is the realm name. The
display name cannot be longer than 128 characters and
cannot be null.

rename

new_realm_
name

Allows you to change the realm name of an existing realm.

Creating the CPL
Be aware that the examples below are just part of a comprehensive authentication policy. By
themselves, they are not adequate for your purposes.
Note:

Refer to the Blue Coat ProxySG Content Policy Language Guide for details about CPL and
how transactions trigger the evaluation of policy file layers.

Be aware that the default policy condition for these examples is allow. The default policy condition on
new SGOS 4.x systems is deny.


Every LDAP-authenticated user is allowed access the ProxySG.

authenticate(LDAPRealm)



324

Group membership is the determining factor in granting access to the ProxySG.

Chapter 9: Using Authentication Services

Section B: LDAP Realm Authentication and Authorization

authenticate(LDAPRealm)

group=”cn=proxyusers, ou=groups, o=myco”
deny


A subnet definition determines the members of a group, in this case, members of the Human
Resources department.

authenticate(LDAPRealm)

Define subnet HRSubnet
192.168.0.0/16
10.0.0.0/24
End subnet HRSubnet
[Rule] client_address=HRSubnet
url.domain=monster.com
url.domain=hotjobs.com
deny
.
.
.
[Rule]
deny

325

Blue Coat ProxySG Configuration and Management Guide

Section C: RADIUS Realm Authentication and Authorization

Section C: RADIUS Realm Authentication and Authorization
RADIUS is often the protocol of choice for ISPs or enterprises with very large numbers of users.
RADIUS is designed to handle these large numbers through centralized user administration that eases
the repetitive tasks of adding and deleting users and their authentication information. RADIUS also
inherently provides some protection against sniffing.
Some RADIUS servers support one-time passwords. One-time passwords are passwords that become
invalid as soon as they are used. The passwords are often generated by a token or program, although
pre-printed lists are also used. Using one-time passwords ensures that the password cannot be used in
a replay attack.
The ProxySG’s one-time password support works with products such as Secure Computing’s
SafeWord. It is important to note that the ProxySG does not currently support SafeWord’s two-part
challenge mechanism.
This section discusses the following topics:


"Creating a RADIUS Realm"



"Defining RADIUS Realm Properties"



"Defining RADIUS Realm General Properties"




“Creating the CPL” on page 332r
"Creating the CPL"

Creating a RADIUS Realm
To Create a RADIUS Realm through the Management Console
1.

Select Configuration>Authentication>RADIUS>RADIUS Realms.

Figure 9-16: RADIUS Realms Tab

2.

326

Click New; the Add RADIUS Realm dialog displays.

Chapter 9: Using Authentication Services

Section C: RADIUS Realm Authentication and Authorization

Figure 9-17: Add RADIUS Realm

3.

In the Realm name field, enter a realm name. The name can be 32 characters long and composed of
alphanumeric characters and underscores. The name must start with a letter.

4.

Specify the host and port for the primary RADIUS server. The default port is 1812.

5.

Specify the RADIUS secret. RADIUS secrets can be up to 64 characters long and are always case
sensitive.

6.

Confirm the secret.

7.

Click OK; click Apply.

Defining RADIUS Realm Properties
Once you have created the RADIUS realm, you can change the primary host, port, and secret of the
RADIUS server for that realm.
To Re-Define RADIUS Server Properties through the Management Console
Note:

1.

To make these settings through the CLI, see "To Create and Define a RADIUS Realm
through the CLI" on page 330.

Select Configuration>Authentication>RADIUS>RADIUS Servers.

327

Blue Coat ProxySG Configuration and Management Guide

Section C: RADIUS Realm Authentication and Authorization

Figure 9-18: RADIUS Servers Tab

Note:

You must have defined a RADIUS realm (using the RADIUS Realms tab) before
attempting to set RADIUS server properties. If the message Realms must be added in
the RADIUS Realms tab before editing this tab is displayed in red at the bottom of
this page, you do not currently have a RADIUS realm defined.

2.

Specify the host and port for the primary RADIUS server. The default port is 1812. (To create or
change the RADIUS secret, click Change Secret. RADIUS secrets can be up to 64 characters long
and are always case sensitive.)

3.

Specify the Service type, which can be one of the following:


Login



Framed



Callback Login



Callback Framed



Outbound



Administrative



NAS Prompt



Authenticate Only



Callback NAS Prompt



Call Check



Callback Administrative

Framed is the default. If the user record contains Check-list ServiceType attributes, then at least
one of the ServiceType values must match the service-type of the RADIUS server as configured on
the ProxySG.

328

Chapter 9: Using Authentication Services

Section C: RADIUS Realm Authentication and Authorization
4.

(Optional) Specify the host and port for the alternate RADIUS server. The default port is 1812. (To
create or change the RADIUS secret, click Change Secret. RADIUS secrets can be up to 64
characters long and are always case sensitive.)

5.

Specify the service type. (See step 3, above, for information on the allowed services types.)
Framed is the default. If the user record contains Check-list ServiceType attributes, then at least
one of the ServiceType values must match the service-type of the RADIUS server as configured on
the ProxySG.

6.

In the Timeout Request field, enter the number of seconds the ProxySG allows for each request
attempt before timing out. The default request timeout is 5 seconds. In the Retry field, enter the
number of attempts permitted. The default number of retries is 5.

7.

If you are using one-time passwords, select the One-time passwords checkbox. (For more
information on using one-time passwords, see page 326.)

8.

Click Apply.

Defining RADIUS Realm General Properties
The RADIUS General tab allows you to specify the display name and a virtual URL.
To Configure General Settings through the Management Console
1.

Select Configuration>Authentication>RADIUS>RADIUS General.

Figure 9-19: RADIUS General Tab

Note:

You must have defined a RADIUS realm (using the RADIUS Realms tab) before
attempting to set RADIUS server properties. If the message Realms must be added in
the RADIUS Realms tab before editing this tab is displayed in red at the bottom of
this page, you do not currently have a RADIUS realm defined.

329

Blue Coat ProxySG Configuration and Management Guide

Section C: RADIUS Realm Authentication and Authorization
2.

If needed, change the RADIUS realm display name. The default value for the display name is the
realm name. The display name cannot be longer than 128 characters and it cannot be null.

3.

If the RADIUS server is configured to expect case-sensitive usernames and passwords, make sure
the Case sensitive checkbox is selected.

4.

Specify the length of time, in seconds, that user credentials received from the RADIUS server are
cached. Credentials can be cached for up to 3932100 seconds. The default is 900 seconds (15
minutes).
Note:

If you specify 0, traffic is increased to the RADIUS server because each authentication
request generates an authentication and authorization request.

5.

(Optional) You can specify a virtual URL based on the individual realm. For more information on
the virtual URL, see “Understanding Origin-Style Redirection” on page 285.

6.

Click Apply.

To Create and Define a RADIUS Realm through the CLI
1.

At the (config) prompt, enter the following command to create a RADIUS realm:
SGOS#(config) security radius create-realm realm_name secret
primary-server_host [primary-server_port]
-orSGOS#(config) security radius create-realm-encrypted realm_name
encrypted_secret primary_host [primary_port]

where:
realm_name

The name of the RADIUS realm.

secret |
encrypted_secret

The shared secret (or encrypted secret) associated with the primary RADIUS
server. (RADIUS secrets can be up to 64 characters long and are always case
sensitive.)
The primary use of the encrypted-password command is to allow the
ProxySG to reload a password that it encrypted. If you choose to use a
third-party encryption application, be sure it supports RSA encryption,
OAEP padding andBase64 encoded with no new lines.

330

primary_host

The host for the primary RADIUS server.

primary_port

The port for the primary RADIUS server. The default port is 1812.

Chapter 9: Using Authentication Services

Section C: RADIUS Realm Authentication and Authorization
2.

To set the newly-created RADIUS realm primary and alternate hosts and passwords, enter the
following commands:
SGOS#(config) security radius edit-realm realm_name
SGOS#(config radius realm_name) primary-server primary_host [primary_port]
SGOS#(config radius realm_name) primary-server service-type type
SGOS#(config radius realm_name) primary-server secret secret
-orSGOS#(config radius realm_name) primary-server encrypted-secret
encrypted_secret

and optionally:
SGOS#(config radius
[alternate_port]
SGOS#(config radius
-orSGOS#(config radius
encrypted_secret
SGOS#(config radius

realm_name) alternate-server alternate_host
realm_name) alternate-server secret secret
realm_name) alternate-server encrypted-secret
realm_name) alternate-server service-type type

where:
secret |
encrypted_secret

The shared secret (or encrypted secret) associated with the primary or
alternate RADIUS server. (RADIUS secrets can be up to 64 characters long and
are always case sensitive.)
The primary use of the encrypted-password command is to allow the
ProxySG to reload a password that it encrypted. You can choose to use a
third-party encryption application. The encrypted password is encrypted
using RSA with OAEP padding, and is Base64 encoded with no newlines.

type

type stands for the service type, which can be one of the following:
1. Login
2. Framed
3. Callback Login
4. Callback Framed
5. Outbound
6. Administrative
7. NAS Prompt
8. Authenticate Only
9. Callback NAS Prompt
10. Call Check
11. Callback Administrative
If the user record contains Check-list ServiceType attributes, then at least one
of the ServiceType values must match the service-type of the RADIUS server
as configured on the ProxySG.

primary_server

The host for the primary RADIUS server.

primary_port

The port for the primary RADIUS server. The default port is 1812.

alternate_host

The host for the alternate RADIUS server.

alternate_port

The port for the alternate RADIUS server. The default port is 1812.

331

Blue Coat ProxySG Configuration and Management Guide

Section C: RADIUS Realm Authentication and Authorization
3.

To complete configuration of the RADIUS realm, enter the following commands:
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config

radius
radius
radius
radius
radius
radius
radius

realm_name)
realm_name)
realm_name)
realm_name)
realm_name)
realm_name)
realm_name)

timeout seconds
server-retry count
cache-duration seconds
case-sensitive {enable | disable}
display-name name
spoof-authentication {none | origin | proxy}
one-time-passwords {enable | disable}

where:
timeout

seconds

The length of time permitted for RADIUS requests
to be received before timing out. The default is 5
seconds.

server-retry

count

The maximum number of attempts to access the
server.

cache-duration

seconds

The length of time that credentials should be
cached for this RADIUS realm. The default is 900
seconds (15 minutes)

display-name

name

The default value for the display name is the realm
name. The display name cannot be longer than 128
characters and it cannot be null.

spoof-authentication

none |
origin |
proxy

Enables/disables the forwarding of authenticated
credentials to the origin content server or for proxy
authentication. You can only choose one.
• If set to origin, the spoofed header is an
Authorization: header.
• If set to proxy, the spoofed header is a
Proxy-Authorization: header.
• If set to none, no spoofing occurs.
Flush the entries for a realm if the
spoof-authentication value is changed to
ensure that the spoof-authentication value is
immediately applied.

one-time-passwords

enable |
disable

Allows you to use one-time passwords for
authentication. The default is disabled. For more
information on one-time passwords, see page 326.

Creating the CPL
Be aware that the examples below are just part of a comprehensive authentication policy. By
themselves, they are not adequate.

332

Chapter 9: Using Authentication Services

Section C: RADIUS Realm Authentication and Authorization

Note:



Refer to the Blue Coat ProxySG Content Policy Language Guide for details about CPL and
how transactions trigger the evaluation of policy file layers.

Every RADIUS-authenticated user is allowed access the ProxySG.

authenticate(RADIUSRealm)

allow hasAttribute.servicetype=yes
deny

Configuring the ProxySG as a Session Monitor
You can configure the ProxySG to monitor RADIUS accounting messages and to maintain a session
table based on the information in these messages. The session table can then be used for logging or
authentication.
You can also, optionally, configure multiple ProxySG appliances to act as a session monitor cluster. The
session table is then replicated to all members of the cluster.
Once configured and enabled, the ProxySG session monitor maintains a session table that records
which sessions are currently active and the user identity for each session.

Configuring the Session Monitor
Three steps are required to configure the session monitor:


Configure the RADIUS accounting protocol parameters for the session monitor.



(Optional) Configure the session monitor cluster.



Configure the session monitor parameters.

Configuring the RADIUS Accounting Protocol Parameters
The configuration commands to create the RADIUS accounting protocol parameters can only be done
through the CLI. If you are using session-monitor clustering, the commands must be done on each
system in an already-existing failover group. (For information on configuring a failover group, see
"Section L: Configuring Failover" on page 134.)
To Configure the RADIUS Accounting Protocol Parameters
At the (config) prompt, enter the following commands:

333

Blue Coat ProxySG Configuration and Management Guide

Section C: RADIUS Realm Authentication and Authorization
SGOS#(config) session-monitor
SGOS#(config session-monitor)
SGOS#(config session-monitor)
SGOS#(config session-monitor)
encrypted_secret
SGOS#(config session-monitor)
SGOS#(config session-monitor)
SGOS#(config session-monitor)

radius acct-listen-port port_number
radius authentication {enable | disable}
radius encrypted-shared-secret
radius no encrypted-shared-secret
radius response {enable | disable}
radius shared-secret plaintext_secret

where
Command

Option

Description

radius
acct-listen-port

port_number

The port number where the ProxySG
listens for accounting messages

radius authentication

enable | disable

Enable or disable (the default) the
authentication of RADIUS messages
using the shared secret. Note that the
shared secret must be configured before
authentication is enabled.

radius
encrypted-sharedsecret

encrypted_shared_
secret

Specify the shared secret (in encrypted
form) used for RADIUS protocol
authentication. The secret is decrypted
using the configuration-passwords-key.
Clears the shared secret used for
RADIUS protocol authentication.

radius no
shared-secret
radius response

enable | disable

Enable (the default) or disable
generation of RADIUS responses.

radius shared-secret

plaintext_secret

Specify the shared secret used for
RAIDUS protocol in plaintext.

Configuring a Session Monitor Cluster
Configuring a session monitor cluster is optional. When a session monitor cluster is enabled, the
session table is replicated to all members of the cluster. The cluster members are the ProxySG
Appliances that are configured as part of the failover group referenced in the session monitor cluster
configuration. The failover group must be configured before the session monitor cluster. (For
information on configuring a failover group, see "Section L: Configuring Failover" on page 134.)
If you want the session table to be replicated to all the members of a failover group, you can use the
following commands.
Note:

When using a session monitor cluster, the RADIUS client must be configured to send the
RADIUS accounting messages to the failover group's virtual IP address.

Proxy traffic can be routed to any of the machines in the cluster.

334

Chapter 9: Using Authentication Services

Section C: RADIUS Realm Authentication and Authorization

Note:

Each member of the failover group must configured with the cluster commands to
maintain the session table for RADIUS accounting messages.

To Configure Session Monitor Cluster Parameters
At the (config) prompt, enter the following commands:
SGOS#(config) session-monitor
SGOS#(config session-monitor)
SGOS#(config session-monitor)
SGOS#(config session-monitor)
SGOS#(config session-monitor)
SGOS#(config session-monitor)

cluster
cluster
cluster
cluster
cluster

{enable | disable}
group-address IP_address
port port_number
grace-period seconds
synchronization-delay seconds

where
Command

Option

Description

cluster

enable |
disable

Enable or disable (the default) clustering on
a failover group. The group address must be
set before the cluster can be enabled.

cluster group-address
| no group-address

IP_address

Set or clear (the default) the failover group
IP address. This must be an existing failover
group address.

cluster port

port_number

Set the TCP/IP port for the session
replication control. The default is 55555.

cluster
synchronization-delay

seconds

Set the maximum time to wait for session
table synchronization. The default is zero;
the range is from 0 to 2 ^31 -1 seconds.
During this time evaluation of
$(session.username) is delayed, so
proxy traffic might also be delayed.

cluster grace-period

seconds

Set the time to keep session transactions in
memory while waiting for slave logins. This
can be set to allow session table
synchronization to occur after the
synchronization-delay has expired. The
default is 30 seconds; the range is 0 to 2^31-1
seconds.

Configuring the Session Monitor
The session monitor commands set up session monitoring behavior. If using session-monitor
clustering, these commands must be done on all ProxySG systems in the failover group.

335

Blue Coat ProxySG Configuration and Management Guide

Section C: RADIUS Realm Authentication and Authorization
To Configure the Session Monitor
1.

At the (config) prompt, enter the following commands:
SGOS#(config) session-monitor
SGOS#(config session-monitor) disable | enable
SGOS#(config session-monitor) max-entries integer
SGOS#(config session-monitor) timeout minutes

where
Command

Option

Enable or disable (the default) session monitoring

enable | disable

2.

Description

max_entries

integer

The maximum number of entries in the session table.
The default is 500,000; the range is from 1 to 2,000,000. If
the table reaches the maximum, additional START
messages are ignored.

timeout

minutes

The amount of time before a session table entry
assumes a STOP message has been sent. The default is
120 minutes; the range is from 0 to 65535 minutes. Zero
indicates no timeout.

(Optional) To view the session-monitor configuration, you can either use the session-monitor
view command or the config show session-monitor command.
SGOS#(config) show session-monitor
General:
Status: enabled
Entry timeout: 120 minutes
Maximum entries: 500000
Cluster support: enabled
Cluster port: 55555
Cluster group address: 10.9.17.159
Synchronization delay: 0
Synchronization grace period: 30
Accounting protocol: radius
Radius accounting:
Listen ports:
Accounting: 1813
Responses: Enabled
Authentication: Enabled
Shared secret: ************

Limitations


336

The session table is kept in memory. If the system goes down, the contents of the session table are
lost. However, if the system is a member of a failover cluster, the current contents of the session
table can be obtained from another machine in the cluster. The only situation in which the session
table is entirely lost is if all machines in the cluster go down at the same time.

Chapter 9: Using Authentication Services

Section C: RADIUS Realm Authentication and Authorization


The session table is stored entirely in memory. The amount of memory needed is roughly 40MB
for 500,000 users.



The session replication protocol replicates session information only; configuration information is
not exchanged. That means that each ProxySG must be properly configured for session
monitoring.



The session replication protocol is not secured. The failover group should be on a physically
secure network to communicate with each other.



The session monitor requires sufficient memory and at least 100Mb-per-second network links
among the cluster to manage large numbers of active sessions.



The username in the session table is obtained from the Calling-Station-ID attribute in the RADIUS
accounting message and can be a maximum of 19 bytes.

Creating the CPL
Be aware that the examples below are just part of a comprehensive authentication policy. By
themselves, they are not adequate.
Note:



Refer to the Blue Coat ProxySG Content Policy Language Guide for details about CPL and
how transactions trigger the evaluation of policy file layers.

The ProxySG is using the session table maintained by the session monitor for authentication.

allow authenticate(session)

where session is a Policy Substitution realm that uses $(session.username) in
building the username. (For information on creating a Policy Substitution realm, see "Policy
Substitution Realm" on page 386.)

337

Blue Coat ProxySG Configuration and Management Guide

Section D: Local Realm Authentication and Authorization

Section D: Local Realm Authentication and Authorization
Using a Local realm is appropriate when the network topography does not include external
authentication or when you want to add users and administrators to be used by the ProxySG only.
The Local realm (you can create up to 40) uses a Local User List, a collection of users and groups stored
locally on the ProxySG. You can create up to 50 different Local User Lists. Multiple Local realms can
reference the same list at the same time, although each realm can only reference one list at a time. The
default list used by the realm can be changed at any time.
This section discusses the following topics:


"Creating a Local Realm"



"Changing Local Realm Properties"



"Defining the Local User List"



"Creating the CPL"

Creating a Local Realm
To Create a Local Realm through the Management Console
1.

Select Configuration>Authentication>Local>Local Realms.

Figure 9-20: Local Realms Tab

2.

338

Click New; the Add Local Realm dialog displays.

Chapter 9: Using Authentication Services

Section D: Local Realm Authentication and Authorization

Figure 9-21: Add Local Realm

3.

In the Realm name field, enter a realm name. The name can be 32 characters long and composed of
alphanumeric characters and underscores. The name must start with a letter.

4.

Click OK; click Apply.

To Create a Local Realm through the CLI
Up to 40 Local realms can be configured per ProxySG.
At the (config) command prompt, enter the following command to create a Local realm:
SGOS#(config) security local create-realm realm_name

where realm_name is the name of the new Local realm.

Changing Local Realm Properties
Once you have created a Local realm, you can modify the properties through the Management
Console or the CLI.
To Define or Change Local Realm Properties through the Management Console
1.

Select Configuration>Authentication>Local>Local Main.

Figure 9-22: Local Main Tab

339

Blue Coat ProxySG Configuration and Management Guide

Section D: Local Realm Authentication and Authorization

Note:

2.

You must define a Local realm (using the Local Realms tab) before attempting to set realm
properties. If the message Realms must be added in the Local Realms tab before
editing this tab is displayed in red at the bottom of this page, you do not have a Local
realm defined.

Display name: The default value for the display name is the realm name. The display name cannot

be longer than 128 characters and it cannot be null.
3.

Local User List: Specify the local user list from the drop-down list.

4.

Specify the length of time, in seconds, that user and administrator credentials received from the
Local password file are cached. Credentials can be cached for up to 3932100 seconds. The default
is 900 seconds (15 minutes).

5.

You can specify a virtual URL based on the individual realm. For information on using virtual
URLs, see “Understanding Origin-Style Redirection” on page 285.

6.

Click Apply.

To Define or Change Local Realm Properties through the CLI
1.

From the (config) prompt, enter the following commands to modify realm properties:
SGOS#(config) security local edit-realm realm_name
SGOS#(config local realm_name) cache-duration 600
SGOS#(config local realm_name) display-name display_name
SGOS#(config local realm_name) local-user-list list_name
SGOS#(config local realm_name) rename new_realm_name
SGOS#(config local realm_name) spoof-authentication {disable | enable}
SGOS#(config local realm_name) virtual-url url
SGOS#(config local realm_name) validate-authorized-user {disable | enable}
SGOS#(config local realm_name) default-group-name default_group_name
SGOS#(config local realm_name) no default-group-name

where:

340

cache-duration

seconds

The number of seconds that user and administrator
credentials received from the Local password file should
be cached. The default is 900 seconds (15 minutes).

display-name

display_name

The display name for a realm, presented to the user as part
of the authentication challenge, is equivalent to the
display-name option in the CPL authenticate action.
The default value for the display name is the realm name.
The display name cannot be longer than 128 characters
and it cannot be null.

local-user-list

list_name

The list you want to associate with this realm. The list
must exist before it is added. The local user list is set to the
default list when the realm is created. For more
information on creating a local list, see "Defining the Local
User List" on page 342.

Chapter 9: Using Authentication Services

Section D: Local Realm Authentication and Authorization
rename

new_realm_
name

Allows you to change the realm name of an existing realm.

spoofauthentication

none |
origin |
proxy

Enables/disables the forwarding of authenticated
credentials to the origin content server or for proxy
authentication. You can only choose one.
• If set to origin, the spoofed header is an
Authorization: header.
• If set to proxy, the spoofed header is a
Proxy-Authorization: header.
• If set to none, no spoofing occurs.
Flush the entries for a realm if the
spoof-authentication value is changed to ensure
that the spoof-authentication value is immediately
applied.

virtual-url

URL

The URL to redirect to when the user needs to be
challenged for credentials. See Chapter 8: “Security and
Authentication” on page 269 for more details.

validateauthorized-user

enable |
disable

When validate-authorized-user is enabled, an
authorization (not authentication) request will verify that
the user exists in the local user list. If the user does not
exist, the authorization request fails (authentication
requests always require the user to exist).
When validate-authorized-user is disabled, no
user existence check is made for an authorization request.
If the user does not exist, the authorization request
succeeds.

default-groupname

no
default-groupname

group_name

If the validate-authorized-user command is
disabled and a default-group-name is configured, the
default-group-name is used as the group name for
non-existent users.
Clears the default group name.

341

Blue Coat ProxySG Configuration and Management Guide

Section D: Local Realm Authentication and Authorization
2.

(Optional) View the configuration:
SGOS#(config local realm_name) view
Realm name:
local_1
Display name:
local_1
Local user list:
local_user_database
Cache duration:
900
Virtual URL:
Spoof authentication:
none
Validate authorized user: yes
Default group name:

Defining the Local User List
Defining the local user list involves the following steps:


Create a list or customize the default list for your needs.



Upload a user list or add users and groups through the CLI.



Associate the list with the realm.

Creating a Local User List
The user list local_user_database is created on a new system or after an upgrade. It is empty on a new
system. If a password file existed on the ProxySG before an upgrade, then the list contains all users
and groups from the password file; the initial default user list is local_user_database. If a new user
list is created, the default can be changed to point to it instead by invoking the security
local-user-list default list list name command. You can create up to 50 new lists with 10,000
users each.
Lists can be uploaded or you can directly edit lists through the CLI. If you want to upload a list, it
must be created as a text file using the .htpasswd format of the ProxySG.
Each user entry in the list consists of:


username



List of groups



Hashed password



Enabled/disabled boolean searches

A list that has been populated looks like this:
SGOS#(config) security local-user-list edit listname
SGOS#(config local-user-list listname) view
list20
Lockout parameters:
Max failed attempts: 60
Lockout duration:
3600
Reset interval:
7200
Users:
admin1
Hashed Password: $1$TvEzpZE$Z2A/OuJU3w5LnEONDHkmg.

342

Chapter 9: Using Authentication Services

Section D: Local Realm Authentication and Authorization
Enabled: true
Groups:
group1
admin2
Hashed Password: $1$sKJvNB3r$xsInBU./2hhBz6xDAHpND.
Enabled: true
Groups:
group1
group2
admin3
Hashed Password: $1$duuCUt30$keSdIkZVS4RyFz47G78X20
Enabled: true
Groups:
group2
Groups:
group1
group2

To create a new empty local user list:
SGOS#(config) security local-user-list create listname

Username
The username must be case-sensitively unique, and can be no more than 64 characters long. All
characters are valid, except for a colon (:).
A new local user is enabled by default and has an empty password.

List of Groups
You cannot add a user to a group unless the group has previously been created in the list. The group
name must be case-sensitively unique, and can be no more than 64 characters long. All characters are
valid, except for colon (:).
The groups can be created in the list; however, their user permissions are defined through policies
only.

Hashed Password
The hashed password must be a valid UNIX DES or MD5 password whose plain-text equivalent
cannot be more than 64 characters long.
To populate the local user list using an off-box .htpasswd file, continue with the next section. To
populate the local user list using the ProxySG CLI, go to "Defining the Local User List" on page 342.

Populating a List using the .htpasswd File
To add users to a text file in .htpasswd format, enter the following UNIX htpasswd command:
prompt> htpasswd [-c] .htpasswd username

The –c option creates a new .htpasswd file and should only be used for the very first .htpasswd
command. You can overwrite any existing .htpasswd file by using the -c option.

343

Blue Coat ProxySG Configuration and Management Guide

Section D: Local Realm Authentication and Authorization
After entering this command, you are prompted to enter a password for the user identified by
username. The entered password is hashed and added to the user entry in the text file. If the -m option
is specified, the password is hashed using MD5; otherwise, UNIX DES is used
Important: Because the -c option overwrites the existing file, do not use the option if you are
adding users to an existing .htpasswd file.
Once you have added the users to the .htpasswd file, you can manually edit the file to add user
groups. When the .htpasswd file is complete, it should have the following format:
user:encrypted_password:group1,group2,…
user:encrypted_password:group1,group2,…

Note:

You can also modify the users and groups once they are loaded on the ProxySG. To
modify the list once it is on the ProxySG, see
"Populating a Local User List through the ProxySG" on page 345.

Uploading the .htpasswd File
When the .htpasswd file is uploaded, the entries from it either replace all entries in the default local
user list or append to the entries in the default local user list. One default local user list is specified on
the ProxySG.
To set the default local user list use the command security local-user-list default list
listname. The list specified must exist.
To specify that the uploaded .htpasswd file replace all existing user entries in the default list, enter
security local-user-list default append-to-default disable before uploading
the .htpasswd file.
To specify that the .htpasswd file entries should be appended to the default list instead, enter
security local-user-list default append-to-default enable.

Uploading the .htpasswd File
The .htpasswd file is loaded onto the ProxySG with a Perl script found at:
http://download.bluecoat.com/release/tools/set_auth.zip

Unzip the file, which contains the set_auth.pl script.
Note:

To use the set_auth.pl script, you must have Perl binaries on the system where the
script is running.

To Load the .htpasswd File
prompt> set_auth.pl username password
path_to_.htpasswd_file_on_local_machine ip_address_of_the_ProxySG

where username and password are valid administrator credentials for the ProxySG.

344

Chapter 9: Using Authentication Services

Section D: Local Realm Authentication and Authorization

Populating a Local User List through the ProxySG
You can populate a local user list from scratch or modify a local user list that was populated by
loading an .htpasswd file.
To Create a New, Empty Local User List
SGOS#(config) security local-user-list create listname

To Modify an Existing Local User List (Can be Empty or Contain Users)
1.

From the (config) prompt, enter:
SGOS#(config) security local-user-list edit listname
SGOS#(config local-user-list listname)

2.

To add users and groups to the list, enter the following commands, beginning with groups, since
they must exist before you can add them to a user account.
SGOS#(config
ok
SGOS#(config
ok
SGOS#(config
ok
SGOS#(config

3.

local-user-list listname) group create group1
local-user-list listname) group create group2
local-user-list listname) group create group3
local-user-list listname) user create username

Add the user information to the user account.
SGOS#(config local-user-list
SGOS#(config local-user-list
SGOS#(config local-user-list
SGOS#(config local-user-list
-orSGOS#(config local-user-list
hashed-password

Note:

4.

listname) user edit username
listname username) group add groupname1
listname username) group add groupname2
listname username) password password
listname username) hashed-password

If you enter a plain-text password, the ProxySG hashes the password. If you enter a
hashed password, the ProxySG does not hash it again.

(Optional) The user account is enabled by default. To disable a user account:
SGOS#(config local-user-list listname username) disable
ok

5.

Repeat the above steps for each user you want added to the list.

To View the Results of an Individual User Account
Remain in the user account submode and enter the following command:

345

Blue Coat ProxySG Configuration and Management Guide

Section D: Local Realm Authentication and Authorization
SGOS#(config local-user-list listname username) view
admin1
Hashed Password: $1$TvEzpZE$Z2A/OuJU3w5LnEONDHkmg.
Enabled: true
Failed Logins: 6
Groups:
group1

Note:

If a user has no failed logins, the statistic does not display.

To View the Users in the Entire List
Exit the user account submode and enter:
SGOS#(config local-user-list listname username) exit
SGOS#(config local-user-list listname) view
list20
Lockout parameters:
Max failed attempts: 60
Lockout duration:
3600
Reset interval:
7200
Users:
admin1
Hashed Password: $1$TvEzpZE$Z2A/OuJU3w5LnEONDHkmg.
Enabled: true
Groups:
group1
admin2
Hashed Password: $1$sKJvNB3r$xsInBU./2hhBz6xDAHpND.
Enabled: true
Groups:
group1
group2
admin3
Hashed Password: $1$duuCUt30$keSdIkZVS4RyFz47G78X20
Enabled: true
Groups:
group2
Groups:
group1
group2

To View all the Lists on the ProxySG
SGOS#(config) show security local-user-list
Default List: local_user_database
Append users loaded from file to default list: false
local_user_database
Lockout parameters:
Max failed attempts: 60
Lockout duration:
3600
Reset interval:
7200

346

Chapter 9: Using Authentication Services

Section D: Local Realm Authentication and Authorization
Users:
Groups:
test1
Users:
Groups:

To Delete Groups Associated with a User
SGOS#(config local-user-list listname username) group remove group_name

To Delete Users from a List
SGOS#(config local-user-list listname) user delete username
This will permanently delete the object. Proceed with deletion?
(y or n) y
ok

To Delete all Users from a List
SGOS#(config local-user-list listname) user clear
ok

The groups remain but have no users.
To Delete all Groups from a List:
SGOS#(config local-user-list listname) group clear
ok

The users remain but do not belong to any groups.

Enhancing Security Settings for the Local User List
You can configure a local user database so that each user account is automatically disabled if too many
failed login attempts occur for the account in too short a period, indicating a brute-force password
attack on the ProxySG. The security settings are available through the CLI only.
Available security settings are:


Maximum failed attempts: The maximum number of failed password attempts allowed for an
account. When this threshold is reached, the account is disabled (locked). If this is zero, there is no
limit. The default is 60 attempts.



Lockout duration: The time after which a locked account is re-enabled. If this is zero, the account
does not automatically re-enable, but instead remains locked until manually enabled. The default
is 3600 seconds (one hour).



Reset interval: The time after which a failed password count resets after the last failed password
attempt. If this is zero, the failed password count resets only when the account is enabled or when
its password is changed. The default is 7200 seconds (two hours).

These values are enabled by default on the system for all user account lists. You can change the
defaults for each list that exists on the system.

347

Blue Coat ProxySG Configuration and Management Guide

Section D: Local Realm Authentication and Authorization
To Change the Security Settings for a Specific User Account List
1.

Enter the following commands from the (config) prompt:
SGOS#(config) security local-user-list
SGOS#(config local-user-list listname)
SGOS#(config local-user-list listname)
SGOS#(config local-user-list listname)

2.

edit listname
lockout-duration seconds
max-failed-attempts attempts
reset-interval seconds

(Optional) View the settings:
SGOS#(config local-user-list listname) view
listname
Lockout parameters:
Max failed attempts: 45
Lockout duration:
3600
Reset interval:
0

3.

(Optional) To disable any of these settings:
SGOS#(config local-user-list listname) no [lockout-duration |
max-failed-attempts | reset-interval]

Creating the CPL
Be aware that the examples below are just part of a comprehensive authentication policy. By
themselves, they are not adequate for your purposes. (The default policy in these examples is deny.)
Note:



Refer to the Blue Coat ProxySG Content Policy Language Guide for details about CPL and
how transactions trigger the evaluation of policy file layers.

Every Local-authenticated user is allowed access the ProxySG.

authenticate(LocalRealm)



Group membership is the determining factor in granting access to the ProxySG.

authenticate(LocalRealm)

group=”group1” allow



A subnet definition determines the members of a group, in this case, members of the Human
Resources department.

authenticate(LocalRealm)

Define subnet HRSubnet
192.168.0.0/16
10.0.0.0/24
End subnet HRSubnet
[Rule] client_address=HRSubnet
url.domain=monster.com
url.domain=hotjobs.com

348

Chapter 9: Using Authentication Services

Section D: Local Realm Authentication and Authorization
deny
.
.
.
[Rule]
deny

349

Blue Coat ProxySG Configuration and Management Guide

Section E: Certificate Realm Authentication

Section E: Certificate Realm Authentication
Certificate realms are used to authenticate users. If the users are members of an LDAP or Local group,
the Certificate Realm can also forward the user credentials to the specified authorization realm, which
determines the user’s authorization (permissions).
This section discusses the following topics:


"How Certificate Realm Works"



"Creating a Certificate Realm"



"Defining a Certificate Realm"



"Defining Certificate Realm General Properties"



"Revoking User Certificates"

How Certificate Realm Works
Once an SSL session has been established, the user is asked to select the certificate to send to the
ProxySG. If the certificate was signed by a Certificate Signing Authority that the ProxySG trusts,
including itself, then the user is considered authenticated. The username for the user is the one
extracted from the certificate during authentication.
At this point the user is authenticated. If an authorization realm has been specified, such as LDAP or
Local, the certificate realm then passes the username to the specified authorization realm, which
figures out which groups the user belongs to.
Note:

If you authenticate with a certificate realm, you cannot also challenge for a password.

Certificate realms do not require an authorization realm. If no authorization realm is configured, the
user is not 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, then you do not need to specify an
authorization realm. Also, if your policy is such that it works as desired when all certificate
realm-authenticated users are not in any group, you do not have to specify an authorization realm.
To use a Certificate Realm, you must:

350



Configure SSL between the client and ProxySG (for more information, see "Using SSL Between the
Client and the ProxySG" on page 289)



Enable verify-client on the HTTPS service to be used (for more information, see "Managing the
HTTPS Service" on page 161).



Verify that the certificate authority that signed the client's certificates is in the ProxySG trusted list.

Chapter 9: Using Authentication Services

Section E: Certificate Realm Authentication

Creating a Certificate Realm
To Create a Certificate Realm through the Management Console
1.

Select Configuration>Authentication>Certificate>Certificate Realms.

Figure 9-23: Certificate Realms Tab

2.

Click New; the Add Certificate Realm dialog displays.

Figure 9-24: Add Certificate Realm

3.

In the Realm name field, enter a realm name. The name can be 32 characters long and composed of
alphanumeric characters and underscores. The name must start with a letter.

4.

Click OK; click Apply.

To Create a Certificate Realm through the CLI
Up to 40 Certificate realms can be configured per ProxySG.
At the (config) command prompt, enter the following command to create a Certificate realm:
SGOS#(config) security certificate create-realm realm_name

where realm_name is the name of the new Certificate realm.

351

Blue Coat ProxySG Configuration and Management Guide

Section E: Certificate Realm Authentication

Defining a Certificate Realm
To Define Certificate Authentication Properties through the Management Console
Note:

1.

You can also define certificate authentication properties through the CLI. For information,
see "To Create and Define a Certificate Realm through the CLI" on page 354.

Select Configuration>Authentication>Certificate>Certificate Main.

Figure 9-25: Certificate Main Tab

2.

From the Realm Name drop-down list, select the Certificate realm for which you want to change
realm properties.
Note:

You must have defined at least one Certificate realm (using the Certificate Realms tab)
before attempting to set Certificate realm properties. If the message Realms must be
added in the Certificate Realms tab before editing this tab is displayed in
red at the bottom of this page, you do not currently have any Certificate realms defined.

3.

(Optional) From the Authorization Realm Name drop-down list, select the LDAP or Local realm you
want to use to authorize users.

4.

From the username attribute field, enter the attribute that specifies the common name in the subject
of the certificate. CN is the default.

5.

(Optional, if you are configuring a Certificate realm with LDAP authorization) Enter the list of
attributes (the container attribute field) that should be used to construct the user's distinguished
name.
For example, $(OU) $(O) substitutes the OU and O fields from the certificate.

6.

(Optional, if you are configuring a Certificate realm with LDAP authorization) Select or deselect
Append Base DN.

352

Chapter 9: Using Authentication Services

Section E: Certificate Realm Authentication
7.

(Optional, if you are configuring a Certificate realm with LDAP authorization) Enter the Base DN
where the search starts. If no BASE DN is specified and Append Base DN is enabled, the first Base
DN defined in the LDAP realm used for authorization is appended.

8.

Cache credentials: Specify the length of time, in seconds, that user and administrator credentials
received from the Local password file are cached. Credentials can be cached for up to 3932100
seconds. The default is 900 seconds (15 minutes).

Defining Certificate Realm General Properties
The Certificate General tab allows you to specify the display name and a virtual URL.
To Configure Certificate Realm General Settings through the Management Console
1.

Select Configuration>Authentication>Certificate>Certificate General.

Figure 9-26: Certificate General Tab

2.

From the Realm name drop-down list, select the Certificate realm for which to change properties.
Note:

You must have defined at least one Certificate realm (using the Certificate Realms tab)
before attempting to set Certificate general properties. If the message Realms must be
added in the Certificate Realms tab before editing this tab is displayed in
red at the bottom of this page, you do not currently have any Certificate realms defined.

3.

If needed, change the Certificate realm display name. The default value for the display name is
the realm name. The display name cannot be longer than 128 characters and it cannot be null.

4.

You can specify a virtual URL based on the individual realm. For more information on the virtual
URL, see “Understanding Origin-Style Redirection” on page 285.

5.

Click Apply.

353

Blue Coat ProxySG Configuration and Management Guide

Section E: Certificate Realm Authentication
To Create and Define a Certificate Realm through the CLI
1.

At the (config) prompt:
SGOS#(config) security certificate create-realm realm_name

2.

To define an authorization realm for the Certificate realm configuration for the realm you just
created, enter the following commands:
SGOS#(config) security certificate edit-realm realm_name
SGOS#(config certificate realm_name) authorization {append-base-dn {enable |
disable | dn dn_to_append} | container-attr-list list | realm-name realm |
username-attribute attribute}

where:

3.

append-base-dn

enable |
disable | dn
dn_to_append

Used only if an LDAP authorization realm is present.

container-attrlist

list

Used only if an LDAP authorization realm is present. If the
CLI contains spaces, quotes must be used, as in
“ou=Research and Development, ou=Sales,
o=Blue Coat”.

realm-name

realm_name

The name of the LDAP or Local realm used for
authorization. The realm name must already exist.

usernameattribute

attribute

The attribute that specifies the common name in the subject
of the certificate. CN is the default.

Enter the following commands to modify Certificate realm properties:
SGOS#(config certificate realm_name) cache-duration 600
SGOS#(config certificate new_realm_name) virtual-url cfauth.com
SGOS#(config certificate new_realm_name) display-name display_name

where:

354

cache-duration

seconds

The number of seconds that user and administrator
credentials received from the Credential realm are cached.
The default is 900 seconds (15 minutes).

virtual-url

URL

The URL to redirect to when the user needs to be
challenged for credentials. See Chapter 8: “Security and
Authentication” on page 269 for more details.

display-name

display_name

The default value for the display name is the realm name.
The display name cannot be longer than 128 characters and
it cannot be null.

Chapter 9: Using Authentication Services

Section E: Certificate Realm Authentication
4.

(Optional) View the results:
SGOS#(config certificate certificate-name) view
Realm name:
certificate-name
Display name:
certificate-name
Cache duration:
900
Virtual URL:
cfauth.com
Authorization realm:
ldap-realm
Username attribute:
cn
Container attr. list: ou=Sales,ou=Manufacturing
Append DN:
enabled
Base DN:

Revoking User Certificates
Using policy you can revoke certain certificates by writing policy that denies access to users who have
authenticated with a certificate you want to revoke. You must maintain this list on the ProxySG; it is
not updated automatically.
A certificate is identified by its issuer (the Certificate Signing Authority that signed it) and its serial
number, which is unique to that CA.
Using that information, you can use the following strings to create a policy to revoke user certificates:


user.x509.serialNumber—This is a string representation of the certificate’s serial number in
HEX. The string is always an even number of characters long, so if the number needs an odd
number of characters to represent in hex, there is a leading zero. Comparisons are case insensitive.



user.x509.issuer—This is an RFC2253 LDAP DN. Comparisons are case sensitive.



(optional) user.x509.subject: This is an RFC2253 LDAP DN. Comparisons are case sensitive.

Example
If you have only one Certificate Signing Authority signing user certificates, you do not need to test the
issuer. In the layer of the Local Policy file:

deny user.x509.serialnumber=11
deny user.x509.serialNumber=0F

If you have multiple Certificate Signing Authorities, test both the issuer and the serial number. In the
layer of the Local Policy file:

355

Blue Coat ProxySG Configuration and Management Guide

Section E: Certificate Realm Authentication

deny
user.x509.issuer="Email=name,CN=name,OU=name,O=company,L=city,ST=state or
province,C=country" user.x509.serialnumber=11\
deny user.x509.issuer="CN=name,OU=name,O=company, L=city,ST=state or
province,C=country" \
deny user.x509.serialnumber=2CB06E9F00000000000B

Creating the Certificate Authorization Policy
When you complete Certificate realm configuration, you can create CPL policies. Be aware that the
examples below are just part of a comprehensive authentication policy. By themselves, they are not
adequate.
Note:

Refer to the Blue Coat ProxySG Content Policy Language Guide for details about CPL and
how transactions trigger the evaluation of policy file and other layers.

Be aware that the default policy condition for these examples is allow. On new SGOS4.x systems, the
default policy condition is deny.


Every Certificate realm authenticated user is allowed access the ProxySG.

authenticate(CertificateRealm)



A subnet definition determines the members of a group, in this case, members of the Human
Resources department. (They are allowed access to the two URLs listed. Everyone else is denied
permission.)

authenticate(CertificateRealm)

Define subnet HRSubnet
192.168.0.0/16
10.0.0.0/24
End subnet HRSubnet
[Rule] client_address=HRSubnet
url.domain=monster.com
url.domain=hotjobs.com
deny
.
.
.
[Rule]
deny

356

Chapter 9: Using Authentication Services

Section E: Certificate Realm Authentication

Tips
If you use a certificate realm and see an error message similar to the following
Realm configuration error for realm "cert": connection is not SSL.

This means that certificate authentication was requested for a transaction, but the transaction was not
done on an SSL connection, so no certificate was available.
This can happen in three ways:


The authenticate mode is either origin-IP-redirect/origin-cookie-redirect or
origin-IP/origin-cookie, but the virtual URL does not have an https: scheme. This is likely if
authentication through a certificate realm is selected with no other configuration, because the
default configuration does not use SSL for the virtual URL.



In a server accelerator deployment, the authenticate mode is origin and the transaction is on a
non-SSL port.



The authenticate mode is origin-IP-redirect/origin-cookie-redirect, the user has
authenticated, the credential cache entry has expired, and the next operation is a POST or PUT
from a browser that does not handle 307 redirects (that is, from a browser other than Internet
Explorer). The workaround is to visit another URL to refresh the credential cache entry and then
try the POST again.



Forms authentication modes cannot be used with a Certificate realm. If a form mode is in use and
the authentication realm is a Certificate realm, a Policy Substitution realm, or an NTLM realm,
you receive a configuration error.

357

Blue Coat ProxySG Configuration and Management Guide

Section F: Netegrity SiteMinder

Section F: Netegrity SiteMinder
The ProxySG can be configured to consult a SiteMinder policy server for authentication and session
management decisions. This requires that a SiteMinder realm be configured on the ProxySG and
policy written to use that realm for authentication.
Access to the SiteMinder policy server is done through the Blue Coat Authentication and
Authorization Agent (BCAAA), which must be installed on a Windows 2000 system or higher with
access to the SiteMinder policy servers.

Understanding SiteMinder Interaction with Blue Coat
Within the SiteMinder system, BCAAA acts as a custom Web agent. It communicates with the
SiteMinder policy server to authenticate the user and to obtain a SiteMinder session token, response
attribute information, and group membership information.
Custom header and cookie response attributes associated with OnAuthAccept and OnAccessAccept
attributes are obtained from the policy server and forwarded to the ProxySG. They can (as an option)
be included in requests forwarded by the ProxySG.
Within the ProxySG system, BCAAA acts as its agent to communicate with the SiteMinder server. The
ProxySG provides the user information to be validated to BCAAA, and receives the session token and
other information from BCAAA.
Each ProxySG SiteMinder realm used causes the creation of a BCAAA process on the Windows host
computer running BCAAA. A single host computer can support multiple ProxySG realms (from the
same or different ProxySG Appliances); the number depends on the capacity of the BCAAA host
computer and the amount of activity in the realms.
Configuration of the ProxySG SiteMinder realm must be coordinated with configuration of the
SiteMinder policy server. Each must be configured to be aware of the other. In addition, certain
SiteMinder responses must be configured so that BCAAA gets the information the ProxySG needs.

Configuring the SiteMinder Policy Server
Note:

Blue Coat assumes you are familiar with configuration of SiteMinder policy servers and
Web agents.

Since BCAAA is a Web agent in the SiteMinder system, it must be configured on the SiteMinder policy
server. Configuration of BCAAA on the host computer is not required; the agent obtains its
configuration information from the ProxySG.
A suitable Web agent must be created and configured on the SiteMinder server. This must be
configured to support 4.x agents, and a shared secret must be chosen and entered on the server (it
must also be entered in the ProxySG SiteMinder realm configuration).

358

Chapter 9: Using Authentication Services

Section F: Netegrity SiteMinder
SiteMinder protects resources identified by URLs. A ProxySG realm is associated with a single
protected resource. This could be an already existing resource on a SiteMinder server, (typical for a
reverse proxy arrangement) or it could be a resource created specifically to protect access to ProxySG
services (typical for a forward proxy).
Important: The request URL is not sent to the SiteMinder policy server as the requested
resource; the requested resource is the entire ProxySG realm. Access control of
individual URLs is done on the ProxySG using CPL or VPM.
The SiteMinder realm that controls the protected resource must be configured with a compatible
authentication scheme. The supported schemes are Basic (in plain text and over SSL), Forms (in plain
text and over SSL), and X.509 certificates. Configure the SiteMinder realm with one of these
authentication schemes.
Note:

Only the following X.509 Certificates are supported: X.509 Client Cert Template, X.509
Client Cert and Basic Template, and X.509 Client Cert and Form Template.

ProxySG requires information about the authenticated user to be returned as a SiteMinder response.
The responses should be sent by an OnAuthAccept rule used in the policy that controls the protected
resource.
The responses must include the following:


A Web-Agent-HTTP-Header-variable named BCSI_USERNAME. It must be a user attribute; the
value of the response must be the simple username of the authenticated user. For example, with
an LDAP directory this might be the value of the cn attribute or the uid attribute.



A Web-Agent-HTTP-Header-variable named BCSI_GROUPS. It must be a user attribute and the
value of the response must be SM_USERGROUPS.

If the policy server returns an LDAP FQDN as part of the authentication response, the ProxySG uses
that LDAP FQDN as the FQDN of the user.
Once the SiteMinder agent object, configuration, realm, rules, responses and policy have been
defined, the ProxySG can be configured.

Additional SiteMinder Configuration Notes
Note:

Additional configuration might be needed on the SiteMinder server depending on
specific features being used.



If using single-signon (SSO) with off-box redirection (such as to a forms login page), the forms
page must be processed by a 5.x or later Web Agent, and that agent must be configured with
fcccompatmode=no. This precludes that agent from doing SSO with 4.x agents.



For SSO to work with other Web agents, the other agents must have the AcceptTPCookie=YES as
part of their configuration. This is described in the SiteMinder documentation.

359

Blue Coat ProxySG Configuration and Management Guide

Section F: Netegrity SiteMinder


Blue Coat does not extract the issuerDN from X.509 certificates in the same way as the SiteMinder
agent. Thus, a separate certificate mapping might be needed for the SGOS agent and the
SiteMinder agents.
For example, the following was added to the SiteMinder policy server certificate mappings:
CN=Waterloo Authentication and Security Team,OU=Waterloo R&D, O=Blue Coat\,
Inc.,L=Waterloo,ST=ON,C=CA



In order to use off-box redirection (such as an SSO realm), all agents involved must have the
setting EncryptAgentName=no in their configurations.



The ProxySG Appliance's credential cache only caches the user's authentication information for
the smaller of the time-to-live (TTL) configured on the ProxySG and the session TTL configured
on the SiteMinder policy server.

Configuring the ProxySG Realm
The ProxySG realm must be configured so that it can:


Find the Blue Coat agent(s) that acts on its behalf (hostname or IP address, port, SSL options, and
the like).



Provide BCAAA with the information necessary to allow it to identify itself as a Web agent (agent
name, shared secret).



Provide BCAAA with the information that allows it to find the SiteMinder policy server (IP
address, ports, connection information.)



Provide BCAAA with the information that it needs to do authentication and collect authorization
information (protected resource name), and general options (server fail-over and off-box
redirection)

For more information on configuring the ProxySG SiteMinder realm, see "Creating a SiteMinder
Realm" on page 361.
Note:

All ProxySG and agent configuration is done on the ProxySG. The ProxySG sends the
necessary information to BCAAA when it establishes communication.

Participating in a Single Sign-On (SSO) Scheme
The ProxySG can participate in SSO with other systems that use the same SiteMinder policy server.
Users must supply their authentication credentials only once to any of the systems participating.
Participating in SSO is not a requirement, the Proxy SG can use the SiteMinder realm as an ordinary
realm.
When using SSO with SiteMinder, the SSO token is carried in a cookie (SMSESSION). This cookie is set
in the browser by the first system that authenticates the user; other systems obtain authentication
information from the cookie and so do not have to challenge the user for credentials. The ProxySG sets
the SMSESSION cookie if it is the first system to authenticate a user, and authenticates the user based on
the cookie if the cookie is present.

360

Chapter 9: Using Authentication Services

Section F: Netegrity SiteMinder
Since the SSO information is carried in a cookie, all the servers participating must be in the same
cookie domain, including the ProxySG. This imposes restrictions on the authenticate.mode() used
on the ProxySG.


A reverse proxy can use any origin mode.



A forward proxy must use one of the origin-redirect modes (such as
origin-cookie-redirect). When using origin-*-redirect modes, the virtual URL hostname
must be in the same cookie domain as the other systems. It cannot be an IP address and the
default www.cfauth.com does not work either.

When using origin-*-redirect, the SSO cookie is automatically set in an appropriate response after
the ProxySG authenticates the user. When using origin mode (in a reverse proxy), setting this cookie
must be explicitly specified by the administrator. The policy substitution variable
$(x-agent-sso-cookie) expands to the appropriate value of the set-cookie: header.

Avoiding ProxySG Challenges
In some SiteMinder deployments all credential challenges are issued by a central authentication
service (typically a Web server that challenges through a form). Protected services do not challenge
and process request credentials; instead, they work entirely with the SSO token. If the request does not
include an SSO token, or the SSO token is not acceptable, the request is redirected to the central
service, where authentication occurs. Once authentication is complete, the request is redirected to the
original resource with a response that sets the SSO token.
If the SiteMinder policy server is configured to use a forms-based authentication scheme, the above
happens automatically. However, in this case, the ProxySG realm can be configured to redirect to an
off-box authentication service always. The URL of the service is configured in the scheme definition
on the SiteMinder policy server. The ProxySG realm is then configured with
always-redirect-offbox enabled.
The ProxySG must not attempt to authenticate a request for the off-box authentication URL. If
necessary, authenticate(no) can be used in policy to prevent this.

Creating a SiteMinder Realm
To Create a SiteMinder Realm through the Management Console
1.

Select Configuration>Authentication>Netegrity SiteMinder>SiteMinder Realms.

361

Blue Coat ProxySG Configuration and Management Guide

Section F: Netegrity SiteMinder

Figure 9-27: SiteMinder Realms Tab

2.

Click New; the Add SiteMinder Realm dialog displays.

Figure 9-28: Add SiteMinder Realm

3.

In the Realm name field, enter a realm name. The name can be 32 characters long and composed of
alphanumeric characters and underscores. The name must start with a letter. The name should be
meaningful to you, but it does not have to be the name of the SiteMinder policy server.

4.

Click OK.

5.

Click Apply.

To Create a SiteMinder Realm through the CLI
At the (config) prompt, enter the following command to create a SiteMinder realm:
SGOS#(config) security siteminder create-realm realm_name

where realm_name is the name of the SiteMinder realm.

Configuring Agents
You must configure the SiteMinder realm so that it can find the Blue Coat Authentication and
Authorization Agent (BCAAA).
1.

362

Select Configuration>Authentication>Netegrity SiteMinder>Agents.

Chapter 9: Using Authentication Services

Section F: Netegrity SiteMinder

Figure 9-29: SiteMinder Agents Page

2.

Select the realm name to edit from the drop-down list.
Note:

You must have defined at least one SiteMinder realm (using the SiteMinder Realms tab)
before attempting to configure SiteMinder agents. If the message Realms must be added
in the SiteMinder Realms tab before editing this tab is displayed in red at the
bottom of this page, you do not currently have any SiteMinder realms defined.

3.

In the Primary agent section, enter the hostname or IP address where the agent resides.

4.

Change the port from the default of 16101 if necessary.

5.

Enter the agent name in the Agent name field. The agent name is the name as configured on the
SiteMinder policy server.

6.

You must create a secret for the Agent that matches the secret created on the SiteMinder policy
server. Click Change Secret. SiteMinder secrets can be up to 64 characters long and are always case
sensitive.

7.

(Optional) Enter an alternate agent host and agent name in the Alternate agent section.

8.

(Optional) Click Enable SSL to enable SSL between the ProxySG and the BCAAA.

9.

(Optional) By default, if SSL is enabled, the SiteMinder BCAAA certificate is verified. To not
verify the agent certificate, disable this setting.

363

Blue Coat ProxySG Configuration and Management Guide

Section F: Netegrity SiteMinder
To Edit a SiteMinder Agent through the CLI
1.

To define the primary and alternate agent configuration for the realm you just created, enter the
following commands at the (config) prompt:
SGOS#(config) security siteminder edit-realm realm_name
SGOS#(config siteminder realm_name) primary-agent agent-name agent_name
SGOS#(config siteminder realm_name) primary-agent host
host_name_or_IP_address
SGOS#(config siteminder realm_name) primary-agent port port_number
SGOS#(config siteminder realm_name) primary-agent encrypted-shared-secret
encrypted_shared_secret
-orSGOS#(config siteminder realm_name) primary-agent shared-secret
shared_secret
SGOS#(config siteminder
SGOS#(config siteminder
SGOS#(config siteminder
SGOS#(config siteminder
encrypted_shared_secret
-orSGOS#(config siteminder
shared_secret

realm_name)
realm_name)
realm_name)
realm_name)

alternate-agent
alternate-agent
alternate-agent
alternate-agent

agent-name agent_name
host host_name_or_IP
port port_number
encrypted-shared-secret

realm_name) alternate-agent shared-secret

where:
These commands allow you to configure either
the primary or alternate agent for the SiteMinder
realm.

primary-agent |
alternate agent

agent-name

agent_name

The name of the agent.

host

host_name_or
_IP_address

The host ID or the IP address of the system that
contains the agent.

port

port_number

The port where the agent listens.

encrypted-shared-secret
| shared-secret

secret

The shared secret (or encrypted secret)
associated with the primary or alternate agent.
(Secrets can be up to 64 characters long and are
always case sensitive.)
The primary use of the encrypted-password
command is to allow the ProxySG to reload a
password that it encrypted. You can choose to
use a third-party encryption application. The
encrypted password is encrypted using RSA
with OAEP padding, and is Base64 encoded with
no newlines.

364

Chapter 9: Using Authentication Services

Section F: Netegrity SiteMinder
2.

To enable SSL for this realm and to have the BCAAA certificate verified, enter:
SGOS#(config siteminder realm_name) ssl enable
SGOS#(config siteminder realm_name) ssl-verify-agent enable

Configuring SiteMinder Servers
Once you create a SiteMinder realm, use the SiteMinder Servers page to create and edit the list of
SiteMinder policy servers consulted by the realm.
1.

Select Configuration>Authentication>Netegrity SiteMinder>SiteMinder Servers.

Figure 9-30: SiteMinder Servers Tab

2.

From the Realm Name drop-down list, select the SiteMinder realm for which you want to add
servers or change server properties.
Note:

3.

You must have defined at least one SiteMinder realm (using the SiteMinder Realms page)
before attempting to set SiteMinder policy server properties. If the message Realms must
be added in the SiteMinder Realms tab before editing this tab is displayed in
red Click Apply. Repeat the above steps for additional SiteMinder realms, up to a total of
40.

To create a new SiteMinder policy server, click New.
The Add List dialog displays.

365

Blue Coat ProxySG Configuration and Management Guide

Section F: Netegrity SiteMinder

Figure 9-31: SiteMinder Add List Item Dialog

4.

a.

Enter the name of the server in the dialog. This name is used only to identify the server in
the ProxySG Appliance’s configuration; it usually is the real hostname of the SiteMinder
policy server.

b.

Click OK.

To edit an existing SiteMinder policy server, click Edit.
The Edit dialog displays.

Figure 9-32: SiteMinder Edit Server Dialog

a.

Enter the IP address of the SiteMinder policy server in the IP address field.

b.

Enter the correct port number for the Authentication, Authorization, and Accounting ports. The
ports should be the same as the ports configured on their SiteMinder policy server. The
valid port range is 1-65535.

c.

The maximum number of connections is 32768; the default is 256.

d. The connection increment specifies how many connections to open at a time if more are
needed and the maximum is not exceeded. The default is 1.
e.

366

The timeout value has a default of 60 seconds, which can be changed.

5.

Click OK.

6.

Click Apply.

Chapter 9: Using Authentication Services

Section F: Netegrity SiteMinder
Editing SiteMinder Policy Servers through the CLI
To create and edit the SiteMinder policy server for the realm you just created, enter the following
commands:
Note:

The only required option is the IP address. The other options need only be used if you
want to change the defaults.

SGOS#(config) security siteminder edit-realm realm_name
SGOS#(config siteminder realm_name) siteminder-server create server_name
SGOS#(config siteminder realm_name) siteminder-server edit server_name
SGOS#(config siteminder realm_name server_name) ip-address ip_address
SGOS#(config siteminder realm_name server_name) authentication-port
port_number
SGOS#(config siteminder realm_name server_name) authorization-port
port_number
SGOS#(config siteminder realm_name server_name) accounting-port port_number
SGOS#(config siteminder realm_name server_name) connection-increment number
SGOS#(config siteminder realm_name server_name) max-connections number
SGOS#(config siteminder realm_name server_name) min-connections number
SGOS#(config siteminder realm_name server_name) timeout seconds

where:
siteminderserver

create server_name |
edit server_name |
delete

You can create a SiteMinder policy server, edit
it, or delete it.

edit
server_name

ip-address ip_address

The IP address of the SiteMinder policy server.

edit
server_name

authentication-port
port_number

The default is 44442. The ports should be the
same as the ports configured on the
SiteMinder policy server. The valid port range
is 1-65535.

edit
server_name

authorization-port
port_number

The default is 44443. The ports should be the
same as the ports configured on the
SiteMinder policy server. The valid port range
is 1-65535.

edit
server_name

accounting-port
port_number

The default is 44441. The ports should be the
same as the ports configured on the
SiteMinder policy server. The valid port range
is 1-65535.

edit
server_name

connection-increment
number

The default is 1. The connection increment
specifies how many connections to open at a
time if more are needed and the maximum is
not exceeded.

edit
server_name

max-connections number

The default is 256. The maximum number of
connections is 32768.

367

Blue Coat ProxySG Configuration and Management Guide

Section F: Netegrity SiteMinder
edit
server_name

min-connections number

The default is 1.

edit
server_name

timeout seconds

The default is 60.

To View the SiteMinder Policy Server Configuration:
SGOS#(config siteminder realm_name server_name) view
Server name:
test
IP address:
10.25.36.47
Min connections:
1
Max connections:
256
Connection inc:
1
Timeout:
60
Authentication Port: 44442
Authorization Port: 44443
Accounting Port:
44441

Defining SiteMinder Server General Properties
The SiteMinder Server General tab allows you to specify the protected resource name, the server mode,
and whether requests should always be redirected off box.
To Configure General Settings through the Management Console
1.

Select Configuration>Authentication>Netegrity SiteMinder>SiteMinder Server General.

Figure 9-33: SiteMinder Server General Tab

2.

368

From the Realm Name drop-down list, select the SiteMinder realm for which you want to change
properties.

Chapter 9: Using Authentication Services

Section F: Netegrity SiteMinder

Note:

You must have defined at least one SiteMinder realm (using the SiteMinder Realms tab)
before attempting to set SiteMinder general properties. If the message Realms must be
added in the SiteMinder Realms tab before editing this tab is displayed in red
at the bottom of this page, you do not currently have any SiteMinder realms defined.

3.

Enter the protected resource name. The protected resource name is the same as the resource name
on the SiteMinder policy server that has rules and policy defined for it.

4.

In the Server mode drop-down list, select either failover or round-robin. Failover mode falls back to
one of the other servers if the primary one is down. Round-robin modes specifies that all of the
servers should be used together in a round-robin approach. Failover is the default.
Note:

5.

The server mode describes the way the agent (BCAAA) interacts with the SiteMinder
policy server, not the way that ProxySG interacts with BCAAA.

To force authentication challenges to always be redirected to an off-box URL, select Always redirect
off-box.
Note:

All SiteMinder Web agents involved must have the setting EncryptAgentName=no in their
configurations to go off-box for any reason.

If using SiteMinder forms for authentication, the ProxySG always redirects the browser to the
forms URL for authentication. You can force this behavior for other SiteMinder schemes by
configuring the always redirect off-box property on the realm.
6.

If your Web applications need information from the SiteMinder policy server responses, you can
select Add Header Responses. Responses from the policy server obtained during authentication are
added to each request forwarded by the ProxySG. Header responses replace any existing header
of the same name; if no such header exists, the header is added. Cookie responses replace a cookie
header with the same cookie name; if no such cookie header exists, one is added.

7.

To enable validation of the client IP address, select Validate client IP address. If the client IP address
in the SSO cookie can be valid yet different from the current request client IP address, due to
downstream proxies or other devices, deselect Validate client IP address for the realm. SiteMinder
agents participating in SSO with the ProxySG should also be modified; set the TransientIPCheck
variable to yes to enable IP address validation and no to disable it.

8.

Click Apply.

369

Blue Coat ProxySG Configuration and Management Guide

Section F: Netegrity SiteMinder
To Configure General Settings through the CLI
At the (config) command prompt, enter the following commands to configure general server
settings:
SGOS#(config siteminder realm_name) protected-resource-name
protected_resource_name
SGOS#(config siteminder realm_name) server-mode {failover| round-robin}
(Optional) SGOS#(config siteminder realm_name) always-redirect-offbox {enable
| disable}
(Optional) SGOS#(config siteminder realm_name) add-header-responses {enable |
disable}
(Optional) SGOS#(config siteminder realm_name) validate-client-IP {disable |
enable}

where:
protected-resourcename

protected_resource_
name

The resource name on the SiteMinder
policy server that has rules and policy
defined for it.

server-mode

failover |
round-robin

Behavior of the server. Failover mode falls
back to one of the other servers if the
primary one is down. Round-robin modes
specifies that all of the servers should be
used together in a round-robin approach.
Failover is the default.

always-redirectoffbox

enable | disable

If using SiteMinder forms for
authentication, the ProxySG always
redirects the browser to the forms URL for
authentication. You can force this behavior
for other SiteMinder schemes by
configuring the always redirect off-box
property on the realm.
All agents involved must have the setting
EncryptAgentName=no in their
configurations to go off-box for any
reason.

add-header-responses

370

enable | disable

Enable if your Web applications need
information from the SiteMinder policy
server responses. Header responses
replace any existing header of the same
name; if no such header exists, the header
is added. Cookie responses replace a
cookie header with the same cookie name;
if no such cookie header exists, one is
added.

Chapter 9: Using Authentication Services

Section F: Netegrity SiteMinder
validate-client-IP

enable | disable

Enables validation of the client IP address.
If the client IP address in the SSO cookie
can be valid yet different from the current
request client IP address, due to
downstream proxies or other devices,
disable client IP validation. The
SiteMinder agents participating in SSO
with the ProxySG should also be
modified. Set the TransientIPCheck
variable to yes to enable IP validation and
no to disable it.

Configuring General Settings for SiteMinder
The SiteMinder General tab allows you to set a display name, cache credentials, timeout value, and
create a virtual URL.
To Manage General Settings for the SiteMinder realm
1.

Select Authentication>Netegrity SiteMinder>SiteMinder General.

Figure 9-34: SiteMinder General Page

2.

From the Realm Name drop-down list, select the SiteMinder realm for which you want to change
properties.
Note:

3.

You must have defined at least one SiteMinder realm (using the SiteMinder Realms tab)
before attempting to set SiteMinder general properties. If the message Realms must be
added in the SiteMinder Realms tab before editing this tab is displayed in red
at the bottom of this page, you do not currently have any SiteMinder realms defined.

If needed, change the SiteMinder realm display name. The default value for the display name is
the realm name. The display name cannot be longer than 128 characters and it cannot be null.

371

Blue Coat ProxySG Configuration and Management Guide

Section F: Netegrity SiteMinder
4.

Specify the length of time, in seconds, that user and administrator credentials received from the
SiteMinder policy server are cached. Credentials can be cached for up to 3932100 seconds. The
default cache-duration is 900 seconds (15 minutes).

5.

If you want group comparisons for SiteMinder groups to be case sensitive, select Case sensitive.

6.

The virtual hostname must be in the same cookie domain as the other servers participating in the
SSO. It cannot be an IP address or the default, www.cfauth.com.

7.

Click Apply.

To Set SiteMinder General Settings through the CLI
At the (config) command prompt, enter the following commands to configure general server
settings:
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config

siteminder
siteminder
siteminder
siteminder

realm_name)
realm_name)
realm_name)
realm_name)

cache-duration seconds
case-sensitive enable | disable
display-name name
virtual-url URL

where:
cache-duration

seconds

Specifies the length of time in seconds that user and
administrator credentials received from the SiteMinder policy
server are cached. Credentials can be cached for up to 3932100
seconds. The default value is 900 seconds (15 minutes).

case-sensitive

enable |
disable

Specifies whether the SiteMinder policy server is configured to
expect case-sensitive usernames and passwords.

display-name

name

Equivalent to the display-name option in the CPL authenticate
action. The default value for the display name is the realm name.
The display name cannot be longer than 128 characters and it
cannot be null.

virtual-url

URL

The URL to redirect to when the user needs to be challenged for
credentials. If the ProxySG is participating in SSO, the virtual
hostname must be in the same cookie domain as the other servers
participating in the SSO. It cannot be an IP address or the default,
www.cfauth.com.

Creating the CPL
You can create CPL policies now that you have completed SiteMinder realm configuration. Be aware
that the examples below are just part of a comprehensive authentication policy. By themselves, they
are not adequate for your purposes.
The examples below assume the default policy condition is allow. On new SGOS 4.x systems, the
default policy condition is deny.

372

Chapter 9: Using Authentication Services

Section F: Netegrity SiteMinder

Note:



Refer to the Blue Coat ProxySG Content Policy Language Guide for details about CPL and
how transactions trigger the evaluation of policy file and other layers.

Every SiteMinder-authenticated user is allowed access the ProxySG.

authenticate(SiteMinderRealm)



Group membership is the determining factor in granting access to the ProxySG.

authenticate(LDAPRealm)

group=”cn=proxyusers, ou=groups, o=myco”
deny

373

Blue Coat ProxySG Configuration and Management Guide

Section G: Oblix COREid

Section G: Oblix COREid
The ProxySG can be configured to consult an Oblix COREid (formerly known as Oblix NetPoint)
Access Server for authentication and session management decisions. This requires that a COREid
realm be configured on the ProxySG and policy written to use that realm for authentication.
The ProxySG supports authentication with Oblix COREid v6.5 and v7.0.
Access to the COREid Access System is done through the Blue Coat Authentication and Authorization
Agent (BCAAA), which must be installed on a Windows 2000 system or higher with access to the
COREid Access Servers.

Understanding COREid Interaction with Blue Coat
Within the COREid Access System, BCAAA acts as a custom AccessGate. It communicates with the
COREid Access Servers to authenticate the user and to obtain a COREid session token, authorization
actions, and group membership information.
HTTP header variables and cookies specified as authorization actions are returned to BCAAA and
forwarded to the ProxySG. They can (as an option) be included in requests forwarded by the ProxySG.
Within the ProxySG system, BCAAA acts as its agent to communicate with the COREid Access
Servers. The ProxySG provides the user information to be validated to BCAAA, and receives the
session token and other information from BCAAA.
Each ProxySG COREid realm used causes the creation of a BCAAA process on the Windows host
computer running BCAAA. When a process is created, a temporary working directory containing the
Oblix COREid files needed for configuration is created for that process. A single host computer can
support multiple ProxySG realms (from the same or different ProxySG Appliances); the number
depends on the capacity of the BCAAA host computer and the amount of activity in the realms.
Configuration of the ProxySG COREid realm must be coordinated with configuration of the Access
System. Each must be aware of the AccessGate. In addition, certain authorization actions must be
configured in the Access System so that BCAAA gets the information the ProxySG needs.

Configuring the COREid Access System
Note:

Blue Coat assumes you are familiar with the configuration of the COREid Access System
and WebGates.

Since BCAAA is an AccessGate in the COREid Access System, it must be configured in the Access
System just like any other AccessGate. BCAAA obtains its configuration from the ProxySG so
configuration of BCAAA on the host computer is not required. If the Cert Transport Security Mode is
used by the Access System, then the certificate files for the BCAAA AccessGate must reside on
BCAAA’s host computer.

374

Chapter 9: Using Authentication Services

Section G: Oblix COREid
COREid protects resources identified by URLs in policy domains. A ProxySG COREid realm is
associated with a single protected resource. This could be an already existing resource in the Access
System, (typical for a reverse proxy arrangement) or it could be a resource created specifically to
protect access to ProxySG services (typical for a forward proxy).
Important: The request URL is not sent to the Access System as the requested resource; the
requested resource is the entire ProxySG realm. Access control of individual URLs is
done on the ProxySG using policy.
The COREid policy domain that controls the protected resource must use one of the challenge
methods supported by the ProxySG.
Supported challenge methods are Basic, X.509 Certificates and Forms. Acquiring the credentials over
SSL is supported as well as challenge redirects to another server.
The ProxySG requires information about the authenticated user to be returned as COREid
authorization actions for the associated protected resource. Since authentication actions are not
returned when a session token is simply validated, the actions must be authorization and not
authentication actions.
The following authorization actions should be set for all three authorization types (Success, Failure,
and Inconclusive):


A HeaderVar action with the name BCSI_USERNAME and with the value corresponding to the
simple username of the authenticated user. For example, with an LDAP directory this might be
the value of the cn attribute or the uid attribute.



A HeaderVar action with the name BCSI_GROUPS and the value corresponding to the list of groups
to which the authenticated user belongs. For example, with an LDAP directory this might be the
value of the memberOf attribute.

Once the COREid AccessGate, authentication scheme, policy domain, rules, and actions have been
defined, the ProxySG can be configured.

Additional COREid Configuration Notes
The ProxySG Appliance's credential cache only caches the user's authentication information for the
lesser of the two values of the time-to-live (TTL) configured on the ProxySG and the session TTL
configured in the Access System for the AccessGate.

Configuring the ProxySG Realm
The ProxySG realm must be configured so that it can:


Communicate with the Blue Coat agent(s) that act on its behalf (hostname or IP address, port, SSL
options, and the like).



Provide BCAAA with the information necessary to allow it to identify itself as an AccessGate
(AccessGate id, shared secret).

375

Blue Coat ProxySG Configuration and Management Guide

Section G: Oblix COREid


Provide BCAAA with the information that allows it to contact the primary COREid Access Server
(IP address, port, connection information).



Provide BCAAA with the information that it needs to do authentication and collect authorization
information (protected resource name), and general options (off-box redirection).

For more information on configuring the ProxySG COREid realm, see "Creating a COREid Realm" on
page 377.
Note:

All ProxySG and agent configuration is done on the ProxySG. The ProxySG sends the
necessary information to BCAAA when it establishes communication.

Participating in a Single Sign-On (SSO) Scheme
The ProxySG can participate in SSO using the encrypted ObSSOCookie cookie. This cookie is set in the
browser by the first system in the domain that authenticates the user; other systems in the domain
obtain authentication information from the cookie and so do not have to challenge the user for
credentials. The ProxySG sets the ObSSOCookie cookie if it is the first system to authenticate a user,
and authenticates the user based on the cookie if the cookie is present.
Since the SSO information is carried in a cookie, the ProxySG must be in the same cookie domain as
the servers participating in SSO. This imposes restrictions on the authenticate.mode() used on the
ProxySG.


A reverse proxy can use any origin mode.



A forward proxy must use one of the origin-redirect modes (such as
origin-cookie-redirect). When using origin-*-redirect modes, the virtual URL's
hostname must be in the same cookie domain as the other systems. It cannot be an IP address; the
default www.cfauth.com does not work either.

When using origin-*-redirect, the SSO cookie is automatically set in an appropriate response after
the ProxySG authenticates the user. When using origin mode (in a reverse proxy), setting this cookie
must be explicitly specified by the administrator using the policy substitution variable
$(x-agent-sso-cookie). The variable $(x-agent-sso-cookie) expands to the appropriate value
of the set-cookie: header.

Avoiding ProxySG Challenges
In some COREid deployments all credential challenges are issued by a central authentication service.
Protected services do not challenge and process request credentials; instead, they work entirely with
the SSO token. If the request does not include an SSO token, or if the SSO token is not acceptable, the
request is redirected to the central service, where authentication occurs. Once authentication is
complete, the request is redirected to the original resource with a response that sets the SSO token.

376

Chapter 9: Using Authentication Services

Section G: Oblix COREid
If the COREid authentication scheme is configured to use a forms-based authentication, the ProxySG
redirects authentication requests to the form URL automatically. If the authentication scheme is not
using forms authentication but has specified a challenge redirect URL, the ProxySG only redirects the
request to the central service if always-redirect-offbox is enabled for the realm on the ProxySG. If
the always-redirect-offbox option is enabled, the authentication scheme must use forms
authentication or have a challenge redirect URL specified.
Note:

The ProxySG must not attempt to authenticate a request for the off-box authentication
URL. If necessary, authenticate(no) can be used in policy to prevent this.

Creating a COREid Realm
To Create a COREid Realm through the Management Console
1.

Select Configuration>Authentication>Oblix COREid>COREid Realms.

Figure 9-35: Creating a COREid Realm

2.

Click New; the Add COREid Realm dialog displays.

Figure 9-36: Adding the COREid Realm Name

3.

In the Realm name field, enter a realm name. The name can be 32 characters long and composed of
alphanumeric characters and underscores. The name must start with a letter. The name should be
meaningful to you, but it does not have to be the name of the COREid AccessGate.

377

Blue Coat ProxySG Configuration and Management Guide

Section G: Oblix COREid
4.

Click OK.

5.

Click Apply.

To Create a COREid Realm through the CLI
At the (config) prompt, enter the following command to create a COREid realm:
SGOS#(config) security coreid create-realm realm_name

where realm_name is the name of the COREid realm.

Configuring Agents
You must configure the COREid realm so that it can find the Blue Coat Authentication and
Authorization Agent (BCAAA).
1.

Select Configuration>Authentication>Oblix COREid>Agents.

Figure 9-37: Configuring COREid Agents

2.

Select the realm name to edit from the drop-down list.
Note:

378

You must have defined at least one COREid realm (using the COREid Realms tab) before
attempting to configure COREid agents. If the message Realms must be added in the COREid
Realms tab before editing this tab is displayed in red at the bottom of this page, you do not
currently have any COREid realms defined.

3.

In the Primary agent section, enter the hostname or IP address where the agent resides.

4.

Change the port from the default of 16101 if necessary.

5.

Enter the AccessGate ID in the AccessGate id field. The AccessGate ID is the ID of the AccessGate
as configured in the Access System.

Chapter 9: Using Authentication Services

Section G: Oblix COREid
6.

If an AccessGate password has been configured in the Access System, you must specify the
password on the ProxySG. Click Change Secret and enter the password. The passwords can be up
to 64 characters long and are always case sensitive.

7.

(Optional) Enter an alternate agent host and AccessGate ID in the Alternate agent section.

8.

(Optional) Select Enable SSL to enable SSL between the ProxySG and the BCAAA agent.

9.

(Optional) By default, if SSL is enabled, the COREid BCAAA certificate is verified. If you do not
want to verify the agent certificate, disable this setting.

To Edit a COREid Agent through the CLI
1.

To define the primary and alternate agent configuration for the realm you just created, enter the
following commands at the (config) prompt:
SGOS#(config) security coreid edit-realm realm_name
SGOS#(config coreid realm_name) primary-agent accessgate-id id
SGOS#(config coreid realm_name) primary-agent host host
SGOS#(config coreid realm_name) primary-agent port port
SGOS#(config coreid realm_name) primary-agent encrypted-secret
encrypted_shared_secret
-orSGOS#(config coreid realm_name) primary-agent secret shared_secret
SGOS#(config coreid realm_name) alternate-agent accessgate-id id
SGOS#(config coreid realm_name) alternate-agent host host
SGOS#(config coreid realm_name) alternate-agent port port
SGOS#(config coreid realm_name) alternate-agent encrypted-secret
encrypted_shared_secret
-orSGOS#(config coreid realm_name) alternate-agent secret shared_secret

where
These commands allow you to configure either the
primary or alternate agent for the COREid realm.

primary-agent |
alternate agent
accessgate-id

id

The ID of the AccessGate.

host

host

The hostname or the IP address of the system that
contains the agent.

port

port

The port where the agent listens.

encrypted-secret
| secret

shared_secret

The password (or encrypted password) associated
with the primary or alternate AccessGate. (Passwords
can be up to 64 characters long and are always case
sensitive.) The primary use of the encrypted-secret
command is to allow the ProxySG to reload a password
that it encrypted. You can choose to use a third-party
encryption application. The encrypted password is
encrypted using RSA with OAEP padding, and is
Base64 encoded with no newlines.

379

Blue Coat ProxySG Configuration and Management Guide

Section G: Oblix COREid
2.

To enable SSL between the ProxySG and the BCAAA agent and to have the BCAAA certificate
verified, enter:
SGOS#(config coreid realm_name) ssl enable
SGOS#(config coreid realm_name) ssl-verify-agent enable

Configuring the COREid Access Server
Once you create a COREid realm, use the COREid Access Server page to specify the primary Access
Server information.
1.

Select Configuration>Authentication>Oblix COREid>COREid Access Server.

Figure 9-38: Configuring the COREid Access Server

2.

Select the realm name to edit from the drop-down list.
Note:

380

You must have defined at least one COREid realm (using the COREid Realms tab) before
attempting to configure COREid agents. If the message Realms must be added in the COREid
Realms tab before editing this tab is displayed in red at the bottom of this page, you do not
currently have any COREid realms defined.

3.

Enter the protected resource name. The protected resource name is the same as the resource name
defined in the Access System policy domain.

4.

Select the Security Transport Mode for the AccessGate to use when communicating with the
Access System.

5.

If Simple or Cert mode is used, specify the Transport Pass Phrase configured in the Access System.
Click Change Transport Pass Phrase to set the pass phrase.

6.

If Cert mode is used, specify the location on the BCAAA host machine where the key, server and
CA chain certificates reside. The certificate files must be named aaa_key.pem, aaa_cert.pem, and
aaa_chain.pem, respectively.

Chapter 9: Using Authentication Services

Section G: Oblix COREid
7.

To force authentication challenges to always be redirected to an off-box URL, select Always redirect
off-box.

8.

To enable validation of the client IP address in SSO cookies, select Validate client IP address. If the
client IP address in the SSO cookie can be valid yet different from the current request client IP
address because of downstream proxies or other devices, then deselect the Validate client IP address
in the realm. Also modify the WebGates participating in SSO with the ProxySG. Modify the
WebGateStatic.lst file to either set the ipvalidation parameter to false or to add the downstream
proxy/device to the IPValidationExceptions lists.

9.

If your Web applications need information from the Authorization Actions, select Add Header
Responses. Authorization actions from the policy domain obtained during authentication are
added to each request forwarded by the ProxySG. Header responses replace any existing header
of the same name; if no such header exists, the header is added. Cookie responses replace a cookie
header with the same cookie name, if no such cookie header exists, one is added.

10. Specify the ID of the AccessGate’s primary Access Server.
11. Specify the hostname of the AccessGate’s primary Access Server.
12. Specify the port of the AccessGate’s primary Access Server.
13. Click Apply.
Editing COREid Access Server through the CLI
To create and edit the COREid Access Server configuration for the realm you just created, enter the
following commands:
SGOS#(config) security coreid edit-realm realm_name
SGOS#(config coreid realm_name) protected-resource-name resource name
SGOS#(config coreid realm_name) security-mode cert | open | simple
SGOS#(config coreid realm_name) transport-pass-phrase pass_phrase
-orSGOS#(config coreid realm_name) encrypted-transport-pass-phrase
encrypted_pass_phrase
SGOS#(config coreid realm_name) certificate-path certificate path
SGOS#(config coreid realm_name) always-redirect-offbox disable | enable
SGOS#(config coreid realm_name) validate-client-IP disable | enable
SGOS#(config coreid realm_name) add-header-responses disable | enable
SGOS#(config coreid realm_name) access-server-id id
SGOS#(config coreid realm_name) access-server-hostname hostname
SGOS#(config coreid realm_name) access-server-port port

where:
protected-resourcename

protected_resource_
name

The resource name defined in the
Access System policy domain.

security-mode

cert | open | simple

The Security Transport Mode for the
AccessGate to use when
communicating with the Access
System

381

Blue Coat ProxySG Configuration and Management Guide

Section G: Oblix COREid

382

If Simple or Cert mode is used, the
Transport pass phrase (or encrypted
pass phrase) configured in the Access
System.

transport-pass-phrase

pass_phrase

-or-

-or-

encrypted-transportpass-phrase

encrypted_pass_phrase

certificate-path

certificate_path

If Cert mode is used, the location on
the BCAAA host machine where the
key, server and CA chain certificates
reside. The certificate files must be
named aaa_key.pem,
aaa_cert.pem, and
aaa_chain.pem, respectively.

always-redirect-offbox

disable | enable

Forces authentication challenges to
always be redirected to an off-box
URL.

validate-client-IP

disable | enable

Enables validation of the client IP
address in SSO cookies. If the client IP
address in the SSO cookie can be valid
yet different from the current request
client IP address because of
downstream proxies or other devices,
then disable client IP address
validation. Also, modify the
WebGates participating in SSO with
the ProxySG. Modify the
WebGateStatic.lst file to either
set the ipvalidation parameter to false
or to add the downstream
proxy/device to the
IPValidationExceptions lists.

add-header-responses

disable | enable

When enabled, authorization actions
from the policy domain obtained
during authentication are added to
each request forwarded by the
ProxySG. Header responses replace
any existing header of the same name;
if no such header exists, the header is
added. Cookie responses replace a
cookie header with the same cookie
name; if no such cookie header exists,
one is added.

access-server-id

id

The ID of the primary Access Server.

access-server-hostname

hostname

The hostname of the primary Access
Server.

access-server-port

port

The port of the primary Access
Server.

Chapter 9: Using Authentication Services

Section G: Oblix COREid

Configuring the General COREid Settings
The COREid General tab allows you to set a display name, cache credentials timeout, request timeout
value, and case-sensitivity and create a virtual URL.
To Manage General Settings for the COREid Realm through the Management Console
1.

Select Authentication>Oblix COREid>COREid General.

Figure 9-39: Configuring COREid General Properties

2.

From the Realm Name drop-down list, select the COREid realm for which you want to change
properties.
Note:

You must have defined at least one COREid realm (using the COREid Realms tab) before
attempting to configure COREid agents. If the message Realms must be added in the COREid
Realms tab before editing this tab is displayed in red at the bottom of this page, you do not
currently have any COREid realms defined.

3.

If needed, change the COREid realm display name. The default value for the display name is the
realm name. The display name cannot be longer than 128 characters and it cannot be null.

4.

Specify the length of time, in seconds, to elapse before timeout if a response from BCAAA is not
received.

5.

Specify the length of time, in seconds, that user and administrator credentials are cached.
Credentials can be cached for up to 3932100 seconds. The default cache-duration is 900 seconds
(15 minutes).

6.

If you want username and group comparisons on the ProxySG to be case sensitive, select Case
sensitive.

7.

Specify the virtual URL to redirect the user to when they need to be challenged by the ProxySG. If
the ProxySG is participating in SSO, the virtual hostname must be in the same cookie domain as
the other servers participating in the SSO. It cannot be an IP address or the default,
www.cfauth.com.

383

Blue Coat ProxySG Configuration and Management Guide

Section G: Oblix COREid
8.

Click Apply.

To Set COREid General Settings through the CLI
At the (config) command prompt, enter the following commands to configure general settings:
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config

coreid
coreid
coreid
coreid
coreid

realm_name)
realm_name)
realm_name)
realm_name)
realm_name)

display-name name
timeout seconds
cache-duration seconds
case-sensitive disable | enable
virtual-url URL

where:
display-name

name

Equivalent to the display-name option in the CPL authenticate
action. The default value for the display name is the realm name.
The display name cannot be longer than 128 characters and it
cannot be null.

timeout

seconds

Specifies the length of time, in seconds, to elapse before timeout
if a response from BCAAA is not received.

cache-duration

seconds

Specifies the length of time in seconds that user and
administrator credentials received are cached. Credentials can be
cached for up to 3932100 seconds. The default value is 900
seconds (15 minutes).

case-sensitive

disable
| enable

Specifies whether the username and group comparisons on the
ProxySG should be case-sensitive.

virtual-url

URL

The URL to redirect to when the user needs to be challenged for
credentials. If the ProxySG is participating in SSO, the virtual
hostname must be in the same cookie domain as the other servers
participating in the SSO. It cannot be an IP address or the default,
www.cfauth.com.

Creating the CPL
You can create CPL policies now that you have completed COREid realm configuration. Be aware that
the examples below are just part of a comprehensive authentication policy. By themselves, they are not
adequate for your purposes.
The examples below assume the default policy condition is allow. On new SGOS 4.x systems, the
default policy condition is deny.
Note:



Refer to the Blue Coat ProxySG Content Policy Language Guide for details about CPL and
how transactions trigger the evaluation of policy file and other layers.

Every COREid-authenticated user is allowed access the ProxySG.

authenticate(COREidRealm)

384

Chapter 9: Using Authentication Services

Section G: Oblix COREid


Group membership is the determining factor in granting access to the ProxySG.

authenticate(COREidRealm)

group=”cn=proxyusers, ou=groups, o=myco”
deny

385

Blue Coat ProxySG Configuration and Management Guide

Section H: Policy Substitution Realm

Section H: Policy Substitution Realm
A Policy Substitution realm provides a mechanism for identifying and authorizing users based on
information in the request to the ProxySG. The realm uses information in the request and about the
client to identify the user. The realm is configured to construct user identity information by using
policy substitutions.
If authorization data (such as group membership) is needed, the realm can be configured with the
name of an associated authorization realm (such as LDAP or local). If an authorization realm is
configured, the fully-qualified username is sent to the authorization realm’s authority to collect
authorization data.
You can use policy substitutions 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. Be aware that if you use
Policy Substitution realms to provide granular policy on a user, it might not be very secure because
the information used to identify the user can be forged.
This section discusses the following topics:


"How Policy Substitution Realms Work"



"Creating a Policy Substitution Realm"



"Defining a Policy Substitution Realm"



"Defining Policy Substitution Realm General Properties"

How Policy Substitution Realms Work
The realm is configured the same way as other realms, except that the realm uses policy substitutions
to construct the username and full username from information available in and about the request.
Any policy substitution whose value is available at client logon can be used to provide information for
the name.
The Policy Substitution realm, in addition to allowing you to create and manipulate realm properties,
such as the name of the realm and the number of seconds that credential cache entries from this realm
are valid, also contains two other attributes:


386

A user field: A string containing policy substitutions that describes how to construct the simple
username.

Chapter 9: Using Authentication Services

Section H: Policy Substitution Realm


A full username field: A string containing policy substitutions that describes how to construct the
full username, which is used for authorization realm lookups. This can either be an LDAP FQDN
when the authorization realm is an LDAP realm, or a simple name when local realms are being
used for authorization.
Note:

Policy Substitution realms never challenge for credentials. If the username and full
username cannot be determined from the configured substitutions, authentication in the
Policy Substitution realm fails.

Remember that 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 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 Policy
Substitution realm users are not in any group, you do not have to specify an authorization realm.
Once the Policy Substitution realm is configured, you must create policy to authenticate the user.
Note:

If all the policy substitutions fail, authentication fails. If any policy substitution works,
authentication succeeds in the realm.

Example
The following is an example of how to use substitutions with Policy Substitution realms.
Assumptions:


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
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.

Results:
Under these circumstances, the following username and full username attributes might be used:


Username: $(netbios.messenger-username)@$(client.address).

This results in SUSIE.SMITH@10.25.36.47.


Full username: cn=$(netbios.messenger-username),cn=users,
dc=$(netbios.computer-domain),dc=company,dc=com.

387

Blue Coat ProxySG Configuration and Management Guide

Section H: Policy Substitution Realm
This results in cn=SUSIE.SMITH,cn=users, dc=AUTHTEAM,dc=company,dc=com.


Username: $(netbios.computer-domain)\$(netbios.messenger-username).

This results in AUTHTEAM\SUSIE.SMITH.


Username: $(client.host:label(6)).$(client.host:label(5)).

This results in SUSIE.SMITH.

Creating a Policy Substitution Realm
To Create a Policy Substitution Realm through the Management Console
1.

Select Configuration>Authentication>Policy Substitution>Policy Substitution Realms.

Figure 9-40: Policy Substitution Realms Tab

2.

Click New; the Add Policy Substitution Realm dialog displays.

Figure 9-41: Add Policy Substitution Realm Dialog

3.

In the Realm name field, enter a realm name. The name can be up to 32 characters long and
composed of alphanumeric characters and underscores. The name must start with a letter.

4.

Click OK; click Apply.

To Create a Policy Substitution Realm through the CLI
Up to 40 Policy Substitution realms can be configured per ProxySG.

388

Chapter 9: Using Authentication Services

Section H: Policy Substitution Realm
At the (config) command prompt, enter the following command to create a Policy Substitution
realm:
SGOS#(config) security policy-substitution create-realm realm_name

where realm_name is the name of the new Policy Substitution realm.

Defining a Policy Substitution Realm
You can define a Policy Substitution realm through either the Management Console or the CLI.
To Define Policy Substitution User Information through the Management Console
1.

Select Configuration>Authentication>Policy Substitution>User Information.

Figure 9-42: Policy Substitution User Information Tab

2.

From the Realm Name drop-down list, select the Policy Substitution realm for which you want to
change realm properties.
Note:

3.

You must have defined at least one Policy Substitution realm (using the Policy
Substitution Realms tab) before attempting to set Policy Substitution realm properties. If
the message Realms must be added in the Policy Substitutions Realms tab
before editing this tab is displayed in red at the bottom of this page, you do not
currently have any Policy Substitution realms defined.

(Optional) From the Authorization Realm Name drop-down list, select the realm you want to use to
authorize users.
Note:

Remember that Policy Substitution 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.

389

Blue Coat ProxySG Configuration and Management Guide

Section H: Policy Substitution Realm
4.

To construct usernames and full usernames, remember that the Username and Full username
attributes are character strings that contain policy substitutions. When authentication is required
for the transaction, these character strings are processed by the policy substitution mechanism,
using the current transaction as input. The resulting string becomes the user's identity for the
current transaction. For an overview of usernames and full usernames, see "How Policy
Substitution Realms Work" on page 386.

5.

Click Apply.

To Define Policy Substitution User Information through the CLI
From the (config) command prompt, enter the following commands:
SGOS#(config) security policy-substitution create-realm realm_name
SGOS#(config) security policy-substitution edit-realm realm_name
(Optional)SGOS#(config policy-substitution realm_name)
authorization-realm-name realm_name
SGOS#(config policy-substitution realm_name) username policy
SGOS#(config policy-substitution realm_name) full-username policy

where
edit-realm

realm_name

The name of the realm you want to edit. This
command puts you in the edit submode.

authorization-realmname

realm_name

This option is only required if you are
associating an authorization realm with the
Policy Substitution realm.

username

construction_
rule

The username as created through policy
substitutions. The construction rule is made up
any of the substitutions whose values are
available at client logon, listed in Appendix D,
“CPL Substitutions,” in the Blue Coat ProxySG
Content Policy Language Guide.
Note: The username and full-username
attributes are character strings that contain
policy substitutions. When authentication is
required for the transaction, these character
strings are processed by the policy
substitution mechanism, using the current
transaction as input. The resulting string is
stored in the user object in the transaction,
and becomes the user’s identity.
To create usernames for various uses in Policy
Substitution realms, see the Blue Coat ProxySG
Content Policy Language Guide.

390

Chapter 9: Using Authentication Services

Section H: Policy Substitution Realm
full-username

construction_
rule

The username as created through policy
substitutions. The full username is only
required if you are using an authorization
realm. The construction rule is made up any of
the policy substitutions whose values are
available at client logon listed in Appendix D,
“CPL Substitutions,” in the Blue Coat ProxySG
Content Policy Language Guide.
Note: The username and full-username
attributes are character strings that contain
policy substitutions. When authentication is
required for the transaction, these character
strings are processed by the policy
substitution mechanism, using the current
transaction as input. The resulting string is
stored in the user object in the transaction,
and becomes the user’s identity.
To create full usernames for the various uses of
Policy Substitution realms, see the Blue Coat
ProxySG Content Policy Language Guide.

Defining Policy Substitution Realm General Properties
The Policy Substitution General tab allows you to specify the display name and a virtual URL.
To Configure Policy Substitution Realm General Settings through the Management Console
1.

Select Configuration>Authentication>Policy Substitution>General.

Figure 9-43: Policy Substitution General Tab

2.

From the Realm name drop-down list, select the Policy Substitution realm for which to change
properties.

391

Blue Coat ProxySG Configuration and Management Guide

Section H: Policy Substitution Realm

Note:

You must have defined at least one Policy Substitution realm (using the Policy
Substitution Realms tab) before attempting to set Policy Substitution general properties. If
the message Realms must be added in the Policy Substitution Realms tab
before editing this tab is displayed in red at the bottom of this page, you do not
currently have any Policy Substitution realms defined.

3.

Specify the length of time, in seconds, that user and administrator credentials are cached.
Credentials can be cached for up to 3932100 seconds. The default cache-duration is 900 seconds
(15 minutes).

4.

You can specify a virtual URL. For more information on the virtual URL, see “Understanding
Origin-Style Redirection” on page 285.

5.

Click Apply.

To Configure Policy Substitution Realm General Settings through the CLI
1.

Enter the following commands to modify Policy Substitution realm properties:
SGOS#(config) security policy-substitution edit-realm realm_name
SGOS#(config policy-substitution realm_name) cache-duration seconds
SGOS#(config policy-substitution realm_name) virtual-url URL

where:

2.

cache-duration

seconds

The number of seconds that user and administrator
credentials received from the Policy Substitution realm
should be cached. The default is 900 seconds (15 minutes).

virtual-url

URL

The authentication virtual URL for this Policy Substitution
realm.

(Optional) View the results:
SGOS#(config Policy Substitution realm_name) view
Realm name: PS_1
Username:
$(netbios.messenger-user-name)
Full username:
cn=$(netbios.messenger-user-name),cn=users,
dc=$(netbios.computer-domain)
Authorization realm:
LDAP_1
Cache duration:
600
Virtual URL:

Tips and Boundary Conditions


Following is an example of how to configure three different types of Policy Substitution realms.
For a list of available substitutions, see "Fields Available for Creating Access Log Formats" on
page 926.


392

Identity to be determined by sending a NetBIOS over TCP/IP query to the client computer,
and using LDAP authorization

Chapter 9: Using Authentication Services

Section H: Policy Substitution Realm
SGOS#(config) security policy-substitution create-realm netbios
SGOS#(config) security policy-substitution edit-realm netbios
SGOS#(config policy-substitution netbios) username \
$(netbios.messenger-username)
SGOS#(config policy-substitution netbios) full-username \
cn=$(netbios.messenger-username),cn=users,dc=company,dc=com
SGOS#(config policy-substitution netbios) authorization-realm-name ldap



Identity to be determined by reverse DNS, using local authorization. Blue Coat assumes login
scripts on the client computer update the DNS record for the client.
SGOS#(config) security policy-substitution create-realm RDNS
SGOS#(config) security policy-substitution edit-realm RDNS
SGOS#(config policy-substitution RDNS) username \
$(client.host:label(5)).$(client.host:label(6))
#SGOS#(config policy-substitution RDNS) full-username \
$(client.host:label(5)).$(client.host:label(6))
SGOS#(config policy-substitution RDNS) authorization-realm-name local



Identity to be determined by a header in the request, using LDAP authorization.
SGOS#(config) security policy-substitution create-realm header
SGOS#(config) security policy-substitution edit-realm header
SGOS#(config policy-substitution header) username \
$(request.x_header.username)
SGOS#(config policy-substitution header) full-username \
cn=$(request.x_header.username),cn=users,dc=company,dc=com
SGOS#(config policy-substitution header) username \
authorization-realm-name ldap



If you need to change the NetBIOS defaults of 5 seconds and 3 retries, you can use the nbstat
requester option from the netbios command submode. (For more information on using the
NetBIOS commands, refer to the Blue Coat ProxySG Command Line Reference.)

Creating the Policy Substitution Policy
When you complete Policy Substitution realm configuration, you must create CPL policies for the
policy-substitution realm to be used. Be aware that the example below is just part of a comprehensive
authentication policy. By themselves, they are not adequate.
Note:

Refer to the Blue Coat ProxySG Content Policy Language Guide for details about CPL and
how transactions trigger the evaluation of policy file and other layers.

Be aware that the default policy condition for this example is allow. On new SGOS 4.x systems, the
default policy condition is deny.
Note:


The Policy Substitution realm cannot be used in an layer.

Every Policy Substitution realm authenticated user is allowed to access the ProxySG.

393

Blue Coat ProxySG Configuration and Management Guide

Section H: Policy Substitution Realm

authenticate(PolicySubstitutionRealm)

394

Chapter 9: Using Authentication Services

Section I: Sequence Realm Authentication

Section I: Sequence Realm Authentication
Once a realm is configured, you can associate it with other realms to allow Blue Coat to search for the
proper authentication credentials for a specific user. That is, if the credentials are not acceptable to the
first realm, they are sent to the second, and so on until a match is found or all the realms are
exhausted. This is called sequencing.
This section discusses the following topics:


"Adding Realms to a Sequence Realm"



"Creating a Sequence Realm"

Adding Realms to a Sequence Realm
Keep in mind the following rules for using realm sequences:


Ensure the realms to be added to the sequence are customized to your needs. Check each realm to
be sure that the current values are correct. For NTLM, verify that the Allow Basic Credentials
checkbox is set correctly.



All realms in the realm sequence must exist and cannot be deleted or renamed while the realm
sequence references them.



NTLM caveats:


Only one NTLM realm is allowed in a realm sequence.



If an NTLM realm is in a realm sequence, it must be either the first or last realm in the list.



If an NTLM realm is in a realm sequence and the NTLM realm does not support Basic
credentials, the realm must be the first realm in the sequence and try NTLM authentication once
must be enabled.



Multiple BASIC realms are allowed.



Connection-based realms, such as Certificate, are not allowed in the realm sequence.



A realm can only exist once in a particular realm sequence.



A realm sequence cannot have another realm sequence as a member.



If a realm is down, an exception page is returned. Authentication is not tried against the other
later realms in the sequence.

Creating a Sequence Realm
To Create a Sequence Realm through the Management Console
1.

Select Configuration>Authentication>Sequences>Sequence Realms.

395

Blue Coat ProxySG Configuration and Management Guide

Section I: Sequence Realm Authentication

Figure 9-44: Sequence Realms Tab

2.

Click New; the Add Sequence Realm dialog displays.

Figure 9-45: Add Sequence Realm

3.

In the Realm name, enter a realm name. The name can be 32 characters long and composed of
alphanumeric characters and underscores. The name must start with a letter.

4.

Click OK.

5.

Click Apply.

To Create a Sequence Realm through the CLI
Up to 40 Sequence realms can be configured per ProxySG.
At the (config) command prompt, enter the following command to create a Sequence realm:
SGOS#(config) security sequence create-realm realm_name

where realm_name is the name of the new Sequence realm.

Adding Realms to a Sequence Realm
To Add Realms to a Sequence Realm through the Management Console
1.

396

Select Configuration>Authentication>Sequences>Sequence Main.

Chapter 9: Using Authentication Services

Section I: Sequence Realm Authentication
The Sequences tab displays with the Sequence realm that you want to add realms to.
Note:

You must have defined at least one sequence realm (using the Sequence Realms tab)
before attempting to set Sequence general properties. If the message Realms must be
added in the Sequence Realms tab before editing this tab is displayed in red at
the bottom of this page, you do not currently have any Sequence realms defined.

Figure 9-46: Sequence Main Tab

2.

Click New to add an existing realm to the realm sequence from the drop-down list. Remember that
each realm can be used only once in a realm sequence.

Figure 9-47: Add Member Realm

3.

From the drop-down list, select the Sequence realm you wanted added to the realm sequence.

4.

Click OK.
You are returned to the main Sequences menu.

5.

Click Apply.

6.

Repeat from step 2 until you have added all necessary realms.

7.

To change the order that the realms are checked, use the promote/demote buttons. When you add
an NTLM realm, it is placed first in the list and you can allow the realm sequence to try NTLM
authentication only once. If you demote the NTLM entry, it becomes last in the sequence and the
default of checking NTLM multiple times is enabled.

397

Blue Coat ProxySG Configuration and Management Guide

Section I: Sequence Realm Authentication
8.

Click Apply.

To Add Authentication Realms to a Sequence Realm through the CLI
1.

From the (config) prompt, add existing realms to the new specified sequence realm name:
SGOS#(config) security sequence edit-realm realm_sequence_name
SGOS#(config sequence realm_sequence_name) realm add realm_name

2.

Repeat the realm add realm_name command until all necessary realms have been added.

3.

(Optional) Give the new sequence realm a display name. The default value for the display name is
the realm name. The display name cannot be longer than 128 characters and it cannot be null.
SGOS#(config sequence realm_sequence_name) display-name display_name

Defining Sequence Realm General Properties
The Sequence General tab allows you to specify the display name and a virtual URL.
1.

Select Configuration>Authentication>Sequences>Sequence General.

Figure 9-48: Sequence General Tab

2.

From the Realm name drop-down list, select the Sequence realm for which you want to change
properties.
Note:

398

You must have defined at least one sequence realm (using the Sequence Realms tab)
before attempting to set Sequence general properties. If the message Realms must be
added in the Sequence Realms tab before editing this tab is displayed in red at
the bottom of this page, you do not currently have any Sequence realms defined.

3.

If needed, change the Sequence realm display name. The default value for the display name is the
realm name. The display name cannot be longer than 128 characters and it cannot be null.

4.

You can specify a virtual URL based on the individual realm sequence. For more information on
the virtual URL, see “Understanding Origin-Style Redirection” on page 285.

Chapter 9: Using Authentication Services

Section I: Sequence Realm Authentication
5.

Click Apply.

To Manage Authentication Realms in a Sequence Realm through the CLI
1.

When you add an NTLM realm it is placed first in the list, and you have the option of allowing the
realm sequence to try NTLM authentication only once. If you demote the NTLM entry, it becomes last
in the sequence and the default of checking NTLM multiple times is enabled.
SGOS#(config sequence realm_sequence_name) ntlm-only-once-enable
% An NTLM realm must be the first member of the realm sequence before
specifying to try NTLM authentication only once
SGOS#(config sequence realm_sequence_name) realm promote ntlm1
SGOS#(config sequence realm_sequence_name) ntlm-only-once-enable

2.

(Optional) You can specify a virtual URL based on the individual realm sequence. For information
on the virtual URL, see “Understanding Origin-Style Redirection” on page 285.
SGOS#(config sequence realm_sequence_name) virtual-url 10.25.36.47
ok

3.

View the configuration.
a.

To view the configuration of the current realm sequence, remain in the submode and
enter:
SGOS#(config sequence realm_sequence_name) view
Realm name:
seq1
Display name:seq1
Virtual URL:
10.25.36.47
Try NTLM only once:
yes
Member realms:
ntlm1
radius1
test
ldap1

b.

To view the configurations of all realm-sequence-names, exit the edit-realm submode,
and enter:
SGOS#(config sequence realm_sequence_name) exit
SGOS#(config) security sequence view
Realm name:
seq1
Display name:seq1
Virtual URL:
10.25.36.47
Try NTLM only once:
yes
Member realms:
ntlm1
radius1
test
ldap1
Realm name:
seq2
Virtual URL:
Try NTLM only once:
no
Member realms:
ldap1
ldap2

399

Blue Coat ProxySG Configuration and Management Guide

Section I: Sequence Realm Authentication

Tips


Explicit Proxy involving a sequence realm configured with an NTLM realm and a substitution
realm.
Internet Explorer (IE) automatically sends Windows credentials in the Proxy-Authorization:
header when the ProxySG issues a challenge for NTLM. The prompt for username/password
appears only if NTLM authentication fails. However, in the case of a sequence realm configured
with an NTLM realm and a substitution realm, the client is authenticated as a guest in the policy
substitution realm, and the prompt allowing the user to correct the NTLM credentials never
appears.



Transparent Proxy setup involving a sequence realm configured with an NTLM realm and a
substitution realm.
The only way the ProxySG can differentiate between a domain and non-domain user is though
the NTLM credentials provided during the authentication challenge.
IE does not offer Windows credentials in the Proxy-Authorization: header when the Proxy issues
a challenge for NTLM unless the browser is configured to do so. In this case, the behavior is the
same as for explicit proxy.
If IE is not configured to offer Windows credentials, the browser issues a prompt for
username/password, allowing non-domain users to be authenticated as guests in the policy
substitution realm by entering worthless credentials.

400

Chapter 9: Using Authentication Services

Section J: Forms-Based Authentication

Section J: Forms-Based Authentication
You can use forms-based authentication exceptions to control what your users see during
authentication. You can:


Specify the realm the user is to authenticate against.



Specify that the credentials requested are for the ProxySG. This avoids confusion with other
authentication challenges.



Make the form comply with company standards and provide other information, such as a help
link.

The authentication form (an HTML document) is served when the user makes a request and requires
forms-based authentication. If the user successfully authenticates to the ProxySG, the ProxySG
redirects the user back to the original request.
If the user does not successfully authenticate against the ProxySG and the error is user-correctable, the
user is presented with the authentication form again.
Note:

You can configure and install the authentication form and several properties through the
Management Console and the CLI, but you must use policy to dictate the authentication
form’s use.

With forms-based authenticating, you can set limits on the maximum request size to store and define
the request object expiry time. You can also specify whether to verify the client’s IP address against the
original request and whether to allow redirects to the original request.
To create and put into use forms-based authentication, you must complete the following steps:


Create a new form or edit the existing authentication form exception



Set storage options



Set CPL policies

Understanding Authentication Forms
You can customize the default authentication form exception or you can use it as a template to create
other authentication forms. (You can create as many authentication form exceptions as needed. The
form must be a valid HTML document that contains valid form syntax.)
The default authentication form contains the following:


Title and sentence instructing the user to enter ProxySG credentials for the appropriate realm.



Domain: Text input with maximum length of 64 characters The name of the input must be
PROXY_SG_DOMAIN, and you can specify a default value of $(x-cs-auth-domain) so that the
user's domain is prepopulated on subsequent attempts (after a failure).
The input field is optional, used only if the authentication realm is an NTLM realm. If it is used,
the value is prepended to the username value with a backslash.

401

Blue Coat ProxySG Configuration and Management Guide

Section J: Forms-Based Authentication


Username: Text input with maximum length of 64 characters. The name of the input must be
PROXY_SG_USERNAME, and you can specify a default value of $(cs-username) so the username is
prepopulated on subsequent attempts (after a failure).



Password: The password should be of type PASSWORD with a maximum length of 64 characters.
The name of the input must be PROXY_SG_PASSWORD.



Request ID: If the request contains a body, then the request is stored on the ProxySG until the user
is successfully authenticated.
The request ID should be of type HIDDEN. The input name must be PROXY_SG_REQUEST_ID, and
the value must be $(x-cs-auth-request-id). The information to identify the stored request is
saved in the request id variable.



Submit button. The submit button is required to submit the form to the ProxySG.



Clear form button.The clear button is optional and resets all form values to their original values.



Form action URI: The value is the authentication virtual URL plus the query string containing the
base64 encoded original URL $(x-cs-auth-form-action-url).



Form METHOD of POST. The form method must be POST. The ProxySG does not process forms
submitted with GET.

The ProxySG only parses the following input fields during form submission:


PROXY_SG_USERNAME (required)



PROXY_SG_PASSWORD (required)



PROXY_SG_REQUEST_ID (required)



PROXY_SG_DOMAIN. (optional) If specified, its value is prepended to the username and separated

with a backslash.
The default authentication form looks similar to the following:


Enter Proxy Credentials for Realm $(cs-realm)


Enter Proxy Credentials for Realm $(cs-realm)

Reason for challenge: $(exception.last_error)



$(x-cs-auth-form-domain-field)

Username: VALUE=$(cs-username)>


Password: MAXLENGTH="64">




402

Chapter 9: Using Authentication Services

Section J: Forms-Based Authentication



$(exception.contact)



If the realm is an NTLM realm, the $(x-cs-auth-form-domain-field) substitution expands to:

Domain: VALUE=$(x-cs-auth-domain)>

If you specify $(x-cs-auth-form-domain-field), you do not need to explicitly add the domain
input field.

User/Realm CPL Substitutions for Authentication Forms
CPL user/realm substitutions that are common in authentication form exceptions are listed below.
The syntax for a CPL substitution is:
$(CPL_substitution)
group

user-name

x-cs-auth-request-id

groups

user.x509.issuer

x-cs-auth-domain

realm

user.x509.serialNumber

x-cs-auth-form-domain-field

user

user.x509.subject

x-cs-auth-form-action-url

cs-realm

x-cs-auth-request-id

Note:

Any substitutions that are valid in CPL and in other exceptions are valid in authentication
form exceptions.

For a discussion of using CPL and a complete list of CPL substitutions, as well as a description of each
substitution, refer to the Blue Coat ProxySG Content Policy Language Guide.

Tip
There is no realm restriction on the number of authentication form exceptions you can create. You can
have an unlimited number of forms, although you might want to make them as generic as possible to
cut down on maintenance.

Creating and Editing an Authentication Form
You can create a new authentication form or you can edit the existing one. If you create a new form,
the new form uses the default authentication form as a template. If you edit the default form, all forms
created after that contain the modification.

403

Blue Coat ProxySG Configuration and Management Guide

Section J: Forms-Based Authentication
To Create or Edit an Authentication Form through the Management Console
1.

Select Configuration>Authentication>Forms.

Figure 9-49: Authentication Forms

Click Edit to edit the default authentication form; click New to create a new authentication form
based on the existing default settings.
2.

If you click New, the Add Authentication Form dialog displays.

Figure 9-50: Authentication Form Dialog

3.

Enter the form name. Click OK.

4.

If you highlight the form you want to edit and click Edit, the Edit Authentication dialog displays.

Figure 9-51: Edit Authentication Form Dialog

5.

From the drop-down list, select the method to use to install the authentication form; click Install.


404

Remote URL:

Chapter 9: Using Authentication Services

Section J: Forms-Based Authentication
Enter the fully-qualified URL, including the filename, where the authentication form is
located. To view the file before installing it, click View. Click Install. To view the results, click
Results; to close the dialog when through, click OK.

Figure 9-52: Specifying the Remote Location of an Authentication Form



Local File:
Click Browse to bring up the Local File Browse window. Browse for the file on the local
system. Open it and click Install. When the installation is complete, a results window opens.
View the results; to close the window, click Close.

Figure 9-53: Specifying the Local Location of an Authentication Form



Text Editor:

405

Blue Coat ProxySG Configuration and Management Guide

Section J: Forms-Based Authentication
The current authentication form is displayed in the text editor. You can edit the form in place.
Click Install to install the form. When the installation is complete, a results window opens.
View the results; to close the window, click Close.

Figure 9-54: Using the ProxySG Text Editor

To Create an Authentication Form through the CLI
Remember that if you create a new form, the new form uses the default authentication form as a
template. If you edit the default form, all forms created after that will also have the modification.
To create a new form, enter the following command from the (config) prompt:
SGOS#(config) security authentication-form create form_name
ok

To view the authentication forms on the system, enter the following command:
SGOS#(config) show security authentication-form
Authentication forms:
authentication_form
authentication_test

To Edit an Authentication Form through the CLI
You cannot edit an authentication form in place through the CLI. You can replace a form though using
either remote download or through the ProxySG Appliance’s inline commands.

406

Chapter 9: Using Authentication Services

Section J: Forms-Based Authentication
To Edit an Authentication Form using Inline Commands:
SGOS#(config) security authentication-form inline form_name
end-of-file_marker
-orSGOS# inline authentication-form form_name end-of-file_marker

Remember that any form you modify must contain the username, password and request ID. A form
that is missing these values results in the user receiving an error page when the authentication form is
submitted. For more information on required fields in a new authentication form, see "Understanding
Authentication Forms" on page 401.
Note:

You can also import the entire set of forms through the inline authentication-forms
command.

Notes on using inline commands:


If you make a mistake on the current line of the script you are typing, you can backspace to correct
the problem.



If you notice a mistake on a previous line, you must quit the script (by using ) and start
over.



The inline script overwrites the existing template.

To Create and Download an Authentication Form using a Text Editor:
1.

Create the authentication form as a text file.

2.

Place the form on a server that is accessible to the ProxySG.

3.

Enter the following commands to give the ProxySG the file’s location and to download the file:
SGOS#(config) security authentication-form path [form_name] path
SGOS#(config) security authentication-form load form_name
-orSGOS#load authentication-form form_name

Note:

You can also download the entire set of forms through the security
authentication-form path and load authentication-forms commands.

To Delete an Authentication Form
From the (config) prompt, enter the following commands:
SGOS#(config) security authentication-form delete form_name

Setting Storage Options
When a request requiring the user to be challenged with a form contains a body, the request is stored
on the ProxySG while the user is being authenticated. Storage options include:


the maximum request size

407

Blue Coat ProxySG Configuration and Management Guide

Section J: Forms-Based Authentication


the expiration of the request



whether to verify the IP address of the client requesting against the original request



whether to allow redirects from the origin server

The storage options are global, applying to all form exceptions you use.
The global allow redirects configuration option can be overridden on a finer granularity in policy
using the authenticate.redirect_stored_requests(yes|no) action.
To Set Storage Options through the Management Console
1.

Select Configuration>Authentication>Request Storage.

Figure 9-55: Request Storage Tab

2.

In the Maximum request size to store (Megabytes) field, enter the maximum POST request size
allowed during authentication. The default is 50 megabytes.

3.

In the Request object expiry time (seconds) field, enter the amount of time before the stored request
expires. The default is 300 seconds (five minutes). The expiry time should be long enough for the
user to fill out and submit the authentication form.

4.

If you do not want the ProxySG to Verify the IP address against the original request, deselect that
option. The default is to verify the IP address.

5.

To Allow redirects from the origin servers, select the checkbox. The default is to not allow redirects
from origin servers.
Note:

408

During authentication, the user's POST is redirected to a GET request. The client therefore
automatically follows redirects from the origin server. Because the ProxySG is converting
the GET to a POST and adding the post data to the request before contacting the origin
server, the administrator must explicitly specify that redirects to these POSTs requests can
be automatically followed.

Chapter 9: Using Authentication Services

Section J: Forms-Based Authentication
6.

Click Apply.

To Set Storage Options through the CLI
From the (config) prompt, enter the following commands to select storage options:
SGOS#(config)
SGOS#(config)
SGOS#(config)
SGOS#(config)

security
security
security
security

request-storage
request-storage
request-storage
request-storage

max-size megabytes
expiry-time seconds
verify-ip enable | disable
allow-redirects enable | disable

where
max-size

megabytes

Sets the maximum POST request size during
authentication. The default is 50 megabytes.

expiry-time

seconds

Sets the amount of time before the stored request
expires. The default is 300 seconds (five minutes)

verify-ip

enable | disable

Enables or disables the verify-ip option. The
default is to enable the ProxySG to verify the IP
address against the original request.

allow-redirects

enable | disable

Specifies whether to allow redirects. The default is
disable.

Using CPL with Forms-Based Authentication
To use forms-based authentication, you must create policies that enable it and also control which form
is used in which situations. A form must exist before it can be referenced in policy.


Which form to use during authentication is specified in policy using the CPL condition
authenticate.form(form_name).
Note:



The authenticate.form(form.name) condition can be used with the form
authentication modes only. If no form is specified the form defaults to
authentication_form.

Using the authentication.mode( ) property selects a combination of challenge type and
surrogate credentials. The authentication.mode( ) property offers several options specifically
for forms-based authentication:


Form-IP—The user’s IP address is used as a surrogate credential. The form is presented

whenever the user’s credential cache entry expires.


Form-Cookie—Cookies are used as surrogate 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—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.

409

Blue Coat ProxySG Configuration and Management Guide

Section J: Forms-Based Authentication


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.



If you authenticate users who have third-party cookies explicitly disabled, you can use the
authenticate.use_url_cookie( ) property.



Since the authentication.mode( ) property is defined as a form mode (above) in policy, you do
not need to adjust the default authenticate mode through the CLI.



Using the authenticate.redirect_stored_requests(yes|no) action allows granularity in
policy over the global allow redirect config option.

For information on using these CPL conditions and properties, refer to the Blue Coat ProxySG Content
Policy Language Guide.

Tips and Boundary Conditions


If the user is supposed to be challenged with a form on a request for an image or video, the
ProxySG returns a 403 error page instead of the form. If the reason for the challenge is that the
user's credentials have expired and the object is from the same domain as the container page, then
reloading the container page results in the user receiving the authentication form and being able
to authenticate. However, if the client browser loads the container page using an existing
authenticated connection, the user might still not receive the authentication form.
Closing and reopening the browser should fix the issue. Requesting a different site might also
cause the browser to open a new connection and the user is returned the authentication form.
If the container page and embedded objects have a different domain though and the
authentication mode is form-cookie, reloading or closing and reopening the browser might not fix
the issue, as the user is never returned a cookie for the domain the object belongs to. In these
scenarios, Blue Coat recommends that policy be written to either bypass authentication for that
domain or to use a different authentication mode such as form-cookie-redirect for that domain.

410



Forms-based authentication works with HTTP browsers only.



Because forms only support BASIC authentication, authentication-form exceptions cannot be
used with a Certificate realm, a Policy Substitution realm, or with an NTLM realm that allows
only NTLM credentials. If a form is in use and the authentication realm is a NTLM credentials, a
Policy Substitution realm, or a Certificate realm, the user receives a configuration error.



User credentials are sent in plain text. However, they can be sent securely using SSL if the virtual
URL is HTTPS.



Because not all user requests support forms (such as WebDAV and streaming), create policy to
bypass authentication or use a different authentication mode with the same realm for those
requests.

Chapter 9: Using Authentication Services

Section K: Managing the Credential Cache
When you have configured all your realms, you can view your realms and manage the credentials
cache for a specific realm.
To Manage the Credential Cache through the Management Console
1.

Select to Configuration>Authentication>Realms.
The Realms page displays, with all realms that you have created.

Figure 9-56: Viewing All Realms on the ProxySG

2.

To manage the credential cache:


To purge the credentials cache when you make policy changes, select Flush When Policy File
Changes (this option is selected by default).



To flush the entire credentials cache immediately, click Flush and confirm.



To flush only the entries for a particular realm in the credentials cache, select the realm from
the drop-down list, click Flush Realm confirm.

All of these actions force users to be re-authenticated.
3.

Click Apply.

To Manage the Credential Cache through the CLI
From the (config) command prompt, enter the following command:
SGOS#(config) security flush-credentials [on-policy-change {enable |
disable} | realm realm]

where:
Press the key to flush the credential cache
now.



on-policy-change

enable | disable

Flush the cache only if the policy changes.

realm

realm

Flush the credential cache for the specified realm.

411

Blue Coat ProxySG Configuration and Management Guide

Limitations


For all realms except NTLM, SiteMinder, and COREid, the maximum number of entries stored in
the credential cache is 80,000.
For NTLM, SiteMinder, and COREid authentication, the maximum number of entries stored in
the credential cache is dependent on the system. You can have at least 2500 entries but potentially
more depending on the system resources.



412

XFTP users are not prompted for proxy authentication if the credentials are in the cache and the
credentials have not expired.

Chapter 10:Bandwidth Management

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. Network
resource sharing (or link sharing) is done using a bandwidth-management hierarchy where multiple
traffic classes share available bandwidth in a controlled manner.
Note:

The ProxySG does not try to reserve any bandwidth on the network links that it is
attached to or otherwise guarantee that the available bandwidth on the network can
sustain any of the bandwidth limits which have been configured on it. The ProxySG can
only shape the various traffic flows passing through it, and prioritize some flows over
others according to its configuration.

By managing the bandwidth of specified classes of network traffic, you can do the following:


Guarantee that certain traffic classes receive a specified minimum amount of available bandwidth.



Limit certain traffic classes to a specified maximum amount of bandwidth.



Prioritize certain traffic classes to determine which classes have priority over available bandwidth.

Bandwidth Management Terms
Some of the terms used in this document are described below.


Bandwidth Class: A defined unit of bandwidth allocation. An administrator uses bandwidth
classes to allocate bandwidth to a particular type of traffic flowing through the ProxySG.



Bandwidth Class Hierarchy: Bandwidth classes can be grouped together in a class hierarchy,
which is a tree structure that specifies the relationship among different classes. You create a
hierarchy by creating at least one parent class and assigning other classes to be its children.



Bandwidth Policy: The set of rules that you define in the policy layer to identify and classify the
traffic in the ProxySG, using the bandwidth classes that you create. You must use policy (through
either VPM or CPL) in order to manage bandwidth.



Child Class: The child of a parent class is dependent upon that parent class for available
bandwidth (they share the bandwidth in proportion to their minimum/maximum bandwidth
values and priority levels). A child class with siblings (classes with the same parent class) shares
bandwidth with those siblings in the same manner.



Inbound Traffic: Network packets flowing into the ProxySG. Inbound traffic mainly consists of the
following:





Server inbound: Packets originating at the origin content server (OCS) and sent to the
ProxySG to load a Web object.



Client inbound: Packets originating at the client and sent to the ProxySG for Web requests.

OCS: Origin content server.

413

Blue Coat ProxySG Configuration and Management Guide



Outbound Traffic: Network packets flowing out of the ProxySG. Outbound traffic mainly consists
of the following:


Client outbound: Packets sent to the client in response to a Web request.



Server outbound: Packets sent to an OCS or upstream proxy to request a service.



Parent Class: A class with at least one child. The parent class must share its bandwidth with its
child classes in proportion to the minimum/maximum bandwidth values or priority levels.



Sibling Class: A bandwidth class with the same parent class as another class.



Traffic Flow: Also referred to as flow. A set of packets belonging to the same TCP/UDP connection
that terminate at, originate at, or flow through the ProxySG. A single request from a client
involves two separate connections. One of them is from the client to the ProxySG, and the other is
from the ProxySG to the OCS. Within each of these connections, traffic flows in two directions—in
one direction, packets flow out of the ProxySG (outbound traffic), and in the other direction,
packets flow into the ProxySG (inbound traffic). Connections can come from the client or the
server. Thus, traffic can be classified into one of four types:


Server inbound



Server outbound



Client inbound



Client outbound

These four traffic flows represent each of the four combinations described above. Each flow
represents a single direction from a single connection.

Bandwidth Management Overview
To manage the bandwidth of different types of traffic that flow into, out of, or through the ProxySG,
you must do the following:


Determine how many bandwidth classes you need and how to configure them to accomplish your
bandwidth management goals. This includes determining the structure of one or more bandwidth
hierarchies if you want to use priority levels to manage bandwidth.



Create and configure bandwidth classes accordingly.



Create policy rules using those bandwidth classes to identify and classify the traffic in the
ProxySG.



Enable bandwidth management.

Bandwidth management configuration consists of two areas:


Bandwidth allocation
This is the process of creating and configuring bandwidth classes and placing them into a
bandwidth class hierarchy. This process can be done using either the Management Console or the
CLI.

414



Flow classification
This is the process of classifying traffic flows into bandwidth management classes using policy
rules. Policy rules can classify flows based on any criteria testable by policy. 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). For more information about using
VPM to create policy rules, see Chapter 14: “The Visual Policy Manager” on page 493. For
information about composing CPL, refer to the Blue Coat ProxySG Content Policy Language Guide.

Allocating Bandwidth
The process of defining bandwidth classes and grouping them into a bandwidth class hierarchy is
called bandwidth allocation. Bandwidth allocation is based on:


the placement of classes in a hierarchy (the parent/child relationships)



the priority level of classes in the same hierarchy



the minimum and/or maximum bandwidth setting of each class

For example deployment scenarios, see "Bandwidth Allocation and VPM Examples" on page 426.

Bandwidth Classes
To define a bandwidth class, you create the class, giving it a name meaningful to the purpose for
which you are creating it. You can configure the class as you create it or edit it later. The configuration
settings available are:


Parent: Used to create a bandwidth-management hierarchy.



Minimum Bandwidth: Minimum amount of bandwidth guaranteed for traffic in this class.



Maximum Bandwidth: Maximum amount of bandwidth allowed for traffic in this class.



Priority: Relative priority level among classes in the same hierarchy.

Parent Class
A parent class is a class that has children. When you create or configure a bandwidth class, you can
specify another class to be its parent (the parent class must already exist). Both classes are now part of
the same bandwidth-class hierarchy, and so are subject to the hierarchy rules (see "Class Hierarchy
Rules and Restrictions" on page 417).
Minimum Bandwidth
Setting a minimum for a bandwidth class guarantees that class receives at least that amount of
bandwidth, if the bandwidth is available. If multiple hierarchies are competing for the same available
bandwidth, or if the available bandwidth is not enough to cover the minimum, bandwidth
management is not be able to guarantee the minimums defined for each class.

415

Blue Coat ProxySG Configuration and Management Guide

Note:

The ProxySG does not try to reserve any bandwidth on the network links that it is
attached to or otherwise guarantee that the available bandwidth on the network can be
used to satisfy bandwidth class minimums. The ProxySG can only shape the various
traffic flows passing through it, and prioritize some flows over others according to its
configuration.

Maximum Bandwidth
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 is available; a class can never receive more bandwidth
than its maximum.
To keep a bandwidth class from using more than its maximum, the ProxySG inserts delays before
sending packets associated with that class until the bandwidth used is no more than the specified
maximum. This results in queues of packets (one per class) waiting to be sent. These queues allow the
ProxySG to use priority settings to determine which packet gets sent next. If no maximum bandwidth
is set, every packet is sent as soon as it arrives, so no queue is built and nothing can be prioritized.
Unlike minimums and priority levels, the maximum-bandwidth setting can slow down traffic on
purpose. 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.
Priority
When sharing excess bandwidth with classes in the same hierarchy, the class with the highest priority
gets the first opportunity to use excess bandwidth. When the high-priority class uses all the
bandwidth it needs or is allowed, the next class gets to use the bandwidth, if any remains. If two
classes in the same hierarchy have the same priority, then excess bandwidth is shared in proportion to
their maximum bandwidth setting.

Class Hierarchies
Bandwidth classes can be grouped together to form a class hierarchy. Creating a bandwidth class
allows you to allocate a certain portion of the available bandwidth to a particular type of traffic.
Putting that class into a bandwidth-class hierarchy with other bandwidth classes allows you to specify
the relationship among various bandwidth classes for sharing available (unused) bandwidth.
The way bandwidth classes are grouped into the bandwidth hierarchy determines how they share
available bandwidth among themselves. You create a hierarchy so that a set of traffic classes can share
unused bandwidth. The hierarchy starts with a bandwidth class you create to be the top-level parent.
Then you can create other bandwidth classes to be the children of the parent class, and those children
can have children of their own.

416

Chapter 10: Bandwidth Management

In order to manage the bandwidth for any of these classes, some parent in the hierarchy must have a
maximum bandwidth setting. The classes below that parent can then be configured with minimums
and priority levels to determine how unused bandwidth is shared among them. If none of the higher
level classes have a maximum bandwidth value set, then bandwidth flows from the parent to the child
classes without limit. In that case, minimums and priority levels are meaningless, because all classes
get all the bandwidth they need at all times. The bandwidth, in other words, is not being managed.
Class Hierarchy Rules and Restrictions
Certain rules and restrictions must be followed to create a valid BWM class hierarchy:


Each traffic flow can only belong to one bandwidth management class.
You can classify multiple flows into the same bandwidth class, but any given flow is always
counted as belonging to a single class. If multiple policy rules match a single flow and try to
classify it into multiple bandwidth classes, the last classification done by policy applies.



When a flow is classified as belonging to a bandwidth class, all packets belonging to that flow is
counted against that bandwidth class.



If a minimum bandwidth is configured for a parent class, it must be greater than or equal to the
sum of the minimum bandwidths of its children.



If a maximum bandwidth is configured for a parent class, it must be greater than or equal to the
largest maximum bandwidth set on any of its children. It must also be greater than the sum of the
minimum bandwidths of all of its children.



The minimum bandwidth available to traffic directly classified to a parent class is equal to its
assigned minimum bandwidth minus the minimum bandwidths of its children. For example, if a
parent class has a minimum bandwidth of 600 kbps and each of its two children have minimums
of 300 kbps, the minimum bandwidth available to traffic directly classified into the parent class
is 0.

Relationship among Minimum, Maximum, and Priority Values
Maximum values can be used to manage bandwidth for classes whether or not they are placed into a
hierarchy. This is not true for minimums and priorities, which can only manage bandwidth for classes
that are placed into a hierarchy. Additionally, a hierarchy must have a maximum configured on a
high-level parent class in order for the minimums and priorities to manage bandwidth.
This is because, without a maximum, bandwidth goes to classes without limit and there is no point to
setting priorities or minimum guarantees. Bandwidth cannot be managed unless a maximum limit is
set somewhere in the hierarchy.
When a hierarchy has a maximum on the top-level parent and minimums, maximums and priorities
placed on the classes related to that parent, the following conditions apply:


If classes in a hierarchy have minimums, the first thing that happens with available bandwidth is
that all the minimum requests are satisfied. If the amount requested is less than the minimum for
any class, it receives the entire amount, and its priority level does not matter.
Keep in mind that, even though a minimum is considered to be a guaranteed amount of
bandwidth, satisfying minimums is dependent on the parent being able to receive its own
maximum, which is not guaranteed.

417

Blue Coat ProxySG Configuration and Management Guide



When all of the classes in a hierarchy have had their minimums satisfied, any additional requests
for bandwidth must be obtained. When a class requests more than its minimum, it must obtain
bandwidth from its parent or one of its siblings. If, however, a class requests more than its
maximum, that request is denied—no class with a specified maximum is ever allowed more than
that amount.



If a class does not have a minimum specified, it must obtain all of the bandwidth it requests from
its parents or siblings, and it cannot receive any bandwidth unless all of the minimums specified
in the other classes in its hierarchy are satisfied.



Classes obtain bandwidth from their parents or siblings based on their priority levels—the highest
priority class gets to obtain what it needs first, until either its entire requested bandwidth is
satisfied or until it reaches its maximum. After that, the next highest priority class gets to obtain
bandwidth, and this continues until either all the classes have obtained what they can or until the
maximum bandwidth available to the parent has been reached. The amount available to the
parent can sometimes be less than its maximum, because the parent must also participate in
obtaining bandwidth in this way with its own siblings and/or parent if it is not a top-level class.

Flow Classification
You can classify flows to BWM classes by writing policy rules that specify the bandwidth class that a
particular traffic flow belongs to. A typical transaction has four traffic flows:
1.

Client inbound—traffic flowing into the ProxySG from a client (the entity sending a request, such
as a client at a remote office linked to the ProxySG).

2.

Server outbound—traffic flowing out of the ProxySG to a server.

3.

Server inbound—traffic flowing back into the ProxySG from a server (the entity responding to the
request).

4.

Client outbound—traffic flowing back out of the ProxySG to a client.

Figure 10-1 shows the traffic flows between a client and server through the ProxySG.

Figure 10-1: Network Configuration Showing Traffic Flow Directions

418

Chapter 10: Bandwidth Management

Some types of traffic can flow in all four directions. The following example describes different
scenarios that you might see with an HTTP request. A client sends a GET to the ProxySG (client
inbound). The ProxySG then forwards this GET to a server (server outbound). The server responds to
the ProxySG with the appropriate content (server inbound), and then the ProxySG delivers this
content to the client (client outbound).
Policy allows you to configure different classes for each of the four traffic flows. See "Using Policy to
Manage Bandwidth" on page 425 for information about classifying traffic flows with policy.

Configuring Bandwidth Allocation
You can use either the Management Console or the CLI to do the following tasks:


Enable or disable bandwidth management.



Create and configure bandwidth classes.



Delete bandwidth classes.



View bandwidth management class configurations.

Note:

If you are planning to manage the bandwidth of streaming media protocols (Windows
Media, Real Media, or QuickTime), you might want to use the streaming features instead
of the bandwidth management features described in this section. For most circumstances,
Blue Coat recommends that you use the streaming features to control streaming
bandwidth rather than the bandwidth management features. For information about the
differences between these two methods, see "Choosing a Method to Limit Streaming
Bandwidth" on page 638.

Enabling or Disabling Bandwidth Management
The following procedures explain how to enable or disable bandwidth management through the
Management Console or the CLI.
To Enable or Disable Bandwidth Management through the Management Console
1.

Select Configuration>Bandwidth Management>BWM Classes>Bandwidth Classes.

419

Blue Coat ProxySG Configuration and Management Guide

Figure 10-2: Bandwidth Classes Tab

2.

To enable or disable bandwidth management, select or deselect the Enable Bandwidth Management
checkbox.

3.

Click Apply.

To Enable or Disable Bandwidth Management through the CLI
At the (config) command prompt, enter the following commands to enable or disable bandwidth
management:
SGOS#(config) bandwidth-management
SGOS#(config bandwidth-management) enable | disable

Creating and Editing Bandwidth Classes
The following procedures detail how to create and edit a bandwidth management class.
To Create a BWM Class through the Management Console
1.

Select Configuration>Bandwidth Management>BWM Classes>Bandwidth Classes.

2.

To create a new BWM class, click New.
The Create Bandwidth Class dialog displays.

420

Chapter 10: Bandwidth Management

Figure 10-3: Create Bandwidth Class Dialog

3.

Fill in the fields as appropriate:


Class name: Assign a meaningful name for this class. The name can be up to 64 characters long;
spaces are not allowed.



Parent: If you want the class you are creating to be the child of another class in the bandwidth
class hierarchy, select a class from the Parent drop-down list. This class must already exist.



Min. Bandwidth: To set a minimum bandwidth for this class in kilobits per second (kbps), select
Min. Bandwidth and enter a minimum bandwidth value in the field. The default minimum

bandwidth setting is Unspecified, meaning the class is not guaranteed a minimum amount of
bandwidth.


Max. Bandwidth: To set a maximum bandwidth for this class in kbps, select Max. Bandwidth and

enter a maximum bandwidth value in the field. The default maximum bandwidth setting is
Unlimited, meaning the class is not limited to a maximum bandwidth value by this setting.



Priority: Select a priority level for this class from the Priority drop-down list—0 is the lowest

priority level and 7 is the highest. The default priority is 0.
4.

Click OK.

5.

Click Apply.

To Create a BWM Class through the CLI
1.

At the (config) command prompt, enter the following commands to create a new BWM class:
SGOS#(config) bandwidth-management
SGOS#(config bandwidth-management) create bwm_class
where bwm_class is the name of the new BWM class.

2.

Configure the newly created bandwidth class (see "To Edit a BWM Class through the CLI" on
page 422 for instructions).

To Edit a BWM Class through the Management Console
1.

Select Configuration>Bandwidth Management>BWM Classes>Bandwidth Classes.

2.

Highlight the class that you want to edit and click Edit.
The Edit Class dialog displays.

421

Blue Coat ProxySG Configuration and Management Guide

Figure 10-4: Edit Class Dialog

3.

Fill in the fields as appropriate:


Class Name: this field cannot be edited. To change the name of a class, you must delete the
class and create a new one with the new name.



Parent: To make the class you are editing be the child of another class in the bandwidth class
hierarchy, select a class from the Parent drop-down list.



Min. Bandwidth: To set a minimum bandwidth for this class in kilobits per second (kbps), select
Min. Bandwidth and enter a minimum bandwidth value in the field. The default minimum
bandwidth setting is Unspecified, meaning the class is not guaranteed a minimum amount of

bandwidth.


Max. Bandwidth: To set a maximum bandwidth for this class in kbps, select Max. Bandwidth and

enter a maximum bandwidth value in the field. The default maximum bandwidth setting is
Unlimited, meaning the class is not limited to a maximum bandwidth value by this setting.



Priority: Select a priority level for this class from the Priority drop-down list—0 is the lowest

priority level and 7 is the highest. The default priority is 0.
4.

Click OK.

5.

Click Apply.

To Edit a BWM Class through the CLI
1.

To set the priority level and minimum/maximum bandwidth values for an existing BWM class,
enter the following commands:
SGOS#(config) bandwidth-management
SGOS#(config bandwidth-management) edit bwm_class

This changes the prompt and puts you into the Bandwidth-Class submode.
SGOS#(config bw-class bwm_class) min-bandwidth minimum_in_kbps
SGOS#(config bw-class bwm_class) max-bandwidth maximum_in_kbps
SGOS#(config bw-class bwm_class) priority value_from_0_to_7

422

Chapter 10: Bandwidth Management

where:

2.

min-bandwidth

minimum_in_kbps

Sets the minimum bandwidth for this class
in kilobits per second. The default for this
setting is unspecified, meaning that the
class is not guaranteed a minimum
amount of bandwidth.

max-bandwidth

maximum_in_kbps

Sets the maximum bandwidth for this class
in kilobits per second. The default for this
setting is unlimited (no maximum).

priority

value_from_0_to_7

Sets the priority level for this class—0 is
the lowest priority level and 7 is the
highest. The default priority is 0.

(Optional) To reset the values to the defaults, enter the following commands:
SGOS#(config bandwidth-management bwm_class) no {min-bandwidth |
max-bandwidth}
where:

3.

no min-bandwidth

Sets the default minimum to the default, unspecified (no minimum
bandwidth guarantee).

no max-bandwidth

Sets the maximum-bandwidth setting to the default, unlimited (no
maximum).

To make this class a child of another class or to clear the parent class from this class, enter one of
the following commands:
SGOS#(config bandwidth-management bwm_class) parent parent_class_name
-orSGOS#(config bandwidth-management bwm_class) no parent

4.

To view the configuration for this class, enter the following command:
SGOS#(config bandwidth-management bwm_class) view

For example:
SGOS#(config bandwidth-management Office_A) view
Class Name:
Office_A
Parent:

Minimum Bandwidth:
unspecified
Maximum Bandwidth:
750 kbps
Priority:
0

5.

To view the configuration of any child classes of this class, enter the following command:
SGOS#(config bandwidth-management bwm_class) view children

423

Blue Coat ProxySG Configuration and Management Guide

Deleting a Bandwidth Management Class
The following procedures explain how to delete a bandwidth management class through the
Management Console or the CLI.
Note:

You cannot delete a class that is referenced by another class or by the currently installed
policy. For instance, you cannot delete a class that is the parent of another class or one that
is used in an installed policy rule. If you attempt to do so, a message displays explaining
why this class cannot be deleted.

To Delete a BWM Class through the Management Console
1.

Select Configuration>Bandwidth Management>BWM Classes>Bandwidth Classes.

2.

Highlight the class you want to delete and click the Delete button.
The Remove Object dialog displays.

3.

Click Yes to delete the class.

4.

Click Apply.

To Delete a BWM Class through the CLI
At the (config) command prompt, enter the following command to delete the specified BWM class:
SGOS#(config) bandwidth-management
SGOS#(config bandwidth-management) delete bwm_class

Viewing Bandwidth Management Configurations and Statistics
You can view bandwidth management configurations to see what the settings are for each class, and
you can view bandwidth management statistics to see the current and total bandwidth, packet rate,
and number of drops (the total number of packets dropped).
Bandwidth management configurations (minimum/maximum bandwidth, priority level, and
hierarchy relationships) are visible in the Management Console. The view commands allow you to
view the same information in the CLI. See "Bandwidth Management Statistics" on page 889 for
information about viewing bandwidth management statistics.

Viewing Bandwidth Management Configurations
You can view the following bandwidth class configurations through the Management Console or CLI

424



Level in the hierarchy (parent/child relationships)



Priority level



Maximum bandwidth value



Minimum bandwidth value

Chapter 10: Bandwidth Management

To View BWM Configuration through the Management Console
1.

Select Configuration>Bandwidth Management>BWM Classes>Bandwidth Classes.
On this tab, you can view a class’s minimum, maximum and priority value. Top level classes are
visible—classes with children have a folder icon on the left.

2.

To view the configurations of the child class(es) of a class, double-click the folder icon.
The child classes become visible. A second double-click closes the folder.

To View BWM Configuration through the CLI
1.

To view all BWM configuration information, enter the following commands at the (config)
command prompt:
SGOS#(config) bandwidth-management
SGOS#(config bandwidth-management) view configuration

2.

To view the BWM configuration for a specific class, enter the following command:
SGOS#(config bandwidth-management) view configuration bwm_class
For example:
SGOS#(config bandwidth-management) view configuration Office_A
Class Name:
Office_A
Parent:

Minimum Bandwidth:
unspecified
Maximum Bandwidth:
750 kbps
Priority:
0

3.

To view the BWM configuration for the children of a specific class, enter the following commands:
SGOS#(config bandwidth-management) edit bwm_class
SGOS#(config bw-class bwm_class) view children

Viewing Bandwidth Management Statistics
See "Bandwidth Management Statistics" on page 889 for information about viewing BWM statistics.

Using Policy to Manage Bandwidth
Once you have created and configured bandwidth management classes, you need to create policy
rules to classify traffic flows using those classes. Each policy rule can only apply to one of four traffic
flow types:


Client inbound



Client outbound



Server inbound



Server outbound

You can use the same bandwidth management classes in different policy rules, so that one class can
manage bandwidth for several types of flows based on different criteria. However, any given flow is
always be counted as belonging to a single class. If multiple policy rules match a flow and try to
classify it into multiple bandwidth classes, the last classification done by policy will apply.

425

Blue Coat ProxySG Configuration and Management Guide

To manage the bandwidth classes you have created, you can either compose CPL (see "CPL Support
for Bandwidth Management" below) or you can use VPM (see "VPM Support for Bandwidth
Management" on page 426). To see examples of policy using these methods, see "Bandwidth
Allocation and VPM Examples" on page 426 or "Policy Examples: CPL" on page 434.

CPL Support for Bandwidth Management
You must use policy to classify traffic flows to different bandwidth classes. Refer to the Blue Coat
ProxySG Content Policy Language Guide for more information about writing and managing policy.

CPL Triggers
You can use all of the CPL triggers for BWM classification (refer to the Blue Coat ProxySG Content
Policy Language Guide for information about using CPL triggers). Basing a bandwidth decision on a
trigger means that the decision does not take effect until after the information needed to make that
decision becomes available. For example, if you set the CPL to trigger on the MIME type of the HTTP
response, then the HTTP headers must be retrieved from the OCS before a classification can be made.
The decision to retrieve those headers is made too late to count any of the request bytes from the client
or the bytes in the HTTP response headers. However, the decision affects the bytes in the body of the
HTTP response and any bytes sent back to the client.

Supported CPL
Bandwidth class can be set with policy on each of these four traffic flows:


limit_bandwidth.client.inbound(none | bwm_class)



limit_bandwidth.client.outbound(none | bwm_class)



limit_bandwidth.server.inbound(none | bwm_class)



limit_bandwidth.server.outbound(none | bwm_class)

If you set policy to none, the traffic is unclassified and is not to be bandwidth-managed.

VPM Support for Bandwidth Management
You can manage bandwidth using VPM in the Action column of four policy layers: Web Access, DNS
Access, Web Content, and Forwarding Layers. For more information about using VPM to manage
bandwidth, see "Manage Bandwidth" on page 557. For examples of bandwidth management scenarios
using VPM, see "Bandwidth Allocation and VPM Examples" below.

Bandwidth Allocation and VPM Examples
This section illustrates how to allocate bandwidth, arrange hierarchies, and create policy using the
Visual Policy Manager. It describes an example deployment scenario and the tasks an administrator
must accomplish to manage the bandwidth for this deployment. For specific instructions about
allocating bandwidth through either the Management Console or the CLI, see "Configuring
Bandwidth Allocation" on page 419. For examples of bandwidth management tasks done by
composing CPL, see "Policy Examples: CPL" on page 434.

426

Chapter 10: Bandwidth Management

Task One: Bandwidth Allocation
The administrator is responsible for managing the bandwidth of three branch offices. He has been told
to make sure that each office uses no more than half of its total link bandwidth for Web and FTP traffic.
The total link bandwidth of each office is as follows:


Office A: 1.5 Mb



Office B: 1 Mb



Office C: 2 Mb

He creates one bandwidth class for each of the three offices and configures the maximum bandwidth
to an amount equal to half of the total link bandwidth of each, as shown in Figure 10-5. He also creates
policy rules for each class, as described below in "Task One: VPM".

Figure 10-5: Bandwidth Hierarchy Diagram One

Each of the classes in Figure 10-5 has a maximum set at an amount equal to half of the total link
bandwidth for each office. A hierarchy does not exist in this scenario.
Task One: VPM
The administrator has created one bandwidth class for each office, setting a maximum bandwidth on
each one equal to the half of the total link bandwidth of each. Now he must create policy rules to
classify the traffic flows.
The administrator launches VPM and creates a new Web Access Layer, calling it FTP/HTTP
Limitations. He selects the Client IP Address/Subnet object in the Source column, filling in the IP
address and mask of the subnet used by Office_A, as shown in Figure 10-6.

427

Blue Coat ProxySG Configuration and Management Guide

Figure 10-6: Adding the Client IP Address and Subnet Mask to the Source Column

He selects a Combined Service Object in the Service column, naming it FTP/HTTP and adding a Client
Protocol for FTP and for HTTP. In the Add Combined Service Object dialog, he adds both protocols to
the top box, as shown in Figure 10-7.

Figure 10-7: Adding Protocols to a Combined Service Object

In the Action column, he selects Manage Bandwidth, naming it Office_A and setting it to manage the
bandwidth of Office_A on the Client side in the Outbound direction, as shown in Figure 10-8.

428

Chapter 10: Bandwidth Management

Figure 10-8: Manage Bandwidth Action Object

He adds two more similar rules for the other two offices. He is able to reuse the same Combined Service
Object in the Service column, but must add new objects specific to each office in the Source and Action
columns. The order of the rules does not matter here, because each office, and thus each rule, is distinct
because of its IP address/subnet mask configuration.
Task Two: Bandwidth Allocation
A few days later, the administrator gets a visit from the CEO of his company. She wants him to fix it so
that she can visit any of the branch offices without having her own Web and FTP access slowed down
unnecessarily.
The administrator creates two more classes for each office: one for the CEO and another for everyone
else (employees). He sets the parent class of each new class to the appropriate class that he created in
Task One. For instance, he creates Emp_A and CEO_A and sets their parent class to Office_A. He also sets
a priority level for each class: 0 (the lowest) for employees and 1 for the CEO. He then uses VPM to
create additional policy rules for the new classes (see "Task Two: VPM" below). Figure 10-9 shows the
hierarchical relationship among all of the classes.

Figure 10-9: Bandwidth Hierarchy Diagram Two

The administrator now has three separate hierarchies. In each one, 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.
Priority levels are only effective among the classes in the same hierarchy. This means that the priority
levels for the Office_A hierarchy do not affect the classes in the Office_B or Office_C hierarchies.

429

Blue Coat ProxySG Configuration and Management Guide

Task Two: VPM
Because the CEO wants to prioritize FTP and HTTP access among employees and herself, the
administrator must create additional bandwidth classes (as described above in "Task Two: Bandwidth
Allocation") and write policy rules to classify the traffic for the new classes.
He first edits each of the three VPM rules for the three offices. He edits each the Manage Bandwidth
objects, changing the name of the objects to Emp_A, Emp_B, and Emp_C and changes the bandwidth
class to the corresponding employee class (see Figure 10-10).

Figure 10-10: Editing the Bandwidth Management Object

Next, he creates three more rules for the CEO, moving them above the first three rules. For the CEO
rules, he selects the same combined FTP/HTTP object in the Service column; in the Action column, he
selects a Manage Bandwidth object configured for client side/outbound, as before, but this time, he
names the objects CEO_A, CEO_B, and CEO_C and selects the corresponding CEO bandwidth class. In
the Source column, he creates a Combined Source Object, naming it for the CEO. He combines the Client
IP/subnet object already created for each office with a User object that he creates for the CEO, as shown
in Figure 10-11.

430

Chapter 10: Bandwidth Management

Figure 10-11: Adding a Combined Source Object

The administrator places all three CEO rules above the employee rules, because the ProxySG looks for
the first rule that matches a given situation and ignores the remaining rules. If he had placed the CEO
rules below the employee rules, the ProxySG would never get to the CEO rules because the CEO’s
Web surfing client IP address matches both the CEO rules and the employee rules, and the ProxySG
would stop looking after the first match. With the CEO rules placed first, the ProxySG applies the CEO
rules to the CEO’s Web surfing, and an employee’s Web surfing does not trigger the CEO rules and
instead skips ahead to the appropriate employee rule.
Task Three: Bandwidth Allocation
It soon becomes apparent that CEO visits are causing problems for the branch offices. At times, she
uses all of the available bandwidth, resulting in decreased productivity throughout the office she
visits. Also, management has complained that they have been given the same priority for FTP and
HTTP traffic as regular employees, and they are requesting that they be given priority over employees
for this type of traffic.
First, the administrator creates two new classes for each office. In this example, we will look at the
classes and configurations for the first office only. He creates a class called Staff_A and sets a minimum
bandwidth of 500 kbps on it. He also creates a class called Mgmt_A, setting the priority to 1 and the
parent to Staff_A. He edits the class Emp_A, setting the parent to Staff_A. Finally, he edits the class
CEO_A, changing the priority to 2. The resulting hierarchy is illustrated in Figure 10-12. To see what
the administrator did to the policy rules, see "Task Three: VPM" below.

431

Blue Coat ProxySG Configuration and Management Guide

Figure 10-12: Bandwidth Hierarchy Diagram Three

In the example illustrated above, employees and management combined are guaranteed a total of 500
kbps. The CEO’s priority level has no effect until that minimum is satisfied. This means that the CEO
can only use 250 kbps of bandwidth if the rest of the staff are using a total of 500 kbps. It also means
that the CEO can use 750 kbps if no one else is using bandwidth at the time. In fact, any of the classes
can use 750 kbps if the other classes use none.
Priority levels kick in after all of the minimums are satisfied. In this example, if the staff requests more
than 500 kbps, they can only receive it if the CEO is using less than 250 kbps. Now notice that the
minimum setting for the staff is set on the parent class, Staff_A, and not on the child classes, Emp_A or
Mgmt_A. This means that the two child classes, representing employees and management, share a
minimum of 500 kbps. But they share it based on their priority levels. This means that management
has priority over employees. The employees are only guaranteed a minimum if management is using
less than 500 kbps.
Task Three: VPM
The administrator has added additional classes for each office and edited the existing employee
classes, as described above in "Task Three: Bandwidth Allocation". One of the new classes he added
for each office is a parent class that does not have traffic classified to it; it was created to provide a
minimum amount of bandwidth to its child classes. Not every class in the hierarchy has to have a
traffic flow. This means that he needs to add just three more rules for the three new management
classes. For the management rules, he selects the same combined FTP/HTTP object in the Service
column; in the Action column, he selects a Manage Bandwidth object configured for client side/outbound
with the bandwidth class one of the management classes (Mgmt_A, Mgmt_B, or Mgmt_C). In the Source
column, he creates a Combined Source Object containing the subnet object for the office and the Group
object for management.
The management rules must go above the employee rules, although it does not matter where they are
placed in relation to the CEO rules. This would not be true if the CEO was part of the same group as
management, however. If that were true, the CEO rules would still need to go on top.
Task Four: Bandwidth Allocation
The administrator decided later that he needed to guarantee employees some bandwidth. He
configures a minimum for the class Emp_A, as illustrated in Figure 10-13.

432

Chapter 10: Bandwidth Management

Figure 10-13: Bandwidth Hierarchy Diagram Four

He decides to leave the minimum on the parent class Staff_A and not to set a minimum for the class
Mgmt_A. This is okay, because the minimum of the parent class is available to its children if the parent
class does not use all of it, and the only way that the CEO can get more than 250 kbps is if the
employees and management combined use less than 500.
This last change does not require additional changes to policy; the administrator has added a
minimum to a class that he has already classified for traffic using policy.
In the above scenario, the class called Staff_A does not have traffic configured for it—it was created to
guarantee bandwidth minimums for its child classes. However, if it were configured for traffic, it
would have a practical minimum of 300 kbps. The practical minimum of a parent class is equal to its
assigned minimum bandwidth minus the minimums of its children. In that case, if the parent class
Staff_A used 300 kbps and the child class Emp_A used 200 kbps, the child class Mgmt_A would not
receive any bandwidth unless the class CEO_A was using less than 250 kbps. Under those
circumstances, the administrator probably also needs to create a minimum for management.
Task Five: Bandwidth Allocation
The CEO makes another request, this time for the main office, the one the administrator himself works
from. This office uses the content filtering feature of the ProxySG to control the types of Web sites that
employees are allowed to view. Although the office uses content filtering, access to sports sites is not
restricted because the CEO is a big fan.
The administrator creates a bandwidth management class called Sports with a maximum bandwidth
of 500 kbps and launches VPM to create policy for this class as described below.
Task Five: VPM
To classify traffic for the Sports class, the administrator opens VPM, creates a Web Access Layer, and
sets the Destination column to the Category object that includes sports viewing (content filtering is
already set up in VPM). He sets the Action column to the Manage Bandwidth object, selecting Server
side/Inbound and the Sports bandwidth class he created. After installing the policy and verifying that
bandwidth management is enabled, he is finished.

433

Blue Coat ProxySG Configuration and Management Guide

Policy Examples: CPL
The examples below are complete in themselves. The administrator uses CLI to create and configure
bandwidth management classes and writes CPL to classify traffic flow for these classes. These
examples do not make use of a bandwidth class hierarchy. For examples of hierarchies, see
"Bandwidth Allocation and VPM Examples" on page 426.
Example One: CPL
In this example, the administrator of a college is asked to prevent college students from downloading
MP3 files during peak hours, while still allowing the music department to download MP3 files at any
time. The CPL triggers used are authentication and/or source subnet and MIME type. The action
taken is to limit the total amount of bandwidth consumed by students to 40 kbps.
CLI commands:
SGOS#(config) bandwidth-management
SGOS#(config bandwidth-management) create mp3
SGOS#(config bandwidth-management) edit mp3
SGOS#(config bw-class mp3) max-bandwidth 40

CPL:
define condition student_mp3_weekday
client_address=student_subnet response_header.Content-Type="audio/mpeg" \
weekday=1..5 hour=9..16
end condition

condition=student_mp3_weekday limit_bandwidth.server.inbound(mp3)

Example Two: CPL
In this example, an administrator must restrict the amount of bandwidth used by HTTP POST
requests for file uploads from clients to 2 Mbps. The CPL trigger used is request method, and the
action taken is to throttle (limit) the amount of bandwidth used by client side posts by limiting
inbound client side flows.
CLI commands:
SGOS#(config) bandwidth-management
SGOS#(config bandwidth-management) create http_post
SGOS#(config bandwidth-management) edit http_post
SGOS#(config bw-class http_post) max-bandwidth 2000

CPL:
define condition http_posts
http.method=POST
end condition

e-Highlighter

Click to send permalink to address bar, or right-click to copy permalink.

Un-highlight all Un-highlight selectionu Highlight selectionh