Name: ProxySG

Text: 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-02679
Document Revision: 3.2.7—02/01/2006

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.

iii

Blue Coat ProxySG Configuration and Management Guide

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

iv

Copyrights

However, I am not implying to give any licenses to any patents or copyrights held by third parties, and the software includes parts that
are not under my direct control. As far as I know, all included source code is used in accordance with the relevant license agreements and
can be used freely for any purpose (the GNU license being the most restrictive); see below for details.
[However, none of that term is relevant at this point in time. All of these restrictively licenced software components which he talks about
have been removed from OpenSSH, i.e.,
- RSA is no longer included, found in the OpenSSL library
- IDEA is no longer included, its use is deprecated
- DES is now external, in the OpenSSL library
- GMP is no longer used, and instead we call BN code from OpenSSL
- Zlib is now external, in a library
- The make-ssh-known-hosts script is no longer included
- TSS has been removed
- MD5 is now external, in the OpenSSL library
- RC4 support has been replaced with ARC4 support from OpenSSL
- Blowfish is now external, in the OpenSSL library
[The licence continues]
Note that any information and cryptographic algorithms used in this software are publicly available on the Internet and at any major
bookstore, scientific library, and patent office worldwide. More information can be found e.g. at "http://www.cs.hut.fi/crypto".
The legal status of this program is some combination of all these permissions and restrictions. Use only at your own responsibility. You
will be responsible for any legal consequences yourself; I am not making any claims whether possessing or using this is legal or not in
your country, and I am not taking any responsibility on your behalf.
NO WARRANTY
BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT
PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. IN NO
EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY
OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR
DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE
OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED
INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY
OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.
2) The 32-bit CRC compensation attack detector in deattack.c was contributed by CORE SDI S.A. under a BSD-style license.
Cryptographic attack detector for ssh - source code
Copyright (c) 1998 CORE SDI S.A., Buenos Aires, Argentina. All rights reserved. Redistribution and use in source and binary forms, with
or without modification, are permitted provided that this copyright notice is retained. THIS SOFTWARE IS PROVIDED ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES ARE DISCLAIMED. IN NO EVENT SHALL CORE SDI S.A. BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES RESULTING FROM THE USE OR MISUSE OF
THIS SOFTWARE.
Ariel Futoransky
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)

v

Blue Coat ProxySG Configuration and Management Guide

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

vi

Copyrights

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are
met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
OpenSSL
Copyright (c) 1995-1998 Eric Young (eay@cryptsoft.com). All rights reserved.
http://www.openssl.org/about/
http://www.openssl.org/about/
OpenSSL is based on the excellent SSLeay library developed by Eric A. Young 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:

vii

Blue Coat ProxySG Configuration and Management Guide

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

viii

Copyrights

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

ix

Blue Coat ProxySG Configuration and Management Guide

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

x

Copyrights

xi

Blue Coat ProxySG Configuration and Management Guide

xii

Contents
Contact Information
Third Party Copyright Notices
Chapter 1: Introducing the ProxySG
Web Security Solution ......................................................................................................................................19
New Features in this Release ...........................................................................................................................22
Protocols Supported..........................................................................................................................................26
Supported Browsers..........................................................................................................................................27
Upgrading and Upgrade Enhancements .......................................................................................................27
About the Document Organization ................................................................................................................27
Related Blue Coat Documentation..................................................................................................................29
Document Conventions....................................................................................................................................29
Chapter 2: Licensing
About Licensing.................................................................................................................................................31
Licensable Components....................................................................................................................................31
About the Trial Period ......................................................................................................................................32
About License Expiration.................................................................................................................................32
Installing a System License Key ......................................................................................................................33
Viewing License Information ..........................................................................................................................36
Updating a License............................................................................................................................................37
Automatically Updating a License .................................................................................................................37
Chapter 3: Accessing the ProxySG
Before You Begin: Understanding Modes .....................................................................................................39
Accessing the ProxySG .....................................................................................................................................40
Management Console Home Page..................................................................................................................41
Changing the Login Parameters......................................................................................................................42
Configuring the SSH Console..........................................................................................................................47
Chapter 4: Configuring the System
Global Configurations ......................................................................................................................................53
Archive Configuration......................................................................................................................................59
Adapters .............................................................................................................................................................64
Software and Hardware Bridges.....................................................................................................................68
Gateways ............................................................................................................................................................72
Defining Static Routes ......................................................................................................................................74
Using RIP ............................................................................................................................................................78
DNS ....................................................................................................................................................................81
Attack Detection ................................................................................................................................................86
Using a Bypass List ...........................................................................................................................................91

xiii

Blue Coat ProxySG Configuration and Management Guide

Installing WCCP Settings................................................................................................................................. 99
Virtual IP Addresses....................................................................................................................................... 103
Configuring Failover ...................................................................................................................................... 104
TCP-IP Configuration..................................................................................................................................... 109
Chapter 5: Managing Port Services
Section A: Managing Multiple Management Consoles
HTTPS Console (Secure Console)................................................................................................................. 114
HTTP Console.................................................................................................................................................. 117
SSH Console..................................................................................................................................................... 118
Telnet Console ................................................................................................................................................. 119
Section B: Creating and Editing Services
About Service Attributes................................................................................................................................ 122
DNS-Proxy ....................................................................................................................................................... 122
FTP .................................................................................................................................................................... 125
HTTP ................................................................................................................................................................. 126
HTTPS............................................................................................................................................................... 127
Instant Messaging Protocols.......................................................................................................................... 129
Streaming Protocols ........................................................................................................................................ 130
SOCKS .............................................................................................................................................................. 131
TCP Tunneling................................................................................................................................................. 132
Telnet Shell Proxy Service.............................................................................................................................. 134
Chapter 6: Configuring Proxies
Section A: About Explicit and Transparent Proxy
Section B: Configuring Explicit Proxies
Creating an Explicit Proxy Server................................................................................................................. 139
Configuring the FTP Proxy............................................................................................................................ 140
Configuring FTP Connection Welcome Banners........................................................................................ 146
Configuring an HTTP Proxy ......................................................................................................................... 147
Configuring a SOCKS Proxy ......................................................................................................................... 160
Shell Proxies..................................................................................................................................................... 162
Section C: Transparent Proxies
Configuring the Transparent Proxy Hardware .......................................................................................... 169
IP Forwarding.................................................................................................................................................. 171
Creating a Transparent Proxy Service ......................................................................................................... 171
Chapter 7: Using Secure Services
HTTPS Termination Overview ..................................................................................................................... 173
Configuring HTTPS Termination ................................................................................................................. 177
Managing the SSL Client................................................................................................................................ 196
Configuring HTTP or HTTPS Origination to the Origin Content Server............................................... 200
Configuring DNS Resolution to the Origin Content Server ..................................................................... 202

xiv

Contents

Chapter 8: Security and Authentication
Section A: Controlling Access to the ProxySG
Limiting Access to the ProxySG Appliance ................................................................................................ 205
About Password Security............................................................................................................................... 206
Limiting User Access to the ProxySG—Overview..................................................................................... 207
Moderate Security: Restricting Management Console Access Through the Console Access Control List
210
Maximum Security: Administrative Authentication and Authorization Policy ................................... 212
Section B: Controlling Access to the Internet and Intranet
Using Authentication and Proxies................................................................................................................ 217
Using SSL with Authentication and Authorization Services ................................................................... 222
Creating a Proxy Layer to Manage Proxy Operations............................................................................... 223
Chapter 9: Using Authentication Services
Understanding Realms................................................................................................................................... 233
SSL Between the ProxySG and the Authentication Server ....................................................................... 233
Section A: NTLM Realm Authentication and Authorization
How Blue Coat Works with NTLM.............................................................................................................. 235
Creating an NTLM Realm ............................................................................................................................. 235
NTLM Servers.................................................................................................................................................. 236
Defining NTLM Realm General Properties................................................................................................. 238
Creating the CPL ............................................................................................................................................. 240
Tips and Boundary Conditions..................................................................................................................... 240
Section B: LDAP Realm Authentication and Authorization
Overview .......................................................................................................................................................... 242
Creating an LDAP Realm .............................................................................................................................. 243
LDAP Servers .................................................................................................................................................. 244
Defining LDAP Base Distinguished Names ............................................................................................... 248
LDAP Search & Groups Tab (Authorization and Group Information) .................................................. 251
Customizing LDAP Objectclass Attribute Values...................................................................................... 254
Defining LDAP General Realm Properties.................................................................................................. 255
Creating the CPL ............................................................................................................................................. 257
Section C: RADIUS Realm Authentication and Authorization
Creating a RADIUS Realm............................................................................................................................. 258
Defining RADIUS Realm Properties ............................................................................................................ 259
Defining RADIUS Realm General Properties ............................................................................................. 261
Creating the CPL ............................................................................................................................................. 264
Section D: Local Realm Authentication and Authorization
Creating a Local Realm .................................................................................................................................. 265
Changing Local Realm Properties ................................................................................................................ 266
Defining the Local User List .......................................................................................................................... 268
Creating the CPL ............................................................................................................................................. 275

xv

Blue Coat ProxySG Configuration and Management Guide

Section E: Certificate Realm Authentication
How Certificate Realm Works ...................................................................................................................... 276
Creating a Certificate Realm.......................................................................................................................... 276
Defining a Certificate Realm ......................................................................................................................... 278
Defining Certificate Realm General Properties .......................................................................................... 279
Revoking User Certificates ............................................................................................................................ 281
Creating the Certificate Authorization Policy ............................................................................................ 282
Tips.................................................................................................................................................................... 282
Section F: Sequence Realm Authentication
Adding Realms to a Sequence Realm" ......................................................................................................... 284
Creating a Sequence Realm ........................................................................................................................... 284
Adding Realms to a Sequence Realm........................................................................................................... 285
Defining Sequence Realm General Properties ........................................................................................... 287
Section G: Netegrity SiteMinder
Understanding SiteMinder Interaction with Blue Coat ............................................................................ 290
Participating in a Single Sign-On (SSO) Scheme ........................................................................................ 292
Creating a SiteMinder Realm ....................................................................................................................... 293
SiteMinder Servers.......................................................................................................................................... 297
Defining SiteMinder Server General Properties......................................................................................... 300
Creating the CPL ............................................................................................................................................. 304
Section H: Forms-Based Authentication
Understanding Authentication Forms......................................................................................................... 306
Creating and Editing an Authentication Form ........................................................................................... 308
Setting Storage Options.................................................................................................................................. 313
Using CPL with Forms-Based Authentication............................................................................................ 314
Tips and Boundary Conditions..................................................................................................................... 315
Section I: Managing the Credential Cache
Chapter 10: External Services
Section A: ICAP
Supported ICAP Servers ................................................................................................................................ 322
ICAP v1.0 Features.......................................................................................................................................... 322
About Content Scanning ................................................................................................................................ 323
Installing the ICAP Server ............................................................................................................................. 325
Creating an ICAP Service .............................................................................................................................. 325
Deleting an ICAP Service............................................................................................................................... 330
Customizing ICAP Patience Text ................................................................................................................. 330
Creating ICAP Policy...................................................................................................................................... 335
Managing Virus Scanning.............................................................................................................................. 341
Access Logging................................................................................................................................................ 342
References......................................................................................................................................................... 343

xvi

Contents

Section B: Websense
Creating a Websense Service......................................................................................................................... 344
Deleting a Websense Service ......................................................................................................................... 346
Section C: Service Groups
Creating a Service Group............................................................................................................................... 348
Deleting a Service Group or Group Entry................................................................................................... 350
About Weighted Load Balancing.................................................................................................................. 350
Section D: Displaying External Service and Group Information
Chapter 11: Health Checks
About General Health Checks....................................................................................................................... 355
Configuring Service-Specific Health Checks .............................................................................................. 356
About Global Forwarding and SOCKS Gateway Health Checks ............................................................ 359
Configuring Global Health Checks .............................................................................................................. 359
Pausing or Resuming Global Health Checking .......................................................................................... 361
Chapter 12: Managing Policy Files
About Policy Files ........................................................................................................................................... 363
Creating and Editing Policy Files ................................................................................................................. 366
Managing the Central Policy File ................................................................................................................. 371
Viewing Policy Files ....................................................................................................................................... 373
Chapter 13: The Visual Policy Manager
Section A: About the Visual Policy Manager
JRE Requirement ............................................................................................................................................. 379
Launching the Visual Policy Manager ......................................................................................................... 379
About the Visual Policy Manager User Interface ....................................................................................... 380
About VPM Components............................................................................................................................... 383
The Set Object Dialog ..................................................................................................................................... 386
The Add/Edit Object Dialog ......................................................................................................................... 387
Section B: Policy Layer and Rule Object Reference
About the Reference Tables ........................................................................................................................... 389
Administration Authentication Policy Layer Reference ........................................................................... 389
Administration Access Policy Layer Reference.......................................................................................... 389
DNS Access Policy Layer Reference............................................................................................................. 389
SOCKS Authentication Policy Layer Reference ......................................................................................... 390
Web Authentication Policy Layer Reference .............................................................................................. 391
Web Access Policy Layer Reference ............................................................................................................. 391
Web Content Policy Layer Reference........................................................................................................... 393
Forwarding Policy Layer Reference ............................................................................................................. 393
Section C: Detailed Object Column Reference
Source Column Object Reference.................................................................................................................. 396
Destination Column Object Reference ......................................................................................................... 406
Service Column Object Reference................................................................................................................. 411

xvii

Blue Coat ProxySG Configuration and Management Guide

Time Column Object Reference .................................................................................................................... 416
Action Column Object Reference.................................................................................................................. 419
Track Object Column Reference ................................................................................................................... 441
Comment Object Reference ........................................................................................................................... 444
Using Combined Objects ............................................................................................................................... 444
Creating Categories ........................................................................................................................................ 446
Restricting DNS Lookups .............................................................................................................................. 448
Restricting Reverse DNS Lookups .............................................................................................................. 449
Setting the Group Log Order......................................................................................................................... 449
Section D: Managing Policy Layers and Files
How Policy Layers, Rules, and Files Interact.............................................................................................. 452
Managing Policy Files .................................................................................................................................... 455
Installing VPM-Created Policy Files ............................................................................................................ 456
Viewing the Policy/Created CPL ................................................................................................................. 459
Section E: Tutorials
Tutorial—Creating a Web Authentication Policy ...................................................................................... 461
Tutorial—Creating a Web Access Policy ..................................................................................................... 465
Chapter 14: Advanced Policy
Blocking Pop-Up Windows ........................................................................................................................... 473
Stripping or Replacing Active Content........................................................................................................ 474
About Active Content Types ......................................................................................................................... 475
Modifying Headers......................................................................................................................................... 476
Defining Exceptions........................................................................................................................................ 477
About Exception Definitions ......................................................................................................................... 480
About the Exceptions Hierarchy................................................................................................................... 481
About the Exceptions Installable List........................................................................................................... 482
Creating or Editing Exceptions ..................................................................................................................... 483
Viewing Exceptions ........................................................................................................................................ 486
Chapter 15: Streaming Media
Section A: About Streaming Media
Streaming Media Overview........................................................................................................................... 490
Streaming Media Protocols............................................................................................................................ 491
Streaming Media Player Support ................................................................................................................. 494
Streaming Media Authentication ................................................................................................................. 494
Streaming Media Caching Behavior............................................................................................................. 496
Section B: Configuring Streaming Media
Limiting Bandwidth ....................................................................................................................................... 499
Configuring the Refresh Rate ........................................................................................................................ 503
Configuring HTTP Handoff .......................................................................................................................... 504
Forwarding Client Logs to the Media Server.............................................................................................. 505
Configuring Media Server Authentication Type (Windows Media) ...................................................... 506
About Multicast Streaming............................................................................................................................ 506

xviii

Contents

Managing Multicast Streaming for Windows Media ................................................................................ 507
Managing Multicast Streaming for Real Media.......................................................................................... 511
Managing Simulated Live Content (Windows Media) ............................................................................. 512
ASX Rewriting (Windows Media)................................................................................................................ 514
About Fast Streaming (Windows Media).................................................................................................... 517
Section C: Windows Media Player
Configuring Windows Media Player ........................................................................................................... 518
Limitations ....................................................................................................................................................... 519
Windows Media Access Log Formats.......................................................................................................... 520
Section D: RealPlayer
Configuring RealPlayer.................................................................................................................................. 521
Real Media Access Log Formats ................................................................................................................... 523
Limitations and Known Issues...................................................................................................................... 523
Section E: QuickTime Player
Configuring QuickTime Player..................................................................................................................... 524
QuickTime Access Log Formats ................................................................................................................... 524
Limitations ....................................................................................................................................................... 524
Access Log Format .......................................................................................................................................... 525
Chapter 16: Instant Messaging
About Securing Instant Messaging............................................................................................................... 527
Recommended Deployments ........................................................................................................................ 527
About the Instant Messaging Protocol Services ......................................................................................... 527
About HTTP Proxy Support.......................................................................................................................... 528
About Instant Messaging Reflection ............................................................................................................ 528
IM Reflection Diagrams ................................................................................................................................. 528
About Instant Messaging Proxy Authentication ........................................................................................ 532
Securing AOL Encryption Capability .......................................................................................................... 532
Instant Message Proxies ................................................................................................................................. 533
Configuring Instant Messenger Clients ....................................................................................................... 536
VPM Examples ................................................................................................................................................ 539
Statistics ............................................................................................................................................................ 540
Related Material .............................................................................................................................................. 543
Chapter 17: Content Filtering
Overview .......................................................................................................................................................... 545
Selecting Category Providers ........................................................................................................................ 546
Configuring a Local Database ....................................................................................................................... 549
Configuring Blue Coat Web Filter ............................................................................................................... 554
Configuring InterSafe ..................................................................................................................................... 561
Configuring Proventia Web Filter ................................................................................................................ 566
Configuring SmartFilter ................................................................................................................................. 571
Configuring SurfControl................................................................................................................................ 579
Configuring Websense ................................................................................................................................... 583
How to Apply Policy to Categorized URLs ................................................................................................ 588

xix

Blue Coat ProxySG Configuration and Management Guide

Using Content-Filtering Vendors with ProxySG Policies ......................................................................... 591
Tips.................................................................................................................................................................... 594
Chapter 18: Configuring the Upstream Networking Environment
Forwarding Configuration ............................................................................................................................ 597
SOCKS Gateway Configuration.................................................................................................................... 619
Internet Caching Protocol (ICP) Configuration.......................................................................................... 628
Using Policy to Manage Forwarding ........................................................................................................... 636
Chapter 19: Access Logging
Overview .......................................................................................................................................................... 641
Customizing the Log Procedures ................................................................................................................. 642
Testing Access Log Uploading...................................................................................................................... 676
Viewing Access-Log Statistics ....................................................................................................................... 678
Using Access Logging with Policy Rules .................................................................................................... 682
Chapter 20: Maintaining the ProxySG
Restarting the ProxySG .................................................................................................................................. 687
Restoring System Defaults............................................................................................................................. 689
Purging the DNS Cache ................................................................................................................................. 691
Clearing the System Cache ............................................................................................................................ 692
Upgrading the ProxySG ................................................................................................................................. 692
Managing ProxySG Systems ......................................................................................................................... 695
Event Logging and Notification.................................................................................................................... 698
Configuring SNMP ......................................................................................................................................... 705
Disk Reinitialization ....................................................................................................................................... 708
Deleting Objects from the ProxySG.............................................................................................................. 709
Chapter 21: Statistics
Selecting the Graph Scale............................................................................................................................... 711
General Statistics ............................................................................................................................................. 711
System Usage Statistics .................................................................................................................................. 714
HTTP/FTP History Statistics ........................................................................................................................ 718
Streaming History Statistics .......................................................................................................................... 720
SOCKS History Statistics................................................................................................................................ 724
Shell History Statistics .................................................................................................................................... 725
Resources Statistics ......................................................................................................................................... 726
Efficiency Statistics.......................................................................................................................................... 729
Contents Statistics ........................................................................................................................................... 733
Event Logging.................................................................................................................................................. 734
Failover Statistics............................................................................................................................................. 735
Advanced Statistics......................................................................................................................................... 735
Appendix A: Using the Authentication/Authorization Agent
Installing the BCAAA Service on a Windows or Windows NT System................................................. 737
NTLM and the BCAAA Service .................................................................................................................... 744

xx

Contents

SiteMinder and the BCAAA Service ............................................................................................................ 744
Troubleshooting Authentication Agent Problems ..................................................................................... 745
Common BCAAA Event Messages .............................................................................................................. 745
Appendix B: Access Log Formats
Custom or W3C ELFF Format....................................................................................................................... 751
SQUID-Compatible Format ........................................................................................................................... 754
NCSA Common Access Log Format ............................................................................................................ 755
Fields Available for Creating Access Log Formats .................................................................................... 756
Appendix C: Using WCCP
Overview .......................................................................................................................................................... 785
Quick Start........................................................................................................................................................ 787
Configuring a WCCP Version 2 Service on the Router ............................................................................. 788
Creating a ProxySG WCCP Configuration File .......................................................................................... 795
Examples .......................................................................................................................................................... 802
Troubleshooting: Home Router .................................................................................................................... 806
Tips.................................................................................................................................................................... 809
Appendix D: RIP Commands
net ...................................................................................................................................................................... 811
host .................................................................................................................................................................... 811
RIP Parameters ................................................................................................................................................ 812
ProxySG-Specific RIP Parameters................................................................................................................. 813
Using Passwords with RIP ............................................................................................................................ 814
Appendix E: Using Regular Expressions
Regular Expression Syntax ............................................................................................................................ 816
Regular Expression Details............................................................................................................................ 817
Regular Expression Engine Differences From Perl .................................................................................... 828
Appendix F: Diagnostics
Service Information......................................................................................................................................... 832
Packet Capturing (the PCAP Utility) ........................................................................................................... 839
Core Image Restart Options .......................................................................................................................... 845
Diagnostic Reporting (Heartbeats) ............................................................................................................... 846
Appendix G: Using Blue Coat Director to Manage Multiple Appliances
How Director Works with ProxySG............................................................................................................. 849
Director Documentation ................................................................................................................................ 853
Index

xxi

Blue Coat ProxySG Configuration and Management Guide

xxii

Chapter 1:

Introducing the ProxySG

The Internet is becoming a primary conduit for Web-based information, applications, and
transactions. This growing use of Web applications exposes organizations to new security threats from
Web viruses, hostile mobile code, and inappropriate Web content—all of which are capable of using
HTTP as an open door into the organization.
While current security infrastructures include firewalls designed to protect enterprises from
packet-level threats, they are not designed to handle the sophisticated threats allowed in from
content-level applications. This has led organizations to embrace a new security model—one that
includes both a firewall for packet-level protection and a Web security solution optimized to provide
content-level protection.
Blue Coat™ Systems ProxySG 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.

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 utilizing
port 80.



Highly scalable, policy-based virus scanning optimized to scan Web-based threats in real-time.



Flexibility to implement security policies for both uploaded and downloaded Web content.



Scalable policy-based, URL filtering provides comprehensive control over Web usage and reduces
response times for users.



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



Optimized design for Web content and security resulting in higher performance and lower
management costs.

19

Chapter 1: Introducing the ProxySG

Configurable Management Console Sessions
The ProxySG ships with a default Management Console session timeout of 900 seconds (15 minutes).
You can determine whether you want this feature enabled, and the session timeout value can be
changed.
At the end of the session, you are prompted to either log out or to log back in. If you do nothing, you
are logged out.
To log out before the session is over, click the Log Out link at the top of the page.

HTTPS Termination
The ProxySG ships with a default keyring (name, keypair, certificate, and SSL client) that allows the
appliance to authenticate itself to other browsers. You can also configure other keyrings using
self-signed certificates or any of the many Certificate-Authority-signed (CA) certificates. Lists of
CA-Certificates that can be associated with a particular HTTPS service can be created.
The ProxySG HTTPS termination is implemented as follows:


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.

Enhanced Services
In SGOS 3.x, configuring and enabling services is more intuitive.
Some services have been renamed to better reflect the fact they control access to the Management
Console and CLI. Other services were added for this version of SGOS, including MMS, RTSP,
MSN-IM, AOL-IM, and Yahoo-IM.
The streaming services—MMS and RTSP— are part of configuring and enabling streaming proxies.
MSN-IM, AOL-IM, and Yahoo-IM are services that can be enabled to use Instant Messaging.
Each of these proxies must be configured through their specific Proxy tab and then configured with a
port and enabled through the Service Ports tab.

Increased Policy Configuration and Management
Policies allow you to manage Web access and allow you to control end-user Web access in your existing
infrastructure. Policies differ from the ProxySG configuration settings. Configuration sets up a feature;
policies determine how the feature is used. Both are essential.
Policy is substantially more robust in SGOS 3.x. Many new conditions, properties, and actions have
been added to manage new and improved features, such as Instant Messaging and Access Logging.
The Visual Policy Manager (VPM) contains substantially more functionality than in previous versions.
Using just the VPM, you can:


Generate more complex and granular policy.



Browse users and groups from Security realms (LDAP, NTLM, and the like) defined on the
ProxySG and insert them in policy without typing in complex Distinguished Names (DNs).

25

Blue Coat ProxySG Configuration and Management Guide



Track specific policy rules.



Include month and year in the time object.



Rewrite policy to include server_portal and header rewrite.

Like the Management Console, the VPM has be redesigned.

Increased Logging Capabilities
For SGOS 3.x, Access Logging has been redone, with increased robustness and improved
functionality.
Access logging allows you to track the number of visitors, their originating IP address, how many
requests for each page at the site, and usage patterns regarding a specific site.
Log takes on additional meaning. In addition to the log, customizable components such as log format,
upload schedules, and upload client configurations are also saved with the log and can be
reconfigured with new information at any time.

RTSP Proxy Support
SGOS 3.x replaces the former ported Real proxy with new RTSP proxy. Changes include:


HTTP streaming support through the RTSP proxy



Ability to use HTTP to the origin content server



Firewall problems have been eliminated, since RTSP no longer uses ports 3030/7878



More granular control of RTSP through policy



Streaming-speed prepopulation



Line-speed pre-population from a Web server using HTTP download



Logging user accesses to a single streaming facility, using default ELFF format



Multicasting to clients.

Protocols Supported
Blue Coat ProxySGs are multi-protocol. Blue Coat supports the following protocols:


HTTP



HTTP 1.1—The benefits of HTTP 1.1 include persistent connections that allow multiple requests
to be pipelined to the ProxySG and virtual hosting capabilities.
For either HTTP or HTTP 1.1, you must enable the service before using it.



FTP, Transparent FTP—The ProxySG implementation of transparent FTP is intended for caching
public FTP objects, which constitute the vast majority of the FTP objects accessed through Web
browsers. Public FTP objects are those that are accepted anonymously, using the anonymous
reserved username of FTP.
Transparent FTP is configured and enabled by default.

26

Chapter 1: Introducing the ProxySG



HTTPS—This is the default protocol used by the Management Console. It is configured and
enabled by default. You can create other HTTPS services.



Streaming Media—The ProxySG allows streaming of both live and pre-recorded video and audio
using unicast one-to-one transmission or multicast (one-to-many) transmission.
MMS and RTSP ports are configured and enabled by default.

Supported Browsers
The ProxySG Management Console supports Microsoft® Internet Explorer 5 and 6, and Netscape®
Communicator 4.76 and 6.2.
The Management Console uses the Java Runtime Environment. All browsers come with a default,
built-in JRE, and you should use this default JRE rather than an independent JRE version downloaded
from Sun® Microsystems.

Upgrading and Upgrade Enhancements
For information on doing upgrades or downgrades, or for restoring default system settings, refer to
the Blue Coat SGOS 3.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.
p

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.

p

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.

27

Blue Coat ProxySG Configuration and Management Guide



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.



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:


28

Proxy caching (HTTP, FTP, Streaming)

Chapter 1: Introducing the ProxySG



Authentication/single sign-on



Access control policy



Content filtering



Web anti-virus

Implementing policies is a two-step process:


Configure the feature; for example, choose Blue Coat Web Filter (BCWF) 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.

29

Blue Coat ProxySG Configuration and Management Guide



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.

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

• Blue Coat Reporter: Chapter 3, “Creating the First
Profile”; Blue Coat Reporter Configuration and Management
Guide
• SurfControl Reporter: "Using SurfControl Reporter with
SGOS 3.x."

Table 1.2: Anti-Virus
Task

Reference

Block Web viruses using ProxyAV

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

Set up anti-virus filtering

Blue Coat ProxyAV Configuration and Management Guide

Table 1.3: Authentication

30

Task

Reference

Achieve single sign-on with NTLM

"Section A: NTLM Realm Authentication and
Authorization"

Select the right authentication mode

"Using Authentication and Proxies"

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

Appendix A: "Using the Authentication/Authorization
Agent"

Configure authentication to work with an
existing authentication service

Chapter 9: “Using Authentication Services”

Set up authentication schemes and use them in
policy

Chapter 8: “Security and Authentication”

Chapter 1: Introducing the ProxySG

Table 1.4: Bridging
Task

Reference

Configure bridging (hardware or software)

"Software and Hardware Bridges"

Allow those from outside a bridged deployment
to get to internal servers

"Defining Static Routes"

Table 1.5: HTTP
Task

Reference

Redirect HTTP with WCCP

"Standard HTTP Redirection"

Table 1.6: HTTPS
Task

Reference

Create a transparent HTTPS service

"HTTP"

Table 1.7: Management
Task

Reference

Get the Management Console to work

Chapter 3: “Accessing the ProxySG”

Manage the System:
• License the system

• Chapter 2: “Licensing”

• View statistics

• Chapter 21: “Statistics”

• Resources
• Efficiency
• SNMP monitoring

• Chapter 21: “Statistics”

Table 1.8: Policy
Task

Reference

Set up authentication schemes and use them in
policy

Chapter 8: “Security and Authentication”

Limit network access and configuring
compliance pages

"Section B: Controlling Access to the Internet and Intranet"

Block unwanted content

"How to Apply Policy to Categorized URLs"

Change policy default

"Transaction Settings: Deny and Allow"

31

Blue Coat ProxySG Configuration and Management Guide

Table 1.8: Policy
Write policy using the Visual Policy Manager
(VPM)

"Section E: Tutorials"

Write policy using the Content Policy Language
(CPL)

Blue Coat Content Policy Language Guide

Table 1.9: Proxies
Task

Reference

Determine the best type of proxy for the
environment

Chapter 6: “Configuring Proxies”

Get traffic to the proxy

Chapter 6: “Configuring Proxies”

Table 1.10: Reporter, Blue Coat
Task

Reference

Make Blue Coat Reporter work with access
logging

" Customizing the Log: Configuring the Upload Schedule";
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.11: Reporter, SurfControl
Task

Reference

Configure SurfControl Reporter

" Using SurfControl Reporter with SGOS 3.x"

Table 1.12: Services
Task

Reference

Create a port service

"Section B: Creating and Editing Services"

Table 1.13: Streaming

32

Task

Reference

Control streaming protocols

Chapter 15: “Streaming Media”

Chapter 1: Introducing the ProxySG

Table 1.14: WCCP
Task

Reference

Configure WCCP for multiple ports

"Creating a Configuration File"

Redirect HTTP with WCCP

"Standard HTTP Redirection"

Configure the home-router IP

"Creating a Configuration File"

Configure multiple home-routers

"Creating a Configuration File"

Configure a multicast address as the proxy's
home router

"Configuring a WCCP Version 2 Service on the Router"

About the Document Organization
This document is organized for easy reference, and is divided into the following sections and chapters:
Table 1.1: 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 chapters describes which features
require licenses.

Chapter 3 – Accessing the ProxySG

This chapter explains how to log in to the ProxySG command
line interface 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
covers 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 kinds of proxy you should use.

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.

33

Blue Coat ProxySG Configuration and Management Guide

Table 1.1: Document Organization (Continued)
Chapter Title

Description

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 – External Services

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

Chapter 11 – Health Checks

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

Chapter 12 – 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 13 – The Visual Policy Manager

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

Chapter 14 – Advanced Policy

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

Chapter 15 – Streaming Media

This chapter discusses streaming, including the new RTSP
proxy.

Chapter 16 – Instant Messaging

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

Chapter 17 – 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 18 – Configuring the Upstream
Networking Environment

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

Chapter 19 – Access Logging

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

Chapter 20 – Maintaining the ProxySG

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

Chapter 21 – 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 NTLM agent is discussed in this appendix.

Appendix B – Access Log Formats

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

Appendix C – Using WCCP

How to configure and use 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 – Using Regular Expressions

Regular expressions (regex) are explained in this appendix.

Appendix F – Diagnostics

Determining and resolving ProxySG problems are discussed
in this appendix.

Appendix G – Using Blue Coat Director to Manage Discusses how Blue Coat Director works with multiple
Multiple ProxySG Appliances
ProxySG Appliances.

34

Chapter 1: Introducing the ProxySG

Note:

The Blue Coat Configuration and Management Guide and the online help contain the same
information but are not identical. For the latest information, refer to the Blue Coat Configuration
and Management Guide.

Related Blue Coat Documentation


Blue Coat 6000 and 7000 Installation Guide



Blue Coat 400 Series Installation Guide



Blue Coat 800 Series Installation Guide



Blue Coat 8000 Series Installation Guide



Blue Coat Content Policy Language Guide



Blue Coat Command Line Interface Reference

Document Conventions
The following section lists the typographical and Command Line Interface (CLI) syntax conventions
used in this manual.
Table 1.2: Typographic Conventions
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.

35

Blue Coat ProxySG Configuration and Management Guide

36

Chapter 2:

Licensing

This chapter describes the ProxySG licensing behavior.

About Licensing
SGOS 3.x introduces a global licensing system for the ProxySG. This system improves the correlation
between deployed ProxySG appliances and allows for improved communication with Blue Coat
Systems Customer Support.
In previous SGOS releases, licenses for features that required them were entered on the feature-specific
panel in the Management Console. SGOS 3.x uses one global license key that includes licenses for
whichever ProxySG features you have elected to use. Licenses are issued on a per-appliance basis.

Licensable Components
The following table lists the ProxySG licensable components.
Table 2.1: Licensable Components
Component

Description

SGOS 3

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

SSL Termination

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

3rd Party Onbox Content
Filtering

Allows use with third-party vendor databases, such as Smartfilter, Websense, and
SurfControl.

Websense Offbox Content
Filtering

For Websense off-box support only.

ICAP Services

External virus and content scanning with ICAP servers.

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.

Windows Media Streaming

Refer to "Streaming Licenses".

Real Media Streaming

Refer to "Streaming Licenses".

QuickTime Streaming

Refer to "Streaming Licenses".

Netegrity SiteMinder

Allows realm initialization and user authentication to SiteMinder servers.

Streaming Licenses
There are two types of Windows Media and Real Media licenses available, but only one QuickTime
license type.
The following table describes each streaming media license type.

31

Blue Coat ProxySG Configuration and Management Guide

Table 2.2: Streaming Licenses Available
License Type

Description

Windows Media
Standard

MMS proxy; no caching or splitting; content pass-through.

Windows Media
Premium

MMS proxy; content caching and splitting.

Full policy control over MMS.
Full policy control over MMS.
When the maximum concurrent streams is reached, all further streams are denied and
the client receives a message.

Real Media Standard

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

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.

QuickTime Basic

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

About the Trial Period
Blue Coat provides a trial period. For the first 60 days, all licensable components are active and
available to use. The initial system boot-up triggers the 60-day trial, which is a grace period you can
use to register the ProxySG and SGOS 3.x with Blue Coat.
Note:

If you require more time to explore the ProxySG features, a demo license is available; refer to
the Blue Coat product registration Web site.

Each time the Management Console home page or Maintenance>Licensing tab is clicked, a pop-up
dialog appears warning the user that the trial period expires in so many days (a text message is
displayed on a Telnet, SSH, or serial console).
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, Base SGOS, 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.

About License Expiration
At the end of the trial period or 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, and users are notified of the license expiration.
If a license expires, users might not be informed, depending upon the application they are using:


32

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

Chapter 2: Licensing



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.



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 login connection has failed.



FTP clients—If the FTP clients 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.

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

System Serial Number Prerequisite
As each ProxySG serial number is the appliance identifier used to assign a license key, the serial
number must be recognized before a license can be installed. If the ProxySG contains an EEPROM
with the serial number encoded, the serial number is recognized upon system boot-up. If not, the
serial number must be entered manually before a license can be installed.
To verify a serial number is defined:


In the Management Console, navigate to Configuration>General>Identification. If a serial number
exists in the Serial Number field, the ProxySG is ready to be registered and licensed.



In the Management Console, navigate to Maintenance>Licensing>Install. If Request is active, a serial
number has been entered or detected and the ProxySG is ready to be registered and licensed. If
Request is greyed-out, a serial number must be entered.



In the Management Console, navigate to Maintenance>Licensing>View. If a serial number has been
entered or detected, it appears in the Hardware Serial Number line. If the line is blank, a serial
number must be entered.

To enter a serial number, see "Configuring the Serial Number" on page 54.

Registering with Blue Coat
When your ProxySG was shipped from Blue Coat, a corresponding license key was created that
licenses the system with the set of base and value-added software components. Before you can obtain
this license, you must register the ProxySG and obtain a Blue Coat WebPower user account.
To Register with Blue Coat through the Management Console:
1.

Select Maintenance>Licensing>Install.
In the License Administration field, click Register/Manage.A new window opens to the Blue Coat
ProxySG Registration page.

33

Chapter 2: Licensing

Each licensable component is listed, along with its validity state 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 maximum
number of streams allowed.

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

4.

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

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 or deselect 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}

37

Blue Coat ProxySG Configuration and Management Guide

Note:

38

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

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 privilege
mode (enable/configuration) password. These passwords are always stored and displayed hashed.
This chapter discusses:


"Before You Begin: Understanding Modes"



"Accessing the ProxySG"



"Management Console Home Page"



"Changing the Login 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 into 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 3.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 entered when you first access the CLI.



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 entered when you first access the
Management Console.



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

39

Blue Coat ProxySG Configuration and Management Guide

If you use the Management Console, you are in configuration mode when you are completely logged
into 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 Command Line
Interface 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 a SSHv1 host key. For more information on creating SSH host
keys, see "Configuring the SSH Console" on page 47.
To login to the CLI, you must have:


the account name that has been established on the ProxySG



the IP address of the ProxySG



the port number (8082 is the default port number)

You must login 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.

40

Chapter 3: Accessing the ProxySG

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

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

Changing the ProxySG Realm Name
The realm name displays when you log in to the ProxySG Management Console. The default realm
name is the connection used to access the ProxySG, usually the IP address of the system.
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 into 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

45

Blue Coat ProxySG Configuration and Management Guide

The new realm name displays the next time you log into 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.

Click Apply.

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

46

Chapter 3: Accessing the ProxySG

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

47

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 into 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 Open SSH.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 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:

49

Blue Coat ProxySG Configuration and Management Guide

52

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


"Global Configurations"



"Archive Configuration"



"Adapters"



"Software and Hardware Bridges"



"Gateways"



"Defining Static Routes"



"Using RIP"



"DNS"



"Attack Detection"



"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 the need to change a configuration occurs.

Global Configurations
The ProxySG global configurations include: defining the ProxySG name and serial number, setting the
time, and configuring NTP for your environment.

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 General tab displays.

53

Blue Coat ProxySG Configuration and Management Guide

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.

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.

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.

56

Blue Coat ProxySG Configuration and Management Guide

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.

2.

Select an NTP server to promote or demote.

3.

Click Promote entry or Demote entry as appropriate.

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 will wait 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:

58

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.

Chapter 4: Configuring the System

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.
To share configurations among systems, continue with the next section; to archive a configuration for
later use, skip to "Archiving a Configuration" on page 62.

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 that are established 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 G: “Using
Blue Coat Director to Manage Multiple Appliances” on page 849.

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.

59

Chapter 4: Configuring the System

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.

5.



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.

Click Close.

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:
SGOS# show configuration {post-setup | brief | expanded]

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

brief

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

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.

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. (You will 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:


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:
At the enable command prompt, enter the following command:
SGOS# configure network “url”

61

Blue Coat ProxySG Configuration and Management Guide

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 all 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 login 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
login or to require a username and password.

Preparing 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.
Note:

62

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

Chapter 4: Configuring the System

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 756.
SGOS#(config) archive-configuration username user_name

where user_name 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”

63

Blue Coat ProxySG Configuration and Management Guide

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@

Adapters
This section describes ProxySG network adapters and interfaces.

About Adapters
ProxySG Appliances ship with one or more network adapters. 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 adapters and interfaces. When you initially set up the ProxySG, you
optionally configured 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:

64

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

Chapter 4: Configuring the System

3.

Click Settings.

4.

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

5.

Click OK to close the Settings dialog.

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_#) no accept inbound
SGOS#(config interface interface_#) 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 interface_#
SGOS#(config interface interface_#) full-duplex | half-duplex
SGOS#(config interface interface_#) speed 10 | 100 | 1gb
SGOS#(config interface interface_#) exit

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

67

Blue Coat ProxySG Configuration and Management Guide

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

Software and Hardware Bridges
This section describes the ProxySG hardware and software bridging capabilities.

About Bridging
Network bridging through the ProxySG provides transparent proxy pass-through and failover
support. This functionality allows ProxySG Appliances to be deployed 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 card. This
type of bridge provides pass-through support.

About the Pass-Through Card
A pass-through card is a 10/100 dual port Ethernet adapter designed by Blue Coat to provide an
efficient fault-tolerant bridging solution. If this card is installed on a ProxySG, SGOS detects the card
upon system bootup and automatically creates a bridge—the two Ethernet ports 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 port 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:

68

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

Blue Coat ProxySG Configuration and Management Guide

7.

8.

Further customize the bridge:
a.

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

b.

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

c.

In the Browser Configuration field, the default browser instruction is to use the browser’s
default PAC file. To use a proxy or other PAC file type, select from the list.

Click Apply.

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

At the (config) command prompt, enter the following commands:
SGOS#(config) bridge
SGOS#(config bridge) edit bridge_name

where name designates the bridge name. The limit is 16 characters.
SGOS#(config bridge bridge_name) ip-address ip_address

where ip_address designates the IP address of the interface.
SGOS#(config bridge bridge_name) subnet-mask subnet_mask

where subnet_mask designates the subnet mask of the interface.
2.

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

where port_number identifies a port on the interface.


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



To attach a port to an interface or change the Duplex and Speed options, enter the following
commands:
SGOS#(config bridge
interface_number
SGOS#(config bridge
SGOS#(config bridge
SGOS#(config bridge

70

bridge_name port port_number) attach-interface
bridge_name port port_number) full-duplex
bridge_name port port_number) half-duplex
bridge_name port port_number) speed {10 | 100 | 1gb}

Chapter 4: Configuring the System

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)

3.

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

4.

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

5.

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

url

Use the PAC file specified at the given URL.
Use the proxy’s accelerated PAC file.

Configuring Failover
You can configure failover for software bridges, not hardware bridges. Failover is accomplished by
creating virtual IPs 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.4) master
ProxySG_A#(config failover 10.0.0.4) priority 100
ProxySG_A#(config failover 10.0.0.4) interval 1

71

Blue Coat ProxySG Configuration and Management Guide



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.4) priority 100
ProxySG_B#(config failover 10.0.0.4) 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 Tables
Certain firewall configurations require the use of static forwarding tables. 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.
The solution is to create a static forwarding table that defines the next hop gateway that is on the
correct side of the bridge.
Note:

A port must have an interface attached to allow creation of the static forwarding table, and
you can only create one forwarding table per bridge.

To Create a Static Forwarding Table through the CLI:
1.

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

2.

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

Add up to 256 entries per bridge.

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

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

72

Chapter 4: Configuring the System

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.

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

73

Blue Coat ProxySG Configuration and Management Guide

Take care to choose a unique end-of-input string that does not match any string of characters in the
configuration information.
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

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. (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 811.
Once you have created an RIP configuration file, you can install it several ways:

78



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.

Chapter 4: Configuring the System

4.

Click Apply.

5.

Select Enable RIP.

6.

Click Apply.

Configuring RIP 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 eofm

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_marker command.
Example
SGOS#(config) inline rip-settings eofm
ripv2
ripv1_out
no_rdisc eofm
ok

DNS
During first-time installation of the ProxySG, you configured the IP address of a single primary 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.

ProxySG Specifics
If you have defined more than one Domain Name Service (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:

81

Blue Coat ProxySG Configuration and Management Guide



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, ProxySG returns an error to the client.



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), 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 attempt 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 the host name cannot be translated to an IP
address, 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 that the host
name could not be resolved. If the first alternate DNS server is unable to resolve the host name, an
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 an error to the client if none of the
servers in a DNS server list responds to the DNS request. The ProxySG only sends requests to servers
in the alternate DNS server list if a server in the primary list returns a response indicating that the host
name could not be translated to an IP address.
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 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 steps 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.

82

Chapter 4: Configuring the System

2.

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

3.

Enter the name 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 DNS name inputing through the CLI.
To Change the Order through the Management Console:
1.

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

2.

Select the imputing suffix to promote or demote.

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.

85

Blue Coat ProxySG Configuration and Management Guide

To Restore Negative Caching Defaults:
From the (config) prompt):
SGOS#(config) dns no negative-cache-ttl-override

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 website. As the attack progresses, the target host shows decreased responsiveness and
often stops responding. Legitimate HTTP traffic will be unable to proceed because the ProxySG is still
waiting for a response from the target host.
Port scanning involves viruses trying 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 will not respond to connection attempts from a client already at this limit
or will reset 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.
For information on configuring a client, continue with the next section. To configure a server for attack
detection, continue with "Configuring Attack-Detection Mode for a Server or Server Group" on
page 91.

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:

86



client limits enabled: true



client interval: 20 minutes

Chapter 4: Configuring the System



block-action: drop (for each client)



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 will not be 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

87

Blue Coat ProxySG Configuration and Management Guide

where:
enable-limits |
disable-limits

Toggles between enabled and disabled. The default is
disabled. Note that this is a global setting and cannot be
modified for individual clients.

interval

integer

Indicates the amount of time, in multiples of 10 minutes,
that client activity is monitored. The default is 20. Note that
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: 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.

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

3.

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

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

88

Chapter 4: Configuring the System

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

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

89

Blue Coat ProxySG Configuration and Management Guide

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

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)

90

Chapter 4: Configuring the System

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

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

where:
hostname

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.

add | remove
request-limit

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

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

Using a Bypass List
A bypass list prevents the ProxySG from transparently accelerating requests to servers that perform IP
authentication with clients. 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. A bypass list is only used for transparent caching.
There are three types of bypass lists: local list, central list, and policy-based list. Each of these bypass
lists are discussed below.
The first two lists are not the same as the Local Policy file and the Central Policy file. The policy-based
bypass list is a list maintained in the Forward Policy file or Local Policy file.
The local and central bypass lists can be managed two ways: either through the Management Console
or through the CLI. For installation procedures for the two lists, see "Creating and Installing Local or
Central Bypass Lists" on page 97.

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. You can also use a dynamic local bypass list to increase
ProxySG efficiency. For more information on dynamic bypass lists, see "Using Dynamic Bypass" on
page 93.

91

Blue Coat ProxySG Configuration and Management Guide

The gateways specified in the bypass list must be on the same subnet as the ProxySG. Note also that
you are limited to 10,000 entries in the local bypass list.
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.
The following is a sample of a local 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

Note:

The BYPASS_GATEWAY and default gateway must be on a different subnet from the IP
addresses.

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

Using Dynamic Bypass
Dynamic bypass provides a maintenance-free method for improving performance of the ProxySG by
automatically compiling a list of requested URLs that return various kinds of errors.
With dynamic bypass, the ProxySG adds dynamic bypass entries containing the server IP address of
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 server, 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 origin server. If
the origin server 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.
Dynamic bypass increases ProxySG efficiency because redundant attempts to contact the origin server
are minimized.

Limitations


92

Dynamic bypass applies to transparent proxy connections only.

Chapter 4: Configuring the System



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 will bypass future policy evaluation.
Therefore, if a site that requires forwarding policy to reach its destination is populated into the
dynamic 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.

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 will 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, and/or DYNAMIC_TIMEOUT values. This

step is optional, as 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 will be 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 will cause 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

93

Blue Coat ProxySG Configuration and Management Guide

where trigger_event can be any item in listed in Table 4.1 on page 95.
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 server, including
timeouts.

receive-error

Enables dynamic bypass for when a TCP connection to an origin 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 server, including timeouts, inserts
the origin server destination IP address into the dynamic bypass list. From 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.
If receive-error is enabled, when the cache does not receive an HTTP response on a successful TCP
connection to the origin server, the origin server destination IP address is inserted into the dynamic
bypass list. From 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 58).

94

Chapter 4: Configuring the System

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

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

95

Blue Coat ProxySG Configuration and Management Guide

Using the Central Bypass List
The central bypass list is a shared list of addresses that is used by multiple ProxySG Appliances. The
central list contains addresses to bypass, but does not specify gateways (because the ProxySG
Appliances are located on different subnets, using different gateways). The gateway used for matches
in the central bypass list is defined using 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.
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/SG3/files/CentralBypassList.txt
Note:

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

The central bypass list maintained by Blue Coat contains addresses Blue Coat has identified as using
client authentication. You can determine whether to download the list automatically when it changes
or to just be sent 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).



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 92 or "Using the Central Bypass
List" on page 97.

To Install Bypass Lists through the Management Console:
1.

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

96

Chapter 4: Configuring the System

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

Policy-Based Bypass Lists
ProxySG policies support the ability to define bypass lists. This section describes a property used to
define a policy-based bypass list that can go into the Local Policy or Forward Policy file. For more
information on defining policies, refer to the Blue Coat Content Policy Language Guide.
While static and dynamic bypass lists allow traffic to bypass the ProxySG based on a destination IP
address, the bypass_cache property is intended to allow a bypass based on the properties of the
client. This property uses the following syntax:
bypass_cache(yes | no)

If set to yes, the ProxySG is not queried and the response is not stored. Set to no to specify the default
behavior, which is to follow standard caching behavior. This property is available only in the
layer.
This property has no effect on streaming objects, but does affect the following types of transactions:
HTTP, HTTPS, FTP over HTTP, and transparent FTP.
Example
; Bypass the cache for requests from this client IP.
client_address=10.25.198.0 bypass_cache(yes)

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.

99

Blue Coat ProxySG Configuration and Management Guide

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:

4.

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

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

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 68.
Note:

104

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

Chapter 4: Configuring the System

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

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

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 64.
You also need to decide which machine will be the master and which machines will be 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.

105

Chapter 4: Configuring the System

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.



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

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

107

Blue Coat ProxySG Configuration and Management Guide

where:

2.

group_address

Refers to the IP address or VIP address that will be 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.) Note that 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 will then be 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
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

108

Blue Coat ProxySG Configuration and Management Guide



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.



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

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}

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 will be jammed with ICMP echo reply packets, making the network unusable. By disabling
ICMP broadcast echo response, the ProxySG will not 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 87.

110

Chapter 4: Configuring the System

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, by disabling the ICMP timestamp echo commands, you can prevent 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}

PMTU Discovery
PMTU (Path Maximum Transmission Unit) is a mechanism designed to discover the largest packet
size that can be sent that will not be 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.
Configuring 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

111

Blue Coat ProxySG Configuration and Management Guide

where
tcp-ip
pmtu-discovery

enable | disable

Allows you to enable PMTU discovery. The
default is disabled.

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.

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 window size:

112

enabled
disabled
disabled
disabled
disabled
enabled
600 seconds
120 seconds
65535 bytes

Chapter 4: Configuring the System

113

Blue Coat ProxySG Configuration and Management Guide

114

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 10: “External Services” on page 321.
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 137:


FTP Proxy



HTTP Proxy



SOCKS Proxy



Shell Proxies (Telnet)

113

Blue Coat ProxySG Configuration and Management Guide

Section A: Managing Multiple Management Consoles

Section A: Managing Multiple Management Consoles
The ProxySG ships with 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 to gain 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).

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 meant only for
accessing the ProxySG. An HTTPS service is meant to allow secure access to other systems.
Creating a new HTTPS Console port requires three steps, discussed more fully in the following
sections:


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

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, simply accept the default keyring through the Management Console, or, if
you’re using the CLI, enter default for the keyring ID when using the services https-console
create command.
Note:

114

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 "Troubleshooting
Certificate Problems" on page 195.

Chapter 5: Managing Port Services

Section A: Managing Multiple Management Consoles
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:
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

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.

To Create or Edit a Telnet Console Port Service through the Management Console:
Before you begin, make sure 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, being sure to use a different port. For information on the Telnet service, see"Telnet Shell Proxy
Service" on page 134.
1.

Select Configuration>Services>Service Ports.
The Service Ports tab displays.

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.

119

Chapter 5: Managing Port Services

Section B: Creating and Editing Services

Section B: Creating and Editing Services
Port services define attributes for ports on which the ProxySG listens for Web requests. Each service
applies to all IP addresses, or can be limited to a specific address.
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. So you can have HTTP listening on a given port on some subset of interfaces (or
VIPs), but you can't have HTTP on one interface and HTTPS on a different interface with both
using the same port.
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

Default

Configuration Discussed

DNS

53 (both transparent and explicit)

Disabled

"DNS-Proxy"

FTP

21 (transparent and explicit

Disabled

"FTP"

HTTP

80 (transparent and explicit)

Enabled

"HTTP"

HTTP

8080 (explicit only)

Enabled

"HTTP"

HTTP-Console

8081

Disabled

"HTTP Console"

HTTPS

Disabled

"HTTPS"

HTTPS-Console

8082

Enabled

"HTTPS Console (Secure Console)"

MSN-IM

1863 (transparent and explicit) and
6891 (transparent and explicit)

Disabled

"Instant Messaging Protocols"

Yahoo-IM

5050 (transparent and explicit) and
5101 (transparent and explicit)

Disabled

"Instant Messaging Protocols"

AOL-IM

5190 (transparent and explicit)

Disabled

"Instant Messaging Protocols"

MMS

1755 (transparent and explicit)

Disabled

"Streaming Protocols"

RTSP

554 (transparent and explicit)

Disabled

"Streaming Protocols"

SOCKS

1080

Disabled

"SOCKS"

SSH-Console

22

Enabled

"SSH Console"

Disabled

"TCP Tunneling"

Telnet-Console

23

Disabled

"Telnet Console"

Telnet shell
proxy

23

Disabled

"Telnet Shell Proxy Service"

TCP-Tunnel

121

Blue Coat ProxySG Configuration and Management Guide

Section B: Creating and Editing Services
Note:

If HTTP is configured to be explicit, Internet Explorer version 5.5 and 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. In addition to
configuring the default port services, you can create additional ports and define their attributes.
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 port. (Explicit allows connections to a
ProxySG 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.)

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.

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:

122

The ProxySG is not a DNS server. It does not perform zone transfers, and recursive queries are
forwarded to other name servers.

Blue Coat ProxySG Configuration and Management Guide

Section B: Creating and Editing Services
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

where:

3.

attribute

explicit | transparent | Give the DNS proxy explicit and transparent
send-client-ip enable
attributes, and create IP spoofing (where the ProxySG
[ip_address:]port
pretends to be a client so the OCS can see the client’s
IP address).

enable

[ip_address:]port

Enable the new Telnet shell 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 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)

124

Chapter 5: Managing Port Services

Section B: Creating and Editing Services
6.

In the Attributes field, select all that apply: Explicit, Transparent, Authenticate-401, or Send-client-IP.

7.

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

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

HTTPS
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.
The Service Ports tab displays.

2.

Click New; the Add Service dialog appears.

3.

Select HTTPS from the Protocol drop-down list.

127

Chapter 5: Managing Port Services

Section B: Creating and Editing Services
Note:

To create client-certification lists and keyrings, see "Configuring HTTPS Termination" on
page 176.

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

2.

(Optional) View the results:
SGOS#(config services https) view
Port:
1000
IP: 10.9.17.159
Type: https
Keyring: default
Properties: explicit, enabled
SSL Protocol version: SSLv2v3TLSv1
CA Certificate List: not configured
Cipher suite:
RC4-MD5:RC4-SHA:DES-CBC3-SHA:DES-CBC3-MD5:RC2-CBC-MD5:RC4-64-MD5:DES-CBC-SHA:DE
S-CBC-MD5:EXP1024-RC4-MD5:EXP1024-RC4-SHA:EXP1024-RC2-CBC-MD5:EXP1024-DES-CBC-S
HA:EXP-RC4-MD5:EXP-RC2-CBC-MD5:EXP-DES-CBC-SHA:+SSLv2:+SSLv3+LOW:+SSLv2+LOW:+EX
PO

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. Note that 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.
The Service Ports tab displays.

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:


AOL— Port 5190

129

Blue Coat ProxySG Configuration and Management Guide

Section B: Creating and Editing Services

5.



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

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

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.
The Service Ports tab displays.

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.

130

At the (config) command prompt, enter the following commands:

Chapter 5: Managing Port Services

Section B: Creating and Editing Services
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

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

SOCKS
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 619.
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:
1.

Select Configuration>Services>Service Ports.
The Service Ports tab displays.

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.

131

Blue Coat ProxySG Configuration and Management Guide

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 where you want the ProxySG to listen. 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, you have completed the procedure. If you created an
explicit TCP-Tunnel service, you must configure a forwarding destination port.
Configuring 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

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: If you want 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 "Telnet Console" on page 119.

134

Blue Coat ProxySG Configuration and Management Guide

Section B: Creating and Editing Services
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

attribute

explicit | transparent | Give the Telnet shell proxy explicit and transparent
send-client-ip enable
attributes, and create IP spoofing (where the ProxySG
[ip_address:]port
pretends to be a client so the OCS can see the client’s
IP address).

enable

[ip_address:]port

Create a Telnet shell proxy service at the (optional)
address and port number.

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

136

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


"Section A: About Explicit and Transparent Proxy"



"Section B: Configuring Explicit Proxies"



"Section C: Transparent Proxies"

137

Chapter 6: Configuring Proxies

Section A: About Explicit and Transparent Proxy

Section A: 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.

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. Since 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 server and the resource on that server. The proxy service uses this
information to contact the origin server 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.

Transparent Proxy
When transparent proxy is enabled, the client (browser) does not know the traffic is being processed
by a machine other than the origin server. The browser believes it is talking to the origin server, so the
request is formatted for the origin server, 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 169.

138

Chapter 6: Configuring Proxies

Section B: Configuring Explicit Proxies

Section B: Configuring Explicit Proxies
You can configure several different explicit proxy servers and services:


Native FTP—See "Configuring the FTP Proxy" on page 140.



HTTP Proxy—See "Configuring an HTTP Proxy" on page 147.



SOCKS—See "Configuring a SOCKS Proxy" on page 160.



Shell Proxies—See "Customizing Policy Settings for Shell Proxies" on page 163

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

139

Blue Coat ProxySG Configuration and Management Guide

Section B: 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 6.2:
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 105.

Interface Proxy Settings
Once the explicit proxy is configured on the browser, decide which interface cards listen for which
service. Each interface card 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 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 servers were only accomplished over HTTP.
SGOS 3.x supports Native FTP proxy.
Note:

140

As in previous releases, FTP requests sent through the HTTP proxy are still valid.

Chapter 6: Configuring Proxies

Section B: Configuring Explicit Proxies
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.

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

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.

141

Blue Coat ProxySG Configuration and Management Guide

Section B: Configuring Explicit Proxies


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

Select Configuration>Services>FTP Proxy.
The FTP Proxy tab displays.

142

Chapter 6: Configuring Proxies

Section B: Configuring Explicit Proxies

Configuring an 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 "HTTP" on
page 126.
The HTTP proxy is the first line of defense for the ProxySG, controlling all traffic that arrives on port
80 to the ProxySG. You can also configure the HTTP proxy as a server accelerator to improve response
times.
You can set a limit to the maximum bandwidth the ProxySG is allowed to use for refreshing objects in
the background. In most situations, however, the default settings produces optimal performance.
Terms:


Caching Policy—The HTTP Proxy policy determines the maximum size of objects to cache and
the number of minutes the ProxySG remembers that an object is not stored, as well as whether to
verify the freshness of an object (an option that can affect performance) and whether to verify
server certificates for secure connections.



Freshness—Guarantees that all objects served from the ProxySG are current. An object is fresh if its
age does not exceed its freshness lifetime.



HITs—Objects that are in the ProxySG and can be retrieved when an end user requests the
information.



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.



MISSes—Objects that can be stored but have never been requested before are called MISSes; they
were not in the ProxySG to start, so they 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.



Negative Responses—If the ProxySG receives an origin server error response code indicating, for
example, that the requested page or image does not exist, it caches that negative response. 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—If set to zero, the ProxySG does not do active refresh.



Server Acceleration Profile—Normal (the default), Portal, or Bandwidth Gain, to cause the
ProxySG to behave as a server accelerator and help improve object response time.

For more information on controlling HTTP proxy traffic, continue with the next section. For more
information on using the HTTP proxy as a server accelerator, see "Controlling the HTTP Proxy Profile"
on page 153.

147

Blue Coat ProxySG Configuration and Management Guide

Section B: Configuring Explicit Proxies

Controlling HTTP Proxy Traffic
With the HTTP proxy, you can control which objects are stored in the ProxySG, how long they are
stored, how often the objects are verified that the content has not changed. You can also change the
profile for the HTTP proxy, allowing you to configure the proxy for accelerated performance, or leave
it at a normal setting.
To control HTTP proxy traffic, you can configure the following settings:


"Refresh Bandwidth" on page 148



"Setting Proxy Policies" on page 150: This includes setting maximum object size, meta tag headers,
strict HTTP parsing.



"Controlling the HTTP Proxy Profile" on page 153: You have three profiles to choose among:
normal, bandwidth, or portal.

Refresh Bandwidth
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 examine 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 manage refresh bandwidth), 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.

Select Configuration>Services>HTTP Proxy>Freshness.
The Freshness tab displays.

148

Chapter 6: Configuring Proxies

Section B: Configuring Explicit Proxies


In the Cache negative responses for field, enter the number of minutes the ProxySG remembers
that the object is not stored. The default is 0, meaning that the ProxySG will not remember and
will always attempt to retrieve the object.
When the ProxySG receives an origin server error response code indicating, for example, that
the requested page or image does not exist, it caches that negative response. 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.



To always verify that each object is fresh, select the Always check with source before serving object
checkbox. Remember that this affects performance.



If you communicate with the origin server through HTTPS and want the origin server's
certificate to be verified by the ProxySG, make sure that the Verify server certificate for secure
connection checkbox is checked.
Note:

If the ProxySG HTTPs service is configured to require a client certificate, 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.



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

Setting Proxy Policies through the CLI:
1.

At the (config) command prompt, enter the following commands:
SGOS#(config) caching
SGOS#(config caching) max-cache-size megabytes
SGOS#(config caching) negative-response minutes
SGOS#(config caching) no always-verify-source

151

Blue Coat ProxySG Configuration and Management Guide

Section B: Configuring Explicit Proxies
where:
max-cache-size

The maximum size, in megabytes, of the largest object that
can stored on the ProxySG. Note that 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.

always-verifysource

Ensures that every object is always fresh. This severely
impacts performance.

no

2.

megabytes

always-verify The default is no always-verify-source. This tells the
source
ProxySG never to check objects on the source before serving
them to the client.

(Optional) If you use HTTPS, you might want to change the verify-server certificate from the
default of enabled to suppress verification of the origin server certificate:
SGOS#(config caching) exit
SGOS#(config) services
SGOS#(config services) https
SGOS#(config services) https attribute verify-client disable

Note:

If the ProxySG HTTPs service is configured to require a client certificate, 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.

3.

(Optional) To disable meta-tag parsing (parsing is enabled by default), enter the following
command:
SGOS#(config services) exit
SGOS#(config) http no parse meta-tag {cache-control | expires | pragma-no-cache}

To view all HTTP settings, see "Viewing the HTTP Settings through the CLI" on page 159.
Tips on Parsing Meta Tags


If ICAP response modification is occurring, the response body modified by ICAP server is not
parsed.



Relevant HTTP meta tags must appear within the first 1000 bytes of 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


152

The following meta tags can be used in the layer for HTTP proxy, HTTP refresh, and
HTTP pipeline transactions:

Chapter 6: Configuring Proxies

Section B: Configuring Explicit Proxies
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.

Tolerant HTTP Request Parsing
The tolerant HTTP request parsing flag prevents certain syntax errors in an HTTP request from
generating a 400 Invalid Request error.
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 doesn't 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.
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
the HTTP Settings through the CLI" on page 159.

Controlling the HTTP Proxy Profile
When configured as a server accelerator, the ProxySG improves object response time to client requests,
scalability of the origin server site, and overall Web performance at the origin server. A server
accelerator services requests meant for an origin server as if it is the origin server itself.
Because an origin server can actually consist of many servers—a single Web server or an entire server
farm—origin servers are identified by domain name or IP address. To the ProxySG, the domain name
or IP address is treated as the origin server, regardless of how many back-end Web servers might be
installed.
When a ProxySG is first manufactured, it is set to a Normal profile. You can also use a Bandwidth Gain
profile or the Portal profile. You can also combine needed elements of all three profiles.

153

Chapter 6: Configuring Proxies

Section B: Configuring Explicit Proxies
Note:
2.

You can customize the settings, no matter which button you select.

Click Use Bandwidth Gain Profile or Use Portal Profile.
The default settings change to reflect the new profile.

3.

Click Apply.

To Switch Profiles through the CLI:
1.

At the (config) command prompt, enter the profile you want:
SGOS#(config) profile {normal | portal | bwgain}

Note:

2.

You cannot mix and match profiles through the CLI. Customizing the profile is only
available through the Management Console.

(Optional) View the settings. (This example assumes you have selected the Portal profile.)
SGOS#(config) show profile
SG is currently using the Portal Profile
Pipeline client requests:
Pipeline client redirects:
Pipeline prefetch requests:
Pipeline prefetch redirects:
Substitute Get “if-modified-since”:
Substitute Get “pragma: no-cache”:
Substitute HTTP 1.1 Conditional Get:
Substitute Internet Explorer reload:
Never refresh before expiration:
Never serve after expiration:
Cache expired objects:
Bandwidth gain mode:

Disabled
Disabled
Disabled
Disabled
Enabled
Enabled
Enabled
Enabled
Enabled
Enabled
Disabled
Disabled

You can view all HTTP settings. See "Viewing the HTTP Settings through the CLI" on page 159 for
more information.

Using Explicit HTTP Proxy with Internet Explorer
Internet Explorer does not allow origin content server (OCS) NTLM authentication through a
ProxySG when explicitly proxied. To correct this, Blue Coat has 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 origin server NTLM authentication challenge to pass through when Internet Explorer is
explicitly proxied through the ProxySG.

155

Chapter 6: Configuring Proxies

Section B: Configuring Explicit Proxies
CPL
Use CPL to define the Proxy-Support custom header object and to specify what action you want 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. Note that this CLI setting is global, affecting all clients. You can
also use VPM or CPL to provide granular control for NTLM authentication. (See "VPM" on page 157
and "CPL" on page 157.) These commands should only be used if the Proxy-support header is not
suitable for the situation.
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 the HTTP Settings through the CLI" on page 159.
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.

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.

157

Blue Coat ProxySG Configuration and Management Guide

Section B: Configuring Explicit Proxies
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

Byte Range Support
HTTP byte range support on the ProxySG can be enabled or disabled through the CLI. If byte range
support is disabled, then HTTP will treat all byte range requests as non-cacheable. This means that
HTTP will never even check to see whether the object is in the cache, but will forward the request to
the Origin Content Server (OCS) and not cache the result. Thus, a byte range request has no affect on
the cache when byte range support is disabled.
If byte range support is enabled (the default setting), the ProxySG will try to serve the byte range
request from the cache. With byte range support enabled, if the object is already cached and the
ProxySG does not need to reload the object from the OCS, the ProxySG will serve the byte range
request from the cache only. But if the object is not in the cache or if it requires a reload of the object
from the OCS, the ProxySG may treat the byte range request as if the byte range support is disabled.
Most download managers make byte range requests with a PNC (pragma-no-cache) header. In order
to serve such requests from the cache, you should also configure the PNC settings as described below.
For more information, see "Controlling the HTTP Proxy Profile" on page 153.

Configuring Byte Range Support
Byte range support can be enabled or disabled through the CLI. You cannot configure this setting
through the Management Console.
To Enable Byte Range Support through the CLI:
At the (config) command prompt, enter the following commands:
SGOS#(config) http byte-ranges

To Disable Byte Range Support through the CLI:
At the (config) command prompt, enter the following commands:
SGOS#(config) http no byte-ranges

158

Chapter 6: Configuring Proxies

Section B: Configuring Explicit Proxies
To Configure the PNC Setting through the CLI:
At the (config) command prompt, enter the following commands:
SGOS#(config) http revalidate-pragma-no-cache
-orSGOS#(config) http no revalidate-pragma-no-cache

To view all HTTP settings, see "Viewing the HTTP Settings through the CLI".

Viewing the HTTP Settings through the CLI
You can view the existing HTTP settings by entering the following command:
Note:

The tolerant-request-parsing option displays only if it is enabled.
SGOS#(config) show http
Supported protocol version: HTTP 1.1
Caching options:
Cache authenticated data: enabled
Cache expired objects:
enabled
Cache personal pages:
disabled
Reverse DNS lookup on IP: 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
"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

159

Blue Coat ProxySG Configuration and Management Guide

Section B: Configuring Explicit Proxies
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

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
SOCKS v4/4a and SOCKS v5; however, because of increased username and password authentication
capabilities, Blue Coat recommends that you use SOCKS v5.
Note:

For Blue Coat compatibility with SOCKS clients, check with customer support.

Configuring a SOCKS proxy requires two steps:


Creating and configuring the service



Creating and enabling the port service

Creating and Configuring the Service
Complete the following steps to create a SOCKS proxy and to configure SOCKS-proxy connection and
timeout values.
Note:

Policy allows you to control the version of SOCKS is accepted. For example, to use only
SOCKS v5, enter the following in the Local Policy file:

client.protocol=socks
ALLOW socks.version=5
DENY

To Create a SOCKS Proxy Server through the Management Console:
1.

Select Configuration>Services>SOCKS Proxy.
The SOCKS Proxy tab displays.

160

Chapter 6: Configuring Proxies

Section B: Configuring Explicit Proxies
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.4: 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

Interface number of the appliance on which this connection is accepted.

client.protocol

This is "telnet".

client.address

IP address of the client.

proxy.primary_address

Primary address of the proxy, not where the user is connected.

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

163

Blue Coat ProxySG Configuration and Management Guide

Section B: Configuring Explicit Proxies
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.
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 will not be 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.

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:

164



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.

Chapter 6: Configuring Proxies

Section B: Configuring Explicit Proxies


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 origin server 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 169.



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

Once in the shell, the following commands are available:


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 "Telnet Shell Proxy Service" on
page 134.

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.
The Telnet Proxy Settings Tab displays.

165

Blue Coat ProxySG Configuration and Management Guide

Section B: Configuring Explicit Proxies
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’s 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

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

168



Telnet credential exchange is in clear text.



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.

Chapter 6: Configuring Proxies

Section C: Transparent Proxies

Section C: 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 interface cards, 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 interface card, 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 interface
cards. 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 interface ports 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 69.

169

Blue Coat ProxySG Configuration and Management Guide

Section C: Transparent Proxies

Configuring a Layer-4 Switch for Transparent Proxy
In Transparent Proxy Acceleration, as traffic is sent to the origin server, 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 very 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, all you need to do is:

170



Define the appropriate IP configurations per the instructions in the Installation Guide that
accompanied the ProxySG.



Test the new network configuration.

Chapter 6: Configuring Proxies

Section C: 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 785.

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 interface card, 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

When upgrading to SGOS 2.x from CacheOS 4.x, the ProxySG retains the setting.
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 3.x.

171

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 RSA authentication) instead of Telnet for basic communication between machines.



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:


"HTTPS Termination Overview"



"Configuring HTTPS Termination"



"Managing the SSL Client"



"Enabling an HTTPS Service"



"Configuring HTTP or HTTPS Origination to the Origin Content Server"



"Configuring DNS Resolution to the Origin Content Server"

HTTPS Termination Overview
Offloading SSL processing from the origin server (referred to as HTTPS termination), allows more
requests to be processed more 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 is in conjunction with HTTPS origination. HTTPS
termination is used to connect the client to the ProxySG; HTTPS origination is used to connect from
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

173

Blue Coat ProxySG Configuration and Management Guide



Certificates



Keyrings



Cipher Suites



SSL client

There are many network infrastructure variables that must be considered in your key and certificate
management plan. A good publication that addresses such issues is Understanding Public-Key
Infrastructure; Concepts, Standards, and Deployment Considerations by Carlisle Adams and Steve Lloyd ISBN 1-57870-166-X.

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.
A keyring contains a public/private keypair. It can also contain a certificate signing request or a
signed certificate.

Certificates
Certificates are used to authenticate the identity of a server by associating a public key with a
particular server. A certificate is electronic confirmation of the owner of a public key, and contains
other information, such as its expiration date. Several kinds of certificates are used.

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.

CA Certificates
This association is performed by a certificate signing authority (CA), who verifies the identity of a
server and then signs the server's public key. 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 ssl view summary ca-certificate command.
Additionally, 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.

174

Chapter 7: Using Secure Services

External Certificates
An external certificate is an X.509 certificate created outside the ProxySG for the purpose of encrypting
access logs. 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
"Customizing the Log: Configuring the Upload Client" on page 655 for information about encrypting
access logs.

Wildcard Certificates
Wildcard certificates are certificates that contain wildcard characters in the common name field of an
X.509 certificate. Wildcards certificates are typically used in order to share a single certificate among
multiple hosts belonging to the same DNS domain.
Wildcard certificates during SSL termination are supported. Keep in mind that 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.

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

175

Blue Coat ProxySG Configuration and Management Guide

Table 7.1: SGOS Cipher Suites Shipped with the ProxySG
SGOS Cipher # Cipher Name

Strength

Exportable

Description

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.

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.

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.
Although only one SSL client exists on a ProxySG, the SSL client:


Determines which certificates can be presented to origin servers by associating a keyring with the
SSL client.



Identifies the protocol version the ProxySG uses in negotiations with origin servers.



Identifies the cipher suites used.

Configuring HTTPS Termination
To configure HTTPS termination, you must complete the following tasks:


176

Create a keyring. A default keyring is shipped with the system. You can create others.

Chapter 7: Using Secure Services



(Optional) Create Certificate Signing Requests (CSRs) that can be sent to Certificate Signing
Authorities (CAs).



Create or import certificates and associate them with the keyring.



Associate the keyring with the SSL client, if necessary.



Enable the HTTPS Service.

Do these steps in order.
Note:

These steps must be done with a serial console or SSH connection; you cannot use Telnet.

Before you begin, you should be familiar with the following terms:
CA Certificates

This is a certificate that has been signed by a CA. You only need this certificate if the
ProxySG will be obtaining data through an encrypted source. CA certificates are also used
to verify the client certificates that browsers can be configured to present.

CA-Cert Lists

CA-Cert lists allow you to associate a specific CA certificate (or a list of CA certificates)
with the HTTPS service you create.

Certificates

A certificate can be created (self-signed), imported from another machine, or sent by
Certificate Signing Authorities (CA Certificates). Certificates and CA Certificates are
imported differently on the ProxySG.

Certificate Signing
Authority (CA)

CAs receive Certificate Signing Requests and create signed certificates from the
information and the keypair provided. The signed 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.
Once the certificate is sent from the CA, you can import into the ProxySG. (For information
on importing CA certificates, see "Importing a CA-Certificate" on page 190.)

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.
When the ProxySG is acting as 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.

SSL Server

When the ProxySG is acting as an SSL server (SSL termination), SSL sessions are cached for
one hour. This timeout value is not configurable.

HTTPS Service

Once the keyrings are configured properly, you can create an HTTPS service and associate
any keyring that has certificates with the HTTPS service.

Keyring

A keyring holds a keypair and a certificate, 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:


The default



configuration-passwords-key

177

Blue Coat ProxySG Configuration and Management Guide

show |
no-show

The show option allows the keys to be viewed and exported in the future, while the
no-show option will never allow the keys to be viewed or exported from this
ProxySG. If you think that the keypair-certificate combination will be needed in the
future (for example to put onto an origin server or onto another ProxySG), then the
show option should be selected. The no-show option is provided as additional
security for environments where the keys will never be used outside of the particular
ProxySG.

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 keylength used in SGOS and most U.S.-based
servers is 1024, which is the maximum keylength. Be aware that the maximum
keylength allowed for international export might be different than the default. For
deployments reaching outside of the U.S., determine the maximum keylength
allowed for export.

To Import a Keyring through the CLI:
Note:

This procedure can only be done if the keyring containing the keypair was created using the
show parameter.

1.

Copy the certificate to the clipboard.

2.

At the (config) command prompt, enter the following commands:
SGOS#(config) ssl
SGOS#(config ssl) import keyring {show | no-show} keyring_id
Paste keypair here, end with “...” (three periods) on a new line

To View the Results of a New or Imported Keyring through the CLI:
Note:

This example shows the default keyring.

SGOS#(config ssl) view keyring [keyring_id]
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

Managing SSL Certificates
The ProxySG ships with a certificate associated with a default keyring. The certificate, self-signed and
associated with the default keyring, can be reused in other keyrings meant for internal use.

180

Chapter 7: Using Secure Services

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
AeFw0wMzAzMDQyMTA2NThaFw0wMzA0MDMyMTA2NThaMIGHMQswCQYDVQQGEwJVUzELMAkGA1UEC
BMCQ0ExCzAJBgNVBAcTAlNWMRIwEAYDVQQKEwlCbHVlIENvYXQxDTALBgNVBAsTBERvY3MxGTAX
BgNVBAMTEHd3dy5ibHVlY29hdC5jb20xIDAeBgkqhkiG9w0BCQEWEXRlc3RAYmx1ZWNvYXQuY29
tMEwwDQYJKoZIhvcNAQEBBQADOwAwOAIxAK+AGYRMbnjyGr7U0oZUYdslO6y8uQnxq2PV6qCr4Q
BpN1Vqyr1Fi7ZEaw0lyMs5FwIDAQABMA0GCSqGSIb3DQEBBAUAAzEAe8zoYW0igTcGRGG7sBpca
U95J907ZVm8qSU/PQfx1IrDzKdRSQPO9Gs1I8MqXi0D
-----END CERTIFICATE-----

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.

183

Chapter 7: Using Secure Services

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:
This procedure can only be performed if the keyring containing the keypair and certificate was created
using the show parameter.
1.

Copy the certificate to the clipboard.

2.

At the (config) command prompt, enter the following commands:
SGOS#(config) ssl
SGOS#(config ssl) import keyring {show | no-show} keyring_id
Paste certificate here, end with “...” (three periods) on a new line

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) import certificate keyring-id
Paste certificate here, end with “...” (three periods) on a new line
-----BEGIN CERTIFICATE----MIIB7TCCAaegAwIBAgIBADANBgkqhkiG9w0BAQQFADCBjjELMAkGA1UEBhMCVVMx
CzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTdW5ueXZhbGUxEjAQBgNVBAoTCUJsdWUg
Q29hdDENMAsGA1UECxMERG9jczEZMBcGA1UEAxMQd3d3LmJsdWVjb2F0LmNvbTEg
MB4GCSqGSIb3DQEJARYRdGVzdEBibHVlY29hdC5jb20wHhcNMDMwMjA1MjM1OTM1
WhcNMDMwMzA3MjM1OTM1WjCBjjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIw
EAYDVQQHEwlTdW5ueXZhbGUxEjAQBgNVBAoTCUJsdWUgQ29hdDENMAsGA1UECxME
RG9jczEZMBcGA1UEAxMQd3d3LmJsdWVjb2F0LmNvbTEgMB4GCSqGSIb3DQEJARYR
dGVzdEBibHVlY29hdC5jb20wTDANBgkqhkiG9w0BAQEFAAM7ADA4AjEAvs3U2zu2
WQ25ewgb/AyiGTHMAEgyC/vpQ2TN4+IOrIlUGItjvtnytYbhi6nwmbKPAgMBAAEw
DQYJKoZIhvcNAQEEBQADMQBc1s6HS0XewGG390Vh4B7wwXloXWEz4SDoGuspP21l
gu7UjWYUd+h/dZxbERv8gzQ=
-----END CERTIFICATE----...
ok

185

Blue Coat ProxySG Configuration and Management Guide

The External Certificates tab displays.
2.

Highlight the name of the external certificate that you want to delete.

3.

Click Delete.
The Confirm delete dialog appears.

4.

Click OK in the Confirm delete dialog that appears; click Apply.

To Delete an External Certificate through the CLI:
From the (config) prompt, enter the following commands:
SGOS#(config) ssl
SGOS#(config ssl) delete external-certificate name

Managing CA-Certificates
If you plan to use certificates issued by well-known Certificate Authorities, you can use the ProxySG
to create certificate signing requests (CSRs). These can be sent to the Certificate Authority for signing.
Obtain the keypair and CSR to send to the CA in two ways:


Use the Blue Coat Signing Request



Obtain the keypair and CSR off-box

Once the signed request is returned to you from the CA, you can import the certificate into the
ProxySG.
Note:

If you have a CA certificate that is not on the ProxySG default CA certificate list, you might
receive the following message when you attempt 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.
To import a CA-Certificate, go to "Importing a CA-Certificate" on page 190; to create a CSR to be sent
to a CA, continue with the next section.
Creating a CSR through the Management Console:
1.

Select Configuration>SSL>SSL Keyrings>SSL Certificates.
The SSL Certificates tab displays.

2.

Select, from the drop-down list, 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.

188

Blue Coat ProxySG Configuration and Management Guide

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 results.
SGOS#(config ssl) view signing-request keyring_id
-----BEGIN CERTIFICATE REQUEST----MIIBVDCCAQ4CAQAwgYcxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTELMAkGA1UEBxMCU1YxEjAQ
BgNVBAoTCUJsdWUgQ29hdDENMAsGA1UECxMERG9jczEZMBcGA1UEAxMQd3d3LmJsdWVjb2F0LmN
vbTEgMB4GCSqGSIb3DQEJARYRdGVzdEBibHVlY29hdC5jb20wTDANBgkqhkiG9w0BAQEFAAM7AD
A4AjEAobHjK0AsnKV0TcsntWCdfTaNyCgwNDXffxT5FwM0xkzQi0pCSku27CJXn7TahrKRAgMBA
AGgMTAUBgkqhkiG9w0BCQcxBxMFdGVzdAAwGQYJKoZIhvcNAQkCMQwWCkJsdWUgQ29hdAAwDQYJ
KoZIhvcNAQEEBQADMQBooZfEnzZT2WMMiu3oT9EP3CdtddOTtdBImWUXPdHJGfm1vEJ7HI0cE0W
71JP6pUY=
-----END CERTIFICATE REQUEST-----

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>Keyrings>SSL Certificates.
The SSL Certificates tab displays.

190

Chapter 7: Using Secure Services

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_cert_name
CA Certificate ID: ca_cert_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

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

Creating CA-Certificate Lists
You can select from among the CA-Certificates on the ProxySG, including those you added from a CA,
by using CA-Certificate lists. These lists can include as many or as few CA-Certificates as you need.
These lists can be used by the specific HTTPS service you enable for HTTPS termination.
The default is that no list is configured, so 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.
The CA Certificate Lists tab displays.

193

Chapter 7: Using Secure Services

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 it, using 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
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

Troubleshooting Certificate Problems
If the client does not trust the Certificate Signing Authority that has signed the ProxySG Appliance’s
certificate, you will see an error message in the event log similar to the following:
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
shows 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:

195

Blue Coat ProxySG Configuration and Management Guide



If this was caused by 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.

Managing the SSL Client
Although only one SSL client exists on a ProxySG, 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.

196

Chapter 7: Using Secure Services

Creating an SSL Client
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.
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 197 or "Changing the Cipher Suites of the SSL Client" on page 199.
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

Associating a Keyring and Protocol with the SSL Client
The SSL client 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.
The SSL Client tab displays.

197

Chapter 7: Using Secure Services

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
will have 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:
1.

Note that the Use Column in the set cipher-suite output below indicates that the default is to
use all ciphers.
SGOS#(config ssl ssl-client default) ciphersuite
SSL-Client
-------------------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

Name
Keyring Name
------------------- -----------default
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

Protocol

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. Note the change in the Use column.
SGOS#(config ssl ssl-client default) view
SSL-Client
-------------------default
Cipher#
------1
2
3
4
5

Use
--yes
no
yes
yes
no

Name
Keyring Name
------------------- -----------default
SSLv2v3TLSv1

Description
-------------------RC4-MD5
RC4-SHA
DES-CBC3-SHA
DES-CBC3-MD5
RC2-CBC-MD5

Protocol

Strength
-------Medium
Medium
High
High
Medium

199

Blue Coat ProxySG Configuration and Management Guide

Configuring DNS Resolution to the Origin Content Server
In different server accelerator scenarios, you might be required to use DNS resolution to the OCS
instead of HTTPS origination.
As long as the DNS that the ProxySG points to correctly resolves the domain name that the client
seeks to access, no addition configuration is required. Verify that the ProxySG has the certificate of the
Certificate Authority that signs the certificate on the OCS.

202

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.
Terms:
Access Control Lists (ACLs)

A list maintained by the ProxySG that restricts access to the ProxySG to certain IP
addresses.

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

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.

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. Note that 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 233.

203

Blue Coat ProxySG Configuration and Management Guide

serial console

A device that allows you to connect directly to the serial port for 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 the serial
console.

setup console

This allows you to create initial network and configuration settings, including
password creation, and helps you recover from Management Console problems.
The setup console can only be reached through the serial port.

serial port

The serial port provides a direct connection to the ProxySG. Through the serial
port, you can go to either the serial console and use the CLI just as if you were
using the CLI through SSH, or you can go to the setup console.
If you put a password on the serial port, you can only access the setup console
after successfully responding to the password challenge.

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:

204



"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
The ProxySG has a single console account and privileged password that are created during initial
configuration. The ProxySG allows you to restrict use of these credentials and to allow additional
administrator access through policy.
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"



"Maximum Security: Administrative Authentication and Authorization Policy"

The ProxySG permits you to define a rule-based administrative access policy for SSH with password
authentication, for the Management Console, and for the serial console. These policy rules can be
specified either by using the Visual Policy Manager 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.

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 serial console port.

These methods are in addition to the restrictions placed on the console account (a console account user
password and user 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"

205

Blue Coat ProxySG Configuration and Management Guide

Section A: Controlling Access to the ProxySG

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.
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" on page 210.)

Securing the Serial Port
During initial configuration, using either the setup console or the front panel, you can restrict access to
functions accessed through the serial port. You can set a password to limit access to the setup console,
and require administrator login before accessing the serial console CLI.
Once the secure serial port is enabled, the ProxySG is much more secure:


A setup console password is now required to access the setup console. If the setup console
password is forgotten, the setup console is inaccessible and can no longer be used to manage
network settings or recover from Management Console problems.



A username and password is now required to use the CLI through the serial console. If the setup
console password is forgotten, you can still use the serial console to connect to the ProxySG CLI.

Important: Because there is no workaround for a forgotten setup console password, Blue Coat
recommends that the password be preserved on non-volatile media in a physically
secure location away from the ProxySG.
To enable the secure serial port, refer to the Quick Start Guide for your platform.

About Password Security
In the ProxySG, console administrator passwords, the setup console password, and privileged-mode
(enable) passwords are hashed and stored. It is not possible to reverse the hash to recover the plaintext
passwords.

206

Chapter 8: Security and Authentication

Section A: Controlling Access to the ProxySG
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, be sure it
supports RSA encryption, OAEP padding, andBase64 encoded with no new lines.
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 659



Archive configuration FTP password—For configuration information, see "Archive
Configuration" on page 59



RADIUS primary and alternate secret—For configuration information, see "Defining RADIUS
Realm Properties" on page 259



LDAP search password—For configuration information, see "LDAP Search & Groups Tab
(Authorization and Group Information)" on page 251



SmartFilter download password—For configuration information, see "Configuring SmartFilter"
on page 571



SurfControl download password—For configuration information, see "Configuring SurfControl"
on page 579



Local Database password—For configuration information, see "Configuring a Local Database" on
page 549 (Note that the local database often does not have a password)

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 applies
to Telnet as well. Use of Telnet is not recommended because it is not a secure protocol.



Console account—minimum security

207

Blue Coat ProxySG Configuration and Management Guide

Section A: Controlling Access to the ProxySG
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 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 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).
After setting the console account username, password, and 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" on page 210.



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 can't 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 enables you to create an through the policy to control administrative access to the ProxySG. 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.

208



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



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

Chapter 8: Security and Authentication

Section A: Controlling Access to the ProxySG


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" on page 210. 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.1: ProxySG Console Access Methods/Available Security Measures
Security Measures
Available

Setup
Console

Serial
Console

SSH with
Password
Authentication

SSH with RSA
Authentication

Management
Console

Front Panel PIN1
Serial Port Password
Username and Password
Evaluated
(Console-Level
Credentials)
Console Access Control
List Evaluated

CPL Layer
Evaluated

(if console
credentials are
offered)
2

(if console
credentials are
offered)
3

Enable Password
required to enter
privileged mode (see
Note 2 below)
CLI line-vty
timeout command
applies
Management Console
Login/Logout
1The

Front Panel PIN protects the ProxySG front panel from authorized access. For more information on
limiting access to the front panel, see "Requiring a PIN for the Front Panel" on page 206.

2

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.

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

209

Chapter 8: Security and Authentication

Section A: Controlling Access to the ProxySG
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.
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.
Important:

6.

Before you enforce the ACL, make sure 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 will be able to use the Management
console account to administer the ProxySG. Make sure 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.

211

Blue Coat ProxySG Configuration and Management Guide

Section A: Controlling Access to the ProxySG

Maximum Security: Administrative Authentication and Authorization
Policy
The ProxySG permits you to define a rule-based administrative access policy for SSH with password
authentication and the Management Console. 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.
Setup-console access is not controlled by policy rules. For maximum security to the setup console, you
can create a password to secure the serial port that connects to the ProxySG.
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.



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 12: “Managing Policy Files” on
page 363.

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 13: “The Visual Policy Manager” on page 377.

Defining Policies Directly in Policy Files
To define policies manually, type CPL rules directly in one of the two policy files, Central or Local.

212

Chapter 8: Security and Authentication

Section A: Controlling Access to the ProxySG
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 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 366).

Admin Transactions and Layers
Admin transactions execute layers. Only a restricted set of conditions, properties, and actions
are permitted in layers. Table 8.2 lists the conditions permitted in the layer
Table 8.2: 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.

Date/Time Conditions
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

213

Blue Coat ProxySG Configuration and Management Guide

Section A: Controlling Access to the ProxySG
Table 8.2: Layer Conditions (Continued)
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.

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

214

Chapter 8: Security and Authentication

Section A: Controlling Access to the ProxySG
Table 8.2: Layer Conditions (Continued)
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 groupname.

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.

Table 8.3 lists the properties permitted in the layer:
Table 8.3: Layer Properties
Properties
deny | service(no)

Refuse service to the source of the transaction.

authenticate(realm_name)

Requests authentication of the transaction source for the
specified realm.

215

Blue Coat ProxySG Configuration and Management Guide

Section A: Controlling Access to the ProxySG
Table 8.3: Layer Properties (Continued)
authenticate.force( )

If 'yes' is specified then forces authentication even if the
transaction will be denied. This results in the user
information being available for logging. If no, then early
denial without authentication will be possible.

allow | service(yes)

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.4 lists the actions permitted in the layer:
Table 8.4: Layer Actions
Actions
notify_email( )

Sends an email 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.

216

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 may not be expecting it.

Once the browser supplies the credentials, the ProxySG authenticates them.

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.
Important: Credential caching is applicable only for authentication modes involving surrogates.

217

Blue Coat ProxySG Configuration and Management Guide

Section B: Controlling Access to the Internet and Intranet
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. The
purpose of surrogate credentials is to allow flexibility in limiting the frequency of
authentication challenges but to ensure security in that the surrogate is associated with the
same user used to create that surrogate.



Auto: The default; the mode is automatically selected, based on the request. Chooses among
proxy, origin-IP, and origin-IP-redirect, depending on the kind of connection (explicit or
transparent) and the transparent authentication cookie configuration. For streaming transactions,
authenticate.mode(auto) uses origin mode.



Proxy: The ProxySG uses an explicit proxy challenge. No surrogate credentials are used. This is
the typical mode for an authenticating explicit proxy. In some situations proxy challenges will not
work; origin challenges are then issued.



Proxy-IP: The ProxySG uses an explicit proxy challenge and the client's IP address as a surrogate
credential. Proxy-IP specifies an insecure forward proxy, possibly suitable for LANs of single-user
workstations. In some situations proxy challenges will not work; origin challenges are then
issued.



Origin: The ProxySG acts like an OCS and issues OCS challenges. The authenticated connection
serves as the surrogate credential.



Origin-IP: The ProxySG acts like an OCS and issues OCS challenges. The client IP address is used
as a surrogate credential. Origin-IP is used to support NTLM authentication to the upstream
device when the client cannot handle cookie credentials. This mode is primarily used for
automatic downgrading, but it can be selected for specific situations.



Origin-cookie: The ProxySG acts like an origin server and issues origin server challenges. A
cookie is used as the surrogate credential. Origin-cookie is used in forward proxies to support
pass-through authentication more securely than origin-ip if the client understands cookies.
Only the HTTP and HTTPS protocols support cookies; other protocols are automatically
downgraded to origin-ip.
This mode could also be used in reverse proxy situations if impersonation is not possible and the
origin server requires authentication.



Origin-cookie-redirect: The client is redirected to a virtual URL to be authenticated, and cookies
are used as the surrogate credential. Note that the ProxySG does not support origin-redirects with
the CONNECT method.
Note:

218

During cookie-based authentication, the redirect to strip the authentication cookie from
the URL is logged as a 307 (or 302) TCP_DENIED.



Origin-IP-redirect: The client is redirected to a virtual URL to be authenticated, and the client IP
address is used as a surrogate credential. Note that the ProxySG does not support origin-redirects
with the CONNECT method.



SG2: The mode is selected automatically, based on the request, and uses the SGOS 2.x-defined
rules.

Chapter 8: Security and Authentication

Section B: Controlling Access to the Internet and Intranet


Form-IP: A form is presented to collect the user's credentials. The form is presented whenever the
user’s credential cache entry expires.



Form-Cookie: A form is presented to collect the user's credentials. The cookies are set on the OCS
domain only, and the user is presented with the form for each new domain. This mode is most
useful in reverse proxy scenarios where there are a limited number of domains.



Form-Cookie-Redirect: A form is presented to collect the user's credentials. The user is redirected
to the authentication virtual URL before the form is presented. The authentication cookie is set on
both the virtual URL and the OCS domain. The user is only challenged when the credential cache
entry expires.



Form-IP-redirect: This is similar to form-ip except that the user is redirected to the authentication
virtual URL before the form is presented.

Important: Modes that use an IP surrogate credential are insecure: After a user has authenticated
from an IP address, all further requests from that IP address are treated as from that user.
If the client is behind a NAT, or on a multi-user system, this can present a serious security
problem.
The default value is auto.
For more information on using authentication modes, see the Blue Coat 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}

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 (although not required) to 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.

219

Blue Coat ProxySG Configuration and Management Guide

Section B: Controlling Access to the Internet and Intranet
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.
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 220 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. You will
receive an error message similar to the following:
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. Note that 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 121.
To Set Transparent Proxy Options through the Management Console:
1.

Select Configuration>Authentication>Transparent Proxy.
The Transparent Proxy tab displays.

220

Blue Coat ProxySG Configuration and Management Guide

Section B: Controlling Access to the Internet and Intranet
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 choose 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 minutes

A value of 0 (zero) for the IP address TTL re-prompts the user for credentials once the
specified cache duration for the particular realm has expired.
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.

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

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.

SSL Between the Client and the ProxySG
To configure SSL for to use origin-cookie-redirect or origin-ip-redirect challenges, you must:

222



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.

Chapter 8: Security and Authentication

Section B: Controlling Access to the Internet and Intranet
Note:

You can only use SSL between the client and the ProxySG for origin-style challenges on
transparent 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 will be 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 may not important).

For information on creating a keyring and a certificate, see "Configuring HTTPS Termination" on
page 176.
You can use SSL between the ProxySG and NTLM and LDAP authentication servers. For more
information, see Chapter 9: “Using Authentication Services” on page 233.

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.

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 Content Policy Language Guide.
Table 8.5: Layer Conditions
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.

223

Blue Coat ProxySG Configuration and Management Guide

Section B: Controlling Access to the Internet and Intranet
Table 8.5: Layer Conditions (Continued)
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.negoti
ated_
cipher=

Test the cipher suite negotiated with a securely connected client. Can also
be used in layers.

client.connection.negoti
ated_
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.

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.

224

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.

Chapter 8: Security and Authentication

Section B: Controlling Access to the Internet and Intranet
Table 8.5: Layer Conditions (Continued)
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.

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.

225

Blue Coat ProxySG Configuration and Management Guide

Section B: Controlling Access to the Internet and Intranet
Table 8.5: Layer Conditions (Continued)

226

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.

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.

Chapter 8: Security and Authentication

Section B: Controlling Access to the Internet and Intranet
Table 8.5: Layer Conditions (Continued)
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_na
me.length

Test the total length of the header values for the given header_name. Can
also be used in layers.

request.header.Referer.u
rl.host.has_name=

Test whether the Referer URL has a resolved DNS hostname. Can also be
used in layers.

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

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

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.

227

Blue Coat ProxySG Configuration and Management Guide

Section B: Controlling Access to the Internet and Intranet
Table 8.5: Layer Conditions (Continued)
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=

228

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

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.

Chapter 8: Security and Authentication

Section B: Controlling Access to the Internet and Intranet
Table 8.5: Layer Conditions (Continued)
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.6: Layer Properties
Layer Properties

Meaning

action.action_label( )

Selectively enables or disables a specified define action block. Can also be
used in layers.

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_st
ored_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 will be bypassed for a request.

229

Chapter 8: Security and Authentication

Section B: Controlling Access to the Internet and Intranet
Table 8.6: Layer Properties (Continued)
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
will be 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.

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.

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.

230

Blue Coat ProxySG Configuration and Management Guide

Section B: Controlling Access to the Internet and Intranet
Table 8.6: Layer Properties (Continued)
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.

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.7: Layer Actions
Layer Actions

231

Meaning

log_message( )

Writes the specified string to the ProxySG event log. Can be used in all
layers except .

notify_email( )

Sends an email 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.

Blue Coat ProxySG Configuration and Management Guide

Section B: Controlling Access to the Internet and Intranet
Table 8.7: Layer Actions (Continued)
transform

232

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 137.
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®)



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.

Note:

One-time passwords for any realm type are not supported.

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 "SSL Between the Client and the ProxySG" on page 222.
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.

233

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:

234



"NTLM Realm Authentication and Authorization"



"LDAP Realm Authentication and Authorization"



"RADIUS Realm Authentication and Authorization"



"Local Realm Authentication and Authorization"



"Certificate Realm Authentication"



"Sequence Realm Authentication"



"Netegrity SiteMinder"



"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 must use the 3.2 release of BCAAA with SGOS 3.2. You can also use BCAAA in place
of the deprecated CAASNT service for SGOS 2.x and SGOS 3.x. 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.
The NTLM Realms tab displays.

235

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:

Note that 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. Note that 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:

If you specify 0, traffic is increased to the NTLM server because each authentication
request generates an authentication and authorization request to the server.

7.

You can specify a virtual URL based on the individual realm. For more information on the virtual
URL, see Chapter 8: “Security and Authentication” on page 203.

8.

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

239

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 203 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 3.x systems, the
default policy condition is deny.
Note:



See the Blue Coat 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


Forms authentication modes cannot be used with an NTLM realm that allows only NTLM
credentials or a Certificate realm. If a form mode is in use and the authentication realm is either,
you will receive a configuration error.



For Windows Internet Explorer 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.
To define the information in Internet Explorer, go to Internet Options>Security>Local
intranet>Sites>Advanced...>Web sites. (If you are an XP user, go to Internet
Options>Security>Internet>Custom Level, then check Automatic logon with current username and
password.)

240

Chapter 9: Using Authentication Services

Section A: NTLM Realm Authentication and Authorization
For Windows Internet Explorer 6.x users, add the virtual host address to Internet
Options>Privacy>Web Sites>Managed Web Sites>Always Allow.

241

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 ProxySG (TLS) 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.

242

Blue Coat ProxySG Configuration and Management Guide

Section B: LDAP Realm Authentication and Authorization
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, click 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 Define a Realm and Edit LDAP Server Properties through the CLI:
1.

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

base_dn

The distinguished name (DN) that will be 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.
Note that at least one base DN is required for authentication to succeed,
although you can create a realm without a base DN.

2.

primary_host

The host for the primary LDAP server.

primary_port

The port for the primary LDAP server. The default port is 389.

To redefine the newly-created LDAP realm authentication properties, enter the following
commands:
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

246

ldap
ldap
ldap
ldap
ldap

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

Chapter 9: Using Authentication Services

Section B: LDAP Realm Authentication and Authorization
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)

spoof-authentication none | origin | proxy
ssl enable | disable
ssl-verify-server enable | disable
exit
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) that will be 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.
Note that 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 will be an
Authorization: header.
• If set to proxy, the spoofed header will be a
Proxy-Authorization: header.
• If set to none, no spoofing will be done.
Flush the entries for a realm if the
spoof-authentication value is changed to ensure
that the spoof-authentication value is
immediately applied.

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. If you do not want to verify
the server certificate, disable this setting.

247

Blue Coat ProxySG Configuration and Management Guide

Section B: LDAP Realm Authentication and Authorization
SGOS#(config ldap
realm_name) timeout

3.

seconds

Note that this command is not in the edit-realm
submode. Changes the timeout request for the
server from its default of 60 seconds.

(Optional) Once in the edit-realm submode, use the ? command to view all of the edit-realm
commands available.

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.
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=email address

User or group email 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= 650 Almanor Avenue Sunnyvale, California
94085-3515

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.

248

Select Configuration>Authentication>LDAP>LDAP DN.

Blue Coat ProxySG Configuration and Management Guide

Section B: LDAP Realm Authentication and Authorization
3.

Specify whether to allow anonymous search or to enforce user authentication before allowing a
search.
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 type: uniqueMember



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.

252



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.

Chapter 9: Using Authentication Services

Section B: LDAP Realm Authentication and Authorization
5.

Click Apply.

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 will not be permitted to anonymously bind to the
LDAP service.
If enabled, users will be 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 |
Sets dereference options.
finding | always dereference aliases is the default.
searching |
finding dereferences aliases only during name resolution.
never
searching dereferences aliases only after name resolution.
never means that aliases will never be dereferenced.

password |
encryptedpassword

password |
encrypted_
password

Specifies the user password (or encrypted password) associated with
the user distinguished name. The non-encrypted (or clear-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. If you choose to use
a third-party encryption application, be sure it supports RSA
encryption, OAEP padding andBase64 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.)
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.

253

Blue Coat ProxySG Configuration and Management Guide

Section B: LDAP Realm Authentication and Authorization
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 Chapter 8: “Security and Authentication” on page 203.

To Configure General Settings through the CLI:
At the (config) prompt, enter the following command to configure general settings:
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config

ldap
ldap
ldap
ldap

realm_name)
realm_name)
realm_name)
realm_name)

cache-duration seconds
case-sensitive {enable | disable}
virtual-url url
display-name name

where:
cacheduration

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.

256

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

display-name

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.

Chapter 9: Using Authentication Services

Section B: LDAP Realm Authentication and Authorization

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 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 3.x systems is deny.


Every LDAP-authenticated user is allowed access the ProxySG.

authenticate(LDAPRealm)



Group membership is the determining factor in granting access to the ProxySG.

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

257

Blue Coat ProxySG Configuration and Management Guide

Section C: RADIUS Realm Authentication and Authorization
3.

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.

4.

(Optional) You can specify a virtual URL based on the individual realm. For more information on
the virtual URL, see Chapter 8: “Security and Authentication” on page 203.

5.

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.

2.

primary_host

The host for the primary RADIUS server.

primary_port

The port for the primary RADIUS server. The default port is 1812.

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
SGOS#(config radius
-orSGOS#(config radius
encrypted_secret
SGOS#(config radius

262

realm_name) alternate-server alternate_host [alternate_port]
realm_name) alternate-server secret secret
realm_name) alternate-server encrypted-secret
realm_name) alternate-server service-type type

Chapter 9: Using Authentication Services

Section C: RADIUS Realm Authentication and Authorization
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. If you choose to use a third-party
encryption application, be sure it supports RSA encryption, OAEP padding
andBase64 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.

3.

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.

To complete configuration of the RADIUS realm, enter the following commands:
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config

radius
radius
radius
radius
radius
radius

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

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.

263

Blue Coat ProxySG Configuration and Management Guide

Section C: RADIUS Realm Authentication and Authorization
spoof-authentication none | origin Enables/disables the forwarding of authenticated
| proxy
credentials to the origin content server or for proxy
authentication. You can only choose one.
• If set to origin, the spoofed header will be an
Authorization: header.
• If set to proxy, the spoofed header will be a
Proxy-Authorization: header.
• If set to none, no spoofing will be done.
Flush the entries for a realm if the spoof-authentication
value is changed to ensure that the
spoof-authentication value is immediately applied.

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

264

Blue Coat ProxySG Configuration and Management Guide

Section D: Local Realm Authentication and Authorization
where:
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

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

rename

new_name

Allows you to change the display name of an existing realm.

spoofauthentication

none | origin Enables/disables the forwarding of authenticated credentials
| proxy
to the origin content server or for proxy authentication. You
can only choose one.
• If set to origin, the spoofed header will be an Authorization:
header.
• If set to proxy, the spoofed header will be a
Proxy-Authorization: header.
• If set to none, no spoofing will be done.
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

2.

url

The URL to redirect to when the user needs to be challenged
for credentials. See Chapter 8: “Security and Authentication”
on page 203 for more details.

(Optional) View the configuration:
SGOS#(config local realm_name) view
Realm name:
local1
Display name:
local1
Local user list: list20
Cache duration:
600
Virtual URL:
10.9.87.85

Defining the Local User List
Defining the local user list involves the following steps:

268



Create a list or customize the default list for your needs.



Upload a user list or add users and groups through theProxySG.



(Optional but recommended) Enhance security settings for the user list.

Chapter 9: Using Authentication Services

Section D: Local Realm Authentication and Authorization


Associate the list with the realm through CPL.

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:


User name



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

269

Blue Coat ProxySG Configuration and Management Guide

Section D: Local Realm Authentication and Authorization
To create a new empty local user list:
SGOS#(config) security local-user-list create listname

User Name
The user name 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 clear-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 "Creating a Local User List" on page 269.

How to Populate 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.
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,…

270

Chapter 9: Using Authentication Services

Section D: Local Realm Authentication and Authorization
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 271.

How to Upload 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.

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)

271

Blue Coat ProxySG Configuration and Management Guide

Section D: Local Realm Authentication and Authorization
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 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
SGOS#(config
SGOS#(config
SGOS#(config
-orSGOS#(config

Note:

4.

local-user-list listname) group create group1

local-user-list
local-user-list
local-user-list
local-user-list

listname) user edit username
listname username) group add groupname1
listname username) group add groupname2
listname username) password password

local-user-list listname username) hashed-password hashed-password

If you enter a clear-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:
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

272

Chapter 9: Using Authentication Services

Section D: Local Realm Authentication and Authorization
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
Users:
Groups:
test1
Lockout parameters:
Max failed attempts: 60
Lockout duration:
3600
Reset interval:
7200
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

273

Blue Coat ProxySG Configuration and Management Guide

Section D: Local Realm Authentication and Authorization
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 will be disabled (locked). If this is zero, there
is no limit. The default is 60 attempts.



Lockout duration: The time after which a locked account will be re-enabled. If this is zero, the
account will not automatically re-enable, but will instead stay locked until manually enabled. The
default is 3600 seconds (one hour).



Reset interval: The time after which a failed password count will be reset after the last failed
password attempt. If this is zero, the failed password count will be reset 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.
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 edit listname
SGOS#(config local-user-list listname)lockout-duration seconds
SGOS#(config local-user-list listname)max-failed-attempts attempts
SGOS#(config local-user-list listname) reset-interval seconds

2.

(Optional) View the settings:
SGOS#(config local-user-list listname) view
listname
Lockout parameters:
Max failed attempts: 45
Lockout duration:
3600
Reset interval:
0

274

Chapter 9: Using Authentication Services

Section D: Local Realm Authentication and Authorization
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 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
deny
.
.
.
[Rule]
deny

275

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 user name 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 user name 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:


Configure SSL between the client and ProxySG (for more information, see "SSL Between the
Client and the ProxySG" on page 222)



Enable verify-client on the HTTPS service that will be used (for more information, see "HTTPS" on
page 127).



Verify that the certificate authority that signed the client's certificates is in the ProxySG trusted list.

Creating a Certificate Realm
To Create a Certificate Realm through the Management Console:
1.

276

Select Configuration>Authentication>Certificate>Certificate Realms.

Blue Coat ProxySG Configuration and Management Guide

Section E: Certificate Realm Authentication
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 Chapter 8: “Security and Authentication” on page 203.

5.

Click Apply.

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 that will be 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:

280

cache-duration

seconds

The number of seconds that user and administrator
credentials received from the Credential realm should be
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 203 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:

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

281

Blue Coat ProxySG Configuration and Management Guide

Section E: Certificate Realm Authentication

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

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:


282

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, since the default
configuration does not use SSL for the virtual URL.

Chapter 9: Using Authentication Services

Section E: Certificate Realm Authentication


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.

283

Blue Coat ProxySG Configuration and Management Guide

Section F: Sequence Realm Authentication

Section F: 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.



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.
The Sequence Realms tab displays.

284

Blue Coat ProxySG Configuration and Management Guide

Section F: Sequence Realm Authentication
2.

From the Realm name drop-down list, select the Sequence realm for which you want to change
properties.
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.

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 Chapter 8: “Security and Authentication” on page 203.

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)
% An NTLM realm must be the first member of
to try NTLM authentication only once
SGOS#(config sequence realm_sequence_name)
SGOS#(config sequence realm_sequence_name)

2.

ntlm-only-once-enable
the realm sequence before specifying
realm promote ntlm1
ntlm-only-once-enable

(Optional) You can specify a virtual URL based on the individual realm sequence. For information
on the virtual URL, see "Security and Authentication" on page 203.
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.

288

To view the configurations of all realm-sequence-names, exit the edit-realm submode, and
enter:

Chapter 9: Using Authentication Services

Section F: Sequence Realm Authentication
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

289

Blue Coat ProxySG Configuration and Management Guide

Section G: Netegrity SiteMinder

Section G: 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.
Important: Use of this feature is subject to obtaining the appropriate license. The license check is on
the ProxySG.
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.
Note:

The BCAAA service is not supported on Solaris in this release. However, Blue Coat can
communicate with SiteMinder, regardless of the system it runs on.

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.

290

Chapter 9: Using Authentication Services

Section G: Netegrity SiteMinder
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).
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 clear and over SSL), Forms (in clear 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 user name 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.

Note that if the policy server returns an LDAP FQDN as part of the authentication response, the
ProxySG will use 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-sign-on (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. Note that this precludes that agent from doing SSO with 4.x agents.

291

Blue Coat ProxySG Configuration and Management Guide

Section G: Netegrity SiteMinder


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.



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

Credential caching is applicable only for authentication modes involving surrogates.

Configuring the ProxySG Realm
The ProxySG realm must be configured so that it can:


Find the Blue Coat agent(s) that will 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 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 293.
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.

292

Chapter 9: Using Authentication Services

Section G: Netegrity SiteMinder
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.
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). Note that, 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 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.
Note that 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.
The SiteMinder Realms tab displays.

293

Blue Coat ProxySG Configuration and Management Guide

Section G: Netegrity SiteMinder
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 of the agent 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. If you do
not want to verify the agent certificate, disable this setting.

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

realm_name) alternate-agent agent-name agent_name
realm_name) alternate-agent host host_name_or_IP_address
realm_name) alternate-agent port port_number
realm_name) alternate-agent encrypted-shared-secret

realm_name) alternate-agent shared-secret shared_secret

where:
primary-agent/
alternate agent

296

These commands allow you to configure
either the primary or alternate agent for the
SiteMinder realm.

agent-name

agent_name

host

host_name_or_IP_add The host ID or the IP address of the system
ress
that contains the agent.

port

port_number

The name of the agent.

The port where the agent listens.

Chapter 9: Using Authentication Services

Section G: Netegrity SiteMinder
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. One is the default.
e.

The timeout value has a default of 60 seconds, which can be changed.

5.

Click OK.

6.

Click Apply.

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

299

Blue Coat ProxySG Configuration and Management Guide

Section G: Netegrity SiteMinder
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.

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.
The SiteMinder Server General tab displays.

300

Blue Coat ProxySG Configuration and Management Guide

Section G: Netegrity SiteMinder
6.

If your Web applications need information from the SiteMinder policy server responses, you can
check the Add Header Responses checkbox. When this is checked, responses from the policy server
obtained during authentication are added to each request forwarded by the ProxySG. Note that
header responses will replace any existing header of the same name; if no such header exists, the
header will be added. Cookie responses will replace a cookie header with the same cookie name;
if no such cookie header exists, one will be added.

7.

Click Apply.

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

where:
protected-resource-name 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-redirect-offbox

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.

302

Blue Coat ProxySG Configuration and Management Guide

Section G: Netegrity SiteMinder
3.

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.

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 | Specifies whether the SiteMinder policy server is configured to expect
disable 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. see Chapter 8: “Security and Authentication” on page 203
for more details.

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 3.x systems, the
default policy condition is deny.
Note:

304

See the Blue Coat Content Policy Language Guide for details about CPL and how transactions
trigger the evaluation of policy file and other layers.

Chapter 9: Using Authentication Services

Section G: Netegrity SiteMinder


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

305

Blue Coat ProxySG Configuration and Management Guide

Section H: Forms-Based Authentication

Section H: 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 will be 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.

306

Chapter 9: Using Authentication Services

Section H: 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 will 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 will be 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:





$(exception.contact)



307

Blue Coat ProxySG Configuration and Management Guide

Section H: Forms-Based Authentication
If the realm is an NTLM realm, the $(x-cs-auth-form-domain-field) substitution expands to:

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 Content Policy Language Guide.

Tip
There is no realm restriction on the number of authentication form exceptions you can create. You can
have as many forms as you want, 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.
To Create or Edit an Authentication Form through the Management Console:
1.

Select Configuration>Authentication>Forms.
The Authentication Forms tab displays.

308

Blue Coat ProxySG Configuration and Management Guide

Section H: Forms-Based Authentication
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.
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 will result 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 306.
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 Ctrl) 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)

312

security authentication-form delete form_name

Blue Coat ProxySG Configuration and Management Guide

Section H: Forms-Based Authentication
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 don’t want the ProxySG to Verify the IP address against the original request, doubleclick the
checkbox to deselect the option. The default is to verify the IP address.

5.

If you want to Allow redirects from the origin servers, click the checkbox. The default is to not allow
redirects from origin servers.
Note:

6.

During authentication, the user's POST is redirected to a GET request. The client will
therefore automatically follow redirects from the origin server. Since the ProxySG is
converting the GET to a POST and adding the post data to the request before contacting
the origin server, the administrator needs to explicitly specify that redirects to these
POSTs requests can be automatically followed.

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
will be used in which situations. A form must exist before it can be referenced in policy.


314

Which form to use during authentication is specified in policy using the CPL condition
authenticate.form(form_name).

Chapter 9: Using Authentication Services

Section H: Forms-Based Authentication
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 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.



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 will be defined as a form mode (above) in policy, you
don’t 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 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 should result 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 will be 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, it is recommended 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.

315

Blue Coat ProxySG Configuration and Management Guide

Section H: Forms-Based Authentication

316



Forms-based authentication works with HTTP browsers only.



Since forms only support BASIC authentication, authentication-form exceptions cannot be used
with a Certificate realm or with an NTLM realm that allows only NTLM credentials. If a form is in
use and the authentication realm is either NTLM credentials or a Certificate realm, the user
receives a configuration error.



User credentials are sent in cleartext. However, they can be sent securely using SSL if the virtual
URL is HTTPS.



Since not all user requests support forms (such as WebDAV and streaming), you should create
policy to bypass authentication or use a different authentication mode with the same realm for
those requests.

Blue Coat ProxySG Configuration and Management Guide

Section I: Managing the Credential Cache
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:


318

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

Chapter 9: Using Authentication Services

Section I: Managing the Credential Cache

319

Blue Coat ProxySG Configuration and Management Guide

Section I: Managing the Credential Cache

320

Chapter 10: External Services

This chapter describes how to configure the ProxySG to interact with external ICAP and Websense
servers to provide content scanning, content transformation, and content filtering services.
This chapter contains the following sections:


"Section A: ICAP"—Describes the ICAP protocol and describes how to create and manage ICAP
services on the ProxySG.



"Section B: Websense"—Describes how to create a Websense service



"Section C: Service Groups"—Describes how to create service groups of ICAP or Websense entries
and configure load balancing.



"Section D: Displaying External Service and Group Information"—Describes how to display
external service configurations through the CLI.

Related Topics:


Chapter 11: "Health Checks"



Chapter 17: "Content Filtering"

321

Blue Coat ProxySG Configuration and Management Guide

Section A: ICAP

Section A: ICAP
This section describes the Internet Content Adaptation Protocol (ICAP) solution of content scanning
and modification.
When integrated with a supported ICAP server, the ProxySG provides content scanning, filtering, and
repair service for Internet-based malicious code. ICAP is an evolving architecture that allows an
enterprise to dynamically scan and change Web content. To eliminate threats to the network and to
maintain caching performance, the ProxySG sends objects to the integrated ICAP server for checking
and saves the scanned objects in its object store. With subsequent content requests, the appliance
serves the scanned object rather than rescan the same object for each request.
Configuring ICAP on the ProxySG involves the following steps:
1.

Install the ICAP server.

2.

Configure the ProxySG to use ICAP and configure basic features.

3.

Define scanning policies, then load the policy file on the ProxySG.

Supported ICAP Servers
The ProxySG supports the following ICAP servers:


Blue Coat ProxyAV, version 2.x.



Symantec AntiVirus Scan Engine (SAVSE) 4.0, version 4.04.46; ICAP 1.0



Trend Micro InterScan WebProtect (ISWP) 1.5, build_SOL_1266; ICAP 1.0



WebWasher 4.4, build 552; ICAP 1.0



Finjan Vital Security for Web v7.0; Service Pack 2; build 4.552; ICAP 1.0

Note:

While SGOS 2.x supported ICAP v0.95 servers and services, SGOS 3.2.x does not. Upon
upgrading to SGOS 3.2.x, any configured v0.95 services become inactive.

ICAP v1.0 Features
This section describes features of the ICAP v1.0 protocol.

Sense Settings
The Sense Settings feature allows the ProxySG to query any identified ICAP server running v1.0,
detect the parameters, and configure the ICAP service as appropriate. See "Creating an ICAP Service"
on page 325.

322

Chapter 10: External Services

Section A: ICAP

ISTags
An ICAP v1.0 server is required to return in each response an ICAP header ISTag indicating the
current state of the ICAP server. This eliminates the need to designate artificial pattern version
numbers, as is required in v0.95.
Note:

Backing out a virus pattern on the ICAP server can revert ISTags to previous values that are
ignored by the ProxySG. To force the ProxySG to recognize the old value, use the Sense
Settings option as described in "Creating an ICAP Service" on page 325.

Persistent Connections
New ICAP connections are created dynamically as ICAP requests are received (up to the defined
maximum connection limit). The connection remains open to receive further requests. If a connection
error occurs, the connection closes to prevent further errors.

About Content Scanning
The ProxySG ICAP scanning solution prevents the spread of viruses and other malicious code by
serving content that has been scanned by a supported ICAP server.

Determining Which Files to Scan
In determining which files to scan, this integrated solution uses the content scanning server’s filtering
in addition to ProxySG capabilities. Table 10.1 describes the supported content types and protocols.
Table 10.1: Content Types Scanned By ICAP Server and the ProxySG
ICAP Server

ProxySG

Unsupported content

supported content types

supported protocols

protocols

All or specified file types, based
on file extension, as configured
on the server.

• HTTP objects

• Streaming content (for example,
RTSP and MMS)

• FTP objects (uploads and
Examples: .exe (executable
downloads)
programs), .bat (batch
files), .doc and .rtf (document • Transparent FTP responses
files), and .zip (archive files), or
with specific MIME types.

• Live HTTP streams (for example,
HTTP radio streams)

HTTPS connections terminated at a HTTPS connections tunneled through a
ProxySG.
Blue Coat client-side ProxySG.

After the ProxySG retrieves a requested Web object from the origin server, it uses content scanning
policies to determine whether the object should be sent to the ICAP server for scanning. If cached
objects are not scanned or are scanned before a new pattern file was updated, the ProxySG rescans
those objects upon:


the next request for that object, or

323

Blue Coat ProxySG Configuration and Management Guide

Section A: ICAP


the object is refreshed.

With the ProxySG, you can define flexible, enterprise-specific content scanning policies. Consider the
following example. A business wants to scan software downloaded by employees from popular
shareware Web sites. To do this, the business defines an appliance policy that includes a custom
scanshareware action for the purpose. This rule includes URL domains related to the relevant
shareware Web sites.
Before continuing, plan the types of policies you want to use. For more information, see "Creating
ICAP Policy" on page 335.

Performing Response Modification
The ProxySG sends the first part (a preview) of the object to the ICAP server that supports response
modification. The object preview includes the HTTP request and response headers, and the first few
bytes of the object. After checking those bytes, the ICAP server either continues with the transaction
(that is, asks the ProxySG to send the remainder of the object for scanning) or sends a notification to
the appliance that the object is clean and opts out of the transaction.
The ICAP server features and configuration determine how scanning works, including the following:


Handling of certain objects, including those that are infected and cannot be repaired.



Whether to attempt to repair infected files.



Whether to delete infected files that cannot be repaired from the ICAP server’s archive.

Performing Request Modification
The ProxySG sends the client request to a ICAP server that supports request modification. The server
might then return an HTTP response to the client (for example, sports not allowed); or the client
request might be modified, such as stripping a referer header, before continuing to the origin content
server.
Note:

Some ICAP servers do not support virus scanning for request modification, only content
filtering.

Returning the Object to the ProxySG
This object may be the original unchanged object, a repaired version of the original object minus a
virus, or an error message indicating that the object contained a virus. Each of these responses is
configured on the ICAP server, independent of the appliance and the ICAP protocol. If the appliance
receives the error message, it forwards the error message to the client and does not save the infected
file.

324

Chapter 10: External Services

Section A: ICAP

Caching and Serving the Object
Once an object is determined cacheable, the ProxySG saves it and serves it for the subsequent content
requests. When the ProxySG detects that the cached content has changed on the origin server, it
fetches a fresh version and forwards it to the ICAP server for scanning. If a pattern file change occurs
on the virus scanning server while content is still fresh, the already-cached object is rescanned.
However, this only occurs for objects marked as clean by a previous ICAP scan.
When a virus is detected during an ICAP scan, the ICAP server might return a transformed (cleaned)
object or an error page reporting that the virus was detected. This object is cached by the ProxySG, just
as it would cache the original content, and is served until either the original content is updated on the
origin server or the pattern file is updated on the ICAP server. When that occurs, the ProxySG always
refetches content from the origin server before rescanning it. Already-cached objects are never
rescanned.
ProxySG policies related to ICAP response scanning are created in the layer. These policies
apply to content fetches by clients, content distribute commands, refreshes, and pipeline fetches. For
more information on policies, see "Creating ICAP Policy" on page 335. For more information on the
layer, refer to the Blue Coat Content Policy Language Guide.

Installing the ICAP Server
Follow the manufacturer instructions for installing the ICAP server, including any configuration
necessary to work with the Blue Coat ProxySG. Based on your network environment, you might use
the ProxySG with multiple ICAP servers or multiple scanning services on the same server. Configure
options as needed, including the error message displayed to end users in the event the requested
object was modified or blocked.

Creating an ICAP Service
An ICAP service on the ProxySG is specific to the ICAP server and includes the server IP address or
hostname, as well as the supported number of connections. If you are using the ProxySG with
multiple ICAP servers or multiple scanning services on the same server, add an ICAP service for each
server or scanning service.
To Create and Configure an ICAP Service through the Management Console:
1.

Select Configuration>External Services>ICAP Services.

2.

Click New; the Add List Item dialog appears.

3.

In the ICAP service name field, enter an alphanumeric name; click OK.

4.

Highlight the new ICAP service name and click Edit; the Edit ICAP Service dialog appears.

325

Chapter 10: External Services

Section A: ICAP
b.

The maximum number of connections possible at any given time between the ProxySG and
the ICAP server. The range is a number from 1 to 65535. The default is 5. The number of
recommended connections is dependent on the capabilities of the ICAP server. Refer to the
vendor’s product information.

c.

The number of seconds the ProxySG waits for replies from the ICAP server. The range is 60 to
65536. The default timeout is 70 seconds.

d. Optional: You can enable the ProxySG to display a default patience page when an ICAP
server is processing a relatively large object. The page informs users that a content scan is in
process. If enabled, the patience page is displayed after the designated time value is reached
for scanned objects. Patience pages might not be displayed for truncated objects; Blue Coat
recommends increasing the maximum cacheable object size (up to 1 GB) to reduce the amount
of truncated objects.
Note:

Patience pages display regardless of any pop-up blocking policy that is in effect.

To enable the patience page, in the Patience page delay field, enter the number of seconds the
ProxySG waits before displaying the page. The range is 5 to 65535. Select Enable.
e.
6.

Select Notify administrator: Virus detected to send an email to the administrator if the ICAP scan
detects a virus. The notification is also sent to the Event Log and the Event Log email list.

The following steps configure ICAP v1.0 features:
a.

Select the ICAP method: response modification or request modification.
Note:

b.

An ICAP server might have separate URLs for response modification and request
modification services.

Enter the preview size (in bytes) and select preview size enable. The ICAP server reads the
object up to the specified byte total. The ICAP server either continues with the transaction
(that is, receives the remainder of the object for scanning) or opts out of the transaction.
The default is 0. Only response headers are sent to the ICAP server; more object data is only
sent if requested by the ICAP server.
Note:

c.

Trend Micro does not support previews for request modification mode.

(Optional) Click Send: Client address or Server address to specify what is sent to the ICAP
server: Send: Client address, Server address, Authenticated user, or Authenticated groups.

d. (Optional) Clicking Sense Settings automatically configures the ICAP service using the ICAP
server parameters. If you use the sense settings feature, no further steps are required; the
ICAP service is configured. Otherwise, proceed with the manual configuration.
7.

Click OK; click Apply.

327

Blue Coat ProxySG Configuration and Management Guide

Section A: ICAP
To Register a Newly Created ICAP Service for Health Checking:
For convenience, the Edit ICAP Service dialog allows you to register a newly-created ICAP service for
health checking (this duplicates the functionality on the Configuration>Health Checks>General tab).
Registering for health checking requires that a valid ICAP server URL was entered.


Click Register; a dialog prompts confirmation; click OK.



You can also click Health check to perform an immediate health check on this service.

To Monitor ICAP Health Checks:
In a browser, enter one of the following URLs to list health check information.


To list all health check entries and their configuration parameters, enter:
http://ProxySG_IP_address:8081/health_check/view



To list the statistics for all currently active entries, enter:
http://ProxySG_IP_address:8081/health_check/statistics

For more information about health checks, see Chapter 11: “Health Checks” on page 355.
Note:

When a health check determines that a server is not healthy, the ProxySG no longer attempts
to contact this server to perform ICAP actions. Any ICAP actions that refer to this server
results in the return of the ICAP server unavailable error code. When an ICAP action references
a service group, server unavailable is only returned when all the servers in this service group
are determined to not be healthy.

To Create and Configure an ICAP Service through the CLI:
1.

At the (config) command prompt, enter the following commands:
SGOS#(config) external-services
SGOS#(config external-services) create icap service_name

Specify a unique alphanumeric name for each service.
2.

To configure the service, enter the following commands:
SGOS#(config external-services) edit service_name
SGOS#(config icap service_name) url icap://url

where url specifies the URL schema, ICAP server hostname or IP address, and the ICAP port
number. The default port number is 1344.
Note:

While http://url:1344 is valid, an ICAP service pointing to a WebWasher server
must use icap as the protocol in the URL.

SGOS#(config icap service_name) max-conn number

where number is the maximum number, from 1 to 65535, of connections the ICAP service uses
to connect to the ICAP server. The default is 5. Blue Coat recommends that the setting not
exceed 200.
SGOS#(config icap service_name) timeout timeout_seconds

328

Chapter 10: External Services

Section A: ICAP
where timeout_seconds is the number of seconds, from 60 to 65535, the ProxySG waits for
replies from the ICAP server. The default timeout is 70 seconds.
SGOS#(config icap service_name) notify virus-detected

Sends an email to the administrator if the ICAP scan detects a virus. The notification is also
sent to the Event Log and the Event Log email list.
3.

The following commands configure ICAP v1.0 features:
SGOS#(config icap service_name) methods {REQMOD | RESPMOD}

Specifies the ICAP service type: request modification or response modification.
Note:

On most ICAP servers, one URL is designated for response modification and one
for request modification.

SGOS#(config icap service_name) preview-size bytes

where number is the preview size in bytes. If specified, the ICAP server reads the object up
to the specified byte total. The ICAP server either continues with the transaction (that is,
receives the remainder of the object for scanning) or opts out of the transaction.
The default is 0. Only response headers are sent to the ICAP server; more object data is
only sent if requested by the ICAP server.
Optional:
SGOS#(config icap service_name) send {client-address | server-address}

Specifies to send the client IP address or the server IP address to the ICAP server.
SGOS#(config icap service_name) send {authenticated-user | authenticated-groups}

Specifies to send authenticated user and group information to the ICAP server.
4.

Optional: If the ICAP server is a version 1.0 server, you can use the sense-settings command to
automatically configure the ICAP service using ICAP server parameters. Otherwise, proceed with
the manual configuration in Step 3. To use the ICAP server parameters, enter the following
command:
SGOS#(config icap services service_name) sense-settings

The ICAP service is now configured. No further steps are required.
5.

Optional: You can enable the ProxySG to display a default patience page when an ICAP server is
processing a relatively large object. The page informs users that a content scan is in process. If
enabled, the patience page is displayed after the designated time value is reached for scanned
objects. Patience pages might not be displayed for truncated objects; Blue Coat recommends
increasing the maximum cacheable object size (up to 1 GB) to reduce the amount of truncated
objects. To customize patience pages, see "Customizing ICAP Patience Text" on page 330.
SGOS#(config icap services service_name) patience-page seconds

where seconds is the duration before the patience page is displayed. The range is 5 to 65535.
The default is disabled.

329

Blue Coat ProxySG Configuration and Management Guide

Section A: ICAP
Note:

Patience pages display regardless of any pop-up blocking policy that is in effect.

Deleting an ICAP Service
The following steps describe how to delete an ICAP service.
Note:

You cannot delete an ICAP service used in a ProxySG policy (that is, if a policy rule uses the
ICAP service name) or that belongs to a service group.

To Delete an ICAP Service through the Management Console:
1.

Select Configuration>External Services>ICAP.

2.

Select the service to be deleted.

3.

Click Delete; click OK to confirm.

4.

Click Apply.

To Delete an ICAP Service through the CLI:
At the (config) prompt, enter the following commands:
SGOS#(config) external-services
SGOS#(config external-service) delete service_name

Customizing ICAP Patience Text
This section describes how to customize text displayed during ICAP scanning.

HTTP Patience Text
The ProxySG allows you to customize the patience pages that are displayed when HTTP clients
experience delays as Web content is scanned. You can customize the following patience page
components:


330

Header—Contains HTML tags that define what appears in the dialog title bar. This component
also contains the tag, which is used to specify a non-English character set.

Blue Coat ProxySG Configuration and Management Guide

Section A: ICAP
Example:
SGOS#(config) external-services
SGOS#(config external-services) inline http icap-patience-summary eof
Your request is experiencing a slight delay while it is scanned for malicious
content or viruses. If the content is safe, you will receive the request. Please
be patient. eof
ok
SGOS#(config external-services)

Windows XP, Service Pack 2 Behavior
With Windows XP, Microsoft is continually updating the security measures, which impacts how the
ProxySG manages patience pages.


Browsers running on Windows XP, Service Pack 2 (XP SP2), experience slightly different patience
page behavior when pop-up blocking is enabled.


If pop-up blocking is not enabled, patience page behavior should be normal.



If pop-up blocking is enabled (the default), the ProxySG attempts to display the patience page
in the root window.



If the download triggers an invisible Javascript window, the user can track the scanning
progress with the progress bar at the bottom of the window; however, if other policy blocks
Javascript active content, this bar is also not visible.



If Internet Explorer blocks all downloads initiated by Javascript, the user must click the yellow
alert bar to download the scanned object.



Users experience two patience page responses for non-cacheable objects.

Interactivity and Limitations


When ICAP scanning is enabled and a patience page is triggered, a unique URL is dynamically
generated and sent to the browser to access the patience page. This unique URL might contain a
modified version of the original URL. This is expected behavior.



Patience pages and exceptions can only be triggered by left-clicking a link. If a user right-clicks a
link and attempt to save it, it is not possible to display patience pages. If this action causes a
problem, the user might see browser-specific errors (for example, an Internet site not found);
however, ICAP policy is still in effect.



A patience page is not displayed if a client object request results in an HTTP 302 response and the
ProxySG pipelines the object in the Location header. Once the ProxySG receives the client request
for the object, the client enters a waiting state because a server-side retrieval of the object is
already in progress. The wait status of the client request prevents the patience page from
displaying. To prevent the ProxySG from pipelining these requests (which decreases
performance) and retain the ability to provide a patience page, configure HTTP:
#ProxySG (config) http no pipeline client redirects



334

The status bar update does not work if it is disabled or if the Javascript does not have sufficient
rights to update it.

Chapter 10: External Services

Section A: ICAP


Looping: Certain conditions cause browsers to re-spawn patience pages. For example, a site states
it will begin a download in 10 seconds, initiates a pop-up download window, and returns to the
root window. If the download window allows pop-ups, the patience page is displayed in another
window. The automatic return to the root window initiates the download sequence again,
spawning another patience page. If unnoticed, this loop could cause a system hang. The same
behavior occurs if the user clicks the back button to return to the root window. For known and
used download sites, you can create policy that redirects the page so that it doesn’t return to the
root window after a download starts.

FTP Patience Text
The patience text displayed to FTP clients during an ICAP scan can be modified.
To Customize ICAP Patience Text through the Management Console:
1.

Select Configuration>External Services>ICAP>ICAP Patience Page.

2.

In the FTP Patience Page Customization field, click Summary; the Customize FTP Patience Text dialog
appears. Customize the FTP client patience text.

3.

Click OK; click Apply.

To Customize ICAP Patience Text through the CLI:
At the (config) command prompt, enter the following commands:
SGOS#(config) external-services
SGOS#(config external-services) inline ftp icap-patience-text eof

Creating ICAP Policy
Defined ICAP policy dictates the anti-virus behavior for your enterprise. You can either use the Visual
Policy Manager (VPM) or you can manually edit policy files. For more information on the VPM and
defining policies, see "The Visual Policy Manager" on page 377.
Use the request.icap_service() (request modification) or response.icap_service() (response
modification) properties to manage the ProxySG ICAP services.

VPM Objects
The VPM contains the following objects specific to AV scanning (linked to their descriptions in the
VPM chapter).
Table 10.1: VPM ICAP Objects
Object

Layer>Column

"Virus Detected"

Web Access>Service

"ICAP Error Code"

Web Access>Service

"Return ICAP Patience Page"

Web Access>Action

"Set ICAP Request Service"

Web Access>Action

"Set ICAP Request Service"

Web Content>Action

335

Blue Coat ProxySG Configuration and Management Guide

Section A: ICAP
Table 10.1: VPM ICAP Objects
Object

Layer>Column

"Set ICAP Response Service"

Web Content>Action

Note:

For CPL policy, refer to the Blue Coat Systems ProxySG Content Policy Language Guide.

Example ICAP Policy
The following VPM example demonstrates the implementation of an ICAP policy that performs virus
scanning on both client uploads (to prevent propagating a virus) and responses (to prevent the
introduction of viruses).
For this example:


The ProxySG has configured ICAP services. The response service is corporateav1 and the request
service is corporateav2.



The ProxyAV is the virus scanner and is configured to serve password-protected files.



A group named IT is configured on the ProxySG.



The IT group wants to be allowed to download password protected files, but deny everyone else.

Procedure—To perform virus scanning, protecting both the server side and client side:

336

1.

In the VPM, select Policy>Web Content Layer. Name the layer RequestAV.

2.

Right-click the Action column; select Set. The Set Action Object dialog appears.
a.

Select Set ICAP Request Service; the Add ICAP Request Service Object dialog appears.

b.

From the Use ICAP request service drop-down list, select corporateav2.

c.

Select Deny the client request. This prevents a client from propagating a threat. If a virus is
found, the content is not uploaded. For example, a user attempts to post a document that has
a virus.

Blue Coat ProxySG Configuration and Management Guide

Section A: ICAP


If a virus is detected and there were no scanning process errors, a log entry occurs.



As the ProxyAV is configured to serve password-protected objects, only the IT group can
download such files; everyone else is denied.

Exempting HTTP Live Streams From Response Modification
The following CPL examples demonstrate how to exempt HTTP live streams from response
modification, as they are not supported by ICAP. The CPL designates user agents that are bypassed.

url.scheme=http request.header.User-Agent="RealPlayer G2"
response.icap_service(no)
url.scheme=http request.header.User-Agent="(RMA)" response.icap_service(no)
url.scheme=http request.header.User-Agent="(Winamp)"
response.icap_service(no)
url.scheme=http request.header.User-Agent="(NSPlayer)"
response.icap_service(no)
url.scheme=http request.header.User-Agent="(Windows-Media-Player)"
response.icap_service(no)
url.scheme=http request.header.User-Agent="QuickTime"
response.icap_service(no)
url.scheme=http request.header.User-Agent="(RealMedia Player)"
response.icap_service(no)

Streaming Media Request Modification Limitation
Some HTTP progressive download streaming media transactions are complex enough to disrupt
ICAP request modification services. If such behavior is noticed (most common with RealPlayer),
implement the following workaround policy to bypass the ICAP request modification service for
HTTP progressive downloads:

url.scheme=http request_header.User-Agent="user_agent"
request.icap_service(no)
url.scheme=http request_header.User-Agent="user_agent"
request.icap_service(no)

where user_agent specifies a media player attribute that is disrupting service. For example:

url.scheme=http request_header.User-Agent="(RealMedia Player)"
request.icap_service(no)
url.scheme=http request_header.User-Agent="RMA" request.icap_service(no)

CPL Notes


If policy specifies that an ICAP service is to be used, but the service is not available, the default
behavior is to fail closed—that is, deny the request or response. The following CPL allows objects
to be served without ICAP processing if the server is down.
request.icap_service(service_name, fail_open)
response.icap_service(service_name, fail_open)

340

Chapter 10: External Services

Section A: ICAP
Note:


Blue Coat recommends this CPL to be used for internal sites; use with caution.

To provide an exception to a general rule, the following CPL negates ICAP processing:
request.icap_service(no)
response.icap_service(no)

Managing Virus Scanning
You might need to perform additional ProxySG maintenance concerning virus scanning, particularly
for updates to the virus definition on the ICAP virus scanning server.

Advanced Configurations
This section summarizes more-advanced configurations between the ProxySG and multiple ICAP
servers. These brief examples provide objectives and suggest ways of supporting the configuration.

Using Object-Specific Scan Levels
You can specify different scanning levels for different types of objects, or for objects from different
sources.
This requires a service group of ICAP servers, with each server configured to provide the same level
of scanning. For more information, see "Creating a Service Group" on page 348.

Improving Virus Scanning Performance
You can overcome request-handling limitations of ICAP servers. Generally, ProxySGs can handle
many times the volume of simultaneous user requests that ICAP servers can handle.
This requires multiple ICAP servers to obtain a reasonable performance gain. On the ProxySG, define
policy rules that partition requests among the servers. If you are going to direct requests to individual
servers based on rules, configure in rule conditions that only use the URL. Note that you can increase
the scale by using a service group, rather than use rules to partition requests among servers. For more
information on using multiple ICAP servers, see "Creating a Service Group" on page 348. For more
information on defining policies, see Chapter 12: “Managing Policy Files” on page 363, as well as the
Blue Coat Content Policy Language Guide.
When the virus definitions are updated, the ProxySG stores a signature. This signature consists of the
server name plus a virus definition version. If either of these changes, the ProxySG checks to see if the
object is up to date, and then rescans it. If two requests for the same object are directed to different
servers, then the scanning signature changes and the object is rescanned.

Updating the ICAP Server
If there is a problem with the integration between the ProxySG and a supported ICAP server after a
version update of the server, you may need to configure the preview size the appliance uses. For
information, see "Creating an ICAP Service" on page 325.

341

Blue Coat ProxySG Configuration and Management Guide

Section A: ICAP

Replacing the ICAP Server
If you replace an ICAP server with another supported ICAP server, reconfigure the ICAP service on
the ProxySG:
SGOS#(config) external-services
SGOS#(config external-service) edit service_name
SGOS#(config service_name) url url

For information about these commands, see "Creating an ICAP Service" on page 325.

Access Logging
The ProxySG provides access log support for Symantec, Trend Micro, and Finjan ICAP 1.0 server
actions (Management>Access Logging). The following sections describe access logging behavior for the
various supported ICAP servers.

Symantec AntiVirus Scan Engine 4.0
When this Symantec server performs a scan, identifies a problem (for example, a virus), and performs
a content transformation, the action is logged. For example:
“virus-id: Type=number; Resolution=[0 | 1 | 2]; Threat=name;”

where:
Type=number

Specifies the numeric code for the virus.

Resolution=

Specifies an integer value that indicates what action was taken to fix the
file. Zero (0) defines the file is unrepairable, one (1) specifies that the file
was repaired, and two (2) specifies that the file was deleted.

Threat=

Specifies the name of the virus.

Trend Micro Interscan WebProtect v 1.5
When of these Trend Micro ICAP servers performs a scan, identifies a problem (for example, a virus),
and performs a content transformation, the action is logged. For example:
“virus-id: name”

where name specifies the name of the virus.
Important: The ivscan.ini ISWP configuration file on the Trend Micro server must contain the
following entry:
‘yes’: security_gateway_virus_log=yes.

Finjan SurfinGate 7.0
When this Finjan ICAP server performs a scan, identifies a problem (for example, a virus), and
performs a content transformation, the action is logged. For example:
“virus-id: name, response-info: Blocked, response-desc: virus_name was detected”

342

Chapter 10: External Services

Section A: ICAP
Finjan ICAP servers also log occurrences malicious mobile code.
Note:

The access log string cannot exceed 256 characters. If the header name or value extends the
length over the limit, then that string does not get logged. For example, if the x-virus-id
header value is 260 characters, the access log displays x-virus-id: with no value because
the value is too long to display. Furthermore, if the access log string is already 250 characters
and the ProxySG attempts to append a Malicious-Mobile-Type: string, the string is not
appended.

Access log entries might vary depending upon the type of ICAP scan performed and the custom log
formats. For information about Access Logging, see Chapter 19: “Access Logging” on page 641.

References
The following are selected references for this feature.
Note:


As with any Web site, addresses are subject to change or deletion at any time.

Symantec—A provider of Internet security technology, including content and network security
software and appliance solutions.
http://www.symantec.com/
http://enterprisesecurity.symantec.com/products/



Trend Micro—A provider of network anti-virus and Internet content security software and
services.
http://www.trendmicro.com/



Finjan—A provider of proactive active content defense, virus protection, and Web and email
content filtering solutions.
http://www.finjan.com/



ICAP Forum—A resource on Internet Content Adaptation Protocol (ICAP), an evolving Web
architecture. ICAP effectively adapts content for user needs.
http://www.i-cap.org/

343

Chapter 10: External Services

Section B: Websense
d. In the Maximum connections field, enter the maximum number of connections. The range is a
number from 1 to 65535. The default is 5. Blue Coat recommends that the setting not exceed
200.
e.
6.

In the Receive Timeout field, enter the number of seconds the ProxySG waits for replies from
the Websense server. The range is 60 to 65535. The default timeout is 70 seconds.

Select the following options, as required:
a.

Fail open—If a default Websense service is selected (from the External Services>Websense tab), a

connection error with the Websense server results in requests and responses proceeding, as
the default Websense service is subjected to policy.
b.

Send client address—Sends the client IP address to the Websense server.

c.

Send Authenticated user—Sends user information to the Websense server.

d. Serve exception page when content is blocked—If the requested content is defined by Websense as
inappropriate, the client receives a page with information stating the content is blocked.
When this option is selected, the exception page originates from the ProxySG; if not selected,
the Websense server provides the exception page.
7.

Click OK.

8.

Optional: You can designate a default Websense service. On the Configuration>External
Services>Websense tab, select a service from the Default service to use drop-down list.

To Register a Newly Created Websense Service for Health Checking:
For convenience, the Edit Websense Service dialog allows you to register a newly-created Websense
service for health checking (this duplicates the functionality on the Configuration>Health Checks>General
tab). Registering for health checking requires that a valid Websense server URL was entered.


Click Register; a dialog prompts confirmation; click OK.



You can also click Health check to perform an immediate health check on this service.

For more information about health checks, see Chapter 11: “Health Checks” on page 355.
To Configure a Websense Service through the CLI:
1.

At the (config) command prompt, enter the following commands:
SGOS#(config) external-services
SGOS#(config external-services) create websense service_name

Specify a unique alphanumeric name for each service.
2.

To configure the service, enter the following commands:
SGOS#(config external-services) edit service_name
SGOS#(config websense service_name) version {4.3 | 4.4}

where version specifies 4.3 or 4.4 and higher.
SGOS#(config websense service_name) host {hostname | IP_address}

where hostname or IP_address specifies the Websense server.

345

Blue Coat ProxySG Configuration and Management Guide

Section B: Websense
SGOS#(config websense service_name) port port_number

where port_number specifies the port number of the Websense server. The default port
number is 15868.
SGOS#(config websense service_name) max-conn number

where number is the maximum number, from 1 to 65535, of connections the Websense service
uses to connect to the Websense server. The default number is 5. Blue Coat recommends that
the setting not exceed 200.
SGOS#(config websense service_name) timeout timeout_seconds

where timeout_seconds is the number of seconds, from 60 to 65535, the ProxySG waits for
replies from the Websense server. The default timeout is 70 seconds.
SGOS#(config websense service_name) send {client-address | authenticated-user}

Specifies to send the client IP address or authenticated user information to the Websense
server.
3.

Optional: You can automatically detect the categories defined on the Websense server.
SGOS#(config websense service_name) sense-categories

4.

Optional: You can designate a default Websense service.
SGOS#(config websense service_name) apply-by-default

This Websense service is now the default and is used if failover is enabled.
5.

Optional: You can enable failover. If a default Websense service is selected (from the External
Services>Websense tab), a connection error with the Websense server results in requests and
responses proceeding, as the default Websense service is subjected to policy.
SGOS#(config websense service_name) fail-open

6.

Optional: You can send a test URL to the Websense server to verify content filtering is active.
SGOS#(config websense service_name) test-url url

where url is a valid URL that points to a site determined categorized by Websense as
inappropriate.

Deleting a Websense Service
The following steps describe how to delete an Websense service.
Note:

You cannot delete a Websense service used in a ProxySG policy (that is, if a policy rule uses
the Websense service name) or if the service belongs to a service group.

To Delete a Websense Service through the Management Console:

346

1.

Select Configuration>External Service>Websense.

2.

Select the service to be deleted.

3.

Click Delete; click OK to confirm.

Chapter 10: External Services

Section B: Websense
4.

Click Apply.

To Delete an Websense Service through the CLI:
At the (config) prompt, enter the following commands:
SGOS#(config) external-services
SGOS#(config external-services) delete service_name

347

Blue Coat ProxySG Configuration and Management Guide

Section C: Service Groups

Deleting a Service Group or Group Entry
You can delete the configuration for an entire service group from the ProxySG, or you can delete
individual entries from a service group.
Note:

A service or service group used in a ProxySG policy (that is, if a policy rule uses the entry)
cannot be deleted; it must first be removed from the policy.

To Delete a Service Group through the Management Console:
1.

Select Configuration>External Services>Service-Groups.

2.

Select the service group to be deleted.

3.

Click Delete; click OK to confirm.

4.

Click Apply.

To Delete a Service Group through the CLI:
At the (config) command prompt, enter the following commands:
SGOS#(config) external-services
SGOS#(config external-services) delete service_group_name

To Delete a Service Group Entry through the Management Console:
1.

Select Configuration>External Services>Service-Groups.

2.

Select the service group to be modified.

3.

Click Edit.

4.

Select the service entry; click Delete.

5.

Click OK; click Apply.

To Delete a Service Group Configuration through the CLI:
At the (config) command prompt, enter the following commands:
SGOS#(config) external-services
SGOS#(config external-services) edit service_group_name
SGOS#(config type name) remove entry_name

About Weighted Load Balancing
The ProxySG supports weighted load balancing in forwarding requests to service groups. By default,
the ProxySG performs typical round-robin load balancing and evenly forwards requests sequentially
to servers as defined within the service group. Manually assigning weights takes advantage of
round-robin load balancing in service groups that are not homogeneous, or where the servers have
different capacities.

350

Chapter 10: External Services

Section C: Service Groups
Weighting determines what proportion of the load one server bears relative to the others. If all servers
have either the default weight (1) or the same weight, each share an equal proportion of the load. If
one server has weight 25 and all other servers have weight 50, the 25-weight server processes half as
much as any other server.
Before configuring weights, consider the relative weights to assign to each server. Factors that could
affect assigned weight of a ICAP server include the following:


The processing capacity of the server hardware in relationship to other servers (for example, the
number and performance of CPUs or the number of network interface cards)



The maximum number of connections configured for the service. Note that the maximum
connections setting pertains to how many simultaneous scans can be performed on the server,
while weighting applies to throughput in the integration. While these settings are not directly
related, consider both when configuring weighted load balancing For more information on
maximum connections, see "Creating an ICAP Service" on page 325 and "Creating a Websense
Service" on page 344.

The table below provides an example of how weighting works with a service group of three ICAP
servers, Server1, Server2, and Server3. Because Server3 is a higher-capacity server (including dual
CPUs and multiple network interface cards (NICs)) compared to Server1 and Server2, it is assigned a
heavier weight. Using the weights below, for every 100 requests forwarded to the service group,
Server3 receives 60 requests, while Server1 and Server2 each receive 20 requests.
Table 10.1: Example of Weighted Load Balancing for an ICAP Service Group
ICAP server

Capacity

ICAP service /
Maximum connections

Weight

Server1

Standard

Service1 / 10

1

Server2

Standard

Service2 / 10

1

Server3

High

Service3 / 25

3

Note:

Setting the weight value to 0 (zero) disables weighted load balancing for the ICAP service.
Therefore, if one ICAP server of a two-server group has a weight value of 1 and the second a
weight value of 0, should the first server go down, a communication error results because the
second server cannot process the request.

While you cannot specifically designate an ICAP server in a group as a backup, you can specify
weight values that create a large differential between a server that is used continuously and one that is
rarely used, thus simulating a backup server.

351

Blue Coat ProxySG Configuration and Management Guide

Section D: Displaying External Service and Group Information

Section D: Displaying External Service and Group Information
After configuring a service or service group, you can display information either for all or individual
service groups.
To Display Information about all External Services and Groups through the CLI:
At the (config) command prompt, enter the following commands:
SGOS#(config) external-services
SGOS#(config external-services) view

Individual service information is displayed first, followed by service group information. For example:
; External Services
icap4
ICAP-Version:
1.0
URL:
icap://10.1.1.1
Max-conn:
5
Timeout(secs):
70
Health-checks:
no
Patience-page(secs): disabled
Notification:
never
Methods:
RESPMOD
Preview-size:
0
Send:
nothing
ISTag:
websense4
Version:
4.4
Host:
www.websense.com/list
Port:
15868
Max-conn:
5
Timeout(secs):
70
Send:
nothing
Fail-by-default:
closed
Apply-by-default:
no
Serve-exception-page:yes
; External Service-Groups
CorpICAP
total weight 5
entries:
ICAP1
weight 4
ICAP2
weight 1
BranchWebsense
total weight
entries:
Websense1
weight
1
Websense2
weight
1

352

2

Chapter 10: External Services

Section D: Displaying External Service and Group Information
To Display Information about an Individual Service or Service Group through the CLI:
At the (config) command prompt, enter the following commands:
SGOS#(config) external-services
SGOS#(config external-services) edit {service_name | service_group_name}
SGOS#(config type name) view

353

Blue Coat ProxySG Configuration and Management Guide

354

Chapter 11: Health Checks

This chapter discusses health checks for services and hosts and describes how to configure the
ProxySG.

About General Health Checks
The ProxySG can perform health checks on a forwarding host or external server that is providing a
service. The supported server types are HTTP, HTTPS, ICAP, Websense (off-box), and SOCKS
gateways, Layer-3, and Layer 4 forwarding hosts.
Based on the health check type, the ProxySG periodically verifies the health status, and thus the
availability, of the host. The time interval between checks is configurable. If the health check is
successful, the ProxySG considers the host available. If the initial health check is not successful for a
host, the ProxySG retries, using the number of attempts in the health check failure count. If the health
check is not successful for every server in a domain, the ProxySG might not serve stale content from its
object store, depending on the ProxySG configuration.
The following table describes the types of health checks.
Table 11.1: Types of Health Checks
Health check type

Description

HTTP

Use this type to confirm that the host can fulfill a content
request over HTTP by the ProxySG. The ProxySG accepts only
a 200 OK as a healthy response.

Criterion for success

The ProxySG fetches the object.

Criterion for failure

The ProxySG cannot fetch the object.

HTTPS

Use this type to confirm that the host can fulfill a content
request over HTTPS by the ProxySG. The ProxySG accepts
only a 200 OK as a healthy response.

Criterion for success

The ProxySG fetches the object.

Criterion for failure

The ProxySG cannot fetch the object.

Layer-3 health check

Use this type to confirm the basic connection between the
ProxySG and the origin server. The server must recognize
ICMP echoing. The ProxySG sends a ping (three Internet
Control Message Protocol [ICMP] echo requests) to the host.

Criterion for success

The ProxySG receives at least one ICMP echo reply.

Criterion for failure

The ProxySG does not receive a single ICMP echo reply.

Layer-4 health check

Use this type to confirm that the ProxySG can connect to the
host HTTP and FTP ports. The ProxySG attempts to establish a
TCP connection to an HTTP port or FTP port on the host.

355

Blue Coat ProxySG Configuration and Management Guide

Table 11.1: Types of Health Checks (Continued)
Health check type

Description

Criterion for success

The ProxySG establishes the connection to the defined port (of
any type), then closes it. For global forwarding checks, the first
defined port in the forwarding host port list is used for the
attempt (except for SOCKS gateways, in which the SOCKS
port is used).

Criterion for failure

The ProxySG cannot establish the connection.

ICAP health check and Websense 4 off-box

Requests are not sent to sick services. If a health check
determines the service is healthy, requests resume.

Configuring Service-Specific Health Checks
This section describes how to create a health check service for a specific host (for example, an ICAP
server). A failed health check results in administrator notification; however, unlike global forwarding
health checks, the ProxySG does not recognize the healthy or sick status of the host and thus alters
where it sends transactions.
To Configure Health Checks through the Management Console:
Part 1: General Tasks
This part of the procedures is the same for all health check types.

356

1.

Select Configuration>Health Checks>General.

2.

Click New.

3.

In the Add Health Check dialog, specify a name for the health check service; click OK.

4.

In the Health Check list, select the newly created service and click Edit; the Edit Health Check dialog
displays.

Blue Coat ProxySG Configuration and Management Guide

Part 2: Health Check Type Specific Tasks
This part of the procedure configures the health check based upon the type selected.
1.

2.

Upon selecting the health check type, the Options section of the dialog changes to display the
appropriate configuration fields. Enter the required information:


HTTP and HTTPS: Enter the URL of the server to be checked.



ICAP: Select the ICAP service. The ICAP service must already be configured on the ProxySG
(see Chapter 10: "External Services").



Layer-3 and Layer-4: Enter the host name; for Layer-4, also enter the port number.



Websense off-box: Select the Websense service. The Websense service must already be
configured on the ProxySG (see Chapter 10: "External Services"). Enter the URL to be
test-categorized, or click Use default.

Click OK to close the Edit Health Check dialog; Click Apply to apply the configuration to the
ProxySG.

To Specify a Health Check through the CLI:
At the (config) command prompt, enter the following commands:
SGOS#(config) health-check
SGOS#(config health-check) create name
SGOS#(config health-check) edit name
SGOS#(config health-check name) type {layer-3 | layer-4 | http | https | icap |
websense-offbox}

where type specifies the type of health check.
SGOS#(config health-check name) type parameter

where type is the type of health check and parameter is the required attribute:
layer-3
layer-4
layer-4
{http |

hostname host_name
hostname host_name
port port
https} url url

icap servicename service_name—The ICAP service must already be configured on the
ProxySG. See Chapter 10: "External Services".
websense-offbox servicename service_name—The Websense service must already be
configured on the ProxySG. For more information, see Chapter 10: "External Services".
websense-offbox {url | default-url}
SGOS#(config health-check name) interval healthy seconds

where seconds specifies the interval between health checks to the server. The default is 10.
SGOS#(config health-check name) interval sick seconds

where seconds specifies the interval between health checks to the server that has been
determined to be sick. The default is 10.
SGOS#(config health-check name) threshold healthy number

358

Chapter 11: Health Checks

where number is the number of successful health checks before an entry is considered healthy.
Valid values are 1-65535. The default is 1.
SGOS#(config health-check name) threshold sick number

where number is the number of failed health checks before an entry is considered sick. Valid values
are 1-65535. The default is 1.
SGOS#(config health-check name) failure-trigger number

where number is the number of failed connections to the server before a health check is triggered.
Valid values are 0-65535, where 0 disables the trigger. The default is 0.
Optional:
SGOS#(config) health-check name) notify

Sends e-mail notification when the health of a service changes. The recipients are specified in
(config event-log) mail add option.
Note:

To enable health check notification, you must set the event logging level to Informational or
Verbose. For more information about event logging, see "Event Logging and Notification"
on page 698

Perform an Instant Health Check
You can manually issue a health check request.
To Do a Health Check through the Management Console:
1.

Select Health Checks>General.

2.

Select a health check name.

3.

Click Edit.

4.

Click Health Check.

To Do a Health Check through the CLI:
At the (config) prompt, enter the following commands:
SGOS#(config) health-check
SGOS#(config) health-check) edit health_check_name
SGOS#(config) health-check name) perform-health-check

About Global Forwarding and SOCKS Gateway Health Checks
This section describes health checks that can be configured on the ProxySG that apply to all
forwarding hosts and SOCKS gateway hosts.
When the ProxySG performs a health check on one or more hosts, it determines whether the host
returns a response and is available to fill a content request. A positive health check indicates that there
is an end-to-end connection and that the host is healthy and is able to return a response.

359

Chapter 11: Health Checks

To Configure Global Forwarding Host Health Checks through the CLI:
At the (config) command prompt, enter the following commands:
SGOS#(config) health-check
SGOS#(config health-check) forwarding type {http | https | layer-3 | layer-4}
SGOS#(config health-check) forwarding interval seconds

where seconds specifies the time between health checks.
SGOS#(config health-check) forwarding failcount count

where count specifies the number of sequential failures before the host is considered down.
The default is 5.
To Configure Global SOCKS Gateways Health Checks through the CLI:
At the (config) command prompt, enter the following commands:
SGOS#(config) health-check
SGOS#(config health-check) socks-gateways type {layer-3 | layer-4}
SGOS#(config health-check) socks-gateways interval seconds

where seconds specifies the time between health checks.
SGOS#(config) health-check) socks-gateways failcount count

where count specifies the number of sequential failures before the host is considered down.
The default is 5.

Pausing or Resuming Global Health Checking
You can temporarily halt global health checks and resume when ready. This is helpful if the ProxySG
needs to be temporarily taken out of service.
Note:

If the health check is paused, the state remains paused until the resume option is invoked. The
paused state remains even after a reboot.

To Pause or Resume Health Checking through the Management Console:
1.

Select Configuration>Health Checks>Forwarding or SOCKS Gateway.

2.

Click Pause.

3.

To resume health checks, click Resume.

To Pause or Resume Health Checking through the CLI:
At the (config) command prompt, enter the following commands:
SGOS#(config) health-check
SGOS#(config) health-check) {forwarding | socks-gateways} {pause | resume}

361

Blue Coat ProxySG Configuration and Management Guide

362

Chapter 12: Managing Policy Files

Policy files contain the policies that manage every aspect of the ProxySG, from controlling user
authentication and privileges to disabling access logging or determining the version of SOCKS.
The policy for a given system can contain several files with many layers and rules in each. Policies can
be defined through the Visual Policy Manager (VPM) or composed in Content Policy Language (CPL).
(Some advanced policy features are not available in VPM and can only be configured through CPL.)
Policies are managed through four files:


Central policy file—Contains global settings to improve performance and behavior and filters for
important and emerging viruses (such as Code Red and Nimda). This file is usually managed by
Blue Coat, although you can point the ProxySG to a custom Central policy file instead.



Forward policy file—Usually used to supplement any policy created in the other three policy files.
The Forward policy file contains Forwarding rules when the system is upgraded from a previous
version of SGOS (2.x) or CacheOS (4.x).



Local policy file—A file you create yourself. When VPM is not the primary tool used to define
policy, the Local file contains the majority of the policy rules for a system. If VPM is the primary
tool, this file is either empty or includes rules for advanced policy features that are not available in
VPM.



Visual Policy Manager—The policy created by VPM can either supplement or override the policies
created in the other policy files.

This chapter contains the following sections:


"About Policy Files"



"Creating and Editing Policy Files"



"Managing the Central Policy File"



"Viewing Policy Files"

To learn about writing policies, refer to the Blue Coat Content Policy Language Guide.

About Policy Files
When creating the files, keep in mind:


The order in which the files are evaluated.



The transaction default settings, which control whether you allow everything or deny everything
by default.



Whether or not to use VPM.

363

Chapter 12: Managing Policy Files

Note:

Use the show policy order command to check the current settings.

Transaction Settings: Deny and Allow
The default transaction policy is deny everything or allow everything, depending on whether
this is a new installation or an upgrade. You can change the default policy.


A default transaction policy of Deny prohibits proxy-type access to the ProxySG: you
must then create policies to explicitly grant access on a case-by-case basis. This is the default for
those who are installing a new release of SGOS without an upgrade and for administrator
transactions.



A default transaction policy of Allow permits any and all proxy-types access to the
ProxySG: you must then create policies to explicitly deny access on a case-by-case basis. This is the
default for those upgrading from a previous version of CacheOS and for transactions.
Changing the default transaction policy affects the basic environment in which the
overall policy is evaluated. It is likely that you must revise policies to retain expected behavior
after such a change.

Also consider:


Changes to the evaluation order might result in different effective policy, because the order of
policy evaluation defines general rules and exceptions.



Changes made to transactions do not affect transactions and
transactions.

To Configure Deny or Allow Default Policy through the Management Console:
1.

Select Configuration>Policy>Policy Options.

2.

Under Default Proxy Policy, select either Deny or Allow.

3.

Click Apply.

To Configure the Deny or Allow Transaction Policy through the CLI:
At the (config) command prompt, enter the following command
SGOS#(config) policy proxy-default {allow | deny}

Policy Tracing
Tracing enabled with the Management Console or CLI is global; that is, it records every policy-related
event in every layer. It should be used only while troubleshooting. For information on troubleshooting
policy, refer to the Blue Coat Content Policy Language Guide. Turning on policy tracing of any kind is
expensive in terms of system resource usage, and it will slow down the ProxySG's ability to handle
traffic.
To Enable Policy Tracing through the Management Console:
1.

Select Configuration>Policy>Policy Options.

2.

Select Trace all policy execution.

365

Blue Coat ProxySG Configuration and Management Guide

3.

Click Apply.

To Enable Policy Tracing through the CLI:
From the command prompt, enter the following command:
SGOS# policy trace {all | none}

Creating and Editing Policy Files
You can create and edit policy files two ways:


Through the Management console (recommended).



Through the CLI inline policy command (not recommended because the policies can grow large
and using inline policy overwrites any existing policy on the ProxySG).

You can use VPM to create policy layers and rules in the VPM file. For information on managing the
VPM file, see Chapter 13: “The Visual Policy Manager” on page 377.
To create or edit policy files, use CPL to define policy rules (refer to the Blue Coat Content Policy
Language Guide). You can use the Management Console or CLI to create or edit policy files directly, or
create a file that can be uploaded to the ProxySG through the Management Console or CLI.

Create and Edit Policy Files
You can install the policy files in the following ways.


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



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.



Through the CLI inline command.

The ProxySG compiles the new policy from all source files and installs the policy, if the compilation is
successful.
Important: If errors or warnings are produced when you load the policy file, a summary of the
errors and/or warnings is displayed automatically. If errors are present, the policy file is
not installed. If warnings are present, the policy file is installed, but the warnings should
be examined.
To Define and Install Policy Files Directly through the Management Console:
1.

Select Configuration>Policy>Policy Files>Policy Files.
The Policy Files tab displays.

366

Blue Coat ProxySG Configuration and Management Guide

Enter each line and press . To correct mistakes on the current line, use . If a
mistake has been made in a line that has already been terminated by , exit the inline
policy command by typing Ctrlc to prevent the file from being saved.
3.

Enter the eof marker to save the policies and exit the inline mode.

For more information on the inline command, refer to the Blue Coat Command Line Interface Reference.
To Load Policy Files through the CLI:
At the (config) command prompt, enter the following commands:
SGOS#(config) policy {forward-path | local-path | central-path} url
SGOS#(config) load policy {forward | local | central}

The ProxySG compiles and installs the new policy. The ProxySG might display a warning if the new
policy causes conflicts. If a syntax error is found, the appliance displays an error message. For
information about these messages, refer to the Blue Coat Content Policy Language Guide. Correct the
error, then reload the file.

Unloading Policy Files
To disable policies, do the following procedure to unload the compiled policy file from the ProxySG
memory. These steps describe how to replace a current policy file with an empty policy file.
To keep a current policy file, either make a backup copy or rename the file before unloading it. By
renaming the file, you can later reload the original policy file. If you use multiple policy files, back up
or rename files as necessary. Alternatively, rather than use an empty policy file, you can delete the
entire contents of the file, then reload it.
To unload policies defined using the VPM, you can either:


Do the procedure below for unloading policies through the CLI.



Use the VPM and individually delete all layers.

To Unload Policies through the Management Console:
1.

Select Configuration>Policy>Policy Files>Policy Files.

2.

Select Text Editor in the Install Local/Forward/Central File from drop-down list and click the appropriate
Install button.
The Edit and Install the Local/Forward/Central Policy File window opens.

3.

Delete the text and click Install.

4.

View the results in the results page that opens; close the page.

5.

Click Close.

To Unload Policies through the CLI:
1.

At the (config) command prompt, enter the following command:
SGOS#(config) inline policy file end-of-input-marker

370

Chapter 12: Managing Policy Files

where:
file

Specifies the type of policy you want to define: central (central policy
file), local (local policy file), vpm-cpl, or vpm-xml (VPM policy files,
usually defined using the VPM).

end-of-input-marker Specifies the string that marks the end of the current inline command
input. The CLI buffers all input until you enter the marker string. eof is
commonly used as the marker.

Note:

If you use the CLI to unload VPM-generated policies, you must run the inline command
twice; once for the CPL file and once for the XML file.

2.

Enter an end-of-input-marker to save the policies and exit inline mode. Enter nothing else.

3.

If you use multiple policy files, repeat step 1 and step 2 for each policy file used.

For more information on the inline policy command, refer to the Blue Coat Command Line Interface
Reference.

Managing the Central Policy File
The Central policy file is updated when needed by Blue Coat. The file can be updated automatically or
you can request email notification. You can also configure the path to point to your own custom
Central policy file.

Configuring Automatic Installation
You can specify whether the ProxySG checks for a new version of the Central policy file. If a new
version exists, the appliance can install it automatically.

Configuring the ProxySG for Automatic Installation
Do the following procedure to configure the ProxySG to check for and install a new version of the
Central policy file.
To Configure Automatic Installation through the Management Console:
1.

Select Configuration>Policy>Policy Files>Policy Files.

2.

Select Automatically install new Policy when central file changes.

3.

Click Apply.

To Configure Automatic Installation through the CLI:
At the (config) command prompt, enter the following command:
SGOS#(config) policy subscribe

371

Blue Coat ProxySG Configuration and Management Guide

Configuring a Custom Central Policy File for Automatic Installation
If you define your own Central policy file, you can configure the ProxySG to automatically install any
subsequent updated version of the file. To use this capability, you must change the Central policy file’s
first line with each version update. With automatic installation, the ProxySG checks for a change to the
first line of the file. In defining a custom Central policy file, add an item, such as a comment, to the
first line of the Central policy file that changes with each update. The following is a sample first line,
containing date information that is routinely updated with each version:
; Central policy file MonthDate, Year version

When you update and save the file in the original location, the ProxySG automatically loads the
updated version.

Configuring Email Notification
You can specify whether the ProxySG sends email when the Central policy file changes. The email
address used is the same as that used in diagnostic reporting: the event recipient for the custom
heartbeat email. For information about diagnostic reporting, see "Diagnostic Reporting (Heartbeats)"
on page 846.
To Configure Email Notification through the Management Console:
1.

Select Configuration>Policy>Policy Files>Policy Files.

2.

Select Send me email when central file changes.

3.

Click Apply.

To Configure Email Notification through the CLI:
At the (config) command prompt, enter the following command:
SGOS#(config) policy notify

Configuring the Update Interval
You can specify how frequently the ProxySG checks for a new version of the Central policy file. By
default, the appliance checks for an updated Central policy file once every 24 hours (1440 minutes).
You must use the CLI to configure the update interval. You cannot configure the update interval
through the Management Console.
To Configure the Update Interval through the CLI:
At the (config) command prompt, enter the following command:
SGOS#(config) policy poll-interval minutes

Checking for an Updated Central Policy File
You can manually check whether the Central policy file has changed. You must use the CLI. You
cannot check for updates through the Management Console.

372

Chapter 12: Managing Policy Files

To Check for an Updated Central File through the CLI:
At the (config) command prompt, enter the following command:
SGOS#(config) policy poll-now

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

Resetting the Policy Files
You can clear all the policy files automatically through the CLI.
To Clear all Policy Files through the CLI:
1.

At the (config) command prompt, enter the following command:
SGOS#(config) policy reset
WARNING: This will clear local, central, forward and VPM policy. Are you sure you
want to reset ALL policy files? (y or n)

The ProxySG displays a warning that you will be resetting all of your policy files.
2.

Enter y to continue or n to cancel.
Note:

This command does not change the default proxy policy settings.

Moving VPM Policy Files from One ProxySG to Another
VPM policy files are specific to the ProxySG where they were created. But just as you can use the same
Central, Local, and Forward policy files on multiple ProxySG Appliances, you can use VPM policies
created on one appliance on other appliances.
For detailed information on moving VPM policy files, see "Installing VPM-Created Policy Files" on
page 456 in Chapter 13: "The Visual Policy Manager".

Viewing Policy Files
You can view either the compiled policy or the source policy files. Use these procedures to view
policies defined in a single policy file (for example, using VPM) or in multiple policy files (for
example, using the Blue Coat Central policy file and VPM).

Viewing the Installed Policy
Use the Management Console or a browser to display installed Central, Local, or Forward policy files.
Note:

You can view VPM policy files through the Visual Policy Files tab.

To View Installed Policy through the Management Console:
1.

Select Configuration>Policy>Policy Files>Policy Files.

373

Blue Coat ProxySG Configuration and Management Guide

2.

In the View File drop-down list, select Current Policy to view the installed and running policy, as
assembled from all policy source files. You can also select Results of Policy Load to view any
warnings or errors resulting from the last attempt (successful or not) to install policy.

3.

Click View.
The ProxySG opens a separate browser window and displays the installed policy file.

To View the Currently Installed Policy through a Browser:
1.

Enter a URL in one of the following formats:


If an HTTPS-Console is configured, use
https://ip_address_of_ProxySG:HTTPS-Console_port/Policy/current (the default
port is 8082).



If an HTTP-Console is configured, use
http://ip_address_of_ProxySG:HTTP-Console_port/Policy/current (the default port
is 8081).

The ProxySG opens a separate browser window and displays the policy.
2.

Review the policy, then close the browser.

To View the Currently Installed Policy through the CLI:
At the (config) command prompt, enter the following command:
SGOS#(config) show policy

Viewing Policy Source Files
You can display source (uncompiled) policy files on the ProxySG.
To View Policy Source Files through the Management Console:
1.

Select Configuration>Policy>Policy Files>Policy Files.

2.

To view a policy source file, select the file you want to view (Local, Forward, or Central) from the
View File drop-down list and click View.
The ProxySG opens a separate browser window and displays the appropriate source policy file.

To View Policy Source Files through the CLI:
At the (config) command prompt, enter one of the following commands:
SGOS#(config) show configuration
-orSGOS#(config) show sources policy {central | local | forward | vpm-cpl | vpm-xml}

The show configuration command displays general configuration information, followed by the
policy source file contents. If the ProxySG is using multiple policy files, file source displays in this
sequence: Central file, local file, VPM. The show sources policy command allows you to specify the
policy files you want to view.

374

Chapter 12: Managing Policy Files

Note:

You can use the show configuration command to save the output to a file for reference, in
addition to displaying the current configuration. For more information, refer to the Blue Coat
Command Line Interface Reference.

Viewing Policy Statistics
You can view policy statistics on all requests processed by the ProxySG. Use the Management Console
or a browser. You cannot view policy statistics through the CLI.
To Review Policy Statistics through the Management Console:
1.

Select Statistics>Advanced.

2.

Click the Policy link.

3.

Click the Show policy statistics link.
A separate browser window opens and displays the statistics.

4.

Examine the statistics, then close the browser.

To Review Policy Statistics through a Browser:
1.

Enter a URL in one of the following formats:


If an HTTPS-Console is configured, use
https://ip_address_of_ProxySG:HTTPS-Console_port/Policy/statistics (the default
port is 8082).



If an HTTP-Console is configured, use
http://ip_address_of_ProxySG:HTTP-Console_port/Policy/statistics (the default
port is 8081).

The ProxySG opens a separate browser window and displays the statistics.
2.

Examine the statistics, then close the browser.

375

Blue Coat ProxySG Configuration and Management Guide

376

Chapter 13: The Visual Policy Manager

The Visual Policy Manager (VPM) is graphical policy editor included with the ProxySG. VPM allows
you to define Web access and resource control policies without having an in-depth knowledge of Blue
Coat Systems Content Policy Language (CPL) and without the need to manually edit policy files.
This chapter assumes that you are familiar with basic concepts of ProxySG policy functionality as
described in Chapter 12: "Managing Policy Files".
While VPM creates only a subset of everything you can achieve by writing policies directly in CPL, it
is sufficient for most purposes. If your needs require more advanced policies, consult the Blue Coat
Content Policy Language Guide.
This chapter contains the following sections:


"Section A: About the Visual Policy Manager"



"Section B: Policy Layer and Rule Object Reference"



"Section C: Detailed Object Column Reference"



"Section D: Managing Policy Layers and Files"



"Section E: Tutorials"

Related topics:


Blue Coat Content Policy Language Guide



Chapter 12: "Managing Policy Files"



Chapter 17: "Content Filtering"

377

Blue Coat ProxySG Configuration and Management Guide

Section A: About the Visual Policy Manager

Section A: About the Visual Policy Manager
This section contains the following topics:

378



“JRE Requirement” on page 379—Discusses the Java Runtime Environment component
requirement.



"Launching the Visual Policy Manager" on page 379—Describes how to start VPM from the
Management Console.



"About the Visual Policy Manager User Interface" on page 380—Describes VPM menu items, tool
bars, and work areas.



"About VPM Components" on page 383—Provides definitions of the policy layers and describes
how rule objects comprise the layers.



"The Set Object Dialog" on page 386—Describes the dialog used to select objects to be added or
edited.



"The Add/Edit Object Dialog" on page 387—Describes the dialog used to add and edit rule
objects.

Chapter 13: The Visual Policy Manager

Section A: About the Visual Policy Manager

Menu Bar
The following table describes VPM Menu Bar items.
Table 13.1: VPM Menu Bar Items
Install Policy On ProxySG

Saves all new policy rules.

Revert to existing Policy on ProxySG

Ignores changes and reloads installed policy rules.

Exit

Exits the application.

Add Rule
Delete Rule

Adds a new blank rule to the visible policy layer or
removes a rule from the visible policy layer.

Cut Rule
Copy Rule
Paste Rule

Standard cut, copy, and paste operations.

Move Rule Up
Move Rule Down

Moves rules up or down one position in a policy layer.

Reorder Layers
Delete Layer

Reorders the policy layers.
Deletes a specific policy layer.

Policy

Add Admin Authentication Layer
Add Admin Access Layer
Add DNS Access Layer
Add SOCKS Authentication Layer
Add Web Authentication Layer
Add Web Access Layer
Add Web Content Layer
Add Forwarding Layer

The Policy menu items add policy layers to be
populated with policy rules.

Configuration

Set DNS Lookup Restrictions

Restricts DNS lookups during policy evaluation.

Set Reverse DNS Lookup Restrictions

Restricts reverse DNS lookups during policy
evaluation.

Set Group Log Order

Configures the order in which the group information
would is logged.

Edit Categories

Edits content filtering categories.

Generated CPL

Displays the CPL generated by VPM.

Current ProxySG VPM Policy Files

Displays the currently stored VPM policy files.

Object Occurrences

Lists the user-created object(s) in the selected rule; lists
use in other rules as well.

Tool Tips

Toggles the tool-tip display on and off.

Help Topics

Displays the online help.

About

Displays copyright and version information.

File

Edit

View

Help

Tool Bar
The VPM Tool Bar contains the following functions:


Add Rule—Adds a blank rule to visible policy layer; all values for the rule are the defaults.



Delete Rule—Deletes the selected rule from the visible policy layer.



Move Up—Moves a rule up one position in the visible policy layer.

381

Blue Coat ProxySG Configuration and Management Guide

Section A: About the Visual Policy Manager
As you create policy layers, you will create many different layers of the same type. Often, an overall
policy requires layers of different types designed to work together to perform a task. For example,
Authentication and Access layers usually accompany each other; an Authentication layer determines
if a user or client must authenticate, and an Access layer subsequently determines where that user or
client can go (what ProxySG or Web sites they can access) once they are authenticated.
Each object type is described in "Policy Layer and Rule Object Reference" on page 388.

Rule Objects
Policy layers contain rule objects. Only the objects available for that policy layer type are displayed.
There are two types of objects:


Static Objects—A self-contained object that cannot be edited or removed. For example, if you
write a rule that prohibits users from accessing a specific Web site, the Action object you select is
Deny.
Static objects are part of the system and are always displayed.



Configurable Objects—A configurable object requires parameters. For example, consider the rule
mentioned in the previous item that prohibits users from accessing a specific Web site. In this case,
the user is a Source object. That object can be a specific IP Address, user, group, user agent (such
as a specific browser), and so on. Select one and then enter the required information (such as a
verifiable user name or group name).
Configurable objects do not exist until you create them. A created object is listed along with all
static objects in the list dialog, and you can reuse it in other applicable policy layers. For example,
an IP address can be a Source or Destination object in many different policy-layer types.

Important: The orders of policy layers, and the order of rules within a layer are important. For more
information, see "How Policy Layers, Rules, and Files Interact" on page 452.
While individual object-type menus occasionally contain entries specific to the object type, the basic
menu options are:

384



Allow—(Web Access Layer Action column only) Quick menu access; sets the policy to allow.



Deny—(Web Access Layer Action column only) Quick menu access; sets the policy to deny.



Set—Displays the Set Object dialog where you select an object or create a new one.



Edit—Opens the Edit Object dialog where you edit an object or change to another.



Delete—Removes the selected object from the current rule and restores the default.



Negate—Defined as not. Negate provides flexibility in writing rules and designing the structure of
policies. The following is a simple Web Access rule that states: “When any client tries to access a
URL contained in an object of JobSearch, allow access.”

Blue Coat ProxySG Configuration and Management Guide

Section B: Policy Layer and Rule Object Reference

Section B: Policy Layer and Rule Object Reference
This section contains the following topics:

388



"About the Reference Tables" on page 389—Describes the table conventions used in this section.



"Administration Authentication Policy Layer Reference" on page 389—Describes the objects
available in this policy layer.



"Administration Access Policy Layer Reference" on page 389—Describes the objects available in
this policy layer.



"DNS Access Policy Layer Reference" on page 389—Describes the objects available in this policy
layer.



"SOCKS Authentication Policy Layer Reference" on page 390—Describes the objects available in
this policy layer.



"Web Authentication Policy Layer Reference" on page 391—Describes the objects available in this
policy layer.



"Web Access Policy Layer Reference" on page 391—Describes the objects available in this policy
layer.



"Web Content Policy Layer Reference" on page 393—Describes the objects available in this policy
layer.



"Forwarding Policy Layer Reference" on page 393—Describes the objects available in this policy
layer.

Chapter 13: The Visual Policy Manager

Section B: Policy Layer and Rule Object Reference

About the Reference Tables
The tables in this section list the static and configurable objects available for each policy layer.
Note:

If viewing this document as a PDF, you can click an object name to jump to a description of
that object (all objects are described in Section C). To jump back to a specific policy layer
reference, click policy layer name in any object reference table that appears in the next section.

Administration Authentication Policy Layer Reference
The following table provides the objects available in the Administration Authentication policy layer.
Source Objects

Action Objects

Track Objects

Client IP Address/Subnet

Do Not Authenticate

Trace

Client Hostname

Deny

Proxy IP Address/Port

Authenticate

Combined Objects

Force Authenticate

Administration Access Policy Layer Reference
The following table provides the objects available in the Administration Access policy layer.
Source Objects

Action Objects

Track Objects

Client IP Address/Subnet

Allow Read-Only Access

Event Log

Client Hostname

Allow Read-Write Access

Email

Proxy IP Address/Port

Deny

SNMP

User

Force Deny

Trace

Group

Combined Objects

Attribute
Combined Objects

DNS Access Policy Layer Reference
The following table provides the objects available in the DNS Access policy layer.
Source Objects

Destination Objects

Time Objects

Action Objects

Client IP
Address/Subnet

DNS Response
Contains No Data

Time

Bypass DNS Cache Event Log

Track Objects

Proxy IP
Address/Port

DNS Response IP
Address/Subnet

Combined
Objects

Do Not Bypass DNS Email
Cache

DNS Request
Name

RDNS Response Host

Allow DNS From
Upstream Server

SNMP

RDNS Request IP
Address/Subnet

DNS Response
CNAME

Serve DNS Only
From Cache

Trace

389

Blue Coat ProxySG Configuration and Management Guide

Section B: Policy Layer and Rule Object Reference
Source Objects

Destination Objects

DNS Request
Opcode

DNS Response Code

Time Objects

Action Objects

Track Objects

Enable/Disable
DNS Imputing

Combined
Objects

DNS Request Class Category

Send DNS/RDNS
Response Code

DNS Request Type

Send DNS
Response

Combined Objects

DNS Client
Transport

Send Reverse DNS
Response
Reflect IP

Combined Objects

Combined Objects

SOCKS Authentication Policy Layer Reference
The following table provides the objects available in the SOCKS Authentication policy layer.
Source Objects

Action Objects

Track Objects

Client IP Address/Subnet

Do Not Authenticate

Trace

Client Hostname

Authenticate

Proxy IP Address/Port

Force Authenticate

SOCKS Version
Combined Objects

390

Chapter 13: The Visual Policy Manager

Section B: Policy Layer and Rule Object Reference

Web Authentication Policy Layer Reference
The following table provides the objects available in the Web Authentication policy layer.
Source Objects

Destination Objects

Action Objects

Track Objects

Client Hostname
Unavailable

Destination IP
Address/Subnet

Do Not Authenticate

Trace

Client IP Address/Subnet

Destination Host/Port

Deny

Client Hostname

URL

Authenticate

Proxy IP Address/Port

Category

Force Authenticate

User Agent

Combined Objects

Request Header
Combined Objects

Web Access Policy Layer Reference
The following table provides the objects available in the Web Access policy layer.
Web Access policy layers regulate, from a general to a granular level, who or what can access specific
Web locations or content.


Users, groups, individual IP addresses, and subnets, as well as object lists comprised of any
combination of these, can be subject to rules.



Rules can include access control for specific Web sites, specific content from any Web site,
individual IP addresses, and subnets.



Actions taken can range from allowing and denying access to more finely tuned changes or
limitations.



Rules can also be subject to day and time specifications and protocol, file type, and agent
delimiters.

Source Objects

Destination Objects

Service Objects

Time Objects

Action Objects

Track Objects

Streaming Client

Destination IP
Address/Subnet

Using HTTP
Transparent
Authentication

Time

Allow

Event Log

Client Hostname
Unavailable

Destination Host/Port

Virus Detected

Combined
Objects

Deny

Email

Authenticated User

URL

Client Protocol

Force Deny

SNMP

Client IP
Address/Subnet

Category

Protocol Methods

Bypass Cache

Trace

Client Hostname

File Extensions

IM File Transfer

Do Not Bypass
Cache

Combined
Objects

Proxy IP
Address/Port

HTTP MIME Types

IM Message Text

Check/Do Not
Check Authorization

User

Response Code

IM Message
Reflection

Always Verify

391

Blue Coat ProxySG Configuration and Management Guide

Section B: Policy Layer and Rule Object Reference
Source Objects

Destination Objects

Service Objects

Time Objects

Action Objects

Group

Response Header

Streaming Content
Type

Use Default
Verification

Attribute

IM Buddy

ICAP Error Code

Block/Do Not Block
Pop-Up Ads

User Agent

IM Chat Room

Combined Objects

Force/Do Not Force
NTLM for Server
Auth

SOCKS Version

Reflect/Do Not
Reflect IM
Messages

Request Header

Block/Do Not Block
IM Encryption

IM User

Return Exception

Client Negotiated
Cipher

Return Redirect

Client Negotiated
Cipher Strength

Send IM Alert

Combined Objects

Modify Access
Logging
Override Access
Log Field
Rewrite Host
Reflect IP
Suppress Header
Control Request
Header/Control
Response Header
Strip Active Content
Modify IM Message
Return ICAP
Patience Page
Set External Filter
Service
Set ICAP Request
Service
Set FTP Connection
Set SOCKS
Acceleration
Set Streaming Max
Bitrate
Combined Objects

392

Track Objects

Chapter 13: The Visual Policy Manager

Section B: Policy Layer and Rule Object Reference

Web Content Policy Layer Reference
The following table provides the objects available in the Web Content policy layer.
The Web Content policy layer applies to requests independent of user identity.
Content scanning policy layers scan requested URLs and file types for viruses and other malicious
code. You must have an ICAP service installed on the ProxySG to use this policy type.
Destination Objects

Action Objects

Track Objects

Destination IP
Address/Subnet

Check/Do Not Check Authorization

Event Log

Destination Host/Port

Always Verify

URL

Use Default Verification

Email

Category

Use Default Caching

SNMP

File Extensions

Do Not Cache

Trace

HTTP MIME Types

Force Cache

Combined Objects

Combined Objects

Mark/Do Not Mark As Advertisement
Enable/Disable Pipelining
Set External Filter Service
Set ICAP Request Service
Set ICAP Response Service
Set TTL
Modify Access Logging
Override Access Log Field
Combined Objects

Forwarding Policy Layer Reference
The following table provides the objects available in the Forwarding policy layer.
Source Objects

Destination Objects Service Objects

Streaming Client

Destination IP
Address/Subnet

Client IP
Address/Subnet

Destination Host/Port Combined Objects

Integrate/Do Not Integrate
New Hosts

Client Hostname

URL

Allow Content From Origin
Server

Proxy IP
Address/Port

Combined Objects

Serve Content Only From
Cache

Combined Objects

Client Protocol

Action Objects

Track Objects

Send Direct

Trace

Select SOCKS Gateway
Select Forwarding
Reflect IP
Set IM Transport

393

Blue Coat ProxySG Configuration and Management Guide

Section B: Policy Layer and Rule Object Reference
Source Objects

Destination Objects Service Objects

Action Objects
Set Streaming Transport
Combined Objects

394

Track Objects

Chapter 13: The Visual Policy Manager

Section C: Detailed Object Column Reference

Section C: Detailed Object Column Reference
This section contains the following topics:


"Source Column Object Reference"



"Destination Column Object Reference"



"Service Column Object Reference"



"Time Column Object Reference"



"Action Column Object Reference"



"Track Object Column Reference"



"Comment Object Reference"



"Using Combined Objects"



"Creating Categories"

395

Blue Coat ProxySG Configuration and Management Guide

Section C: Detailed Object Column Reference

Source Column Object Reference
A source object specifies the communication or Web transaction origin that is evaluated by the policy.
Not all policy layers contain the same source objects; once you understand each source object,
however, you can configure as necessary in any layer of your policies.

Any
Applies to any source.

Streaming Client
This is a static object. This rule applies to any request from a streaming client.

Client Hostname Unavailable
This is a static object. This rule applies if the client IP address could not be looked up with a reverse
DNS query.

Authenticated User
This is a static object. This rule applies to any authenticated user.

Client IP Address/Subnet
Specifies the IP address and, optionally, a subnet mask of a client. The policy defined in this rule
applies only to this address or addresses on this subnet. This object is automatically named using the
prefix Client; for example, Client: 1.2.0.0/255.255.0.0.

Client Hostname
Specifies a reverse DNS hostname resolved in the reverse lookup of a client IP address. Enter the host
name and select matching criteria. This object is automatically named using the prefix Client; for
example, Client: host.com. If you select a matching qualifier, that attribute is appended to the object in
parentheses. For example, Client: host.com (RegEx).

Proxy IP Address/Port
Specifies the IP address and, optionally, a port on the ProxySG. The policy defined in this rule applies
only to this address or addresses with this subnet.

User
Specifies an individual user in the form of a verifiable username or login name. Enter a user name and
an authentication realm. The dialog then displays different information depending on the type of
authentication realm specified. Select the appropriate realm from the drop-down list. Items in the list
are taken from the realms configured by the administrator in the ProxySG.

396

Blue Coat ProxySG Configuration and Management Guide

Section C: Detailed Object Column Reference

DNS Request Name
Specifies a DNS request. Enter the host name and select matching criteria. This object is automatically
named using the prefix DNS; for example, DNS: host.com. If you select a matching qualifier, that
attribute is appended to the object in parentheses. For example, DNS: host.com (RegEx).

RDNS Request IP Address/Subnet
Specifies the reverse DNS IP address and, optionally, a subnet mask. The policy defined in this rule
applies only to this address or addresses on this subnet. This object is automatically named using the
prefix RDNS; for example, RDNS: 5.6.0.0/255.255.0.0.

DNS Request Opcode
Specifies OPCODEs to represent in the DNS header.
To Specify a DNS Request OPCODE Object:
1.

In the Name field, enter a custom name or leave as is to accept the default.

2.

Select one or more of the OPCODEs.

3.

Click OK.

DNS Request Class
Specifies the DNS request class (QCLASS) properties.
To Specify a DNS Request Class Object:
1.

In the Name field, enter a custom name or leave as is to accept the default.

2.

Select one or more of the request classes.

3.

Click OK.

DNS Request Type
Specifies the DNS request types (QTYPE) attributes.
To Specify a DNS Request Type Object:
1.

In the Name field, enter a custom name or leave as is to accept the default.

2.

Select one or more of the request types.

3.

Click OK.

DNS Client Transport
Specifies the DNS client transport method, UDP or TCP.

402

Chapter 13: The Visual Policy Manager

Section C: Detailed Object Column Reference

Client Negotiated Cipher Strength
Specifies the cipher strength. Select Export, Low, Medium, or High from the drop-down list. This object is
automatically named using the prefix Cipher Strength; for example, Cipher Strength: Medium.

Combined Source Object
Allows you to create an object that combines different source types. Refer to "Using Combined
Objects" on page 444.

Source Column/Policy Layer Matrix
The following matrix lists all of the Source column objects and indicates which policy layer they apply
to.
Object

Admin
Auth

Admin
Access

DNS
Access

SOCKS
Auth

Web
Auth

Web
Access

x

x

x

x

x

x

x

x

x

x

x

x

x

x

Streaming Client
Client Hostname
Unavailable

x

Authenticated User
Client IP Address/Subnet

x

Client Hostname

x

Proxy IP Address/Port

x

x

x

x

x

x

User

x

x

Group

x

x

Attribute

x

x

DNS Request Name

x

RDNS Request IP
Address/Subnet

x

DNS Request Opcode

x

DNS Request Class

x

DNS Request Type

x

DNS Client Transport

x
x

SOCKS Version

x

User Agent

x

x

Request Header

x

x
x

IM User
Combined Objects

Web
Forwarding
Content

x

x

x

x

x

x

x

405

Blue Coat ProxySG Configuration and Management Guide

Section C: Detailed Object Column Reference

Destination Column Object Reference
A destination object specifies the communication or Web traffic destination that is evaluated by the
policy. Not all policy layers contain the same destination objects; once you understand each
destination object, however, you can configure as necessary in any layer of your policies.

Any
Applies to any destination.

DNS Response Contains No Data
This is a static object.

Destination IP Address/Subnet
Specifies the IP address and, optionally, a subnet mask of a destination server. The policy defined in
this rule only applies to this address only or addresses within this subnet. This object is automatically
named using the prefix Destination; for example, Destination: 1.2.0.0/255.255.0.0.

Destination Host/Port
Specifies the hostname or port of a destination server. The policy defined in this rule applies to this
host on this port only. Enter the host name and port number, and select matching criteria. This object is
automatically named using the prefix Destination; for example, Destination: company:80.

URL
Specifies a URL entered by a user.
To Specify a URL:
Select a radio button and enter the required information in the fields:

406



Simple Match—Matches a partial URL. If a host name is specified, all hosts in that domain or
subdomain match; if a path is specified, all paths with that path prefix match; if a scheme or port
number is specified, only URLs with that scheme or port match. This object is automatically
named using the prefix URL; therefore, the object is displayed as URL: host.com.



Regular Expression Match—Specifies a regular expression. This object is automatically named using
the prefix URL; therefore, the object is displayed as URL: host.com (RegEx).



Advanced Match—Specifies a scheme (protocol), host, port range, and/or path. Enter a name at the
top of the dialog to name the object. With host and path, you can select from the drop-down list to
match exactly as entered or parts thereof: Exact Match, Contains, At Beginning, At End, or RegEx. If
you select a matching qualifier, that attribute is appended to the object in parentheses. For
example, URL: host.com (Contains).

Chapter 13: The Visual Policy Manager

Section C: Detailed Object Column Reference

Destination Column/Policy Layer Matrix
The following matrix lists all of the Destination column objects and indicates which policy layer they
apply to.
Object

Admin
Auth

Admin
Access

DNS
Access

SOCKS
Auth

Web
Auth

Web
Access

Destination IP Address/Subnet

x

x

x

x

Destination Port

x

x

x

x

URL

x

x

x

x
x

x

Web
Forwarding
Content

x

x

File Extensions

x

x

HTTP MIME Types

x

x

Response Header

x

Response Code

x

IM Buddy

x

Category

x

IM Chat Room
DNS Response IP
Address/Subnet

x

RDNS Response Host

x

DNS Response CNAME

x

DNS Response Code

x

Combined Objects

x

x

x

x

x

Service Column Object Reference
A service object specifies a service type, such as a protocol, that is evaluated by the policy. Not all
policy layers contain the same service objects; once you understand each service object, however, you
can configure as necessary in any layer of your policies.

Any
Applies to any service.

Using HTTP Transparent Authentication
This is a static object. The rule applies if the service is using HTTP transparent authentication.

Virus Detected
This is a static object. Based on a content scan, this object trigger is set as one of the following:


yes—A virus was detected and there were no scanning process errors on either the ProxySG or
the virus scanning server. Based on this, you can define an action. For example: to only allow to a
specific person, such as the administrator, to see the object but deny to everyone else; begin a
trace; and send to an access log.

411

Chapter 13: The Visual Policy Manager

Section C: Detailed Object Column Reference

Streaming Content Type
Defines streaming content by protocol.
To Specify Streaming Content Type:
1.

In the Name field, enter a name for the object or accept the default.

2.

Select All Streaming Content (all protocols become selected), or one or more streaming protocols.

3.

Click OK.

ICAP Error Code
Defines an object that recognizes one or more ICAP error codes returned during an antivirus scan. The
rule applies if the scan returns the specified errors.
To Specify ICAP Error Codes:
1.

In the Name field, enter a name for the object or accept the default.

2.

Select an option:


No errors—An ICAP scan was performed without scanning errors.



Any errors—An ICAP error code was returned during a scan.



Selected errors—An ICAP error code of a specific type or types.

In the Available Errors field, select one or more ICAP error codes (press and hold the Control
key to select more than one type or the Shift key to select a block of types). Click Add.
3.

Click OK.

Interactivity:


Of the available Selected errors, only the following error codes are available for all virus scanning
servers: Connection Failure, Internal Error, Request Timeout, Server Error, and Server Unavailable. The
other errors are specific to the Blue Coat ProxyAV virus scanning server.



If the ProxySG is configured to deny, this trigger cannot override that setting to allow; however, it
can trigger an exception action to deny if the ProxySG is configured to allow (see "Return
Exception" on page 423).

Combined Service Objects
Allows you to create an object that combines different service types. Refer to "Using Combined
Objects" on page 444.

Service Column/Policy Layer Matrix
The following matrix lists all of the Service column objects and indicates to which policy layer they
apply.

415

Blue Coat ProxySG Configuration and Management Guide

Section C: Detailed Object Column Reference
Object

Admin
Auth

Admin
Access

DNS
Access

SOCKS
Auth

Using HTTP Transparent
Authentication

Web
Auth

Web
Access

Web
Forwarding
Content

x

Virus Detected

x

Client Protocol

x

x

x

Protocol Methods

x

x

x

IM File Transfer

x

IM Message Text

x

IM Message Reflection

x

Streaming Content Type

x

ICAP Error Code

x

Combined Objects

x

x

x

Time Column Object Reference
A time object specifies a block of time or time trigger that determines client access regarding other
parameters in the rule (such Web sites and content types). Currently, the Time object is only applicable
to the Web Access Layer.

Any
Applies anytime.

Time
Specifies the time restrictions.
To Configure Time Restrictions:
1.

In the Name field, enter a name for the object or leave to accept the default.

2.

Select Use Local Time Zone or Use UTC Time Zone.
Local time sets the rule to follow the ProxySG internal clock. UTC sets the rule to use the
Universal Coordinated Time (also known as Greenwhich Mean Time or GMT).

3.

To specify a range for any given day, select Enable; in the Specify Time of Day Restriction (hh:mm)
field, configure the times. The time style is military.
The range can be contained within one 24-hour calendar day, or overlap days. For example,
configuring the time to range from 22:00 to 06:00 sets a limit from 10 at night to 6 the following
morning.

4.

416

To specify a day of the week restriction, select Enable; in the Specific Weekday Restriction field, select
one or more days.

Blue Coat ProxySG Configuration and Management Guide

Section C: Detailed Object Column Reference

Time Column/Policy Layer Matrix
The following matrix lists all of the Time column objects and indicates which policy layer they apply
to.
Object

Admin
Auth

Admin
Access

DNS
Access

SOCKS
Auth

Web
Auth

Web
Access

Time

x

x

Combined Objects

x

x

418

Web
Content

Forwarding

Chapter 13: The Visual Policy Manager

Section C: Detailed Object Column Reference

Action Column Object Reference
An action object determines which action to take if other parameters, such as source, destination,
service, and time requirements validate the rule. Not all policy layers contain the same action objects;
once you understand each action object, however, you can configure as necessary in any layer of your
policies.
Important: Because of character limitations required by the generated CPL, only alphanumeric,
underscore, and dash characters can be used to define an action object name.

Allow
This is a static object. Selecting this overrides other related configurations and the specified user
requests are allowed.

Deny
This is a static object. Selecting this overrides other related configurations and denies the specified
user requests.

Force Deny
This is a static object. Forces a request to be denied, regardless if rules in subsequent layers would
have allowed the request.

Allow Read-Only Access
This is a static object. Grants full access to view data on the appliance.

Allow Read-Write Access
This is a static object. Grants full access to view and manipulate data on the appliance.

Do Not Authenticate
This is a static object. Selecting this overrides other configurations and the specified users are not
authenticated when requesting content.

Authenticate
Creates an authentication object to verify users. An authentication realm must exist on the ProxySG to
be selected through VPM.
Note:

In the SOCKS Authentication policy layer, the object is SOCKS Authenticate.

419

Blue Coat ProxySG Configuration and Management Guide

Section C: Detailed Object Column Reference
To Create an Authentication Object:
1.

In the Name field, enter a name for the object or leave as is to accept the default.

2.

From the Realm drop-down list, select an authentication realm, which must already exist on the
ProxySG.

3.

Optional (in the Web Authentication policy layer only): from the Mode drop-down list, select a
mode. The mode determines the way the ProxySG interacts with the client for authentication
specifying the challenge type and the accepted surrogate credential:


Auto—The default; the mode is automatically selected, based on the request. Selects among

proxy, origin-IP, and origin-IP-redirect, depending on the type of connection (explicit or
transparent) and the transparent authentication cookie settings.


Form Cookie—For forms-based authentication: 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.



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 IP Redirect—This is similar to Form IP except that the user is redirected to the

authentication virtual URL before the form is presented.


Proxy—For explicit forward proxies: the ProxySG uses an explicit proxy challenge. No
surrogate credentials are used. This is the typical mode for an authenticating explicit proxy.



Proxy IP—The ProxySG uses an explicit proxy challenge and the client's IP address as a
surrogate credential.



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 Cookie—For transparent proxies: for clients that understand cookies but do not
understand redirects; the ProxySG acts like an origin server and issues origin server
challenges. The surrogate credential is used.



Origin Cookie Redirect—For transparent forward proxies: 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.



Origin IP Redirect—Significantly reduces security; only useful for reverse proxy and when

clients have unique IP addresses and do not understand cookies (or you cannot set a cookie).
Provides partial control of transparently intercepted HTTPS requests. 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.

420

Blue Coat ProxySG Configuration and Management Guide

Section C: Detailed Object Column Reference

Do Not Bypass DNS Cache
This is a static object. The ProxySG always queries the DNS cache list of resolved lookup names or
addresses.

Allow DNS From Upstream Server
This is a static object. Allows the ProxySG to send requests for data not currently cached to DNS
servers.

Serve DNS Only From Cache
This is a static object. Instructs the ProxySG to only serve a DNS request from content that is already
cached.

Enable/Disable DNS Imputing
These are static objects. If DNS imputing is enabled, the ProxySG appends the suffixes in the DNS
imputing list to hostnames looked up when the original name is not found.

Check/Do Not Check Authorization
These are static objects. These actions control whether or not the ProxySG forces a request to be sent to
an upstream server every time to check authorization, even if the content is already cached. The check
action is not usually required for upstream origin content servers performing authentication, as the
ProxySG automatically tracks whether content required authentication in each case. However, it can
be required when an upstream proxy is performing proxy authentication because of the way some
proxies cache credential information, causing them not to reliably challenge every request. When
requests are directed to an upstream proxy which operates in this manner, enabling Check
Authorization ensures that all such requests are properly authorized by the upstream proxy before the
content is served from the local cache.

Always Verify
This is a static object. Cached content is always verified for freshness for the sources, destinations, or
service specified in the rule. For example, the CEO and Executive Staff always require content to be
the most recent, but everyone else can be served from the cache.

Use Default Verification
This is a static object. Overrides the Always Verify action and instructs the ProxySG to use its default
freshness verification.

422

Chapter 13: The Visual Policy Manager

Section C: Detailed Object Column Reference

Block/Do Not Block Pop-Up Ads
These are a static objects. Blocks or allows pop-up windows. Blue Coat recommends creating separate
Web Access policy layers that only contain pop-up blocking actions. Furthermore, many Web
applications require pop-up windows. As it is unlikely that your intranet contains pages that pop-up
unwanted advertising windows, Blue Coat recommends disabling pop-up blocking for your intranet.
For example:


Web Access rule 1: Specify the intranet IP address and subnet mask in the Destination column and
select Do Not Block Popup Ads in the Action column.



Web Access rule 2: Select Block Popup Ads in the Action column.

As you continue to modify policy, you can add more policy layers to block or allow specific IP
addresses, but the policy layer as defined in the Web Access rule 2 above must always be positioned
last, blocking pop-up ads is the default if a previous policy rule does not trigger.
For more concept information about pop-up windows, refer to "Blocking Pop-Up Windows" on
page 473.

Force/Do Not Force NTLM for Server Auth
These are static objects. When configured for explicit proxy, Internet Explorer (IE) does not support an
NTLM challenge from an origin server. If Force NTLM for Server Auth is applied, the ProxySG converts
the 401-type server authentication challenge to a 407-type proxy authentication challenge, which IE
supports. The ProxySG also converts the resulting Proxy-Authentication headers in client requests to
standard server authorization headers, which allows an origin server NTLM authentication challenge
to pass through when IE is explicitly proxied through the ProxySG.

Reflect/Do Not Reflect IM Messages
These are static objects. IM traffic can be contained and restricted to the network so that it never
reaches the IM server. A hierarchy of ProxySG appliances manage the traffic and routes it depending
on each ProxySG fail open and fail closed configurations. For detailed information about this
deployment, refer to Chapter 16, Instant Messaging, of the Blue Coat Configuration and Management
Guide.

Block/Do Not Block IM Encryption
These are static objects. AOL IM provides the option for clients to send encrypted messages through
both standard messaging (through the IM service) and direct connection messaging. These objects
allow you to block or not block the ability to send encrypted messages through AOL IM. For detailed
information about security benefits of this feature, see Chapter 16, Instant Messaging, of the Blue Coat
Configuration and Management Guide.

Return Exception
Allows you to select exception types and associate a custom message, if desired. Blue Coat provides a
list of standard exceptions, but VPM also accepts user-defined values.

423

Chapter 13: The Visual Policy Manager

Section C: Detailed Object Column Reference
1.

In the Name field, enter a name for the object, or accept the default.

2.

In the large, blank field, enter text to be displayed.

3.

Select Set message text to replace the text displayed to the user. For example, Instant Messaging is
not allowed during these hours. Alternatively, select Append to message text to add the text to the
displayed message.

Chapter 16: “Instant Messaging” on page 527 provides more information about regulating IM through
the ProxySG, as well as VPM examples.

Return ICAP Patience Page
Specifies to display an ICAP patience page after a determinable amount of time. Enter a time value (in
seconds) that the ProxySG waits for content to be serviced from the origin content server before
displaying the page that instructs users an ICAP scan is in progress.
Note:

Patience pages display regardless of any pop-up blocking policy that is in effect.

Set External Filter Service
Specifies which installed content filtering service or service group a content request is subjected to or
bypasses, and specifies what occurs if a communication error occurs between the ProxySG and the
external service.
To Determine External Filter Service Request Behavior:
1.

In the Name field, enter a name for the object or leave as is to accept the default.

2.

To instruct all requests defined in the rule to route to a specific external filter service, select Use
External Filter Service; from the drop-down list, select the external filter service or service group
(which must already exist on the ProxySG).

3.

Under Error Handling, select the action the ProxySG perform if an error occurs during a content
scan:


Deny the client request (recommended)—The scan halts or does not begin, and the client does not
receive any content. Blue Coat recommends this option for optimum security.



Continue without further external filter service processing—The scan halts or does not occur;
however, the client receives the ProxySG-bypassed content. The security risk is increased, as
malicious content can be brought into the network.

433

Blue Coat ProxySG Configuration and Management Guide

Section C: Detailed Object Column Reference
2.

Select one of the following:


Automatically—Accelerates SOCKS requests automatically, based on the destination port

receiving the connection.


Do Not Accelerate—Never accelerate SOCKS requests matched by this rule.



Accelerate via [HTTP | AOL IM | MSN IM | Yahoo IM]—Specifies the type of acceleration applied

to requests matched by this rule.
3.

Click OK.

Set Streaming Max Bitrate
Specifies the maximum bitrate, in kilobits per second, of requested streaming media. If a request
exceeds this rule, the request is denied.

Send DNS/RDNS Response Code
Specifies to send out the default response code or a selectable error response code. Perform one of the
following:


Select Send Default DNS Response; optionally, enter a TTL value.



Select Send Error Response Code and select a code from the drop-down list.

Send DNS Response
Specifies which IP address to return for a specified host.
To Set a DNS Response:
1.

In the Host field, enter a host name that is returned.

2.

To respond with the incoming IP address, select Respond with proxy IP.

3.

To respond with one or more IP addresses:
a.

Select Respond with listed IPs.

b.

Click Add. The Add DNS Response IP dialog appears.

c.

Enter an IP address and click Add.

d. Repeat as desired; click Close when finished.
4.

(Optional) In the TTL field, enter a time-to-live value.

5.

Click OK.

Send Reverse DNS Response
Specifies which host to return for a reverse DNS response. Optional: define a time-to-live value.

436

Chapter 13: The Visual Policy Manager

Section C: Detailed Object Column Reference

Do Not Cache
This is a static object. Specifies that objects requested by the defined source or served by the defined
destination are never cached.

Force Cache
This is a static object. Specifies that objects are always cached; however, the object still must be a
cacheable object. For example, RealMedia file types that are supported in pass-through mode only are
not cached.

Use Default Caching
This is a static object. Overrides the Do Not Cache and Force Cache actions and instructs the ProxySG to
use its default determination of whether or not to cache the content.

Mark/Do Not Mark As Advertisement
These are static objects. Specifies content to be identified as an advertisement. The ProxySG still
fetches content from the cache (if present); however, just after serving to the client, the content is
re-fetched from the ad server so that hit counters are updated.

Enable/Disable Pipelining
These are static objects. Enables or disables the ProxySG pipelining feature, which, when enabled,
examines Web pages for embedded objects and requests them from the origin server in anticipation of
a client request.

Set TTL
Specifies the time-to-live (TTL) an object is stored in the ProxySG. In the Name field, enter a name for
the object (or leave as is to accept the default); in the TTL field, enter the amount of time in seconds.

Send Direct
This is a static object. Overrides forwarding host, SOCKS gateway, or ICP configurations and instructs
the ProxySG to request the content directly from the origin server.

Integrate/Do Not Integrate New Hosts
This is a static object. Used in server accelerator deployments. When enabled, the corresponding host
that is accessed is added to the list of hosts for which the ProxySG performs health checks. If that host
name resolves to multiple IP addresses that correspond to different servers, the ProxySG fetches
content from the available servers and ignores the servers that fail the health check.

437

Blue Coat ProxySG Configuration and Management Guide

Section C: Detailed Object Column Reference

Allow Content From Origin Server
This is a static object. Allows request to access content from an origin server if the content is not
cached.

Serve Content Only From Cache
This is a static object. Requests to access content that is not cached are denied. If the content is cached,
the content is served.

Select SOCKS Gateway
Specifies which SOCKS gateway, if any, to use; defines behavior if communication between the
SOCKS gateway and the ProxySG is down.


To instruct the rule to connect directly without routing through a SOCKS service, select Do not use
SOCKS gateway.



To instruct the rule to connect through a SOCKS gateway, select Use SOCKS Gateway and select an
installed SOCKS service from the drop-down list.
In the If no SOCKS gateway is available field, select Deny the request or Connect directly, which allows
requests to bypass the SOCKS service.

Select Forwarding
Specifies which forwarding host or group, if any, to use; defines behavior if communication between
the forwarding and the ProxySG is down.


To instruct the rule to connect directly without redirecting to a forwarding host or group, select Do
not forward.



To instruct the rule to redirect to a forwarding host, select Use Forwarding and select an installed
forwarding host from the drop-down list.
In the If no forwarding is available field, select Deny the request (fail closed) or Connect directly (fail open),
which allows requests to bypass the forwarding host.



To instruct the rule to forward using the ICP configuration, select Forward using ICP.

Set IM Transport
Specifies the transport method used for IM traffic.

438



Auto—Connects using the transport method used by the client.



HTTP—Tunnels the IM requests over HTTP.



Native—Connects using the native transport used by the service.

Chapter 13: The Visual Policy Manager

Section C: Detailed Object Column Reference

Set Streaming Transport
Specifies which streaming transport method the rule uses.


Auto—Connects using the transport method used by the client.



HTTP—Streaming over HTTP.



TCP—Streaming over TCP.

Combined Action Objects
Allows you to combine an action object that invokes multiple actions. See "Using Combined Objects"
on page 444.

Action Column/Policy Layer Matrix
The following matrix lists all of the Action column objects and indicates which policy layer they apply
to.
Object

Admin
Auth

Admin
Access

DNS
Access

SOCKS
Auth

Web
Auth

Web
Content

Forwarding

x

Allow
Deny

Web
Access

x

x

x

x

x

Allow Read-Only Access

x

Allow Read-Write Access
Do Not Authenticate

x

x

x

Authenticate

x

x

x

Force Authenticate

x

x

x

Bypass Cache

x

Do Not Bypass Cache

x

Check Authorization

x

x

Do Not Check Authorization

x

x

Always Verify

x

x

Use Default Verification

x

x

Block Up Ads

x

Do Not Block PopUp Ads

x

Force NTLM For Server Auth

x

Do Not Force NTLM For Server
Auth

x

Reflect IM Messages

x

Do Not Reflect IM Messages

x

Block IM Encryption

x

Do Not Block IM Encryption

x

Return Exception

x

Return Redirect

x

439

Blue Coat ProxySG Configuration and Management Guide

Section C: Detailed Object Column Reference
Object

Admin
Auth

Admin
Access

DNS
Access

SOCKS
Auth

Web
Auth

Web
Access

Web
Content

Send IM Alert

x

Modify Access Logging

x

x

Override Access Log Field

x

x

Rewrite Host

x

Reflect IP

x

Forwarding

x

Suppress Header

x

Control Request Header

x

Control Response Header

x

Strip Active Content

x

Modify IM Message

x

Return ICAP Patience Page

x

Set External Filter Service

x

Set ICAP Request Service

x

x
x

Set ICAP Response Service

x

Use Default Caching
Set FTP Connection

x

Set SOCKS Acceleration

x

Set Streaming Max Bitrate

x

Send DNS/RDNS Response
Code

x

Send DNS Response

x

Send Reverse DNS Response

x

Do Not Cache

x

Force Cache

x

Mark As Advertisement

x

Do Not Mark as Advertisement

x

Enable Pipelining

x

Disable Pipelining

x

Set TTL

x

Send Direct

x

Integrate New Hosts

x

Do Not Integrate New Hosts

x

Allow Content From Origin
Server

x

Serve Content Only From
Cache

x

Select SOCKS Gateway

x

Select Forwarding

x

Reflect IP

x

Set IM Transport

x

440

Blue Coat ProxySG Configuration and Management Guide

Section C: Detailed Object Column Reference
The substitution variables instruct the ProxySG to append specific information to the tracking
object. The variables are categorized alphabetically, according to prefix.
Note:

Some variables do not have prefixes.

Tracing Objects
This object specifies rule and Web traffic tracing.
Click Trace Level and select one of the following trace options:


No Tracing—The default.



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



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



Verbose Tracing—Generates the same output as Rule and Request, but also lists which rules were
skipped because one or more of their conditions were false, and displays the specific condition in
the rule that was false.

A trace destination can also be entered that specifies the destination for any trace produced by the
current transaction. To specify a destination path, select Trace File and enter a path in the field. For
example, abc.html.
If a trace destination is configured in multiple layers, the actual trace destination value displayed is
the one specified in the last layer that had a rule evaluated (which has a destination property
configured). Consider the following multiple Web Access Layer example, demonstrated by the
generated CPL:
;; Tab: [Web Access Layer (1)]

Deny trace.request(yes) trace.rules(no)trace.destination("abc.html"); Rule 1
;; Tab: [Web Access Layer (2)]

Deny trace.request(yes) trace.rules(all) trace.destination("xyz.html"); Rule 1
;; Tab: [Web Access Layer (3)]
Deny trace.request(yes) trace.rules(yes); Rule 1
;; Tab: [Web Access Layer (4)]

Deny trace.request(yes) trace.rules(no) ; Rule 1

The resulting actions are:

442



deny—from layer 4 rule 1



trace.request(yes)—from layer 4 rule 1



trace.rules(no)—from layer 4 rule 1

Blue Coat ProxySG Configuration and Management Guide

Section C: Detailed Object Column Reference


A new content filter database is downloaded automatically and the new update
contains category changes.



A new content filter database is downloaded manually by an administrator through the CLI or
the Management Console.

Restricting DNS Lookups
This section discusses DNS lookup restrictions and describes how to create a list.

About DNS Lookup Restriction
The DNS lookup restriction list is a list of domain names that apply globally, regardless of policy layer
definitions. Once a domain name is added to the list, DNS lookup requests do not occur for that
domain name while policy is evaluated. For more detailed information about using DNS lookups,
refer to the Blue Coat Content Policy Language Guide.

Creating the DNS Lookup Restriction List
The list is created from the VPM Menu bar.
To Create the DNS Lookup Restriction List:
1.

Select Configuration>Set DNS Lookup Restrictions; the Set DNS lookup restrictions dialog appears.
The default is None; no domain names are restricted.

2.

To restrict every domain name, select All.

3.

To add specific domain names, perform the following steps.
a.

Select Listed Host Patterns.
This enables the Host Patterns field.

b.

Click Add; the Add Host Pattern dialog appears.

c.

Enter a domain name; click OK.

d. Repeat to add other domain names.
e.

448

Click OK.

Chapter 13: The Visual Policy Manager

Section C: Detailed Object Column Reference

Restricting Reverse DNS Lookups
This section discusses reverse DNS lookup restrictions and describes how to create a list.

About Reverse DNS Lookup Restriction
The Reverse DNS lookup restriction list is a list of subnets that apply globally, regardless of policy
layer definitions. Once a subnet is added to the list, the ProxySG will not perform a reverse lookup of
addresses on that subnet during policy evaluation. For more detailed information about using reverse
DNS lookups, refer to the Blue Coat Content Policy Language Guide.

Creating the Reverse DNS Lookup Restriction List
The list is created from the VPM Menu bar. This prevents the ProxySG from performing reverse DNS
lookups of addresses in the list while evaluating policy.
To Create the Reverse DNS Lookup Restriction List:
1.

Select Configuration>Set Reverse DNS Lookup Restrictions; the Set Reverse DNS lookup restrictions
dialog appears.
The default is None; no subnets are restricted.

2.

To restrict every subnet, select All.

3.

To add specific subnets, perform the following steps.
a.

Select Listed Subnets.
This enables the Subnets field.

b.

Click Add; the Add Subnet dialog appears.

c.

Enter a subnet; click OK.

d. Repeat to add other subnets.
e.

Click OK.

Setting the Group Log Order
This section discusses the group log order and describes how to create a list.

About the Group Log Order
The Group Log Order object allows you to establish the order group data appears in the access logs.
For more detailed information about using group log ordering, refer to the Blue Coat Content Policy
Language Guide.

Creating the Group Log Order List
The list is created from the VPM Menu bar.

449

Blue Coat ProxySG Configuration and Management Guide

Section C: Detailed Object Column Reference
To Create the Group Log Order List:
1.

Select Configuration>Set Group Log Order; the Set Group Log Order dialog appears.

2.

Click Add; the Add Group Object dialog appears.

3.

In the Group Name field, enter the name of a group.
The group must be already configured on the ProxySG.

450

4.

From the Authentication Realm drop-down list, select a realm.

5.

Click OK.

6.

Repeat as required to add more groups.

7.

To order the list, select a group and click Move Up or Move Down until you achieve the desired
order.

8.

Click OK.

Chapter 13: The Visual Policy Manager

Section D: Managing Policy Layers and Files

Section D: Managing Policy Layers and Files
This section contains the following topics:


"How Policy Layers, Rules, and Files Interact" on page 452—Describes the importance of rule
order policy layer order.



"Managing Policy Files" on page 455—Describes how to save and install policies on the ProxySG.



"Installing VPM-Created Policy Files" on page 456—Describes how to propagate a policy file
created on one ProxySG to another.



"Viewing the Policy/Created CPL" on page 459—Describes how to view the underlying CPL that
is created with VPM.

451

Blue Coat ProxySG Configuration and Management Guide

Section D: Managing Policy Layers and Files

How Policy Layers, Rules, and Files Interact
The following critical points discuss the behaviors and priorities of policy rules, layers, and files:


Rules in different policy layers of the same type work together, and the order of policy layers is
important.



The order of policy layers of different types is important.



The order of rules in a policy layer is important.



Policy created in VPM is saved in a file on the ProxySG; the state of the VPM user interface is also
stored as an XML file on the ProxySG.
Note:



These files are stored only if the policy is installed without any errors.

How the appliance evaluates those rules in relation to policy layers that exist in the central and
local policy files is important. For more information, see Chapter 12: "Managing Policy Files".

How VPM Layers Relate to CPL Layers
VPM generates CPL in various layers, but the concept of layers presented in VPM is slightly different.
VPM provides policy layers for special purposes. For example, Web Authentication and Web
Authorization, which both generate CPL layers. This minimizes timing conflicts by

e-Highlighter

Click to send permalink to address bar, or right-click to copy permalink.

Un-highlight all Un-highlight selectionu Highlight selectionh